Re: [PATCH 16/18] revert: Remove sequencer state when no commits are pending

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

 



Hi again,

Jonathan Nieder writes:
> Ramkumar Ramachandra wrote:
> For reference:
>
>> My sequencer state was blown away just because of a stray
>> .git/remove-sequencer-state-after-commit from a previous operation!
>> This is horrible.  One can then argue: the file should only ever abort
>> *that* sequencer operation, and now we run into the problem of
>> assigning a UID for each sequencer operation.  Unnatural and ugly.
>> Conclusion: Making "git commit" remove the sequencer state is WRONG.
>
> That is a compelling argument for not using a
> .git/remove-sequencer-state-after-commit file, but I don't see why one
> would want such a file anyway.  Why can't "git commit" just call a
> function or use a command that examines .git/sequencer and looks at
> how many commits are left to pick?

Hm, yes.  I'd definitely like to see a tighter coupling between "git
commit" and the sequencer as it becomes more generalized.
Would you advocate this specific change now?  If so, I'll write an
implementation right away.  I was wondering whether you'd like such a
tight coupling at this stage.

> Looking at it from the other side, "My sequencer state was blown away"
> is a bit dramatic.  If it's a problem in "git commit", why isn't it a
> problem in "git reset", too?  If I just commited after resolving a
> conflict from applying the last commit in the series, what cherry-pick
> sequence state is going to be useful to me now?

Er, no.  I said "stray .git/remove-sequencer-state-after-commit" --
something that's left over from a long-forgotten sequencer operation*.
 Since "git reset" has already been established as a command that
removes the branch state, it's not as dramatic when "git reset"
removes the sequencer state; more so when "git commit" does it
accidentally.

> And how is this any less unnatural than making the 'abort cherry-pick'
> facility unusable when and only when cherry-picking the last commit in
> a sequence?  I don't get it.

I don't want to make it unusable! I was asking for suggestions (like
.git/SEQUENCER_HEAD).

* I realize now that we can remove this file before starting a fresh
sequencer operation.

Thanks.

-- Ram
--
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]