Re: [gentoo-dev] Git workflow

[C Bergström]

On Sun, Jul 5, 2015 at 6:54 AM, Peter Stuge <peter@×××××.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)