Thread (21 messages) flat view 21 messages, 5 authors, 2016-06-15

Re: [PATCH] git-svn: remove --first-parent, add --upstream

From: Peter Baumann <hidden>
Date: 2016-06-15 22:43:34

On Fri, Sep 07, 2007 at 02:23:58AM +0200, Lars Hjemli wrote:
On 9/7/07, Peter Baumann [off-list ref] wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help