Ensimag students projects, version 2013

Ensimag students projects, version 2013

[Matthieu Moy]

Hi,

Like the years before, I'm going to offer my students a 1 month project
(end of May -> end of June) where they can contribute to a free
software, in particular Git.

Students are free to pick the feature they want, but I maintain a list
of small project ideas on the wiki to help them:

  https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

fell free to edit and comment. Students will anyway have to discuss here
before starting to code anything non-trivial.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Ensimag students projects, version 2013

[Ping Yin]

> 15 git rebase --stash, git pull --rebase --stash

It seems that Ramkumar Ramachandra is working on this in his "[PATCH
v2 0/3] Introduce pull.autostash" series
Ping Yin


On Mon, Apr 15, 2013 at 4:04 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Hi,
>
> Like the years before, I'm going to offer my students a 1 month project
> (end of May -> end of June) where they can contribute to a free
> software, in particular Git.
>
> Students are free to pick the feature they want, but I maintain a list
> of small project ideas on the wiki to help them:
>
>   https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
>
> fell free to edit and comment. Students will anyway have to discuss here
> before starting to code anything non-trivial.
>
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Ensimag students projects, version 2013

[Matthieu Moy]

Ping Yin <pkufranky@gmail.com> writes:

>> 15 git rebase --stash, git pull --rebase --stash
>
> It seems that Ramkumar Ramachandra is working on this in his "[PATCH
> v2 0/3] Introduce pull.autostash" series
> Ping Yin

Ah, cool! Added a note to the wiki, thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Ensimag students projects, version 2013

[Thomas Rast]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

>   https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

My $0.02:

* Allow "git add -p" to use "git diff --color-words" to show hunks 

  Check if you can use the existing --word-diff=porcelain output somehow
  to get it done in pure perl.  Alternatively, try to hack a word-diff
  mode where it spews out both the line-diff (for later application) and
  the word-diff (for display) in some clever format, so that the perl
  code can easily match them up.  If neither one is possible my feeling
  is that it's one of the hardest tasks on the list.  (Not to
  discourcage anyone from trying, but still.)

* git pull --set-upstream

  This is vaguely related to another itch that nobody has bothered to
  fix: 'git fetch origin foo' should really update origin/foo.  This has
  been discussed on the list a few times already:

    http://thread.gmane.org/gmane.comp.version-control.git/192252
    http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758

  which by the way would be a *great* thing to fix, hint hint ;-)  and
  since Peff already posted a POC patch in the first thread, it's
  probably not that hard.  (Peff?)

* Allow git send-email --cc 'foo@example.com, bar@example.com' instead
  of git send-email --cc foo@example.com --cc bar@example.com

  That would be really nice.  Bonus points if it handles continuation
  lines etc. correctly, so that it's even easier to paste.

-- 
Thomas Rast
trast@{inf,student}.ethz.ch

Re: Ensimag students projects, version 2013

[Matthieu Moy]

Thomas Rast <trast@inf.ethz.ch> writes:

> My $0.02:

(BTW, feel free to edit the wiki. I've added a few bits from your
message there already).

> * Allow "git add -p" to use "git diff --color-words" to show hunks 
[...]
>   If neither one is possible my feeling is that it's one of the
>   hardest tasks on the list. (Not to discourcage anyone from trying,
>   but still.)

Yes, this was already inferable from the "See also the GSoC proposal"
statement and our discussions on GSoCs on this list ;-). It's not funny
if all projects are easy, but it's not a coincidence if this idea has
been there for a while without being implemented.

> * git pull --set-upstream
>
>   This is vaguely related to another itch that nobody has bothered to
>   fix: 'git fetch origin foo' should really update origin/foo.  This has
>   been discussed on the list a few times already:
>
>     http://thread.gmane.org/gmane.comp.version-control.git/192252
>     http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758
>
>   which by the way would be a *great* thing to fix, hint hint ;-)  and
>   since Peff already posted a POC patch in the first thread, it's
>   probably not that hard.  (Peff?)

My understanding is that this would be technically easy to fix, but a
migration plan is needed, which isn't easy for a one-shot, one-month
contribution.

I've added it to the wiki.

> * Allow git send-email --cc 'foo@example.com, bar@example.com' instead
>   of git send-email --cc foo@example.com --cc bar@example.com
>
>   That would be really nice.  Bonus points if it handles continuation
>   lines etc. correctly, so that it's even easier to paste.

Added to the wiki too.

Thanks,

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Ensimag students projects, version 2013

[John Keeping]

On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
> Thomas Rast <trast@inf.ethz.ch> writes:
> > * Allow git send-email --cc 'foo@example.com, bar@example.com' instead
> >   of git send-email --cc foo@example.com --cc bar@example.com
> >
> >   That would be really nice.  Bonus points if it handles continuation
> >   lines etc. correctly, so that it's even easier to paste.
> 
> Added to the wiki too.

As an extension to this, it would be really nice if I could say "git
send-email --reply-to <file>", feeding it an existing message.  This
would set "To" and "Cc" appropriately but also quote the existing
message for me to reply to, either into the cover letter or after the
"---" in the patch (it's probably an error if there's no cover letter
and more than one patch in this mode).

Re: Ensimag students projects, version 2013

[Jeff King]

On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:

> > * git pull --set-upstream
> >
> >   This is vaguely related to another itch that nobody has bothered to
> >   fix: 'git fetch origin foo' should really update origin/foo.  This has
> >   been discussed on the list a few times already:
> >
> >     http://thread.gmane.org/gmane.comp.version-control.git/192252
> >     http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758
> >
> >   which by the way would be a *great* thing to fix, hint hint ;-)  and
> >   since Peff already posted a POC patch in the first thread, it's
> >   probably not that hard.  (Peff?)
> 
> My understanding is that this would be technically easy to fix, but a
> migration plan is needed, which isn't easy for a one-shot, one-month
> contribution.

Yes. The concept isn't that hard, but the question was one of whether it
would break some obscure workflows. But I don't remember all of the
details; I think I gave some examples in past threads.

-Peff

Re: Ensimag students projects, version 2013

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy wrote:
>
>> > * git pull --set-upstream
>> >
>> >   This is vaguely related to another itch that nobody has bothered to
>> >   fix: 'git fetch origin foo' should really update origin/foo.  This has
>> >   been discussed on the list a few times already:
>> >
>> >     http://thread.gmane.org/gmane.comp.version-control.git/192252
>> >     http://thread.gmane.org/gmane.comp.version-control.git/165720/focus=165758
>> >
>> >   which by the way would be a *great* thing to fix, hint hint ;-)  and
>> >   since Peff already posted a POC patch in the first thread, it's
>> >   probably not that hard.  (Peff?)
>> 
>> My understanding is that this would be technically easy to fix, but a
>> migration plan is needed, which isn't easy for a one-shot, one-month
>> contribution.
>
> Yes. The concept isn't that hard, but the question was one of whether it
> would break some obscure workflows. But I don't remember all of the
> details; I think I gave some examples in past threads.

I think the one Thomas lists in $gmane/165758 is the one.

It has been the way for users to make sure that origin/master stays
put to explicitly tell Git not to update the remote tracking branch
using a refspec without colon, so that they can do

	git fetch origin master
	git log origin/master..FETCH_HEAD

(or its three-dot variant) to gauge the progress of the other side
since the last time the user observed.

Personally I doubt this trick is so relevant these days, not just
because we can look at reflog of origin/master.  The user could just
do

	old=$(git rev-parse origin/master)
        git fetch origin master
        git log $old..FETCH_HEAD

even with a modified Git that updates the remote tracking branches
without a storing refspec.

The primary reason why I do not think this is relevant these days is
because the original premise "remote tracking branches keep what the
last 'git fetch' observed" has already been broken for a long time.
The users are better off thinking that the remote tracking branches
can be updated any time (not just the last 'git fetch') when Git
observes (or could observe) the state of the remote without being
told explicitly with today's "pretend as if we fetched immediately
after we push" behaviour.

Re: Ensimag students projects, version 2013

[Jeff King]

On Mon, Apr 15, 2013 at 07:53:48AM -0700, Junio C Hamano wrote:

> > Yes. The concept isn't that hard, but the question was one of whether it
> > would break some obscure workflows. But I don't remember all of the
> > details; I think I gave some examples in past threads.
> 
> I think the one Thomas lists in $gmane/165758 is the one.

The one I was thinking of is:

  http://article.gmane.org/gmane.comp.version-control.git/127215

> The primary reason why I do not think this is relevant these days is
> because the original premise "remote tracking branches keep what the
> last 'git fetch' observed" has already been broken for a long time.
> The users are better off thinking that the remote tracking branches
> can be updated any time (not just the last 'git fetch') when Git
> observes (or could observe) the state of the remote without being
> told explicitly with today's "pretend as if we fetched immediately
> after we push" behaviour.

Yeah, that is certainly my mental model, and how "git push" works (and
how the patch I linked to above works). I actually don't care that much
either way, which is why I haven't polished up that patch. I'd be happy
if somebody worked on it, but I don't know if it is all that interesting
a student project. It is not much development, and mostly about digging
in the history of what tracking branches mean, and convincing everybody
it's a good change. Which is hard for any newcomer to the community to
do as a first project.

-Peff

Re: Ensimag students projects, version 2013

[Duy Nguyen]

On Mon, Apr 15, 2013 at 7:06 PM, Thomas Rast <trast@inf.ethz.ch> wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>>   https://git.wiki.kernel.org/index.php/SmallProjectsIdeas
>
> My $0.02:
>
> * Allow "git add -p" to use "git diff --color-words" to show hunks
>
>   Check if you can use the existing --word-diff=porcelain output somehow
>   to get it done in pure perl.  Alternatively, try to hack a word-diff
>   mode where it spews out both the line-diff (for later application) and
>   the word-diff (for display) in some clever format, so that the perl
>   code can easily match them up.  If neither one is possible my feeling
>   is that it's one of the hardest tasks on the list.  (Not to
>   discourcage anyone from trying, but still.)

Yes, please.. Also in some case, I'd like to pass the pattern to
--color-words (usually just --color-words=.). Something for the
student to think about when designing the interface.

> * Allow git send-email --cc 'foo@example.com, bar@example.com' instead
>   of git send-email --cc foo@example.com --cc bar@example.com
>
>   That would be really nice.  Bonus points if it handles continuation
>   lines etc. correctly, so that it's even easier to paste.

* Color the header lines in git send-email. Bonus point if it could
highlight possible typos like foo@example.co.
--
Duy

Re: Ensimag students projects, version 2013

[Ramkumar Ramachandra]

A few small personal itches off the top of my head:

- Make git status -s show "state status" as well: this essentially
requires writing an equivalent of wt_status_print_state() for use in
wt_shortstatus_print().

- Make the -s and -b switches in git status configuration variables.
I currently have status aliased to status -sb, and this is less than
ideal.

- Make the -3 and -c switches in git am configuration variables.  I
have an alias.

- Create an advice.ui (like color.ui) to turn off all advice.  I don't
need advice.

Re: Ensimag students projects, version 2013

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> - Make the -3 and -c switches in git am configuration variables.  I
> have an alias.

 - Make failed "git am --3way" due to "unusable index" a bit more
   helpful. Right now, the information on which hunk failed to apply
   is lost, and there is no "git am --no-3way" (the user needs to
   know the trick ">.git/rebase-apply/threeway").

Re: Ensimag students projects, version 2013

[Matthieu Moy]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> A few small personal itches off the top of my head:
>
> - Make git status -s show "state status" as well: this essentially
> requires writing an equivalent of wt_status_print_state() for use in
> wt_shortstatus_print().

Do you mean, showing it in a natural language form, or machine-parsable?

If the later, there was a patch series doing essentially this:

  http://thread.gmane.org/gmane.comp.version-control.git/209240

It doesn't seem to have been merged. Phil, what happened to it?

> - Make the -s and -b switches in git status configuration variables.
> I currently have status aliased to status -sb, and this is less than
> ideal.
>
> - Make the -3 and -c switches in git am configuration variables.  I
> have an alias.

Seems reasonable. Should be good technical warm-ups if people agree this
is a good idea.

> - Create an advice.ui (like color.ui) to turn off all advice.  I don't
> need advice.

I tend to agree with you, but the idea has explicitly been rejected in
the past. The problem with an option like this is that it would also
disable the advices that may be added in the future. By letting people
disable the advices one by one, people see new advices as they arrive.
You may think of it like "do not show this message again" tickboxes in
some graphical user interfaces.

Too controversial area for newcommers I guess ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: Ensimag students projects, version 2013

[Jeff King]

On Mon, Apr 15, 2013 at 06:32:49PM +0200, Matthieu Moy wrote:

> > - Create an advice.ui (like color.ui) to turn off all advice.  I don't
> > need advice.
> 
> I tend to agree with you, but the idea has explicitly been rejected in
> the past. The problem with an option like this is that it would also
> disable the advices that may be added in the future. By letting people
> disable the advices one by one, people see new advices as they arrive.
> You may think of it like "do not show this message again" tickboxes in
> some graphical user interfaces.

FWIW, I do not think it was so much rejected as that I had initially
planned to implement it, then decided against it. Mostly because I
wanted to actually get annoyed with each piece of advice before
disabling it. Because sometimes the right answer is actually "make the
advice better".

But I do not mind somebody adding it if it is a burning desire.

-Peff

Re: Ensimag students projects, version 2013

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> FWIW, I do not think it was so much rejected as that I had initially
> planned to implement it, then decided against it. Mostly because I
> wanted to actually get annoyed with each piece of advice before
> disabling it. Because sometimes the right answer is actually "make the
> advice better".

I am pretty much aligned with this position. "Make the advice
better" not only refers to what we say (i.e. the message) but when
we say it, and keeping the advice variables enabled is the only way
to notice when we are being excessive.

I'd hate to see any Git developers running with advice turned off
for this exact reason.

Re: Ensimag students projects, version 2013

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> I'd hate to see any Git developers running with advice turned off
> for this exact reason.

Improving advice is your itch, but it is certainly not my itch.  I
don't want to see messages like "Commit your changes or stash them",
or "try --continue | --skip | --abort" cluttering up my valuable
terminal output when I know what to do.  I don't care how they can be
made "better", because I don't want to see them in the first place.

You should have nothing against me for running with all advice turned
off.  It's not your job to dictate how a software should be used, but
rather design it so that intended usage is the most intuitive.

Re: Ensimag students projects, version 2013

[Ramkumar Ramachandra]

Matthieu Moy wrote:
> I tend to agree with you, but the idea has explicitly been rejected in
> the past. The problem with an option like this is that it would also
> disable the advices that may be added in the future. By letting people
> disable the advices one by one, people see new advices as they arrive.
> You may think of it like "do not show this message again" tickboxes in
> some graphical user interfaces.
>
> Too controversial area for newcommers I guess ;-).

This is the kind of nonsense that I absolutely won't stand for.  Am I
a less important customer than a newcomer?  Hell, if anything, I'm the
_more_ important customer because I spend time improving git while a
newcomer makes no contribution whatsoever.  In my opinion, the most
important customers of git are (in this order of precedence):

1. Developers who hack on git to make it better.  This means that the
implementation must have a pleasing consistency, and end-user
expectations of UI are secondary.  For some reason, Junio seems to
disagree with this.

2. Advanced users hacking on projects that demand effective use of git
like linux.git and git.git, as opposed to some little project on
GitHub that just accepts pull requests.

3. Newcomers.

I don't develop git for newcomers.  I develop git for myself, and
scratch my personal itches.  The most important customer to me is
myself, and everyone else is secondary.

That said, I don't feel strongly about this particular advice.ui
issue, and Jeff/ Junio have presented a reasonably cogent argument.

Re: Ensimag students projects, version 2013

[Junio C Hamano]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> Matthieu Moy wrote:
>> I tend to agree with you, but the idea has explicitly been rejected in
>> the past. The problem with an option like this is that it would also
>> disable the advices that may be added in the future. By letting people
>> disable the advices one by one, people see new advices as they arrive.
>> You may think of it like "do not show this message again" tickboxes in
>> some graphical user interfaces.
>>
>> Too controversial area for newcommers I guess ;-).
>
> This is the kind of nonsense that I absolutely won't stand for.  Am I
> a less important customer than a newcomer?

Who said anything about a customer?

A newcomer to a community (i.e. Matthieu's student) needs not just
to show technical excellence with patches, but needs to make a good
argument on a larger design decision; old timers already tried to
achieve a concensus on it, and did not manage to do so the last time
we tried.

It is a tough topic for a newcomer developer to tackle.

Re: Ensimag students projects, version 2013

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> It is a tough topic for a newcomer developer to tackle.

Agreed.  We should give these students tasks that are relatively
straightforward, and not controversial.

Re: Ensimag students projects, version 2013

[Ramkumar Ramachandra]

Junio C Hamano wrote:
> Who said anything about a customer?
>
> A newcomer to a community (i.e. Matthieu's student) needs not just
> to show technical excellence with patches, but needs to make a good
> argument on a larger design decision; old timers already tried to
> achieve a concensus on it, and did not manage to do so the last time
> we tried.

And sorry about the huge misunderstanding.  I thought Matthieu was
saying that the proposed configuration variable would be harmful to
newcomers, and we should therefore not add it.

I feel very silly about having written such a long response to
something I misunderstood.

Re: Ensimag students projects, version 2013

[Phil Hord]

On Mon, Apr 15, 2013 at 11:18 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> A few small personal itches off the top of my head:
>
> - Make git status -s show "state status" as well: this essentially
> requires writing an equivalent of wt_status_print_state() for use in
> wt_shortstatus_print().

I actually submitted a patch for this last fall.   I was going to
reprise it and give it another run after your wt_status changes died
down (and I found some free time).

http://comments.gmane.org/gmane.comp.version-control.git/208209

Phil