David Kastrup <dak@xxxxxxx> wrote:
> Eric Wong <normalperson@xxxxxxxx> writes:
> > David Kastrup <dak@xxxxxxx> wrote:
> >> Junio C Hamano <gitster@xxxxxxxxx> writes:
> >> > Eric Wong <normalperson@xxxxxxxx> writes:
> >> >
> >> >> I've been meaning to do this for a while, hopefully this cuts
> >> >> down on the redundant mailing list traffic about these subjects.
> >> >> ...
> >> >> +CAVEATS
> >> >> +-------
> >> >> +
> >> >> +For the sake of simplicity and interoperating with a less-capable system
> >> >> +(SVN), it is recommended that all git-svn users clone, fetch and dcommit
> >> >> +directly from the SVN server, and avoid all git-clone/pull/merge/push
> >> >> +operations between git repositories and branches. The recommended
> >> >> +method of exchanging code between git branches and users is
> >> >> +git-format-patch and git-am, or just dcommiting to the SVN repository.
> >> >> +
> >> >> +Running 'git-merge' or 'git-pull' is NOT recommended on a branch you
> >> >> +plan to dcommit from. Subversion does not represent merges in any
> >> >> +reasonable or useful fashion; so users using Subversion cannot see any
> >> >> +merges you've made.
> >> >
> >> > Ok, my ruling before 1.5.3 is to take this patch, and encourage
> >> > interested parties to help Eric adding reliable support for the
> >> > feature after that, if such is possible.
> >>
> >> Couldn't we at least get a _documentation_ of the current behavior
> >> when actually using git for branch work? Knowing what will fail how
> >> and when is not as good as things just working as one would expect,
> >> but it certainly beats obscure warnings.
> >>
> >> For example, I consider it rather unacceptable that nowhere is
> >> documented just _how_ git-svn chooses one Subversion branch to commit
> >> to.
> >
> > dcommit always chooses the last SVN branch it branched off from.
>
> No, it doesn't. That's the problem. If I do
> git-merge master
> in a side branch, and do git-svn dcommit afterwards, the commit
> goes to the master branch.
>
> Which is utterly unexpected.
Oops, sorry I only read your response and forgot about the original
topic. Yes, merging between SVN branches in git breaks dcommit badly,
which is why I advise against using it. I'll try to fix it when I've
got more free time.
> 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.
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...
--
Eric Wong
-
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
