From: David Kastrup <dak@gnu.org>
Date: Thu, 23 Aug 2007 07:48:51 GMT
Subject: Re: [PATCH] git-svn: update documentation with CAVEATS section
Message-ID: <86odgybsik.fsf@lola.quinscape.zz>
In-Reply-To: <20070823062631.GD4417@hand.yhbt.net>

Eric Wong <normalperson@yhbt.net> writes:

> David Kastrup <dak@gnu.org> wrote:
>
>> This is already a _large_ help for avoiding clobbering the central
>> repository.  But I stress that it would be much better if git-svn
>> dcommit/rebase stayed exclusively on the branch that is associated
>> with it/fetching in the "svn" config section, like git does in
>> general with remotes.  No random branch jumping after merges or (to
>> be _really_ avoided) rebases and certainly after cherry-picking
>> within git.
>
> I think I see where you're coming from, now.  git-svn doesn't ever
> associate remotes with local branches in the .git/config like
> regular git-clone.
>
> I just cloned git.git from kernel.org again to see that .git/config
> associates a local branch with a remote branch like this:
>
> ----------------------------------------------------------------
> [branch "master"]
>         remote = origin
>         merge = refs/heads/master
> ----------------------------------------------------------------
>
> I used git before this feature ever existed, and got used to git
> without ever needing it myself.  I've always had a good idea of
> where I branched off from last, or I can ask with "gitk --all"
> otherwise.

But with -t support, git-svn already has a good notion about what
branch belongs to what remote.

> So yes, I'll shamefully admit that I've never used this feature of
> git and in my very quick (and sleepy) evaluation of it, it seems
> quite limiting...

Oh, I don't mind being limited from wreaking havoc on a central
repository.

-- 
David Kastrup