C Bergström wrote: > >> 3) Ever tried to make a patch of the *actual* merge commit? Can one of > >> the advocates of merge show me the git command to do that? (Sure you > >> can diff between 2 commits, but the "merge" commit likes to avoid > >> being seen) > > > > If there are no conflicts when merging then the merge commit does not > > contain any changes, so how could there be a patch? Do you actually > > know the Git data model? I wrote it down the other day. > > > > http://peter.stuge.se/git-data-model > > You deflect the question so nicely. If there is no merge conflict then > a rebase would be just fine? > > You clearly know git very well - much better than I, why not just > answer the question?
I tried to. My point was that when merge commits don't lead to conflicts on file level (branches touch different files) then the merge commit does not modify anything, so the "patch" is empty. This is where knowing the data model becomes important to not get angry with Git. When you know what is going on internally it's very easy to deal with all the different cases. If on the other hand you make assumptions about what Git does internally based on previous experience or natural language then it's easy to get frustrated. Now, if there are changes in a file in both branches then this needs to be resolved somehow, manually or automatically. There are two or more sources of changes. A patch expresses the difference between two objects; the before and the after so to say, but it can't really be used to express such a merge resolution, becaue there are two before and one after. You would need multiple patches to do so, one for each merged branch. These you could create by diffing each parent with the merge commit. But why do you need to? > >> and a "git pull --rebase" before push will be clean and fast (no > >> problems). > > > > Q: How do you deal with the two commits from other developers that > > were pushed while you were rebasing? > > > > A: You end up having to spin on the remote repo. That's really clumsy. > > Pragmatically - the answer to you question is the same as it exists > today. You're scared of something which gentoo devs have been dealing > with and resolving for years. It's not like CVS/SVN handles this > magically better. I'm not scared of spinning, but do you agree that it's really clumsy? A merge commit *is* a much better way to handle this. It's accurate and it makes sense. > > Arguing without checking makes you look bad. > > How? I didn't claim to know and clearly not knowing didn't seem > important (to me). Not knowing what you're arguing makes you look bad because you can only contribute to the discussion if by chance you are correct, which isn't so likely. It's more likely that your argument wastes time and contributes nothing, if you don't know what you argue. This makes you look bad. > I'm just trying to passionately bring this up. I think that's fine, and I welcome every discussion about workflow, but it's only useful when everyone makes the effort to be constructive and well-informed. > >> I can't say I've ever cared to know the date of a commit, but I can > >> say I have cared a lot about knowing which commit came 1st. Rebase, > >> for better or worse, forces something to be 1st and it's clear and > >> easy to see. > > > > A rebase, like a cherry-pick, loses the very information you claim to > > care about; the original parent of the commit. > > To clarify - I don't (clearly) give a pooh what the original parent > was. I care much more about a linear history. The linear history doesn't say what came first however, so you're going against yourself. > I rarely can see any value of the at-to-time of original commit > compared to the final at-push-time commit (what's rebased). Maybe that's the problem. There is great value in this, because it shows how the commit in question was intended to change the base it starts out with. Rebasing might require modifying the commit so that it applies to the new base, so after a rebase it is impossible to know if a given part of the commit was created before the rebase or as part of the rebase. This has two drawbacks; it makes review more difficult and risks introducing bugs because of incomplete or incorrect rebasing. A rebase, like a cherry-pick, combines these two changes into one, and shouldn't be done too lightly. > The value of linear history outweighs the arbitrary point you started from. Linear history looks neat, and as I wrote earlier I really like it too, but I also think that losing the extra information within merge commits is not something to be take too lightly. > imho a commit and development is not done until it's ready to be pushed. I agree with that, but I think that's separate from the merge vs. rebase discussion. > >> If I controlled the gentoo git server, I'd > > > > I think it's a good thing that you don't, since you seem to still > > need to study Git in more detail. > > Peter - I'm ashamed of you - don't be a dick. We can keep this civil > without subtle insults. Sorry about that - I did not mean to insult - I was just being honest, it did seem to me that you didn't know the data model so well and I think that's important when controlling a repo. > I understand you are one of the people who feels strongly about > this in the opposing way. It's not that simple I'm afraid. :) I do like a linear history and I rebase a lot myself, but I am also very well aware of the loss of information that comes with it, and retaining that information is a quite significant benefit of using merge commits. > git brings out a lot of strong religious-like views. (immutable) What is immutable is that I see great benefits with both methods, *and* drawbacks with both methods. Sorry to disappoint. //Peter
