CODEWITHSUNDEEP
gitgithub
notADevYet
notADevYet

Reputation: 327

Change commit's author using Interactive Rebase. Unmerged Paths

Newbie here. In my private Repository (only user) I am trying to change the author name and email from previous commits (I had a generic email address configured in GIT, therefore Github is not crediting me the contributions in the calendar).

After some reading, and in order to try with just some commits, I was using

git rebase --interactive HEAD~<commit number>

I changed the author name and email in the Text editor by doing

exec git commit --amend --author="newName <newEmail>" -C HEAD

under the commits I wanted to modify, and saved.

After that, I tried git --rebase continue and got this :

src/App.js: needs merge src/components/Navbar.js: needs merge src/components/auth/Login.js: needs merge You must edit all merge conflicts and then mark them as resolved using git add.

Now I have unmerged paths, and I really don't know how I should proceed in order to solve the merge conflict.

There is just one main branch - git status right now is like this:

interactive rebase in progress; onto 1f3deaf
Last commands done (10 commands done):
   pick 930c285 themecontext added
   pick b454a88 login/register added
  (see more in file .git/rebase-merge/done)
No commands remaining.

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

Unmerged paths:
  (use "git add <file>..." to mark resolution)

    both modified:   src/App.js
    both added:      src/components/Navbar.js
    both added:      src/components/auth/Login.js

no changes added to commit (use "git add" and/or "git commit -a")

Any idea on how I should proceed?

Upvotes: 0

Views: 369

Answers (3)

torek
torek

Reputation: 488103

If your goal is to replace bad commits with new-and-improved commits (and it is in this case), there are three tools to consider these days:

  • git rebase: the one you're attempting to use.
  • git filter-branch: this one is officially deprecated, but its replacement is not yet officially supported.
  • git filter-repo: this is the upcoming replacement for git filter-branch.

The problem with using git rebase for this job is that git rebase itself is a bit limited (on purpose because some of the things you might want to do were downright hard). In modern Git, some of these limitations have been lifted (because rebase is now smarter): rebase now has --rebase-merges, provided your Git is new enough. I'll call the older rebase "naïve rebase".

If there are merge commits in the commits you'd like to replace, you cannot use a naïve rebase to accomplish this, because naïve rebase cannot copy merges. So you'll have to use --rebase-merges, to do this with rebase. (The rest you can do as you are attempting.)

Based on your merge conflicts, I believe that there are merge commits in the commits you'd like to rebase. That in turn suggests that maybe you should use filter-branch or filter-repo instead, as these commands are more capable (though more difficult to use correctly).

To see if there are merge commits, use git log --graph, or any of the various graphical viewers as described in Pretty Git branch graphs (or use git log --merges or other techniques, but in general, start with a graph-oriented view). Then decide whether you want to continue down this path, using git rebase with --rebase-merges if needed, or switch to one of the alternatives.

Upvotes: 1

notADevYet
notADevYet

Reputation: 327

a silly as it might sound, git rebase --skipdid it ...

Upvotes: 1

wojand
wojand

Reputation: 190

I found some resource (the interactive rebase section): https://www.git-tower.com/learn/git/faq/change-author-name-email/

The unmerged paths thing means that you have conflicts to resolve -- I assume here that you know how they work usually, and how to fix them if the conflict is in the files (as opposed to conflict of authors) and it's not the problem.

So... I believe you could abort the rebase, and follow the instructions I linked above.

Interesting thing is that the docs (https://git-scm.com/docs/git-rebase) say that combining -i and -p options is generally not a good idea (look at --preserve-merges), but in this case it's not bad as it's a simple rebase (the BUGS are generally related to counter-intuitive results of changing the order of commits or structure of the tree) and following instructions from the article counts as knowing what you're doing. At least I think so. I'm not a git veteran so... I just found some resource on the Internet.

These options are even incompatible, but it looks like they can be used together (hmm...? somehow?) if you know what you're doing.

Upvotes: 2

Related Questions