From: Junio C Hamano <junkio@cox.net>
To: Petr Baudis <pasky@ucw.cz>
Cc: Linus Torvalds <torvalds@osdl.org>, git@vger.kernel.org
Subject: Re: Merge with git-pasky II.
Date: Fri, 15 Apr 2005 03:22:26 -0700 [thread overview]
Message-ID: <7vwtr4ibkt.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20050414233159.GX22699@pasky.ji.cz> (Petr Baudis's message of "Fri, 15 Apr 2005 01:31:59 +0200")
After I re-read [*R1*], in which Linus talks about dircache,
especially this section:
- The "current directory cache" describes some baseline. In particular,
note the "some" part. It's not tied to any special baseline, and you
can change your baseline any way you please.
So it does NOT have to track any particular state in either the object
database _or_ in your actual current working tree. In fact, all real
interactions with "git" are really about updating this staging area one
way or the other: you might check out the state from it into your
working area (partially or fully), you can push your working area into
the staging area (again, partially or fully).
And if you want to, you can write the thing that the staging area
represents as a "tree" into the object database, or you can merge a
tree from the object database into the staging area.
In other words: the staging area aka "current directory cache" is
really how all interaction takes place. The object database never
interacts directly with your working directory contents. ALL
interactions go through the current directory cache.
I started to have more doubts on the approach of *not*
performing the merge in the dircache I set up specifically for
merging, which is the direction in which you are pushing if I
understand you correctly. Maybe I completely misunderstand what
you want. This message is long but I need a clear understanding
of what is expected to be useful to you, so please bear with me.
PB> merge-tree.pl -b $base $(tree-id) $merged | parse-your-output
Please help me understand this example you have given earlier.
Here is my understanding of your assumption when the above
pipeline takes place. Correct me if I am mistaken.
* The user is in a working directory $W. It is controlled by
git-tools and there are $W/.git/. directory and $W/.git/index
dircache.
* The dircache $W/.git/index started its life as a read-tree
from some commit. The git-tools is keeping track of which
commit it is somewhere, presumably in $W/.git/ directory.
Let's call it $C (commit).
? Question. Is the $(tree-id) in your example the same as $C
above?
* The user have run [*1*] (see Footnote below) checkout-cache
on $W/.git/index some time in the past and $W is full of
working files. Some of them may or may not have modified.
There may be some additions or deletions. So the contents of
the working directory may not match the tree associated with
$C.
* The user may or may not have run [*1*] update-cache in $W.
The contents of the dircache $W/.git/index may not match the
tree associated with $C.
? Question. Are you forbidding the user to run update-cache by
hand, and keeping track of the changes yourself, to be
applied all at once at "git commit" time, thereby
guaranteeing the $W/.git/index to match the tree associated
with $C all times? From the description of The "GIT toolkit"
section in README, it is not clear to me which part of his
repository an end user is not supposed to muck with himself.
* Now the user has some changes in his working directory and
notices upstream or a side branch has notable changes
desireble to be picked up. So he runs some git-tools command
to cause the above quoted pipeline to run.
? Question. Does $merged in your example mean such an upstream
or side branch? Is $base in your example the common ancestor
between $C and $merged?
Assuming that my above understanding of your model is correct,
here are my "thinking aloud".
- "merge-trees $base $C $merged" looks only at the git object
database for those three trees named. The data structure of
git object database is optimized to distinguish differences
in those recorded trees (and hence recorded blobs they point
at) without unpacking most of the files if the changes are
small, because all the blobs involved are already hashed. It
is not very good at comparing things in git object store and
working files in random states, which would involve unpacking
blobs and comparing, so "merge-trees" does not bother.
- What can come out from merge-trees is therefore one of the
following for each path from the union of paths contained in
$base, $C, and $merged:
(a) Neither $C nor $merged changed it --- merge result is what
is in $C.
(b) $C changed it but $merged did not --- merge result is what
is in $C.
(c) Both $C and $merged changed it in the same way --- merge
result is what is in $C.
(d) $C did not change it but $merged did --- merge result is
what is in $merged.
(e) Both $C and $merged changed it differently --- merge is
needed and automatically succeeds between $C and $merge.
(f) Both $C and $merged changed it differently --- merge is
needed but have conflicts.
- Assuming we are dealing with the case where working files are
dirty and do not match what is in $C, among the above,
(a)-(c) can be ignored by SCM. What the user has in his
working files is exactly what he would have got if he started
working from the merge result, although in reality the work
was started from $C.
Handling (d), (e) and (f) from SCM's point of view would be
the same. They all involve 3-way merges between the file in
the working directory, and the file from $merged, pivoting on
the file from $base. In order to help SCM, merge-trees
therefore should output SHA1 of blobs for such a file from
$base and $merged and expect SCM to run "cat-file blob" on
them and then merge or diff3. Up to the point of giving
those two SHA1 out is the business of merge-trees and after
that it is up to SCM.
That would work. So I should base the design of output from
merge-trees on the above analysis, which probably needs to be
extended to cover differences between creation, modification,
and deletion.
- However, the above is quite different from the way Linus
envisioned initially, on which my current implementation is
based [*3*].
My current implementation is to record the merge outcome in
the temporary dircache $W/,,merge/.git/index for cases
(a)-(e). The last case (f) is problematic and needs human
validation [*2*], so it is not recorded in that temporary
dircache, but the files to be merged are left in that
temporary directory and merge-trees stops there. It is
expected that the end-user or SCM would merge the resulting
file and run update-cache to update $W/,,merge/.git/index.
After that happens, $W/,,merge/.git/index has the tree
representing the desired result of the merge. It is expected
that the end-user or SCM would write-tree, commit-tree there
in the temporary directory, creating a new commit $C1.
Then, it is expected that the SCM would make a patch file
between $C and the user working directory, checks out $C1
(either in the user's working directory or another temporary
directory; at this point merge-trees does not care because it
has already done its job and exited), applies that patch to
bring the user edits over to $C1. Then that directory would
contain the desired merge of user edits.
That is my understanding of how Linus originally wanted the
tool to do his kernel work with to work. My hesitation to
suggestions from you to change it not to keep its own merge
dircache is coming from here. Not doing what I am currently
doing to $W/,,merge/.git/index dircache would mean that SCM
would have to do more, not less, to arrive at $C1 (the result
of the clean $merge and $C merge pivoted at $base), where the
real SCM merge begins.
Although I suspect I am misunderstanding what you want, your
messages so far suggest that what you want might be quite
different from what Linus wants. Please do not misunderstand
what I mean by saying this. I am not saying that Linus is
always right [*4*] and therefore you are wrong for wanting
something else. It is just that, if what I started writing
needs to support both of those quite different needs, I need to
know what they are. I think I understand what Linus wants well
enough [*5*], but I am not certain about yours.
[Footnotes]
*1* By "The user have run" I mean either the user directly used
the low-level plumbing command himself, or used git-tools to
cause such command to run.
*2* Strictly speaking, case (e) needs human validation as
well, because successful textual merge does not guarantee
sensible semantic merge.
*3* See [*R2*] for descriptions on the way Linus wanted merge
in git to happen. Especially around "5) At this point you need
to MERGE" onwards. The current implementation handles (or
attempts to handle) the `your working directory was fully
committed' case described there.
*4* According to Linus himself, he is always right ;-). [*R3*]
*5* I consider [*R1*] and [*R2*] essential read for anybody
wanting to understand merging operation in git object model (I
am saying this for others; not for Pasky --- it would be like
preaching to the choir ;-)).
[References]
*R1* <Pine.LNX.4.58.0504110928360.1267@ppc970.osdl.org>
http://marc.theaimsgroup.com/?i=%3CPine.LNX.4.58.0504110928360.1267%20()%20ppc970%20!%20osdl%20!%20org%3E
*R2* <Pine.LNX.4.58.0504121606580.4501@ppc970.osdl.org>
http://marc.theaimsgroup.com/?i=%3CPine.LNX.4.58.0504121606580.4501%20()%20ppc970%20!%20osdl%20!%20org%3E
*R3*
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0008.3/0555.html
next prev parent reply other threads:[~2005-04-15 10:19 UTC|newest]
Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-14 0:29 Merge with git-pasky II Petr Baudis
2005-04-13 21:25 ` Christopher Li
2005-04-14 0:45 ` Petr Baudis
2005-04-13 22:00 ` Christopher Li
2005-04-14 3:51 ` Linus Torvalds
2005-04-14 1:23 ` Christopher Li
2005-04-14 5:03 ` Paul Jackson
2005-04-14 2:16 ` Christopher Li
2005-04-14 6:16 ` Paul Jackson
2005-04-14 7:05 ` Junio C Hamano
2005-04-14 8:06 ` Linus Torvalds
2005-04-14 8:39 ` Junio C Hamano
2005-04-14 9:10 ` Linus Torvalds
2005-04-14 11:14 ` Junio C Hamano
2005-04-14 12:16 ` Petr Baudis
2005-04-14 18:12 ` Junio C Hamano
2005-04-14 18:36 ` Linus Torvalds
2005-04-14 19:59 ` Junio C Hamano
2005-04-14 20:20 ` Petr Baudis
2005-04-15 0:42 ` Linus Torvalds
2005-04-15 2:33 ` Barry Silverman
2005-04-15 10:02 ` David Woodhouse
2005-04-15 15:32 ` Linus Torvalds
2005-04-15 16:01 ` David Woodhouse
2005-04-15 16:31 ` C. Scott Ananian
2005-04-15 17:11 ` Linus Torvalds
2005-04-16 15:33 ` Johannes Schindelin
2005-04-17 13:14 ` David Woodhouse
2005-04-15 19:20 ` Paul Jackson
2005-04-16 1:44 ` Simon Fowler
2005-04-16 12:19 ` David Lang
2005-04-16 15:55 ` Simon Fowler
2005-04-16 16:03 ` Petr Baudis
2005-04-16 16:26 ` Simon Fowler
2005-04-16 16:26 ` Linus Torvalds
2005-04-16 23:02 ` David Lang
2005-04-17 14:52 ` Ingo Molnar
2005-04-17 15:08 ` Brad Roberts
2005-04-17 15:18 ` Ingo Molnar
2005-04-17 15:28 ` Ingo Molnar
2005-04-17 17:34 ` Linus Torvalds
2005-04-17 22:12 ` Herbert Xu
2005-04-17 22:35 ` Linus Torvalds
2005-04-17 23:29 ` Herbert Xu
2005-04-17 23:34 ` Petr Baudis
2005-04-17 23:53 ` Kenneth Johansson
2005-04-18 0:49 ` Herbert Xu
2005-04-18 0:55 ` Petr Baudis
2005-04-17 23:50 ` Linus Torvalds
2005-04-18 4:16 ` Sanjoy Mahajan
2005-04-18 7:42 ` Ingo Molnar
2005-04-16 20:29 ` Sanjoy Mahajan
2005-04-16 20:41 ` Linus Torvalds
2005-04-15 2:21 ` [Patch] ls-tree enhancements Junio C Hamano
2005-04-15 16:13 ` Petr Baudis
2005-04-15 18:25 ` Junio C Hamano
2005-04-15 9:14 ` Merge with git-pasky II David Woodhouse
2005-04-15 9:36 ` Ingo Molnar
2005-04-15 10:05 ` David Woodhouse
2005-04-15 14:53 ` Ingo Molnar
2005-04-15 15:09 ` David Woodhouse
2005-04-15 12:03 ` Johannes Schindelin
2005-04-15 10:22 ` Theodore Ts'o
2005-04-15 14:53 ` Linus Torvalds
2005-04-15 15:29 ` David Woodhouse
2005-04-15 15:51 ` Linus Torvalds
2005-04-15 15:54 ` Paul Jackson
2005-04-15 16:30 ` C. Scott Ananian
2005-04-15 18:29 ` Paul Jackson
2005-04-14 18:51 ` Christopher Li
2005-04-14 19:35 ` Petr Baudis
2005-04-14 20:01 ` Live Merging from remote repositories Barry Silverman
2005-04-14 23:22 ` Junio C Hamano
2005-04-15 1:07 ` Question about git process model Barry Silverman
2005-04-14 20:23 ` Re: Merge with git-pasky II Erik van Konijnenburg
2005-04-14 20:24 ` Petr Baudis
2005-04-14 23:12 ` Junio C Hamano
2005-04-14 20:24 ` Christopher Li
2005-04-14 23:31 ` Petr Baudis
2005-04-14 20:30 ` Christopher Li
2005-04-14 20:37 ` Christopher Li
2005-04-14 20:50 ` Christopher Li
2005-04-15 0:58 ` Junio C Hamano
2005-04-14 22:30 ` Christopher Li
2005-04-15 7:43 ` Junio C Hamano
2005-04-15 6:28 ` Christopher Li
2005-04-15 11:11 ` Junio C Hamano
[not found] ` <7vaco0i3t9.fsf_-_@assigned-by-dhcp.cox.net>
2005-04-15 18:44 ` write-tree is pasky-0.4 Linus Torvalds
2005-04-15 18:56 ` Petr Baudis
2005-04-15 20:13 ` Linus Torvalds
2005-04-15 22:36 ` Petr Baudis
2005-04-16 0:22 ` Linus Torvalds
2005-04-16 1:13 ` Daniel Barkalow
2005-04-16 2:18 ` Linus Torvalds
2005-04-16 2:49 ` Daniel Barkalow
2005-04-16 3:13 ` Linus Torvalds
2005-04-16 3:56 ` Daniel Barkalow
2005-04-16 6:59 ` Paul Jackson
2005-04-16 15:34 ` Re: Re: " Petr Baudis
2005-04-15 20:10 ` Junio C Hamano
2005-04-15 20:58 ` C. Scott Ananian
2005-04-15 21:22 ` Petr Baudis
2005-04-15 23:16 ` Junio C Hamano
2005-04-15 21:48 ` [PATCH 1/2] merge-trees script for Linus git Junio C Hamano
2005-04-15 21:54 ` [PATCH 2/2] " Junio C Hamano
2005-04-15 23:33 ` [PATCH 3/2] " Junio C Hamano
2005-04-16 1:02 ` Linus Torvalds
2005-04-16 4:10 ` Junio C Hamano
2005-04-16 5:02 ` Linus Torvalds
2005-04-16 6:26 ` Linus Torvalds
2005-04-16 8:12 ` Junio C Hamano
2005-04-16 9:27 ` [PATCH] Byteorder fix for read-tree, new -m semantics version Junio C Hamano
2005-04-16 10:35 ` [PATCH 1/2] Add --stage to show-files for new stage dircache Junio C Hamano
2005-04-16 10:42 ` [PATCH 2/2] " Junio C Hamano
2005-04-16 14:03 ` Issues with higher-order stages in dircache Junio C Hamano
2005-04-17 5:11 ` Junio C Hamano
2005-04-17 5:31 ` Linus Torvalds
2005-04-17 6:01 ` Junio C Hamano
2005-04-17 10:00 ` Summary of "read-tree -m O A B" mechanism Junio C Hamano
2005-04-16 15:28 ` [PATCH 3/2] merge-trees script for Linus git Linus Torvalds
2005-04-16 16:36 ` Linus Torvalds
2005-04-16 17:14 ` Junio C Hamano
2005-04-15 19:54 ` Re: Merge with git-pasky II Petr Baudis
2005-04-15 10:22 ` Junio C Hamano [this message]
2005-04-15 20:40 ` Petr Baudis
2005-04-15 22:41 ` Junio C Hamano
2005-04-15 19:57 ` Junio C Hamano
2005-04-15 20:45 ` Linus Torvalds
2005-04-14 0:30 ` Petr Baudis
2005-04-14 22:11 ` git merge Petr Baudis
[not found] <000d01c541ed$32241fd0$6400a8c0@gandalf>
2005-04-15 20:31 ` Merge with git-pasky II Linus Torvalds
2005-04-15 23:00 ` Barry Silverman
2005-04-16 0:32 ` Linus Torvalds
-- strict thread matches above, loose matches on Subject: below --
2005-04-26 18:55 Bram Cohen
2005-04-26 19:58 ` Linus Torvalds
2005-04-26 20:30 ` Tom Lord
2005-04-26 20:31 ` Bram Cohen
2005-04-26 20:39 ` Tom Lord
2005-04-26 20:58 ` Linus Torvalds
2005-04-26 21:25 ` Linus Torvalds
2005-04-26 21:28 ` Bram Cohen
2005-04-26 21:36 ` Fabian Franz
2005-04-26 22:30 ` Linus Torvalds
2005-04-26 22:25 ` Linus Torvalds
2005-04-28 0:42 ` Petr Baudis
2005-04-26 21:26 ` Diego Calleja
2005-04-26 20:31 ` Daniel Barkalow
2005-04-26 20:44 ` Tom Lord
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vwtr4ibkt.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
--cc=pasky@ucw.cz \
--cc=torvalds@osdl.org \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).