git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* Git in Outreachy?
@ 2020-08-28  6:56 Jeff King
  2020-08-31  6:55 ` Christian Couder
                   ` (4 more replies)
  0 siblings, 5 replies; 67+ messages in thread
From: Jeff King @ 2020-08-28  6:56 UTC (permalink / raw)
  To: git; +Cc: Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-28  6:56 Git in Outreachy? Jeff King
@ 2020-08-31  6:55 ` Christian Couder
  2020-09-03  6:00   ` Jonathan Nieder
  2020-09-16  6:42   ` Christian Couder
  2020-08-31 17:41 ` Junio C Hamano
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 67+ messages in thread
From: Christian Couder @ 2020-08-31  6:55 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Christian Couder, Johannes Schindelin

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?

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-28  6:56 Git in Outreachy? Jeff King
  2020-08-31  6:55 ` Christian Couder
@ 2020-08-31 17:41 ` Junio C Hamano
  2020-08-31 18:05 ` Emily Shaffer
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 67+ messages in thread
From: Junio C Hamano @ 2020-08-31 17:41 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Christian Couder, Johannes Schindelin

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-28  6:56 Git in Outreachy? Jeff King
  2020-08-31  6:55 ` Christian Couder
  2020-08-31 17:41 ` Junio C Hamano
@ 2020-08-31 18:05 ` Emily Shaffer
  2020-09-01 12:51   ` Jeff King
  2020-09-02  4:00 ` Johannes Schindelin
  2020-09-06 18:56 ` Kaartic Sivaraam
  4 siblings, 1 reply; 67+ messages in thread
From: Emily Shaffer @ 2020-08-31 18:05 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-31 18:05 ` Emily Shaffer
@ 2020-09-01 12:51   ` Jeff King
  2020-09-03  5:41     ` Jeff King
  2020-09-16  8:45     ` Christian Couder
  0 siblings, 2 replies; 67+ messages in thread
From: Jeff King @ 2020-09-01 12:51 UTC (permalink / raw)
  To: Emily Shaffer; +Cc: git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-28  6:56 Git in Outreachy? Jeff King
                   ` (2 preceding siblings ...)
  2020-08-31 18:05 ` Emily Shaffer
@ 2020-09-02  4:00 ` Johannes Schindelin
  2020-09-16  9:01   ` Christian Couder
  2020-09-06 18:56 ` Kaartic Sivaraam
  4 siblings, 1 reply; 67+ messages in thread
From: Johannes Schindelin @ 2020-09-02  4:00 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Christian Couder

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-01 12:51   ` Jeff King
@ 2020-09-03  5:41     ` Jeff King
  2020-09-15 17:35       ` Jeff King
  2020-09-16  8:45     ` Christian Couder
  1 sibling, 1 reply; 67+ messages in thread
From: Jeff King @ 2020-09-03  5:41 UTC (permalink / raw)
  To: Emily Shaffer; +Cc: git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-31  6:55 ` Christian Couder
@ 2020-09-03  6:00   ` Jonathan Nieder
  2020-09-04 14:14     ` Philip Oakley
                       ` (2 more replies)
  2020-09-16  6:42   ` Christian Couder
  1 sibling, 3 replies; 67+ messages in thread
From: Jonathan Nieder @ 2020-09-03  6:00 UTC (permalink / raw)
  To: Christian Couder; +Cc: Jeff King, git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-03  6:00   ` Jonathan Nieder
@ 2020-09-04 14:14     ` Philip Oakley
  2020-09-07 18:49       ` Johannes Schindelin
  2020-09-09 18:26     ` Taylor Blau
  2020-09-16  9:12     ` Christian Couder
  2 siblings, 1 reply; 67+ messages in thread
From: Philip Oakley @ 2020-09-04 14:14 UTC (permalink / raw)
  To: Jonathan Nieder, Christian Couder
  Cc: Jeff King, git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-28  6:56 Git in Outreachy? Jeff King
                   ` (3 preceding siblings ...)
  2020-09-02  4:00 ` Johannes Schindelin
@ 2020-09-06 18:56 ` Kaartic Sivaraam
  2020-09-07 18:55   ` Johannes Schindelin
  2020-09-20 16:31   ` Kaartic Sivaraam
  4 siblings, 2 replies; 67+ messages in thread
From: Kaartic Sivaraam @ 2020-09-06 18:56 UTC (permalink / raw)
  To: Jeff King, git; +Cc: Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-04 14:14     ` Philip Oakley
@ 2020-09-07 18:49       ` Johannes Schindelin
  2020-09-16 15:16         ` Philip Oakley
  0 siblings, 1 reply; 67+ messages in thread
From: Johannes Schindelin @ 2020-09-07 18:49 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Jonathan Nieder, Christian Couder, Jeff King, git, Christian Couder

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
>

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-06 18:56 ` Kaartic Sivaraam
@ 2020-09-07 18:55   ` Johannes Schindelin
  2020-09-16  9:35     ` Christian Couder
  2020-09-20 16:31   ` Kaartic Sivaraam
  1 sibling, 1 reply; 67+ messages in thread
From: Johannes Schindelin @ 2020-09-07 18:55 UTC (permalink / raw)
  To: Kaartic Sivaraam; +Cc: Jeff King, git, Christian Couder

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-03  6:00   ` Jonathan Nieder
  2020-09-04 14:14     ` Philip Oakley
@ 2020-09-09 18:26     ` Taylor Blau
  2020-09-10  1:39       ` Jonathan Nieder
  2020-09-16  9:12     ` Christian Couder
  2 siblings, 1 reply; 67+ messages in thread
From: Taylor Blau @ 2020-09-09 18:26 UTC (permalink / raw)
  To: Jonathan Nieder
  Cc: Christian Couder, Jeff King, git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-09 18:26     ` Taylor Blau
@ 2020-09-10  1:39       ` Jonathan Nieder
  2020-09-10  2:19         ` Taylor Blau
  0 siblings, 1 reply; 67+ messages in thread
From: Jonathan Nieder @ 2020-09-10  1:39 UTC (permalink / raw)
  To: Taylor Blau
  Cc: Christian Couder, Jeff King, git, Christian Couder, Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-10  1:39       ` Jonathan Nieder
@ 2020-09-10  2:19         ` Taylor Blau
  0 siblings, 0 replies; 67+ messages in thread
From: Taylor Blau @ 2020-09-10  2:19 UTC (permalink / raw)
  To: Jonathan Nieder
  Cc: Taylor Blau, Christian Couder, Jeff King, git, Christian Couder,
	Johannes Schindelin

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-03  5:41     ` Jeff King
@ 2020-09-15 17:35       ` Jeff King
  2020-09-15 17:55         ` Kaartic Sivaraam
  2020-09-19  8:12         ` Christian Couder
  0 siblings, 2 replies; 67+ messages in thread
From: Jeff King @ 2020-09-15 17:35 UTC (permalink / raw)
  To: git
  Cc: Emily Shaffer, Christian Couder, Johannes Schindelin,
	Jonathan Nieder, Philip Oakley, Taylor Blau, Kaartic Sivaraam

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-15 17:35       ` Jeff King
@ 2020-09-15 17:55         ` Kaartic Sivaraam
  2020-09-15 18:02           ` Jeff King
  2020-09-19  8:12         ` Christian Couder
  1 sibling, 1 reply; 67+ messages in thread
From: Kaartic Sivaraam @ 2020-09-15 17:55 UTC (permalink / raw)
  To: Jeff King, git
  Cc: Emily Shaffer, Christian Couder, Johannes Schindelin,
	Jonathan Nieder, Philip Oakley, Taylor Blau

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-15 17:55         ` Kaartic Sivaraam
@ 2020-09-15 18:02           ` Jeff King
  0 siblings, 0 replies; 67+ messages in thread
From: Jeff King @ 2020-09-15 18:02 UTC (permalink / raw)
  To: Kaartic Sivaraam
  Cc: git, Emily Shaffer, Christian Couder, Johannes Schindelin,
	Jonathan Nieder, Philip Oakley, Taylor Blau

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-08-31  6:55 ` Christian Couder
  2020-09-03  6:00   ` Jonathan Nieder
@ 2020-09-16  6:42   ` Christian Couder
  1 sibling, 0 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-16  6:42 UTC (permalink / raw)
  To: Jeff King; +Cc: git, Christian Couder, Johannes Schindelin

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-01 12:51   ` Jeff King
  2020-09-03  5:41     ` Jeff King
@ 2020-09-16  8:45     ` Christian Couder
  1 sibling, 0 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-16  8:45 UTC (permalink / raw)
  To: Jeff King; +Cc: Emily Shaffer, git, Christian Couder, Johannes Schindelin

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-02  4:00 ` Johannes Schindelin
@ 2020-09-16  9:01   ` Christian Couder
  2020-09-16  9:45     ` Phillip Wood
                       ` (2 more replies)
  0 siblings, 3 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-16  9:01 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jeff King, git, Christian Couder

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-03  6:00   ` Jonathan Nieder
  2020-09-04 14:14     ` Philip Oakley
  2020-09-09 18:26     ` Taylor Blau
@ 2020-09-16  9:12     ` Christian Couder
  2 siblings, 0 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-16  9:12 UTC (permalink / raw)
  To: Jonathan Nieder; +Cc: Jeff King, git, Christian Couder, Johannes Schindelin

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-07 18:55   ` Johannes Schindelin
@ 2020-09-16  9:35     ` Christian Couder
  2020-09-16 20:27       ` Johannes Schindelin
  0 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2020-09-16  9:35 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Kaartic Sivaraam, Jeff King, git, Christian Couder

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16  9:01   ` Christian Couder
@ 2020-09-16  9:45     ` Phillip Wood
  2020-09-17  9:43     ` Christian Couder
  2020-09-27 16:59     ` Kaartic Sivaraam
  2 siblings, 0 replies; 67+ messages in thread
From: Phillip Wood @ 2020-09-16  9:45 UTC (permalink / raw)
  To: Christian Couder, Johannes Schindelin; +Cc: Jeff King, git, Christian Couder

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.
> 

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-07 18:49       ` Johannes Schindelin
@ 2020-09-16 15:16         ` Philip Oakley
  2020-09-16 18:43           ` Johannes Schindelin
  0 siblings, 1 reply; 67+ messages in thread
From: Philip Oakley @ 2020-09-16 15:16 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Jonathan Nieder, Christian Couder, Jeff King, git, Christian Couder

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
>>


^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16 15:16         ` Philip Oakley
@ 2020-09-16 18:43           ` Johannes Schindelin
  2020-09-17 14:42             ` Philip Oakley
  0 siblings, 1 reply; 67+ messages in thread
From: Johannes Schindelin @ 2020-09-16 18:43 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Jonathan Nieder, Christian Couder, Jeff King, git, Christian Couder

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16  9:35     ` Christian Couder
@ 2020-09-16 20:27       ` Johannes Schindelin
  2020-09-19  7:40         ` Christian Couder
  0 siblings, 1 reply; 67+ messages in thread
From: Johannes Schindelin @ 2020-09-16 20:27 UTC (permalink / raw)
  To: Christian Couder; +Cc: Kaartic Sivaraam, Jeff King, git, Christian Couder

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16  9:01   ` Christian Couder
  2020-09-16  9:45     ` Phillip Wood
@ 2020-09-17  9:43     ` Christian Couder
  2020-09-17 10:14       ` Phillip Wood
  2020-09-17 15:34       ` Elijah Newren
  2020-09-27 16:59     ` Kaartic Sivaraam
  2 siblings, 2 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-17  9:43 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Jeff King, git, Christian Couder

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-17  9:43     ` Christian Couder
@ 2020-09-17 10:14       ` Phillip Wood
  2020-09-18  8:37         ` Christian Couder
  2020-09-17 15:34       ` Elijah Newren
  1 sibling, 1 reply; 67+ messages in thread
From: Phillip Wood @ 2020-09-17 10:14 UTC (permalink / raw)
  To: Christian Couder, Johannes Schindelin; +Cc: Jeff King, git, Christian Couder

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.
> 

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16 18:43           ` Johannes Schindelin
@ 2020-09-17 14:42             ` Philip Oakley
  0 siblings, 0 replies; 67+ messages in thread
From: Philip Oakley @ 2020-09-17 14:42 UTC (permalink / raw)
  To: Johannes Schindelin
  Cc: Jonathan Nieder, Christian Couder, Jeff King, git, Christian Couder

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



^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-17  9:43     ` Christian Couder
  2020-09-17 10:14       ` Phillip Wood
@ 2020-09-17 15:34       ` Elijah Newren
  2020-09-18  8:42         ` Christian Couder
  1 sibling, 1 reply; 67+ messages in thread
From: Elijah Newren @ 2020-09-17 15:34 UTC (permalink / raw)
  To: Christian Couder; +Cc: Johannes Schindelin, Jeff King, git, Christian Couder

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-17 10:14       ` Phillip Wood
@ 2020-09-18  8:37         ` Christian Couder
  0 siblings, 0 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-18  8:37 UTC (permalink / raw)
  To: Phillip Wood; +Cc: Johannes Schindelin, Jeff King, git, Christian Couder

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!

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-17 15:34       ` Elijah Newren
@ 2020-09-18  8:42         ` Christian Couder
  0 siblings, 0 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-18  8:42 UTC (permalink / raw)
  To: Elijah Newren; +Cc: Johannes Schindelin, Jeff King, git, Christian Couder

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16 20:27       ` Johannes Schindelin
@ 2020-09-19  7:40         ` Christian Couder
  2020-09-20 15:06           ` Johannes Schindelin
  0 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2020-09-19  7:40 UTC (permalink / raw)
  To: Johannes Schindelin; +Cc: Kaartic Sivaraam, Jeff King, git, Christian Couder

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-15 17:35       ` Jeff King
  2020-09-15 17:55         ` Kaartic Sivaraam
@ 2020-09-19  8:12         ` Christian Couder
  2020-09-19 15:10           ` Phillip Wood
  1 sibling, 1 reply; 67+ messages in thread
From: Christian Couder @ 2020-09-19  8:12 UTC (permalink / raw)
  To: Jeff King
  Cc: git, Emily Shaffer, Christian Couder, Johannes Schindelin,
	Jonathan Nieder, Philip Oakley, Taylor Blau, Kaartic Sivaraam,
	Phillip Wood

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.)

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-19  8:12         ` Christian Couder
@ 2020-09-19 15:10           ` Phillip Wood
  0 siblings, 0 replies; 67+ messages in thread
From: Phillip Wood @ 2020-09-19 15:10 UTC (permalink / raw)
  To: Christian Couder, Jeff King
  Cc: git, Emily Shaffer, Christian Couder, Johannes Schindelin,
	Jonathan Nieder, Philip Oakley, Taylor Blau, Kaartic Sivaraam,
	Phillip Wood

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.)
> 

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-19  7:40         ` Christian Couder
@ 2020-09-20 15:06           ` Johannes Schindelin
  0 siblings, 0 replies; 67+ messages in thread
From: Johannes Schindelin @ 2020-09-20 15:06 UTC (permalink / raw)
  To: Christian Couder; +Cc: Kaartic Sivaraam, Jeff King, git, Christian Couder

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.
>

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-06 18:56 ` Kaartic Sivaraam
  2020-09-07 18:55   ` Johannes Schindelin
@ 2020-09-20 16:31   ` Kaartic Sivaraam
  2020-09-21  4:22     ` Christian Couder
  1 sibling, 1 reply; 67+ messages in thread
From: Kaartic Sivaraam @ 2020-09-20 16:31 UTC (permalink / raw)
  To: git; +Cc: Christian Couder, Johannes Schindelin, Jeff King

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-20 16:31   ` Kaartic Sivaraam
@ 2020-09-21  4:22     ` Christian Couder
  2020-09-21  7:59       ` Kaartic Sivaraam
  2020-09-21 20:56       ` Shourya Shukla
  0 siblings, 2 replies; 67+ messages in thread
From: Christian Couder @ 2020-09-21  4:22 UTC (permalink / raw)
  To: Kaartic Sivaraam
  Cc: git, Christian Couder, Johannes Schindelin, Jeff King, Shourya Shukla

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-21  4:22     ` Christian Couder
@ 2020-09-21  7:59       ` Kaartic Sivaraam
  2020-09-21 20:56       ` Shourya Shukla
  1 sibling, 0 replies; 67+ messages in thread
From: Kaartic Sivaraam @ 2020-09-21  7:59 UTC (permalink / raw)
  To: Christian Couder
  Cc: git, Christian Couder, Johannes Schindelin, Jeff King, Shourya Shukla

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-21  4:22     ` Christian Couder
  2020-09-21  7:59       ` Kaartic Sivaraam
@ 2020-09-21 20:56       ` Shourya Shukla
  1 sibling, 0 replies; 67+ messages in thread
From: Shourya Shukla @ 2020-09-21 20:56 UTC (permalink / raw)
  To: Christian Couder
  Cc: Kaartic Sivaraam, git, Christian Couder, Johannes Schindelin, Jeff King

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-16  9:01   ` Christian Couder
  2020-09-16  9:45     ` Phillip Wood
  2020-09-17  9:43     ` Christian Couder
@ 2020-09-27 16:59     ` Kaartic Sivaraam
  2020-09-27 21:16       ` Christian Couder
  2 siblings, 1 reply; 67+ messages in thread
From: Kaartic Sivaraam @ 2020-09-27 16:59 UTC (permalink / raw)
  To: Christian Couder; +Cc: Jeff King, Christian Couder, Johannes Schindelin, git

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

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-27 16:59     ` Kaartic Sivaraam
@ 2020-09-27 21:16       ` Christian Couder
  2020-10-29 10:13         ` Christian Couder
  0 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2020-09-27 21:16 UTC (permalink / raw)
  To: Kaartic Sivaraam; +Cc: Jeff King, Christian Couder, Johannes Schindelin, git

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2020-09-27 21:16       ` Christian Couder
@ 2020-10-29 10:13         ` Christian Couder
  0 siblings, 0 replies; 67+ messages in thread
From: Christian Couder @ 2020-10-29 10:13 UTC (permalink / raw)
  To: Kaartic Sivaraam, Jeff King, Phillip Wood, Emily Shaffer,
	Jonathan Nieder, git

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.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-29 17:34       ` Taylor Blau
@ 2021-09-29 20:30         ` Taylor Blau
  0 siblings, 0 replies; 67+ messages in thread
From: Taylor Blau @ 2021-09-29 20:30 UTC (permalink / raw)
  To: Christian Couder
  Cc: Taylor Blau, git, Jeff King, Christian Couder, Emily Shaffer,
	Matheus Tavares Bernardino, ZheNing Hu

On Wed, Sep 29, 2021 at 01:34:08PM -0400, Taylor Blau wrote:
> > We still have only one project ("Unify ref-filter formats with other
> > pretty formats", that ZheNing and me are willing to co-mentor)
> > submitted though.
>
> I plan to submit and mentor a project myself. (I'm thinking that I'll do
> a grab-bag of bitmap-related items that I'd like to see implemented, but
> that may be too open-ended for a successful Outreachy project).

I think (open-ended as it may be) that I'll be able to provide the most
guidance for a bitmap-related project. I submitted that as a intern
project, which anybody logged in through the Outreachy site can view
here:

  https://www.outreachy.org/apply/project-selection/#git

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-29 14:18     ` Christian Couder
@ 2021-09-29 17:34       ` Taylor Blau
  2021-09-29 20:30         ` Taylor Blau
  0 siblings, 1 reply; 67+ messages in thread
From: Taylor Blau @ 2021-09-29 17:34 UTC (permalink / raw)
  To: Christian Couder
  Cc: Taylor Blau, git, Jeff King, Christian Couder, Emily Shaffer,
	Matheus Tavares Bernardino, ZheNing Hu

On Wed, Sep 29, 2021 at 04:18:43PM +0200, Christian Couder wrote:
> Hi Taylor and all,
>
> On Tue, Sep 21, 2021 at 11:26 PM Taylor Blau <me@ttaylorr.com> wrote:
>
> > > The project deadline of September 23rd is fast approaching, and we do
> > > not have any proposed projects or signed-up mentors.
> >
> > It looks like the deadline was extended to September 29th at 4pm UTC. So
> > we have a little less than an extra week. The below link is still the
> > right place to submit proposals:
> >
> >     https://www.outreachy.org/communities/cfp/git/
>
> So the deadline for mentors to submit projects has been extended again
> to Wednesday, October 6 at 4pm UTC.

Thanks for mentioning. I got an email from Sage announcing this
yesterday, but neglected to share it here.

> We still have only one project ("Unify ref-filter formats with other
> pretty formats", that ZheNing and me are willing to co-mentor)
> submitted though.

I plan to submit and mentor a project myself. (I'm thinking that I'll do
a grab-bag of bitmap-related items that I'd like to see implemented, but
that may be too open-ended for a successful Outreachy project).

GitHub is planning on sponsoring an intern, too, but I haven't finalized
the paperwork.

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-21 21:25   ` Taylor Blau
@ 2021-09-29 14:18     ` Christian Couder
  2021-09-29 17:34       ` Taylor Blau
  0 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2021-09-29 14:18 UTC (permalink / raw)
  To: Taylor Blau
  Cc: Taylor Blau, git, Jeff King, Christian Couder, Emily Shaffer,
	Matheus Tavares Bernardino, ZheNing Hu

Hi Taylor and all,

On Tue, Sep 21, 2021 at 11:26 PM Taylor Blau <me@ttaylorr.com> wrote:

> > The project deadline of September 23rd is fast approaching, and we do
> > not have any proposed projects or signed-up mentors.
>
> It looks like the deadline was extended to September 29th at 4pm UTC. So
> we have a little less than an extra week. The below link is still the
> right place to submit proposals:
>
>     https://www.outreachy.org/communities/cfp/git/

So the deadline for mentors to submit projects has been extended again
to Wednesday, October 6 at 4pm UTC.

We still have only one project ("Unify ref-filter formats with other
pretty formats", that ZheNing and me are willing to co-mentor)
submitted though.

I plan to submit another project that I will be willing to (co-)mentor
before the deadline.

It's confirmed that GitLab will sponsor one intern.

Best,
Christian.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-21 15:39           ` Christian Couder
@ 2021-09-22 15:01             ` ZheNing Hu
  0 siblings, 0 replies; 67+ messages in thread
From: ZheNing Hu @ 2021-09-22 15:01 UTC (permalink / raw)
  To: Christian Couder
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino

Christian Couder <christian.couder@gmail.com> 于2021年9月21日周二 下午11:39写道:
>
> On Tue, Sep 21, 2021 at 7:41 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > Christian Couder <christian.couder@gmail.com> 于2021年9月20日周一 下午11:15写道:
> > >
> > > On Mon, Sep 20, 2021 at 4:52 PM Christian Couder
> > > <christian.couder@gmail.com> wrote:
> > >
> > > > I will also prepare soon a page with a few micro-projects. Of course
> > > > more micro-project and regular project ideas are very welcome!
> > >
> > > So here is the page:
> > >
> > > https://git.github.io/Outreachy-23-Microprojects/
> > >
> >
> > s/Outreachy-23-Microprojects/Outreachy-22-Microprojects/
>
> I think the number is not linked to the year but rather to the number
> of Outreachy rounds since the beginning.
>
> Last year's Winter round was round 21 and there has been a Summer
> round we didn't participate in, so I think the Winter 2021-2022 is
> round 23.
>

Ok. I thought it was related to the year before.

> But yeah, it might be clearer to rename all the Outreachy files with
> names like Outreachy-Winter-21-22-Microprojects to avoid such
> confusion, as I think the round number is not used much anymore by
> anyone.

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-21 15:35         ` Christian Couder
@ 2021-09-22 14:58           ` ZheNing Hu
  0 siblings, 0 replies; 67+ messages in thread
From: ZheNing Hu @ 2021-09-22 14:58 UTC (permalink / raw)
  To: Christian Couder
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino, Hariom verma,
	Charvi Mendiratta

Christian Couder <christian.couder@gmail.com> 于2021年9月21日周二 下午11:35写道:
>
> On Tue, Sep 21, 2021 at 7:39 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > Christian Couder <christian.couder@gmail.com> 于2021年9月20日周一 下午10:52写道:
> > >
> > > On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> > > > I haven't thought of any good projects for the time being,
> > > > Christian, any ideas?
> > >
> > > I already suggested the following project upthread:
> > >
> > > > > About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
> > > > > ref-filter formats with other \-\-pretty formats" project could be and
> > > > > idea, though maybe it could interact too much with ZheNing Hu
> > > > > continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
> > > > > project.
> > >
> > > and you replied:
> > >
> > > > If the project idea is related to Hariom or my GSoC project, I think I can
> > > > provide a lot of help. :)  I can help them as a mentor.
> > >
> > > so I am ok to co-mentor this project with you.
> > >
> > > If you are still ok, I will submit it.
> >
> > Yeah, I am ok. grateful.
>
> I submitted it. You should see it and be able to register as a co-mentor there:
>
> https://www.outreachy.org/communities/cfp/git/
>

Yes, I saw it. Thanks!

> > I am still looking at the code in ref-filter.c these two days, I deeply
> > doubt whether we can add a --no-sort option to git for-each-ref,
> >
> > Inspired by Peff's experimental patches [1], I think the --no-sort option
> > may improve the performance of ref-filter by avoiding the execution
> > of ref_array_sort().
> >
> > I don't know if this can be regarded as a micro-project.
>
> If you think that such a patch is likely to be accepted and that would
> take you less than a few hours to prepare and submit, then it can
> probably be regarded as a micro-project, and you are welcome to send a
> pull request to add it to the micro-project page.
>

Eh, It may not be simple, I can try to solve it by myself first, but I
think it is
appropriate for novices to complete this mini-project to understand the
technical details of ref-filter.

> > This may require the help of this patch of mine: [2]
> > which use list api for ref_sorting. This may can help eliminate unnecessary
> > sorting.
> >
> > [1] https://lore.kernel.org/git/YTTC2IUO1ZmTOEoR@coredump.intra.peff.net/
> > [2] https://lore.kernel.org/git/pull.1025.git.1629882532.gitgitgadget@gmail.com/
>
> Then please add this information to the description of the micro-project.
>

ok!

> Thanks!

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-18 16:10 ` Taylor Blau
  2021-09-20  7:45   ` ZheNing Hu
@ 2021-09-21 21:25   ` Taylor Blau
  2021-09-29 14:18     ` Christian Couder
  1 sibling, 1 reply; 67+ messages in thread
From: Taylor Blau @ 2021-09-21 21:25 UTC (permalink / raw)
  To: Taylor Blau
  Cc: git, Jeff King, Christian Couder, Emily Shaffer,
	Matheus Tavares Bernardino, ZheNing Hu

On Sat, Sep 18, 2021 at 12:10:40PM -0400, Taylor Blau wrote:
> On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
> > Are we interested in participating in the December 2021 round of
> > Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> > application deadline.
>
> The project deadline of September 23rd is fast approaching, and we do
> not have any proposed projects or signed-up mentors.

It looks like the deadline was extended to September 29th at 4pm UTC. So
we have a little less than an extra week. The below link is still the
right place to submit proposals:

    https://www.outreachy.org/communities/cfp/git/

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-21  5:41         ` ZheNing Hu
@ 2021-09-21 15:39           ` Christian Couder
  2021-09-22 15:01             ` ZheNing Hu
  0 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2021-09-21 15:39 UTC (permalink / raw)
  To: ZheNing Hu
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino

On Tue, Sep 21, 2021 at 7:41 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> 于2021年9月20日周一 下午11:15写道:
> >
> > On Mon, Sep 20, 2021 at 4:52 PM Christian Couder
> > <christian.couder@gmail.com> wrote:
> >
> > > I will also prepare soon a page with a few micro-projects. Of course
> > > more micro-project and regular project ideas are very welcome!
> >
> > So here is the page:
> >
> > https://git.github.io/Outreachy-23-Microprojects/
> >
>
> s/Outreachy-23-Microprojects/Outreachy-22-Microprojects/

I think the number is not linked to the year but rather to the number
of Outreachy rounds since the beginning.

Last year's Winter round was round 21 and there has been a Summer
round we didn't participate in, so I think the Winter 2021-2022 is
round 23.

But yeah, it might be clearer to rename all the Outreachy files with
names like Outreachy-Winter-21-22-Microprojects to avoid such
confusion, as I think the round number is not used much anymore by
anyone.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-21  5:39       ` ZheNing Hu
@ 2021-09-21 15:35         ` Christian Couder
  2021-09-22 14:58           ` ZheNing Hu
  0 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2021-09-21 15:35 UTC (permalink / raw)
  To: ZheNing Hu
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino, Hariom verma,
	Charvi Mendiratta

On Tue, Sep 21, 2021 at 7:39 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Christian Couder <christian.couder@gmail.com> 于2021年9月20日周一 下午10:52写道:
> >
> > On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu <adlternative@gmail.com> wrote:

> > > I haven't thought of any good projects for the time being,
> > > Christian, any ideas?
> >
> > I already suggested the following project upthread:
> >
> > > > About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
> > > > ref-filter formats with other \-\-pretty formats" project could be and
> > > > idea, though maybe it could interact too much with ZheNing Hu
> > > > continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
> > > > project.
> >
> > and you replied:
> >
> > > If the project idea is related to Hariom or my GSoC project, I think I can
> > > provide a lot of help. :)  I can help them as a mentor.
> >
> > so I am ok to co-mentor this project with you.
> >
> > If you are still ok, I will submit it.
>
> Yeah, I am ok. grateful.

I submitted it. You should see it and be able to register as a co-mentor there:

https://www.outreachy.org/communities/cfp/git/

> I am still looking at the code in ref-filter.c these two days, I deeply
> doubt whether we can add a --no-sort option to git for-each-ref,
>
> Inspired by Peff's experimental patches [1], I think the --no-sort option
> may improve the performance of ref-filter by avoiding the execution
> of ref_array_sort().
>
> I don't know if this can be regarded as a micro-project.

If you think that such a patch is likely to be accepted and that would
take you less than a few hours to prepare and submit, then it can
probably be regarded as a micro-project, and you are welcome to send a
pull request to add it to the micro-project page.

> This may require the help of this patch of mine: [2]
> which use list api for ref_sorting. This may can help eliminate unnecessary
> sorting.
>
> [1] https://lore.kernel.org/git/YTTC2IUO1ZmTOEoR@coredump.intra.peff.net/
> [2] https://lore.kernel.org/git/pull.1025.git.1629882532.gitgitgadget@gmail.com/

Then please add this information to the description of the micro-project.

Thanks!

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-20 15:15       ` Christian Couder
@ 2021-09-21  5:41         ` ZheNing Hu
  2021-09-21 15:39           ` Christian Couder
  0 siblings, 1 reply; 67+ messages in thread
From: ZheNing Hu @ 2021-09-21  5:41 UTC (permalink / raw)
  To: Christian Couder
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino

Christian Couder <christian.couder@gmail.com> 于2021年9月20日周一 下午11:15写道:
>
> On Mon, Sep 20, 2021 at 4:52 PM Christian Couder
> <christian.couder@gmail.com> wrote:
>
> > I will also prepare soon a page with a few micro-projects. Of course
> > more micro-project and regular project ideas are very welcome!
>
> So here is the page:
>
> https://git.github.io/Outreachy-23-Microprojects/
>

s/Outreachy-23-Microprojects/Outreachy-22-Microprojects/

> It's very similar as last year's page
> (https://git.github.io/Outreachy-21-Microprojects/). The differences
> are:
>
> - added new "Replace a run_command*() call by direct calls to C functions" idea
> - removed "Unify the meaning of -dirty between diff and describe" idea
> as it looks a bit complex for a micro-project (though I can add it
> back if someone disagree with this opinion).

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-20 14:52     ` Christian Couder
  2021-09-20 15:15       ` Christian Couder
@ 2021-09-21  5:39       ` ZheNing Hu
  2021-09-21 15:35         ` Christian Couder
  1 sibling, 1 reply; 67+ messages in thread
From: ZheNing Hu @ 2021-09-21  5:39 UTC (permalink / raw)
  To: Christian Couder
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino

Christian Couder <christian.couder@gmail.com> 于2021年9月20日周一 下午10:52写道:
>
> On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > Taylor Blau <me@ttaylorr.com> 于2021年9月19日周日 上午12:10写道:
> > >
> > > [+everybody from upthread to cc]
> > >
> > > On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
> > > > Are we interested in participating in the December 2021 round of
> > > > Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> > > > application deadline.
> > >
> > > The project deadline of September 23rd is fast approaching, and we do
> > > not have any proposed projects or signed-up mentors.
> > >
> > > If you are interested in mentoring, the time to sign-up and propose a
> > > project is definitely ASAP :-). You can do so by clicking "Submit a
> > > project proposal" at:
> > >
> > >     https://www.outreachy.org/communities/cfp/git/
> >
> > I haven't thought of any good projects for the time being,
> > Christian, any ideas?
>
> I already suggested the following project upthread:
>
> > > About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
> > > ref-filter formats with other \-\-pretty formats" project could be and
> > > idea, though maybe it could interact too much with ZheNing Hu
> > > continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
> > > project.
>
> and you replied:
>
> > If the project idea is related to Hariom or my GSoC project, I think I can
> > provide a lot of help. :)  I can help them as a mentor.
>
> so I am ok to co-mentor this project with you.
>
> If you are still ok, I will submit it.
>

Yeah, I am ok. grateful.

> I will also prepare soon a page with a few micro-projects. Of course
> more micro-project and regular project ideas are very welcome!

I am still looking at the code in ref-filter.c these two days, I deeply
doubt whether we can add a --no-sort option to git for-each-ref,

Inspired by Peff's experimental patches [1], I think the --no-sort option
may improve the performance of ref-filter by avoiding the execution
of ref_array_sort().

I don't know if this can be regarded as a micro-project.

This may require the help of this patch of mine: [2]
which use list api for ref_sorting. This may can help eliminate unnecessary
sorting.

[1] https://lore.kernel.org/git/YTTC2IUO1ZmTOEoR@coredump.intra.peff.net/
[2] https://lore.kernel.org/git/pull.1025.git.1629882532.gitgitgadget@gmail.com/

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-20 14:52     ` Christian Couder
@ 2021-09-20 15:15       ` Christian Couder
  2021-09-21  5:41         ` ZheNing Hu
  2021-09-21  5:39       ` ZheNing Hu
  1 sibling, 1 reply; 67+ messages in thread
From: Christian Couder @ 2021-09-20 15:15 UTC (permalink / raw)
  To: ZheNing Hu
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino

On Mon, Sep 20, 2021 at 4:52 PM Christian Couder
<christian.couder@gmail.com> wrote:

> I will also prepare soon a page with a few micro-projects. Of course
> more micro-project and regular project ideas are very welcome!

So here is the page:

https://git.github.io/Outreachy-23-Microprojects/

It's very similar as last year's page
(https://git.github.io/Outreachy-21-Microprojects/). The differences
are:

- added new "Replace a run_command*() call by direct calls to C functions" idea
- removed "Unify the meaning of -dirty between diff and describe" idea
as it looks a bit complex for a micro-project (though I can add it
back if someone disagree with this opinion).

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-20  7:45   ` ZheNing Hu
@ 2021-09-20 14:52     ` Christian Couder
  2021-09-20 15:15       ` Christian Couder
  2021-09-21  5:39       ` ZheNing Hu
  0 siblings, 2 replies; 67+ messages in thread
From: Christian Couder @ 2021-09-20 14:52 UTC (permalink / raw)
  To: ZheNing Hu
  Cc: Christian Couder, Taylor Blau, Git List, Jeff King, Taylor Blau,
	Emily Shaffer, Matheus Tavares Bernardino

On Mon, Sep 20, 2021 at 9:45 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Taylor Blau <me@ttaylorr.com> 于2021年9月19日周日 上午12:10写道:
> >
> > [+everybody from upthread to cc]
> >
> > On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
> > > Are we interested in participating in the December 2021 round of
> > > Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> > > application deadline.
> >
> > The project deadline of September 23rd is fast approaching, and we do
> > not have any proposed projects or signed-up mentors.
> >
> > If you are interested in mentoring, the time to sign-up and propose a
> > project is definitely ASAP :-). You can do so by clicking "Submit a
> > project proposal" at:
> >
> >     https://www.outreachy.org/communities/cfp/git/
>
> I haven't thought of any good projects for the time being,
> Christian, any ideas?

I already suggested the following project upthread:

> > About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
> > ref-filter formats with other \-\-pretty formats" project could be and
> > idea, though maybe it could interact too much with ZheNing Hu
> > continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
> > project.

and you replied:

> If the project idea is related to Hariom or my GSoC project, I think I can
> provide a lot of help. :)  I can help them as a mentor.

so I am ok to co-mentor this project with you.

If you are still ok, I will submit it.

I will also prepare soon a page with a few micro-projects. Of course
more micro-project and regular project ideas are very welcome!

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-18 16:10 ` Taylor Blau
@ 2021-09-20  7:45   ` ZheNing Hu
  2021-09-20 14:52     ` Christian Couder
  2021-09-21 21:25   ` Taylor Blau
  1 sibling, 1 reply; 67+ messages in thread
From: ZheNing Hu @ 2021-09-20  7:45 UTC (permalink / raw)
  To: Christian Couder
  Cc: Taylor Blau, Git List, Jeff King, Taylor Blau, Emily Shaffer,
	Matheus Tavares Bernardino

Taylor Blau <me@ttaylorr.com> 于2021年9月19日周日 上午12:10写道:
>
> [+everybody from upthread to cc]
>
> On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
> > Are we interested in participating in the December 2021 round of
> > Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> > application deadline.
>
> The project deadline of September 23rd is fast approaching, and we do
> not have any proposed projects or signed-up mentors.
>
> If you are interested in mentoring, the time to sign-up and propose a
> project is definitely ASAP :-). You can do so by clicking "Submit a
> project proposal" at:
>
>     https://www.outreachy.org/communities/cfp/git/
>

I haven't thought of any good projects for the time being,
Christian, any ideas?

> Thanks,
> Taylor

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-03  2:40 Taylor Blau
                   ` (2 preceding siblings ...)
  2021-09-04 17:51 ` Taylor Blau
@ 2021-09-18 16:10 ` Taylor Blau
  2021-09-20  7:45   ` ZheNing Hu
  2021-09-21 21:25   ` Taylor Blau
  3 siblings, 2 replies; 67+ messages in thread
From: Taylor Blau @ 2021-09-18 16:10 UTC (permalink / raw)
  To: Taylor Blau
  Cc: git, Jeff King, Christian Couder, Emily Shaffer,
	Matheus Tavares Bernardino, ZheNing Hu

[+everybody from upthread to cc]

On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
> Are we interested in participating in the December 2021 round of
> Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> application deadline.

The project deadline of September 23rd is fast approaching, and we do
not have any proposed projects or signed-up mentors.

If you are interested in mentoring, the time to sign-up and propose a
project is definitely ASAP :-). You can do so by clicking "Submit a
project proposal" at:

    https://www.outreachy.org/communities/cfp/git/

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-06 12:36         ` Matheus Tavares Bernardino
@ 2021-09-07  5:50           ` ZheNing Hu
  0 siblings, 0 replies; 67+ messages in thread
From: ZheNing Hu @ 2021-09-07  5:50 UTC (permalink / raw)
  To: Matheus Tavares Bernardino
  Cc: Jeff King, Christian Couder, Taylor Blau, git, Christian Couder,
	Hariom verma

Matheus Tavares Bernardino <matheus.bernardino@usp.br> 于2021年9月6日周一 下午8:36写道:
>
> On Sun, Sep 5, 2021 at 5:59 AM ZheNing Hu <adlternative@gmail.com> wrote:
> >
> > Jeff King <peff@peff.net> 于2021年9月4日周六 下午8:50写道:
> > >
> > > On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
> > >
> > > > This may be a place to promote my patches: See [1][2][3].
> > > > It can provide some extra atoms for git cat-file --batch | --batch-check,
> > > > like %(tree), %(author), %(tagger) etc. Although some performance
> > > > optimizations have been made, It still has small performance gap.
> > > >
> > > > If the community still expects git cat-file --batch to reuse the logic
> > > > of ref-filter,
> > > > I expect it to get the attention of reviewers.
> > > >
> > > > The solutions I can think of to further optimize performance are:
> > > > 1. Delay the evaluation of some ref-filter intermediate data.
> > > > 2. Let ref-filter code reentrant and can be called in multi-threaded  to take
> > > > advantage of multi-core.
> > >
> > > I don't think trying to thread it will help much. For expensive formats,
> > > where we have to actually open and parse objects, in theory we could do
> > > that in parallel. But most of our time there is spent in zlib getting
> > > the object data, and that all needs to be done under a big lock.
> >
> > This big lock is "obj_read_lock()", right?
>
> The object reading code actually releases this lock before doing zlib
> decompression (and acquires it right after), to allow better
> multi-threaded performance.
>

Yeah, I guess this unlock place is in unpack_loose_short_header().

> However, it is unfortunately not so simple to call object reading
> routines in multi-threaded code, even with this lock. The lock mainly
> protects `oid_object_info_extended()` and its wrappers. Some global
> resources used by these functions are also accessed outside of them,
> which could lead to race conditions in threaded code.
>
> That's why `builtin/grep.c` and `grep.c` have some explicit calls to
> `obj_read_lock()` outside `object-file.c` and `packfile.c`. (And it
> can be quite tricky to identity these cases.)

Indeed, a large number of global variables in ref-filter code are worth
eliminating.

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-05  8:58       ` ZheNing Hu
@ 2021-09-06 12:36         ` Matheus Tavares Bernardino
  2021-09-07  5:50           ` ZheNing Hu
  0 siblings, 1 reply; 67+ messages in thread
From: Matheus Tavares Bernardino @ 2021-09-06 12:36 UTC (permalink / raw)
  To: ZheNing Hu
  Cc: Jeff King, Christian Couder, Taylor Blau, git, Christian Couder,
	Hariom verma

On Sun, Sep 5, 2021 at 5:59 AM ZheNing Hu <adlternative@gmail.com> wrote:
>
> Jeff King <peff@peff.net> 于2021年9月4日周六 下午8:50写道:
> >
> > On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
> >
> > > This may be a place to promote my patches: See [1][2][3].
> > > It can provide some extra atoms for git cat-file --batch | --batch-check,
> > > like %(tree), %(author), %(tagger) etc. Although some performance
> > > optimizations have been made, It still has small performance gap.
> > >
> > > If the community still expects git cat-file --batch to reuse the logic
> > > of ref-filter,
> > > I expect it to get the attention of reviewers.
> > >
> > > The solutions I can think of to further optimize performance are:
> > > 1. Delay the evaluation of some ref-filter intermediate data.
> > > 2. Let ref-filter code reentrant and can be called in multi-threaded  to take
> > > advantage of multi-core.
> >
> > I don't think trying to thread it will help much. For expensive formats,
> > where we have to actually open and parse objects, in theory we could do
> > that in parallel. But most of our time there is spent in zlib getting
> > the object data, and that all needs to be done under a big lock.
>
> This big lock is "obj_read_lock()", right?

The object reading code actually releases this lock before doing zlib
decompression (and acquires it right after), to allow better
multi-threaded performance.

However, it is unfortunately not so simple to call object reading
routines in multi-threaded code, even with this lock. The lock mainly
protects `oid_object_info_extended()` and its wrappers. Some global
resources used by these functions are also accessed outside of them,
which could lead to race conditions in threaded code.

That's why `builtin/grep.c` and `grep.c` have some explicit calls to
`obj_read_lock()` outside `object-file.c` and `packfile.c`. (And it
can be quite tricky to identity these cases.)

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-04 12:50     ` Jeff King
@ 2021-09-05  8:58       ` ZheNing Hu
  2021-09-06 12:36         ` Matheus Tavares Bernardino
  0 siblings, 1 reply; 67+ messages in thread
From: ZheNing Hu @ 2021-09-05  8:58 UTC (permalink / raw)
  To: Jeff King
  Cc: Christian Couder, Taylor Blau, git, Christian Couder, Hariom verma

Jeff King <peff@peff.net> 于2021年9月4日周六 下午8:50写道:
>
> On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:
>
> > This may be a place to promote my patches: See [1][2][3].
> > It can provide some extra atoms for git cat-file --batch | --batch-check,
> > like %(tree), %(author), %(tagger) etc. Although some performance
> > optimizations have been made, It still has small performance gap.
> >
> > If the community still expects git cat-file --batch to reuse the logic
> > of ref-filter,
> > I expect it to get the attention of reviewers.
> >
> > The solutions I can think of to further optimize performance are:
> > 1. Delay the evaluation of some ref-filter intermediate data.
> > 2. Let ref-filter code reentrant and can be called in multi-threaded  to take
> > advantage of multi-core.
>
> I don't think trying to thread it will help much. For expensive formats,
> where we have to actually open and parse objects, in theory we could do
> that in parallel. But most of our time there is spent in zlib getting
> the object data, and that all needs to be done under a big lock.
>

This big lock is "obj_read_lock()", right? If there are indeed the limitations
of these locks, I am afraid that the parallel scheme is not good.

> For little formats (e.g., just printing "%(refname)"), we need to
> serialize the output anyway. So our unit of work is so tiny, I suspect
> that the threading overhead would be a net negative.
>

Make sence.

> I was coincidentally looking at ref-filter last week, and it seemed to
> me that a lot of the slowness is because of the over-use of malloc

Agree. malloc() and data-copy is the reason for the poor performance of
ref-filter.

> (e.g., we allocate a substring for every atom_value, and then form them
> into a separate buffer). If we could parse the original format into a
> form that could be traversed without having to do further allocations,
> just writing directly to a strbuf (or even a file handle), I think that
> would be a big improvement.
>

This patch has been tried to eliminate some malloc and data-copy:
https://lore.kernel.org/git/3760ff032bb1dec3812881fd408f8d78ec125477.1629184489.git.gitgitgadget@gmail.com/
It is indeed possible to obtain some optimizations.

> I just posted the results of some of my experiments to the list:
>
>   https://lore.kernel.org/git/YTNpQ7Od1U%2F5i0R7@coredump.intra.peff.net/
>
> I don't think that gives any kind of useful base to build on, but it
> shows what's possible by skipping past various segments of the
> ref-filter code.
>
> -Peff

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-03  2:40 Taylor Blau
  2021-09-03 18:33 ` Emily Shaffer
  2021-09-04  4:30 ` Christian Couder
@ 2021-09-04 17:51 ` Taylor Blau
  2021-09-18 16:10 ` Taylor Blau
  3 siblings, 0 replies; 67+ messages in thread
From: Taylor Blau @ 2021-09-04 17:51 UTC (permalink / raw)
  To: Taylor Blau; +Cc: git, Christian Couder, Jeff King

On Thu, Sep 02, 2021 at 10:40:45PM -0400, Taylor Blau wrote:
>   - Updates to our applicant materials on git.github.io (project ideas,
>     as well as potential microprojects).

One project I have been thinking of is a grab-bag of bitmap-related
tasks. Some ideas for general improvements are:

  - Designing a new .bitmap format (perhaps using the new chunkfile
    API?) to allow us to add optional data to it in the future, like any
    information we might need for a stable object order.

  - Experimenting with replacing EWAH with different bitmap compression
    algorithms to see if we can increase read performance and/or
    decrease file size.

  - Tidy up and take measurements from my RFC patch(es) to add an
    extension which indicates which commits have bitmaps, and at what
    position. These were discussed beginning at:

        https://lore.kernel.org/git/YNuiM8TR5evSeNsN@nand.local/

    (but they seem to help most when there isn't too much traversal
    required between the ref tips and the bitmapped commits).

  - Rethinking bitmap selection to be more robust against repositories
    which have "spikey" ref tips and for which follow-on traversal is
    expensive.

These are all fairly open-ended, and so may not make a good Outreachy
project. But I would be in favor of having more people familiar with and
interested in reachability bitmaps.

I'll think of some others, too.

Thanks,
Taylor

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-04  7:40   ` ZheNing Hu
@ 2021-09-04 12:50     ` Jeff King
  2021-09-05  8:58       ` ZheNing Hu
  0 siblings, 1 reply; 67+ messages in thread
From: Jeff King @ 2021-09-04 12:50 UTC (permalink / raw)
  To: ZheNing Hu
  Cc: Christian Couder, Taylor Blau, git, Christian Couder, Hariom verma

On Sat, Sep 04, 2021 at 03:40:41PM +0800, ZheNing Hu wrote:

> This may be a place to promote my patches: See [1][2][3].
> It can provide some extra atoms for git cat-file --batch | --batch-check,
> like %(tree), %(author), %(tagger) etc. Although some performance
> optimizations have been made, It still has small performance gap.
> 
> If the community still expects git cat-file --batch to reuse the logic
> of ref-filter,
> I expect it to get the attention of reviewers.
> 
> The solutions I can think of to further optimize performance are:
> 1. Delay the evaluation of some ref-filter intermediate data.
> 2. Let ref-filter code reentrant and can be called in multi-threaded  to take
> advantage of multi-core.

I don't think trying to thread it will help much. For expensive formats,
where we have to actually open and parse objects, in theory we could do
that in parallel. But most of our time there is spent in zlib getting
the object data, and that all needs to be done under a big lock.

For little formats (e.g., just printing "%(refname)"), we need to
serialize the output anyway. So our unit of work is so tiny, I suspect
that the threading overhead would be a net negative.

I was coincidentally looking at ref-filter last week, and it seemed to
me that a lot of the slowness is because of the over-use of malloc
(e.g., we allocate a substring for every atom_value, and then form them
into a separate buffer). If we could parse the original format into a
form that could be traversed without having to do further allocations,
just writing directly to a strbuf (or even a file handle), I think that
would be a big improvement.

I just posted the results of some of my experiments to the list:

  https://lore.kernel.org/git/YTNpQ7Od1U%2F5i0R7@coredump.intra.peff.net/

I don't think that gives any kind of useful base to build on, but it
shows what's possible by skipping past various segments of the
ref-filter code.

-Peff

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-04  4:30 ` Christian Couder
@ 2021-09-04  7:40   ` ZheNing Hu
  2021-09-04 12:50     ` Jeff King
  0 siblings, 1 reply; 67+ messages in thread
From: ZheNing Hu @ 2021-09-04  7:40 UTC (permalink / raw)
  To: Christian Couder
  Cc: Taylor Blau, git, Christian Couder, Jeff King, Hariom verma

Hi,

Christian Couder <christian.couder@gmail.com> 于2021年9月4日周六 下午12:30写道:
>
> On Fri, Sep 3, 2021 at 4:40 AM Taylor Blau <ttaylorr@github.com> wrote:
> >
> > Are we interested in participating in the December 2021 round of
> > Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> > application deadline.
> >
> > Christian, Peff, and I discussed off-list that we would each try to pull
> > together funding for one intern from GitHub and GitLab respectively.
>
> Yeah, and we submitted an initial community application.
>
> > If we're interested, the project submission deadline is September 23rd
> > [1]. By then, we'd need:
> >
> >   - Volunteers to act as mentors
>
> I am ok with co-mentoring 2 interns.
>
> >   - Updates to our applicant materials on git.github.io (project ideas,
> >     as well as potential microprojects).
>
> About microprojects, I have been wondering if there are run_command*()
> calls that could be replaced by direct calls to C functions like what
> Junio did in ffcb4e94d3 (bisect: do not run show-branch just to show
> the current commit, 2021-07-27), and if that could make a good
> microproject.
>
> About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
> ref-filter formats with other \-\-pretty formats" project could be and
> idea, though maybe it could interact too much with ZheNing Hu
> continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
> project.

If the project idea is related to Hariom or my GSoC project, I think I can
provide a lot of help. :)  I can help them as a mentor.

This may be a place to promote my patches: See [1][2][3].
It can provide some extra atoms for git cat-file --batch | --batch-check,
like %(tree), %(author), %(tagger) etc. Although some performance
optimizations have been made, It still has small performance gap.

If the community still expects git cat-file --batch to reuse the logic
of ref-filter,
I expect it to get the attention of reviewers.

The solutions I can think of to further optimize performance are:
1. Delay the evaluation of some ref-filter intermediate data.
2. Let ref-filter code reentrant and can be called in multi-threaded  to take
advantage of multi-core.
These ideas may be very difficult to implement now.

[1]: https://lore.kernel.org/git/CAOLTT8SxHuH2EbiSwQX6pyJJs5KyVuKx6ZOPxpzWLH+Tbz5F+A@mail.gmail.com/
[2]: https://lore.kernel.org/git/pull.1025.git.1629882532.gitgitgadget@gmail.com/
[3]: https://github.com/adlternative/git/commits/cat-file-reuse-ref-filter-logic

Thanks.
--
ZheNing Hu

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-03  2:40 Taylor Blau
  2021-09-03 18:33 ` Emily Shaffer
@ 2021-09-04  4:30 ` Christian Couder
  2021-09-04  7:40   ` ZheNing Hu
  2021-09-04 17:51 ` Taylor Blau
  2021-09-18 16:10 ` Taylor Blau
  3 siblings, 1 reply; 67+ messages in thread
From: Christian Couder @ 2021-09-04  4:30 UTC (permalink / raw)
  To: Taylor Blau; +Cc: git, Christian Couder, Jeff King, Hariom verma, ZheNing Hu

On Fri, Sep 3, 2021 at 4:40 AM Taylor Blau <ttaylorr@github.com> wrote:
>
> Are we interested in participating in the December 2021 round of
> Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> application deadline.
>
> Christian, Peff, and I discussed off-list that we would each try to pull
> together funding for one intern from GitHub and GitLab respectively.

Yeah, and we submitted an initial community application.

> If we're interested, the project submission deadline is September 23rd
> [1]. By then, we'd need:
>
>   - Volunteers to act as mentors

I am ok with co-mentoring 2 interns.

>   - Updates to our applicant materials on git.github.io (project ideas,
>     as well as potential microprojects).

About microprojects, I have been wondering if there are run_command*()
calls that could be replaced by direct calls to C functions like what
Junio did in ffcb4e94d3 (bisect: do not run show-branch just to show
the current commit, 2021-07-27), and if that could make a good
microproject.

About project ideas, maybe continuing Hariom Verma's GSoC 2020 "Unify
ref-filter formats with other \-\-pretty formats" project could be and
idea, though maybe it could interact too much with ZheNing Hu
continuing his GSoC 2021 "Use ref-filter formats in `git cat-file`"
project.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Re: Git in Outreachy?
  2021-09-03  2:40 Taylor Blau
@ 2021-09-03 18:33 ` Emily Shaffer
  2021-09-04  4:30 ` Christian Couder
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 67+ messages in thread
From: Emily Shaffer @ 2021-09-03 18:33 UTC (permalink / raw)
  To: Taylor Blau; +Cc: Git List, Christian Couder, Jeff King

On Thu, Sep 2, 2021 at 7:41 PM Taylor Blau <ttaylorr@github.com> wrote:
>
> Are we interested in participating in the December 2021 round of
> Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
> application deadline.
>
> Christian, Peff, and I discussed off-list that we would each try to pull
> together funding for one intern from GitHub and GitLab respectively.
>
> If we're interested, the project submission deadline is September 23rd
> [1]. By then, we'd need:
>
>   - Volunteers to act as mentors

I'd be happy to mentor actively during the application stage, but I
don't have bandwidth to host/mentor an accepted intern this term. I
would also be happy to be CC'd, pinged, and so on on any reviews from
interns which aren't receiving enough love.

>   - Updates to our applicant materials on git.github.io (project ideas,
>     as well as potential microprojects).

Will bring this up with Google folks today and see if we've got any ideas.

Thanks for mentioning it, Taylor.

^ permalink raw reply	[flat|nested] 67+ messages in thread

* Git in Outreachy?
@ 2021-09-03  2:40 Taylor Blau
  2021-09-03 18:33 ` Emily Shaffer
                   ` (3 more replies)
  0 siblings, 4 replies; 67+ messages in thread
From: Taylor Blau @ 2021-09-03  2:40 UTC (permalink / raw)
  To: git; +Cc: Christian Couder, Jeff King

Are we interested in participating in the December 2021 round of
Outreachy? September 3rd (tomorrow at 4pm UTC) is the initial community
application deadline.

Christian, Peff, and I discussed off-list that we would each try to pull
together funding for one intern from GitHub and GitLab respectively.

If we're interested, the project submission deadline is September 23rd
[1]. By then, we'd need:

  - Volunteers to act as mentors

  - Updates to our applicant materials on git.github.io (project ideas,
    as well as potential microprojects).

Thanks,
Taylor

[1]: https://www.outreachy.org/docs/community/#current-timeline

^ permalink raw reply	[flat|nested] 67+ messages in thread

end of thread, other threads:[~2021-09-29 20:30 UTC | newest]

Thread overview: 67+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-28  6:56 Git in Outreachy? Jeff King
2020-08-31  6:55 ` Christian Couder
2020-09-03  6:00   ` Jonathan Nieder
2020-09-04 14:14     ` Philip Oakley
2020-09-07 18:49       ` Johannes Schindelin
2020-09-16 15:16         ` Philip Oakley
2020-09-16 18:43           ` Johannes Schindelin
2020-09-17 14:42             ` Philip Oakley
2020-09-09 18:26     ` Taylor Blau
2020-09-10  1:39       ` Jonathan Nieder
2020-09-10  2:19         ` Taylor Blau
2020-09-16  9:12     ` Christian Couder
2020-09-16  6:42   ` Christian Couder
2020-08-31 17:41 ` Junio C Hamano
2020-08-31 18:05 ` Emily Shaffer
2020-09-01 12:51   ` Jeff King
2020-09-03  5:41     ` Jeff King
2020-09-15 17:35       ` Jeff King
2020-09-15 17:55         ` Kaartic Sivaraam
2020-09-15 18:02           ` Jeff King
2020-09-19  8:12         ` Christian Couder
2020-09-19 15:10           ` Phillip Wood
2020-09-16  8:45     ` Christian Couder
2020-09-02  4:00 ` Johannes Schindelin
2020-09-16  9:01   ` Christian Couder
2020-09-16  9:45     ` Phillip Wood
2020-09-17  9:43     ` Christian Couder
2020-09-17 10:14       ` Phillip Wood
2020-09-18  8:37         ` Christian Couder
2020-09-17 15:34       ` Elijah Newren
2020-09-18  8:42         ` Christian Couder
2020-09-27 16:59     ` Kaartic Sivaraam
2020-09-27 21:16       ` Christian Couder
2020-10-29 10:13         ` Christian Couder
2020-09-06 18:56 ` Kaartic Sivaraam
2020-09-07 18:55   ` Johannes Schindelin
2020-09-16  9:35     ` Christian Couder
2020-09-16 20:27       ` Johannes Schindelin
2020-09-19  7:40         ` Christian Couder
2020-09-20 15:06           ` Johannes Schindelin
2020-09-20 16:31   ` Kaartic Sivaraam
2020-09-21  4:22     ` Christian Couder
2020-09-21  7:59       ` Kaartic Sivaraam
2020-09-21 20:56       ` Shourya Shukla
2021-09-03  2:40 Taylor Blau
2021-09-03 18:33 ` Emily Shaffer
2021-09-04  4:30 ` Christian Couder
2021-09-04  7:40   ` ZheNing Hu
2021-09-04 12:50     ` Jeff King
2021-09-05  8:58       ` ZheNing Hu
2021-09-06 12:36         ` Matheus Tavares Bernardino
2021-09-07  5:50           ` ZheNing Hu
2021-09-04 17:51 ` Taylor Blau
2021-09-18 16:10 ` Taylor Blau
2021-09-20  7:45   ` ZheNing Hu
2021-09-20 14:52     ` Christian Couder
2021-09-20 15:15       ` Christian Couder
2021-09-21  5:41         ` ZheNing Hu
2021-09-21 15:39           ` Christian Couder
2021-09-22 15:01             ` ZheNing Hu
2021-09-21  5:39       ` ZheNing Hu
2021-09-21 15:35         ` Christian Couder
2021-09-22 14:58           ` ZheNing Hu
2021-09-21 21:25   ` Taylor Blau
2021-09-29 14:18     ` Christian Couder
2021-09-29 17:34       ` Taylor Blau
2021-09-29 20:30         ` Taylor Blau

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).