From: Steven Grimm <koreth@midwinter.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Steffen Prohaska <prohaska@zib.de>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH v2] user-manual: mention git gui citool (commit, amend)
Date: Mon, 06 Aug 2007 17:36:43 +0800 [thread overview]
Message-ID: <46B6EBAB.4050805@midwinter.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0708060119320.14781@racer.site>
Johannes Schindelin wrote:
> But how do you make sure that it works as expected? I.e. when you commit
> a hunk using, say, variable "rule_the_world", and by mistake (happen to me
> all the time, maybe to you, too?) forgot to select the hunk which declares
> that variable, maybe because it is hidden in a forest of other variables?
>
For cases like that, sure, partial commits are dangerous. On the other
hand, I've sometimes done partial commits for things like correcting
erroneous comments in code I'm working on, where there is no functional
change whatsoever in the hunk I'm committing and where I want to isolate
the corrections from the functional changes I *am* working on.
Also, when I'm working on a topic branch in my local sandbox I like to
do lots of work-in-progress commits. I usually do those based on the
granularity of my mental model of what I'm working on, and I have no
expectation whatsoever that any particular percentage of them represent
working code or even code that compiles. Sometimes I do partial commits
in that situation too: I make a change to some function in a file that
I'm editing elsewhere, and commit just that hunk with a commit log
message reminding me of why I made the change. Those commits are not
intended for public consumption; they're just to help me keep track of
my own work. Once everything is in a working state, I do a squash merge
or a bunch of cherry-pick -n invocations to build some revisions to
publish to the outside world, and *then* I am in "each commit must
represent a non-broken state" mode.
The great thing about git (well, *one* of the great things) is that it
unifies those two workflows in one system. With, say, svn, the "lots of
little checkpoints of my work in progress" part of that is awkward at
best, because it's very much oriented around an "if the version control
system knows about a change, it is by definition published to the
outside world" model.
So I guess my point, after all that, is just that assumptions that are
valid in the context of one workflow are not necessarily as valid in
others, and that even in a particular context, not all changes are
created equal.
-Steve
next prev parent reply other threads:[~2007-08-06 9:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-30 16:11 [PATCH] user-manual: mention git gui citool (commit, amend) Steffen Prohaska
2007-07-31 0:24 ` Shawn O. Pearce
2007-08-02 18:18 ` J. Bruce Fields
2007-08-02 22:24 ` Steffen Prohaska
2007-08-02 22:31 ` J. Bruce Fields
2007-08-03 5:08 ` Steffen Prohaska
2007-08-03 12:56 ` J. Bruce Fields
2007-08-05 12:59 ` [PATCH v2] " Steffen Prohaska
2007-08-05 13:58 ` Johannes Schindelin
2007-08-05 14:17 ` Steffen Prohaska
2007-08-05 14:48 ` Johannes Schindelin
2007-08-05 15:03 ` David Kastrup
2007-08-05 19:47 ` Steffen Prohaska
2007-08-06 0:22 ` Johannes Schindelin
2007-08-06 5:20 ` Steffen Prohaska
2007-08-06 9:36 ` Steven Grimm [this message]
2007-08-06 11:51 ` Johannes Schindelin
2007-08-05 22:22 ` J. Bruce Fields
2007-08-05 22:25 ` J. Bruce Fields
2007-08-06 0:26 ` Johannes Schindelin
2007-08-06 3:51 ` J. Bruce Fields
2007-08-06 19:36 ` Robin Rosenberg
2007-08-06 19:43 ` J. Bruce Fields
2007-08-03 3:01 ` [PATCH] " Shawn O. Pearce
2007-08-03 12:56 ` J. Bruce Fields
2007-08-04 6:33 ` Shawn O. Pearce
2007-08-05 12:09 ` Steffen Prohaska
2007-08-03 0:05 ` Junio C Hamano
2007-08-03 3:04 ` Shawn O. Pearce
2007-08-03 12:58 ` J. Bruce Fields
2007-08-04 6:20 ` Shawn O. Pearce
2007-08-04 7:44 ` David Kastrup
2007-08-04 14:35 ` J. Bruce Fields
2007-08-05 12:26 ` Steffen Prohaska
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=46B6EBAB.4050805@midwinter.com \
--to=koreth@midwinter.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=prohaska@zib.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).