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
