Re: git merge and merge message
- From
Martin Langhoff <martin.langhoff@gmail.com>
- Date
- Mar 12, 2007, 03:07 UTC
- Message-ID
- <46a038f90703112007y2baf7205v56a1ad4b784e93f0@mail.gmail.com>
- In-Reply-To
- <Pine.LNX.4.64.0703111309410.9690@woody.linux-foundation.org>
On 3/12/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 5 quoted lines
> The "don't merge, just fast-forward" is the right thing to do for working > together. However, I can well imagine that if you actually work with > branches not as "distributed development", but *just* as "topic branches", > then having the "useless" merge (with the parents actually being parents > of each other) migth actually be nice from a documentation standpoint.
Well, actually I do quite a bit of work in private repos, and it is more useful to know *trivially* that the branches are in the same place, and get me and my team into the "it's about the content, stupid" mindset.
So after all the flamefesting, I drank the content-is-king koolaid and if a pull leads to a fast-forward, I'm happy. If it's a pointless merge I often rebase to linearise.
> I'm torn on this.
Man, you're getting soft in the middle ;-) First, git gets a newline conversion option to please windows users that don't use the many GOOD programming editors that know a unix newline from a UFO (and those are the majority these days, or so I hear). And now _this_! Tsk, tsk!
> I really dislike anything but fast-forward, because I > have a strong suspicion that it will cause "alpha male" behaviour (where > maintainers use the "useless merge" as a way to mark their territory), > which I think is actually really bad form.
I share your concern. And for Xavier's case ref logs should do the trick anyway.
cheers,
m