David Aguilar <davvid@xxxxxxxxx> writes: >> After hinting a low-hanging-fruit that would be an easy way for new >> people to dip their toes, I saw no takers for one month, so I ended >> up doing it myself. > > My bad,... Not yours. These hints I drop from time to time are meant for eager new people who want to dip their toes to the development (we don't do "assignments" but these are the closest that we have); you no longer quite qualify as "new" ;-) > While on the mergetool topic... Now we are not talking about "dip their toes" low hanging fruit anymore ;-) > Would the ability to resolve the various merge situations using > the command-line be a wanted addition? > > This would let a submodule or deleted/modified encountering > user do something like: > > $ git mergetool --theirs -- submodule > > ...and not have to remember the various git commands that it runs. Does it have to run various git commands? For a normal path, all it needs to do is "git checkout --theirs $path", no? What does it mean to resolve a conflicted merge of a gitlink to take "theirs"? We obviously would want to point the resolved gitlink at the submodule commit their side wants in the resulting index but what, if any, should we do to the submodule itself? Stepping back a bit, if there is no conflict, and as a result of a clean merge (this applies to the case where you check out another branch that has different commit at the submodule path), if gitlink changed to point at a different commit in the submodule, what should happen? If you start from a clean working tree, with your gitlink pointing at the commit that matches HEAD in the submodule, and if the working tree of the submodule does not have any local modification, it may be ideal to check out the new commit in the submodule (are there cases where "git checkout other_branch" in the superproject does not want to touch the submodule working tree?). There are cases where it is not possible; checking out the new commit in the submodule working tree may not succeed due to local modifications. But is that kind of complication limited to the merge resolution case? Isn't it shared with normal "switching branches" case as well? If so, it could be that your "git mergetool --theirs -- submodule" is working around a wrong problem, and the right solution may be to make "git checkout --theirs -- $path" to always do an appropriate thing regardless of what kind of object $path is, no? -- 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