top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

Can we mark a commit as authoritative in interactive rebase in Git?

+1 vote
381 views

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?

posted Sep 13, 2013 by Naveena Garg

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

1 Answer

+1 vote

I am not very sure, but I think you can use the option strategy to what you want. Reading the documentation, it says "using the ours strategy simply discards all patches from the , which makes little sense". So, I think you can use it to discard all changes from the other commits. It is just a guess.

answer Sep 13, 2013 by Anderson
Similar Questions
0 votes
Is there a short-hand for referring to the first commit in Git?

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?

+2 votes
How to delete a commit in GIT?

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

+2 votes
Git: Looking for pre-commit hook to check whitespace errors but not for all files

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
Programatically determine revision of commit of GIT

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
Merge commits in GIT

I have a question about merge commits. Now when I perform git pull from somebody. Sometimes I'm getting a merge commit where I should write a merge commit message. Sometimes it does not happen, I just hit the git pull and it pulls the updates without creating a merge commit.

What is the difference? note that the files modified in the new commit -when getting a merge commit- are only maintained by a single user. And how can I avoid these merge commits as long as the file is maintained by one user ?

...