Re: Flag day for simplified package inputs
Hi, Jelle Licht skribis: > From 69926c94fb576e503d7838836cfd83066c39abcc Mon Sep 17 00:00:00 2001 > From: Jelle Licht > Date: Mon, 13 Dec 2021 16:08:22 +0100 > Subject: [PATCH] maint: Ignore specified bulk changes in git blame. > > * etc/git/git-blame-ignore-revs: New file. > * etc/git/gitconfig (blame): Add ignoreRevsFile. > * doc/guix.texi ("Invoking guix style"): Document git-blame-ignore-revs usage. > > Signed-off-by: Jelle Licht LGTM, thanks! Ludo’.
Re: Flag day for simplified package inputs
Hello, Ludovic Courtès writes: > Hi, > > Jelle Licht skribis: > >> I will work on that. Do we already have a suitable 'bulk change' in the >> repo? Or should we first run `guix style', and subsequently use that >> commit as the first entry in the .git-blame-ignore-revs file? > > The latter I guess. Attached what I was thinking of: I decided to go with integrating the git-blame-ignore-revs file with our existing gitconfig situation. Let me know what you think of the workflow and the documented changes after running `guix style'. >From 69926c94fb576e503d7838836cfd83066c39abcc Mon Sep 17 00:00:00 2001 From: Jelle Licht Date: Mon, 13 Dec 2021 16:08:22 +0100 Subject: [PATCH] maint: Ignore specified bulk changes in git blame. * etc/git/git-blame-ignore-revs: New file. * etc/git/gitconfig (blame): Add ignoreRevsFile. * doc/guix.texi ("Invoking guix style"): Document git-blame-ignore-revs usage. Signed-off-by: Jelle Licht --- doc/guix.texi | 5 + etc/git/git-blame-ignore-revs | 0 etc/git/gitconfig | 3 +++ 3 files changed, 8 insertions(+) create mode 100644 etc/git/git-blame-ignore-revs diff --git a/doc/guix.texi b/doc/guix.texi index 59651f996b..0c0293cc8e 100644 --- a/doc/guix.texi +++ b/doc/guix.texi @@ -12769,6 +12769,11 @@ Invoking guix style trigger any package rebuild. @end table +When applying automated changes to many packages, consider adding that +particular commit hash to @file{etc/git/git-blame-ignore-revs} in a +follow-up commit. This will allow @command{git blame} +(@pxref{Configuring Git}) to automatically ignore the specified commits. + @node Invoking guix lint @section Invoking @command{guix lint} diff --git a/etc/git/git-blame-ignore-revs b/etc/git/git-blame-ignore-revs new file mode 100644 index 00..e69de29bb2 diff --git a/etc/git/gitconfig b/etc/git/gitconfig index c9ebdc8fa8..afa598c4e3 100644 --- a/etc/git/gitconfig +++ b/etc/git/gitconfig @@ -1,3 +1,6 @@ +[blame] + ignoreRevsFile = etc/git/git-blame-ignore-revs + [diff "scheme"] xfuncname = "^(\\(define.*)$" base-commit: e765ad091d861c99eae9fdd402214a2e2e90ed4d -- 2.34.0 - Jelle
Re: Flag day for simplified package inputs
Hi, Jelle Licht skribis: > I will work on that. Do we already have a suitable 'bulk change' in the > repo? Or should we first run `guix style', and subsequently use that > commit as the first entry in the .git-blame-ignore-revs file? The latter I guess. Thanks, Ludo’.
Re: Flag day for simplified package inputs
Hello there, Ludovic Courtès writes: > Hi, > > Jelle Licht skribis: > >> Ludovic Courtès writes: >> >>> Hi, >>> >>> Jelle Licht skribis: >>> When applying this and future bulk changes, could we perhaps list the specific commits (+ commented shortlog line) in a file. To clarify, if we were to store these commits in `.git-blame-ignore-revs', later on we can instruct users to run: git config blame.ignoreRevsFile .git-blame-ignore-revs to ignore the bulk change for git blame purposes. >>> >>> Sounds like a good idea. There’s no particular convention regarding the >>> file name of ‘.git-blame-ignore-revs’, right? >> >> As far as I know there is no established convention, although after >> searching around a bit I found that Sarah Morgensen proposed the exact >> same thing in September. It seems the chromium project also follows the >> same naming scheme, so we won't be totally idiosyncratic at least :). > > Good. :-) Could you (or Sarah?) propose a patch, including a sentence > or two in the manual with the ‘git config’ snippet? I will work on that. Do we already have a suitable 'bulk change' in the repo? Or should we first run `guix style', and subsequently use that commit as the first entry in the .git-blame-ignore-revs file? - Jelle
Re: Flag day for simplified package inputs
Hi, Jelle Licht skribis: > Ludovic Courtès writes: > >> Hi, >> >> Jelle Licht skribis: >> >>> When applying this and future bulk changes, could we perhaps list the >>> specific commits (+ commented shortlog line) in a file. To clarify, if >>> we were to store these commits in `.git-blame-ignore-revs', later on we >>> can instruct users to run: >>> >>> git config blame.ignoreRevsFile .git-blame-ignore-revs >>> >>> to ignore the bulk change for git blame purposes. >> >> Sounds like a good idea. There’s no particular convention regarding the >> file name of ‘.git-blame-ignore-revs’, right? > > As far as I know there is no established convention, although after > searching around a bit I found that Sarah Morgensen proposed the exact > same thing in September. It seems the chromium project also follows the > same naming scheme, so we won't be totally idiosyncratic at least :). Good. :-) Could you (or Sarah?) propose a patch, including a sentence or two in the manual with the ‘git config’ snippet? Thanks, Ludo’.
Re: Flag day for simplified package inputs
Hello there, Ludovic Courtès writes: > Hi, > > Jelle Licht skribis: > >> When applying this and future bulk changes, could we perhaps list the >> specific commits (+ commented shortlog line) in a file. To clarify, if >> we were to store these commits in `.git-blame-ignore-revs', later on we >> can instruct users to run: >> >> git config blame.ignoreRevsFile .git-blame-ignore-revs >> >> to ignore the bulk change for git blame purposes. > > Sounds like a good idea. There’s no particular convention regarding the > file name of ‘.git-blame-ignore-revs’, right? As far as I know there is no established convention, although after searching around a bit I found that Sarah Morgensen proposed the exact same thing in September. It seems the chromium project also follows the same naming scheme, so we won't be totally idiosyncratic at least :).
Re: Flag day for simplified package inputs
Hi, Jelle Licht skribis: > When applying this and future bulk changes, could we perhaps list the > specific commits (+ commented shortlog line) in a file. To clarify, if > we were to store these commits in `.git-blame-ignore-revs', later on we > can instruct users to run: > > git config blame.ignoreRevsFile .git-blame-ignore-revs > > to ignore the bulk change for git blame purposes. Sounds like a good idea. There’s no particular convention regarding the file name of ‘.git-blame-ignore-revs’, right? > It seems like a maintainable way to mitigate some of the (IMO) major > disadvantages that we bring in by applying bulk changes. The disadvantage of changes is that they introduce changes, indeed. :-) But really, I think we should be able to find relevant hints as comments and use VCS history more as a last resort. Thanks, Ludo’.
Re: Flag day for simplified package inputs
Hey Guix, Ludovic Courtès writes: > Hello Guix! > > As a reminder, the plan I proposed¹ is to have a “flag day” shortly > before ‘core-updates-frozen’ is merged into ‘master’ when we would run > ‘guix style’ on the whole repo, thereby removing input labels from most > packages. > If everything goes well, this could happen in a few days. > > Thoughts? Slightly OT, but I think we should think about it now rather than after the merge. As with any bulk change, this change will clobber git blame for the forseeable future for a big chunk of the code. When applying this and future bulk changes, could we perhaps list the specific commits (+ commented shortlog line) in a file. To clarify, if we were to store these commits in `.git-blame-ignore-revs', later on we can instruct users to run: --8<---cut here---start->8--- git config blame.ignoreRevsFile .git-blame-ignore-revs --8<---cut here---end--->8--- to ignore the bulk change for git blame purposes. It seems like a maintainable way to mitigate some of the (IMO) major disadvantages that we bring in by applying bulk changes. NB, we could still ponder and discuss this approach at a later point in time, but perhaps we want to deal with some of these issues in a different way that cannot be delayed as easily. WDYT? - Jelle
Flag day for simplified package inputs
Hello Guix! As a reminder, the plan I proposed¹ is to have a “flag day” shortly before ‘core-updates-frozen’ is merged into ‘master’ when we would run ‘guix style’ on the whole repo, thereby removing input labels from most packages. Doing that before merging will (1) let us ensure there are no rebuilds or, if rebuilds need to happen, that they’ll take place before the merge, and (2) reduce chances of merge conflicts. (‘guix style’ by default changes packages in a way that does not trigger a rebuild; ‘guix style --input-simplification=safe’, which we may also want to run, can trigger rebuilds.) If everything goes well, this could happen in a few days. Thoughts? Ludo’. ¹ https://issues.guix.gnu.org/49169#16