[PATCH] [checkout-index] Give names to stages

[PATCH] [checkout-index] Give names to stages

[Luben Tuikov]

[-- Attachment #1: Type: text/plain, Size: 371 bytes --]

One can now say "git-checkout-index --stage=ours ..."  or
"git-checkout-index --stage=theirs ...", instead of having
to remember the corresponding number assigned to each stage.

Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
 builtin-checkout-index.c |   11 ++++++++++-
 1 files changed, 10 insertions(+), 1 deletions(-)

I find this quite helpful when resolving.


[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 808 bytes --]

diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
index b097c88..d54a290 100644
--- a/builtin-checkout-index.c
+++ b/builtin-checkout-index.c
@@ -236,8 +236,17 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
 				int ch = arg[8];
 				if ('1' <= ch && ch <= '3')
 					checkout_stage = arg[8] - '0';
+				else if (!strncmp(arg+8, "ancestor", 8))
+					checkout_stage = 1;
+				else if (!strncmp(arg+8, "ours", 4))
+					checkout_stage = 2;
+				else if (!strncmp(arg+8, "HEAD", 4))
+					checkout_stage = 2;
+				else if (!strncmp(arg+8, "theirs", 6))
+					checkout_stage = 3;
 				else
-					die("stage should be between 1 and 3 or all");
+					die("stage should be "
+					    "(1|ancestor)|(2|ours|HEAD)|(3|theirs)");
 			}
 			continue;
 		}
-- 
1.4.4.1.gc87e

Re: [PATCH] [checkout-index] Give names to stages

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> writes:

> One can now say "git-checkout-index --stage=ours ..."  or
> "git-checkout-index --stage=theirs ...", instead of having
> to remember the corresponding number assigned to each stage.

I really do not like to have this in checkout-index; I would
rather keep checkout-index a purely plumbing thing.  If there
are valid and frequently appearing use cases that currently
requires "checkout-index --stage=$n", I think that need should
be addressed as a missing feature in the UI layer.

During a conflicted merge, you may run "diff --cc" in order to
decide that you would want to take yours (or theirs), and that
would be a good reason to wanting to checkout "your" version (or
"their" version; but I do not think of a valid reason to want to
say "checkout-index --stage=1").  From the UI point of view, it
would make more sense to be able to say:

	$ git checkout --ours hello.c
	$ git checkout --theirs Makefile

If the user is interested in looking at raw copies of our and
their version for comparison (not just "diff --theirs" kind of
usage), it _might_ even make sense to be able to do:

	$ git checkout --stdout --ours hello.c >hello.c-ours
	$ git checkout --stdout --theirs hello.c >hello.c-theirs
        $ diff -u hello.c-ours hello.c-theirs

I do not particularly like the above overloaded meaning of
"checkout" myself, but that would be something people who are
used to "cvs up -p" might expect to be able to do.

If we were to do both of the above, then it might even make
sense to make the first form (sans --stdout) to also mark the
index entry after checking out the specified higher stage.

And the UI layer (Porcelain-ish) should be where we should add
the "usability" and "human readability" bits.

Re: [PATCH] [checkout-index] Give names to stages

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
> 
> > One can now say "git-checkout-index --stage=ours ..."  or
> > "git-checkout-index --stage=theirs ...", instead of having
> > to remember the corresponding number assigned to each stage.
> 
> I really do not like to have this in checkout-index; I would
> rather keep checkout-index a purely plumbing thing.  If there
> are valid and frequently appearing use cases that currently
> requires "checkout-index --stage=$n", I think that need should
> be addressed as a missing feature in the UI layer.

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.

If you think this breaks the ideology, ok.

    Luben

> During a conflicted merge, you may run "diff --cc" in order to
> decide that you would want to take yours (or theirs), and that
> would be a good reason to wanting to checkout "your" version (or
> "their" version; but I do not think of a valid reason to want to
> say "checkout-index --stage=1").  From the UI point of view, it
> would make more sense to be able to say:
> 
> 	$ git checkout --ours hello.c
> 	$ git checkout --theirs Makefile
> 
> If the user is interested in looking at raw copies of our and
> their version for comparison (not just "diff --theirs" kind of
> usage), it _might_ even make sense to be able to do:
> 
> 	$ git checkout --stdout --ours hello.c >hello.c-ours
> 	$ git checkout --stdout --theirs hello.c >hello.c-theirs
>         $ diff -u hello.c-ours hello.c-theirs
> 
> I do not particularly like the above overloaded meaning of
> "checkout" myself, but that would be something people who are
> used to "cvs up -p" might expect to be able to do.
> 
> If we were to do both of the above, then it might even make
> sense to make the first form (sans --stdout) to also mark the
> index entry after checking out the specified higher stage.
> 
> And the UI layer (Porcelain-ish) should be where we should add
> the "usability" and "human readability" bits.

Re: [PATCH] [checkout-index] Give names to stages

[Junio C Hamano]

Luben Tuikov <ltuikov@yahoo.com> 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.

Re: [PATCH] [checkout-index] Give names to stages

[Luben Tuikov]

--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> 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"

Yes, that's what I normally do.

> 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.

Ok.

    Luben

Re: [PATCH] [checkout-index] Give names to stages

[Johannes Schindelin]

Hi,

On Sun, 3 Dec 2006, Luben Tuikov wrote:

> 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.

Dunno. When this problem hits me, I usually do

	git diff --theirs their_broken_file.c

anyway, to see what it is doing (colour and all). When I am satisfied, 
that "theirs" is really what I want, I just go back one in history, and 
append a call to git-apply like this:

	git diff --theirs their_broken_file.c | git apply --index

Ciao,
Dscho

Re: [PATCH] [checkout-index] Give names to stages

[Jakub Narebski]

Johannes Schindelin wrote:

> On Sun, 3 Dec 2006, Luben Tuikov wrote:
> 
>> 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.
> 
> Dunno. When this problem hits me, I usually do
> 
>       git diff --theirs their_broken_file.c
> 
> anyway, to see what it is doing (colour and all). When I am satisfied, 
> that "theirs" is really what I want, I just go back one in history, and 
> append a call to git-apply like this:
> 
>       git diff --theirs their_broken_file.c | git apply --index

Then

        git checkout --theirs their_broken_file.c

is obvious simplification.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: [PATCH] [checkout-index] Give names to stages

[Johannes Schindelin]

Hi,

On Mon, 4 Dec 2006, Jakub Narebski wrote:

> Johannes Schindelin wrote:
> 
> > On Sun, 3 Dec 2006, Luben Tuikov wrote:
> > 
> >> 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.
> > 
> > Dunno. When this problem hits me, I usually do
> > 
> >       git diff --theirs their_broken_file.c
> > 
> > anyway, to see what it is doing (colour and all). When I am satisfied, 
> > that "theirs" is really what I want, I just go back one in history, and 
> > append a call to git-apply like this:
> > 
> >       git diff --theirs their_broken_file.c | git apply --index
> 
> Then
> 
>         git checkout --theirs their_broken_file.c
> 
> is obvious simplification.

Obvious maybe. But simplification, not to me. Especially since the way I 
call it, there is less possibility to shoot myself into the foot.

But then, I do not really care.

Ciao,
Dscho