Temporary directories getting errantly added into trees
I just got through a rather nasty debugging session with git-rebase, which relies on a .dotest directory. Turns out that .dotest was accidentally added to the tree in the history of the commit that was being rebased onto.
There are a lot of temporary files like that made by various scripts - eg, git-filter-branch makes .git-rewrite, etc.
I think it would be a good thing for all if you had to work very hard to put files like this in the tree, or perhaps it would be better to go through and make all the tools that create these temporary directories create them under .git instead.
Thoughts/comments?
Sam.
Quoted 4 lines · Sam Vilain
I just got through a rather nasty debugging session with git-rebase, which relies on a .dotest directory. Turns out that .dotest was accidentally added to the tree in the history of the commit that was being rebased onto.
Hi Sam,
Ouch
Quoted 7 lines
There are a lot of temporary files like that made by various scripts - eg, git-filter-branch makes .git-rewrite, etc.
I think it would be a good thing for all if you had to work very hard to put files like this in the tree, or perhaps it would be better to go through and make all the tools that create these temporary directories create them under .git instead.
Polluting the working tree is definitely a bad thing to do IMNSHO.
git-rebase --merge already puts its temporary directory inside .git/.dotest-merge. I hoped to set an example with that and get more tools to do the same; but it hasn't happened yet...
Signature · 1 line
Eric Wong
Quoted 4 lines · Sam Vilain
I think it would be a good thing for all if you had to work very hard to put files like this in the tree, or perhaps it would be better to go through and make all the tools that create these temporary directories create them under .git instead.
Personally, I think they should all go under .git with very descriptive, public names (the name ".dotest" is not really hidden from the user, and I have never really been able to make sense of it. Surely there is some more useful name?).
But I think there is the real possibility of damaging user scripts which make assumptions based on the presence of .dotest (to see if we're in a git-am or rebase session, etc). I have no idea how common such scripts are.
-Peff
Hi,
Quoted 4 lines · Sam Vilain
I just got through a rather nasty debugging session with git-rebase, which relies on a .dotest directory. Turns out that .dotest was accidentally added to the tree in the history of the commit that was being rebased onto.
While we're at it, could we change the name so that it is .git/rebase, and not .dotest or .git/.dotest-merge?
Yes, I know, existing tools could rely on the location. But then, I do not think that tools should be allowed to be _that_ married to particular implementations. And indeed, I see no reason why a tool should access .dotest, except for accessing .dotest/patch, and then it will be very obvious where it fails.
But I don't know about QGit, StGit, etc...
Ciao,
Dscho
Quoted 2 lines · Johannes Schindelin
While we're at it, could we change the name so that it is .git/rebase, and not .dotest or .git/.dotest-merge?
I totally agree.
Quoted 5 lines
Yes, I know, existing tools could rely on the location. But then, I do not think that tools should be allowed to be _that_ married to particular implementations. And indeed, I see no reason why a tool should access .dotest, except for accessing .dotest/patch, and then it will be very obvious where it fails.
Another reason might be something like:
test -d .dotest && die "rebase or am already in progress"
which some of the git tools do, and which third party scripts might care about.
-Peff
Hi.
Quoted 8 lines · Jeff King
Quoted 5 lines · Johannes Schindelin
Yes, I know, existing tools could rely on the location. But then, I do not think that tools should be allowed to be _that_ married to particular implementations. And indeed, I see no reason why a tool should access .dotest, except for accessing .dotest/patch, and then it will be very obvious where it fails.
Quoted 6 lines
Another reason might be something like:
test -d .dotest && die "rebase or am already in progress"
which some of the git tools do, and which third party scripts might care about.
Yep, for example this nice bash-completion addendum which changes the prompt according to the current repository's state.
I hope that a symlink .dotest -> .git/rebase (as I suggested in a reply to Martin) would help that, but in the long run I'd appreciate losing even that.
Ciao,
Dscho
P.S.: note that even a symlink would already help the situation described by Sam.
Quoted 1 line · Johannes Schindelin
But I don't know about QGit, StGit, etc...
I don't think StGit relies on the name of any file outside .git. (It does pollute the root of the worktree with some temp files of its own, though -- but not across invocations.)
Signature · 2 lines
Karl Hasselström, [email protected] www.treskal.com/kalle
Quoted 6 lines · Karl Hasselström
Quoted 2 lines
But I don't know about QGit, StGit, etc...
I don't think StGit relies on the name of any file outside .git. (It does pollute the root of the worktree with some temp files of its own, though -- but not across invocations.)
Yes, I've had to add .tmp_msg* to my .git/info/exclude for those, too. Given nothing cares, perhaps put them under .git anyway?
Sam.
On Nov 22, 2007 11:55 PM, Johannes Schindelin > While we're at it, could we change the name so that it is .git/rebase, and
Quoted 1 line
not .dotest or .git/.dotest-merge?
+1 on that
Quoted 3 lines
... And indeed, I see no reason why a tool should access .dotest, except for accessing .dotest/patch, and then it will be very obvious where it fails.
when it comes to .dotest/patch, it must be reasonably accessible. When git-am refuses to apply a patch, and I am resolving things by hand, I need it pretty handy. I also sometimes edit .dotest/msg-clean.
cheers,
m
Quoted 3 lines · Martin Langhoff
when it comes to .dotest/patch, it must be reasonably accessible. When git-am refuses to apply a patch, and I am resolving things by hand, I need it pretty handy. I also sometimes edit .dotest/msg-clean.
Any serious "am" user shares the habit to edit .dotest/patch and it would be VERY painful to change this, I suspect.
I do not mind shipping .dotest in the sample templates/info--exclude file, though.
Hi,
Quoted 9 lines · Martin Langhoff
On Nov 22, 2007 11:55 PM, Johannes Schindelin
Quoted 3 lines
... And indeed, I see no reason why a tool should access .dotest, except for accessing .dotest/patch, and then it will be very obvious where it fails.
when it comes to .dotest/patch, it must be reasonably accessible. When git-am refuses to apply a patch, and I am resolving things by hand, I need it pretty handy. I also sometimes edit .dotest/msg-clean.
Maybe install a .dotest/ symlink for a few "git eons", i.e. some 6 months?
Although this will not work on Windows, I see not much problems in it, since Windows users are not big in scripting (at least the git type) anyway.
Ciao,
Dscho
Quoted 3 lines · Johannes Schindelin
But I don't know about QGit, StGit, etc...
QGit does not rely on .dotest or any other temporary file produced by git
Interface with git is only through git commands.
Thanks
Marco