Re: How to commit incomplete changes?

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

 



On Thu, 15 Dec 2011 10:44:44 +0400, Alexey Shumkin <Alex.Crezoff@xxxxxxxxx> wrote:
Do people have any feelings or conventions for how and when to
publish a series of commits where the first one(s) break something
and the next ones clear it up?

I'm curiuos, why to you want to commit changes that break something
separately from fixup?

I answered that, but maybe too briefly:

 I'm about to commit some small edits which go together with bigger
generated changes. It seems both more readable and more cherry-pick-
 friendly to me to keep these in separate commits.

To expand on that: To review the change, review the hand-edited commits,
which is easier when these do not drown in generated changes.  Review
the *commands* which generated the rest - I'd put those in the commit
message - and glance at the actual changes.  Cherry-pick: Possbly you
need to run the commands instead of cherry-picking the generated
changes.  That's easier with a commit with only generated changes.

I know it also can cause problems.  Would you make a single big commit
anyway, and describe carefully in the commit message which parts are
hand-edits?  (We don't auto-test commits yet, but I'll sure this issue
will crop up again later when we do.)

--
Hallvard
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]