On 2009.02.12 13:04:48 -0800, Junio C Hamano wrote:
> It can be argued that it adds one huge convenience. It is quicker to say
> 'git stash save --keep' than 'git commit -a -m "WIP as of $(date)"', and
> in addition, you first have to do a "checkout -b wip" once, if you use the
> approach with regular commits on a exprimental branch forked from the
> target branch, instead of the approach with regular commits directly on
> the target branch.
Another thing that came to my mind is that stash --keep would not affect
"git diff". I often look at the current diff to reassure myself of what
I'm actually doing, and when you do intermediate commits, you can no
longer use a plain "git diff", but need to use, for example, "git diff
master", assuming that your current branch is exclusively for this thing
you're working on. But the whole idea of taking snapshots feels more
like it is for a use case that assumes that you end up with a single
commit, that might in the end be a part of some bigger commit series. So
for the "git diff <whatever>" to be convenient, you might need a
(temporary) branch for just this one commit to be, or you need to tag
your starting point.
And (in part) you also lose the ability to dynamically mark parts of
your changes as "good" by staging and unstaging them. I use that quite
often to "trim" the diff output to the currently interesting part. When
I refactor some function, that might need a lot of callers to be
trivially changed, and I don't want to be bothered with those trivial
changes when I look at the diff to review my changes. So I temporarily
stage that trivial stuff, do a review of the "interesting" part, change
something here and there and might eventually unstage all the stuff
again. Often that's more comfortable than passing a list of interesting
files to each "git diff" command, and sometime that's the only way to
get things filtered down enough to make me happy, because the trivial
and the interesting changes are in the same file.
I think it could make sense to have that "snapshot" thing committing to
another branch (or some ref in /refs/snapshots/, or whatever). Say you
have topicA checked out, and work on some change "foo" that's likely
going to be a single commit, but you want to test several versions of
that thing, while always keeping your changes uncommitted as far as HEAD
is concerned. Then "git snapshot foo", could do something like:
export GIT_INDEX_FILE=.git/snap_index
parent_ref=$(git rev-parse --symbolic-full-name HEAD)
parent_ref=${parent_ref#refs/heads/}
snap_ref="refs/snapshots/$parent_ref/$1"
git read-tree HEAD
git add -u # Or maybe git add -A?
parent=$(git rev-parse --verify --quiet "$snap_ref" || echo HEAD)
commit=$(echo "Snapshot" | git commit-tree $(git write-tree) -p "$parent")
git update-ref "$snap_ref" "$commit"
rm "$GIT_INDEX_FILE"
So you get the benefits of having your snapshots stored much like
intermediate commits, but don't lose the "benefits" of having
uncommitted changes, like the plain "git diff" invocation instead of
"git diff <what's_my_base_today>".
Björn
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
