Re: Feature request: git-pull -e/--edit

On 2006-11-20 05:21, Junio C Hamano wrote:

[snip]

[snip]

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.

Of course, you could just fast-forward instead:

  A--B--C--D--E master

but then you lose a meaningful and useful part of the historical record.

There are the obvious bad consequences if you make this the default, but how about adding a --force-commit option to merge and pull?

You'd need to educate users on how to use this responsibly 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.

Eran Tromer <git2eran@tromer.org> wrote:

[...]

I don't see the usefulness of this. 

Yep.

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.

Fast forward is fast forward. Merge is when /independent/ changes are integrated into one.

Looks like you've never met real users ;-)

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.

On Mon, Nov 20, 2006 at 06:09:50PM CET, Horst H. von Brand wrote:

..snip..

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.

Yes, that is a real problem. ;-) But not adding features because users could use them irresponsibly doesn't get you too far.

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.

Tell that to Junio, our pickaxe guy. :^)

On 2006-11-20 19:09, Horst H. von Brand wrote:

Just look up this thread for the most recent example: recording the text of "pull foo to get" and "[00/05] Fix quux" message.

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.

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.

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.

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:

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,