Branch renaming not updating the configuration correctly.

Branch renaming not updating the configuration correctly.

[Jurko Gospodnetić]

   Hi.

   I noticed that the .git/config file is not updated completely in case 
you create two branches aaa and bbb, set the repository up so it 
automatically merges changes from bbb into aaa and then rename the branches:

   Here is an exact list of commands and config file contents 
illustrating the problem:

   > git branch aaa
   > git branch bbb
   > git config --add branch.aaa.remote .
   > git config --add branch.aaa.merge bbb

-- .git/config: --
[branch "aaa"]
	remote = .
	merge = bbb
------------------

   > git branch -m aaa patched
   > git branch -m bbb original

-- .git/config: --
[branch "patched"]
	remote = .
	merge = bbb
------------------

   And as you can see above, the branch.patched.merge configuration 
setting did not get updated and still holds the old branch name 'bbb'.

   Hope this helps.

   Best regards,
     Jurko Gospodnetić

Re: Branch renaming not updating the configuration correctly.

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 841 bytes --]

Hi,

On Mon, 28 Jul 2008, Jurko Gospodnetić wrote:

> -- .git/config: --
> [branch "aaa"]
> 	remote = .
> 	merge = bbb
> ------------------
> 
>   > git branch -m aaa patched
>   > git branch -m bbb original
> 
> -- .git/config: --
> [branch "patched"]
> 	remote = .
> 	merge = bbb
> ------------------
> 
> And as you can see above, the branch.patched.merge configuration setting 
> did not get updated and still holds the old branch name 'bbb'.

I deem this not an "important" bug.

We usually do not set up tracking information for local branches, and I 
still do not know valid common scenarios for that workflow.

But hey, if it really bothers you, and you can come up with a 
non-intrusive patch (i.e. a patch that does not punish all users that do 
_not_ set up locally-tracking branches), I am sure it will be welcomed.

Ciao,
Dscho

Re: Branch renaming not updating the configuration correctly.

[Jurko Gospodnetić]

   Hi Johannes.

>> -- .git/config: --
>> [branch "aaa"]
>> 	remote = .
>> 	merge = bbb
>> ------------------
>>
>>   > git branch -m aaa patched
>>   > git branch -m bbb original
>>
>> -- .git/config: --
>> [branch "patched"]
>> 	remote = .
>> 	merge = bbb
>> ------------------
>>
>> And as you can see above, the branch.patched.merge configuration setting 
>> did not get updated and still holds the old branch name 'bbb'.
> 
> I deem this not an "important" bug.

   Just wanted to chip in and report... not comfortable enough yet with 
git from the user side to contribute with much else...


> We usually do not set up tracking information for local branches, and I 
> still do not know valid common scenarios for that workflow.

   I was playing around with setting up a local branch containing Boost 
library sources as there is no official git repository for that project. 
  They hold their main repository under subversion and have currently 
closed down their main development branch for changes while a new 
release is being prepared. As I do _hate_ svn branching/merging I 
thought git should be perfect for the task of tracking my own changes to 
the project and this whole 'project' would give me a chance to get 
better acquainted with the tool :-).

   Crossing the SVN/Git boundary however is causing a problem since I 
use Windows and 'git svn' does not seem to be supported here. My initial 
idea was to manually update my own personal 'origin/master' branch (svn 
checkout & then manually commit to the my git branch) and then update 
other branches containing my patches from there. Locally-tracking 
branches seemed like a perfect fit for that.

   Any other suggested patterns/organizations/solutions I should try out 
in this case?


> But hey, if it really bothers you, and you can come up with a 
> non-intrusive patch (i.e. a patch that does not punish all users that do 
> _not_ set up locally-tracking branches), I am sure it will be welcomed.

   Heh... it'll take a little more time for me to get comfortable enough 
with git to attempt something like that. :-) Still an infant user here, 
happy with reporting what I find and hoping I don't miss something too 
obvious or find & report something already reported. :-)

   Best regards,
     Jurko Gospodnetić