Re: can we prevent reflog deletion when branch is deleted?

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

 



Jeff King wrote:
> Why don't the branch names have significance? If I deleted branch "foo"
> yesterday evening, wouldn't I want to be able to say "show me foo from
> 2pm yesterday" or even "show me all logs for foo, so that I can pick the
> useful bit from the list"?

Oh, I misunderstood then.  I didn't realize that your usecase was actually

    git log foo@{yesterday}

where foo is a deleted branch.  Just to give some perspective, so we
don't limit our problem space:

I only ever batch-delete "cold" branches: if I haven't touched a
branch in ~2 months, I consider the work abandoned (due to disinterest
or otherwise) and remove it.  Most of my branches are short-lived, and
I don't remember branch names, much less of the names of the cold
branches I deleted.  My usecase for a graveyeard is "I lost something,
and I need to find it": I don't want to have to remember the original
branch name "foo"; if you can tell everything I deleted yesterday, I
can spot foo and the commit I was looking for.  The HEAD reflog is
almost good enough for me.

To be clear: I'm not against including branch name information; I just
don't want to _have_ to remember them to find what I'm looking for.

> Defining
> a new GRAVEYARD format would need an additional field for the ref name
> of each entry, but lets us drop the other naming complexities.

Certainly.  Putting it in the description will only lead to more
problems (like bugs in the @{<N>} parser).

> The HEAD reflog is not sufficient for two reasons:
>
>   1. Not all ref updates were part of the HEAD reflog (e.g.,
>      refs/remotes, tags).

Would be nice to solve, but it's not a big itch in my opinion.

>   2. It is not easy to see deduce which ref each entry comes from, which
>      makes "deleted_branch@{yesterday}" difficult. You can sometimes
>      deduce the branch by reading the surrounding entries (e.g., for
>      "checkout" entries), but I do not know offhand whether it can be
>      done reliably in all cases (I suspect not, given that unreachable
>      reflog entries may be pruned sooner than reachable ones, leaving
>      "holes" in the reflog's story).

Yeah, this makes sense.

> I do not necessarily disagree with your criticisms of the tooling around
> reflogs, but they are just not my interest right now, and I do not think
> working on one concept needs to hold up the other.

Oh, I didn't mean to hold up anything.  I brought it up because I
thought it would be of interest to heavy reflog users.
--
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]