Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] git-svn: update documentation with CAVEATS section

From: David Kastrup <hidden>
Date: 2016-06-15 22:43:30

Eric Wong [off-list ref] writes:
David Kastrup [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help