Eric Wong <normalperson@xxxxxxxx> writes: > David Kastrup <dak@xxxxxxx> 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 - 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
