On 06/06/10 19:14, Thomas Rast wrote:
>
> At least the svn/git setting should definitely be configurable through
> git-config, so that it becomes per-repo configurable. Also, you could
> try to trigger the svn mode by default if a svn-remote.svn.url exists.
>
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. 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.
> How about starting with
>
> git log -1 --first-parent --grep="^git-svn-id: $remote_branch"
>
> which should be faster and is also closer to the truth. It still
> doesn't work if the repo was cloned with --no-metadata. Doing it
> right probably would require a new informational command in git-svn
> that reports the branch name.
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.
I don't see how to actually split out the branch name without calling
sed or using one of the disallowed ${} constructs. So I compared the
following commands on my PC (2.1 GHz dual-core Athlon) using a
repository with 100 empty commits between HEAD and a git-svn-id:
time git log | \
sed -ne "/^ git-svn-id: / { s/^ git-svn-id: "\
"$remote_branch\/\([^@]*\).*/\1/p ; q }"
time git log -1 --grep="^git-svn-id: $remote_branch" | \
sed -ne "s/^ git-svn-id: $remote_branch\/\([^@]*\).*/\1/p"
The former averaged about 0.017 seconds, whereas the latter averaged
about 0.015. So when I resubmit this patch, I'll include your version
if merge commits are somehow useful to SVNers, or a merge warning otherwise.
Incidentally, a quick bit of etiquette - would you rather I submitted an
RFC patch or two with these changes, or wait until the discussion has
reached a more stable point?
- Andrew
--
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