If you're just trying to identify where the problem was introduced, and don't mind working from a cloned repository, you can use git's "filter-branch" to rewrite a clone of the repo to be as though the Changelog file never existed.
git clone git://git.savannah.gnu.org/grub.git grub-upstream git clone grub-upstream grub-no-changelog cd grub-no-changelog git filter-branch -d /dev/shm/git --index-filter "git rm -qrf --cached --ignore-unmatch ChangeLog" --prune-empty HEAD Hrmmm.. that failed thusly: Rewrite 21b9992685e4fa58f818610b6b13c22cb2f85ec7 (2966/8756)fatal: empty ident name (for <>) not allowed could not write rewritten commit I don't have time to hunt it down (and it is likely not of interest to you, but rather to the upstream maintainers), but further clobbering history we can just trample the author names. Starting over: git clone git://git.savannah.gnu.org/grub.git grub-upstream git clone grub-upstream grub-no-changelog cd grub-no-changelog git filter-branch -d /dev/shm/git --env-filter ' export GIT_AUTHOR_NAME="User Name" export GIT_AUTHOR_EMAIL="em...@example.com" export GIT_COMMITTER_NAME="User Name" export GIT_COMMITTER_EMAIL="em...@example.com" ' HEAD git filter-branch -f -d /dev/shm/git --index-filter "git rm -qrf --cached --ignore-unmatch ChangeLog" --prune-empty HEAD You now have a repo with no ChangeLog file, so bisecting should be easier. Here's a more in-depth explanation of how this kind of thing really works: http://jonmccune.wordpress.com/2012/06/17/code-release-history-and-aesthetics-with-git-filter-branch-and-friends/ -Jon On Thu, Nov 6, 2014 at 6:38 AM, Lennart Sorensen < lsore...@csclub.uwaterloo.ca> wrote: > On Thu, Nov 06, 2014 at 08:01:14AM +0100, Paul Menzel wrote: > > Dear GRUB folks, > > > > > > trying to a bisect a regression of AHCI on the ASRock E350M1 with > > coreboot and GRUB as firmware, `ChangeLog` poses a problem when > > resetting to an older commit and then cherry-picking certain commits to > > fix other problems. The problem is that of course conflicts are shown. > > > > Do you know how to circumvent that to avoid manually resolving the > > conflicts? > > Changelog entries should NEVER be part of the code commit since it forces > your commits to only be able to applied in one order. And the git log > should already be your changelog so the changelog serves no purpose > other than to make life difficult for people. > > Same goes for version numbers in source files. > > -- > Len Sorensen > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel >
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
