Sitaram Chamarty wrote:
> I think I'd have to be playing with *several* branches simultaneously
> before I got to the point of forgetting the branch name!

Yeah, I work on lots of small unrelated things: the patch-series I
send in are usually the result of few hours of work (upto a few days).
 I keep the branch around until I've rewritten it for enough re-rolls
and am sufficiently sure that it'll hit master.

> More to the point, your use case may be relevant for a non-bare repo
> where "work" is being done, but for a bare repo on a server, I think
> the branch name *does* have significance, because it's what people are
> collaborating on.
> (Imagine someone accidentally nukes a branch, and then someone else
> tries to "git pull" and finds it gone.  Any recovery at that point
> must necessarily use the branch name).

Ah, you're mostly talking about central workflows.  I'm on the other
end of the spectrum: I want triangular workflows (and git.git is
slowly getting there).  However, I might have a (vague) thought on
server-side safety in general: I think the harsh dichotomy in ff-only
versus non-ff branches is very inelegant.  Imposing ff-only feels like
a hammer solution, because what happens in practice is different: the
`master` does not need to be rewritten most of the time, but I think
it's useful to allow some "safe" rewrites to undo the mistake of
checking in an private key or something [*1*].  By safety, I mean that
git should give the user easy access to recent dangling objects by
annotating it with enough information: sort of like a general-purpose
"pretty" reflog that is gc-safe (configurable trunc_length?).  It's a
serves more usecases than just the branch-removal problem.

Ofcourse, the standard disclaimer applies: there's a high likelihood
that I'm saying nonsense, because I've never worked in a central


*1* It turns out that this is not uncommon:
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to