Re: Git in Outreachy December 2019?

From: Christian Couder <christian.couder@gmail.com>
Date: Sep 23, 2019, 14:23 UTC
Message-ID: <CAP8UFD3zw1dYUZ8Sei+kzcYmcsgQsRLoy1uHU+ZQp6CBDbCVkQ@mail.gmail.com>
In-Reply-To: <20190921014701.GA191795@google.com>

On Mon, Sep 23, 2019 at 3:35 PM Emily Shaffer <emilyshaffer@google.com> wrote:

Show 9 quoted lines

>
> On Fri, Sep 20, 2019 at 10:04:48AM -0700, Jonathan Tan wrote:
>
> > I'm new to Outreachy and programs like this, so does anyone have an
> > opinion on my draft proposal below? It does not have any immediate
> > user-facing benefit, but it does have a definite end point.
>
> I'd appreciate similar opinion if anybody has it - and I'd also really
> feel more comfortable with a co-mentor.

First as the deadline is tomorrow, I think it is important to submit projects to Outreachy even if they are not perfect and even if we would like a co-mentor (which is also my case by the way).

We can hopefully improve the projects after the deadline or perhaps drop them if we cannot find enough co-mentors or if we don't agree with the goal or find it too difficult.

Show 33 quoted lines

> """
> "Did You Mean..?"
>
> There are some situations where it's fairly clear what a user meant to
> do, even though they did not do that thing correctly. For example, if a
> user runs `git commit` with tracked, modified, unstaged files in their
> worktree, but no staged files at all, it's fairly likely that they
> simply forgot to add the files they wanted. In this case, the error
> message is slightly obtuse:
>
> $ git commit
> On branch master
> Changes not staged for commit:
>         modified:   foo.txt
>
> no changes added to commit
>
>
> Since we have an idea of what the user _meant_ to do, we can offer
> something more like:
>
> $ git commit
> On branch master
> Changes not staged for commit:
>         modified:   foo.txt
>
> Stage listed changes and continue? [Y/n]
>
> While the above case is a good starting place, other similar cases can
> be added afterwards if time permits. These helper prompts should be
> enabled/disabled via a config option so that people who are used to
> their current workflow won't be impacted.
> """

I agree that it might help. There could be significant discussion about what the UI should be though. For example maybe we could just promote `git commit -p` in the tutorials instead of doing the above. Or have a commit.patch config option if we haven't one already.

Thanks, Christian.