Re: [DRAFT] Branching and merging with git

J. Bruce Fields wrote:

This has some useful material that fills gaps in the existing
documentation.  We need to think a little more about the intended
audience, and about how to fit it in with existing documentation.

On Thu, Nov 16, 2006 at 05:17:01PM -0500, linux@horizon.com wrote:

quoted

* A brief digression on command names.

But the case I'm most interested in is the user whose
distribution installs git for them, in which case I think the above
could be distilled down to:

      - "git-foo" and "git foo" can be used interchangeably.

But it is encouraged (also for example by git-completion.bash) to use 
"git foo" form in command line (because git commands can be not in the PATH,
although usually they are), and "git-foo" form in scripts (if possible).

quoted

The details are too advanced for this discussion, but the default
"recursive" merge strategy that git uses solves the answer by merging
a and b into a temporary commit and using *that* as the merge base.

I'm tempted to ignore any description of the merge strategy, or postpone
it till later; as a first pass I think it's better just to say "obvious
cases will be handled automatically, and you'll be prompted for
comments."  Only other SCM developers are going to wonder how you handle
the corner cases.

See below...
 

quoted

* When merging goes wrong

But yes, I think people could use more help on how to resolve merges.

It would be useful to cover all non-reductible cases of recursive merge
strategy (the default merge strategy for two-head merges) conflicts: 
contents (covered), add/add, rename/modify etc.

So some info about recirsive merge strategy would be useful.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git