Re: Suggestion for cherry-picking to stable branches
Bruno Haible writes: > Sam James wrote: >> It's metadata in addition to the >> commit summary (matching based on a title isn't easy, it's way easier if >> someone says "here's the commits it's based on"; one can give multiple >> such lines). > > It would significantly increase the amount of work for maintaining a stable > branch. No, thanks. Sure, no worries. I wasn't aware of your workflow and just wanted to make the suggestion. > >> it makes life far easier if investigating a bug. > > The way I check whether a certain bug fix is present is > 1. to get the fix from master, > 2. find a particular code line / hunk that is essential for the fix, > 3. look if this change is present in the branch. > > This is more reliable than to look at the git log or ChangeLog, because > when a patch has not been applied correctly in the branch (due to > rejects, maybe) there is a mismatch between the advertised list of fixes > and the actual list of fixes. Thanks! best, sam
Re: Suggestion for cherry-picking to stable branches
Sam James wrote: > It's metadata in addition to the > commit summary (matching based on a title isn't easy, it's way easier if > someone says "here's the commits it's based on"; one can give multiple > such lines). It would significantly increase the amount of work for maintaining a stable branch. No, thanks. > it makes life far easier if investigating a bug. The way I check whether a certain bug fix is present is 1. to get the fix from master, 2. find a particular code line / hunk that is essential for the fix, 3. look if this change is present in the branch. This is more reliable than to look at the git log or ChangeLog, because when a patch has not been applied correctly in the branch (due to rejects, maybe) there is a mismatch between the advertised list of fixes and the actual list of fixes. Bruno
Re: Suggestion for cherry-picking to stable branches
Bruno Haible writes: >> > easy to compare with the original commit and distinguish >> > branch-only commits from backports. > > You can get limited insights by comparing the ChangeLogs of the > master branch with a stable branch. > > But if what you want is a mechanically verifiable assertion of > any kind, I can tell you that none exists. Backporting patches > is, ultimately, manual developer work. (This is obvious by the > fact that developers who have to maintain 6 or 7 backport branches > spend a *lot* of time on that.) You may trust or may not trust > this developer work, but there is no mechanical way to prove > that you can trust it. I wasn't asking from a perpective of auditing, more that it makes life far easier if investigating a bug. It's metadata in addition to the commit summary (matching based on a title isn't easy, it's way easier if someone says "here's the commits it's based on"; one can give multiple such lines). If it's not easy for you to add that metadata with your workflow, that's fine, of course. thanks, sam
Re: Suggestion for cherry-picking to stable branches
Sam James wrote: > The expectation isn't that it directly matches the 'cherry-picked from > ...' commits, but rather that it gives some anchor to compare to / > expresses intent, rather than having to compare just the commit summary > (as those aren't unique). You can get such an "anchor" (a) by using fuzzy-compare on the 'git log' entries, or (b) by doing a side-by-side diff of the ChangeLogs, followed by a "git annotate" of matching ChangeLog entries. Bruno
Re: Suggestion for cherry-picking to stable branches
> > easy to compare with the original commit and distinguish > > branch-only commits from backports. You can get limited insights by comparing the ChangeLogs of the master branch with a stable branch. But if what you want is a mechanically verifiable assertion of any kind, I can tell you that none exists. Backporting patches is, ultimately, manual developer work. (This is obvious by the fact that developers who have to maintain 6 or 7 backport branches spend a *lot* of time on that.) You may trust or may not trust this developer work, but there is no mechanical way to prove that you can trust it. Bruno
Re: Suggestion for cherry-picking to stable branches
Bruno Haible writes: > Sam James wrote: >> Could I propose that cherry-picks to the stable-XXX branches are done >> with 'git cherry-pick -x'? This is often done in projects following a >> gnulib-like model. >> >> git will append '(cherry picked from commit ...)' to the commit message >> which makes it easy to compare with the original commit and distinguish >> branch-only commits from backports. > > All commits to the stable branches [1] are backports. There are no commits > that are created for the branch specifically. > > But while doing these backports, I have to make several adjustments: > - Combine 2 or more commits from 'master' if the first of these commits > introduced a regression that was only fixed later on. > - Assign new '# serial' numbers to the *.m4 files. > - Omit modifications to modules that did not exist when the stable branch > was forked off. > - Omit documentation changes that don't apply. > - Fix merge conflicts. > - For stable branches from the previous year: Update the (C) year > of each modified file. > > I don't think that a tool like 'git cherry-pick' will allow me to have > the needed flexibility for this process. Ah, so, in a way, this is precisely why the line is useful, because they're *not* direct cherry-picks and it's useful to be able to correspond them to what the mainline change(s) were. But if you're not using 'git cherry-pick' already for these, then I can understand it's a big workflow change and probably not worth it. The expectation isn't that it directly matches the 'cherry-picked from ...' commits, but rather that it gives some anchor to compare to / expresses intent, rather than having to compare just the commit summary (as those aren't unique). > > Bruno > > [1] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html
Re: Suggestion for cherry-picking to stable branches
Sam James wrote: > Could I propose that cherry-picks to the stable-XXX branches are done > with 'git cherry-pick -x'? This is often done in projects following a > gnulib-like model. > > git will append '(cherry picked from commit ...)' to the commit message > which makes it easy to compare with the original commit and distinguish > branch-only commits from backports. All commits to the stable branches [1] are backports. There are no commits that are created for the branch specifically. But while doing these backports, I have to make several adjustments: - Combine 2 or more commits from 'master' if the first of these commits introduced a regression that was only fixed later on. - Assign new '# serial' numbers to the *.m4 files. - Omit modifications to modules that did not exist when the stable branch was forked off. - Omit documentation changes that don't apply. - Fix merge conflicts. - For stable branches from the previous year: Update the (C) year of each modified file. I don't think that a tool like 'git cherry-pick' will allow me to have the needed flexibility for this process. Bruno [1] https://www.gnu.org/software/gnulib/manual/html_node/Stable-Branches.html
