[RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Johannes Schindelin]

With this patch, git automatically extracts the information from 
.git/branches and .git/remotes, puts it into .git/config, and renames the 
directories to .git/branches.old and .git/remotes.old, respectively.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

---

 git-parse-remote.sh |   53 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 53 insertions(+), 0 deletions(-)

applies-to: 239817500e3556e8541d3b2b8257802c10da85c2
69062e3473f9f3cafe33954d9b995da89f6d9898
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index cd976da..0d603ac 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -2,6 +2,59 @@
 
 . git-sh-setup
 
+if [ -d "$GIT_DIR"/branches ]; then
+	echo "Rewriting $GIT_DIR/branches" >&2
+	error=0
+	# rewrite into config
+	{
+		cd "$GIT_DIR"/branches
+		ls | while read f; do
+			name=$(echo -n "$f" | tr -c "A-Za-z0-9" ".")
+			sed \
+			-e "s/^/remote.$name.url /" \
+			-e "s/#\(.*\)$/\nremote.$name.pull \1/" \
+			< "$f"
+		done
+		echo done
+	} | while read key value; do
+		case $key in
+		done)
+			if [ $error = 0 ]; then
+				mv "$GIT_DIR"/branches "$GIT_DIR"/branches.old
+			fi ;;
+		*)
+			git-config-set $key "$value" || error=1 ;;
+		esac
+	done
+fi
+
+if [ -d "$GIT_DIR"/remotes ]; then
+	echo "Rewriting $GIT_DIR/remotes" >&2
+	error=0
+	# rewrite into config
+	{
+		cd "$GIT_DIR"/remotes
+		ls | while read f; do
+			name=$(echo -n "$f" | tr -c "A-Za-z0-9" ".")
+			sed -n \
+			-e "s/^URL: /remote.$name.url . /p" \
+			-e "s/^Pull: /remote.$name.pull ^$ /p" \
+			-e "s/^Push: /remote.$name.push ^$ /p" \
+			< "$f"
+		done
+		echo done
+	} | while read key regex value; do
+		case $key in
+		done)
+			if [ $error = 0 ]; then
+				mv "$GIT_DIR"/remotes "$GIT_DIR"/remotes.old
+			fi ;;
+		*)
+			git-config-set $key "$value" $regex || error=1 ;;
+		esac
+	done
+fi
+
 get_data_source () {
 	case "$1" in
 	*/*)
---
0.99.9.GIT

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Josef Weidendorfer]

On Monday 21 November 2005 14:56, Johannes Schindelin wrote:
> With this patch, git automatically extracts the information from 
> .git/branches and .git/remotes, puts it into .git/config, and renames the 
> directories to .git/branches.old and .git/remotes.old, respectively.

Please... don't trash .git/branches.
This is about Cogito, not about Git. You will render every repository cloned
with Cogito useless, as it expects a per-branch configuration with the same
name as heads.

The part about .git/branches has to be sent to Pasky, not Junio. 

Josef

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Johannes Schindelin]

Hi,

On Mon, 21 Nov 2005, Josef Weidendorfer wrote:

> On Monday 21 November 2005 14:56, Johannes Schindelin wrote:
> > With this patch, git automatically extracts the information from 
> > .git/branches and .git/remotes, puts it into .git/config, and renames the 
> > directories to .git/branches.old and .git/remotes.old, respectively.
> 
> Please... don't trash .git/branches.
> This is about Cogito, not about Git. You will render every repository cloned
> with Cogito useless, as it expects a per-branch configuration with the same
> name as heads.
> 
> The part about .git/branches has to be sent to Pasky, not Junio. 

I was aware that .git/branches was introduced by Pasky, but as it is 
handled in git-parse-remote.sh, I thought that it may be a bit more 
general than just cogito.

Anyways, I sent this out as an *RFC*, but the "C" obviously stands for 
"Comments"...

What do people say? Is it useless to move that information into the 
config, where it can be queried/replaced/set/removed by the config "API", 
or should we continue with two incompatible ad-hoc formats? (If that 
sounds biased, it was not meant to be.)

Ciao,
Dscho

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Josef Weidendorfer]

On Monday 21 November 2005 16:57, Johannes Schindelin wrote:
> > The part about .git/branches has to be sent to Pasky, not Junio. 
> 
> I was aware that .git/branches was introduced by Pasky, but as it is 
> handled in git-parse-remote.sh, I thought that it may be a bit more 
> general than just cogito.

AFAIK, Cogito introduced it, and Git used it in the wrong way. All files
in .git/branches map 1:1 to a local head (perhaps not really existing).
Git misused this information by using a head name as shortcut for a
remote repository - which still leads to quite some confusion:
In repositories cloned by Cogito you now have a "origin" head, and
automatically have a repository shortcut "origin", too. The same name is
used for different kinds of objects - IMHO quite bad.

The best thing is to simply remove .git/branches parsing in git at all.
 
> Anyways, I sent this out as an *RFC*, but the "C" obviously stands for 
> "Comments"...

I think that putting .git/remotes info into .git/config is nice.
And I also think that putting .git/branches info into .git/config is a nice
thing.
If .git/branches/origin contains "http://www.kernel.org/pub/scm/git/git.git#todo",
this should map to

[head.origin]
  fetchurl = http://www.kernel.org/pub/scm/git/git.git
  fetchhead = todo

The problem here is that heads can have spaces, "." and "/" in their name.

> What do people say? Is it useless to move that information into the 
> config, where it can be queried/replaced/set/removed by the config "API", 
> or should we continue with two incompatible ad-hoc formats? (If that 
> sounds biased, it was not meant to be.)

Cogito does not have per-repository configuration (e.g. like this "shortcut"
thing), but only about per-head configuration. In this way, the information
in .git/branches is quite different from the one in .git/remotes.

Josef

> 
> Ciao,
> Dscho
> 
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Andreas Ericsson]

Johannes Schindelin wrote:
> 
> What do people say? Is it useless to move that information into the 
> config, where it can be queried/replaced/set/removed by the config "API", 

You're thinking the wrong way around. "Is it useless so we should 
refrain?" is not the same as "is it useful enough to do?".


> or should we continue with two incompatible ad-hoc formats? (If that 
> sounds biased, it was not meant to be.)
> 

I don't use Cogito myself so I'm not aware of what incompatibilities 
there are. However, it's a user-friendliness layer, so it can choose to 
do things differently if it wants to, but changing how the plumbing 
works to match the porcelain seems wrong to me.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Mon, 21 Nov 2005, Josef Weidendorfer wrote:
>
>> On Monday 21 November 2005 14:56, Johannes Schindelin wrote:
>> > With this patch, git automatically extracts the information from 
>> > .git/branches and .git/remotes, puts it into .git/config, and renames the 
>> > directories to .git/branches.old and .git/remotes.old, respectively.
>> 
>> Please... don't trash .git/branches.
>> This is about Cogito, not about Git. You will render every repository cloned
>> with Cogito useless, as it expects a per-branch configuration with the same
>> name as heads.
>> 
> I was aware that .git/branches was introduced by Pasky, but as it is 
> handled in git-parse-remote.sh, I thought that it may be a bit more 
> general than just cogito.

What Josef said is correct in that I was not aware of the fact
that Cogito branches/ are *per-branch* configuration when I did
parse-remote.  remotes/ are deliberately *per-remote*
configuration, because it is more efficient when you are
downloading more than one refs from the same remote over a
git-aware protocol.  Arguably, it is optimizing for the wrong
case, because it may well be a minority case to keep track of
more than one remote head.  I dunno.

I am not sure if it is a good idea to automatically convert what
is stored in .git/branches to .git/remotes (or the equivalent of
the latter in .git/config), but if somebody wanted to do it, the
right thing would be:

 - grab the URL without optional fragment '#rembranch' part from
   all branches/* file;

 - group the ones that fetch from the same URL into one
   remotes/$file (what to call that file is very debatable
   because the original branches/* is in different namespace and
   we cannot tell what the user wants to call the remote),
   giving appropriate head mapping.  branches/$branch file with
   the fragment part '#$rembranch' translates to "Pull:
   $rembranch:$branch".

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Petr Baudis]

Dear diary, on Mon, Nov 21, 2005 at 02:56:41PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> With this patch, git automatically extracts the information from 
> .git/branches and .git/remotes, puts it into .git/config, and renames the 
> directories to .git/branches.old and .git/remotes.old, respectively.
> 
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>

Please don't do so for .git/branches, that is primarily Cogito thing
and you will make it impossible to use GIT and Cogito on the same
repository - the moment the user uses git-pull on the repository, his
Cogito configuration is trashed and he has even no reliable undo
mechanism.

And in another thread (we have too many threads for this subject ;-)
I've tried to explain that branches and remotes are different concepts,
which live in different namespaces and have different semantics, so
rewriting branches to remotes is a bad idea anyway.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Johannes Schindelin]

Hi,

On Sun, 27 Nov 2005, Petr Baudis wrote:

> I've tried to explain that branches and remotes are different concepts,

Well, no. They aren't. The "branches" concept is a proper special case of 
the "remotes" concept.

But what the heck, I don't care what you eventually use.

I only realized that we -- in the good tradition of UNIX -- have many 
different formats for different configurations: Some configurations are in 
.gitignore, some are in .git/branches/, some in .git/remotes/, some in 
.git/config, and even some in environment variables!

If everybody says that this should stay so, I'll just shut up.

Hth,
Dscho

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> I only realized that we -- in the good tradition of UNIX -- have many 
> different formats for different configurations: Some configurations are in 
> .gitignore, some are in .git/branches/, some in .git/remotes/, some in 
> .git/config, and even some in environment variables!

Can you live with something like this?

 - we will add new ones to config, now we have it;

 - we will not deprecate existing ones outside of config for some time;

 - we will not duplicate/move existing ones into config at least
   for now to keep our work less complicated;

 - we would revisit deprecating things outside config file
   sometime later after 1.0 stabilizes, and that's when we will
   talk about moving these things into config.

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Andreas Ericsson]

Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> 
>>I only realized that we -- in the good tradition of UNIX -- have many 
>>different formats for different configurations: Some configurations are in 
>>.gitignore, some are in .git/branches/, some in .git/remotes/, some in 
>>.git/config, and even some in environment variables!
> 
> 
> Can you live with something like this?
> 
>  - we will add new ones to config, now we have it;
> 

I'd still like to see git-repo-config and git-user-config. Otherwise 
we'll need to continue having user-based environment variables 
(GIT_COMMITTER_IDENT and friends).

> 
>  - we would revisit deprecating things outside config file
>    sometime later after 1.0 stabilizes, and that's when we will
>    talk about moving these things into config.
> 

GIT_DIR and GIT_OBJECT_DIR must remain environment variables (or command 
line arguments) more or less indefinitely. It doesn't make sense to keep 
them any other way.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Junio C Hamano]

Andreas Ericsson <ae@op5.se> writes:

> I'd still like to see git-repo-config and git-user-config. Otherwise 
> we'll need to continue having user-based environment variables 
> (GIT_COMMITTER_IDENT and friends).

Since .git/config is not shared across repositories even on
clone (and is deliberately so), "git-repo-config user.name" is
for you to set *your* name.

Having said that, GIT_COMMITTER_IDENT and friends are there to
stay, because that is how you override what you get from the
config file per commit, which is needed for people playing the
integrator role.  When one is playing an individual developer
role, user.name or even not having any and relying on GECOS is
often good enough.

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Josef Weidendorfer]

On Monday 28 November 2005 09:43, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > 
> >>I only realized that we -- in the good tradition of UNIX -- have many 
> >>different formats for different configurations: Some configurations are in 
> >>.gitignore, some are in .git/branches/, some in .git/remotes/, some in 
> >>.git/config, and even some in environment variables!
> > 
> > 
> > Can you live with something like this?
> > 
> >  - we will add new ones to config, now we have it;

It is not really fitting for all purposes (eg. syntax restrictions).


> I'd still like to see git-repo-config and git-user-config. Otherwise 
> we'll need to continue having user-based environment variables 
> (GIT_COMMITTER_IDENT and friends).

In fact, it would be nice to have different "config levels" supported
by git. I can imagine:
(1) user config (typically in $HOME/.gitrc)
(2) project config (in .git/project.conf)
(3) repository config; i.e. separate for every clone
    (in .git/repo.conf instead of .git/config as of now?)
Even for one such level, it would be nice to be able to seperate the
config into multiple files; ie. remote config in a .git/remote.conf,
and a porcelain should be able to have its own config files, but still
using git's config parser.

To allow for this, git_config() should not be hardcoded to only
read .git/config, but perhaps a list of files in environment variable
GIT_CONFIG_FILES.

For (2), git-clone should copy some files, e.g. the .git/project.conf
or .git/info/exclude. But project config probably should be kept
up to date among all repositories for a project, i.e. it should be
version controlled itself, but independent from the project.
We could use a project config head .git/refs/projectconfig for this;
of course post-1.0 material.


Josef

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Andreas Ericsson]

Josef Weidendorfer wrote:
> 
> To allow for this, git_config() should not be hardcoded to only
> read .git/config, but perhaps a list of files in environment variable
> GIT_CONFIG_FILES.
> 

$HOME/.gitrc:$GIT_DIR/conf/*

All files could support the freestanding "include" syntax.

> For (2), git-clone should copy some files, e.g. the .git/project.conf
> or .git/info/exclude. But project config probably should be kept
> up to date among all repositories for a project, i.e. it should be
> version controlled itself, but independent from the project.
> We could use a project config head .git/refs/projectconfig for this;
> of course post-1.0 material.


It would be very nifty to have some files that can hold maintainer-like 
variables (like upstream email address for patches).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...)

[Josef Weidendorfer]

On Monday 28 November 2005 14:11, Andreas Ericsson wrote:
> Josef Weidendorfer wrote:
> > 
> > To allow for this, git_config() should not be hardcoded to only
> > read .git/config, but perhaps a list of files in environment variable
> > GIT_CONFIG_FILES.
> > 
> 
> $HOME/.gitrc:$GIT_DIR/conf/*

Yes, perhaps with this as default...

> All files could support the freestanding "include" syntax.

Better run cpp on the config files before loading ;-)
Or provide a hook which returns the config on stdout.
The default for .git/hooks/config would be

	cat $GIT_DIR/config

Hmm... this was only meant to be a joke; but now I actually think
this is a nice idea as basic configuration mechanism of git plumbing.

Josef

Re: Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...)

[Johannes Schindelin]

Hi,

On Mon, 28 Nov 2005, Josef Weidendorfer wrote:

> On Monday 28 November 2005 14:11, Andreas Ericsson wrote:
> > Josef Weidendorfer wrote:
> > > 
> > > To allow for this, git_config() should not be hardcoded to only
> > > read .git/config, but perhaps a list of files in environment variable
> > > GIT_CONFIG_FILES.
> > > 
> > 
> > $HOME/.gitrc:$GIT_DIR/conf/*
> 
> Yes, perhaps with this as default...
> 
> > All files could support the freestanding "include" syntax.
> 
> Better run cpp on the config files before loading ;-)
> Or provide a hook which returns the config on stdout.
> The default for .git/hooks/config would be
> 
> 	cat $GIT_DIR/config
> 
> Hmm... this was only meant to be a joke; but now I actually think
> this is a nice idea as basic configuration mechanism of git plumbing.

The longer I read this thread the more I *positively* *hate* to have 
started it.

People, I wanted simplification. And you ask instead for every feature and 
his dog, and could I have fries with that?

KISS!

I *don't* want split config files. Why? Because it buys you only confusion 
and complication. If you want to group variables, do so with sections (BTW 
that's what they were designed for).

I am perfectly okay when somebody says that I should leave things as they 
are and not fsck around with configuration. The impression I get is that 
you want to force me to admit that I was wrong from the start.

Ciao,
Dscho

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Petr Baudis]

Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> (2) project config (in .git/project.conf)

What are you going to keep in it? There isn't much of stuff which is not
per-user or per-instance. I can't think of anything now, but there is no
list of configuration variables to check yet.

(Upstream maintainer email is interesting, OTOH it alone doesn't seem to
justify the mechanism by itself; also, the upstreams may be different
based on where you cloned the project from, etc.)

> For (2), git-clone should copy some files, e.g. the .git/project.conf
> or .git/info/exclude. But project config probably should be kept
> up to date among all repositories for a project, i.e. it should be
> version controlled itself, but independent from the project.
> We could use a project config head .git/refs/projectconfig for this;
> of course post-1.0 material.

If you still want per-project config, why should it be independent from
the project? Actually, like you have .gitignore, having something like
.gitconfig in project root would be by far the simplest - if you want
separate head, your merging and stuff gets quite more complicated, as
well as actually branching the project config, etc.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Josef Weidendorfer]

On Monday 28 November 2005 14:48, Petr Baudis wrote:
> Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter
> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > (2) project config (in .git/project.conf)
> 
> What are you going to keep in it? There isn't much of stuff which is not
> per-user or per-instance. I can't think of anything now, but there is no
> list of configuration variables to check yet.

Project global configurations could be:
- .git/info
- .git/hooks
- default for encoding of commit messages
- relationship of public project branches (perhaps access rights)
- project description, maintainers, public branch descriptions
- central repository URL
- ...

> (Upstream maintainer email is interesting, OTOH it alone doesn't seem to
> justify the mechanism by itself; also, the upstreams may be different
> based on where you cloned the project from, etc.)

Hmm.. this even could be seen as another level: origin specific

> > For (2), git-clone should copy some files, e.g. the .git/project.conf
> > or .git/info/exclude. But project config probably should be kept
> > up to date among all repositories for a project, i.e. it should be
> > version controlled itself, but independent from the project.
> > We could use a project config head .git/refs/projectconfig for this;
> > of course post-1.0 material.
> 
> If you still want per-project config, why should it be independent from
> the project? Actually, like you have .gitignore, having something like
> .gitconfig

That doesn't work well with configuration which should be global to the
whole history of the original project, e.g. .git/info/exclude, or maintainer
information.

> in project root would be by far the simplest - if you want 
> separate head, your merging and stuff gets quite more complicated, as
> well as actually branching the project config, etc.

Project configuration probably always should be up to date, so:
* always update when fetching/pulling project branches
* always push when pushing project branches

Josef

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Junio C Hamano]

Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:

>> >  - we will add new ones to config, now we have it;
>
> It is not really fitting for all purposes (eg. syntax restrictions).

OK; please read it as "when able".

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Johannes Schindelin]

Hi,

On Sun, 27 Nov 2005, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I only realized that we -- in the good tradition of UNIX -- have many 
> > different formats for different configurations: Some configurations are in 
> > .gitignore, some are in .git/branches/, some in .git/remotes/, some in 
> > .git/config, and even some in environment variables!
> 
> Can you live with something like this?
> 
>  - we will add new ones to config, now we have it;
> 
>  - we will not deprecate existing ones outside of config for some time;
> 
>  - we will not duplicate/move existing ones into config at least
>    for now to keep our work less complicated;
> 
>  - we would revisit deprecating things outside config file
>    sometime later after 1.0 stabilizes, and that's when we will
>    talk about moving these things into config.

I can very well live with this!

As a first step, we could support getting the remote information from 
.git/config after testing .git/branches/ and .git/remotes/?

Ciao,
Dscho

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Petr Baudis]

Dear diary, on Mon, Nov 28, 2005 at 02:52:08AM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 27 Nov 2005, Petr Baudis wrote:
> 
> > I've tried to explain that branches and remotes are different concepts,
> 
> Well, no. They aren't. The "branches" concept is a proper special case of 
> the "remotes" concept.

Yes, but precisely what I want to do is to avoid (most of) the "added
value" of the remotes concept, if you will. Also, it really is a
different namespace than branches (while branches share the same
namespace with heads); I can try to make the namespaces match, but when
they suddenly won't, you are in big mess.

> But what the heck, I don't care what you eventually use.
> 
> I only realized that we -- in the good tradition of UNIX -- have many 
> different formats for different configurations: Some configurations are in 
> .gitignore, some are in .git/branches/, some in .git/remotes/, some in 
> .git/config, and even some in environment variables!
> 
> If everybody says that this should stay so, I'll just shut up.

As I said, I don't care much if this moves to the git configuration
file, but please don't merge it with the remotes.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.

Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config

[Johannes Schindelin]

Hi,

On Mon, 28 Nov 2005, Petr Baudis wrote:

> As I said, I don't care much if this moves to the git configuration
> file, but please don't merge it with the remotes.

As you have made quite clear, it is for *you* to decide if you want to 
move .git/branches/ anywhere. I wrote the automatic conversion only to 
demonstrate how I thought how a migration *could* be done painlessly, if 
the information goes into .git/config.

Hth,
Dscho