On Sun, Jul 5, 2015 at 6:54 AM, Peter Stuge <pe...@stuge.se> wrote: > 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? > > >> 4) I disagree that even a very active repo will have a problem with >> rebase - Why? >> a. If devs aren't working in the same area there will be no conflicts >> b. If > > It's not about conflicts. > > >> 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. > > >> 5) More about linear commits and "history" - I need to double check, >> but I don't think rebase changes the actual commit date (I could be >> mistaken). > > You are mistaken, and should have double checked before you argued. > > Arguing without checking makes you look bad. How? I didn't claim to know and clearly not knowing didn't seem important (to me). I'm not trying to overstate anything. I'm just trying to passionately bring this up. I ***wish*** someone with some guts would actually take charge of this on the gentoo side, have a vote or make some executive decision which is stronger than this wimpy policy we have now. > > >> The only advantage to merge is you could see that the commit >> happened on the "1st" ${DATE-TIME} of the month > > That's not correct. > >> 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. 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). The value of linear history outweighs the arbitrary point you started from. imho a commit and development is not done until it's ready to be pushed. > > >> 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. I understand you are one of the people who feels strongly about this in the opposing way. I wish I could flip your way of thinking, but git brings out a lot of strong religious-like views. (immutable)
