> I would actually call that behaviour a bug.
Well, yes, that was my inclination, too. But writing documentation was
easier than writing a code patch. :-)
Even when it is fixed, a comment about when it was fixed and what the
buggy version did should live in the BUGS section for a while, to warn
people writing portable scripts.
> Perhaps it should grab
> all the command line arguments first, group them per the ref the
> reflog entries are based on, and expire _all_ reflog entries from
> the same reflog in one go?
Two other options are to sort them in decreasing entry order (which you
could do either per-reflog, or simply globally), or to remember previous
deletions so you can adjust the numbers of later ones.
One tricky point is whether it's possible for a reflog to have two names,
via a symlink or something. That definitely complicates collision
> Until that happens, it may make sense to error it out when more than
> one entries are given from the command line, at least for the same
Detecting this seems like half the implementation work of fixing it,
so I'm not sure it's worth bothering.
Looking at the code (builtin/reflog.c), I notice that expire_reflog()
takes a lock on the ref, but the previous count_reflog_ent code doesn't,
so things aren't necessarily race-proof. I haven't figured out if the
race is a problem (i.e. does expire_reflog do something nasty if the
struct cmd_reflog_expire_cb holds stale data?), but I noticed...
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html