From: Linus Torvalds Date: Wed, 14 Sep 2011 15:25:15 GMT Subject: Re: Fwd: [Survey] Signed push Message-ID: In-Reply-To: <4E7085E6.3060509@alum.mit.edu> On Wed, Sep 14, 2011 at 3:45 AM, Michael Haggerty wrote: > > Instead of "like a branch description", why not implement branch > descriptions directly? Mostly because of just human interface issues. We already have a "repository description", and it's quite commonly never even filled in. For branches, that would be doubly true, because a lot of branches are throw-away. So I think it would work if we made it part of of something like "git push -s" - because that's when it starts mattering to others. > I wish that one could annotate a branch (e.g., at creation) and have the > annotation follow the branch around.  This would be a useful place to > record *why* you created the branch, your plans for it, etc.  The > annotation should be modifiable, because often a branch evolves in > unforeseen ways during its lifetime.  Anybody could read the annotation > to get a quick idea of what kind of work is in progress. I wouldn't be against that as a concept, I just think you'd be a small small minority, and most branches would never get annotated. But I don't really care deeply how it actually works - my main issue is that git makes it way too easy to have bad merge messages. I think part of that is an even simpler idiocy: we never even fire up the editor by default for a "git merge", but we do for a "git commit". That was a design mistake, and it means that if you want to actually add a note to a merge, you have to do extra work. So people don't. Now people do "git merge" in scripts etc, so we can't fix it ;-( Linus