On 1/6/13 4:03 PM, Vladimir Panteleev wrote:
On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu wrote:
git pull --rebase -s recursive -X ours
Question: Do you know what exactly does this command do?
I do now after having read about it at the end of several google searches.
Git is a very powerful and flexible system. Unfortunately, it is also
comparatively more complicated than its competitors, svn and hg.
Incorrect usage, especially by project maintainers, can result in
history rewrites, duplicate commits, and lost changes. This has already
happened multiple times in the past.
I agree it is important to be fluent with git. I'm an okay user but
currently unfit for an admin. Probably Walter is at a similar stage. I'm
doing my best to improve my knowledge in the limited time I have, and
part of it is discussing git here. So I hope you'll understand why I
find it contradictory to be reprimanded for doing so with the reproach
that I should be doing exactly what I'm doing.
Earlier I noticed some discussion regarding how Walter attempted to
follow a guide on the wiki regarding the release process. The problem is
that (from what I gathered) he attempted to simply run the commands
listed there, without understanding each one's exact effect and purpose.
An observation was raised that the guide was incomplete - however, I
believe the iteration at that point was written as a guideline (a
general outline of what needs to be done) as opposed to strict
step-by-step instructions. When stumped with a merge, he elected to use
the "git cherry-pick" command to copy the commits on top of his HEAD -
however, this duplicates the commits' contents and results in duplicate
commits in the repository.
I agree we need to develop a better understanding of git. At the same
time it would be great to learn the meaning of commands from a guide
that actually works, as opposed to a sketch that doesn't quite.
I think you're trying to solve the wrong problem...
Back to your question. Let's look at the command you posted:
git pull --rebase -s recursive -X ours
From my understanding, this this is what will happen:
1. Fetch whatever commit objects that are absent from your tree but are
present in the remote branch, and copy them to your tree. So far so good.
2. Rewind your HEAD to the tip of the branch you just pulled.
3. Take each commit that are in your branch's history, but are not in
the remote's history, and re-apply them on top of the new HEAD. This
creates new commit objects, with new SHA-1 hashes. Anything that builds
upon the old SHA-1 hashes (e.g. if you've already uploaded these commits
anywhere) will break. (--rebase rewrites history!)
4. Whenever there is a merge conflict, it will THROW AWAY your change
and automatically apply the other change.
Was this your intention?
Yes, that was exactly my intention.
Now, the question you should ask: WHY did you get a merge conflict?
Was it a case of you and someone else actually changing the same bit of
code? Or was it another instance of git abuse and someone force-pushing
after someone else already pulled the code?
I have no idea. To the best of my understanding I had no meaningful work
in master proper. The one conflict I looked at was in std/variant.d. It
was a conflict of an older version of the thing with a newer one (the
lines in conflict were at the recent apply functionality). I'd written
no lines of code in the conflict. It's not impossible I might have
checked out a pull request to look at it. Anyway, my purpose was:
whatever crap is in my master right now, make it the same as the
origin's master.
If the merge conflict is genuine, and you don't want to deal with the
merge, you should abort the merge, save your work as a new branch, and
reset the current branch to the remote's:
$ git merge --abort
$ git branch branch-name-for-my-work
$ git reset --hard origin/master
(substitute "origin" for the remote name, and "master" for the remote
branch name).
I get these tidbits of commands - git idioms - all the time, and I
forget them because I don't use them frequently. I don't see why it's a
crime to want to define some macros for such idioms instead of
essentially putting that in a text file that I'd be perusing now and then.
If you want to throw away any commits that are in your local branch but
not in the remote branch, just run the third command.
That's pretty much what I wanted but was unable to find easily by
searching the net.
Andrei
