Mina Almasry <almasry.m...@hotmail.com> writes:
> On 12-08-15 02:46 PM, Junio C Hamano wrote:
> ...
>> 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'"
You have to do that _at least once_ anyway, as there is no other way
for Git to tell which one is debugging cruft and which one is the
real change you value without you telling it. Will return to the
topic later.
> 2. All of the safety concerns can be alleviated with the right
> interface.
There are three safety concerns I raised in the original thread.
Among them, I do not think
(1) new user may mistake "undo" to be something safe; and
(2) experts will continue making typo between "y" and "u"
are the primary risks of the original patch Thomas pointed out.
A much bigger problem with the approach is (3) letting "add" touch
the working tree breaks the world model. Both experts and newbies
alike, people have learned that "git add" will never clobber what
they have in the working tree and rely on that promise.
And your key assignment, command renaming or extra prompting do not
change this fundamental issue at all.
Let's step back a bit, and define the problem we are solving.
Suppose you have changes in your working tree that are worth
multiple commits, debugging aid, and uncommittable WIP. You want to
create multiple commits, possibly giving each of them the final
testing before committing, and want to end up with the WIP (plus
possibly the debugging aid, as that may still help your WIP) in your
working tree.
Do we agree that the goal of the discussion of this thread is to
make that process simple, safe, efficient and easy?
Now, back when the original patch by Pierre was proposed, it indeed
was cumbersome. You could sift things through by "add -p" to build
the first commit in the index, commit, and iterate. In each round,
"add -p" step had to skip the same debugging aid and WIP over and
over again. If you wanted to give the result of "git add -p" a
final test before committing, "stash save -k" would give you the
state you would be committing, but it isn't easy to reintroduce only
the debugging aid to the working tree.
Since then "stash -p" was added to our toolchest. So theoretically,
we should be able to do something like this:
# 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
and at this point, your working tree and the index has what you are
about to commit. If we can apply the "debugging aid" stash we
created earlier to the working tree, that would allow you to test
the state you are about to commit with your debugging aid. The
command to do so may be
git stash apply stash@{2}
Once you are satisfied, you can reset this change out of your
working tree with "checkout .", and then "git commit" to record what
is in the index.
And then you can "git stash pop" to bring back the remainder of
N-commit series worth of changes. You are ready to continue to the
next round.
Once you created N-commit series, you will still have two stash
entries, one "debug" and one "wip". You should be able to resurrect
"wip" with
git stash pop
just fine, but there is a little problem after this step. Because
"git stash [apply|pop]" does not want to work on a dirty working
tree, starting from this state just after popping "wip" stash, you
cannot "git stash pop" to have both WIP changes and debugging aid to
the working tree.
A topic to improve "stash [apply/pop]" to allow it may be a valid
and useful thing to do.
As an approximation, without changing any of the current tools,
however, you should be able to do this after creating N-commit
series following the above procedure.
git stash pop ;# resurrect "wip" to the working tree.
git add -u ;# and add that to the index temporarily
git stash pop ;# resurrect "debug" to the working tree as well.
git reset ;# then match the index to HEAD
That will mix the WIP and debug again in your working tree.
Why you would want to mix them together, after sifting debug and wip
using "add -p" already, is a different issue, though (there are
valid scenarios why you would want to do so, and there are valid
cases why you do not have to bother).
So is this still an issue?
--
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
