Re: [FAQ?] Rationale for git's way to manage the index

Linus Torvalds [off-list ref] writes:

And unlike the "simpler" model of committing individual hunks
with "git add -i" or something like that, my model is actually
much superior!

I obviously agree with this.  As I said a few times I regret
introducing "add -i" --- it encourages a wrong workflow, in that
what you commit in steps never match what you had in the working
tree and could have tested until the very end.

Junio C Hamano wrote:

I obviously agree with this.  As I said a few times I regret
introducing "add -i" --- it encourages a wrong workflow, in that
what you commit in steps never match what you had in the working
tree and could have tested until the very end.
  

On the other hand, not all changes require any testing at all. For 
example, if you're using git to manage documentation, it is totally 
reasonable to commit a fix for a simple spelling error in one part of a 
file while not committing an in-progress rewrite of another part.

-Steve

On Wed, 9 May 2007, Steven Grimm wrote:

Junio C Hamano wrote:

quoted

I obviously agree with this.  As I said a few times I regret
introducing "add -i" --- it encourages a wrong workflow, in that
what you commit in steps never match what you had in the working
tree and could have tested until the very end.
  

On the other hand, not all changes require any testing at all. For example, if
you're using git to manage documentation, it is totally reasonable to commit a
fix for a simple spelling error in one part of a file while not committing an
in-progress rewrite of another part.

Yeah, I don't think "git add -i" is a horrible flow - it just shouldn't be 
the only or the primary one (ie apparently it *is* the primary one for 
darcs, and that's a mistake!)

Of course, whether "git add -i" is a nice interface or not, I dunno. 
Personally, if I wanted to do hunk selection, I think I'd stick to 
something graphical where I can just click on the hunks. But that's just 
me.

		Linus

Junio C Hamano [off-list ref] wrote:

Linus Torvalds [off-list ref] writes:

quoted

And unlike the "simpler" model of committing individual hunks
with "git add -i" or something like that, my model is actually
much superior!

I obviously agree with this.  As I said a few times I regret
introducing "add -i" --- it encourages a wrong workflow, in that
what you commit in steps never match what you had in the working
tree and could have tested until the very end.

Which is why I'm considering shelving support (of some kind) in
git-gui...  but I'm probably not going to take away the current
index view, nor am I going to take away the current hunk selection.

But I would like to make it easier for non-patching-editing gods
(Linus) to pull hunks in from a shelf, test them, and commit them.

Said shelf probably would be another branch, much as Linus' nicely
documented workflow does...

-- 
Shawn.

On Fri, May 11, 2007 at 12:06:49AM CEST, Shawn O. Pearce wrote:

Which is why I'm considering shelving support (of some kind) in
git-gui...  but I'm probably not going to take away the current
index view, nor am I going to take away the current hunk selection.

But I would like to make it easier for non-patching-editing gods
(Linus) to pull hunks in from a shelf, test them, and commit them.

Said shelf probably would be another branch, much as Linus' nicely
documented workflow does...

FWIW, Cogito supports shelving of uncommitted changes when switching a
branch (so that they are not retained through the switch but restored
when you switch back to the original branch) by committing the local
changes to refs/shelves/HEADNAME.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett