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@xxxxxxxxxxx wrote: >> * 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). >> 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... >> * 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html