From: Michael J Gruber <git@drmicha.warpmail.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Jay Soffian <jaysoffian@gmail.com>
Subject: Re: [PATCH] rerere.txt: Document forget subcommand
Date: Wed, 16 Jun 2010 09:42:24 +0200 [thread overview]
Message-ID: <4C188060.5000903@drmicha.warpmail.net> (raw)
In-Reply-To: <7vr5k86ylg.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 15.06.2010 18:37:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> dea4562 (rerere forget path: forget recorded resolution, 2009-12-25)
>> introduced the forget subcommand for rerere.
>> ...
>> diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
>> index acc220a..a7370d3 100644
>> --- a/Documentation/git-rerere.txt
>> +++ b/Documentation/git-rerere.txt
>> @@ -40,6 +40,10 @@ This resets the metadata used by rerere if a merge resolution is to be
>> aborted. Calling 'git am [--skip|--abort]' or 'git rebase [--skip|--abort]'
>> will automatically invoke this command.
>>
>> +'forget' <pathspec>::
>> +
>> +This resets the conflict resolutions which rerere has recorded for <pathspec>.
>> +
>
> This description is not _incorrect_ per-se, but it does not convey one
> important aspect of the subcommand; unlike "clear" and "gc", "forget" only
> works in the context of the _current_ conflict resolution, just like
> "diff" and "status".
Does "current context" mean
- any recorded resolutions for the hunks which are currently recorded as
in in conflict
or
- the resolution which has (just) been recorded for the current conflict?
I'm completely agnostic of the underlying implementation of rerere (as
demonstrated by my questions probably...).
> Perhaps s/for <pathspec>/for the current conflict in <pathspec>/ would be
> a sufficient improvement?
I guess that would mean 2 above?
In any case, rerere forget is not a solution for the original "amend
merge commit and forget previous resolution" question, I guess (I just
happened to note it's undocumented). One would have to redo the merge to
get the conflict info into the index, right?
Michael
next prev parent reply other threads:[~2010-06-16 7:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-14 23:04 Amending a merge commit doesn't update the rerere cache Jay Soffian
2010-06-15 6:21 ` [PATCH] rerere.txt: Document forget subcommand Michael J Gruber
2010-06-15 16:37 ` Junio C Hamano
2010-06-15 16:45 ` Jay Soffian
2010-06-16 7:42 ` Michael J Gruber [this message]
2010-06-16 17:33 ` Junio C Hamano
2010-07-05 13:15 ` [PATCHv2] " Michael J Gruber
2010-06-15 6:23 ` Amending a merge commit doesn't update the rerere cache Johannes Sixt
2010-06-15 13:08 ` Jay Soffian
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=4C188060.5000903@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jaysoffian@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.