Ensimag students projects, version 2013

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.

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:

Ping Yin <pkufranky@gmail.com> writes:

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

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

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.ethz.ch> writes:

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

[...]

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.

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.

Added to the wiki too.

Thanks,

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

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

On Mon, Apr 15, 2013 at 11:24:21AM +0200, Matthieu Moy 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.

-Peff

Jeff King <peff@peff.net> writes:

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.

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

The one I was thinking of is:

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

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

On Mon, Apr 15, 2013 at 7:06 PM, Thomas Rast <trast@inf.ethz.ch> wrote:

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.

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

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.

Ramkumar Ramachandra <artagnon@gmail.com> writes:

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

Ramkumar Ramachandra <artagnon@gmail.com> writes:

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?

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

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

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

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

Jeff King <peff@peff.net> writes:

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.

Junio C Hamano wrote:

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.

Matthieu Moy wrote:

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.

Ramkumar Ramachandra <artagnon@gmail.com> writes:

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.

Junio C Hamano wrote:

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

Junio C Hamano wrote:

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.

On Mon, Apr 15, 2013 at 11:18 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

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