git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Jeff King <peff@peff.net>
Cc: Steven Grimm <koreth@midwinter.com>,
	Junio C Hamano <gitster@pobox.com>,
	Chris Shoemaker <c.shoemaker@cox.net>,
	git@vger.kernel.org, Alex Riesen <raa.lkml@gmail.com>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [PATCH] Document what the stage numbers in the :$n:path syntax mean.
Date: Mon, 20 Aug 2007 02:05:22 -0400	[thread overview]
Message-ID: <20070820060522.GA27913@spearce.org> (raw)
In-Reply-To: <20070820055221.GA22993@coredump.intra.peff.net>

Jeff King <peff@peff.net> wrote:
> On Mon, Aug 20, 2007 at 11:36:38AM +0800, Steven Grimm wrote:
> 
> > The git-rev-parse manpage talks about the :$n:path notation (buried deep in
> > a list of other syntax) but it just says $n is a "stage number" -- someone
> > who is not familiar with the internals of git's merge implementation is
> > never going to be able to figure out that "1", "2", and "3" mean what Junio
> > said.
> 
> I often forget which number corresponds to which source. I seem to
> recall somebody proposing :ours:$path a while ago, but I couldn't find
> any reference in the archive, so perhaps I just dreamed it.
> 
> Am I the only one who messes this up? If not, patch is below.

Maybe.  ;-)

I've memorized it long long ago.  But my coworkers haven't and always
get it wrong, and look at me funny when I tell them "trust me, your
data is in stage 2 and theirs is in stage 3...  because that's the
convention all of the tools you are using follows".

Keywords in that last part: "convention" and "tools you are using".
Someone could redefine what the stages mean and load content into
them using `update index --index-info`.  You might even be able to
load the stages in odd ways yourself from Porcelain.

Oh, like say git-rebase.  During a rebase "theirs" (stage 3) is
your file and "ours" (stage 2) is the upstream.  Confusing now,
ain't it?  Mine is theirs and ours is theirs?  Huh?  Yeeaaaah.

This is why I've never liked most merge tools.  They get hung up on
what is theirs and what is mine and then at some point they wind up
confusing the stages and getting them inverted.  And this is exactly
why git-merge.sh/git-rebase.sh/git-am.sh try to setup GITHEAD_* for
git-merge-recursive, and why they set it up using branch names and
patch subject lines, because it makes the conflict markers easier
to understand.
 
>  	/* sha1:path --> object name of path in ent sha1
>  	 * :path -> object name of path in index
>  	 * :[0-3]:path -> object name of path in index at stage
> +	 * :base|ours|theirs:path -> same as :[1-3]:path
>  	 */

At least document the new syntax in git-rev-parse documentation?

-- 
Shawn.

  reply	other threads:[~2007-08-20  6:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-14 22:33 merge-recursive: do not rudely die on binary merge Junio C Hamano
2007-08-14 23:14 ` Chris Shoemaker
2007-08-15  0:07   ` Junio C Hamano
2007-08-15 11:19     ` Nikodemus Siivola
2007-08-15 11:50       ` Junio C Hamano
2007-08-20  3:36     ` [PATCH] Document what the stage numbers in the :$n:path syntax mean Steven Grimm
2007-08-20  5:52       ` Jeff King
2007-08-20  6:05         ` Shawn O. Pearce [this message]
2007-08-20  6:13           ` Shawn O. Pearce
2007-08-20  7:15             ` Florian Weimer
2007-08-20  8:04               ` Jeff King
2007-08-20  6:30           ` Junio C Hamano
2007-08-20  6:44             ` Jeff King
2007-08-22  0:14             ` Jakub Narebski
2007-08-20  6:37           ` Jeff King
2007-08-20  9:55         ` [PATCH] Document what the stage numbers in the :$n:path syntaxmean Johannes Sixt
2007-08-20  6:20       ` [PATCH] Document what the stage numbers in the :$n:path syntax mean Junio C Hamano
2007-08-20 18:08         ` Jan Hudec
2007-08-20 19:55           ` Junio C Hamano
2007-08-15  0:09   ` merge-recursive: do not rudely die on binary merge Junio C Hamano
2007-08-15  0:18     ` Chris Larson
2007-08-15  1:16     ` Chris Shoemaker

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=20070820060522.GA27913@spearce.org \
    --to=spearce@spearce.org \
    --cc=c.shoemaker@cox.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=johannes.schindelin@gmx.de \
    --cc=koreth@midwinter.com \
    --cc=peff@peff.net \
    --cc=raa.lkml@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).