git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Elijah Newren <newren@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] Make running git under other debugger-like programs easy
Date: Fri, 6 Apr 2018 12:38:29 +0200 (DST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1804061233330.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz> (raw)
In-Reply-To: <CABPp-BHhdxuV9a_4OfgaRu89Kx2039OLeS1vW-KdzpLxb-ZF3g@mail.gmail.com>

Hi Elijah,

On Thu, 5 Apr 2018, Elijah Newren wrote:

> On Thu, Apr 5, 2018 at 12:57 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> 
> > I wonder whether a better approach would be to add an optional argument to
> > that `debug` function (which is intended to have `git` as first argument,
> > anyway, or at least a command/function that does not start with a dash):
> >
> > debug_aux () {
> >         shift
> >         "$@" <&6 >&5 2>&7
> > }
> >
> > debug () {
> >         case "$1" in
> >         -d)
> >                 shift &&
> >                 GIT_TEST_GDB="$1" debug_aux "$@"
> >                 ;;
> >         --debugger=*)
> >                 GIT_TEST_GDB="${1#*=}" debug_aux "$@"
> >                 ;;
> >         *)
> >                 GIT_TEST_GDB=1 "$@" <&6 >&5 2>&7
> >                 ;;
> >         esac
> > }
> >
> > ... and then in wrap-for-bin.sh, we would replace the last lines
> >
> > if test -n "$GIT_TEST_GDB"
> > then
> >         unset GIT_TEST_GDB
> >         exec gdb --args "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> > else
> >         exec "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> > fi
> >
> > by
> >
> > case "$GIT_TEST_GDB" in
> > '')
> >         exec "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> >         ;;
> > 1)
> >         unset GIT_TEST_GDB
> >         exec gdb --args "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> >         ;;
> > *)
> >         GIT_TEST_GDB_$$="$GIT_TEST_GDB"
> >         unset GIT_TEST_GDB
> >         exec $GIT_TEST_GDB_$$ "${GIT_EXEC_PATH}/@@PROG@@" "$@"
> >         ;;
> > esac
> >
> > or some such.
> 
> That all looks great to me.  But at this point, it seems like it's a
> full rewrite and your patch to submit (which I'd be happy to endorse
> in lieu of my own)...

:-)

> or do you want me to submit with you as author and me as committer?

That would be my preference. I have not even tested what I wrote above...

> Also, a side question: if we go this route, do we want to rename
> GIT_TEST_GDB to reflect its expanded usage?

Sure. Probably GIT_TEST_DEBUGGER? Or GIT_TEST_DBG? Or GIT_TEST_DEBUG?

> > Then your magic "GIT_WRAPPER" invocation would become a bit more explicit:
> >
> >     debug --debugger=nemiver git $ARGS
> >     debug -d "valgrind --tool=memcheck --track-origins=yes" git $ARGS
> 
> No, for most (60-80%?) of my invocations, I wouldn't be able to use
> the debug function; only a minority of my uses are from within the
> testsuite.  The rest are from the command line (I have
> git/bin-wrappers/ in my $PATH),

Oy vey. bin-wrappers in your PATH? That's even worse than what I did in
the first two years of developing Git: I always ran `git` in-place.
However, I was bitten by a couple of bugs introduced while developing that
made it hard to recover (if I don't have a functional Git, I cannot use it
to go back to a working version, can I?). How do *you* deal with these
things?

> so the above suggestions would mean that my invocation would become:
> 
> GIT_TEST_GDB="nemiver" git $ARGS
> GIT_TEST_GDB="valgrind --tool-memcheck --track-origins=yes" git $ARGS

Right.

> > (In any case, "GIT_WRAPPER" is probably a name in want of being renamed.)
> 
> Well, with your suggestion, it'd just be whatever that environment
> variable is named.  I'm perfectly happy with something other than
> GIT_WRAPPER (or GIT_TEST_GDB).  I'm not so good at coming up with such
> myself, but maybe something like GIT_DEBUGGER or GIT_DEBUG_WITH?

I like both. Pick whatever you like, as long as it starts with `GIT_` and
is descriptive enough. Even `GIT_LAUNCH_THROUGH` would work, but
`GIT_DEBUGGER` seems to be the shortest that still makes sense.

Ciao,
Dscho

  reply	other threads:[~2018-04-06 10:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 17:49 [PATCH] Make running git under other debugger-like programs easy Elijah Newren
2018-04-05 19:57 ` Johannes Schindelin
2018-04-05 21:16   ` Elijah Newren
2018-04-06 10:38     ` Johannes Schindelin [this message]
2018-04-06 22:36       ` Elijah Newren
2018-04-09 18:51 ` [PATCH v2] " Elijah Newren
2018-04-09 21:19   ` Johannes Schindelin
2018-04-10  0:48     ` Elijah Newren
2018-04-10  8:26       ` Johannes Schindelin
2018-04-24 23:46         ` [PATCH v3] " Elijah Newren
2018-04-25  7:25           ` Johannes Schindelin
2018-04-26  1:56             ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1804061233330.55@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz \
    --to=johannes.schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).