top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How to delete a commit in GIT?

+2 votes
916 views

Can someone help me on how to delete an intermediate commit?

posted Dec 19, 2013 by Sheetal Chauhan

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

2 Answers

+2 votes

git reset --hard HEAD is great if you want to get rid of WORK IN PROGRESS. It will reset you back to the most recent commit, and erase all the changes in your working tree and index.

answer Dec 19, 2013 by Satyabrata Mahapatra
0 votes

Suppose you have following commits( say 'a',' b', 'c', 'd') And you are now at 'd'. You want to delete the commit 'b'.
First take the new branch from 'a'

git checkout 'a' -b newBranch
Now you can cherry pick 'c' , 'd' and can just avaoid 'b'
git cherry-pick 'c' 'd'

Now the new branch doesn't contain your commit 'b'.

answer Jun 12, 2014 by Sanjeet Kumar
Similar Questions
0 votes

There are shorthands for going back from HEAD, but not for the initial commit, AFAICT.

I often want to do this when rebasing, and have come to tagging the initial commit in my repos with INITIAL.

Is there a better syntax I'm missing?

+1 vote

I have many commits: A, B, C, ..., Z. I plan to do some housekeeping using rebase. One thing I want to do is to reorder Z to be the first commit. However, other commits will be in conflict with Z's changes. I know I can go through and interactively resolve the conflicts manually. But this is tedious and error prone. I would like to be able to mark Z's changes as authoritative while rebasing. That is, I want to tell git, "whenever a commit conflicts with Z (during this rebase operation) I want you to keep Z's changes and ignore the other." Is this possible? Is there another (hopefully better) way to accomplish what I'm trying to do?

+2 votes

In coreboot we try to check for whitespace errors before committing. Of course a pre-commit hook is the way to go, but unfortunately it is not so simple (at least for me) as the following requirements exist.

  1. Only the files actually committed should be checked. That means running git commit -a, abort that and then running git commit some/file should only check some/file for whitespace errors.

  2. There are certain files that are allowed to have whitespace errors. In our case these are *.patch and *.diff files which by design seem to contain whitespace error.

Currently the whole tree is checked, which takes a lot of time. I tried to come up with a patch, but failed so far. Best would be to have

$ git diff --check --only-committed-files --exclude "*patch$"

where I could not find a way for the last to switches.

Currently, I would use

$ git diff-index --cached --name-only $against -- | grep -v patch$

and pass that list to some whitespace check program. Unfortunately that still does not fulfill the first requirement. What am I missing to solve this elegantly?

+1 vote

We're attempting to write some scripts to perform automatic commits for certain files under certain conditions. We wish to use the just committed revision number to perform some other logging operation. The --xml command line option on many of the other commands (info, status, etc.) are fantastic, but the commit command does not allow this.

I'm currently attempting to parse the standard output of the commit message to grab it, but feel this is less than optima as it seems very error prone.

Is there any consideration to add an --xml option to the commit command output or a better programmatic means to grab the commit revision?

$ svn commit 1.txt -m "Checkin message". 
Sending 1.txt 
Transmitting file data . 
Committed revision 3272. 
+1 vote

I have two branch in one repository that I need to maintain for 2 different deliveries.
Say branch1 and branch2 in test.git repo.

test.git
- branch1
foo_v1/text.txt
foo_v2/text.txt
- branch2
foo/text.txt

branch1 is developers branch all source looks version'ed manner and branch2 is superset for branch1, example foo_v1 and foo_v2 are the directories in branch1 where developer will update the latest one here foo_v2 and branch2 foo is same as the latest one of branch1 for an instance.

Suppose developer send 10 patches on branch1 where are changes in terms of _/ then I need to apply on my local repo branch1, till now is fine then I need to apply same 10 patches on to my branch2 where source tree which is quite question here how can I do.

...