Re: Best practices for bisecting GRUB and cherry-picking?

[Jonathan McCune]

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="address@hidden"

export GIT_COMMITTER_NAME="User Name"

export GIT_COMMITTER_EMAIL="address@hidden"

' 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 <address@hidden> 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
address@hidden
https://lists.gnu.org/mailman/listinfo/grub-devel