Re: [PATCH 2/2] git-gc: skip stashes when expiring reflogs

[Christian Jaeger <christian@jaeger.mine.nu>]

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.