Re: Translation commits pushed when rolling a tarball

On Mon, 2014-08-04 at 09:38 -0400, Dan Winship wrote:
On 08/03/2014 03:38 PM, David Woodhouse wrote:
  - Make a whole bunch of changes all at once, some of which are
    related to X, some to Y, some to Z, and some to more than one of
    them, and without any indication of which changes relate to which
    commit so no one in the future will ever be able to figure it out
    ha ha ha.

Which sucks. So I'll stick with rebasing, thanks.

That is so far from the normal experience of using git as intended, that I
don't quite recognise it.

How else is a merge commit going to look? If you have more than one
commit on your branch, and more than one conflict with master, and you
only get one commit to fix it all up, then how can you avoid having that
one commit include fixes that are unrelated to one another?

(Sure, if you don't have any conflicts, then the merge commit will be
empty and confusion-free, but in that case you could have rebased
without conflicts too, so the argument about accidentally creating bugs
while rebasing doesn't apply.)

There are multiple options here.

First of all, you *can* rebase if you want to. I don't think anybody
objects to that; only to the *forced* rebasing.

But let's say you don't want to rebase, because you really do want to
preserve the original context and the validity of the original testing —
perhaps other people had tested it for you in esoteric environments. If
upstream has done X, Y and Z since you started your work and *all* of
them interact non-trivially with what you've done, then rather than
pulling today's upstream in one go, you could first pull it as of commit
X, resolve conflicts and retest, then pull Y, repeat, and finally do the
same for Z.

Of course, if X, Y and Z are all inter-related then that might actually
be a bit more work than doing it in one go — so you might *not* want to
do that. But it's *one* of the options.

I'm not trying to take away your options, of which rebasing is sometimes
a perfectly valid one. I'm pointing out that this thread only exists
because one of the useful options (i.e. *not* rebasing) *has* been taken


Attachment: smime.p7s
Description: S/MIME cryptographic signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]