|
ExcessBLarg!, I think you've correctly assessed the situation. Upstream is aware of the messy situation of my PR. (I have no idea why they bother trying to keep up with me to be honest ...). When I try to push, I get code:This was after checking out my remote branch, merging in master, fixing the merge conflict, and committing. So am I supposed to do git push origin HEAD:my_remote/my_branch? Edit: wait wait. I did something wrong. I did everything again exactly as you said and now I'm looking at our CI trying to deal with my mess, so it seems it's working. Somewhat. Cingulate fucked around with this message at 12:25 on Apr 12, 2015 |
#
?
Apr 12, 2015 11:53
|
|
|
|
| # ? May 31, 2024 21:35 |
|
|
So basically there's two states you can be in a git repository: * On a branch * Detached HEAD There is always reference called HEAD which basically tells you and git "where you are" in a repository. HEAD points to either a branch (which in turn points to a commit), or it points directly to a commit (in which case it's a detached HEAD). When your HEAD points to a branch, it can do nice things like add commits to the branch, and update remotes with your new commits, etc. When you hop from one branch to another, you're telling HEAD to start looking at the other branch. However, it is possible to detach your HEAD, which kind of 'locks' you into a specific commit and can stop some bad things from happening. Now, when you do the command "git push", what you're telling it do is (it depends on your version and configuration, but this is basically the gist) look at the current branch that your HEAD is pointing to, and update the remote version of the branch to match it. However, if you aren't currently on a branch (that is, your HEAD is detached and is looking directly at a commit), then the "git push" command makes no sense because it requires you to be on a branch. That's what it's telling you. I've never pushed from a HEADless state, so I'm not sure what this will do, but you're better off getting back on the branch you want to push. HEADless states are usually reserved for deployments and advanced stuff.
|
|
#
?
Apr 12, 2015 13:35
|
|
|
A little Git question: I have modified a file and git status shows it correctly (https://github.com/leodido99/srdb_manager): "$ git status On branch dev Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: README.md modified: application/GUI/SC2KGUI/mainwindow.cpp modified: application/GUI/SC2KGUI/mainwindow.h modified: application/GUI/SC2KGUI/mainwindow.ui Untracked files: (use "git add <file>..." to include in what will be committed) application/Lib/dll/ no changes added to commit (use "git add" and/or "git commit -a")" However I don't understand why git says those changes are not staged for commit. The files are properly registered with git but when doing git commit it says no changes added to commit, I must always add git commit -a for it to show up? What am I doing wrong?
|
|
#
?
May 11, 2015 14:33
|
|
|
Git has an intermediate stage for adding files to a commit before you finalize the commit itself. You have to git add the files you want to stage for your commit. People generally use this to split up their changes into related commits so it's not a massive change in the commit log. http://git-scm.com/book/en/v2/Getting-Started-Git-Basics#The-Three-States
|
|
#
?
May 11, 2015 15:10
|
|
|
Le0 posted:However I don't understand why git says those changes are not staged for commit. The files are properly registered with git but when doing git commit it says no changes added to commit, I must always add git commit -a for it to show up? What am I doing wrong? Git does not automatically include all of your changes in each commit the way, say, SVN does. You must explicitly specify which changes you want to commit, using git add; this adds them to the "index", which is the snapshot of changes that will actually go into the next commit. git commit -a will automatically stage all modifies and deletes (but not new files) before making the commit. If you've made a bunch of changes but want to slice them into multiple commits, this lets you do that by picking and choosing individual files or even individual changes within those files (using git add -p or a GUI like git-gui or git-cola) to go into each commit.
|
|
#
?
May 11, 2015 15:11
|
|
|
Also note that git actually snapshots the file when you add it to the index. This means that in the following sequence: 1. Check out repository 2. Modify file A 3. git add A 4. Modify file A (some more) 5. git commit Only the changes made in step 2 are committed to a new revision, those made in step 4 are not stored anywhere in the history yet.
|
|
#
?
May 11, 2015 16:14
|
|
|
git gui is a good way to manage all of that if you're like me and don't like to interrupt your work constantly managing each part that should be a separate commit. Do a bunch of changes, then using git gui, pick out your changes into logical commits...
|
|
#
?
May 11, 2015 21:11
|
|
|
That clears it up, thanks guys. I'm going to give the GUI a try I think.
|
|
#
?
May 12, 2015 07:32
|
|
|
Le0 posted:That clears it up, thanks guys. I'm going to give the GUI a try I think. There are no great Git GUIs, but Sourcetree is okay.
|
|
#
?
May 12, 2015 10:42
|
|
|
Sourcetree is the first git GUI client that I've actually stuck with and not just gone back to the command line. I still pull up the terminal every now and then but Sourcetree is good for the most part.
|
|
#
?
May 12, 2015 12:41
|
|
|
Committing node_modules and bower_components: Yay or nay?
|
|
#
?
May 12, 2015 20:00
|
|
|
No, except for the fact that npm is lovely and node itself doesn't pride itself in backwards compatibility. So I'd be inclined to check those in on a production branch, but leave them out of the development branch.
|
|
#
?
May 12, 2015 20:07
|
|
|
ExcessBLarg! posted:No, except for the fact that npm is lovely and node itself doesn't pride itself in backwards compatibility. So I'd be inclined to check those in on a production branch, but leave them out of the development branch. Wouldn't you just make sure to specify a version of the package?
|
|
#
?
May 14, 2015 04:25
|
|
|
Ithaqua posted:Wouldn't you just make sure to specify a version of the package? The things you depend on aren't, so you need to do the equivalent of pip freeze.
|
|
#
?
May 14, 2015 07:53
|
|
only
|
That sounds like npm shrinkwrap.
|
|
#
?
May 14, 2015 13:32
|
|
|
This isn't a question, but I figured this is probably this was the most appropriate place to share it anyhow. It's a skit from our student revue at DIKU: git meets cheesy german porn https://www.youtube.com/watch?v=tBODkXG_OjI (  for the audio)
|
|
#
?
May 18, 2015 22:47
|
|
|
Ithaqua posted:Wouldn't you just make sure to specify a version of the package?
|
|
#
?
May 19, 2015 02:18
|
|
|
Newbie git question. Why does checking out a commit result in the "detached HEAD" state? If I do "git checkout . " my working directory simply gets changed to look just like the repo, so why doesn't "git checkout <sha>" simply make my working directory look like that commit? Why act like a new branch?
|
|
#
?
May 22, 2015 15:20
|
|
|
caiman posted:Newbie git question. Why does checking out a commit result in the "detached HEAD" state? If I do "git checkout . " my working directory simply gets changed to look just like the repo, so why doesn't "git checkout <sha>" simply make my working directory look like that commit? Why act like a new branch? http://gitolite.com/detached-head.html might be of some help. Specifically: quote:HEAD is, normally, a symbolic reference to [the tip of] a branch. For instance, if you do cat .git/HEAD on a brand new repository, you'll get back ref: refs/heads/master. When you add a commit, git actually updates 'master', because that's where HEAD points. You can see this by doing cat .git/refs/heads/master before and after making a commit. HEAD does not change (it's only a symbolic reference) but 'master' does.
|
|
#
?
May 22, 2015 18:28
|
|
|
Ok I think I understand. My hangup was on the discrepancy in behavior between passing checkout a path or not. If I'm understanding correctly: when you do "checkout <path>", it simply updates your working directory for that path but doesn't do anything with branches (which is what my earlier example of "checkout . " is doing, because "." is a path), but if you don't pass it a path, it switches branches. But since "checkout <commit>" doesn't specify a branch, you end up with a sort of anonymous branch (i.e. detached HEAD). Do I have this right?
|
|
#
?
May 22, 2015 18:59
|
|
|
There are three behaviours going on here: git checkout <commit> -- <file name> git checkout <commit> git checkout <branch name> This first command will look at the file/path you specify, and if it is not staged for commit, reset it to how it would be at <commit>. By default, this is HEAD, so your specific example expands actually to: git checkout HEAD -- ./ The -- is another default hidden argument and there to disambiguate between a branch name and a file name (imagine you had a file called master, but you wanted to check the file out, not the branch. The second command tells your HEAD to point to a specific commit. When you do this, git goes into a special mode called detached HEAD, which is useful for a number of reasons, but mainly because it 'fixes' your HEAD to the commit. This is useful on a Live server, where you don't want someone to inadvertently pull some code and move your HEAD because it was connected to a branch. Tags, which are usually used for versioning, work in this way, for instance. A detached HEAD is not a branch. The third command tells your HEAD to point to the branch you specify.
|
|
#
?
May 22, 2015 20:00
|
|
|
This is git, so I probably got something wrong, but yes, checkout does have several seemingly disparate functions although they do tie up conceptually it's still confusing as gently caress
|
|
#
?
May 22, 2015 20:02
|
|
|
o.m. 94 posted:it's still confusing as gently caress Glad to see I'm not the only one. Git makes me feel stupid.
|
|
#
?
May 22, 2015 20:07
|
|
|
Marsol0 posted:People generally use this to split up their changes into related commits so it's not a massive change in the commit log. This is nice in theory but it can blow up on you in practice. Let's say you gently caress up and commit something that doesn't build, or doesn't pass its tests? What happens when you come back a year and try to run git-bisect? Everyone does it on some minor stuff. But to guarantee your tools work properly, the gold standard is to only commit when you're willing to add everything and end up with a clean state. Just note it as a detail in the commit message. Or if you won't do that, at least stash all the other stuff and build/test before you commit it. See also: don't rebase, don't squash commits, don't cherry pick, etc. Rewriting history is bad if you're ever going to need to use it. And all the power user tools need to use it. http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.html Paul MaudDib fucked around with this message at 20:39 on May 22, 2015 |
|
#
?
May 22, 2015 20:33
|
|
|
Paul MaudDib posted:
Ugh that's a horribly misleading article. Rewriting history is fine, it only becomes problematic when you have non-local counterparts to your history (e.g. remote versions of branches). People who think there is 'one true way' to using git are often wrong. Empower yourself by finding out what works for you & the team.
|
|
#
?
May 22, 2015 20:58
|
|
|
Paul MaudDib posted:See also: don't rebase, don't squash commits, don't cherry pick, etc. Rewriting history is bad if you're ever going to need to use it. And all the power user tools need to use it. This is all terrible advice. The main point of history rewriting is to make "power user" tools like bisect more useful. Git amend is only "lying" in the sense that not committing after every single keypress is "lying" (and better not think about doing something and then not typing it!).
|
|
#
?
May 22, 2015 21:14
|
|
|
Seriously. Even if you have some weird "never rebase" policy, what's wrong with a cherry-pick?
|
|
#
?
May 22, 2015 21:29
|
|
|
ExcessBLarg! posted:Seriously. Even if you have some weird "never rebase" policy, what's wrong with a cherry-pick? E: I guess cherry pick would be fine since it happens to the head, and you'll know if its broken right away or not. Instantly committing a potentially broken state just rubs me the wrong way, but I guess since it's already broken there's probably nothing wrong with amending. You can make structural/logical changes to a file that won't trigger a conflict and the resulting commit still won't work. What's the fix when you come through with bisect later and hit a mini-commit that's broken, inch through the history until you find one that builds and passes the tests? How can you use rebasing to make the advanced stuff more effective? His argument sounds good to me but I'm not an expert. Rewriting history just seems like playing with fire. Paul MaudDib fucked around with this message at 22:57 on May 22, 2015 |
|
#
?
May 22, 2015 22:09
|
|
|
Q != E, I wish I could rewrite history on this mistaken commit.
Paul MaudDib fucked around with this message at 22:56 on May 22, 2015 |
|
#
?
May 22, 2015 22:11
|
|
|
Maybe junior programmer did a bunch of work in a branch, and some of it's real bad. However there's some good stuff in the middle - so you cherry-pick out a handful of commits, test them in your branch, then interactive rebase to squash it down into a sensible, test-passing commit. There are plenty of use-cases for rewriting history, because software development and team methodologies are vast and varied. git doesn't impose One True Workflow as the author of that article, like so many before and after him, are wont to do.  This thing right here? Hammering nails ONLY. Why would I want to pull out nails? I bought this hammer to hammer nails! o.m. 94 fucked around with this message at 22:45 on May 22, 2015 |
|
#
?
May 22, 2015 22:41
|
|
|
Paul MaudDib posted:You can make structural/logical changes to a file that won't trigger a conflict and the resulting commit still won't work. Paul MaudDib posted:What's the fix when you come through with bisect later and hit a mini-commit that's broken, inch through the history until you find one that builds and passes the tests? Well here's a question: if cherry-picks are bad, what's the preferred approach to pull a bug-fix commit across release branches (e.g., from develop to stable, old-stable, etc.)?
|
|
#
?
May 22, 2015 22:45
|
|
|
Honestly I think rules against rewriting your own history is silly. Basically every time I do a commit, I do a "git status; git show" to make sure everything I want is in there, the message is appropriate, and the diff is as expected. If there's a mistake, I do an amend commit. Once I'm happy with the commit, I generally run a build and test. Sometimes I'll do a rebase if I need to pull out a debug commit. For folks familiar with quilt or Mercurial queues, it's basically using git's local history as a patch stack. Once I'm happy with that set of changes, I'll push them out. Here, there's two main goals. First, only rewrite local (and currently private) history, don't do force pushes unless absolutely necessary or there's an agreed policy on a particular branch that force pushes are common and expected. The main reason to avoid force pushes is because anyone who pulls the interim commits is going to have a mess on their hands to deal with after the force push. But it doesn't really matter if you rewrite history before pushing. Unless folks start prodding timestamps closely, they wouldn't know (and wouldn't care) if your local history matches the actual history. The second goal is for each commit in the exposed history (that is, what I actually push out) to build and pass tests, so that yes, things like "git revert" are useful and "git bisect" work properly. Perhaps, occasionally things can break here. However, usually you can evaluate each commit and be aware of the risks to breaking builds. Should I find that builds are broken, and I'll rebase and squash a fix commit. Even if a commit does occasionally slip through that does break builds, it's only going to break "git bisect" and even then it's not really a big deal if it happens rarely. The upshot to that approach is that when folks pull my changes they can usefully review them and not be lost in weeds of "oops!" fix commits. Other workflows might work better for other folks though. ExcessBLarg! fucked around with this message at 23:18 on May 22, 2015 |
|
#
?
May 22, 2015 23:16
|
|
|
Paul MaudDib posted:This is nice in theory but it can blow up on you in practice. Let's say you gently caress up and commit something that doesn't build, or doesn't pass its tests? What happens when you come back a year and try to run git-bisect? Not rewriting history is stupid, that article is wrong. How else would you do code review? More commits to fix nits? gently caress that no.
|
|
#
?
May 22, 2015 23:20
|
|
|
Paul MaudDib posted:You can make structural/logical changes to a file that won't trigger a conflict and the resulting commit still won't work. Paul MaudDib posted:How can you use rebasing to make the advanced stuff more effective? His argument sounds good to me but I'm not an expert. Rewriting history just seems like playing with fire. Bisect works best if every commit compiles and passes all tests. This requires either editing commits after the fact, or going subversion style and never committing anything while it's still in progress and hoping that you can trust your editor's undo to go back to a previous WIP state. The latter is a terrible choice and doesn't actually have any advantages over creating a series of wip commits that you later squash down. Blame works much better if you don't have to step through five commits of "fix a typo in a comment" to get to the commit that made the actual functional change you care about.
|
|
#
?
May 22, 2015 23:31
|
|
|
More generally, anything that encourages you to have uncommitted changes sitting around is a bad thing.
|
|
#
?
May 22, 2015 23:51
|
|
|
Paul MaudDib posted:This is nice in theory but it can blow up on you in practice. Let's say you gently caress up and commit something that doesn't build, or doesn't pass its tests? What happens when you come back a year and try to run git-bisect? Don't treat git like it's subversion or something where you push after each commit. My rule, and the on I encourage my coworkers to follow, is that you can do anything with your commits, but a commit stops being yours once you push it. So far that hasn't really failed me. That being said, I don't know what kind of situations that you've been in that your rules are necessary, but I am sorry you had to deal with that. edit: Also, in your year case, if it's been that long before finding a problem you might as well note it and make a new commit that fixes the problem. History rewriting is bad for the remote and my opinion is that it is better to have bad approaches documented, rather than removed outright. Marsol0 fucked around with this message at 03:46 on May 23, 2015 |
|
#
?
May 23, 2015 03:44
|
|
|
Plorkyeran posted:Which is why you then test it and fix it if needed. I am the most senior developer on this project now (on the project 7 months, the other competent guy retired 2 months ago) so the chances of the this happening are null. The new guy (one of 2 developers on the project of 25) can't fix a null pointer error. No joke, "critical bug" that "stalled his team out for 3+ days" until he nagged me into fixing it for him. He bitched to his boss, his boss bitched to my boss, I finally squealed that this wasn't even close to the first time, my boss told me to hold strong, and then I got tired of him consuming 20% of my working time each day while I told him the two one-liners that could fix the bug he introduced to his branch and just committed the 2 lines. You either check whether what comes back from getAttribute is null or you forcibly assign a new variable when you restart your session and do the removeAttribute. So I guess that probably sounds good if I can squash his commits into nothingness? Reveal your secrets. Let me know the command line that blames all the poo poo on him. apseudonym posted:Not rewriting history is stupid, that article is wrong. What's a code review, precious? Our app is 80k lines plus a couple million rows of DB content, the old guy who just retired didn't believe in code reuse. Every single servlet is just a single 1000 line function, and I'd say there's at least 10k lines of redundant classes and pathways through the core business logic, if not 20k+. If I didn't write the tests they don't exist. I'm now more or less in charge of determining process for this. Yes, I have spent months raising hell about this poo poo and refactoring everything, I called him out a month before he left, the old guy graced me by deucing another couple thousand lines of code into his branch and lying to the team's face that he'd find a way to merge it for the last month before he retired. I hand-merged his turds into the develop branch that I'd spent 6 months completely refactoring while also building a totally new integration /workflow, 0% common code left outside the bullshit generic wrapper classes he'd built for java.util.hashmap that were implemented via O(N) iterations on java.util.list. Apparently he taught himself Java and managed to sustain a 25 year career. He also liked writing HTML using stringbuilders inside Java classes, accessing the database inside JSP files, displaying modal popups by having the browser send a GET that causes a session state alteration that the server catches via scriptlet, and hating on those damned kids who Not suprisingly we have a 3-5:1 tester:developer ratio. Also they refuse to spend any money on tools that might cut down on the trash fire that is our tester personnel budget. Our issue tracker is an excel file on a shared drive that people pate screenshots into. Yes, I have complained about this too, it only took 6 months to approve spending $6/person/month on JIRA since we moved to "agile". Now I'm trying talk them into spending another couple bucks per person-moth for capture too, since they can't write issues worth a drat. Wait, sorry, thought this was the coding horrors thread. Paul MaudDib fucked around with this message at 09:03 on May 23, 2015 |
|
#
?
May 23, 2015 07:44
|
|
|
Paul MaudDib posted:I am the most senior developer on this project now (on the project 7 months, the other competent guy retired 2 months ago) Sucks to be you but nice rant, man. You know some outside consultant is going to make a fortune on this once poo poo gets too bad even for management by making changes that you already suggested yourself?
|
|
#
?
May 23, 2015 09:34
|
|
|
Paul MaudDib posted:
One thing git definitely isn't useful for is fixing your dysfunctional software team
|
|
#
?
May 24, 2015 15:52
|
|
|
|
| # ? May 31, 2024 21:35 |
|
|
I'm completely unfamiliar with SVN, but an application I use distributes itself via SVN (lol). I made some changes to a couple of files that I want to just discard and get from SVN again. I don't want to overwrite changes I've made elsewhere in the whole project, just these two files that are in the same subdirectory. How do I do this?
|
|
#
?
May 24, 2015 17:37
|
|