On Wed, Sep 14, 2011 at 3:45 AM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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
--
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