Issue 4550: Avoid "using namespace std;" in included files (Take 2)

https://sourceforge.net/p/testlilyissues/issues/4550/

For those inexperienced with the problems this can cause, see http://stackoverflow.com/questions/1452721/why-is-using-namespace-std-considered-bad-practice

Some of these changes are manual and others are scripted.  I have them in separate commits, though everything is squashed together in this review.  Depending on what other changes are pushed while this is in review, I may need to recreate the scripted commit before I push.  I will post the script in the review comments.

Summary of these changes:
  * eliminate "using namespace std;"
  * add "std::" to everything in *.hh files (and other included files)
  * add "using std::whatever;" in *.cc files for common types (e.g. string, vector)
  * add "std::" in *.cc files for functions (e.g. swap) and other less common things (e.g. less)

Here's the review from the first attempt (4.5 years ago):
https://codereview.appspot.com/254670043/

[Dan Eble, 2020-01-22 13:43:34]

# This script runs in bash.  It might require bash; I don't know.

# $1 = words to find e.g. '\(foo\|bar\)'
# $2 = file name
function add_std_prefix_to_word () {
    sed -i '' -E "/^#/!s/(^|[^_0-9A-Za-z:\\.])($1)[[:>:]]/\\1std::\\2/g" $2
}

# $1 = types to find
# $2 = file name
function add_std_prefix_to_template () {
    sed -i '' -E "/^#/!{
:top
s/(^|[^_0-9A-Za-z:\\.])($1) *< */\\1std::\\2</
ttop
}" $2
}

# remove "using namespace std;" everywhere
for FILE in $(git grep -l -E "using namespace" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc|*.ll|*.yy)
	    sed -i '' -E "/^ *using namespace std;.*\$/d" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these words in included files
TYPES_RE='(istream|string)'
for FILE in $(git grep -l -E "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.hh|*.[it]cc)
	    add_std_prefix_to_word "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these words in all files
TYPES_RE='(endl|hex|ios|cerr|cout)'
for FILE in $(git grep -l -E "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc)
	    add_std_prefix_to_word "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these templates in included files
TYPES_RE='(list|map|pair|set|vector)'
for FILE in $(git grep -l -E "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.hh|*.[it]cc)
	    add_std_prefix_to_template "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

# add "std::" to these templates everywhere
TYPES_RE='(greater|less|numeric_limits|unary_function)'
for FILE in $(git grep -l -E "$TYPES_RE" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc)
	    add_std_prefix_to_template "$TYPES_RE" "$FILE"
	    ;;
	*)
    esac
done

FUNCS_RE='(isfinite|isinf|isnan|make_pair|max|min|setfill|setw|swap)'
for FILE in $(git grep -l -E "$FUNCS_RE" flower lily)
do
    case "$FILE" in
	*.cc|*.hh|*.[it]cc)
	    # add "std::" to function name
	    sed -i '' -E "/^ *using std::$FUNCS_RE;.*\$/d
/^#/!{
:top
s/(^|[^_0-9A-Za-z:\\.])($FUNCS_RE *\\([^\\)])/\\1std::\\2/
ttop
}" $FILE
	    ;;
	*)
    esac
done

[Dan Eble, 2020-01-22 13:47:08]

On 2020/01/22 13:43:34, Dan Eble wrote:
> # This script runs in bash.  It might require bash; I don't know.

Also, YMMV.   I ran it in a macOS terminal and I have various packages installed
with Homebrew.  I'm not sure whether the sed (and other) commands are portable
to Linux environments.  I'm not sure whether it would run in a vanilla macOS
environment.

[lemzwerg, 2020-01-23 11:33:11]

I'm quite sure that you have more experience with C++ than me, however, I'm not
really happy with this change since it makes the code substantially uglier. 
Isn't there another solution for the problem?

https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
File flower/include/file-name.hh (right):

https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
flower/include/file-name.hh:47: std::string root_;
This is very ugly.  What about using the `std` namespace within a group instead?

[dak, 2020-01-23 11:54:28]

On 2020/01/23 11:33:11, lemzwerg wrote:
> I'm quite sure that you have more experience with C++ than me, however, I'm
not
> really happy with this change since it makes the code substantially uglier. 
> Isn't there another solution for the problem?
> 
>
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
> File flower/include/file-name.hh (right):
> 
>
https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
> flower/include/file-name.hh:47: std::string root_;
> This is very ugly.  What about using the `std` namespace within a group
instead?

I'd say that ship has sailed by virtue of the C++ standard committee.  Most
current changes of Dan are supposed to bring the LilyPond code base in line with
what C++ programmers are used to experiencing.  And for better or worse, std::
most certainly has become part of that experience.  So I am with Dan here.

[hahnjo, 2020-01-23 12:10:51]

https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
File flower/include/file-name.hh (right):

https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
flower/include/file-name.hh:47: std::string root_;
On 2020/01/23 11:33:11, lemzwerg wrote:
> This is very ugly.  What about using the `std` namespace within a group
instead?

Why is this ugly? std::string is really the name of the class. See this SO
thread on my "using namespace" is considered back practice:
https://stackoverflow.com/q/1452721/10606944

[lemzwerg, 2020-01-23 12:43:34]

> Why is this ugly? std::string is really the name of the class.

No question, but I would prefer

  struct xxx {
    using std:string;

    string foo;
    string bar;
    string baz;
  }
}

to

  struct xxx {
    std::string foo;
    std::string bar;
    std::string baz;
  }

for example, to increase legibility if there are many strings.

[Dan Eble, 2020-01-23 12:55:35]

https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
File flower/include/file-name.hh (right):

https://codereview.appspot.com/579240043/diff/577360043/flower/include/file-n...
flower/include/file-name.hh:47: std::string root_;
On 2020/01/23 11:33:11, lemzwerg wrote:
> This is very ugly.

I sympathize, but it is unambiguous.

> What about using the `std` namespace within a group instead?

It is possible to define a type alias File_name::string that can be used as
"string" in the body of the class definition, in the parameter lists of
File_name member functions (but not in the return values), and in the bodies of
File_name member functions.  It would look like this:

    class File_name
    {
      using string = std::string; // C++11
      // or in the old style: typedef std::string string;
      ...

Of course, you would need to do the same for each type or function that you
wanted to avoid qualifying, and you would still have a bad time if you tried to
use it in particular cases where it creates ambiguity.

In a professional setting, I wouldn't advocate using this technique in such a
simple case, but if I had colleagues who loved it, I would put up with it to
keep the peace.  I'd ask them not to demand that I follow their example in
subsystems that were my responsibility.

I expect that switching to this style consistently in LilyPond would require an
amount of labor that I am not currently willing to devote.  Thankfully, it seems
the consensus on this patch is starting to point toward "take it" rather than
"leave it."

[dak, 2020-01-23 14:36:26]

On 2020/01/23 12:43:34, lemzwerg wrote:
> > Why is this ugly? std::string is really the name of the class.
> 
> No question, but I would prefer
> 
>   struct xxx {
>     using std:string;
> 
>     string foo;
>     string bar;
>     string baz;
>   }
> }
> 
> to
> 
>   struct xxx {
>     std::string foo;
>     std::string bar;
>     std::string baz;
>   }
> 
> for example, to increase legibility if there are many strings.

In my book, local types _decrease_ legibility since they force you to hunt
around for the definition in order to know what one is actually talking about.

[dak, 2020-01-23 14:39:36]

On 2020/01/23 14:36:26, dak wrote:
> On 2020/01/23 12:43:34, lemzwerg wrote:
> > > Why is this ugly? std::string is really the name of the class.
> > 
> > No question, but I would prefer
> > 
> >   struct xxx {
> >     using std:string;
> > 
> >     string foo;
> >     string bar;
> >     string baz;
> >   }
> > }
> > 
> > to
> > 
> >   struct xxx {
> >     std::string foo;
> >     std::string bar;
> >     std::string baz;
> >   }
> > 
> > for example, to increase legibility if there are many strings.
> 
> In my book, local types _decrease_ legibility since they force you to hunt
> around for the definition in order to know what one is actually talking about.

But it's not actually an opinion contest.  The question is what use is
predominant in current C++ programming.  And most particularly in _libraries_,
one does not introduce arbitrary type aliases without very good reason.

[lemzwerg, 2020-01-23 18:37:12]

OK, point taken.  Thanks for all the responses.

Well, then the ugly way :-)

[haberg-1_telia.com, 2020-01-23 19:57:25]

> On 23 Jan 2020, at 13:43, lemzwerg--- via Discussions on LilyPond development
<lilypond-devel@gnu.org> wrote:
> 
>> Why is this ugly? std::string is really the name of the class.
> 
> No question, but I would prefer
> 
>  struct xxx {
>    using std:string;
> 
>    string foo;
>    string bar;
>    string baz;
>  }
> }
> 
> to
> 
>  struct xxx {
>    std::string foo;
>    std::string bar;
>    std::string baz;
>  }
> 
> for example, to increase legibility if there are many strings.

When using ones own namespace reusing names of std, then the external object
must be qualified. For example,

namespace lly {

  class string {
  public:
    string(const std::string&);

    explicit operator std::string() const;
  };

  …

  inline string operator+(string& x, string& y) {
    return std::string(x) + std::string(y);
  }

} // namespace lly

[Dan Eble, 2020-01-24 11:22:43]

I'd like special permission to skip the countdown and push this today instead of
tomorrow.  Would that be OK?

[hahnjo, 2020-01-24 13:39:15]

On 2020/01/24 11:22:43, Dan Eble wrote:
> I'd like special permission to skip the countdown and push this today instead
of
> tomorrow.  Would that be OK?

Not my call, but maybe you can give a reason? Is it the expected merge
conflicts? If so, it's probably shifting the problem from you to everyone
else...

[dak, 2020-01-24 13:45:50]

On 2020/01/24 13:39:15, hahnjo wrote:
> On 2020/01/24 11:22:43, Dan Eble wrote:
> > I'd like special permission to skip the countdown and push this today
instead
> of
> > tomorrow.  Would that be OK?
> 
> Not my call, but maybe you can give a reason? Is it the expected merge
> conflicts? If so, it's probably shifting the problem from you to everyone
> else...

Hoo yes.  That kind of extensive change is going to hurt anyway given the
current burst activity level.  It will likely suck either way.  Do you have
particular dependencies yourself, Dan?

[Dan Eble, 2020-01-24 13:57:33]

On 2020/01/24 13:45:50, dak wrote:
> Hoo yes.  That kind of extensive change is going to hurt anyway given the
> current burst activity level.  It will likely suck either way.  Do you have
> particular dependencies yourself, Dan?

I have a bunch of private branches (contexts, rehearsal marks, warning clean-up)
that I would like to get on with rebasing.  Normally, once I'm pretty sure that
a change of mine will be pushed, I'll just rebase to it locally, but with this
one, I don't want to start until it's in master.

If you want help handling Han-Wen's patches tomorrow, you can delegate some to
me.

[dak, 2020-01-24 15:26:06]

On 2020/01/24 13:57:33, Dan Eble wrote:
> On 2020/01/24 13:45:50, dak wrote:
> > Hoo yes.  That kind of extensive change is going to hurt anyway given the
> > current burst activity level.  It will likely suck either way.  Do you have
> > particular dependencies yourself, Dan?
> 
> I have a bunch of private branches (contexts, rehearsal marks, warning
clean-up)
> that I would like to get on with rebasing.  Normally, once I'm pretty sure
that
> a change of mine will be pushed, I'll just rebase to it locally, but with this
> one, I don't want to start until it's in master.
> 
> If you want help handling Han-Wen's patches tomorrow, you can delegate some to
> me.

Well, I should be able to handle them well enough.  It would be preferable if
Han-Wen would provide Git-formatted patches (Rietveld is missing out on commit
messages unless you consider scooping them up from the description as such, and
while I would make sure that issue numbers are in the title lines, I think
future rebases/merges at least for Han-Wen himself would work better if I work
from original commits rather than original diffs).  And then it makes little
sense distributing those patches to more than one person.

[dak, 2020-01-24 15:26:50]

On 2020/01/24 15:26:06, dak wrote:
> On 2020/01/24 13:57:33, Dan Eble wrote:
> > On 2020/01/24 13:45:50, dak wrote:
> > > Hoo yes.  That kind of extensive change is going to hurt anyway given the
> > > current burst activity level.  It will likely suck either way.  Do you
have
> > > particular dependencies yourself, Dan?
> > 
> > I have a bunch of private branches (contexts, rehearsal marks, warning
> clean-up)
> > that I would like to get on with rebasing.  Normally, once I'm pretty sure
> that
> > a change of mine will be pushed, I'll just rebase to it locally, but with
this
> > one, I don't want to start until it's in master.
> > 
> > If you want help handling Han-Wen's patches tomorrow, you can delegate some
to
> > me.
> 
> Well, I should be able to handle them well enough.  It would be preferable if
> Han-Wen would provide Git-formatted patches (Rietveld is missing out on commit
> messages unless you consider scooping them up from the description as such,
and
> while I would make sure that issue numbers are in the title lines, I think
> future rebases/merges at least for Han-Wen himself would work better if I work
> from original commits rather than original diffs).  And then it makes little
> sense distributing those patches to more than one person.

What I meant to say: I guess I should be able to handle those comparatively
obvious merge conflicts.

[hanwenn, 2020-01-24 15:32:43]

On Fri, Jan 24, 2020 at 4:26 PM <dak@gnu.org> wrote:
>
> On 2020/01/24 13:57:33, Dan Eble wrote:
> > On 2020/01/24 13:45:50, dak wrote:
> > > Hoo yes.  That kind of extensive change is going to hurt anyway
> given the
> > > current burst activity level.  It will likely suck either way.  Do
> you have
> > > particular dependencies yourself, Dan?
> >
> > I have a bunch of private branches (contexts, rehearsal marks, warning
> clean-up)
> > that I would like to get on with rebasing.  Normally, once I'm pretty
> sure that
> > a change of mine will be pushed, I'll just rebase to it locally, but
> with this
> > one, I don't want to start until it's in master.
> >
> > If you want help handling Han-Wen's patches tomorrow, you can delegate
> some to
> > me.
>
> Well, I should be able to handle them well enough.  It would be
> preferable if Han-Wen would provide Git-formatted patches (Rietveld is
> missing out on commit messages unless you consider scooping them up from
> the description as such, and while I would make sure that issue numbers
> are in the title lines, I think future rebases/merges at least for
> Han-Wen himself would work better if I work from original commits rather
> than original diffs).  And then it makes little sense distributing those
> patches to more than one person.

this goes back to what we discussed in Salzburg, namely that our
tooling is clumsy. Having a gerrit or GH/GL based workflow would let
us review and exchange diffs as native Git commits, which simplifies a
lot of things.

I'm happy to push my stuff to some git branch somewhere, if that helps you.

BTW, Why do we insist in associating each review with a sf.net issue,
even if there is no related bug?

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen

[hanwenn, 2020-01-24 15:37:36]

this change seems uncontroversial, and if it compiles, it should be
good to push.

On Fri, Jan 24, 2020 at 12:22 PM <nine.fierce.ballads@gmail.com> wrote:
>
> I'd like special permission to skip the countdown and push this today
> instead of tomorrow.  Would that be OK?
>
> https://codereview.appspot.com/579240043/
>


-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen

[hahnjo, 2020-01-24 15:43:53]

On 2020/01/24 15:32:43, hanwenn wrote:
> On Fri, Jan 24, 2020 at 4:26 PM <mailto:dak@gnu.org> wrote:
> >
> > On 2020/01/24 13:57:33, Dan Eble wrote:
> > > On 2020/01/24 13:45:50, dak wrote:
> > > > Hoo yes.  That kind of extensive change is going to hurt anyway
> > given the
> > > > current burst activity level.  It will likely suck either way.  Do
> > you have
> > > > particular dependencies yourself, Dan?
> > >
> > > I have a bunch of private branches (contexts, rehearsal marks, warning
> > clean-up)
> > > that I would like to get on with rebasing.  Normally, once I'm pretty
> > sure that
> > > a change of mine will be pushed, I'll just rebase to it locally, but
> > with this
> > > one, I don't want to start until it's in master.
> > >
> > > If you want help handling Han-Wen's patches tomorrow, you can delegate
> > some to
> > > me.
> >
> > Well, I should be able to handle them well enough.  It would be
> > preferable if Han-Wen would provide Git-formatted patches (Rietveld is
> > missing out on commit messages unless you consider scooping them up from
> > the description as such, and while I would make sure that issue numbers
> > are in the title lines, I think future rebases/merges at least for
> > Han-Wen himself would work better if I work from original commits rather
> > than original diffs).  And then it makes little sense distributing those
> > patches to more than one person.
> 
> this goes back to what we discussed in Salzburg, namely that our
> tooling is clumsy. Having a gerrit or GH/GL based workflow would let
> us review and exchange diffs as native Git commits, which simplifies a
> lot of things.
> 
> I'm happy to push my stuff to some git branch somewhere, if that helps you.

I wasn't in Salzburg, but why can't you push to staging as everybody else does?
It's not harder than pushing to a random branch and you obviously have all
commits locally, don't you?

> BTW, Why do we insist in associating each review with a http://sf.net issue,
> even if there is no related bug?

I think there's no initial message for a new patch here, so there needs to be a
place where new patches go and others can see them.

[pkx166h_posteo.net, 2020-01-24 16:02:31]

On 24/01/2020 15:43, jonas.hahnfeld@gmail.com wrote:
> On 2020/01/24 15:32:43, hanwenn wrote:
>> On Fri, Jan 24, 2020 at 4:26 PM <mailto:dak@gnu.org> wrote:
>> ...
>> BTW, Why do we insist in associating each review with a http://sf.net
> issue,
>> even if there is no related bug?
> I think there's no initial message for a new patch here, so there needs
> to be a place where new patches go and others can see them.
>
> https://codereview.appspot.com/579240043/
>
Correct (mostly), when the scripts for patch testing worked (they can 
still be found in lilypond-extra) they would scan Allura and before that 
... google's issue tracker (I forget its name) for anything with Patch = 
new. Then it would scrape the issue for the Rietveld link and apply the 
diff. All automatically.

git-cl would create the issue, set the labels and paste the rietveld.

Hence the need for an 'issue'.

Today we (or I) simply look for any issue with new/started labels and 
scan for the URL myself.

That's why we have a tracker. This is something that was in place when I 
started, all I provided back then was a powerful machine that could test 
the patches using the patchy-test script (it'd run on a cron job and 
save the diffs in a local dir that I could check visually).

I'd then edit the issue saying it passed all tests (or failed and how).

What we have today is because these scripts never got updated for Allura 
(when we moved from google code's tracker).

James

[hanwenn, 2020-01-24 16:17:52]

On Fri, Jan 24, 2020 at 4:43 PM <jonas.hahnfeld@gmail.com> wrote:
> > > Well, I should be able to handle them well enough.  It would be
> > > preferable if Han-Wen would provide Git-formatted patches (Rietveld
> is
> > > missing out on commit messages unless you consider scooping them up
> from
> > > the description as such, and while I would make sure that issue
> numbers
> > > are in the title lines, I think future rebases/merges at least for
> > > Han-Wen himself would work better if I work from original commits
> rather
> > > than original diffs).  And then it makes little sense distributing
> those
> > > patches to more than one person.
> >
> > this goes back to what we discussed in Salzburg, namely that our
> > tooling is clumsy. Having a gerrit or GH/GL based workflow would let
> > us review and exchange diffs as native Git commits, which simplifies a
> > lot of things.
> >
> > I'm happy to push my stuff to some git branch somewhere, if that helps
> you.
>
> I wasn't in Salzburg, but why can't you push to staging as everybody
> else does? It's not harder than pushing to a random branch and you
> obviously have all commits locally, don't you?

I am lazy, and quite busy :-)

There is a certain amount of process to follow; especially the part
where I have to wait for a couple of days for the countdown to
complete is something I lack the patience for.  Also, I now have 26
outstanding patches; coordinating this with rietveld LGTMs and
countdowns is a bit of a bother.

If y'all think that I should be allowed to bypass process, then that
would simplify things, obviously, but I also make mistakes that the
process is designed to catc.

> > BTW, Why do we insist in associating each review with a http://sf.net
> issue,
> > even if there is no related bug?
>
> I think there's no initial message for a new patch here, so there needs
> to be a place where new patches go and others can see them.

Git-CL gets a token, so presumably, it could also post a request to
press the 'm' button

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen

[wl_gnu.org, 2020-01-24 17:53:11]

> What I meant to say: I guess I should be able to handle those
> comparatively obvious merge conflicts.
> 
> https://codereview.appspot.com/579240043/

Thanks for taking care of Han-Wen's patches.  My back is still not OK;
I must avoid sitting too much in front of the computer currently...


    Werner

[dak, 2020-01-25 12:26:22]

dak@gnu.org writes:

> On 2020/01/24 15:26:06, dak wrote:
>
> What I meant to say: I guess I should be able to handle those
> comparatively obvious merge conflicts.
>
> https://codereview.appspot.com/579240043/

But frankly, I have not been reckoning with having to deal with the ilk
of

commit 6f4128e1f359daf38a3caf2c0e4ad68e16c10540
Author: Dan Eble <nine.fierce.ballads@gmail.com>
Date:   Thu Jan 9 13:04:18 2020 -0500

    Issue 4550/2: Avoid "using namespace std;" in included files
    
    These are manual changes in preparation for an automated removal of
    "using namespace std;".
    
    Mostly, these are additions of using-declarations for commonly used
    types and containers (e.g. std::string, std::vector) to *.cc files so
    that they will continue to build after the big removal.

diff --git a/lily/slur-scoring.cc b/lily/slur-scoring.cc
index bb779a040e..262b41a677 100644
--- a/lily/slur-scoring.cc
+++ b/lily/slur-scoring.cc
@@ -45,6 +45,9 @@
 #include "stem.hh"
 #include "warn.hh"
 
+using std::string;
+using std::vector;
+
 /*
   TODO:
 
@@ -122,12 +125,12 @@ Slur_score_state::get_encompass_info (Grob *col) const
 
   if (Grob *head = Note_column::first_head (col))
     {
-      Interval hex = head->extent (common_[X_AXIS], X_AXIS);
+      Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
       // FIXME: Is there a better option than setting to 0?
-      if (hex.is_empty ())
+      if (head_ext.is_empty ())
         ei.x_ = 0;
       else
-        ei.x_ = hex.center ();
+        ei.x_ = head_ext.center ();
     }
   else
     ei.x_ = col->extent (common_[X_AXIS], X_AXIS).center ();

That last part applies part of a patch from an unrelated issue of
Han-Wen.  Please don't do stuff like that, if necessary using

git reset --hard

Took me about half an hour of head-scratching to figure out why the
diffs would differ here.

-- 
David Kastrup

[dan_faithful.be, 2020-01-25 13:14:55]

On Jan 25, 2020, at 07:26, David Kastrup <dak@gnu.org> wrote:
> 
> -      Interval hex = head->extent (common_[X_AXIS], X_AXIS);
> +      Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
...
> 
> That last part applies part of a patch from an unrelated issue of
> Han-Wen.  Please don't do stuff like that, if necessary using

It does not apply a patch from Han-Wen.  It necessarily renames that variable
prior to a scripted replacement of "hex" with "std::hex".  I wonder whether the
task would have been easier if I had used a different name for the variable.

> Please don't do stuff like that, if necessary using
> 
> git reset --hard

I don't understand from this description exactly problem you experienced and
where in my development process you would have wanted me to use that command.
— 
Dan

[dak, 2020-01-25 14:09:45]

Dan Eble <dan@faithful.be> writes:

> On Jan 25, 2020, at 07:26, David Kastrup <dak@gnu.org> wrote:
>> 
>> -      Interval hex = head->extent (common_[X_AXIS], X_AXIS);
>> +      Interval head_ext = head->extent (common_[X_AXIS], X_AXIS);
> ...
>> 
>> That last part applies part of a patch from an unrelated issue of
>> Han-Wen.  Please don't do stuff like that, if necessary using
>
> It does not apply a patch from Han-Wen.  It necessarily renames that
> variable prior to a scripted replacement of "hex" with "std::hex".  I
> wonder whether the task would have been easier if I had used a
> different name for the variable.

Well, then I'd have had something looking like an actual conflict in my
rejected parts of the patches.  It would likely have been a bit more
work to resolve and quite a bit less to hunt down.

> I don't understand from this description exactly problem you
> experienced and where in my development process you would have wanted
> me to use that command.

It wasn't clear that this partial overlap with a patch of Han-Wen was
independently arrived at and manually created rather than an artifact.
The problem I experienced is that a partially applying patch apparently
was partly applied previously.  That this was not a problem of what I
was doing took some time to find out.  Of course, resetting would indeed
not have helped since my guess at the discrepancy's origin was wrong.

-- 
David Kastrup