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.

Sam Vilain [off-list ref] wrote:

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

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...

-- 
Eric Wong

On Thu, Nov 22, 2007 at 04:51:53PM +1300, Sam Vilain wrote:

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,

On Thu, 22 Nov 2007, Sam Vilain wrote:

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

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

not .dotest or .git/.dotest-merge?

+1 on that

... 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

On Thu, Nov 22, 2007 at 10:55:00AM +0000, Johannes Schindelin wrote:

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.

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,

On Fri, 23 Nov 2007, Martin Langhoff wrote:

On Nov 22, 2007 11:55 PM, Johannes Schindelin

quoted

... 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

Hi.

On Thu, 22 Nov 2007, Jeff King wrote:

On Thu, Nov 22, 2007 at 10:55:00AM +0000, Johannes Schindelin wrote:

quoted

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.

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.

On 2007-11-22 10:55:00 +0000, Johannes Schindelin wrote:

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.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

On Nov 22, 2007 11:55 AM, Johannes Schindelin
[off-list ref] wrote:

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

Karl Hasselström wrote:

quoted

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.