From: Vincent van Ravesteijn <vfr@lyx.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: Edit a rerere conflict resolution
Date: Mon, 12 Mar 2012 21:20:07 +0100 [thread overview]
Message-ID: <4F5E5A77.1070605@lyx.org> (raw)
In-Reply-To: <7vobs1r3kn.fsf@alter.siamese.dyndns.org>
Op 12-3-2012 21:01, Junio C Hamano schreef:
> Vincent van Ravesteijn<vfr@lyx.org> writes:
>
>> Would it be a useful addition to have a command 'git rerere edit
>> <path> <commit>' ?
>>
>> This would allow the user to edit the conflict resolution which was
>> used in a certain commit (merge, rebase.. ).
>>
>> Now I tend to grep in the .git/rr-cache directory, because I don't
>> want to do 'git rerere forget' as this would require me to refix more
>> resolution than needed.
> I haven't find it necessary in practice, as the re-fix for me
> typically would go like this:
>
> $ git merge other-branch
> ... rerere kicks in; eyeball the results
> ... ah, my earlier resolution is no longer correct
> $ edit $the_path
> ... test the result of manual edit in the context of the merged whole
> ... and be satisified
> $ git rerere forget $the_path
> $ git add $the_path
> $ git commit
> ... rerere records the updated resolution
>
> What scenario do you have in mind that you would need to re-fix more
> resolution than you need?
Context:
I have a number of topic branches that modify the fileformat version and
also the fileformat conversion routines. When merging all those branches
into an integration branch (like you regenerate pu), there are a lot of
annoying merge conflicts in these two files. From one of your scripts I
took some code to automatically commit the merge resolution (here I go
wrong, I probably neglected the reason that git doesn't allow to
autocommit (yet)).
I can of course disable the autocommit, run the merge sequence again,
commit the correct merge resolutions, and modify the merge resolution
that went wrong.
But somehow I felt I was missing the 'git rerere edit' command. Aren't
the recorded merge resolutions essentially part of the codebase, though
in practice they remain rather anonymous temporary thingies.
But well, if the experts don't feel the need, I will search further to
implement something that you do think is useful ;).
Vincent
next prev parent reply other threads:[~2012-03-12 20:20 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-12 19:14 Edit a rerere conflict resolution Vincent van Ravesteijn
2012-03-12 20:01 ` Junio C Hamano
2012-03-12 20:20 ` Vincent van Ravesteijn [this message]
2012-03-12 20:34 ` Junio C Hamano
2012-03-12 21:21 ` Vincent van Ravesteijn
2012-03-12 21:34 ` Junio C Hamano
2012-03-12 21:39 ` Vincent van Ravesteijn
2012-03-12 21:40 ` Jakub Narebski
2012-03-12 21:52 ` Junio C Hamano
2012-03-16 15:54 ` Vincent van Ravesteijn
2012-03-16 16:01 ` Junio C Hamano
2012-03-16 16:14 ` Vincent van Ravesteijn
2012-03-16 16:20 ` Junio C Hamano
2012-03-16 16:37 ` Vincent van Ravesteijn
2012-03-16 16:42 ` Junio C Hamano
2012-03-17 11:03 ` Vincent van Ravesteijn
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=4F5E5A77.1070605@lyx.org \
--to=vfr@lyx.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).