Jeff KingAre we interested in participating in the December 2020 round of Outreachy? The community application period is now open.
I can look into lining up funding, but we'd also need:
- volunteers to act as mentors
- updates to our applicant materials (proposed projects, but also
microproject / patch suggestions)-Peff
Christian CouderRe: Git in Outreachy?
On Fri, Aug 28, 2020 at 8:56 AM Jeff King <peff@peff.net> wrote:
> > Are we interested in participating in the December 2020 round of > Outreachy? The community application period is now open.
I am interested in participating.
> I can look into lining up funding, but we'd also need: > > - volunteers to act as mentors
I am interested in mentoring, but would prefer to co-mentor.
> - updates to our applicant materials (proposed projects, but also > microproject / patch suggestions)
It looks like many micro-project ideas from GSoC 2020 are still valid, and I have a few new ones, so I am ok to create a micro-project page.
I would appreciate help to find project ideas though. Are there still scripts that are worth converting to C (excluding git-bisect.sh and git-submodule.sh that are still worked on)? Are there worthy refactorings or improvements that we could propose as projects?
Jonathan NiederRe: Git in Outreachy?
Hi,
Christian Couder wrote:
> I would appreciate help to find project ideas though. Are there still > scripts that are worth converting to C (excluding git-bisect.sh and > git-submodule.sh that are still worked on)? Are there worthy > refactorings or improvements that we could propose as projects?
I think setting up something like snowpatch[*] to run CI on patches that have hit the mailing list but not yet hit "seen" might be a good project for an interested applicant (and I'd be interested in co-mentoring if we find a taker).
Some other topics that could be interesting: - better support for handling people's name changing - making signing features such as signed push easier to use (for example by allowing signing with SSH keys to simplify PKI) and more useful (for example by standardizing a way to publish signed push logs in Git) - protocol: sharing notes and branch descriptions - formats: on-disk reverse idx - obliterate - cache server to take advantage of multiple promisors+packfile URIs
Jonathan
[*] https://github.com/ruscur/snowpatch
Philip OakleyRe: Git in Outreachy?
On 03/09/2020 07:00, Jonathan Nieder wrote:
> Hi, > > Christian Couder wrote: > >> I would appreciate help to find project ideas though. Are there still >> scripts that are worth converting to C (excluding git-bisect.sh and >> git-submodule.sh that are still worked on)? Are there worthy >> refactorings or improvements that we could propose as projects? > I think setting up something like snowpatch[*] to run CI on patches > that have hit the mailing list but not yet hit "seen" might be a good > project for an interested applicant (and I'd be interested in > co-mentoring if we find a taker). > > Some other topics that could be interesting: > - better support for handling people's name changing > - making signing features such as signed push easier to use (for > example by allowing signing with SSH keys to simplify PKI) and more > useful (for example by standardizing a way to publish signed push > logs in Git) > - protocol: sharing notes and branch descriptions > - formats: on-disk reverse idx > - obliterate > - cache server to take advantage of multiple promisors+packfile URIs > > Jonathan > > [*] https://github.com/ruscur/snowpatch
A suggestion with high value for the Windows community - mechanism to map file names between the index and the local FS, should a repos file/path name already be taken, or invalid. [1]
Philip
[1] https://github.com/git-for-windows/git/issues/2803#issuecomment-687161483
Johannes SchindelinRe: Git in Outreachy?
Hi Philip,
On Fri, 4 Sep 2020, Philip Oakley wrote:
> On 03/09/2020 07:00, Jonathan Nieder wrote: > > > > Christian Couder wrote: > > > >> I would appreciate help to find project ideas though. Are there still > >> scripts that are worth converting to C (excluding git-bisect.sh and > >> git-submodule.sh that are still worked on)? Are there worthy > >> refactorings or improvements that we could propose as projects? > > I think setting up something like snowpatch[*] to run CI on patches > > that have hit the mailing list but not yet hit "seen" might be a good > > project for an interested applicant (and I'd be interested in > > co-mentoring if we find a taker). > > > > Some other topics that could be interesting: > > - better support for handling people's name changing > > - making signing features such as signed push easier to use (for > > example by allowing signing with SSH keys to simplify PKI) and more > > useful (for example by standardizing a way to publish signed push > > logs in Git) > > - protocol: sharing notes and branch descriptions > > - formats: on-disk reverse idx > > - obliterate > > - cache server to take advantage of multiple promisors+packfile URIs > > > > Jonathan > > > > [*] https://github.com/ruscur/snowpatch > A suggestion with high value for the Windows community > - mechanism to map file names between the index and the local FS, should > a repos file/path name already be taken, or invalid. [1]
This suggestion keeps coming up, but I cannot help but highly doubt that it will prove useful in practice: if your source code contains a file called `aux.c`, chances are that your build system lists this file specifically, and it won't do at all to "magically" rename it to, say, `aux_.c` during checkout.
In contrast, I think a much more useful project would be to relax the `core.protectNTFS` protections to cover only the files that will be written to disk, and not bother even checking the files excluded from a sparse-checkout for invalid file names on NTFS.
This is trickier, of course, than meets the eye: we would still want to be _very_ careful to ensure that the unchecked file names will _never_ make it to the disk. And, slightly related, the question whether checking for `.git` (or `GIT~1`) would be likewise weakened, or whether that is too dangerous to allow even in `skip-worktree` entries.
Not necessarily decisions you would want to burden a first-time contributor with.
Ciao, Dscho
> > Philip > > [1] > https://github.com/git-for-windows/git/issues/2803#issuecomment-687161483 >
Philip OakleyRe: Git in Outreachy?
Hi, Sorry I've not been able to attend to the list discussions recently.
On 07/09/2020 19:49, Johannes Schindelin wrote:
> Hi Philip, > > On Fri, 4 Sep 2020, Philip Oakley wrote: > >> On 03/09/2020 07:00, Jonathan Nieder wrote: >>> Christian Couder wrote: >>> >>>> I would appreciate help to find project ideas though. Are there still >>>> scripts that are worth converting to C (excluding git-bisect.sh and >>>> git-submodule.sh that are still worked on)? Are there worthy >>>> refactorings or improvements that we could propose as projects? >>> I think setting up something like snowpatch[*] to run CI on patches >>> that have hit the mailing list but not yet hit "seen" might be a good >>> project for an interested applicant (and I'd be interested in >>> co-mentoring if we find a taker). >>> >>> Some other topics that could be interesting: >>> - better support for handling people's name changing >>> - making signing features such as signed push easier to use (for >>> example by allowing signing with SSH keys to simplify PKI) and more >>> useful (for example by standardizing a way to publish signed push >>> logs in Git) >>> - protocol: sharing notes and branch descriptions >>> - formats: on-disk reverse idx >>> - obliterate >>> - cache server to take advantage of multiple promisors+packfile URIs >>> >>> Jonathan >>> >>> [*] https://github.com/ruscur/snowpatch >> A suggestion with high value for the Windows community >> - mechanism to map file names between the index and the local FS, should >> a repos file/path name already be taken, or invalid. [1] > This suggestion keeps coming up, but I cannot help but highly doubt that > it will prove useful in practice: if your source code contains a file > called `aux.c`, chances are that your build system lists this file > specifically, and it won't do at all to "magically" rename it to, say, > `aux_.c` during checkout.
I'd disagree with that line of reasoning in the sense that if someone is on Windows wanting to 'view' a repo that was developed on Linux, with colons in pathnames, and filenames like aux.c we shouldn't be deliberately de-include them just because of those file/pathname 'accidents. I accept that the build system probably won't be working for their Windows environment (how could it be?), but, if possible, we should be able to support them, in some positive way. In our distributed collaborative environment we can trip over the user's 'your file / your build' tag.
> In contrast, I think a much more useful project would be to relax the > `core.protectNTFS` protections to cover only the files that will be > written to disk, and not bother even checking the files excluded from a > sparse-checkout for invalid file names on NTFS.
That's a valid base method for all the NTFS valid file and path names.
The next level could be a mechanism for path and file name adjustment, at least for a _copy-out_ step (without ability to 'git add' / check back in).
> > This is trickier, of course, than meets the eye: we would still want to be > _very_ careful to ensure that the unchecked file names will _never_ make > it to the disk. And, slightly related, the question whether checking for > `.git` (or `GIT~1`) would be likewise weakened, or whether that is too > dangerous to allow even in `skip-worktree` entries.
Agree that the security aspects of `.Git` etc must still be retained.
> > Not necessarily decisions you would want to burden a first-time > contributor with.
True, but still worth recording as a useful Git project (and that there are a number of nuances within it!)
-- Philip
> Ciao, > Dscho > >> Philip >> >> [1] >> https://github.com/git-for-windows/git/issues/2803#issuecomment-687161483 >>
Johannes SchindelinRe: Git in Outreachy?
Hi Philip,
On Wed, 16 Sep 2020, Philip Oakley wrote:
> On 07/09/2020 19:49, Johannes Schindelin wrote: > > > > On Fri, 4 Sep 2020, Philip Oakley wrote: > > > >> On 03/09/2020 07:00, Jonathan Nieder wrote: > >>> Christian Couder wrote: > >>> > >>>> I would appreciate help to find project ideas though. Are there still > >>>> scripts that are worth converting to C (excluding git-bisect.sh and > >>>> git-submodule.sh that are still worked on)? Are there worthy > >>>> refactorings or improvements that we could propose as projects? > >>> I think setting up something like snowpatch[*] to run CI on patches > >>> that have hit the mailing list but not yet hit "seen" might be a good > >>> project for an interested applicant (and I'd be interested in > >>> co-mentoring if we find a taker). > >>> > >>> Some other topics that could be interesting: > >>> - better support for handling people's name changing > >>> - making signing features such as signed push easier to use (for > >>> example by allowing signing with SSH keys to simplify PKI) and more > >>> useful (for example by standardizing a way to publish signed push > >>> logs in Git) > >>> - protocol: sharing notes and branch descriptions > >>> - formats: on-disk reverse idx > >>> - obliterate > >>> - cache server to take advantage of multiple promisors+packfile URIs > >>> > >>> Jonathan > >>> > >>> [*] https://github.com/ruscur/snowpatch > >> A suggestion with high value for the Windows community > >> - mechanism to map file names between the index and the local FS, should > >> a repos file/path name already be taken, or invalid. [1] > > This suggestion keeps coming up, but I cannot help but highly doubt that > > it will prove useful in practice: if your source code contains a file > > called `aux.c`, chances are that your build system lists this file > > specifically, and it won't do at all to "magically" rename it to, say, > > `aux_.c` during checkout. > > I'd disagree with that line of reasoning in the sense that if someone is > on Windows wanting to 'view' a repo that was developed on Linux, with > colons in pathnames, and filenames like aux.c we shouldn't be > deliberately de-include them just because of those file/pathname > 'accidents.
If someone wanted to just have a look, they usually make use of the web interface of a Git hosting service and look at the file there.
Even if somebody insists on cloning the entire history, they can easily look at the file via `git show origin/HEAD:<path>`.
The most likely users who really need those files to be checked out are the ones who need to build the project, and that's simply not possible with "magically" renamed files.
Ciao, Dscho
Philip OakleyRe: Git in Outreachy?
Hi Dscho,
On 16/09/2020 19:43, Johannes Schindelin wrote:
> Hi Philip, > > On Wed, 16 Sep 2020, Philip Oakley wrote: > >> On 07/09/2020 19:49, Johannes Schindelin wrote: >>> On Fri, 4 Sep 2020, Philip Oakley wrote: >>> >>>> On 03/09/2020 07:00, Jonathan Nieder wrote: >>>>> Christian Couder wrote: >>>>> >>>>>> I would appreciate help to find project ideas though. Are there still >>>>>> scripts that are worth converting to C (excluding git-bisect.sh and >>>>>> git-submodule.sh that are still worked on)? Are there worthy >>>>>> refactorings or improvements that we could propose as projects? >>>>> I think setting up something like snowpatch[*] to run CI on patches >>>>> that have hit the mailing list but not yet hit "seen" might be a good >>>>> project for an interested applicant (and I'd be interested in >>>>> co-mentoring if we find a taker). >>>>> >>>>> Some other topics that could be interesting: >>>>> - better support for handling people's name changing >>>>> - making signing features such as signed push easier to use (for >>>>> example by allowing signing with SSH keys to simplify PKI) and more >>>>> useful (for example by standardizing a way to publish signed push >>>>> logs in Git) >>>>> - protocol: sharing notes and branch descriptions >>>>> - formats: on-disk reverse idx >>>>> - obliterate >>>>> - cache server to take advantage of multiple promisors+packfile URIs >>>>> >>>>> Jonathan >>>>> >>>>> [*] https://github.com/ruscur/snowpatch >>>> A suggestion with high value for the Windows community >>>> - mechanism to map file names between the index and the local FS, should >>>> a repos file/path name already be taken, or invalid. [1] >>> This suggestion keeps coming up, but I cannot help but highly doubt that >>> it will prove useful in practice: if your source code contains a file >>> called `aux.c`, chances are that your build system lists this file >>> specifically, and it won't do at all to "magically" rename it to, say, >>> `aux_.c` during checkout. >> I'd disagree with that line of reasoning in the sense that if someone is >> on Windows wanting to 'view' a repo that was developed on Linux, with >> colons in pathnames, and filenames like aux.c we shouldn't be >> deliberately de-include them just because of those file/pathname >> 'accidents. > If someone wanted to just have a look, they usually make use of the web > interface of a Git hosting service and look at the file there. > > Even if somebody insists on cloning the entire history, they can easily > look at the file via `git show origin/HEAD:<path>`. > > The most likely users who really need those files to be checked out are > the ones who need to build the project, and that's simply not possible > with "magically" renamed files. > > Ciao, > Dscho
Is that the user experience we want to have?
Maybe we need extra documentation on the core.protectNTFS setting noting that Git itself may not be the right tool for such repositories, and these workarounds which may not be familiar to many users.
It feels as if we are giving cart-blanche to bad actors who can add an aux.info or similar files to a repo just to thwart collaborators being on Windows.
Philip
Taylor BlauRe: Git in Outreachy?
Hi Jonathan,
Thanks for suggesting a great list of ideas. I don't have strong opinions on most of the above, so I'll save you a bunch of 'ack's and just talk about the ones that I do:
On Wed, Sep 02, 2020 at 11:00:41PM -0700, Jonathan Nieder wrote:
> I think setting up something like snowpatch[*] to run CI on patches > that have hit the mailing list but not yet hit "seen" might be a good > project for an interested applicant (and I'd be interested in > co-mentoring if we find a taker).
To be honest, I'm not crazy about this one. We already have a system in place that works well (GitHub Actions) that allows people to run CI on their patches automatically at no cost.
I'm not saying that we shouldn't have another because of sticking to one provider or another, but there has been a reasonable amount of churn there, and what's in-tree now seems to be working quite well.
The goal of providing CI easily to new contributors should be to make it as *easy* as possible to test their patches, and adding an additional decision (i.e., "should I use GitHub Actions, or Snowpatch?") seems counter-intuitive.
> - formats: on-disk reverse idx
As a heads up, I think that I am going to start working on (an alternative to) this myself, so it may be worth pushing future Outreachy interns in a different direction.
> Jonathan > > [*] https://github.com/ruscur/snowpatch
Thanks, Taylor
Jonathan NiederRe: Git in Outreachy?
Taylor Blau wrote:
> On Wed, Sep 02, 2020 at 11:00:41PM -0700, Jonathan Nieder wrote:
>> I think setting up something like snowpatch[*] to run CI on patches >> that have hit the mailing list but not yet hit "seen" might be a good >> project for an interested applicant (and I'd be interested in >> co-mentoring if we find a taker). > > To be honest, I'm not crazy about this one. We already have a system > in place that works well (GitHub Actions) that allows people to run CI > on their patches automatically at no cost.
I agree, that's good for people using GitGitGadget. So if we're focusing on individual contributors to Git, that may be enough (or having the ability to run tests on their own machine may be even better ;-)).
But a reviewer or maintainer cannot count on all contributors using GitGitGadget. Hence a bridge from patches sent on the mailing list to git commits that a system like GitHub Actions can consume becomes important. Snowpatch is such a bridge.
In other words: this isn't about changing how tests are executed --- it's about going from patches on list to git commits that can be tested.
[...]
>> - formats: on-disk reverse idx > > As a heads up, I think that I am going to start working on (an > alternative to) this myself,
Neat! I look forward to seeing what you build. (Is this related to the bitmaps-using-midx-ordering work?)
Thanks, Jonathan
>> [*] https://github.com/ruscur/snowpatch
Taylor BlauRe: Git in Outreachy?
On Wed, Sep 09, 2020 at 06:39:15PM -0700, Jonathan Nieder wrote:
> Taylor Blau wrote: > In other words: this isn't about changing how tests are executed --- > it's about going from patches on list to git commits that can be > tested.
Fair enough; it sounds like a Snowpatch-like tool might be useful for that case.
> [...] > >> - formats: on-disk reverse idx > > > > As a heads up, I think that I am going to start working on (an > > alternative to) this myself, > > Neat! I look forward to seeing what you build. (Is this related to > the bitmaps-using-midx-ordering work?)
You guessed it ;-). It's sort of a tricky issue: the pack-objects code needs to know things like the position of an object in index order so that it can look at the offset of the next object and determine its size.
But, in the multi-pack case, things aren't so simple. It would be nice if we could look at a bit position and say "you are at bit position N and there are M different packs before you, so I know what position you are within your pack", but this can't be done in general when you have duplicate objects among packs in your MIDX.
The MIDX is only going to choose one of them, and so you don't know how many "holes" are present before you. In my development version, I have a bitmap extension I'm calling the "rev-cache" which acts like a mapping between bit position and MIDX name order (which can then be used to look up auxiliary info like which pack an object came from, its position in the pack's index order, and so on).
But, having an on-disk mapping between objects and their position in different orderings will be useful not only for this, but for:
- avoiding building a reverse index in memory from scratch (which can
occupy quite a bit of the heap in some repositories that we see),
and - dropping GitHub's custom "bit-cache" extension, which maps objects
from name order to bit position.Anyway, obviously not related to Outreachy, and obviously many more details to come once I have patches that are more mature, but I couldn't help myself in the meantime.
> Thanks, > Jonathan > > >> [*] https://github.com/ruscur/snowpatch
Thanks, Taylor
Christian CouderRe: Git in Outreachy?
Hi,
On Thu, Sep 3, 2020 at 8:00 AM Jonathan Nieder <jrnieder@gmail.com> wrote:
> Christian Couder wrote: > > > I would appreciate help to find project ideas though. Are there still > > scripts that are worth converting to C (excluding git-bisect.sh and > > git-submodule.sh that are still worked on)? Are there worthy > > refactorings or improvements that we could propose as projects? > > I think setting up something like snowpatch[*] to run CI on patches > that have hit the mailing list but not yet hit "seen" might be a good > project for an interested applicant (and I'd be interested in > co-mentoring if we find a taker).
I'd prefer not co-mentoring this one. If this is the only one you'd be ok to co-mentor I could reconsider though.
> Some other topics that could be interesting: > - better support for handling people's name changing
Following discussions about mailmap, name changes, deadnames, etc during the Inclusion Summit yesterday and the day before, I am interested in co-mentoring such a project along what has been discussed.
> - making signing features such as signed push easier to use (for > example by allowing signing with SSH keys to simplify PKI) and more > useful (for example by standardizing a way to publish signed push > logs in Git) > - protocol: sharing notes and branch descriptions > - formats: on-disk reverse idx > - obliterate > - cache server to take advantage of multiple promisors+packfile URIs
Would you be ok to elaborate about the above projects? I am not very much excited about any of them, but I would be ok to co-mentor as long as my co-mentor would come up with a proper project description.
Thanks, Christian.
Christian CouderRe: Git in Outreachy?
On Mon, Aug 31, 2020 at 8:55 AM Christian Couder <christian.couder@gmail.com> wrote:
> > On Fri, Aug 28, 2020 at 8:56 AM Jeff King <peff@peff.net> wrote:
> > - updates to our applicant materials (proposed projects, but also > > microproject / patch suggestions) > > It looks like many micro-project ideas from GSoC 2020 are still valid, > and I have a few new ones, so I am ok to create a micro-project page.
Here is a new page with micro-project ideas for Outreachy applicants:
https://git.github.io/Outreachy-21-Microprojects/
I added only one new idea about modernizing test scripts, though I know someone is already working on modernizing t7001. But I think it can be applied to other test scripts.
While at it I also removed the GSoC 2020 material from the home page and made a few cosmetic changes related to historical materials.
Junio C HamanoRe: Git in Outreachy?
Jeff King <peff@peff.net> writes:
> Are we interested in participating in the December 2020 round of > Outreachy? The community application period is now open. > > I can look into lining up funding, but we'd also need: > > - volunteers to act as mentors > > - updates to our applicant materials (proposed projects, but also > microproject / patch suggestions) > > -Peff
FWIW, I am interested in seeing this project participating. As usual, I won't be able to mentor to avoid biases, though.
As to microprojects, I think we saw #leftoverbits and #micrproject sprinkled in a handful of messages in recent discussions, so with the help of list archive, we may come up with new ones.
Thanks.
Emily ShafferRe: Git in Outreachy?
On Fri, Aug 28, 2020 at 02:56:09AM -0400, Jeff King wrote:
> > Are we interested in participating in the December 2020 round of > Outreachy? The community application period is now open. > > I can look into lining up funding, but we'd also need: > > - volunteers to act as mentors
I'm interested in mentoring or co-mentoring this term. (I'm not working this week but I didn't want to miss a deadline to volunteer.)
> > - updates to our applicant materials (proposed projects, but also > microproject / patch suggestions)
One thought I had was whether it might be cool to shop for another co-mentor from Wireshark and have an intern teach Wireshark how to decipher Git protocol. But it seems large, and maybe last-minute for this term.
- Emily
Jeff KingRe: Git in Outreachy?
On Mon, Aug 31, 2020 at 11:05:37AM -0700, Emily Shaffer wrote:
> I'm interested in mentoring or co-mentoring this term. (I'm not working > this week but I didn't want to miss a deadline to volunteer.)
OK, between you and Christian, then, it sounds like it's worth pursuing. I'll sign us up and try to arrange funding.
> One thought I had was whether it might be cool to shop for another > co-mentor from Wireshark and have an intern teach Wireshark how to > decipher Git protocol. But it seems large, and maybe last-minute for > this term.
That sounds neat. I don't think it would be too large (in fact, I think it might end up being a bit small for a whole-term project). It would definitely require somebody from Wireshark being a co-mentor, though.
-Peff
Jeff KingRe: Git in Outreachy?
On Tue, Sep 01, 2020 at 08:51:20AM -0400, Jeff King wrote:
> On Mon, Aug 31, 2020 at 11:05:37AM -0700, Emily Shaffer wrote: > > > I'm interested in mentoring or co-mentoring this term. (I'm not working > > this week but I didn't want to miss a deadline to volunteer.) > > OK, between you and Christian, then, it sounds like it's worth pursuing. > I'll sign us up and try to arrange funding.
I'm still working out funding details, but in the meantime we're signed up. Potential mentors should propose projects here:
https://www.outreachy.org/communities/cfp/git/
Sooner is better than later. We can technically submit projects up until the 24th, but student applications are open now, and have to be in by September 20th.
-Peff
Jeff KingRe: Git in Outreachy?
On Thu, Sep 03, 2020 at 01:41:26AM -0400, Jeff King wrote:
> I'm still working out funding details, but in the meantime we're signed > up. Potential mentors should propose projects here: > > https://www.outreachy.org/communities/cfp/git/ > > Sooner is better than later. We can technically submit projects up until > the 24th, but student applications are open now, and have to be in by > September 20th.
[Adding everybody to the cc list who has been in the Outreachy thread this year...]
AFAICT we still have no proposed projects nor signed-up mentors. Interns are actively applying _now_, so we are likely missing out on (or have already missed out on) applicants.
If you're interested in mentoring, the time to propose is definitely ASAP.
-Peff
Kaartic SivaraamRe: Git in Outreachy?
On 15-09-2020 23:05, Jeff King wrote:
> On Thu, Sep 03, 2020 at 01:41:26AM -0400, Jeff King wrote: > >> I'm still working out funding details, but in the meantime we're signed >> up. Potential mentors should propose projects here: >> >> https://www.outreachy.org/communities/cfp/git/ >> >> Sooner is better than later. We can technically submit projects up until >> the 24th, but student applications are open now, and have to be in by >> September 20th. > > [Adding everybody to the cc list who has been in the Outreachy > thread this year...] > > AFAICT we still have no proposed projects nor signed-up mentors.
Just to ensure I didn't miss anything, a person who's signing up as a mentor for an organization needs to propose a project or wait for one to be proposed, right? Or is there some other way to express interest in mentoring without proposing a project?
I ask this because I would be willing to sign up as a co-mentor for a project in the organization but don't have any project proposals in mind. I only see a way to "submit a project proposal" in the following page:
https://www.outreachy.org/communities/cfp/git/
> If you're interested in mentoring, the time to propose is definitely > ASAP. >
-- Sivaraam
Jeff KingRe: Git in Outreachy?
On Tue, Sep 15, 2020 at 11:25:08PM +0530, Kaartic Sivaraam wrote:
> >> I'm still working out funding details, but in the meantime we're signed > >> up. Potential mentors should propose projects here: > >> > >> https://www.outreachy.org/communities/cfp/git/ > >> > >> Sooner is better than later. We can technically submit projects up until > >> the 24th, but student applications are open now, and have to be in by > >> September 20th. > > > > [Adding everybody to the cc list who has been in the Outreachy > > thread this year...] > > > > AFAICT we still have no proposed projects nor signed-up mentors. > > Just to ensure I didn't miss anything, a person who's signing up as a > mentor for an organization needs to propose a project or wait for one to > be proposed, right? Or is there some other way to express interest in > mentoring without proposing a project?
Right, mentors propose the projects they're willing to mentor.
> I ask this because I would be willing to sign up as a co-mentor for a > project in the organization but don't have any project proposals in > mind. I only see a way to "submit a project proposal" in the following > page: > > https://www.outreachy.org/communities/cfp/git/
Yeah, you'd have to either find the person you want to co-mentor with and work on a proposal with them, or wait for somebody to propose something and then ask if you could join them as a co-mentor.
-Peff
Christian CouderRe: Git in Outreachy?
On Tue, Sep 15, 2020 at 7:35 PM Jeff King <peff@peff.net> wrote:
> > On Thu, Sep 03, 2020 at 01:41:26AM -0400, Jeff King wrote: > > > I'm still working out funding details, but in the meantime we're signed > > up. Potential mentors should propose projects here: > > > > https://www.outreachy.org/communities/cfp/git/ > > > > Sooner is better than later. We can technically submit projects up until > > the 24th, but student applications are open now, and have to be in by > > September 20th. > > [Adding everybody to the cc list who has been in the Outreachy > thread this year...] > > AFAICT we still have no proposed projects nor signed-up mentors.
It seems that we now have only the 2 projects I proposed and only 1 signed-up mentor (me).
It looks like Jonathan and Emily are reaching out to the Wireshark community to find a co-mentor which is great! So we might have another project and the associated mentors soon.
Outreachy organizers have extended the mentor project submission deadline though. The new deadline is Sept. 29, 2020 at 4pm UTC. They also say that this deadline is a hard deadline, as the contribution period opens October 1, and they cannot add new projects after that date.
> Interns are actively applying _now_, so we are likely missing out on (or > have already missed out on) applicants. > > If you're interested in mentoring, the time to propose is definitely > ASAP.
Sure. By the way if you are interested in mentoring or co-mentoring, then signing-up is not definitive, you can always decide not to mentor at all later for any reason as long as an intern has not been selected yet. (Intern selection deadline is Nov. 9, 2020.)
Re: Git in Outreachy?
On 19/09/2020 09:12, Christian Couder wrote:
> On Tue, Sep 15, 2020 at 7:35 PM Jeff King <peff@peff.net> wrote: >> >> On Thu, Sep 03, 2020 at 01:41:26AM -0400, Jeff King wrote: >> >>> I'm still working out funding details, but in the meantime we're signed >>> up. Potential mentors should propose projects here: >>> >>> https://www.outreachy.org/communities/cfp/git/ >>> >>> Sooner is better than later. We can technically submit projects up until >>> the 24th, but student applications are open now, and have to be in by >>> September 20th. >> >> [Adding everybody to the cc list who has been in the Outreachy >> thread this year...] >> >> AFAICT we still have no proposed projects nor signed-up mentors. > > It seems that we now have only the 2 projects I proposed and only 1 > signed-up mentor (me).
I've been accepted as a co-mentor on the rebase project now.
Best Wishes
Phillip
> It looks like Jonathan and Emily are reaching out to the Wireshark > community to find a co-mentor which is great! So we might have another > project and the associated mentors soon. > > Outreachy organizers have extended the mentor project submission > deadline though. The new deadline is Sept. 29, 2020 at 4pm UTC. They > also say that this deadline is a hard deadline, as the contribution > period opens October 1, and they cannot add new projects after that > date. > >> Interns are actively applying _now_, so we are likely missing out on (or >> have already missed out on) applicants. >> >> If you're interested in mentoring, the time to propose is definitely >> ASAP. > > Sure. By the way if you are interested in mentoring or co-mentoring, > then signing-up is not definitive, you can always decide not to mentor > at all later for any reason as long as an intern has not been selected > yet. (Intern selection deadline is Nov. 9, 2020.) >
Christian CouderRe: Git in Outreachy?
On Tue, Sep 1, 2020 at 2:51 PM Jeff King <peff@peff.net> wrote:
> > On Mon, Aug 31, 2020 at 11:05:37AM -0700, Emily Shaffer wrote: > > > I'm interested in mentoring or co-mentoring this term. (I'm not working > > this week but I didn't want to miss a deadline to volunteer.) > > OK, between you and Christian, then, it sounds like it's worth pursuing. > I'll sign us up and try to arrange funding.
Thanks for signing up and for having arranged some funding already! I might get further funding from GitLab too.
> > One thought I had was whether it might be cool to shop for another > > co-mentor from Wireshark and have an intern teach Wireshark how to > > decipher Git protocol. But it seems large, and maybe last-minute for > > this term. > > That sounds neat. I don't think it would be too large (in fact, I think > it might end up being a bit small for a whole-term project). It would > definitely require somebody from Wireshark being a co-mentor, though.
I agree that it doesn't look too large. If it appears to be too large, it could be finished later either by the Outreachy intern who started it or by someone else like a GSoC student. Also it looks like all the projects will be last minute anyway.
Johannes SchindelinRe: Git in Outreachy?
Hi Peff,
On Fri, 28 Aug 2020, Jeff King wrote:
> Are we interested in participating in the December 2020 round of > Outreachy? The community application period is now open. > > I can look into lining up funding, but we'd also need: > > - volunteers to act as mentors > > - updates to our applicant materials (proposed projects, but also > microproject / patch suggestions)
Thank you for thinking of me! While I am eager to help, I think I won't be able to commit to a full term, though.
As to projects, I would like to believe that https://github.com/gitgitgadget/git/issues has grown into a useful resource.
Ciao, Dscho
Christian CouderRe: Git in Outreachy?
Hi Dscho,
On Wed, Sep 2, 2020 at 10:50 AM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> As to projects, I would like to believe that > https://github.com/gitgitgadget/git/issues has grown into a useful > resource.
Thanks for the useful resource!
I would be interested in mentoring, or better co-mentoring, the following projects:
- Accelerate rename detection and range-diff (https://github.com/gitgitgadget/git/issues/519): ideally I would co-mentor with someone a bit familiar with the suggested algorithms. - Add support for drop!/reword! commits to `git rebase -i` (https://github.com/gitgitgadget/git/issues/259, https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/) - Invent a way to retain reflogs for a while after the ref was deleted (https://github.com/gitgitgadget/git/issues/236): I guess this might be implemented as part of the new `git maintenance` builtin.
Best, Christian.
Re: Git in Outreachy?
On 16/09/2020 10:01, Christian Couder wrote:
> Hi Dscho, > > On Wed, Sep 2, 2020 at 10:50 AM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > >> As to projects, I would like to believe that >> https://github.com/gitgitgadget/git/issues has grown into a useful >> resource. > > Thanks for the useful resource! > > I would be interested in mentoring, or better co-mentoring, the > following projects: > > - Accelerate rename detection and range-diff > (https://github.com/gitgitgadget/git/issues/519): ideally I would > co-mentor with someone a bit familiar with the suggested algorithms. > - Add support for drop!/reword! commits to `git rebase -i` > (https://github.com/gitgitgadget/git/issues/259, > https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/)
I've got some patches that implement the reword! part (or something very similar) at [1]. I've never ended up using them that much so haven't pushed them forward.
Best Wishes
Phillip
[1] https://github.com/phillipwood/git/commits/wip/rebase-amend
> - Invent a way to retain reflogs for a while after the ref was deleted > (https://github.com/gitgitgadget/git/issues/236): I guess this might > be implemented as part of the new `git maintenance` builtin. > > Best, > Christian. >
Christian CouderRe: Git in Outreachy?
On Wed, Sep 16, 2020 at 11:01 AM Christian Couder <christian.couder@gmail.com> wrote:
> On Wed, Sep 2, 2020 at 10:50 AM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > As to projects, I would like to believe that > > https://github.com/gitgitgadget/git/issues has grown into a useful > > resource. > > Thanks for the useful resource! > > I would be interested in mentoring, or better co-mentoring, the > following projects: > > - Accelerate rename detection and range-diff > (https://github.com/gitgitgadget/git/issues/519): ideally I would > co-mentor with someone a bit familiar with the suggested algorithms.
Proposed on Outreachy's website:
https://www.outreachy.org/outreachy-december-2020-internship-round/communities/git/accelerate-rename-detection-and-the-range-diff-com/cfp/
> - Add support for drop!/reword! commits to `git rebase -i` > (https://github.com/gitgitgadget/git/issues/259, > https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/) > - Invent a way to retain reflogs for a while after the ref was deleted > (https://github.com/gitgitgadget/git/issues/236): I guess this might > be implemented as part of the new `git maintenance` builtin.
I will also likely submit a proposal for one of the above projects.
Re: Git in Outreachy?
On 17/09/2020 10:43, Christian Couder wrote:
> On Wed, Sep 16, 2020 at 11:01 AM Christian Couder > <christian.couder@gmail.com> wrote: > >> On Wed, Sep 2, 2020 at 10:50 AM Johannes Schindelin >> <Johannes.Schindelin@gmx.de> wrote: >> >>> As to projects, I would like to believe that >>> https://github.com/gitgitgadget/git/issues has grown into a useful >>> resource. >> >> Thanks for the useful resource! >> >> I would be interested in mentoring, or better co-mentoring, the >> following projects: >> >> - Accelerate rename detection and range-diff >> (https://github.com/gitgitgadget/git/issues/519): ideally I would >> co-mentor with someone a bit familiar with the suggested algorithms. > > Proposed on Outreachy's website: > > https://www.outreachy.org/outreachy-december-2020-internship-round/communities/git/accelerate-rename-detection-and-the-range-diff-com/cfp/ > >> - Add support for drop!/reword! commits to `git rebase -i` >> (https://github.com/gitgitgadget/git/issues/259, >> https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/)
I'd be happy to support someone working on this though not necessarily as a formal co-mentor - what the time (and other) commitments does being a co-mentor involve?
Best Wishes
Phillip
>> - Invent a way to retain reflogs for a while after the ref was deleted >> (https://github.com/gitgitgadget/git/issues/236): I guess this might >> be implemented as part of the new `git maintenance` builtin. > > I will also likely submit a proposal for one of the above projects. >
Christian CouderRe: Git in Outreachy?
On Thu, Sep 17, 2020 at 12:14 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
> > On 17/09/2020 10:43, Christian Couder wrote: > > On Wed, Sep 16, 2020 at 11:01 AM Christian Couder > > <christian.couder@gmail.com> wrote: > > > >> On Wed, Sep 2, 2020 at 10:50 AM Johannes Schindelin > >> <Johannes.Schindelin@gmx.de> wrote: > >> > >>> As to projects, I would like to believe that > >>> https://github.com/gitgitgadget/git/issues has grown into a useful > >>> resource. > >> > >> Thanks for the useful resource! > >> > >> I would be interested in mentoring, or better co-mentoring, the > >> following projects: > >> > >> - Accelerate rename detection and range-diff > >> (https://github.com/gitgitgadget/git/issues/519): ideally I would > >> co-mentor with someone a bit familiar with the suggested algorithms. > > > > Proposed on Outreachy's website: > > > > https://www.outreachy.org/outreachy-december-2020-internship-round/communities/git/accelerate-rename-detection-and-the-range-diff-com/cfp/ > > > >> - Add support for drop!/reword! commits to `git rebase -i` > >> (https://github.com/gitgitgadget/git/issues/259, > >> https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/) > > I'd be happy to support someone working on this though not necessarily > as a formal co-mentor
Ok, I have submitted it then:
https://www.outreachy.org/outreachy-december-2020-internship-round/communities/git/improve-droping-and-rewording-commits-in-git-inter/cfp/
> - what the time (and other) commitments does being > a co-mentor involve?
The above page should have a link/button to let you apply as a co-mentor and when you do that it should explain the requirements in detail. I think though that the time you will actually spend on mentoring depends a lot on the intern that will be selected and on how much time you and I will be willing to spend.
Thanks!
Elijah NewrenRe: Git in Outreachy?
On Thu, Sep 17, 2020 at 2:47 AM Christian Couder <christian.couder@gmail.com> wrote:
> > On Wed, Sep 16, 2020 at 11:01 AM Christian Couder > <christian.couder@gmail.com> wrote: > > > On Wed, Sep 2, 2020 at 10:50 AM Johannes Schindelin > > <Johannes.Schindelin@gmx.de> wrote: > > > > > As to projects, I would like to believe that > > > https://github.com/gitgitgadget/git/issues has grown into a useful > > > resource. > > > > Thanks for the useful resource! > > > > I would be interested in mentoring, or better co-mentoring, the > > following projects: > > > > - Accelerate rename detection and range-diff > > (https://github.com/gitgitgadget/git/issues/519): ideally I would > > co-mentor with someone a bit familiar with the suggested algorithms. > > Proposed on Outreachy's website: > > https://www.outreachy.org/outreachy-december-2020-internship-round/communities/git/accelerate-rename-detection-and-the-range-diff-com/cfp/
As a heads up, I'm going to be sending many patches modifying quite a wide range of diffcore-rename.c in the coming months for accelerating rename detection. Maybe I'll get them all upstreamed before outreachy starts, but that's not so clear. As I mentioned in the gitgitgadget issue, the ideas outlined there and the methods I implemented are different and complementary, but there is a pretty large risk of conflicts we need to resolve if I don't finish landing all my patches first.
> > > - Add support for drop!/reword! commits to `git rebase -i` > > (https://github.com/gitgitgadget/git/issues/259, > > https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/) > > - Invent a way to retain reflogs for a while after the ref was deleted > > (https://github.com/gitgitgadget/git/issues/236): I guess this might > > be implemented as part of the new `git maintenance` builtin. > > I will also likely submit a proposal for one of the above projects.
Christian CouderRe: Git in Outreachy?
On Thu, Sep 17, 2020 at 5:35 PM Elijah Newren <newren@gmail.com> wrote:
> > On Thu, Sep 17, 2020 at 2:47 AM Christian Couder > <christian.couder@gmail.com> wrote:
> > Proposed on Outreachy's website: > > > > https://www.outreachy.org/outreachy-december-2020-internship-round/communities/git/accelerate-rename-detection-and-the-range-diff-com/cfp/ > > As a heads up, I'm going to be sending many patches modifying quite a > wide range of diffcore-rename.c in the coming months for accelerating > rename detection. Maybe I'll get them all upstreamed before outreachy > starts, but that's not so clear.
It starts at the beginning of December, so I think there is still time for you to get them upstreamed.
> As I mentioned in the gitgitgadget > issue, the ideas outlined there and the methods I implemented are > different and complementary, but there is a pretty large risk of > conflicts we need to resolve if I don't finish landing all my patches > first.
It could be a learning experience anyway for the intern, and in my experience it has never been a big problem before, so I am not very worried about this.
Thanks for the heads up!
> > > > > - Add support for drop!/reword! commits to `git rebase -i` > > > (https://github.com/gitgitgadget/git/issues/259, > > > https://public-inbox.org/git/alpine.DEB.2.21.1.1710151754070.40514@virtualbox/) > > > - Invent a way to retain reflogs for a while after the ref was deleted > > > (https://github.com/gitgitgadget/git/issues/236): I guess this might > > > be implemented as part of the new `git maintenance` builtin. > > > > I will also likely submit a proposal for one of the above projects.
Kaartic SivaraamRe: Git in Outreachy?
On 16-09-2020 14:31, Christian Couder wrote:
> > - Accelerate rename detection and range-diff > (https://github.com/gitgitgadget/git/issues/519): ideally I would > co-mentor with someone a bit familiar with the suggested algorithms.
I just applied to be a co-mentor for this project. I'm not familiar with the suggested algorithms right now but I hope I'll be able to get familiar with them over time. If someone else more suitable for the project could volunteer, I wouldn't mind stepping aside :)
Thanks, Sivaraam
Christian CouderRe: Git in Outreachy?
Hi Kaartic,
On Sun, Sep 27, 2020 at 6:59 PM Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> > On 16-09-2020 14:31, Christian Couder wrote: > > > > - Accelerate rename detection and range-diff > > (https://github.com/gitgitgadget/git/issues/519): ideally I would > > co-mentor with someone a bit familiar with the suggested algorithms. > > I just applied to be a co-mentor for this project. I'm not familiar with > the suggested algorithms right now but I hope I'll be able to get > familiar with them over time. If someone else more suitable for the > project could volunteer, I wouldn't mind stepping aside :)
Thanks for volunteering!
In the meantime I have asked GitLab if they could fund one intern.
Best, Christian.
Christian CouderRe: Git in Outreachy?
Hi everyone,
On Sun, Sep 27, 2020 at 11:16 PM Christian Couder <christian.couder@gmail.com> wrote:
> > In the meantime I have asked GitLab if they could fund one intern.
GitLab approved funding one intern, so we now have funding for one intern for each of our 3 Outreachy projects. I updated the "funding" information related to Git on Outrachy's website accordingly.
Best, Christian.
Kaartic SivaraamRe: Git in Outreachy?
On 28-08-2020 12:26, Jeff King wrote:
> Are we interested in participating in the December 2020 round of > Outreachy? The community application period is now open. > > I can look into lining up funding, but we'd also need: > > - volunteers to act as mentors >
I'm willing to co-mentor a project for this term. I don't have any particular preference of projects, though.
> I would appreciate help to find project ideas though. Are there still > scripts that are worth converting to C (excluding git-bisect.sh and > git-submodule.sh that are still worked on)?
I think Dscho's e-mail linked below gives a nice overview of the various scripts and their likely status as of Jan2020:
https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/
I'm guessing only the status of submodule has changed as it's being worked on now.
-- Sivaraam
Johannes SchindelinRe: Git in Outreachy?
Hi Kaartic,
On Mon, 7 Sep 2020, Kaartic Sivaraam wrote:
> On 28-08-2020 12:26, Jeff King wrote: > > Are we interested in participating in the December 2020 round of > > Outreachy? The community application period is now open. > > > > I can look into lining up funding, but we'd also need: > > > > - volunteers to act as mentors > > > > I'm willing to co-mentor a project for this term. I don't have any > particular preference of projects, though. > > > I would appreciate help to find project ideas though. Are there still > > scripts that are worth converting to C (excluding git-bisect.sh and > > git-submodule.sh that are still worked on)? > > I think Dscho's e-mail linked below gives a nice overview of the various > scripts and their likely status as of Jan2020: > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/ > > I'm guessing only the status of submodule has changed as it's being > worked on now.
No, not quite. The `git-merge-*.sh` ones I called "trivial" are already being worked on by Alban Gruin: https://lore.kernel.org/git/20200901105705.6059-1-alban.gruin@gmail.com/
And `git-legacy-stash.sh` is no more, as of v2.27.0~180^2.
But yes, other than that, my summary still holds.
Ciao, Dscho
Christian CouderRe: Git in Outreachy?
Hi Dscho and Kaartic,
On Mon, Sep 7, 2020 at 8:55 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 7 Sep 2020, Kaartic Sivaraam wrote: > > > On 28-08-2020 12:26, Jeff King wrote: > > > Are we interested in participating in the December 2020 round of > > > Outreachy? The community application period is now open. > > > > > > I can look into lining up funding, but we'd also need: > > > > > > - volunteers to act as mentors > > > > > > > I'm willing to co-mentor a project for this term. I don't have any > > particular preference of projects, though.
Thanks!
> > > I would appreciate help to find project ideas though. Are there still > > > scripts that are worth converting to C (excluding git-bisect.sh and > > > git-submodule.sh that are still worked on)? > > > > I think Dscho's e-mail linked below gives a nice overview of the various > > scripts and their likely status as of Jan2020: > > > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/ > > > > I'm guessing only the status of submodule has changed as it's being > > worked on now. > > No, not quite. The `git-merge-*.sh` ones I called "trivial" are already > being worked on by Alban Gruin: > https://lore.kernel.org/git/20200901105705.6059-1-alban.gruin@gmail.com/ > > And `git-legacy-stash.sh` is no more, as of v2.27.0~180^2. > > But yes, other than that, my summary still holds.
To summarize more, it seems to me that only the following scripts could be worth converting:
git-difftool--helper.sh git-mergetool--lib.sh git-mergetool.sh
I wonder if they are really worth converting though, as they should probably all be converted together and we would likely also need to convert the scripts in mergetools/ at the same time. And then there should be a way to still easily configure things for users. So perhaps a better way to approach this would be first to convert the scripts in mergetools/ into config files.
Best, Christian.
Johannes SchindelinRe: Git in Outreachy?
Hi Christian,
On Wed, 16 Sep 2020, Christian Couder wrote:
> On Mon, Sep 7, 2020 at 8:55 PM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > On Mon, 7 Sep 2020, Kaartic Sivaraam wrote: > > > > > On 28-08-2020 12:26, Jeff King wrote: > > > > > > > I would appreciate help to find project ideas though. Are there > > > > still scripts that are worth converting to C (excluding > > > > git-bisect.sh and git-submodule.sh that are still worked on)? > > > > > > I think Dscho's e-mail linked below gives a nice overview of the > > > various scripts and their likely status as of Jan2020: > > > > > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/ > > > > > > I'm guessing only the status of submodule has changed as it's being > > > worked on now. > > > > No, not quite. The `git-merge-*.sh` ones I called "trivial" are already > > being worked on by Alban Gruin: > > https://lore.kernel.org/git/20200901105705.6059-1-alban.gruin@gmail.com/ > > > > And `git-legacy-stash.sh` is no more, as of v2.27.0~180^2. > > > > But yes, other than that, my summary still holds. > > To summarize more, it seems to me that only the following scripts > could be worth converting: > > git-difftool--helper.sh > git-mergetool--lib.sh > git-mergetool.sh > > I wonder if they are really worth converting though, as they should > probably all be converted together and we would likely also need to > convert the scripts in mergetools/ at the same time. And then there > should be a way to still easily configure things for users. So perhaps > a better way to approach this would be first to convert the scripts in > mergetools/ into config files.
The biggest problem is that they're all entangled. `git-difftool--helper.sh` sources `git-mergetool--lib.sh` and uses quite a bit of its machinery.
As to converting the scripts to config files, I'd rather have them hard-coded in the source code. Something along those lines:
struct mergetool {
const char *can_merge;
const char *can_diff;
const char *diff_cmd
const char *merge_cmd;
const char *translate_merge_tool_path;
const char *list_tool_variants;
const char *exit_code_trustable;
} araxis = {
.diff_cmd = "\"$merge_tool_path"\ -wait -2 \"$LOCAL\" \"$REMOTE\" >/dev/null 2>&1",
.merge_cmd = "if $base_present\n"
"then\n"
" \"$merge_tool_path\" -wait -merge -3 -a1"
" \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" >/dev/null 2>&1\n"
"else\n"
" \"$merge_tool_path\" -wait -2"
" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" >/dev/null 2>&1\n"
"fi",
.translate_merge_tool_path = "echo compare"
}, [...]I would then probably try to implement the bare minimum for the `difftool--helper` command to work (re-implementing in C only the parts of `mergetool--lib` that are necessary), and only in a next patch series work on `mergetool`.
Ciao, Dscho
Christian CouderRe: Git in Outreachy?
Hi Dscho,
On Wed, Sep 16, 2020 at 10:27 PM Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Wed, 16 Sep 2020, Christian Couder wrote:
> > To summarize more, it seems to me that only the following scripts > > could be worth converting: > > > > git-difftool--helper.sh > > git-mergetool--lib.sh > > git-mergetool.sh > > > > I wonder if they are really worth converting though, as they should > > probably all be converted together and we would likely also need to > > convert the scripts in mergetools/ at the same time. And then there > > should be a way to still easily configure things for users. So perhaps > > a better way to approach this would be first to convert the scripts in > > mergetools/ into config files. > > The biggest problem is that they're all entangled. > `git-difftool--helper.sh` sources `git-mergetool--lib.sh` and uses quite a > bit of its machinery.
Yeah, I agree this is an issue.
> As to converting the scripts to config files, I'd rather have them > hard-coded in the source code.
I am not sure what are the pros and cons of hardcoding vs config files in this case.
My opinion is that config files would make it easier for people to contribute what's needed for new tools, while hardcoding might make it more easily extensible for us and might reduce backward compatibility issues.
> I would then probably try to implement the bare minimum for the > `difftool--helper` command to work (re-implementing in C only the parts of > `mergetool--lib` that are necessary), and only in a next patch series work > on `mergetool`.
Thanks for your opinion on this. For now I think it needs to be discussed more before we could suggest it as a project.
Best, Christian.
Johannes SchindelinRe: Git in Outreachy?
Hi Christian,
On Sat, 19 Sep 2020, Christian Couder wrote:
> On Wed, Sep 16, 2020 at 10:27 PM Johannes Schindelin > <Johannes.Schindelin@gmx.de> wrote: > > > On Wed, 16 Sep 2020, Christian Couder wrote: > > > > To summarize more, it seems to me that only the following scripts > > > could be worth converting: > > > > > > git-difftool--helper.sh > > > git-mergetool--lib.sh > > > git-mergetool.sh > > > > > > I wonder if they are really worth converting though, as they should > > > probably all be converted together and we would likely also need to > > > convert the scripts in mergetools/ at the same time. And then there > > > should be a way to still easily configure things for users. So perhaps > > > a better way to approach this would be first to convert the scripts in > > > mergetools/ into config files. > > > > The biggest problem is that they're all entangled. > > `git-difftool--helper.sh` sources `git-mergetool--lib.sh` and uses quite a > > bit of its machinery. > > Yeah, I agree this is an issue. > > > As to converting the scripts to config files, I'd rather have them > > hard-coded in the source code. > > I am not sure what are the pros and cons of hardcoding vs config files > in this case.
The thing is: `make install` does not install a Git config. That's why I want the defaults hard-coded.
Of course, it should be possible to override those hard-coded defaults via the config. That should go without saying.
Ciao, Dscho
> My opinion is that config files would make it easier for people to > contribute what's needed for new tools, while hardcoding might make it > more easily extensible for us and might reduce backward compatibility > issues. > > > I would then probably try to implement the bare minimum for the > > `difftool--helper` command to work (re-implementing in C only the parts of > > `mergetool--lib` that are necessary), and only in a next patch series work > > on `mergetool`. > > Thanks for your opinion on this. For now I think it needs to be > discussed more before we could suggest it as a project. > > Best, > Christian. >
Kaartic SivaraamRe: Git in Outreachy?
On 07-09-2020 00:26, Kaartic Sivaraam wrote:>
>> I would appreciate help to find project ideas though. Are there still >> scripts that are worth converting to C (excluding git-bisect.sh and >> git-submodule.sh that are still worked on)? > > I think Dscho's e-mail linked below gives a nice overview of the various > scripts and their likely status as of Jan2020: > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/ > > I'm guessing only the status of submodule has changed as it's being > worked on now. >
After giving it a second thought, I believe I should take back my word about the git-submodule status changing. There still seems to be some work left for it. To be clear,
- there's 'add', whose conversion is currently stalled [1] - there's 'update', which still has a decent amount of code [2] in the shell script. - we still have to complete the conversion completely converting moving the rest of the bits from `git-submodule.sh` to C which is mostly just the option parsing. This might be more trickier than it sounds as we would've to ensure the we don't accidentally change behaviour of the options when moving the option parsing to C.
There's also an e-mail from Junio which is relevant [3]
I'm not sure if this would be enough for a complete project on it's own. I'm also not sure whether 'add' would get converted in the meantime. In any case, I believe we could add a few other small refactoring projects to make up for the rest of the period. For instance,
- Replace more instances of `the_index` and `the_repository` (https://github.com/gitgitgadget/git/issues/379)
- Turn the `fetch_if_missing` global into a field of `struct repository` (https://github.com/gitgitgadget/git/issues/251)
- Possibly others from #leftoverbits
Thoughts?
References === [1]: http://public-inbox.org/git/20200824090359.403944-1-shouryashukla.oo@gmail.com/ [2]: https://github.com/git/git/blob/v2.28.0/git-submodule.sh#L554-L713 [3]: https://lore.kernel.org/git/xmqqtuzrrk8r.fsf@gitster.c.googlers.com/
-- Sivaraam
Christian CouderRe: Git in Outreachy?
On Sun, Sep 20, 2020 at 6:31 PM Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:
> > On 07-09-2020 00:26, Kaartic Sivaraam wrote:> > >> I would appreciate help to find project ideas though. Are there still > >> scripts that are worth converting to C (excluding git-bisect.sh and > >> git-submodule.sh that are still worked on)? > > > > I think Dscho's e-mail linked below gives a nice overview of the various > > scripts and their likely status as of Jan2020: > > > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/ > > > > I'm guessing only the status of submodule has changed as it's being > > worked on now. > > After giving it a second thought, I believe I should take back my word > about the git-submodule status changing. There still seems to be some > work left for it.
Yeah, there is some work left, but Shourya said he was interested in continuing to work on it.
> To be clear, > > - there's 'add', whose conversion is currently stalled [1]
Yeah, but it hasn't been stalled for a long time, and sometimes it takes time after the GSoC or Outreachy period for former GSoC students or Outreachy interns to resume their work.
> - there's 'update', which still has a decent amount of code [2] > in the shell script. > - we still have to complete the conversion completely converting > moving the rest of the bits from `git-submodule.sh` to C which is > mostly just the option parsing. This might be more trickier than > it sounds as we would've to ensure the we don't accidentally > change behaviour of the options when moving the option parsing to C. > > There's also an e-mail from Junio which is relevant [3] > > I'm not sure if this would be enough for a complete project on it's own. > I'm also not sure whether 'add' would get converted in the meantime. In > any case, I believe we could add a few other small refactoring projects > to make up for the rest of the period. For instance, > > - Replace more instances of `the_index` and `the_repository` > (https://github.com/gitgitgadget/git/issues/379) > > - Turn the `fetch_if_missing` global into a field of `struct repository` > (https://github.com/gitgitgadget/git/issues/251) > > - Possibly others from #leftoverbits > > Thoughts?
Yeah, without 'add' we would have enough related issues for another project. I would prefer though that we wait for at least 3 months without any progress before suggesting them as a project. That's what we usually do and I think it's the right thing to do.
Kaartic SivaraamRe: Git in Outreachy?
On 21-09-2020 09:52, Christian Couder wrote:
> On Sun, Sep 20, 2020 at 6:31 PM Kaartic Sivaraam > <kaartic.sivaraam@gmail.com> wrote: >> >> On 07-09-2020 00:26, Kaartic Sivaraam wrote:> >>> >>> I'm guessing only the status of submodule has changed as it's being >>> worked on now. >> >> After giving it a second thought, I believe I should take back my word >> about the git-submodule status changing. There still seems to be some >> work left for it. > > Yeah, there is some work left, but Shourya said he was interested in > continuing to work on it. >
Yeah, he's most welcome to resume his work :)
>> To be clear, >> >> - there's 'add', whose conversion is currently stalled [1] > > Yeah, but it hasn't been stalled for a long time, and sometimes it > takes time after the GSoC or Outreachy period for former GSoC students > or Outreachy interns to resume their work. >
Ok. Got it.
>> - there's 'update', which still has a decent amount of code [2] >> in the shell script. >> - we still have to complete the conversion completely converting >> moving the rest of the bits from `git-submodule.sh` to C which is >> mostly just the option parsing. This might be more trickier than >> it sounds as we would've to ensure the we don't accidentally >> change behaviour of the options when moving the option parsing to C. >> >> There's also an e-mail from Junio which is relevant [3] >> >> I'm not sure if this would be enough for a complete project on it's own. >> I'm also not sure whether 'add' would get converted in the meantime. In >> any case, I believe we could add a few other small refactoring projects >> to make up for the rest of the period. For instance, >> >> - Replace more instances of `the_index` and `the_repository` >> (https://github.com/gitgitgadget/git/issues/379) >> >> - Turn the `fetch_if_missing` global into a field of `struct repository` >> (https://github.com/gitgitgadget/git/issues/251) >> >> - Possibly others from #leftoverbits >> >> Thoughts? > > Yeah, without 'add' we would have enough related issues for another > project. I would prefer though that we wait for at least 3 months > without any progress before suggesting them as a project. That's what > we usually do and I think it's the right thing to do. >
Ok. That makes sense. I also missed the fact that Shourya had also expressed interested in converting the 'update' part of submodule in his final GSoC report [A]. So, I agree that it's too early to propose the rest of the submodule work for Outreachy.
Thanks.
References === [A]: https://shouryashukla.blogspot.com/2020/08/the-final-report.html
-- Sivaraam
Shourya ShuklaRe: Git in Outreachy?
On Mon, Sep 21, 2020 at 9:52 AM Christian Couder <christian.couder@gmail.com> wrote:
> > On Sun, Sep 20, 2020 at 6:31 PM Kaartic Sivaraam > <kaartic.sivaraam@gmail.com> wrote: > > > > On 07-09-2020 00:26, Kaartic Sivaraam wrote:> > > >> I would appreciate help to find project ideas though. Are there still > > >> scripts that are worth converting to C (excluding git-bisect.sh and > > >> git-submodule.sh that are still worked on)? > > > > > > I think Dscho's e-mail linked below gives a nice overview of the various > > > scripts and their likely status as of Jan2020: > > > > > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/ > > > > > > I'm guessing only the status of submodule has changed as it's being > > > worked on now. > > > > After giving it a second thought, I believe I should take back my word > > about the git-submodule status changing. There still seems to be some > > work left for it. > > Yeah, there is some work left, but Shourya said he was interested in > continuing to work on it.
Yeah, I am a bit busy right now catching up with the classes and assignments in my college. I will try to deliver a follow-up v2 to 'submodule add' in a couple of weeks.
> > To be clear, > > > > - there's 'add', whose conversion is currently stalled [1] > > Yeah, but it hasn't been stalled for a long time, and sometimes it > takes time after the GSoC or Outreachy period for former GSoC students > or Outreachy interns to resume their work. > > > - there's 'update', which still has a decent amount of code [2] > > in the shell script. > > - we still have to complete the conversion completely converting > > moving the rest of the bits from `git-submodule.sh` to C which is > > mostly just the option parsing. This might be more trickier than > > it sounds as we would've to ensure the we don't accidentally > > change behaviour of the options when moving the option parsing to C. > > > > There's also an e-mail from Junio which is relevant [3] > > > > I'm not sure if this would be enough for a complete project on it's own. > > I'm also not sure whether 'add' would get converted in the meantime. In > > any case, I believe we could add a few other small refactoring projects > > to make up for the rest of the period. For instance, > > > > - Replace more instances of `the_index` and `the_repository` > > (https://github.com/gitgitgadget/git/issues/379) > > > > - Turn the `fetch_if_missing` global into a field of `struct repository` > > (https://github.com/gitgitgadget/git/issues/251) > > > > - Possibly others from #leftoverbits > > > > Thoughts? > > Yeah, without 'add' we would have enough related issues for another > project. I would prefer though that we wait for at least 3 months > without any progress before suggesting them as a project. That's what > we usually do and I think it's the right thing to do.
If we are talking about submodules, then one project can be to improve the parsing of 'submodule--helper.c' and try to eliminate the shell scripting for this purpose. Another thing which can be done is to clean up the helper sub-commands which were created to aid the conversion (iff they are of little to no use now). I do not have an exact idea if the "improve parsing" and conversion of a couple of subcommands* will be a project big enough for Outreachy or not though.
*'submodule update' is a bit messed up right now and will need a solid conversion to C since some of its fragments are there in the C code while some aren't. Also, the shell code of this subcommand is still there meaning that the fragments do not play any direct role in the functioning of the subcommand. I can pass on the conversion of 'update' to Outreachy if the addition of this will amount to a complete project for a potential Outreachy intern.
Regards, Shourya Shukla