4

Looking at the revision graph provided by Tortoise Git I found a series of commits that all show an orphaned branch being merged into it. A little more investigation showed that the root commit of these orphaned branches was in fact the untracked files commit of some stashes that were merged into our development branch by one of our team members. All of the orphan branches shown in the revision graph were from the same team member so it was clear it was a result of something she was doing in her Git repository management process which appears to have included using the "Merge To " selection from the context menu for a stash shown in the stash list dialog.

I have been searching the interweb for help on how to "remove" or otherwise clean up these untracked file commits from our branch to in turn clean up our revision graph to not show these orphan branches. As of now I haven't been able to find anything. To the best of my determination I cannot see any adverse effects on the actual code base at the branch heads that include these orphan branches but would still like to remove or undo them to clean up the history and view provided by the revision graph. Any suggestions or insight into the situation we have or comment on other possible complications that might stem from it that we haven't considered would be much appreciated.

Tortoise Git revision graph showing orphan branches

thanks for the time, Mike

Mike Long
  • 71
  • 7
  • I had an image of the Tortoise Git revision graph and log view that I wanted to post as support for the question, but I just don't have enough rep to do that yet. I'm a stackoverflow noob and am still trying to figure everything out. – Mike Long Feb 08 '14 at 00:39
  • Did you look into graft points? (http://stackoverflow.com/a/1491057/6309, as used in http://stackoverflow.com/a/21623336/6309) – VonC Feb 08 '14 at 00:42
  • You now have more than 10 reputation, so you may use the upload feature to add an image directly to the post. – poke Feb 08 '14 at 00:44
  • Poke, thank you for the help with the rep points. The image is a little easier to read if it's right clicked and opened in a new tab. – Mike Long Feb 11 '14 at 18:32
  • @MikeLong Are you okay with rewriting history? https://www.kernel.org/pub/software/scm/git/docs/user-manual.html#problems-With-rewriting-history – onionjake Feb 20 '14 at 15:24
  • @onionjake Thanks for the link to this documentation. I was not able to find anything that I could use to "re-write" the history to reove the orphan un-tracked file stash commits. I have a good handle on how to use rebasing and cherry picking to re-write history when we figure it's necessary. Unfortunately the orphan nature of the commits we are trying to deal with is a little different situation as they don't have a parent commit to rebase from and are already merged into the history of our main development branch. I'm just not seeing how to use these tools to get rid of them. – Mike Long Feb 20 '14 at 16:12

1 Answers1

2

WARNING: The following command rewrites history which is most often undesirable on shared repositories. This answer assumes that this is acceptable.

git rebase without --preserve-merges should work great:

Here is how I tested it:

mkdir test_orphan
cd test_orphan/
git init
echo "new file" > file1
git add file1
git commit -m "mainline"
echo "some changes" >> file1
git commit -a -m "some changes"
git checkout --orphan orphan
echo "orphan changes" >> file2
git add file2
git commit -a -m "orphan changes"
git checkout master
git merge orphan
echo "additional changes" >> file1
git commit -a -m "more changes"

That should result in some history like this (git log --decorate --oneline --graph):

* 976e170 (HEAD, master) more changes
*   7bbc2da Merge branch 'orphan'
|\  
| * 4a9d9c0 (orphan) orphan changes
* c2a9ecb some changes
* 1523991 mainline

Now to rebase out those changes:

git rebase 1523991

Results in a tree that looks like this:

* 3b63a46 (HEAD, master) more changes
* c56d554 orphan changes
* daa016c some changes
* 1523991 mainline

How you can apply this to your situation without axing all of your merge commits?

  1. git checkout -b flattening <just after orphaned merge commit>
  2. git rebase <commit before orphaned merge commit>
  3. git checkout master
  4. git rebase -p <just after orphaned merge commit> --onto flattening
onionjake
  • 3,905
  • 27
  • 46
  • 1
    thank you for taking the time to spell this out for me here. I encountered a bit of difficulty in my first attempt to go through this which I think is related to the fact that the merge point where the untracked files orphan commit is injected actually has 3 parents in our situation rather than just the two and one of those parents contains changes we want to maintain, but I think I get the gist of the idea and can try a few things out from here. Gonna be on vacation for the next two weeks and just wanted to assure you your effort wasn't a waste. I'll look at it more when I'm back. – Mike Long Feb 21 '14 at 22:46