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

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

 



Junio C Hamano wrote:
> Brandon Casey <casey@xxxxxxxxxxxxxxx> 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

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

  Powered by Linux