| Message ID | 20210908051340.13332-1-colinpcurtis826@ucla.edu (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add cmd_gud and detect libiconv path for Mac OS | expand |
On 08/09/21 12.13, Colin Curtis wrote: > From: Colin Curtis <colinpcurtis@gmail.com> > > The gud command opens the Pro Git book webpage in the default > web browser. The reason to add this command is due to the > play on words when saying 'git gud', which sounds like 'get good'. > Hence this command when invoked will open up the Pro Git > webpage to allow the user to 'get good' at git. > > We also fix a bug in the Makefile when running on Mac OS, namely > the libiconv path when using a brew install for the library. Previously > the developer would have to manually change the path to the library when > developing on Mac OS. > Two distinct topics in one patch series. Why don't you create separate patch series for each topic? For `git gud`, I think there's no point on adding such easter egg, since users can simply access git-scm.com with their browser, without needing specialized command just to invoke it.
On Tue, Sep 07 2021, Colin Curtis wrote: > From: Colin Curtis <colinpcurtis@gmail.com> > > The gud command opens the Pro Git book webpage in the default > web browser. The reason to add this command is due to the > play on words when saying 'git gud', which sounds like 'get good'. > Hence this command when invoked will open up the Pro Git > webpage to allow the user to 'get good' at git. Purely in terms of implementation if we had this sort of thing it really would belong in "git help", not in an overly cleverly named new built-in. More generally we don't link to git-scm.org now for anything significant, AFAICT the only things we do link to are to our own generated documentation. [Not with my Git PLC hat on, in case anyone's wondering] I don't think we should be further endorsing proprietary documentation in liue of improving the free docs in git.git itself. If this command (whether via "git help" or not) linked to anything it should be to our own https://git-scm.com/docs/user-manual; if there's things lacking there let's try to improve the freely available docs. And purely in terms of UX once we had such freely available docs we should not be opening a webpage to display them, but linking to a manpage etc. Perhaps we should be opening a webpage, and indeed "git help" can do that for you, but that should be to docs we have built locally & are guaranteed to apply to the git version you're working with.
From: Colin Curtis <colinpcurtis@gmail.com> The gud command opens the Pro Git book webpage in the default web browser. The reason to add this command is due to the play on words when saying 'git gud', which sounds like 'get good'. Hence this command when invoked will open up the Pro Git webpage to allow the user to 'get good' at git. We also fix a bug in the Makefile when running on Mac OS, namely the libiconv path when using a brew install for the library. Previously the developer would have to manually change the path to the library when developing on Mac OS. Colin Curtis (2): add cmd_gud to open git-scm.com webpage add liconv link for makefile .gitignore | 1 + Documentation/git-gud.txt | 33 +++++++++++++++++++++++++++++++++ Makefile | 9 +++++++-- builtin.h | 1 + builtin/gud.c | 27 +++++++++++++++++++++++++++ git.c | 1 + t/t9904-git-gud.sh | 16 ++++++++++++++++ 7 files changed, 86 insertions(+), 2 deletions(-) create mode 100644 Documentation/git-gud.txt create mode 100644 builtin/gud.c create mode 100755 t/t9904-git-gud.sh