On 2006-11-20 19:09, Horst H. von Brand wrote:
>>
>> A------------F master
>> \ /
>> B--C--D--E
>>
>> Yes, E and F have identical trees. But it's actually *very useful*, if
>> the commit message at F says "merged branch foo containing experimental
>> bar from quux". And it shows up nicely when looking at gitk.
>
> I don't see the usefulness of this.
Just look up this thread for the most recent example: recording the text
of "pull foo to get" and "[00/05] Fix quux" message.
> And if quux merges back, she gets the same plus a new merge node, and...
> Linus told everybody (quite forcefully, I might add) that this is not
> acceptable for distributed development.
I've address this. Sure, it breaks down completely if done by default
when nothing new happens; but not when done judiciously. For real
problems to show up you'd need two people who both insist on always
using --force-commit when pulling each other. Inevitably, before long
they will realize the folly of their ways and stop doing that; problem
solved.
I expect common usage to be that --force-commit is only used by
maintainers, when pulling/applying non-trivial branches from downstream.
But this is a social convention that can be decided per project, and can
be ignored by anyone who decides to fork off. And if Linus doesn't like
it he can just avoid using it in his projects.
>> There are the obvious bad consequences if you make this the default,
>> but how about adding a --force-commit option to merge and pull?
>
> Fast forward is fast forward. Merge is when /independent/ changes are
> integrated into one.
I was under the impression that git-merge is what (indirectly)
determines if joining multiple commits is a fast-forward or a real
merge. If it's in some other piece of git, please substitute that.
>> You'd need to educate users on how to use this responsibly
>
> Looks like you've never met real users ;-)
No, it's really easy in this case: if someone asks you to pull a rotten
branch with too many forced merges, just refuse until he stops abusing
that option. It's not the default, right? There are plenty of much worse
non-default ways to damage history.
>> And to answer Linus: yes, it's expected that only non-leaf developers
>> will use --force-commit on regular basis, but that's not because
>> maintainers are technically special in any way. It's just because
>> maintainers have something useful to say ("someone's private topic
>> branch, starting at A and ending at E, has just been accepted into my
>> all-important public repo and here's why"). Anyone else can do the same
>> if he feels likewise.
>
> But the individual changes will presumably reflect said someone's
> authorship. If they are interleaved with stuff by others or not doesn't
> make much (development) sense. Yes, it might be interesting for a software
> historian, but that's not git's main audience in the first place.
If the only thing you care about is the tree of the top commit, then
sure, those redundant commits are worthless. But then, why do you bother
with (for example) commit messages, or tag objects? Oh, you want to know
more about what happened and why? Then great, those "pull foo to get"
and "[00/05]" messages are probably the best place to start, if we only
had where to save them.
We are all "software historians" when we look at some project's public
branches and try to grok what's going on recently, who's doing what and
along what workflow, and why it got there. This is useful information,
that is not easily tracked by any other means; there's a reason this
comes up repeatedly in various guises, you know. I can't see why some
people are so eager to discard this information and tell others to use a
munged-up shortlogs, instead of looking for ways to record as much
possible with the least negative impact.
Now, --force-commit with appropriate usage conventions seems like a
reasonable tradeoff.
BTW, in principle another (better?) way to do it is by leaving the
commit DAG alone, and annotating it with tag objects where extra
information such as "[00/05]" is available. The problem is that git
doesn't have any scalable mechanism for adding such annotations. It's a
hard problem; nothing in the commit DAG points to to tag objects, so you
have to scan some external store and that gets more expensive as the
repo grows. It also gets nasty in fetches.
Eran
-
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