J. Bruce Fields wrote:

quoted text
> 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:
>> * A brief digression on command names.

quoted text
> 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 text
>> 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 text
>> * 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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html