Re: Translation commits pushed when rolling a tarball
- From: Dan Winship <danw gnome org>
- To: David Woodhouse <dwmw2 infradead org>
- Cc: desktop-devel-list <desktop-devel-list gnome org>
- Subject: Re: Translation commits pushed when rolling a tarball
- Date: Mon, 04 Aug 2014 09:38:37 -0400
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.)
-- Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]