From: Luben Tuikov <ltuikov@yahoo.com>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] [checkout-index] Give names to stages
Date: Sun, 3 Dec 2006 21:18:32 -0800 (PST) [thread overview]
Message-ID: <505428.75434.qm@web31808.mail.mud.yahoo.com> (raw)
In-Reply-To: <7v1wngv2rc.fsf@assigned-by-dhcp.cox.net>
--- 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.
next prev parent reply other threads:[~2006-12-04 5:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-03 9:49 [PATCH] [checkout-index] Give names to stages Luben Tuikov
2006-12-04 2:00 ` Junio C Hamano
2006-12-04 5:18 ` Luben Tuikov [this message]
2006-12-04 6:32 ` Junio C Hamano
2006-12-04 6:59 ` Luben Tuikov
2006-12-04 10:52 ` Johannes Schindelin
2006-12-04 11:36 ` Jakub Narebski
2006-12-04 11:39 ` Johannes Schindelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=505428.75434.qm@web31808.mail.mud.yahoo.com \
--to=ltuikov@yahoo.com \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.