shared gitconfig

[Vladimir Panteleev]

On Sunday, 6 January 2013 at 19:50:47 UTC, Andrei Alexandrescu 
wrote:
> Sent this to dmd-internals, opening for a broader discussion:
>
> Hello,
>
>
> I wonder how we can define a few aliases of project-wide 
> usefulness to git. For example, I tried today to get the latest 
> and greatest phobos into my repo, and got a bunch of conflicts. 
> I searched a while on the net to figure what the command for 
> "just get the latest remote into my local copy", which is 
> entirely possible but not obvious and not easy to find. I got 
> it from here: http://goo.gl/pWvVB and the invocation is:
>
> git pull --rebase -s recursive -X ours

Question: Do you know what exactly does this command do?

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.

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 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?

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?

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).

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.

-- Vladimir, and too much coffee