git-rebase.sh: Change .dotest directory to .git-dotest

Change git specific doings into namespace .git*. Define new variable WORKDIR, which points to working directory .git-dotest.

---
 git-rebase.sh |   41 +++++++++++++++++++++--------------------
 1 files changed, 21 insertions(+), 20 deletions(-)

index ec052c4..259096f 100755
@@ -14,7 +14,7 @@ It is possible that a merge failure will prevent this process from being
 completely automatic.  You will have to resolve any such merge failure
 and run git rebase --continue.  Another option is to bypass the commit
 that caused the merge failure with git rebase --skip.  To restore the
-original <branch> and remove the .dotest working files, use the command
+original <branch> and remove the .git-dotest working files, use the command
 git rebase --abort instead.
 
 Note that if <branch> is not specified on the command line, the

@@ -43,7 +43,8 @@ To restore the original branch and stop rebasing run \"git rebase --abort\".
 unset newbase
 strategy=recursive
 do_merge=
-dotest=$GIT_DIR/.dotest-merge
+WORKDIR=$GIT_DIR/.git-dotest
+dotest=$WORKDIR-merge
 prec=4
 verbose=
 git_am_opt=

@@ -171,9 +172,9 @@ do
 			finish_rb_merge
 			exit
 		fi
-		head_name=$(cat .dotest/head-name) &&
-		onto=$(cat .dotest/onto) &&
-		orig_head=$(cat .dotest/orig-head) &&
+		head_name=$(cat $WORKDIR/head-name) &&
+		onto=$(cat $WORKDIR/onto) &&
+		orig_head=$(cat $WORKDIR/orig-head) &&
 		git am $git_am_opt --resolved --3way \
 		    --resolvemsg="$RESOLVEMSG" &&
 		move_to_original_branch

@@ -197,9 +198,9 @@ do
 			finish_rb_merge
 			exit
 		fi
-		head_name=$(cat .dotest/head-name) &&
-		onto=$(cat .dotest/onto) &&
-		orig_head=$(cat .dotest/orig-head) &&
+		head_name=$(cat $WORKDIR/head-name) &&
+		onto=$(cat $WORKDIR/onto) &&
+		orig_head=$(cat $WORKDIR/orig-head) &&
 		git am -3 --skip --resolvemsg="$RESOLVEMSG" &&
 		move_to_original_branch
 		exit

@@ -210,11 +211,11 @@ do
 		then
 			move_to_original_branch
 			rm -r "$dotest"
-		elif test -d .dotest
+		elif test -d $WORKDIR
 		then
-			dotest=.dotest
+			dotest=$WORKDIR
 			move_to_original_branch
-			rm -r .dotest
+			rm -r $WORKDIR
 		else
 			die "No rebase in progress?"
 		fi

@@ -262,17 +263,17 @@ do
 	shift
 done
 
-# Make sure we do not have .dotest
+# Make sure we do not have $WORKDIR
 if test -z "$do_merge"
 then
-	if mkdir .dotest
+	if mkdir $WORKDIR
 	then
-		rmdir .dotest
+		rmdir $WORKDIR
 	else
 		echo >&2 '
-It seems that I cannot create a .dotest directory, and I wonder if you
+It seems that I cannot create a $WORKDIR directory, and I wonder if you
 are in the middle of patch application or another rebase.  If that is not
-the case, please rm -fr .dotest and run me again.  I am stopping in case
+the case, please rm -fr $WORKDIR and run me again.  I am stopping in case
 you still have something valuable there.'
 		exit 1
 	fi

@@ -381,10 +382,10 @@ then
 	git am $git_am_opt --binary -3 -k --resolvemsg="$RESOLVEMSG" &&
 	move_to_original_branch
 	ret=$?
-	test 0 != $ret -a -d .dotest &&
-		echo $head_name > .dotest/head-name &&
-		echo $onto > .dotest/onto &&
-		echo $orig_head > .dotest/orig-head
+	test 0 != $ret -a -d $WORKDIR &&
+		echo $head_name > $WORKDIR/head-name &&
+		echo $onto > $WORKDIR/onto &&
+		echo $orig_head > $WORKDIR/orig-head
 	exit $ret
 fi
 

1.5.4-rc5.GIT-dirty


-- 
Welcome to FOSS revolution: we fix and modify until it shines

Shouldn't this just go in the .git/ directory ?

Mike

Hi,

No.

If at all, it should be in .git/rebase/, not in .git-dotest/. Note that we have a different directory already for interactive rebase and rebase -m, .git/.dotest-merge/ (which could have been a better name, too).

But the consensus was that there might be scripts relying on the name of the directory, so we left it as-is, and did not even consolidate both versions into the same name.

So _if_ you still want to change it, you need a looooong-term switch-over plan. For one, you _have_ to install a symbolic link in order not to break existing scripts, and remove it afterwards.

Ciao,
Dscho

* Tue 2008-02-05 Johannes Schindelin <[email protected]>

Much better.

Yes, that should go to .git too.

Who would use or rely on the internal workings of git-rebase? The will not be any considerable amount of those. I'm confident that those people have enough expertise to change their scripts.

The current situation is plain ugly and git shouldn't stomp on any other dir than .git

Jari

Welcome to FOSS revolution: we fix and modify until it shines

I do agree.

The whole (and _only_) reason for the directory being called ".dotest" is literally totally silly and historical:

- I long since wrote my own stupid scripts around BK (and called my set of scripts around BK "bktools")

- that script set included a script to extract the patch and description from a mailbox.

- that script was called "dotest", because it started out as a testing script, and I never re-named it. And while my bktools set had other scripts in it, that was the one I used _every_single_day_, so "dotest" is not only always in my shell history, it's also hardcoded in my brainstem.

- BitMover eventually merged an improved version of my mbox applicator scripts into bitkeeper, making much of it pointless, but I kept the name around as a shell macro, because it was what I was used to (I think it basically expanded into something like "bk import -temail" or something)

- when I started git, I *rewrote* those old bktools for git, and created a new "git-tools" directory. And yes, the script that actually tied all the mail splitting and application together was *still* called "dotest", because it was still what I used.

- again, time passes, and again, my helper scripts end up migrating into the actual SCM, now called "git applymbox" (and then later "git am"), but yet *again*, I cannot teach myself to call it anything sane, so my .bashrc file still contains

	alias dotest='git-am --utf8'

and I still write "dotest" when I apply emails. Even though it hasn't been about "testing" for the last five years or so, and it's how I do all my work.

So the temporary directory that contains all the temp-files for my "dotest" script (which was external to git) - it's called ".dotest". Of course.

It all makes perfect sense. Or rather, it made sense way back when. I agree that it's just totally insane these days, and ".dotest/" should be renamed to something like ".git/split/" or something.

Linus

Hi,

[Jari, keep me Cc'ed. I missed your mail, because you didn't.]

But please, please, please not without a proper plan to keep people informed! I.e. a switch-over plan with deprecation and all. (IOW what I _already_ wrote to Jari.)

On at least one machine (not the current one, because I was too lazy), I have a git alias to call when the patch does not apply, to call another program in turn which made it easier for me to integrate a non-applying patch into the current working directory.

And guess what: this script accesses .dotest/. Yes, I know, it was _prone_ to move.

But I am lucky, I read the git list regularly, I know what truck is going to hit me if I do not change that alias.

However, there are others. And while we like to give everybody way too much rope, we should not willfully run a truck in the direction of unsuspecting users.

Ciao,
Dscho

Aha, that's the script we're talking about :)

I think there's a correlation here: anybody who's meddling with git implementation details (yes, I'm talking about .dotest here) is probably also subscribed to this list :) Seriously though, in git there is often no clear line between implementation details and supported features, so it's way to easy to claim everything is set in stone and that the world will break if we change it. Especially if you've written a script that happens to reach a little to far into the git guts.

Kristian

Hi,

I think you are being unfair here:

Imagine git-am stops somewhere because the patch fails. What to do? Where to look? What to fix?

Exactly. You have _only_ one option. You look into .dotest/.

So yes, it is an implementation detail. But one that we could not _possibly_ hide.

What's so wrong with using a symlink first, trying hard not to break peoples' assumptions, then tell them that they should change their scripts (which they can do lazily now, since both .dotest/ _and_ .git/rebase/ are valid)?

How is being nice to people wrong?

Ciao,
Dscho

Johannes,

Why don't you simply manually add the symlink to your repo, or better yet, fix your script?

I don't think many people will think they've been screwed just because this .dotest directory has moved, since not so many people might be relying on it. And for those who do, well they certainly have the knowledge to help themselves out of this very complicated matter. ;-)

So I'd suggest simply moving it and see if other people, if any, start screaming.

Nicolas

* Tue 2008-02-05 Johannes Schindelin <[email protected]>
* Message-Id: [email protected]

If somebody has written scripts to do something with the internals, he already knows the internals. I'm confident those can easily track the changes. They are experts already if they use .dotest.

All good shell scripts test the conditions before they proceed. Like in this case. Something:

    dir=.dotest

    [ -d "$dir" ] || { echo "No directory $dir" >&2; exit 1; }

Sloppy scripts are best left to script writers headache.

Jari

Welcome to FOSS revolution: we fix and modify until it shines

Hi,

I see no sloppy behaviour when somebody sees that git-am (which uses the same directory!) has no way of handling a non-applying patch, and then writes a script that accesses .dotest/patch.

But I _see_ some sloppy behaviour of somebody not following netiquette, responding to a certain mail, but not to the original poster!

Ciao,
Dscho "who is annoyed"

It may count sloppy not to feed the improvements back, though.

Of course, if the reason is because somebody is ashamed of the script being too hacky for public consumption, then not feeding is not sloppy at all. But then probably that makes the script sloppy. That somebody is sloppy either way, isn't s/he? ;-)

JC "who is trapped in day-job".