From: Michael Haggerty <mhagger@alum.mit.edu>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
Scott Chacon <schacon@gmail.com>,
Jakub Narebski <jnareb@gmail.com>, Michael Nahas <mike@nahas.com>,
git@vger.kernel.org
Subject: Re: Command-line interface thoughts
Date: Thu, 09 Jun 2011 23:37:04 +0200 [thread overview]
Message-ID: <4DF13D00.2060000@alum.mit.edu> (raw)
In-Reply-To: <20110609200403.GA3955@sigill.intra.peff.net>
On 06/09/2011 10:04 PM, Jeff King wrote:
> I'm less sure about these new tokens, for a few reasons:
>
> 1. You get less useful answers in some situations by treating each
> stage as a separate tree (e.g., lack of combined diff). So why
> would I want to use them?
Wouldn't it be nice to be able to do a combined diff between *any* two
trees? Then the nonuniform merge behavior of "git diff" would be a
special case of a general concept:
git diff3 OURS NEXT THEIRS
> 4. They're supposed to be simpler to understand than index stages. But
> are they? The latest definitions seem to be:
>
> OURS is a tree of each path in the index, either from stage 2 if
> it exists, or from NEXT otherwise.
>
> NEXT is a tree of each path in the index, either from stage 0 if
> it exists, or from HEAD otherwise.
>
> But that doesn't seem any simpler to me than just saying "the index
> has numbered stages, and they correspond to resolved, base, ours,
> and theirs".
There is no need to explain the pseudotrees in terms of the index
stages; the pseudotrees are easier to understand and should therefore
become the primary way to describe the index. Let me give it a try, at
tutorial level. Assume that the concepts HEAD and WTREE have already
been introduced:
The "index" is a special area that can hold one or more temporary
snapshots of your version-controlled content. Each snapshot is
called a "tree" because it is analogous to a filesystem tree such
as the working tree [1].
Usually the index holds a single tree called "NEXT". NEXT is a
snapshot of the state of the working tree that is ready to be
committed. This usually consists of the contents from the commit
that was last checked out (HEAD), plus any changes that have been
staged for commit using "git stage".
It is possible to use "git diff" to view the difference between any
two trees, whether they be trees in the index, trees in commits, or
the working tree. For example, to see the difference between the
last commit and the working tree, use
git diff HEAD WTREE
If you would like to see the changes that are ready to be committed,
type
git diff HEAD NEXT
To see the changes in your working tree that have not yet been staged
for commit, use
git diff NEXT WTREE
(The previous command can be abbreviated to "git diff".)
However, things become more complicated during a merge, when the
index is used to keep track of the merge's progress. During a
merge, the index contains four trees: "NEXT", "OURS", "THEIRS", and
"BASE". These four trees are modified as merge conflicts are
resolved.
NEXT, as usual, contains the contents that are ready to be committed.
Specifically, NEXT contains:
* the original contents of the branch being merged into
* plus the merged versions of any files that merged cleanly
* plus any changes that have been staged for commit using
"git stage"; for example, files whose conflicts have been
resolved manually.
OURS contains all of the resolved merges from NEXT, with any
remaining conflicts resolved by using the version from the branch
being merged *into*.
THEIRS contains all of the resolved merges from NEXT, with any
remaining conflicts resolved by using the content from the branch
being merged *from*.
BASE contains all of the resolved merges from NEXT, with any
remaining conflicts resolved by using the content from the most
recent ancestor of the two branches being merged.
As before, "git diff" can be used to view the differences between
these various trees. For example, the following command displays the
conflicts that still have to be resolved:
git diff NEXT WTREE
To see how the resolved version differs from the contents of each of
the original branches, use
git diff HEAD NEXT
git diff MERGE_HEAD NEXT
The "git diff3" command can be used to compare three trees at once:
git diff3 OURS NEXT THEIRS
The previous command can be abbreviated to "git diff3".
[1] The trees that are stored in the index are in an internal format
that is optimized for efficiency. They are not stored as
individual files like in your working copy.
Thoughts?
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2011-06-09 21:37 UTC|newest]
Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <BANLkTikTWx7A64vN+hVZgL7cuiZ16Eobgg@mail.gmail.com>
2011-06-04 16:17 ` Command-line interface thoughts Michael Nahas
2011-06-04 21:49 ` Jakub Narebski
2011-06-05 1:00 ` Michael Nahas
2011-06-05 11:10 ` Jakub Narebski
2011-06-05 18:39 ` Scott Chacon
2011-06-05 23:37 ` Jakub Narebski
2011-06-06 6:16 ` Junio C Hamano
2011-06-06 7:34 ` Michael J Gruber
2011-06-06 11:45 ` Michael Nahas
2011-06-06 12:19 ` Jakub Narebski
2011-06-06 13:20 ` Michael J Gruber
2011-06-08 13:10 ` Jakub Narebski
2011-06-06 16:23 ` Junio C Hamano
2011-06-06 16:40 ` Drew Northup
2011-06-06 14:00 ` Junio C Hamano
2011-06-06 14:16 ` Michael J Gruber
2011-06-06 16:14 ` Junio C Hamano
2011-06-06 17:42 ` Scott Chacon
2011-06-06 19:01 ` Junio C Hamano
[not found] ` <BANLkTi=yytzDrJLvVn_ZhJOiQs-rqvKi1w@mail.gmail.com>
2011-06-07 2:31 ` Michael Nahas
2011-06-07 4:03 ` Junio C Hamano
2011-06-07 11:04 ` Michael Nahas
2011-06-07 6:11 ` Michael J Gruber
2011-06-07 11:45 ` Jonathan Nieder
2011-06-07 19:00 ` Holger Hellmuth
2011-06-07 19:11 ` Jonathan Nieder
2011-06-07 20:33 ` Jakub Narebski
2011-06-08 13:04 ` Holger Hellmuth
2011-06-08 18:56 ` Jakub Narebski
2011-06-09 11:55 ` Holger Hellmuth
2011-06-10 16:44 ` Jakub Narebski
2011-06-10 18:07 ` Holger Hellmuth
2011-06-10 18:35 ` Jakub Narebski
2011-06-10 22:45 ` Holger Hellmuth
2011-06-13 3:43 ` git diff --added (Re: Command-line interface thoughts) Jonathan Nieder
2011-06-13 4:11 ` Miles Bader
2011-06-13 4:46 ` Miles Bader
2011-06-13 8:06 ` Jonathan Nieder
2011-06-13 12:55 ` Junio C Hamano
2011-06-13 12:28 ` Junio C Hamano
2011-06-13 19:47 ` Holger Hellmuth
2011-06-13 20:31 ` Michael Nahas
2011-06-13 10:15 ` Command-line interface thoughts Jakub Narebski
2011-06-13 22:33 ` Holger Hellmuth
2011-06-14 4:21 ` Michael Haggerty
2011-06-14 7:51 ` Jakub Narebski
2011-06-07 19:34 ` René Scharfe
2011-06-07 19:38 ` Jakub Narebski
2011-06-08 11:12 ` Command-line interface thoughts (ad-hominem attacks) Jakub Narebski
2011-06-08 11:39 ` Michael Nahas
2011-06-08 12:42 ` Jakub Narebski
2011-06-08 14:15 ` Michael Nahas
2011-06-08 15:05 ` Jeff King
2011-06-08 18:57 ` Michael Nahas
2011-06-09 0:43 ` Jeff King
2011-06-09 1:56 ` Michael Nahas
2011-06-10 15:29 ` Jakub Narebski
2011-06-09 9:48 ` Command-line interface thoughts Jakub Narebski
2011-06-09 11:44 ` Michael Nahas
2011-06-09 12:45 ` Jakub Narebski
2011-06-09 13:06 ` Jakub Narebski
2011-06-09 9:06 ` Michael Haggerty
2011-06-09 10:02 ` Andreas Ericsson
2011-06-09 13:30 ` Thomas Rast
2011-06-09 16:18 ` Jeff King
2011-06-09 17:15 ` Jay Soffian
2011-06-09 17:20 ` Jeff King
2011-06-09 17:36 ` Junio C Hamano
2011-06-09 18:20 ` Jay Soffian
2011-06-09 19:40 ` Junio C Hamano
2011-06-09 18:03 ` Michael Haggerty
2011-06-09 18:38 ` Junio C Hamano
2011-06-09 19:17 ` Michael Haggerty
2011-06-09 20:04 ` Jeff King
2011-06-09 21:37 ` Michael Haggerty [this message]
2011-06-09 22:04 ` Jakub Narebski
2011-06-09 23:02 ` Michael Haggerty
2011-06-10 10:19 ` Jakub Narebski
2011-06-10 11:06 ` Michael Nahas
2011-06-10 12:20 ` Jakub Narebski
2011-06-09 22:21 ` Jeff King
2011-06-09 22:27 ` Michael Nahas
2011-06-09 22:38 ` Jeff King
2011-06-09 22:55 ` Jakub Narebski
2011-06-10 0:00 ` Michael Nahas
2011-06-10 0:08 ` Jeff King
2011-06-10 21:48 ` Junio C Hamano
2011-06-10 22:08 ` Junio C Hamano
2011-06-10 23:05 ` Jakub Narebski
2011-06-12 6:06 ` Michael Haggerty
2011-06-12 21:12 ` Junio C Hamano
2011-06-12 13:30 ` Michael Nahas
2011-06-12 21:29 ` Junio C Hamano
2011-06-13 2:14 ` Michael Nahas
2011-06-13 18:50 ` Jeff King
2011-06-09 19:41 ` Jeff King
2011-06-05 21:22 ` Paul Ebermann
2011-06-05 21:34 ` Paul Ebermann
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=4DF13D00.2060000@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jnareb@gmail.com \
--cc=mike@nahas.com \
--cc=peff@peff.net \
--cc=schacon@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).