Re: What's cooking in git.git (topics)

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 22, 2008, 22:26 UTC
Message-ID: <7vhcg07hmd.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <47BF18DF.6050100@nrlssc.navy.mil>

Brandon Casey <casey@nrlssc.navy.mil> writes:

Show 17 quoted lines

> Johannes Schindelin wrote:
>> Hi,
>> 
>> On Wed, 20 Feb 2008, Junio C Hamano wrote:
>
>>> * js/reflog-delete (Fri Jan 4 19:11:37 2008 -0600) 2 commits
>>>  + builtin-reflog.c: fix typo that accesses an unset variable
>>>  + Teach "git reflog" a subcommand to delete single entries
>>>
>>> There was a patch that uses this to implement "git-stash drop",
>>> which I didn't queue, as the command name and the UI was
>>> undecided yet.  Dscho was in favor of "pop" without "drop".
>> 
>> Maybe it is time to "drop" this topic?
>
> The issue with drop or pop (for me) was that deleting a reflog
> entry was causing error messages to be printed.

I agree with your analysis, and I am tempted to suggest just the simplest option.

The thing is, unless it is a reflog used to implement stash, removing an entry in the middle and adjusting an entry before and after it, just to fool and squelch the consistency mechanism we explicitly have for safety, feels quite wrong. Especially given that the whole point of the reflog is to allow you to recover your branch to a particular point in time safely.

So I'd rather see us remove "reflog delete" and add "reflog pop" which resets the ref itself to the previous point and deletes the last reflog entry. Then "stash pop" would become simply "stash apply" followed by "reflog pop".

We might need to introduce "stash push" which would be a synonym for "stash pop" for symmetry. Also we may want to introduce a stash per branch if we do this.