Eran Tromer [off-list ref] wrote:
[...]
What about fast forwards? Do you get to record the explanation for the
series only if the guy you pulled from didn't bother to do a rebase?
That's broken.
Let's face it, the merge commits generated when pulling have two
completely independent uses:
1. They're technically necessary for joining DAG nodes that don't all
lie on one path.
2. They're useful as a record of workflow and a place to put comments.
The two uses are nearly independent.
Consider the following silly DAG.
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.
Of course, you could just fast-forward instead:
A--B--C--D--E master
Yep.
but then you lose a meaningful and useful part of the historical record.
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.
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.
You'd need to educate users on how to use this responsibly
Looks like you've never met real users ;-)
to avoid
noise, but that's not any different from existing stuff like rebase and
revert. Most users won't even know it exists.
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.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria +56 32 2654239
On 2006-11-20 19:09, Horst H. von Brand wrote:
quoted
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.
quoted
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.
quoted
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.
quoted
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
Hi,
On Mon, 20 Nov 2006, Eran Tromer wrote:
On 2006-11-20 19:09, Horst H. von Brand wrote:
quoted
quoted
A------------F master
\ /
B--C--D--E
Yes, E and F have identical trees.
There has been only _one_ line of history, so why introduce what was not
there?
It sounds more like you do not trust "E" to be something especially
useful, but in that case you should not merge it to begin with.
Ciao,
On Mon, Nov 20, 2006 at 06:09:50PM CET, Horst H. von Brand wrote:
Eran Tromer [off-list ref] wrote:
quoted
A------------F master
\ /
B--C--D--E
..snip..
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.
Wrong, if quux merges back and does not do the same "force commit"
fast-forward (why would it, anyway - OP clearly said it's only if you
_want_ to make it explicit), quux won't get another merge but end up
with F as well. It all converges back nicely.
I can see how it could be useful.
quoted
You'd need to educate users on how to use this responsibly
Looks like you've never met real users ;-)
Yes, that is a real problem. ;-) But not adding features because users
could use them irresponsibly doesn't get you too far.
quoted
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.
You are personifying too much. Git setups where multiple people have
commit access are very common, and there's no reason to play them down
just because Git makes other setups easy.
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.
Tell that to Junio, our pickaxe guy. :^)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
The meaning of Stonehenge in Traflamadorian, when viewed from above, is:
"Replacement part being rushed with all possible speed."