Re: git cherry-pick --continue?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 10, 2010 at 02:21:14PM -0800, Junio C Hamano wrote:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
> 
> > Jeff King <peff@xxxxxxxx> writes:
> >
> >> Hmm. I was thinking "am" was the odd man out, but really there are only
> >> two sequencer commands that I noted: rebase and am. So you could perhaps
> >> argue that rebase should also learn "--resolved". Or am I forgetting
> >> one?
> 
> Having said all I did in the previous message, I think "am --continue"
> would be a good addition.

OK. I agree with your philosophical ramblings in the previous message,
but I also think there is some value in making it simple for the user to
remember.

Do you just want to pick up my patch from earlier in the thread, or do
you have further comments? The only thing I could think to change would
be that we may not want to even bother advertising --continue in the
usage message (conversely, we could go a step further and actually
advertise it in the manpage).

> And "rebase --resolved" would not make any sense if the reason the control
> is given back to you was because you ran "rebase -i" and marked a commit
> to be "edit"ed.  Of course, we could add "--resolved" and "--edited" (or
> perhaps "--amended") to "rebase", and have it make sure that the correct
> one is given.  For example, when it stopped for "edit", it would reject
> "rebase --resolved".  But I do not think it is worth the hassle.

Agreed.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]