Best practices for bisecting GRUB and cherry-picking?

Best practices for bisecting GRUB and cherry-picking?

[Paul Menzel]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

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?


Thanks,

Paul

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

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

[Lennart Sorensen]

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

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

[Jonathan McCune]

[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]

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="email@example.com"
export GIT_COMMITTER_NAME="User Name"
export GIT_COMMITTER_EMAIL="email@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 <
lsorense@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
>

[-- Attachment #2: Type: text/html, Size: 4256 bytes --]