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

Johannes Schindelin wrote:

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.