Luben Tuikov <ltuikov@xxxxxxxxx> writes:
> Sometimes when I pull things from a bunch of places and do
> a resolve, I'm presented with the standard resolve format of
> a source file, "<<<< ==== >>>>" thingie, and all I'd really
> like to do is "accept ours". I.e. something similar to what I've
> seen in other (commercial) SCMs, a la "scm resolve accept ours".
>
> This patch merely allows the user to say
> git-checkout-index --stage=ours their_broken_file.c
> instead of
> git-checkout-index --stage=2 their_broken_file.c
> and similarly for "theirs", etc.
That's _exactly_ my point. It "merely allows to".
> If you think this breaks the ideology, ok.
It's not about the ideology. It's in the part you quoted but
did not respond to (by the way, please don't quote the the bulk
of the message if you are not responding to it).
You stopped at only adding "ours" as synonym for "2" and did not
do anything else in the patch; it is a very sensible thing to
do, because "checkout-index" is a plumbing command that is about
checking out files from the index to the working tree.
But that means you HAVE TO stop at that because you are working
at the plumbing layer. You said yourself that what you really
wanted to do was "scm resolve accept ours". And from an end
user's point of view, "checkout --stage=ours" is NOT it.
A user who wants to see "accept ours" wants the scm to perform:
git checkout-index --stage=2 paths...
git update-index paths... ;# or Nico's "git add"
for him. That is why I suggested to hoist the place you
implement this usability improvement up one level and make the
Porcelain level command:
git checkout --ours paths...
to do the above two plumbing command sequence internally for the
end user.
-
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