Andrew Sayers wrote:
>
> I'm not averse to adding a config setting, or to exploring the
> "--no-metadata" case. I am concerned about the strict time constraints
> for code called in a command prompt though. For instance, calling
> git-svn could easily make your prompt take over half a second to respond
> because of all the Perl you'd have to compile.
True, I forgot about that.
> I'd also want a few
> real-world use cases and a nod from Shawn before diverging any further
> from the existing GIT_PS1_FOO= convention.
> Having said all that, I'm quite happy to resubmit with
> GIT_PS1_SHOWUNPUSHED=svn treated like GIT_PS1_SHOWUNPUSHED=1 when
> $GIT_DIR/svn doesn't exist.
There's the precedent of bash.showDirtyState that allows you to
disable the +* indicators _per repository_. The latter idea also
sounds reasonable, though I personally would find the configuration
more useful. I have several repos that push to both git (for real
work) and SVN (for buildbots) where I'd prefer the indicator to refer
to git.
> > How about starting with
> >
> > git log -1 --first-parent --grep="^git-svn-id: $remote_branch"
>
> Good idea about "-1" and "--grep", but multi-parent commits aren't
> compatible with SVN, so I don't see how "--first-parent" is useful here?
> In fact I'm tempted to look for merge commits and print a big warning
> when one is found.
Please don't; you'd immediately lose me as a user :-)
First, --first-parent is actually how git-svn looks for the
git-svn-id, and any other search is liable to turn up wrong results.
See working_head_info in git-svn.perl.
Second, the behaviour of git-svn with merges is very useful and
well-defined. (Yes, there are stern warnings in the manpage, but if
you know what you're doing just ignore them...)
'git svn dcommit' will first determine the correct upstream branch
according to the above logic, i.e., it *always* commits to the
first-parent ancestry. Then it commits the diff along this line of
history (i.e., always diffing to the first parent) but it does rewrite
the commits so that merges are preserved.
In pictures, if you have
o---B---o---o---o trunk
\
*---*---*---* topic
and run 'git checkout trunk; git merge topic; git svn dcommit' you get
o---B---o---o---o---M' trunk
\ /
*---*---*---* topic
(writing M' since this is already the rewritten version of an original
merge M). M' looks to SVN like a 'git merge --squash topic' because
git-svn doesn't (yet?) store the merge info.
So you get to keep the git merge info, which is very useful for later
merges of 'topic'.
Note: NEVER run 'git checkout topic; git merge trunk'. git-svn will
think (because of the first-parent rule) that you want to commit on
top of B! I don't know what happens next but I expect it won't be too
pretty.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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