list mirror (unofficial, one of many)
 help / color / Atom feed
From: Andreas Heiduk <>
To: Eric Wong <>
Cc:, Eric Sunshine <>
Subject: Re: [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file
Date: Mon, 19 Mar 2018 23:48:15 +0100
Message-ID: <> (raw)
In-Reply-To: <>

Am 19.03.2018 um 00:04 schrieb Eric Wong:
> Andreas Heiduk <> wrote:
>> The email address in --authors-file and --authors-prog can be empty but
>> git-svn translated it into a syntethic email address in the form
>> $USERNAME@$REPO_UUID. Now git-svn behaves like git-commit: If the email
>> is explicitly set to the empty string, the commit does not contain
>> an email address.
> What is missing is WHY "<>" is preferable to "<$USERNAME@$REPO_UUID>".
> $USERNAME is good anyways since projects/organizations tie their
> SVN usernames to email usernames via LDAP, making it easy to
> infer their email address from $USERNAME.  The latter can also
> be used to disambiguate authors if they happen to have the same
> real name.

That's still available and it's even still the default.

But: If the user of git-svn takes the burden of writing an authors
script or maintaining an authors file then he should have full control
over the result as long as git can handle the output reasonably.
Currently that's the case for git but not for git-svn.

Git can handle empty emails quite nicely:

    > git -c commit --allow-empty -m "foo"
    > git show --format=raw HEAD | egrep "author|committer"
    author jondoe <> 1521495217 +0100
    committer jondoe <> 1521495217 +0100

Doing the same with current git-svn requires a filter-branch followed
by `rm -r .git/svn/`  followed by `git svn fetch` to recreate the
rev_map files. That would be feasible for a one-time conversion but
not in a situation where SVN is live and the master repository.

> "<>" is completely meaningless.

Not quite. The "<>" is not the only information - there is still the
mandatory "name" part. So the commit id

    jondoe <>

just means: "There is intentionally no email address." For an
internal, ephemeral repository that can be OK. It has the advantage,
that no automatic system (Jira, Jenkins, ...) will try to send emails to 

    jondoe <jondoe@6aafaa21e0fb4338a68ab372a049893d>

Additionally the log output isn't cluttered with irrelevant stuff. :-)

And last but not least we don't have to hunt down names long gone by and
already deleted in LDAP. In that case the UUID doesn't help either.

Further steps: Eric Sunshine mentioned [1] that you might have concerns about
the change of behavior per se. For me the patch is not so much a new feature but
a bugfix bringing git-svn in sync with git itself. Adding an option parameter 
to enable the new behavior seems strange to me. But there might be other ways
to achieve the same effect:

- changing the output format of the file and prog: empty emails could be 
  marked by a syntax which is invalid so far.

- OR (if some change of behaviour is acceptable) the script could evaluate
  a new environment variable like GIT_SVN_UUID to compose the 
  `<$user@$uuid>` part itself.

- OR just mention it in the relaese notes ;-)

- OR [please insert ideas here]


  reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2018-03-11 13:58 ` [PATCH v2 0/2] git-svn: --author-prog improvements Andreas Heiduk
2018-03-18 21:19   ` Andreas Heiduk
2018-03-18 21:31     ` Eric Sunshine
2018-03-11 13:58 ` [PATCH v2 1/2] git-svn: search --authors-prog in PATH too Andreas Heiduk
2018-03-11 13:58 ` [PATCH v2 2/2] git-svn: allow empty email-address in authors-prog and authors-file Andreas Heiduk
2018-03-18 23:04   ` Eric Wong
2018-03-19 22:48     ` Andreas Heiduk [this message]
2018-03-20 22:07       ` Eric Wong
2018-03-24 10:20         ` [PATCH v3] git-svn: allow empty email-address using " Andreas Heiduk
2018-04-05  7:51           ` Eric Wong
2018-04-05 18:23             ` Andreas Heiduk
2018-04-05 19:44               ` Eric Wong
2018-04-11 23:18                 ` Junio C Hamano

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:

  List information:

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

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone