Re: Git in Outreachy December 2019?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 20, 2019 at 06:47:01PM -0700, Emily Shaffer wrote:

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

This is an interesting idea. At first I thought it might be too small
for a project, but I think it could be expanded or contracted as much as
the time allows by just looking for more "did you mean" spots.

I have mixed feelings on making things interactive. For one, it gets
awkward when Git commands are called as part of a script or other
program (and a lot of programs like git-commit ride the line of plumbing
and porcelain). I know this would kick in only when a config option is
set, but I think that might things even _more_ confusing, as something
that works for one user (without the config) would start behaving
weirdly for another.

I also think it might be an opportunity to educate. Instead of giving a
yes/no prompt, we can actually recommend one (or more!) sets of commands
to get the desired effect. I _thought_ we already did for this case by
default (triggered by advice.statusHints, which is true by default). But
it looks like those don't get printed for git-commit?

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux