Can anyone correct the Bazaar reference "revno:111954.1.97"?

Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eric S. Raymond]

Here's the context:

    revno: 111954.1.4
    committer: K. Handa <handa@gnu.org>
    branch nick: work
    timestamp: Fri 2013-03-22 00:18:44 +0900
    message:
      Fix a bug introduced by revno:111954.1.97

It doesn't show up in a bzr log --levels=0 listing, and the fact that
97 > 4 suggests the reference is garbled.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

"Those who make peaceful revolution impossible 
will make violent revolution inevitable."
	-- John F. Kennedy

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: esr@thyrsus.com (Eric S. Raymond)
> Date: Sat,  1 Mar 2014 12:13:37 -0500 (EST)
> 
> Here's the context:
> 
>     revno: 111954.1.4
>     committer: K. Handa <handa@gnu.org>
>     branch nick: work
>     timestamp: Fri 2013-03-22 00:18:44 +0900
>     message:
>       Fix a bug introduced by revno:111954.1.97
> 
> It doesn't show up in a bzr log --levels=0 listing, and the fact that
> 97 > 4 suggests the reference is garbled.

I think the correct reference is 111964.1.6.  It was merged in
r112051.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> I think the correct reference is 111964.1.6.  It was merged in
> r112051.

Thanks.  That almost finishes the list of comment references to be fixed up.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Joshua Judson Rosen]

Eli Zaretskii <eliz@gnu.org> writes:
>
> > From: esr@thyrsus.com (Eric S. Raymond)
> > Date: Sat,  1 Mar 2014 12:13:37 -0500 (EST)
> > 
> > Here's the context:
> > 
> >     revno: 111954.1.4
> >     committer: K. Handa <handa@gnu.org>
> >     branch nick: work
> >     timestamp: Fri 2013-03-22 00:18:44 +0900
> >     message:
> >       Fix a bug introduced by revno:111954.1.97
> > 
> > It doesn't show up in a bzr log --levels=0 listing, and the fact that
> > 97 > 4 suggests the reference is garbled.
>
> I think the correct reference is 111964.1.6.  It was merged in
> r112051.

... and the "revno:111954.1.97" was a reference to trunk revno:112051.

The fact that the commit whose comment is making that reference is itself
from a non-mainline branch suggests that the reference may actually
not be garbled, but rather be from an obsolete context.

The "111954.1.97" revno is actually correct relative to the "111954.1.4"
commit and Handa's "work branch" (where it would have been 111954+4=11958;
if you do "bzr branch trunk -r 111954.1.4 handa-work" and then do
"bzr log -r 111954.1.97 --show-ids handa-work", this starts to become clear).

(for the git people who are probably having a major WTF at this: it's
 perhaps on par with abbreviating git sha1sums down to just the first
 few hexits)

-- 
"'tis an ill wind that blows no minds."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eric S. Raymond]

Joshua Judson Rosen <rozzin@geekspace.com>:
> > I think the correct reference is 111964.1.6.  It was merged in
> > r112051.
> 
> ... and the "revno:111954.1.97" was a reference to trunk revno:112051.
> 
> The fact that the commit whose comment is making that reference is itself
> from a non-mainline branch suggests that the reference may actually
> not be garbled, but rather be from an obsolete context.
> 
> The "111954.1.97" revno is actually correct relative to the "111954.1.4"
> commit and Handa's "work branch" (where it would have been 111954+4=11958;
> if you do "bzr branch trunk -r 111954.1.4 handa-work" and then do
> "bzr log -r 111954.1.97 --show-ids handa-work", this starts to become clear).

Oh, crap.  Now I'm confused about what to replace that revno with.  The
alternatives are:

111964.1.6	2013-03-15T16:03:54Z!handa@gnu.org
112051   	2013-03-15T16:06:12Z!handa@gnu.org

It's only a difference in timestamp.  Do they have the same content?
If not, serious can of worms.  If so, the qustion of which timestamp
to consider authoritative becomes more philosophical.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Joshua Judson Rosen]

"Eric S. Raymond" <esr@thyrsus.com> writes:
>
> Oh, crap.  Now I'm confused about what to replace that revno with.  The
> alternatives are:
>
> 111964.1.6	2013-03-15T16:03:54Z!handa@gnu.org
> 112051   	2013-03-15T16:06:12Z!handa@gnu.org

Eeek--sorry, I really meant that more as an FYI for anyone who was
already confused. "Don't Panic".

> It's only a difference in timestamp.  Do they have the same content?
> If not, serious can of worms.  If so, the qustion of which timestamp
> to consider authoritative becomes more philosophical.

It does look like the merge (112051) is indeed `just a merge'.

Actually going through and comparing the diffs ("bzr diff -c 112051"
vs. "bzr diff -c 11964.1.6"), the diffs off the two revisions are
identical except for slight differences in context, and that's explained
by the fact that 112051 looks like this:

    $ bzr log --line -r 112051 -n0
    112051: K. Handa 2013-03-16 [merge] Optimize ASCII file reading...
      111964.1.7: K. Handa 2013-03-16 [merge] merge trunk
      111964.1.6: K. Handa 2013-03-16 Optimize ASCII file reading...
      111964.1.5: K. Handa 2013-03-11 [merge] merge trunk

i.e.: the only thing that's at all different between the two
_changes_ is a slight difference in context, due to their different
positions in the DAG. Had the "Optimize ASCII file reading..."
change happened _after_ the second "merge trunk" (11964.1.7)
instead of before it, then I do think even the diff contexts
would be the same (the revision that 11964.1.7 was merging into
Handa's "work" branch was trunk 12050).

-- 
"'tis an ill wind that blows no minds."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> Date: Sat, 1 Mar 2014 17:02:07 -0500
> From: "Eric S. Raymond" <esr@thyrsus.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, handa@gnu.org, emacs-devel@gnu.org
> 
> Oh, crap.  Now I'm confused about what to replace that revno with.  The
> alternatives are:
> 
> 111964.1.6	2013-03-15T16:03:54Z!handa@gnu.org
> 112051   	2013-03-15T16:06:12Z!handa@gnu.org
> 
> It's only a difference in timestamp.  Do they have the same content?
> If not, serious can of worms.  If so, the qustion of which timestamp
> to consider authoritative becomes more philosophical.

Between 111964.1.6 and 112051 there was 111964.1.7, so the two commits
you mention cannot have the same content.  And even if there were not
111964.1.7, from bzr POV those two commits are different (they have
different parents).

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Joshua Judson Rosen <rozzin@geekspace.com>
> Cc: esr@thyrsus.com (Eric S. Raymond),  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 01 Mar 2014 16:35:35 -0500
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > From: esr@thyrsus.com (Eric S. Raymond)
> > > Date: Sat,  1 Mar 2014 12:13:37 -0500 (EST)
> > > 
> > > Here's the context:
> > > 
> > >     revno: 111954.1.4
> > >     committer: K. Handa <handa@gnu.org>
> > >     branch nick: work
> > >     timestamp: Fri 2013-03-22 00:18:44 +0900
> > >     message:
> > >       Fix a bug introduced by revno:111954.1.97
> > > 
> > > It doesn't show up in a bzr log --levels=0 listing, and the fact that
> > > 97 > 4 suggests the reference is garbled.
> >
> > I think the correct reference is 111964.1.6.  It was merged in
> > r112051.
> 
> ... and the "revno:111954.1.97" was a reference to trunk revno:112051.

No, it isn't, IMO: they have different parents.

> The fact that the commit whose comment is making that reference is itself
> from a non-mainline branch suggests that the reference may actually
> not be garbled, but rather be from an obsolete context.
> 
> The "111954.1.97" revno is actually correct relative to the "111954.1.4"
> commit and Handa's "work branch" (where it would have been 111954+4=11958;
> if you do "bzr branch trunk -r 111954.1.4 handa-work" and then do
> "bzr log -r 111954.1.97 --show-ids handa-work", this starts to become clear).

Unless you are saying that Handa-san used two different branches that
both forked at trunk r111954, I don't see how .1.97 can come before
.1.4 on the same branch.

In any case, what we need is references to revisions recorded in Emacs
bzr repo, not in foreign private branches, I hope you agree.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Joshua Judson Rosen]

Eli Zaretskii <eliz@gnu.org> writes:
>
> > From: Joshua Judson Rosen <rozzin@geekspace.com>
> > Cc: esr@thyrsus.com (Eric S. Raymond),  handa@gnu.org,  emacs-devel@gnu.org
> > Date: Sat, 01 Mar 2014 16:35:35 -0500
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > >
> > > > From: esr@thyrsus.com (Eric S. Raymond)
> > > > Date: Sat,  1 Mar 2014 12:13:37 -0500 (EST)
> > > > 
> > > > Here's the context:
> > > > 
> > > >     revno: 111954.1.4
> > > >     committer: K. Handa <handa@gnu.org>
> > > >     branch nick: work
> > > >     timestamp: Fri 2013-03-22 00:18:44 +0900
> > > >     message:
> > > >       Fix a bug introduced by revno:111954.1.97
> > > > 
> > > > It doesn't show up in a bzr log --levels=0 listing, and the fact that
> > > > 97 > 4 suggests the reference is garbled.
> > >
> > > I think the correct reference is 111964.1.6.  It was merged in
> > > r112051.
> > 
> > ... and the "revno:111954.1.97" was a reference to trunk revno:112051.
>
> No, it isn't, IMO: they have different parents.

They actually don't have different parents--they have the same revid,
and really _are_ the same revision-object.

On Eric's spectrum between "philosophical" and "serious can of worms",
I'd say the severity of picking the wrong one of these two revisions
to associate with "the bug" in Handa's later commit-comment is
a lot closer to "philosophical" than to "serious can of worms"...,
but you can verify that Handa's "revno:111954.1.97" must have
referred to trunk revno 112051:

> > The fact that the commit whose comment is making that reference is itself
> > from a non-mainline branch suggests that the reference may actually
> > not be garbled, but rather be from an obsolete context.
> > 
> > The "111954.1.97" revno is actually correct relative to the "111954.1.4"
> > commit and Handa's "work branch" (where it would have been 111954+4=11958;
> > if you do "bzr branch trunk -r 111954.1.4 handa-work" and then do
> > "bzr log -r 111954.1.97 --show-ids handa-work", this starts to become clear).
>
> Unless you are saying that Handa-san used two different branches that
> both forked at trunk r111954

Well, yes: it looks like Handa was using both "trunk" and a separate
"work" branch, and merging back and forth between the two.

One of the two branches _was_ trunk itself.

The other branch ("work") forked off of trunk at 111954.

Trunk got 97+ additional revisions, and then trunk was merged into "work";
(trunk's 112051 was thus "work's 111954.1.97"; the merge itself was
"work 111955").

Handa made another change on "work" and committed it as "work 11956"
(I mention this only to avoid having gaps in the narration...).

Trunk got some more revisions and was again merged into "work"
at "work 111957".

Handa wrote "Fix bug introduced by revno:111954.1.97" into a commit
at "work 111958".

The same "do something in `work' and the merge trunk into `work'"
cycle was repeated a couple more times on "work", up to "work 111961".

Then "work" was merged back into trunk at trunk revno 112229
(where "work 111957" became "trunk 111954.1.3", "work 111958"
became "trunk 111954.1.4", etc.).

If you separate that "work" branch back out of trunk so that you can
look at the log "from work's perspective", then all of the numbers match
up with how Handa would have seen them when he wrote the comment that
tripped Eric up; you can go look the commit-objects up, get their
revids, and verify that "work 111954.1.97" is the same object as
"trunk 112051".

> I don't see how .1.97 can come before .1.4 on the same branch.

Of course--they weren't on the same branch.

It's illuminating to `pull the branches apart' and then compare,
like this:

    bzr branch trunk -r 111954.1.4 handa-work

... and then you can compare what the revnos were in Handa's "work"
branch vs. what they were/are in trunk, e.g.:

    bzr log -r 111954.1.97:handa-work trunk
    bzr log -r 112051:trunk handa-work

    bzr log --show-ids -r 111954.1.97 handa-work
    bzr log --show-ids -r 112051 trunk

(or possibly just graph the two perspectives with "bzr qlog" or
 "bzr vis --limit=..."; even if you just look at one perspective,
 it still shows the "merging back and forth" somewhat more clearly
 than "bzr log" does)

This is why I say that, when Handa wrote "111954.1.97" in his "work" branch,
the revision that he was referencing was in fact "trunk 112051".

Same node in the DAG, addressed differently by observers sitting at
different points in the DAG.

> In any case, what we need is references to revisions recorded in Emacs
> bzr repo, not in foreign private branches, I hope you agree.

Yes, of course :)

-- 
"'tis an ill wind that blows no minds."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Joshua Judson Rosen <rozzin@geekspace.com>
> Cc: esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 00:53:00 -0500
> 
> > > > >     revno: 111954.1.4
> > > > >     committer: K. Handa <handa@gnu.org>
> > > > >     branch nick: work
> > > > >     timestamp: Fri 2013-03-22 00:18:44 +0900
> > > > >     message:
> > > > >       Fix a bug introduced by revno:111954.1.97
> > > > > 
> > > > > It doesn't show up in a bzr log --levels=0 listing, and the fact that
> > > > > 97 > 4 suggests the reference is garbled.
> > > >
> > > > I think the correct reference is 111964.1.6.  It was merged in
> > > > r112051.
> > > 
> > > ... and the "revno:111954.1.97" was a reference to trunk revno:112051.
> >
> > No, it isn't, IMO: they have different parents.
> 
> They actually don't have different parents--they have the same revid,
> and really _are_ the same revision-object.

No, they haven't, and no, they aren't:

  ------------------------------------------------------------
  revno: 111964.1.6
  revision-id: handa@gnu.org-20130315160354-jkntpv64yp0n0iql
  parent: handa@gnu.org-20130311090639-hslbvd6ot0k25lsn
  committer: K. Handa <handa@gnu.org>
  branch nick: work
  timestamp: Fri 2013-03-15 16:03:54 +0000
  message:
    Optimize ASCII file reading with EOL format detection and decoding.

  ------------------------------------------------------------
  revno: 111964.1.7 [merge]
  revision-id: handa@gnu.org-20130315160447-x6zr5fjm1ez02upn
  parent: handa@gnu.org-20130315160354-jkntpv64yp0n0iql
  parent: michael.albinus@gmx.de-20130315141906-e85ws6zvzcq6wk75
  committer: K. Handa <handa@gnu.org>
  branch nick: work
  timestamp: Fri 2013-03-15 16:04:47 +0000
  message:
    merge trunk
  ------------------------------------------------------------

  revno: 112051 [merge]
  revision-id: handa@gnu.org-20130315160612-scmr21as4wy0g99w
  parent: michael.albinus@gmx.de-20130315141906-e85ws6zvzcq6wk75
  parent: handa@gnu.org-20130315160447-x6zr5fjm1ez02upn
  committer: K. Handa <handa@gnu.org>
  branch nick: trunk
  timestamp: Fri 2013-03-15 16:06:12 +0000
  message:
    Optimize ASCII file reading with EOL format detection and decoding.
  ------------------------------------------------------------

Bazaar is deeply branch-centric, and distinguishes between a "regular"
commit and its merge-commit.

> On Eric's spectrum between "philosophical" and "serious can of worms",
> I'd say the severity of picking the wrong one of these two revisions
> to associate with "the bug" in Handa's later commit-comment is
> a lot closer to "philosophical" than to "serious can of worms"...,
> but you can verify that Handa's "revno:111954.1.97" must have
> referred to trunk revno 112051:

I really don't see a problem, since, as can be seen from the above,
the time stamps of each of these 3 revisions are different.

> > Unless you are saying that Handa-san used two different branches that
> > both forked at trunk r111954
> 
> Well, yes: it looks like Handa was using both "trunk" and a separate
> "work" branch, and merging back and forth between the two.

No, I meant 2 branches _in_addition_ to the trunk.

> Handa wrote "Fix bug introduced by revno:111954.1.97" into a commit
> at "work 111958".
> 
> The same "do something in `work' and the merge trunk into `work'"
> cycle was repeated a couple more times on "work", up to "work 111961".
> 
> Then "work" was merged back into trunk at trunk revno 112229
> (where "work 111957" became "trunk 111954.1.3", "work 111958"
> became "trunk 111954.1.4", etc.).
> 
> If you separate that "work" branch back out of trunk so that you can
> look at the log "from work's perspective", then all of the numbers match
> up with how Handa would have seen them when he wrote the comment that
> tripped Eric up; you can go look the commit-objects up, get their
> revids, and verify that "work 111954.1.97" is the same object as
> "trunk 112051".

No matter what was done with the "work" branch, the count of its
revisions is strictly increasing, and so .1.97 cannot possible precede
.1.4.

> > I don't see how .1.97 can come before .1.4 on the same branch.
> 
> Of course--they weren't on the same branch.

Then there must be a third branch, in addition to trunk and "work",
and that 3rd branch must have been forked from trunk at the same
revision 111954.  That's what I said.

> This is why I say that, when Handa wrote "111954.1.97" in his "work" branch,
> the revision that he was referencing was in fact "trunk 112051".

Can't happen with just 2 branches, AFAIU.

> Same node in the DAG, addressed differently by observers sitting at
> different points in the DAG.

As I show above, they aren't the same nodes in the DAG.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Joshua Judson Rosen <rozzin@geekspace.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sat, 01 Mar 2014 22:47:52 -0500
> 
> It does look like the merge (112051) is indeed `just a merge'.
> 
> Actually going through and comparing the diffs ("bzr diff -c 112051"
> vs. "bzr diff -c 11964.1.6"), the diffs off the two revisions are
> identical except for slight differences in context

This is bzr, not git, so the diffs aren't the whole story.  The
arrangement of the parents is also part of it, and it's different.

>     $ bzr log --line -r 112051 -n0
>     112051: K. Handa 2013-03-16 [merge] Optimize ASCII file reading...
>       111964.1.7: K. Handa 2013-03-16 [merge] merge trunk
>       111964.1.6: K. Handa 2013-03-16 Optimize ASCII file reading...
>       111964.1.5: K. Handa 2013-03-11 [merge] merge trunk
> 
> i.e.: the only thing that's at all different between the two
> _changes_ is a slight difference in context, due to their different
> positions in the DAG. Had the "Optimize ASCII file reading..."
> change happened _after_ the second "merge trunk" (11964.1.7)
> instead of before it, then I do think even the diff contexts
> would be the same (the revision that 11964.1.7 was merging into
> Handa's "work" branch was trunk 12050).

Even if the diffs were identical, the revisions won't be.  Not in bzr.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joshua Judson Rosen <rozzin@geekspace.com>
>> Cc: esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
>> Date: Sun, 02 Mar 2014 00:53:00 -0500
>> 
>> > > > >     revno: 111954.1.4
>> > > > >     committer: K. Handa <handa@gnu.org>
>> > > > >     branch nick: work
>> > > > >     timestamp: Fri 2013-03-22 00:18:44 +0900
>> > > > >     message:
>> > > > >       Fix a bug introduced by revno:111954.1.97
>> > > > > 
>> > > > > It doesn't show up in a bzr log --levels=0 listing, and the fact that
>> > > > > 97 > 4 suggests the reference is garbled.
>> > > >
>> > > > I think the correct reference is 111964.1.6.  It was merged in
>> > > > r112051.
>> > > 
>> > > ... and the "revno:111954.1.97" was a reference to trunk revno:112051.
>> >
>> > No, it isn't, IMO: they have different parents.
>> 
>> They actually don't have different parents--they have the same revid,
>> and really _are_ the same revision-object.
>
> No, they haven't, and no, they aren't:
>
>   ------------------------------------------------------------
>   revno: 111964.1.6

revno:111954.1.97 refers to revno:112051, not revno:111964.1.6.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> This is bzr, not git, so the diffs aren't the whole story.

There is no difference between git and bzr wrt. to the DAG.  Only the
names they use are different.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Joshua Judson Rosen]

Eli Zaretskii <eliz@gnu.org> writes:
>
> > > > > I think the correct reference is 111964.1.6.  It was merged in
> > > > > r112051.
> > > > 
> > > > ... and the "revno:111954.1.97" was a reference to trunk revno:112051.
> > >
> > > No, it isn't, IMO: they have different parents.
> > 
> > They actually don't have different parents--they have the same revid,
> > and really _are_ the same revision-object.
>
> No, they haven't, and no, they aren't:
[...]
> > Same node in the DAG, addressed differently by observers sitting at
> > different points in the DAG.
>
> As I show above, they aren't the same nodes in the DAG.

I'm afraid there's a misunderstanding here about which "they" we're
talking about....

I didn't say that "trunk 111964.1.6" was the same node as "trunk 112051";
it's self-evident that "trunk 11964.1.6" was merged by "trunk 112051",
and that the two are therefor necessarily different nodes in the DAG.
I'm in `violent *agreement*' with you about that :)

The question that Eric asked, and that I was answering, was what
Handa's "*work* 111954.1.97" was, and the answer is:

    "*work* 111954.1.97" is the same as "*trunk* 112051"

I'm not sure what I'm being unclear about. Have you tried
running through the procudure that I laid out (starting at
"bzr branch trunk -r 111954.1.4 handa-work")? If you just do this:

    bzr branch trunk -r 111954.1.4 handa-work
    bzr log handa-work -r 111958 # notice Handa's comment about "111954.1.97"
    bzr log trunk -r 111954.1.97:handa-work

Is there actually something in there that you disagree with?

What procedure led you to the conclusion that Handa's "work 111954.1.97"
was the same node as "trunk 111964.1.6"?

-- 
"'tis an ill wind that blows no minds."

Policy on referencing/abbreviating git commit-IDs, going forward? (was: Can anyone correct the Bazaar reference "revno:111954.1.97"?)

[Joshua Judson Rosen]

Andreas Schwab <schwab@linux-m68k.org> writes:
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > This is bzr, not git, so the diffs aren't the whole story.
>
> There is no difference between git and bzr wrt. to the DAG.  Only the
> names they use are different.

There is an interesting `bzr vs. git' question here, though--because of
the differences in the way revisions are named: when you run into the
analogous "I can't tell what this reference is to" problem in git, how
will you deal with it? When someone writes a abbreviated git sha1sum
into a changelog / commit message because just the first 7 or
howevermany hexits was enough to unambiguously identify the referenced
commit-object in their development environment at the time when they
were committing their change, and then a later commit/merge makes that
abbreviation ambiguous, how will you trace out the now-ambiguously-
abbreviated commit? e.g.: up through July 29 2012, "7a62fbf"
unambiguously identified a commit from October 24 2007; on July 30 2012,
"7a62fbf" stopped being unambiguous.


-- 
"'tis an ill wind that blows no minds."

Re: Policy on referencing/abbreviating git commit-IDs, going forward?

[Andreas Schwab]

Joshua Judson Rosen <rozzin@geekspace.com> writes:

> abbreviation ambiguous, how will you trace out the now-ambiguously-
> abbreviated commit? e.g.: up through July 29 2012, "7a62fbf"
> unambiguously identified a commit from October 24 2007; on July 30 2012,
> "7a62fbf" stopped being unambiguous.

If you know it was previsouly unambiguous you know that it refers to the
older one.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Joshua Judson Rosen <rozzin@geekspace.com>,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 19:25:48 +0100
> 
> revno:111954.1.97 refers to revno:112051, not revno:111964.1.6.

Maybe so, but how did you determine that?

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Joshua Judson Rosen <rozzin@geekspace.com>,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 19:26:46 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This is bzr, not git, so the diffs aren't the whole story.
> 
> There is no difference between git and bzr wrt. to the DAG.  Only the
> names they use are different.

I thought git didn't have merge commits that recorded only the merge,
isn't that right?  Apologies if I was mistaken about that.  But if I
wasn't mistaken, then that;s the difference I alluded to.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Joshua Judson Rosen <rozzin@geekspace.com>
> Cc: esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 14:08:07 -0500
> 
> What procedure led you to the conclusion that Handa's "work 111954.1.97"
> was the same node as "trunk 111964.1.6"?

I looked for the commit that first introduced the changes which the
reference alluded to, and which were corrected in the referencing
commit, 111954.1.4.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> I thought git didn't have merge commits that recorded only the merge,
> isn't that right?

I don't know what this is supposed to mean.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Joshua Judson Rosen <rozzin@geekspace.com>,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
>> Date: Sun, 02 Mar 2014 19:25:48 +0100
>> 
>> revno:111954.1.97 refers to revno:112051, not revno:111964.1.6.
>
> Maybe so, but how did you determine that?

The fixup comes immediately after it.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Policy on referencing/abbreviating git commit-IDs, going forward?

[Joshua Judson Rosen]

Andreas Schwab <schwab@linux-m68k.org> writes:
>
> Joshua Judson Rosen <rozzin@geekspace.com> writes:
>
> > abbreviation ambiguous, how will you trace out the now-ambiguously-
> > abbreviated commit? e.g.: up through July 29 2012, "7a62fbf"
> > unambiguously identified a commit from October 24 2007; on July 30 2012,
> > "7a62fbf" stopped being unambiguous.
>
> If you know it was previsouly unambiguous you know that it refers to the
> older one.

I don't think one necessarily _does_ know that in any meaningful way,
when the situation crops up analogously to how it just did; I'm just
thinking, it may be worth putting a "do not use abbreviated sha1 refs in
your commit comments" or similar policy statement somewhere prominent in
the wiki and other docs, if it's not already there.

When you find an abbreviated ref in a revision that got merged in
from another branch/repository (which is what just happened), you only
know that it was previously unambiguous _in the author's own local
repository_ where the text using the abbreviation was written, not
that it was previously unambiguous in the mainline repository, and
certainly not that it was previously unambiguous in the mainline
repository's trunk branch (or in any other particular branch).

Not everyone pulls/pushes all branches when they sync with the mainline
repository, so it's entirely possible that two developers working on
separate branches to not have each others ambiguously-abbreviated
revisions in their own repositories (even when one of those branches is
the trunk). I'm not sure what the probability is over however long git
will be in use; the probability surely increases if more developers
more-abbreviated refs, though.

-- 
"'tis an ill wind that blows no minds."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rozzin@geekspace.com,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 22:10:49 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Andreas Schwab <schwab@linux-m68k.org>
> >> Cc: Joshua Judson Rosen <rozzin@geekspace.com>,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> >> Date: Sun, 02 Mar 2014 19:25:48 +0100
> >> 
> >> revno:111954.1.97 refers to revno:112051, not revno:111964.1.6.
> >
> > Maybe so, but how did you determine that?
> 
> The fixup comes immediately after it.

Not sure I'm following you.  What fixup are you referring to?  If you
mean the fixup in 111954.1.4, then this is what I see:

  112229: K. Handa 2013-04-05 [merge] Optimize the code for reading UTF-8 files.
    111954.1.7: K. Handa 2013-04-05 [merge] merge trunk
    111954.1.6: K. Handa 2013-04-05 Optimize the code for reading UTF-8 files.
    111954.1.5: K. Handa 2013-03-21 [merge] merge trunk
    111954.1.4: K. Handa 2013-03-21 Fix a bug introduced by revno:111954.1.97
  ...
  112098: K. Handa 2013-03-20 [merge] coding.c (syms_of_coding): Initialize disable_ascii_optimization 1.
    111954.1.3: K. Handa 2013-03-20 [merge] merge trunk
    111954.1.2: K. Handa 2013-03-20 coding.c (syms_of_coding): Initialize disable_ascii_optimization 1.
    111954.1.1: K. Handa 2013-03-19 [merge] merge trunk
  ...
  112051: K. Handa 2013-03-15 [merge] Optimize ASCII file reading with EOL formatdetection and decoding.
    111964.1.7: K. Handa 2013-03-15 [merge] merge trunk
    111964.1.6: K. Handa 2013-03-15 Optimize ASCII file reading with EOL format detection and decoding.
    111964.1.5: K. Handa 2013-03-11 [merge] merge trunk

My reading of this is that what was fixed in 111954.1.4 was introduced
in 111964.1.6 (I saw that by looking at the diffs of these commits),
and there are 6 days and many commits between those two.  On the
trunk, the code appeared in r112051 and was fixed in r112229.

Am I missing something?

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Joshua Judson Rosen]

Eli Zaretskii <eliz@gnu.org> writes:
>
> > From: Joshua Judson Rosen <rozzin@geekspace.com>
> > Cc: esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> > Date: Sun, 02 Mar 2014 14:08:07 -0500
> > 
> > What procedure led you to the conclusion that Handa's "work 111954.1.97"
> > was the same node as "trunk 111964.1.6"?
>
> I looked for the commit that first introduced the changes which the
> reference alluded to, and which were corrected in the referencing
> commit, 111954.1.4.

Why not just ask bzr to interpret the "111954.1.97" reference,
and tell you what it thinks the reference meant in its original
context?

-- 
"'tis an ill wind that blows no minds."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: rozzin@geekspace.com,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
>> Date: Sun, 02 Mar 2014 22:10:49 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> From: Andreas Schwab <schwab@linux-m68k.org>
>> >> Cc: Joshua Judson Rosen <rozzin@geekspace.com>,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
>> >> Date: Sun, 02 Mar 2014 19:25:48 +0100
>> >> 
>> >> revno:111954.1.97 refers to revno:112051, not revno:111964.1.6.
>> >
>> > Maybe so, but how did you determine that?

It cannot be the on the same branch, since it's not a plain number
(handa@gnu.org-20130320075820-0qzn1jnrqj0y2g4m is on the same branch).

(Bzr revnos are useless without context.)

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Andreas Schwab]

Joshua Judson Rosen <rozzin@geekspace.com> writes:

> Why not just ask bzr to interpret the "111954.1.97" reference,

Bzr revnos are useless without context.  You need to ask on the original
branch, otherwise they are meaningless.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Joshua Judson Rosen]

Andreas Schwab <schwab@linux-m68k.org> writes:
>
> Joshua Judson Rosen <rozzin@geekspace.com> writes:
>
> > Why not just ask bzr to interpret the "111954.1.97" reference,
>
> Bzr revnos are useless without context.  You need to ask on the original
> branch, otherwise they are meaningless.

Yes, that's what I said--and it's exactly what the commands I gave do.

-- 
"'tis an ill wind that blows no minds."

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: rozzin@geekspace.com,  esr@thyrsus.com,  handa@gnu.org,  emacs-devel@gnu.org
> Date: Sun, 02 Mar 2014 23:14:18 +0100
> 
> >> >> revno:111954.1.97 refers to revno:112051, not revno:111964.1.6.
> >> >
> >> > Maybe so, but how did you determine that?
> 
> It cannot be the on the same branch, since it's not a plain number
> (handa@gnu.org-20130320075820-0qzn1jnrqj0y2g4m is on the same branch).

Yes, that's true.  I thought Eric wanted the original commit, even if
it was on another branch.  But if he wants the corresponding trunk
commit, then yes, you are right.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eric S. Raymond]

Eli Zaretskii <eliz@gnu.org>:
> > It cannot be the on the same branch, since it's not a plain number
> > (handa@gnu.org-20130320075820-0qzn1jnrqj0y2g4m is on the same branch).
> 
> Yes, that's true.  I thought Eric wanted the original commit, even if
> it was on another branch.  But if he wants the corresponding trunk
> commit, then yes, you are right.

I expect the trunk commit is what a person reading that comment would
want to refer back to - but, as previously noted, the question gets a bit
philosophical.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Stephen J. Turnbull]

Eric S. Raymond writes:

 > I expect the trunk commit is what a person reading that comment
 > would want to refer back to - but, as previously noted, the
 > question gets a bit philosophical.

Sure, but it's also pragmatic.  The Emacs workflow does have a
distinguished mainline.  While Emacs developers often use branches
privately, they communicate with each other about changes by merging
to trunk, rather than by posting a branch URL.  If this merge causes a
problem, the fix is then committed to trunk.  (In projects with a
formalized workflow, this is often referred to as commit-and-review.)

So, pragmatically, trunk is the obvious default point of reference
unless explicitly specified otherwise -- and there're really nothing
else that would serve.  These references are also stable as long as
appropriate push controls are in effect.

I don't see any good reason for you to avoid that convention.

Re: Can anyone correct the Bazaar reference "revno:111954.1.97"?

[Eric S. Raymond]

Stephen J. Turnbull <stephen@xemacs.org>:
> Eric S. Raymond writes:
> 
>  > I expect the trunk commit is what a person reading that comment
>  > would want to refer back to - but, as previously noted, the
>  > question gets a bit philosophical.
> 
> Sure, but it's also pragmatic.  The Emacs workflow does have a
> distinguished mainline.  While Emacs developers often use branches
> privately, they communicate with each other about changes by merging
> to trunk, rather than by posting a branch URL.  If this merge causes a
> problem, the fix is then committed to trunk.  (In projects with a
> formalized workflow, this is often referred to as commit-and-review.)
> 
> So, pragmatically, trunk is the obvious default point of reference
> unless explicitly specified otherwise -- and there're really nothing
> else that would serve.  These references are also stable as long as
> appropriate push controls are in effect.
> 
> I don't see any good reason for you to avoid that convention.

Not trying to. In my current lift script the patch for that reference
does point to the trunk commit.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>