1

I've still got my GIT training wheels on and I recently had a bit of a stack. It's no big deal, but I think it presents an interesting problem to solve. If you take a quick look at the following pick, you can see that the commit where the FluentValidationTrial branch is pointing just kinda stops:

enter image description here

That happened when I was playing around with rebase -i. The history should show no divergence i.e. commit d7d9b1e should follow d2044a6.

Does anyone know how I can clean that up? Should be interesting. Cheers

onefootswill
  • 3,707
  • 6
  • 47
  • 101

2 Answers2

2

While you have the branch develop checked out, simply do a rebase -i on top of FluentValidationTrial:

git checkout develop
git rebase -i FluentValidationTrial

Then drop any duplicate entries in the commits.

The other alternative is to go to git reflog, and restore a rebased branch on its past SHA1.
(As in "undoig a rebase")

But do use Git 2.27 (Q2 2020), as before that, "git rebase -i" did not leave the reflog entries correctly.

See commit 1f6965f (07 Apr 2020) by Elijah Newren (newren).
(Merged by Junio C Hamano -- gitster -- in commit 3aa30cc, 22 Apr 2020)

sequencer: honor GIT_REFLOG_ACTION

Signed-off-by: Elijah Newren

There is a lot of code to honor GIT_REFLOG_ACTION throughout Git, including some in sequencer.c; unfortunately, reflog_message() and its callers ignored it.

Instruct reflog_message() to check the existing environment variable, and use it when present as an override to action_name().

Also restructure pick_commits() to only temporarily modify GIT_REFLOG_ACTION for a short duration and then restore the old value, so that when we do this setting within a loop we do not keep adding " (pick)" substrings and end up with a reflog message of the form

rebase (pick) (pick) (pick) (finish): returning to refs/heads/master
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Not sure what to do in VIM here. I just accepted the stuff that appeared on running the rebase and all it did was move the HEAD pointer to d2044a6. I think I need to reset HEAD. I can be cavalier with what I try as I have backed up the whole repository. – onefootswill May 05 '14 at 09:34
  • 1
    @onefootswill what did you see in VIM? You should be able to replace the 'pick' by 'drop' on the lines you don't want, and generally to reorder commits. – VonC May 05 '14 at 09:35
  • I'm going to blow away that repo and grab a copy from backup because that last opn completely ruined it. It now thinks there's a branch called develop|REBASE-i – onefootswill May 05 '14 at 09:45
  • [This](http://i167.photobucket.com/albums/u122/sixesallround/wronger_zpsf0ff6116.png) is what I see – onefootswill May 05 '14 at 09:50
  • 1
    @onefootswill: git has detected that some commits on `develop` introduce the same changeset as commits already present in `FluentValidationTrial`. If such is the case, he has already removed the duplicates : you only see the 5 commits starting from `Further work on the validation ...` – LeGEC May 05 '14 at 09:55
2

It looks like develop is already a rebased version of FluentValidationTrial, starting from a6afd1b.

Check if the two commits tagged Further work on the validation ... have the same content :

git diff 08dd217 d2044a6

then you can probably drop FluentValidationTrial :

git branch -d FluentValidationTrial
# After that, if you want to a branch named FluentValidationTrial
# pointing at 08dd217 :
git branch FluentValidationTrial 08dd217
LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Ah I see. That branch's history in already in the develop branch. I'll go ahead with that suggestion. – onefootswill May 05 '14 at 09:56
  • The diff showed they were the same. I think that has cleaned it up. Only comment is that I had to use a capital D flag to force the deletion. Not sure why as there was nothing to commit. Not in staging or unstaged. But clean history now. Thanks. – onefootswill May 05 '14 at 10:09