Cc: the current Git GUI maintainer on corresponding patches#1988
Cc: the current Git GUI maintainer on corresponding patches#1988dscho merged 2 commits intomaingitgitgadget/gitgitgadget:mainfrom cc-current-git-gui-maintainergitgitgadget/gitgitgadget:cc-current-git-gui-maintainerCopy head branch name to clipboard
Conversation
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Johannes Sixt gracefully accepted that job, and we need to Cc: them instead of the previous maintainer. I noticed this when Pratyush was Cc:ed in v2 of gitgitgadget/git#358. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
This was probably mentioned somewhere as an outstanding issue. The |
|
We'll have to figure this out on the go, as we truly support more projects. |
…current-git-gui-maintainer, 2025-08-28))
…itgadget/cc-current-git-gui-maintainer, 2025-08-28))
Let's just leave this as-is, for now. If there is a project that wants to use GitGitGadget and that has "sub-lieutenants" that need to be Cc:ed on patches touching specific parts of the code, we can cross that bridge then. And I wouldn't be surprised if it could be handled by a path pattern then, as opposed to the situation in Git which is hampered by its use of an ill-integrated subtree strategy (Junio merges Git GUI's changes, which are at the top-level tree, into In short, I could imagine that we will always have to special-case Git in that respect and it is probably not worth losing more brain cycles over this. My current thinking is to add the following to https://github.com/gitgitgadget-workflows/gitgitgadget-workflows/blob/config/gitgitgadget-config.json: "project": {
"to": "--to=git@vger.kernel.org",
"branch": "upstream/seen",
"cc": [],
"urlPrefix": "https://lore.kernel.org/git/"
}and make the let { branch: upstreamBranch, to, urlPrefix: midUrlPrefix } = config.project;
if ("gitgitgadget/git" === `${config.repo.owner}/${config.repo.name}`
&& (await revParse(`${baseCommit}:git-gui.sh`, workDir)) !== undefined) {
// Git GUI
cc.push("Johannes Sixt <j6t@kdbg.org>");
upstreamBranch = "git-gui/master";
}This will most likely need to live in the code eternally, even if we could come up with a more flexible way to configure this via the JSON, but... https://xkcd.com/1205/ is a real thing. @webstech how does that plan sound to you? |
I mentioned in #1993 I thought you had introduced something for handling this but maybe it was in the sync remotes stuff. Sorry for any confusion. Yes, making project required is a good thing. Handling special cases is difficult. For Having said that, the special case will work for now and other projects may drive a generic solution. Just to re-iterate, |
Right. And |
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
|
For the record, this is how I am intending to go forward with this: dscho@fb72cd6#diff-f15268abff24be0d82e67bb03d2d639789d27a2b734fdf93cf5e6c7fca61e44fL25-R31 |
Missing something? |
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We're about to make the config required, and not implicit, therefore it makes sense to start with the project options for `gitgitgadget/git` itself. So let's set `project` explicitly in `defaultConfig` and remove the implicit configuration of the `gitgitgadget/git` project from `ProjectOptions.get()`. There is a slight quirk here, as the Git GUI special-casing is a bit magic: based on the presence of a specific file at the top-level of `HEAD`'s root tree, it is determined that this is a Git GUI PR rather than a git/git PR. Now, we _could_ introduce some new attribute of the `projectInfo` type that would allow the same kind of trick for other projects. As per gitgitgadget#1988 (comment) though, no other project using GitGitGadget may ever need that, so we'll still hard-code it for `gitgitgadget/git` (and `git/git`) specifically. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
I just noticed that Pratyush was still Cc:ed by default. Then I looked and was puzzled because I thought that the
projectsettings would be used instead of auto-magically figuring out whether the PR in question is a Git GUI one. But then I saw that thedefaultConfigdoes not have aprojectattribute ;-)