git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).