Re: [PATCH 0/3] merge -Xindex-only
Thomas Rast writes: > Michael Haggerty writes: > > On IRC you said you would like a version that always acts as > --no-commit, and simply returns the conflict/no conflict bit as usual. > The caller would then proceed using commit-tree itself. I think that is > probably a saner solution than this "output ref" idea. I just had a huge facepalm moment. We already have this option. It is called git-merge-recursive. That is, git merge-recursive $(git merge-base --all HEAD other) -- HEAD other will internally do all the work that 'git merge other' would do, but not update any refs. With this series, you can therefore say git merge-recursive --index-only $(git merge-base --all HEAD other) -- HEAD other and get an *index-only* merge of HEAD and other. Can you see if this is enough to build git-imerge on top of it? Otherwise I'm glad to help with building the git-merge infrastucture to support it. I'll send v2 of the series in a minute; the only change is that I changed the internal flag semantics as per Junio's comment in http://thread.gmane.org/gmane.comp.version-control.git/229787/focus=229797 -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
Michael Haggerty writes:
> On 07/09/2013 02:08 PM, Thomas Rast wrote:
>> Michael Haggerty writes:
>>
>>> Since you've already implemented a way to merge into the index (even an
>>> alternative index) without touching the working copy, I'll just cross my
>>> fingers and hope for the appearance of an option that makes merge leave
>>> HEAD, MERGE_HEAD, etc. untouched.
>>
>> The most annoying part is probably where to put the output, since
>> merging is more or less defined to do one of:
>>
>> - update HEAD and return 0
>> - update MERGE_HEAD and return 1
>
> I don't understand what you mean here. [...]
I was simply trying to describe what the status quo is, as a basis for
the next paragraph. Does that clarify it?
>> I'm not sure how much flexibility is worth having. Would it be
>> sufficient if you had an option, e.g. -Xresult-ref=refs/heads/foo, that
>> changes it to:
>>
>> - update refs/heads/foo and return 0
>> - return 1, not updating any refs
>>
>> That would mean that it would only work for noninteractive use. In the
>> conflicting case, the driving script would need to remember what it
>> wanted to merge so as have the information when finally committing.
>
> That would be fine with me.
On IRC you said you would like a version that always acts as
--no-commit, and simply returns the conflict/no conflict bit as usual.
The caller would then proceed using commit-tree itself. I think that is
probably a saner solution than this "output ref" idea.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
On 07/09/2013 02:08 PM, Thomas Rast wrote: > Michael Haggerty writes: > >> Since you've already implemented a way to merge into the index (even an >> alternative index) without touching the working copy, I'll just cross my >> fingers and hope for the appearance of an option that makes merge leave >> HEAD, MERGE_HEAD, etc. untouched. > > The most annoying part is probably where to put the output, since > merging is more or less defined to do one of: > > - update HEAD and return 0 > - update MERGE_HEAD and return 1 I don't understand what you mean here. Why does *any* reference need to be updated? Why not * load arbitrary commit-ish A into index * merge arbitrary commit-ish B into index * return error/OK depending on whether there was a conflict ? The script that started the whole process would know what A and B are and could create the commit itself using "git write-tree" and "git commit-tree -p A -p B". And if the index were an alternative index chosen via GIT_INDEX_FILE then the rest of the git repo would be none the wiser. > I'm not sure how much flexibility is worth having. Would it be > sufficient if you had an option, e.g. -Xresult-ref=refs/heads/foo, that > changes it to: > > - update refs/heads/foo and return 0 > - return 1, not updating any refs > > That would mean that it would only work for noninteractive use. In the > conflicting case, the driving script would need to remember what it > wanted to merge so as have the information when finally committing. That would be fine with me. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
Michael Haggerty writes:
> Since you've already implemented a way to merge into the index (even an
> alternative index) without touching the working copy, I'll just cross my
> fingers and hope for the appearance of an option that makes merge leave
> HEAD, MERGE_HEAD, etc. untouched.
The most annoying part is probably where to put the output, since
merging is more or less defined to do one of:
- update HEAD and return 0
- update MERGE_HEAD and return 1
I'm not sure how much flexibility is worth having. Would it be
sufficient if you had an option, e.g. -Xresult-ref=refs/heads/foo, that
changes it to:
- update refs/heads/foo and return 0
- return 1, not updating any refs
That would mean that it would only work for noninteractive use. In the
conflicting case, the driving script would need to remember what it
wanted to merge so as have the information when finally committing.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
On 07/08/2013 05:44 PM, Thomas Rast wrote: > Michael Haggerty writes: > >> [Resend because of address confusion in replied-to email.] >> >> On 07/07/2013 08:00 PM, Thomas Rast wrote: >>> I recently looked into making merge-recursive more useful as a modular >>> piece in various tasks, e.g. Michael's git-imerge and the experiments >>> I made in showing evil merges. >>> >>> This miniseries is the extremely low-hanging fruit. If it makes a >>> good first step for git-imerge, perhaps it can go in like this. It's >>> not a big speedup (about 2.2s vs 2.4s in a sample conflicting merge in >>> git.git), but it does feel much cleaner to avoid touching the worktree >>> unless actually necessary. >>> >>> Otherwise it's probably not worth it just yet; for what I want to do >>> with it, we need some more reshuffling of things. >> >> Interesting. >> >> For git-imerge, it would be nice to speed up merges by skipping the >> working tree updates. 10% might not be so noticeable, but every little >> bit helps :-) >> >> But the killer benefit would be if git-imerge could do some of its >> automatic merge-testing and autofilling in the background while the user >> is resolving conflicts in the main index and working tree. >> >> Is it possible to use this option with an alternate index file (e.g., >> via the GIT_INDEX_FILE environment variable)? Can it be made to leave >> other shared state (e.g., MERGE_HEAD) alone? If so, maybe it's already >> there. > > GIT_INDEX_FILE yes, that one works out of the box. > > I think for the shared state, the following is a (probably) ridiculously > unsupported yet magic way of achieving this: > > mkdir -p unshared/.git > cd unshared/.git > for f in ../../.git/*; do > case "$f" in > *HEAD | index) > cp "$f" . > ;; > *) > ln -s "$f" . > ;; > esac > done > > That gives you a repository that propagates ref changes and object > writing, but does not propagate changes to index, HEAD, FETCH_HEAD or > MERGE_HEAD. Which might just be what you need? > > Note that as far as I'm concerned, this is a live handgrenade. It could > blow up in your face at any time, but it probably has its applications... I might consider such a thing for my own use, but I don't think I'll lob live hand grenades at innocent git-imerge users :-) Since you've already implemented a way to merge into the index (even an alternative index) without touching the working copy, I'll just cross my fingers and hope for the appearance of an option that makes merge leave HEAD, MERGE_HEAD, etc. untouched. It's not like I have any free time to work on git-imerge anyway :-( Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
Michael Haggerty writes:
> [Resend because of address confusion in replied-to email.]
>
> On 07/07/2013 08:00 PM, Thomas Rast wrote:
>> I recently looked into making merge-recursive more useful as a modular
>> piece in various tasks, e.g. Michael's git-imerge and the experiments
>> I made in showing evil merges.
>>
>> This miniseries is the extremely low-hanging fruit. If it makes a
>> good first step for git-imerge, perhaps it can go in like this. It's
>> not a big speedup (about 2.2s vs 2.4s in a sample conflicting merge in
>> git.git), but it does feel much cleaner to avoid touching the worktree
>> unless actually necessary.
>>
>> Otherwise it's probably not worth it just yet; for what I want to do
>> with it, we need some more reshuffling of things.
>
> Interesting.
>
> For git-imerge, it would be nice to speed up merges by skipping the
> working tree updates. 10% might not be so noticeable, but every little
> bit helps :-)
>
> But the killer benefit would be if git-imerge could do some of its
> automatic merge-testing and autofilling in the background while the user
> is resolving conflicts in the main index and working tree.
>
> Is it possible to use this option with an alternate index file (e.g.,
> via the GIT_INDEX_FILE environment variable)? Can it be made to leave
> other shared state (e.g., MERGE_HEAD) alone? If so, maybe it's already
> there.
GIT_INDEX_FILE yes, that one works out of the box.
I think for the shared state, the following is a (probably) ridiculously
unsupported yet magic way of achieving this:
mkdir -p unshared/.git
cd unshared/.git
for f in ../../.git/*; do
case "$f" in
*HEAD | index)
cp "$f" .
;;
*)
ln -s "$f" .
;;
esac
done
That gives you a repository that propagates ref changes and object
writing, but does not propagate changes to index, HEAD, FETCH_HEAD or
MERGE_HEAD. Which might just be what you need?
Note that as far as I'm concerned, this is a live handgrenade. It could
blow up in your face at any time, but it probably has its applications...
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
[Resend because of address confusion in replied-to email.] On 07/07/2013 08:00 PM, Thomas Rast wrote: > I recently looked into making merge-recursive more useful as a modular > piece in various tasks, e.g. Michael's git-imerge and the experiments > I made in showing evil merges. > > This miniseries is the extremely low-hanging fruit. If it makes a > good first step for git-imerge, perhaps it can go in like this. It's > not a big speedup (about 2.2s vs 2.4s in a sample conflicting merge in > git.git), but it does feel much cleaner to avoid touching the worktree > unless actually necessary. > > Otherwise it's probably not worth it just yet; for what I want to do > with it, we need some more reshuffling of things. Interesting. For git-imerge, it would be nice to speed up merges by skipping the working tree updates. 10% might not be so noticeable, but every little bit helps :-) But the killer benefit would be if git-imerge could do some of its automatic merge-testing and autofilling in the background while the user is resolving conflicts in the main index and working tree. Is it possible to use this option with an alternate index file (e.g., via the GIT_INDEX_FILE environment variable)? Can it be made to leave other shared state (e.g., MERGE_HEAD) alone? If so, maybe it's already there. For this feature to be useful for test merges, it would be enough to just get a retcode saying whether a given merge would succeed or conflict. For it to be used for autofilling, it would also be necessary to be able to create a commit from the merge result in the alternate index (this would only be done when there are no conflicts). I assume this part can be done in the usual way using "git commit-tree". Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] merge -Xindex-only
[Michael, sorry for the double mail -- I typoed the list address on the first round.] I recently looked into making merge-recursive more useful as a modular piece in various tasks, e.g. Michael's git-imerge and the experiments I made in showing evil merges. This miniseries is the extremely low-hanging fruit. If it makes a good first step for git-imerge, perhaps it can go in like this. It's not a big speedup (about 2.2s vs 2.4s in a sample conflicting merge in git.git), but it does feel much cleaner to avoid touching the worktree unless actually necessary. Otherwise it's probably not worth it just yet; for what I want to do with it, we need some more reshuffling of things. Thomas Rast (3): merge-recursive: remove dead conditional in update_stages() merge-recursive: untangle double meaning of o->call_depth merge-recursive: -Xindex-only to leave worktree unchanged Documentation/merge-strategies.txt | 4 merge-recursive.c | 46 +- merge-recursive.h | 1 + t/t3030-merge-recursive.sh | 13 +++ 4 files changed, 43 insertions(+), 21 deletions(-) -- 1.8.3.2.908.gbd0dbd0 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
