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.
'reflog delete' can cause read_ref_at() to print an error message in
two ways.
1) If a reflog entry is deleted in the middle of the reflog, then
read_ref_at() will print an error message "warning: Log %s has
gap after %s". This is a sanity check which checks that the
previous reflog entry's "new" sha1 is equal to the current reflog
entry's "old" sha1.
2) If the top-most reflog entry does not match what is in refs/<ref>
then read_ref_at() will print an error message "warning: Log %s
unexpectedly ended on %s". This is another sanity check.
We can either disable these sanity checks, or change the code to ensure that
they pass, or do nothing in which case 'reflog delete' should probably be
removed.
For the first issue, we could rewrite the "old" sha1 while expiring reflog
entries. We would lose some of the meaning of reflog entries in this case.
For the second issue, the ref needs to be rewritten with the sha1 of the
top-most reflog entry. This makes sense for stash, but not for any other
ref.
I'm thinking that two new options to git-reflog are needed which will
implement the above two ideas. One will rewrite the "old" sha1 for each
reflog entry so that it points to the previous entry. The other will
update the ref so that it points at the top-most reflog entry.
thoughts? suggestion for the names for the options?
-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
