Population of "$Id$" in FLTK source code

[sam taylor]

Dear all,

Is something going wrong?

In Fltk 1.3.5 source code I noticed the occurance of a string "$Id$" at the top and bottom of files that I looked at.

I also noticed that same string in files from the latest snapshot i.e. fltk-1.4.x-20200417-75f47a76.tar.gz

However when I looked at old copies of FLTK I noticed that the "$Id$" strings had been 'expanded' for example:

• in fltk-1.3.3-source.tar.gz

// "$Id: fl_ask.H 9748 2012-12-11 17:06:41Z manolo $"

• in fltk-1.3.x-r11189.tar.gz

// "$Id: fl_ask.H 10501 2014-12-20 15:00:27Z manolo $"

Was this an intended change or is something going wrong with the creation of the 'tar.gz' files?

[imm]

On Tue, 21 Apr 2020, 23:48 sam taylor, wrote:

Dear all,

Is something going wrong?

In Fltk 1.3.5 source code I noticed the occurance of a string "$Id$" at the top and bottom of files that I looked at.

I also noticed that same string in files from the latest snapshot i.e. fltk-1.4.x-20200417-75f47a76.tar.gz

However when I looked at old copies of FLTK I noticed that the "$Id$" strings had been 'expanded' for example:

Was this an intended change or is something going wrong with the creation of the 'tar.gz' files

Nah, that's just what happens when you switch from svn to git and haven't got around to fixing the old tags yet...

There's not really an equivalent in git to the old cvs-style tags that svn has, I think.

-- 
Ian
From my Fairphone FP3
  

[Albrecht Schlosser]

On 4/22/20 12:54 AM imm wrote:
> On Tue, 21 Apr 2020, 23:48 sam taylor, wrote:
>
> Dear all,
>
> Is something going wrong?
>
> In Fltk 1.3.5 source code I noticed the occurance of a string "$Id$"
> at the top and bottom of files that I looked at.
>
> I also noticed that same string in files from the latest snapshot
> i.e. fltk-1.4.x-20200417-75f47a76.tar.gz
>
> However when I looked at old copies of FLTK I noticed that the
> "$Id$" strings had been 'expanded' for example:
>
>
> Was this an intended change or is something going wrong with the
> creation of the 'tar.gz' files
>
>
>
> Nah, that's just what happens when you switch from svn to git and
> haven't got around to fixing the old tags yet...

Yep, we didn't even decide what to do with them. Are they maybe of any
use later?

> There's not really an equivalent in git to the old cvs-style tags that
> svn has, I think.

Not directly in git, but there's an option called filters: "smudge
filter" and "clean filter" (IIRC), where the smudge filter can be used
to expand the string when checking out and the clean filter does the
opposite when checking a file in.

There is at least one fundamental issue: these filters can only be
defined in the local repository, i.e. if we wanted to use them globally
all users (or at least all devs) would have to use them *identically* in
their own repos. Although the expansion wouldn't matter much, the "clean
filter" would need to work 100% accurately - otherwise we'd get the
expanded strings into the repository.

I also believe that they might show up in `git diff` but I'm not sure
and I didn't test it. At least they would be visible in diffs with other
tools (as did the old svn id's) besides real diffs.

We could, however, try to use a "smudge filter" when checking out the
sources for the official tar balls and snapshots. But even if this
worked fine we'd have all these different id tags when diff'ing sources
from older and newer snapshots or releases.

Seeing all the downsides I'm not sure it's worth it.

I know this is not really the place to discuss it, but anyway: I could
imagine to remove the $Id$ string at the top of the file and expand it
at the end of the file to just something like "End of <filename>"
because that was one of the reasons in the original concept: show that
the file is complete. OTOH, this might have been an issue in times when
files were transferred with insecure protocols via modems and no longer
today.

What do other devs and users think? Should we remove the $Id$ tags
completely, or anything else?

[duncan]

On Wednesday, April 22, 2020 at 12:14:26 PM UTC+2, Albrecht Schlosser wrote:

 

I know this is not really the place to discuss it, but anyway: I could
imagine to remove the $Id$ string at the top of the file and expand it
at the end of the file to just something like "End of <filename>"
because that was one of the reasons in the original concept: show that
the file is complete. OTOH, this might have been an issue in times when
files were transferred with insecure protocols via modems and no longer
today.

What do other devs and users think? Should we remove the $Id$ tags
completely, or anything else?

Why not just start to replace expanded $Id$ tags with a literal $Id$ just

as and when individual files are committed? Just like copyright year.

That way the Source Documentation rules in the CMP wouldn't change.

Maybe it would be possible to add a commit filter to check?

Are the $Id$ tags actually being used or checked by anything?

If not, change the CMP and slowly start removing them.

D.

[Albrecht Schlosser]

On 4/22/20 1:13 PM duncan wrote:
> On Wednesday, April 22, 2020 at 12:14:26 PM UTC+2, Albrecht Schlosser wrote:
>
> What do other devs and users think? Should we remove the $Id$ tags
> completely, or anything else?
>
> Why not just start to replace expanded $Id$ tags with a literal $Id$ just
> as and when individual files are committed? Just like copyright year.

To clarify: this (the literal '$Id$') was already the case since
conversion from svn to git and was the issue the OP reported.

There was only one file (likely copied from elsewhere after the
transition to git) which I fixed right now.

> Are the $Id$ tags actually being used or checked by anything?

AFAICT the $Id$ tags have never been used by anything except by devs and
users as a visual representation of the file version - which may or may
not be helpful.

The only case I ever found it useful was when someone posted a full
modified source file so one could see what the base of this file was (in
case of merge or patch conflicts).

> If not, change the CMP and slowly start removing them.

Yep, that would certainly be one option. Thanks for your comments.

[Greg Ercolano]

On 2020-04-22 03:14, Albrecht Schlosser wrote:
> What do other devs and users think? Should we remove the $Id$ tags
> completely, or anything else?

+1 for removing any extraneous overhead cruft from code.

I never trusted the ID tags anyway, and they always caused problems
with diffs. The end markers can go too AFAIC.

If we go for removal..

+1 for ripping the band aide off in one big commit to do them all
at once, not a slow removal process over time.

And yes, let's update the CMP to remove the need for adding them.

[Manolo]

On Wednesday, 22 April 2020 12:14:26 UTC+2, Albrecht Schlosser wrote:

What do other devs and users think? Should we remove the $Id$ tags
completely, or anything else?

My view is to remove all of these altogether.

[imm]

I don't really care either way.

FWIW, I do like having an explicit /* End of File */ marker at the bottom of every file, and routinely add them manually to my own files to this day...

But I'm old and remember when that sort of thing used to matter!

[Greg Ercolano]

On 2020-04-23 03:15, imm wrote:
> FWIW, I do like having an explicit /* End of File */ marker at the bottom of every file,

I do this for print outs, such as printing documents for my accountant,
so they know when one document ends and the next starts.

But it seems ancient to put this into code, as printing tools like mpage(1)
can print page headings automatically.

<digression>
I almost always use mpage(1) to print code, if for no other reason
to scale the font so wide lines to fit on the page (-W), get more lines
per page (-L), and get page headings.

For single page-per-page documents, I often use:

mpage -1 -H -W120 -L80 *.cxx | lp

..or if the code ends up being >20 pages, I'll use landscape mode
(-l) and print two pages side by side (-2), e.g.

mpage -2 -H -W120 -L80 *.cxx | lp

Have to get out my magnifier glasses to read those printouts though.
I always check everything first to make sure it looks right:

mpage -2 -H -W120 -L80 *.cxx | ps2pdf - > /tmp/foo.pdf && firefox /tmp/foo.pdf

If there's better printing tools, I'd like to know about 'em.
The only thing I find myself needing that mpage doesn't provide is to
show the total page count along with the page#.