Johannes Schindelin wrote:
You cannot be serious about not wanting to lose the changes when you keep
them in _one_ _single_ repository anyway.
And you cannot be serious about not wanting to lose the changes when you
forget about them, for months, even.
So you are making my point for me.
Maybe I should describe my way of using Git?:
- I'm (amongst other things) using Git for keeping my own codebase for
server maintenance scripts etc, which I then casually replicate between
my servers through Git's networking and merging mechanisms. When I need
a new feature, I'm coding it on the particular server where I need it
and commit it there (I'm even using separate email adresses on every
server so that I can track back on which server I wrote a particular
feature).
- every now and then, I'm being interrupted when I'm coding something
(and will not be able to continue on it for days, weeks or months); when
I return to the repo for something completely different, there's an
uncommitted file or two or more (all of which might not even work), and
before there was git-stash I would sometimes just let those stay around
uncommitted in the working tree; this was a bit of a hassle since I
could for example not use "git commit -a", would IIRC have problems
merging changes coming from another repo into those files, and once more
than one case of unfinished work accumulated, I could no longer tell
what belonged together; I didn't want it to commit to branches because
that didn't seem like a good fit to me (more on that below). Then when
git-stash came around, I first thought, "what's *that*, Git has branches
already?", but then I realized that it would be a perfect fit for
handling those unfinished uncommitted things.
So note that my use case is putting away work which was not finished
(and usually by accident, i.e. I didn't have the time to choose a
sensible interruption point and think of a commit message--I'll actually
usually run "git stash save" not upon interruption, but later when I
want to do other operations in the same repo), to hopefully be picked up
again some (maybe long) time later. (I guess the use case it was
designed for was putting temporarily away intermediate stages of
conflicting merges and such stuff, i.e. for working as maintainer and
not coder?)
- I do backups of the servers. So I don't expect loosing my work even if
it's only being stored on one server.
- But I was not aware of the expiry policy (missing clarity in the man
page). So I think I may actually *have* lost some such work already.
Probably not a big deal, but a bit of a nuisance nonetheless (I wouldn't
continue using git-stash(*)).
You said in a previous mail "If you need something from the stash a day
after stashing it, you have a
serious problem with understanding what branches are for." I've now
spent a bit of thinking about how to use branches easily for that;
should git stash keep the expiry behaviour, I'll need an easy way of
dealing with those uncommitted things; basically git stash onto a
branch. Since I want it to use a default commit message, and when
applying it I want the WIP commit undone, I basically want all of the
same functionality but using a branch as storage instead. Now, what
would be the name of the branch? (Is this calling for discussion of
hierarchical branch namespaces?). It would need to be such that it
wouldn't accidentally interfere with WIP branches on other servers--it's
two different works in progress, so using the same branch name would be
wrong, unless the source prefix ("origin/" etc.) separates names well
enough to not lead to accidents (I don't have enough experience in this
area; when I'm on branch foo, would "git pull" merge another server's
foo branch into the current wip branch? etc.).
((*)BTW regarding the comment from Jeff King about the comparison with
vim's yank buffer and "bounding by time rather than by number of
stashes": yes, why not bound the number of stashes instead? That would
also work like history in bash or other tools which limit it by number
of entries. But I guess the "preference for forgetting" is different for
everyone. Anyway, in my above use case I'm not sure I want the machine
make things forgotten for me; would it reduce my work by just not
reminding me of undone work? Should I let HAL (a fictional intelligent
computer) decide that I've got too much to do and he should decide I
should forget about a few things every now and then? I don't have data
at hand whether that would work and be beneficial for me; it tends to
upset me when I cannot find info again I know has been somewhere--HAL
can't really tell what *I* will forget, after all; I'll just feel like a
looser when it happens. Would another analogy be: shouldn't Git drop
history entries after, say, three years, since nobody should care about
old stuff anymore by then?)
Maybe, if the list of stashes really grows unbounded for some people,
there should be a tool to display stashes in the tree, instead of only
listing them in linear form? i.e. gitk would show the stashes kind of
like branches; of course there's also a linear list of branches--so
maybe stashes *should* be branches but in a different namespace (a
sub-local namespace), hence my thought above about hierarchical
namespaces. To sum it all up: using branches makes sense to me, but the
features that "git stash" offers (separated 'namespace' from normal
branches, and the automatic "git reset HEAD^" for removing the WIP
commit) are missing there yet.
Christian.
--
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
