>>>>> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
PB> What I would like your script to do is therefore just do the
PB> merge in a given already prepared (including built index)
PB> directory, with a passed base. The base should be determined
PB> by a separate tool (I already saw some patches); most future
PB> "science" will probably go to a clever selection of this
PB> base, anyway.
I think you are contradicting yourself for saying the above
after agreeing with me that the script should just work on trees
not commits. My understanding is that the tools is just to
merge two related trees relative to another ancestor tree,
nothing more. Especially, it should not care what is in the
working directory---that is SCM person's business.
I am just trying to follow my understanding of what Linus
wanted. One of the guiding principle is to do as much things as
in dircache without ever checking things out or touching working
PB> This will give the tool maximal flexibility.
I suspect it would force me to have a working directory
populated with files, just to do a merge.
PB> I'm all for an -o, and I don't mind ,, - I just don't want it uselessly
PB> long. I hope "git~merge~$$" was a joke... :-)
Which part do you object to? PID part? or tilde? Would
git~merge do, perhaps? It probably would not matter to you
because as an SCM you would always give an explicit --output
parameter to the script anyway.
PB> By the way, what about indentation with tabs? If you have a
PB> strong opinion about this, I don't insist - but if you
PB> really don't mind/care either way, it'd be great to use tabs
PB> as in the rest of the git code.
I do not have a strong opinion, but it is more trouble for me
only because I am lazy and am used to the indentation my Emacs
gives me. I write code other than git, so changing Perl-mode
indentation setting globally for all .pl files is not an option
for me. I'll see what I can do when I have time.
PB> Is there a fundamental reason why the directory cache
PB> contains the ancestor instead of the destination branch?
Because you are thinking as an SCM person where there are
distinction between tree-A and tree-B, two heads being merged.
There is no "destination branch" nor "source branch" in what I
am doing. It is a merge of two equals derived from the same
PB> I think the script actually does not fundamentally depend on it. My main
PB> motivation is that the user can then trivially see what is he actually
PB> going to commit to his destination branch, which would be bought for
PB> free by that.
And again the user is *not* commiting to his "destination
branch". At the level I am working at, the merge result should
be commited with two -p parameters to commit-tree --- tree-A and
tree-B, both being equal parents from the POV of git object
PB> And this is another thing I dislike a lot. I'd like merge-tree.pl to
PB> leave my directory cache alone, thank you very much. You know, I see
PB> what goes to the directory cache as actually part of the policy part.
Remember I am not touching *your* dircache. It is a dircache in
the temporary merge area, specifically set up to help you review
Can't the SCM driver do things along this line, perhaps?
- You have your working files and your dircache. They may not
match because you have uncommitted changes to your
environment. You want to merge with Linus head. You know
its SHA1 (call it COMMIT-Linus). Your SCM knows which commit
you started with (call it COMMIT-Current).
- First you merge the tree associated with COMMIT-Current. Use
it and COMMIT-Linus to find the common ancestor to use.
- Now use the tree SHA of COMMIT-Current, tree SHA1 of
COMMIT-Linus, and tree SHA1 of the common ancestor commit to
drive git-merge.perl (to be renamed ;-). You will get a
temporary directory. Have your user examine what is in
there, and fix the merge and have them tell you they are
- You go to that temporary directory, do write-tree and
commit-tree with -p parameter of COMMIT-Linus and
COMMIT-Current. This will result in a new commit. Call that
- You, as an SCM, should know what your user have done in the
working directory relative to COMMIT-Current. Especially you
should know the set of paths involved in that change. Go in
to the temporary area, checkout-cache those files if you have
not done so. Apply the changes you have there. Optionally
have the user examine the changes and have him confirm. Lift
those files into the user's working directory.
- Do your bookkeeping like "echo COMMIT-Merge >.git/Head", to
make the user's working files based on COMMIT-Merge, and run
read-tree using the COMMIT-Merge in the user's working
directory. At this point, show-diff output should show what
the changes your user have had made if he had started working
based on COMMIT-Merge instead of starting from
I think the above would result in what SCM person would call
"merge upstream/sidestream changes into my working directory".
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html