Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>No matter what else happens, if you change something—even a single character in the user name and/or email—in some commit, you get a new, different commit. (This is because the commit ID consists of a crypographic checksum of the contents of the commit. So, OK, if you can break the cryptography, you can come up with two different commits that would have the same ID. But then you've completely broken git, and probably won a Turing award or a Nobel prize too. :-) )</p> <p>The "working hook" you've linked to in comments on another answer is probably your best bet. This problem boils down to one thing: you can't make any changes to a <em>published</em> commit (without causing problems for consumers of that publication), but you can make any changes you want to a <em>private</em> commit as long as you "know what you're doing". Using <code>git commit --amend --author "$user &lt;$email&gt;" -C HEAD</code> on a per-commit basis, as they go in to your copy of the repo, guarantees that you replace an unpublished commit with a new, slightly different unpublished commit. (I assume you have put this in the post-commit hook.)</p> <p>I'm not sure which part you're unhappy with, maybe the <code>[ -n "$richo_git_rewrite" ] &amp;&amp; exit 0</code>? That's a reasonably clever method of detecting recursion. An alternative is to skip the recursion detection, and instead compare the existing user and email in the commit with the desired ones.</p> <p>Here's a script that does that (except I used the env variable SWITCHY=true to do my testing):</p> <pre><code>#! /bin/sh # first, pick which git config variables to get if ${SWITCHY-false}; then config=user.work else config=user fi # next, find out if they're set can_rewrite=false target_author=$(git config --get $config.name) &amp;&amp; target_email=$(git config --get $config.email) &amp;&amp; can_rewrite=true # If they ARE set, we can "rewrite" (replace) the commit; # if not, we can't. Just because we can, though, does not # mean we should. Find out if the current author and email # differ from the desired ones. if $can_rewrite; then current_author=$(git log --pretty=format:%an HEAD -n 1) current_email=$(git log --pretty=format:%ae HEAD -n 1) if [ "$current_author" != "$target_author" -o \ "$current_email" != "$target_email" ]; then # may want --allow-empty here, if you're allowing empty commits # at all, otherwise empty ones don't get the rewrite done git commit --amend --author "$target_author &lt;$target_email&gt;" -C HEAD fi fi </code></pre> <p>Note: you'll need to set this same hook in <code>hooks/post-merge</code>, to get amended merges with the updated name-and-email. And of course you can simplify the hook a bit (don't need an actual can_rewrite variable, just do the two git config get ops with <code>&amp;&amp;</code>s and keep going with another <code>&amp;&amp;</code>). It would also make sense to have more than just user vs user.work, maybe user vs user.ModeA vs user.ModeB, etc., and you can drive it off whatever tests you like (env variables, presence or absence of commands, etc).<hr>OK, per comments, here's a pre-commit hook. Unfortunately it doesn't work with <code>git merge</code> (the pre-commit hook runs and complains and then the merge commit goes in).</p> <pre><code>#! /bin/sh fatal() { echo "$@" 1&gt;&amp;2 exit 1 } # pick which git config variables to get if ${SWITCHY-false}; then config=user.work else config=user fi # tn, te = target author name/email # an, ae = what git will use for author name/email tn=$(git config --get $config.name) || exit 0 te=$(git config --get $config.email) || exit 0 an=${GIT_AUTHOR_NAME-$(git config --get user.name)} || fatal "no author name set" ae=${GIT_AUTHOR_EMAIL-$(git config --get user.email)} || fatal "no author email set" [ "$an" = "$tn" -a "$ae" = "$te" ] || fatal "git will use author $an &lt;$ae&gt; but you want them as $tn &lt;$te&gt; fix your environment variables and try again" </code></pre> <p>You could combine this pre-commit hook with a post-merge rewrite-the-commit hook (<em>eww</em> :-) ). I did not try a conflicted commit but presumably the pre-commit hook would catch conflicted merges that require you to do your own commit.</p> <p>(It's also worth noting that this pre-commit hook does not look at the working tree or index, so it does not have the usual "checking the work tree but committing the index" flaw.)</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to change author email at commit time with hooks
      singulars
      1. PTQuestion
    1. PTAnswer
    1. UStorek
    1. UStorek
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTBountyClose
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COMy issue is with the "commit, test if we need to rewrite, rewrite" pattern. I'd like to just write the commit out as the correct user in the first place, my workflow involves a lot of rebasing and I'd wager that what I have now will bite me in the ass sooner or later. After looking into it further I'd say I'll have to implement it inside git and beg to merge it into the next release. Thanks!
      singulars
      1. PO
      1. USricho
    2. COYou can't *quite* do that, but if you like, you could have a pre-commit hook that checks whether "what git will set" is "what I want it to set". Have the filter grab `$GIT_AUTHOR_NAME` and `$GIT_AUTHOR_EMAIL`, use git config get if they're not set, and then compare them (a la my example post-commit hook) to the "desired" values. If they don't match, exit 1, stopping the commit. (And of course, put this on pretty much pre-everthing.)
      singulars
      1. PO
      1. UStorek
    3. COI hadn't considered that option, just bail if it's wrong.Thanks!
      singulars
      1. PO
      1. USricho
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload