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

From: Brandon Casey <casey@nrlssc.navy.mil>
Date: Feb 23, 2008, 00:19 UTC
Message-ID: <47BF669F.4070803@nrlssc.navy.mil>
In-Reply-To: <7vhcg07hmd.fsf@gitster.siamese.dyndns.org>

Junio C Hamano wrote:

Show 26 quoted lines

> Brandon Casey <casey@nrlssc.navy.mil> writes:
> 
>> 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.

Just to clarify, only the entry _after_ has to be adjusted.

If the primary reason for the old sha1 field is to be able to check the reflog for consistency, then maybe it makes sense to adjust this field. It's not used when resetting to a particular reflog entry is it?

We do lose something. The reflog entry conveys a transition _from_ a state _to_ a state. If the reflog entry is adjusted, the _from_ state is modified. But I think you would have to manually read the reflog file to see this information right? The fact that this information is lost is why I didn't feel comfortable adjusting the reflog entries by default. In the case of stash, this information is uninteresting.

> 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".

The patch series I sent would allow this with

    git reflog delete --updateref stash@{0}

I don't think that satisfies the requests though. People wanted to be able to delete any entries in the stash list.

Is any of this currently useful outside of stash? I don't know enough to know why someone would want to modify the ref without resetting at least the index and that is what git-reset is for. Also, outside of stash, I don't know why someone would want to delete individual reflog entries.

> We might need to introduce "stash push" which would be a synonym
> for "stash pop" for symmetry.

I like "stash push" if you mean _antonym_ and not _synonym_.

"stash pop" and "stash push" would be antonyms (opposite meaning). "stash push" and "stash save" would be synonyms (same meaning).

>  Also we may want to introduce a stash per branch if we do this.

This isn't necessary for how I use stash.

-brandon