Dear diary, on Fri, Apr 15, 2005 at 02:58:25AM CEST, I got a letter
where Junio C Hamano <[EMAIL PROTECTED]> told me that...
> >>>>> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes:
> >> I think the above would result in what SCM person would call
> >> "merge upstream/sidestream changes into my working directory".
>
> PB> And that's exactly what I'm doing now with git merge. ;-) In fact,
> PB> ideally the whole change in my scripts when your script is finished
> PB> would be replacing
>
> PB> checkout-cache `diff-tree` # symbolic
> PB> git diff $base $merged | git apply
>
> PB> with
>
> PB> merge-tree.pl -b $base $(tree-id) $merged | parse-your-output
>
> In the above I presume by $merged you mean the tree ID (or
> commit ID) the user's working directory is based upon? Well,
> merge-trees (Linus has a single directory merge-tree already)
> looks at tree IDs (or commit IDs); it would never involve
> working files in random state that is not recorded as part of a
> tree (committed or not). Given that constraints I am not sure
> how well that would pan out. I have to think about this a bit.
No, $(tree-id) is the "destination branhc", what the user directory is
based upon; $merged is the branch you are merging now, relative to
$base. When I throw away the useless "-b" argument, in practice it would
look like
merge-trees abcd 1234 5678
for doing
/------ 1234 -+-
abcd < /
\------ 5678
(not that the order of 1234 and 5678 would actually really matter)
I fear I don't understand the rest of your paragraph. :-(
> I do like, however, the idea of separating the step of doing any
> checkout/merge etc. and actually doing them. So the command set
> of parse-your-output needs to be defined. Based on what I have
> done so far, it would consist of the following:
>
> - Result is this object $SHA1 with mode $mode at $path (takes
> one of the trees); you can do update-cache --cacheinfo (if
> you want to muck with dircache) or cat-file blob (if you want
> to get the file) or both.
>
> - Result is to delete $path.
>
> - Result is a merge between object $SHA1-1 and $SHA1-2 with
> mode $mode-1 or $mode-2 at $path.
>
> Would this be a good enough command set?
What about the conflicts? Like one tree deleting, other tree modifying?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
-
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
