On Mon, Sep 23, 2019 at 3:35 PM Emily Shaffer <emilyshaf...@google.com> wrote: > > 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. > """ > "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.
