git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Peter Baumann <waste.manager@gmx.de>
To: Lars Hjemli <hjemli@gmail.com>
Cc: Eric Wong <normalperson@yhbt.net>,
	Junio C Hamano <gitster@pobox.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] git-svn: remove --first-parent, add --upstream
Date: Fri, 7 Sep 2007 10:43:52 +0200	[thread overview]
Message-ID: <20070907084352.GD4538@xp.machine.xx> (raw)
In-Reply-To: <8c5c35580709061723m7e01c9d4p1b1936dc1d590459@mail.gmail.com>

On Fri, Sep 07, 2007 at 02:23:58AM +0200, Lars Hjemli wrote:
> On 9/7/07, Peter Baumann <waste.manager@gmx.de> 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

  reply	other threads:[~2007-09-07  8:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-05  9:35 [RFC/PATCH] git-svn: add support for --first-parent Lars Hjemli
2007-09-05 10:19 ` Eric Wong
2007-09-06  7:18   ` Lars Hjemli
2007-09-06  7:51     ` Eric Wong
2007-09-06  8:05       ` David Kastrup
2007-09-06  8:34       ` Lars Hjemli
2007-09-06 16:37       ` [PATCH] git-svn: remove --first-parent, add --upstream Lars Hjemli
2007-09-06 17:49         ` Steven Grimm
2007-09-06 21:01         ` Eric Wong
2007-09-06 21:35           ` Eric Wong
2007-09-06 22:14             ` Lars Hjemli
2007-09-06 23:55               ` Peter Baumann
2007-09-07  0:23                 ` Lars Hjemli
2007-09-07  8:43                   ` Peter Baumann [this message]
2007-09-07 10:13                     ` Lars Hjemli
2007-09-07 11:51                       ` Peter Baumann
2007-09-07 12:08                         ` Configure mutt to be used in git and lkml mailing lists (was: Re: [PATCH] git-svn: remove --first-parent, add --upstream) Fernando J. Pereda
2007-09-07 18:37                         ` [PATCH] git-svn: remove --first-parent, add --upstream Eric Wong
2007-09-15 14:08                       ` Lars Hjemli
2007-09-15 14:37                         ` Peter Baumann
2007-09-15 15:24                           ` Lars Hjemli
2007-09-15 15:49                             ` Peter Baumann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070907084352.GD4538@xp.machine.xx \
    --to=waste.manager@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=hjemli@gmail.com \
    --cc=normalperson@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).