Return values from environment for GIT_AUTHOR_* #20

Open
wants to merge 1 commit into
from

Conversation

Projects
None yet
3 participants

hoelzro commented Aug 30, 2012

Some Git users, like myself, prefer to manage the username and e-mail address that Git sees in the environment. git-deploy does not currently respect this; it simply complains that user.name and user.email are not set. This pull request adds the ability to consult the environment variables for those settings.

I don't understand why using git config --global for this is a problem.

I am generally reluctant to add exceptions to the "all config through git" rule that we have in git-deploy. It has proved to be a really good decision so far.

Can you explain why you this using the environment variable is better than using git-config?

Owner

avar commented Sep 1, 2012

I like this conceptually, git-deploy only cares that you set your username and E-Mail, but it shouldn't try to enforce one particular way of doing so when Git support multiple ways of doing it.

But I thought hooking into the low-level config mechanism to support this was a bit hacky, so I wrote dc4541f as an alternative. Would that do what you wanted to do Rob, and does anyone else like that patch better?

hoelzro commented Sep 1, 2012

@avar That implementation looks fine to me; I didn't care for the "special case" nature of my patch, but I just wanted to get it done. I considered using git-var, but that involved some extra parsing of a format that may change in the future.

hoelzro commented Sep 1, 2012

@demerphq The reason I use an environment variable instead of git-config is because I have all of my dotfiles in a Git repository, but I want commits made at work to show up with my work e-mail, and commits made for personal projects to show up with my personal e-mail. I could use Git's include configuration feature, but this is relatively new and not available in some versions of Git (like some boxes we have at work). I think it makes sense for git-deploy to support the environment variables because Git itself does.

Owner

avar commented Sep 1, 2012

@hoelzro Actually I can't even get this to work, I pushed an updated
version as 61e0054 but I can't get the created tags to have the author
info specified in the environment variables when creating tags. This
seems to be a limitation in git. See http://article.gmane.org/gmane.comp.version-control.git/204635

So it seems to me that this whole approach is inherently broken until such time as git-tag itself is patched to accept these environment values.

Otherwise all the stuff git-deploy will create on your behalf won't have this author info.

hoelzro commented Sep 1, 2012

@avar Shouldn't you be grepping for 'Tagger' rather than 'Author' in git --no-pager show tag-name-1 | grep ^Author? Author is the identity of the person who created the commit that the tag is pointing to; Tagger is the identify of the person who created the tag itself.

Owner

avar commented Sep 1, 2012

@hoelzro I got the grep wrong but it doesn't set the tagger either, see my reply in the git mailing list thread.

hoelzro commented Sep 1, 2012

I see; that makes sense. I set GIT_COMMITTER_* in my environment as well; is there a way we can get git-deploy to pick those up?

Owner

avar commented Sep 1, 2012

@hoelzro It picks up GIT_COMMITTER_{NAME,EMAIL}, but then this is getting a bit tricky. With just user.{name,email} set in the config we could guarantee that everything we have for both commits and tags had the right info.

With the env vars you have to ensure that all of GIT_{AUTHOR,COMMITTER}_{NAME,EMAIL} are set, and maybe we should even check that they're all set to the same thing.

Maybe you could hack up the WIP patch I had with the tests to do something like that?

hoelzro commented Sep 2, 2012

@avar Done! Please see #21.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment