Well I actually didn't know about stash -p when I asked for this, but I
still see room for us removing some more friction here:
# start from N-commit worth of change, debug and WIP
git stash save -p debug ;# stash away only the debugging aid
# now we have only N-commit worth of change and WIP
git stash save -p wip ;# stash away WIP
Then after that, you need N round of git add -p git commit.
Now, with what we have already, can we also give final testing
before committing? Each round may now start with:
git add -p ;# prepare the index for the next commit
git stash save -k ;# save away the changes for later commits
Here you have to _at least_ go through all your hunks once to stash the
debug code, once to stash the WIP, and once to add -p and commit.
Going through hunks is expensive... it takes quite a bit of time. Each
time you launch one of those commands you have to go through all hunks
you haven't decided on yet - could be a lot of hunks.
Now, what if we had a command where you would go through all your hunks
one, by one, and will give you an option to stage, stash, or discard
what you want as you please? In the above scenario, lets say N was 1,
then the scenario would be:
# start from 1-commit worth of change, debug and WIP
# stash debugging and WIP code,
# and stage the code you want to commit
git mystery-command
# everything done
git commit
Then we would reduce 3 -p commands to 1 -p command.
Now what should this command be called? You resist making git-add unsafe
and I understand that. How about:
1. Give git add -p options that expose this extra functionality. So:
git add -p ; # can only stage code
git add -p --with-discard ; # does git add -p, plus discards hunks
git add -p --with-discard --with-stage ; # plus discard, plus stage
So in the hunks you can go:
- discard; # and it would discard it
- stage stash; # and it would stash it into stash
The argument I am making is that if a programmer explicitly asks for one
of those features then git will cooperate, and add becomes unsafe. We
are trusting that the programmer knows what they are doing. In all other
cases git add is the same, and will never touch the working tree.
We can also change git checkout -p and git stash -p so that they behave
the same:
git stash -p --with-add; # does everything -p stash, and stages too
git checkout -p --with-add; # does everything -p checkout, and stages
2. We can come up with a whole new git command that does this.
Something like git patch-process
# start from 1-commit worth of change, debug and WIP
git patch-process ; # Stage, stash, and discard hunks as you please
# ready for commit
git commit
How does this sound?
PS: Newbish question: I am looking to help out with git, either with
this feature or others. How do I get around getting assigned a work to
do? Thanks.
Mina
On Wed, 2012-08-15 at 16:58 -0400, Mina Almasry wrote:
On 12-08-15 02:46 PM, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@student.ethz.ch writes:
This has come up before, and actually led to the introduction of
'checkout -p' and 'reset -p':
http://thread.gmane.org/gmane.comp.version-control.git/123854
That is a blast from the past.
Why is saying git checkout . too much work, after add -p that
you excluded the debugging cruft?
Please forget this question. A better way in the form of stash -p
was suggested in the old thread to get rid of debug cruft in the
tree before an add -p session (or during a series of add -p
sessions).
So is this still an issue?
I read most of the thread, and I do think it still is. Here are my 2 cents:
1. The alternative commands aren't nearly as time efficient:
- git checkout . is fast and awesome, but you can't use it if, for
example, you have to maintain a dirty working tree
- git (stash|reset|checkout) -p make you go through (all|most) of
the hunks you have to hunt down those 2 lines that say echo
'This line is runningantoeuhaoeuaoae'
2. All of the safety concerns can be alleviated with the right
interface. I am glad the u option mentioned in the thread did not go
through since I agree it is not ideal. However, if the command is:
(a) something with a '!', then no one will hit it by mistake, and
(b) the prompt makes it clear that work is lost
then I think it would be fine
The advantages of a command like this are pretty huge IMO. I can see
this being a big time saver.
How about adding this to the git add -p prompt:
r! - remove this hunk. The hunk is discarded from the working tree,
and is irrevocably lost.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line
