Re: [PATCH] bash completion: Support "unpushed commits" warnings in __git_ps1

From: Thomas Rast <trast@student.ethz.ch>
Date: Jun 7, 2010, 07:42 UTC
Message-ID: <201006070942.34753.trast@student.ethz.ch>
In-Reply-To: <4C0C09BF.4070503@pileofstuff.org>

Andrew Sayers wrote:

Show 6 quoted lines

> 
> 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.

Show 8 quoted lines

> > 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