From: Daniele Sassoli Date: Fri, 22 Aug 2025 09:14:20 GMT Subject: Re: [PATCH] doc:clarify which remotes can be used when contributing Message-ID: In-Reply-To: On 20/08/2025 22:16, Junio C Hamano wrote: > Daniele Sassoli writes: > >> On 19/08/2025 22:19, Junio C Hamano wrote: >>> "Daniele Sassoli via GitGitGadget" writes: >>>> https://github.com/gitgitgadget/git and open a PR either with the "New pull >>>> request" button or the convenient "Compare & pull request" button that may >>>> appear with the name of your newly pushed branch. >>>> +If you're using https://github.com/git/git as your remote, you will need to >>>> +open the pull-request from your fork, selecting `git/git` as base. >>>> + >>>> +The differences between using `gitgitgadget/git` and `git/git` as your base can >>>> +be found [here](https://gitgitgadget.github.io/#should-i-use-gitgitgadget-on-gitgitgadgets-git-fork-or-on-gits-github-mirror) >>> Looking at the table, there is no advantage to use git/git at all. >> Most of the document, including the "Getting Started" section, points to cloning >> from git/git. It's only when it comes to the gitgitgadget section that we >> mention gitgitgadget/git. >> >> It's true that there are no advantages of using git/git over gitgitgadget/git, >> but I would argue that the disadvantages are quite minor and definitely don't >> impact someone at their first contribution? First of all, thanks for taking the time to review this series, really appreciate it. > Even the disabled things may be rather advanced features, wouldn't > it still impact them for them to stay to be on git/git? > > Those started from git/git have to learn what different things they > need to do to use GGG by reading this extra piece of documentation, > and then if they plan to keep using GGG, they will have to do this > extra thing each and every time until the end of time (since your > preference is not to teach switching to GGG/git from git/git). I think for someone's first contribution, the most straightforward thing to do is simply to stick with what they have setup so far. If someone finds themselves doing this more than once, I would imagine they know what they're doing and are not beginners, so can figure out to switch the remote themselves. > > I have no strong opinions as I wouldn't be the one who is doing > something extra every time, but I'd rather see our new contributors > having to spend less time to get their work published and more time > to polish their work into reviewable state. We're trying to achieve the same outcome, which is why I'm trying to have the reader follow the path of least resistance in getting their patch to the mailing list. If they then find themselves contributing regularly and realise they need the more advanced features of gitgitgadget on a regular basis, I'm sure they'll figure to switch the remote themselves. >