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ć
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
