Re: [gentoo-dev] Git workflow

[Peter Stuge]

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