Question

I’m having a couple of branches, corresponding with abandoned or later postponed development, some of them are pure garbage. I use

git log master..mybranch

to find out what’s mybranch all about, but the lists are usually needlessly long, since they contain also commits contained in master, just in a different order. This comes from master having been rebased.

When I try to rebase mybranch on top of master, I get conflicts caused by this reordering. Such conflicts are not worth resolving, as it takes time and leads to a result already known from master.

So what I need is a way to get rid of such commits in mybranch, so that only the important commits remains and the branch can be rebased more easily.

Answer 1

I think what you are looking for is git cherry. This generates sha1 values from the commit body rather than using the git commit id to compare commits. This makes it independent of the commit ordering. You use it to find commits which might be worth adding from one branch to another.

An example from the msysGit development tree might help. We have an old branch ‘work/symlink’ which may have been merged to the ‘devel’ branch sometime past. So:

pt111992@UKNML4132 /git (devel)
$ git cherry devel origin/work/symlink
+ 7fe3fde1d9b93472faeedb75bfd930825a5abe06
- aebecb0d31e4a546cf4d21d32e82cc852b6057bb
+ 1b467d086fd6601cd2feb34d59baf1e804f70acb
+ 3e735a0bfda6b91ae7cbb20c2c89818405c5bea9
+ d4db723c482ba4d2fd7539060834d231c35cdf53

This says there are 5 commits of interest (which we can also work out from the log output):

$ git  log --oneline devel..origin/work/symlink
d4db723 Place __stdcall between return value and function name
3e735a0 mingw.c: Use the O_BINARY flag to open files
1b467d0 Test for WIN32 instead of __MINGW32_
aebecb0 Define SNPRINTF_SIZE_CORR=1 for Microsoft Visual C++
7fe3fde Support UTF8<=>Unicode filename mapping

Thats the commits present on ‘work/symlink’ and not on ‘devel’. The git cherry output suggests that the aebecb0 commit is already applied to ‘devel’ (from the leading minus) but the others might be worth looking into. We can check that this commit is only present on the work branch:

$ git branch --all --contains aebecb0
  remotes/origin/work/symlink

but we can also find the commit id it got merged into the devel branch with by searching for the commit message using git log --crep to see that this one was really picked into devel.