On Fri, Sep 07, 2007 at 02:23:58AM +0200, Lars Hjemli wrote: > On 9/7/07, Peter Baumann <waste.manager@xxxxxx> wrote: > > Wouldn't it be much more pleasant to say something like > > > > git-svn dcommit --on the_branch > > > > whereas 'the_branch' is the name of the upstream branch as specified > > in the fetch/branch section in the git config? > > Well, git-svn extracts the svn url, revision and repo uuid from the > commit message, while your proposal only specifies the url. But I'm > still not certain that there is a need for --upstream or anything > similar if git-svn always uses 'git log --first-parent' (see > http://article.gmane.org/gmane.comp.version-control.git/57951). > First parent is a heuristic (and a good one, me thinks). If you did something like this: (1) Start state: a-b-c-d-e trunk (both trunk and branch1 are imported \ from SVN) \-x-y branch1 (2) Hm. My Branch 'branch1' should be ready to be merged to 'trunk', so lets do it (not yet dcommited) a-b-c-d-e- m trunk \ / \ -x-y branch1 (3) ARGH. I just discovered a serious bug in 'branch1' and can't just merge it into 'trunk', yet. But the merge was painfull enough so I don't want to redo it again, so lets reset 'trunk' to its state before the merge and 'branch1' to the merge commit, before fixing the bug in 'branch1'. a-b-c-d-e trunk \ \ \ -x-y m branch1 Notice that this DAG is identical to the one in (2), but just the branch labels stick to different commits. And if you now want to commit the merge 'm' to 'branch1' before fixing the bug you are screwed, because --first-parent will give you 'e' instead of 'y'. Yes, I know that this example isn't something happening every day, but at least it shows that --first-parent could *only* be a heuristic and not something you would rely 100% on. And if you imagine several people who are sharing their git commits for codereview with pulling/pushing, it isn't obvious what branch got merged into the other, because it is possible that the other person did the merge. Don't get me wrong, --first-parent *is* an improvement over the current behaviour, but I think it is simply not the *best* we can do. -Peter - 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
