Re: [PATCH v6 00/10] The final building block for a faster rebase -i

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 22, 2017, 11:44 UTC
Message-ID: <alpine.DEB.2.21.1.1707221335150.4271@virtualbox>
In-Reply-To: <xmqqfudqkcux.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Thu, 20 Jul 2017, Junio C Hamano wrote:

Show 14 quoted lines

> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
> > Changes since v5:
> >
> > - replaced a get_sha1() call by a get_oid() call already.
> >
> > - adjusted to hashmap API changes
> 
> Applying this to the tip of 'master' yields exactly the same result
> as merging the previous round js/rebase-i-final to the tip of
> 'master' and then applying merge-fix/js/rebase-i-final to adjust to
> the codebase, so the net effect of this reroll is none.  Which is a
> good sign, as it means there wasn't any rebase mistake and the evil
> merge we've been carrying was a good one.

Good.

Show 9 quoted lines

> But at the same time, I prefer to avoid rebasing to newer 'master'
> until the codebase starts drifting too far apart, or until a new
> feature release is made out of newer 'master'.  This is primarily
> because I want dates on commits to mean something---namely, "this
> change hasn't seen a need to be updated for 'oops, that was wrong'
> since this date".  This use of commit dates as 'priority date'
> matters much less for a topic not in 'next', but as a general
> principle, my workflow tries to preserve commit dates for all
> topics.

By that token, commit message updates would also be inappropriate, in particular when they came from somebody else than the patch author ;-P

As to avoiding a rebase: we can add that to the growing list of things on which we disagree.

If the author dates really meant anything, we would also have to avoid v2, v3, v4, ... v226 of patch series. So that flies in the face of trying to keep the meaning of author dates.

In addition, the development flow I prefer is one that is in harmony with the modern Continuous Integration style, where topic branches are merged into a single, always-ready-to-release integration branch.

That means that I always work off of `master`, unless there is a good reason to base off of `next` or even `pu`. That's to avoid merge conflicts, to see what really gets applied.

I am *especially* adamant about rebasing to a newer upstream commit when there are merge conflicts.

Such as is the case here.

> For the above reason, I may hold onto this patch series in my inbox
> without actually updating js/rebase-i-final topic until the current
> cycle is over; please do not mistake it as this new reroll being
> ignored.

You do as you want, of course. But please note that I will not rebase my topic branches to an ancient revision, especially if that would cause merge conflicts with the current `master`.

And if there should be another iteration of this wallflower patch series, I will rebase it to the then-current `master` again [*1*].

Ciao, Dscho

Footnote *1*: in general, I try to abide by the wishes of maintainers when contributing code, unless those wishes are contrary to what I consider correct software development. Like, when in Rome, I will do as the Romans do. Except when I see them looting a parking meter.