Asked  7 Months ago    Answers:  5   Viewed   30 times

The answers to How to modify existing, unpushed commits? describe a way to amend previous commit messages that haven't yet been pushed upstream. The new messages inherit the timestamps of the original commits. This seems logical, but is there a way to also re-set the times?

 Answers

27

Use git filter-branch with an env filter that sets GIT_AUTHOR_DATE and GIT_COMMITTER_DATE for the specific hash of the commit you're looking to fix.

This will invalidate that and all future hashes.

Example:

If you wanted to change the dates of commit 119f9ecf58069b265ab22f1f97d2b648faf932e0, you could do so with something like this:

git filter-branch --env-filter 
    'if [ $GIT_COMMIT = 119f9ecf58069b265ab22f1f97d2b648faf932e0 ]
     then
         export GIT_AUTHOR_DATE="Fri Jan 2 21:38:53 2009 -0800"
         export GIT_COMMITTER_DATE="Sat May 19 01:01:01 2007 -0700"
     fi'
Tuesday, June 1, 2021
 
peixotorms
answered 7 Months ago
20

knittl has already compiled a good list of the commands that rewrite history, but I wanted to build upon his answer.

Can you provide a list of [...] the operations or commands that can compromise the history in git? What should be absolutely avoided?

First of all, there is nothing wrong with rewriting/deleting history per se; after all, you probably routinely create feature branches, keep them strictly local, then delete (after merging them or realising they lead you nowhere) without thinking twice about it.

However, you can and certainly will run into problems when you locally rewrite/delete history that other people have already access to and then push it to a shared remote.

Operations that should count as rewriting/deleting the history of a local repo

Of course, there are dumb ways of corrupting or deleting history (e.g. tampering with the contents of .git/objects/) , but those are outside the scope of my answer.

You can rewrite history of a local repo in various ways. The section of the Pro Git book entitled Rewriting history, mentions a few

  • git amend --commit
  • git rebase
  • git filter-branch
  • Roberto Tyley's BFG Repo Cleaner (a 3rd-party tool)

Arguably, there are more. Any operation that has the potential to alter or otherwise move a non-symbolic reference (branch or tag) and make it point to a commit that is not a descendant of the branch's current tip should count as rewriting local history. This includes:

  • git commit --amend: replaces the last commit;
  • All forms of rebase (incl. git pull --rebase);
  • git reset (see an example below);
  • git checkout -B and git branch -f: resets an existing branch to a different commit;
  • git tag --force: recreates a tag with the same name but potentially pointing to another commit.

Any deletion of a non-symbolic reference (branch or tag) may also be considered history deleting:

  • git branch -d or git branch -D
  • git tag -d

Arguably, deleting a branch that has been fully merged into another should be considered only a mild form of history deleting, if at all.

Tags are different, though. Deleting a lightweight tag is not such a big deal, but deleting an annotated tag, which is a bona fide Git object, should count as deleting local history.

Operations that rewrite/delete the history of a remote repo

As for as I know, only a git push -f (equivalent to git push --force) has the potential to rewrite/delete history in the remote repository.

That said, it is possible to

  • disable the ability to force-update remote branches to non-fast-forward references, by setting receive.denyNonFastForwards on the server.
  • disable the ability to delete a branch living on a remote repository, by setting receive.denyDeletes on the server.

Moreover I use git reset a lot, but am not completely aware of the possible damage I could do to the repository (or to the other contributors copies). Can git reset be dangerous?

git-reset, as mentioned by knittl, usually changes where a branch reference points. This command can be dangerous, in so far as it can make reachable commits become unreachable. Because a picture speaks a thousand words, consider the following situation:

enter image description here

You're on the master branch, which points at commit D. Now, let's say you run, for instance,

git reset master~2

A soft reset is considered to be the most benign form of reset, because it "only" changes where the current branch points to, but doesn't affect the staging area or your working tree. That said, merely changing where a branch points to in that fashion has ramifications: after that soft reset, you will end up with

enter image description here

Commits C and D, which were reachable from master before the reset, have now become unreachable; in other words, they're not ancestors of any reference (branch, tag, or HEAD). You could say that they're in "repository limbo"; they still exists in your Git repo's object database, but they will no longer be listed in the output of git log.

If you actually found those commits valuable before the reset, you should make them reachable again by making some reference (e.g. another branch) point to commit D again. Otherwise, commits C and D will end up dying a true death when Git runs its automatic garbage collection and deletes unreachable objects.

You can, in theory, fish commit D out of the reflog, but there is always a risk that you will forget about those unreachable commits or won't be able to identify which entry of the reflog corresponds to commit D.

In conclusion, yes, git-reset can be dangerous, and it's a good idea to make sure the current tip of the branch you're about to reset will remain reachable after the reset. If needed, create another branch there before the reset, just in case, as a backup; and if you're sure you want to forget those commits, you can always delete that branch later.

Tuesday, June 1, 2021
 
Naveen
answered 7 Months ago
63

Add these lines to your ~/.bashrc, ~/.bash_profile or ~/.zprofile to force git to display all messages in English:

# Set Git language to English
#alias git='LANG=en_US git'
alias git='LANG=en_GB git'

The alias needs to override LC_ALL on some systems, when the environment variable LC_ALL is set, which has precedence over LANG. See the UNIX Specification - Environment Variables for further explanation.

# Set Git language to English
#alias git='LC_ALL=en_US git'
alias git='LC_ALL=en_GB git'

In case you added these lines to ~/.bashrc the alias will be defined when a new interactive shell gets started. In case you added it to ~/.bash_profile the alias will be applied when logging in.

Saturday, July 10, 2021
 
uiroshan
answered 5 Months ago
75

The solution is simple:

git filter-branch [options] -- --all

Note the four dashes (two sets of double dashes with a space in between) in -- --all.

If you look at the docs for git-filter-branch, it says this:

git filter-branch [--env-filter <command>] [--tree-filter <command>]
    [--index-filter <command>] [--parent-filter <command>]
    [--msg-filter <command>] [--commit-filter <command>]
    [--tag-name-filter <command>] [--subdirectory-filter <directory>]
    [--prune-empty]
    [--original <namespace>] [-d <directory>] [-f | --force]
    [--] [<rev-list options>…]

Reading on, the beginning of the docs say: "Lets you rewrite git revision history by rewriting the branches mentioned in the <rev-list options>, applying custom filters on each revision."

So checking the docs for rev-list gives:

< rev-list options >… Arguments for git rev-list. All positive refs included by these options are rewritten. You may also specify options such as --all, but you must use -- to separate them from the git filter-branch options.

And the docs for git-rev-list say:

--all
Pretend as if all the refs in refs/ are listed on the command line as <commit>.
Sunday, July 11, 2021
 
Zigglzworth
answered 5 Months ago
72

To rebound on the sub-question: is there a git commit --amend for a previous commit (and not just the last one), you could try something like (not tested yet, but Colin O'Dell mentions in the comments having written a script for it colinodell/git-amend-old):

git checkout -b tmp
git reset --hard HEAD~2
git commit -amend 
git rebase --onto tmp HEAD@{1} master

That would be like:

x---x---x---x---x
                ^
                |
               (master*) (* = current branch)

git checkout -b tmp
x---x---x---x---x
                ^
                |
               (tmp*, master) 

git reset --hard HEAD~2
x---x---x---x---x
        ^       ^
        |       |
      (tmp*) (master) 

git commit -amend 
      y (tmp*) 
     /
x---x---x---x---x
        |       ^
   (HEAD@{1})   |
          (master) 

git rebase --onto tmp HEAD@{1} master
    (tmp)
      y---x'---x' (master*) 
     /
x---x---x---x---x (only referenced in reflog)
Tuesday, September 21, 2021
 
Bruno Reis
answered 3 Months ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :
 
Share