From: "Eric S. Raymond" <esr@thyrsus.com>
To: "Stephen J. Turnbull" <stephen@xemacs.org>
Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, emacs-devel@gnu.org
Subject: Re: resolving ambiguity in action stamps
Date: Sun, 14 Sep 2014 10:21:17 -0400 [thread overview]
Message-ID: <20140914142117.GA935@thyrsus.com> (raw)
In-Reply-To: <87egve49d9.fsf@uwakimon.sk.tsukuba.ac.jp>
Stephen J. Turnbull <stephen@xemacs.org>:
> Eric S. Raymond writes:
>
> > One is a genuinely funny gotcha. You can't get to git hashes
> > without going through something semantically like my version stamps
> > on the way!
>
> I disagree.
Well, maybe you have some case, but haring off into bug bisection
techniques doesn't make it.
It is still a technical fact that no git translation containing SHA1s
can be built without passing through a VCS-independent representation
of commit refs on the way. This is because the SHA1-containing repo
would have to be built one commit at a time in order for the correct target
hashes to *exist* to be patched into whatever refers to them.
That means the rewrite of the old commit refs has would need at some
point to pass through a mapping of old refs to something that identifies
a commit but cannot be a git hash *because the hash doesn't exist yet!*
That's the gotcha.
This is not limited to git: it would a general problem with hg or any
other target VCS in which parent hashes are mixed into a commit's hash.
I have a design sketch in my head for a tool (a filter on fast-import
streams) to work around this problem, but it can't eliminate the need
for a VCS-independent commit-ref format, only hide the fact that one
was used during the move.
> > The second problem is that it's not future-proof. Someday we might
> > have to change VCSes again; git is the *fifth*, after RCS CVS Arch
> > bzr. It would be unwise to assume that nobody will ever have a
> > better idea.
>
> I don't. But if the new one can't run
>
> $VCS filter-branch --commit-filter ...
>
> as fast as git, I'd have serious doubts about the sanity of the
> proponents. Even on a 200,000 commit repo, that's just not going to
> take a ton of time, and only needs to be done once.
Yeah, that'd be nice, if a functional equivalent of filter-branch could
do the job at all by itself. No chance of that: see above about hash mixing.
> > At that time it would be a Really Good Thing if as few of our commit
> > refs as possible are opaque magic cookies
>
> Actually, I disagree. It would be a really good thing if they are
> precise. Do you really want to put anybody through the trouble of
> translating randomized format cookies, which may point to any of
> several commits, again? Then revising their scripts every time a new
> variant shows up?
It has yet to be demonstrated that this is a problem in a real use case.
And, actually, I already checked this; the Emacs history doesn't have
any version-stamp collisions in actually referenced revisions.
> Existence proof comes before characterization, please.
I don't understand that.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
next prev parent reply other threads:[~2014-09-14 14:21 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-12 4:36 Everyone, please stop making my life more difficult Eric S. Raymond
2014-09-12 6:08 ` Eli Zaretskii
2014-09-12 9:55 ` Eric S. Raymond
2014-09-12 10:33 ` Eli Zaretskii
2014-09-12 10:49 ` Gregor Zattler
2014-09-12 13:05 ` Eli Zaretskii
2014-09-12 13:19 ` David Kastrup
2014-09-12 13:29 ` Eli Zaretskii
2014-09-12 13:55 ` Andreas Schwab
2014-09-12 14:12 ` Eli Zaretskii
2014-09-12 15:17 ` Eli Zaretskii
2014-09-12 15:21 ` Andreas Schwab
2014-09-12 17:15 ` Eli Zaretskii
2014-09-12 17:43 ` Andreas Schwab
2014-09-12 15:53 ` David Kastrup
2014-09-12 17:22 ` Eli Zaretskii
2014-09-12 19:28 ` David Kastrup
2014-09-12 19:59 ` Eli Zaretskii
2014-09-12 13:57 ` David Kastrup
2014-09-12 14:26 ` Eli Zaretskii
2014-09-12 11:38 ` Eric S. Raymond
2014-09-12 13:14 ` Eli Zaretskii
2014-09-12 16:27 ` Eric S. Raymond
2014-09-12 11:46 ` Harald Hanche-Olsen
2014-09-12 13:56 ` Paul Eggert
2014-09-12 15:08 ` Barry Warsaw
2014-09-12 16:16 ` Eric S. Raymond
2014-09-12 6:47 ` Thien-Thi Nguyen
2014-09-12 7:25 ` David Kastrup
2014-09-12 9:34 ` Thien-Thi Nguyen
2014-09-12 8:18 ` Eli Zaretskii
2014-09-12 8:34 ` Eric S. Raymond
2014-09-12 8:40 ` Eric S. Raymond
2014-09-12 11:47 ` Andreas Schwab
2014-09-12 11:57 ` Eric S. Raymond
2014-09-12 12:17 ` David Kastrup
2014-09-12 13:51 ` Andreas Schwab
2014-09-12 15:54 ` Eric S. Raymond
2014-09-12 16:04 ` David Kastrup
2014-09-12 16:18 ` Andreas Schwab
2014-09-12 16:28 ` Eric S. Raymond
2014-09-12 16:43 ` David Kastrup
2014-09-12 20:19 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Joshua Judson Rosen
2014-09-12 20:41 ` Eric S. Raymond
2014-09-12 21:44 ` resolving ambiguity in action stamps Joshua Judson Rosen
2014-09-13 3:45 ` resolving ambiguity in action stamps (was: Everyone, please stop making my life more difficult) Stephen J. Turnbull
2014-09-13 5:35 ` Eric S. Raymond
2014-09-13 6:57 ` Stephen J. Turnbull
2014-09-13 7:26 ` resolving ambiguity in action stamps Harald Hanche-Olsen
2014-09-13 10:50 ` Eric S. Raymond
2014-09-13 12:43 ` Yuri Khan
2014-09-14 7:34 ` Stephen J. Turnbull
2014-09-14 10:55 ` Eric S. Raymond
2014-09-14 11:03 ` David Kastrup
2014-09-14 13:30 ` Stephen J. Turnbull
2014-09-14 14:06 ` David Kastrup
2014-09-14 15:51 ` Stephen J. Turnbull
2014-09-14 14:21 ` Eric S. Raymond [this message]
2014-09-14 15:45 ` Stephen J. Turnbull
2014-09-14 15:59 ` David Kastrup
2014-09-14 17:12 ` Eric S. Raymond
2014-09-15 0:09 ` Stephen J. Turnbull
2014-09-13 8:51 ` Andreas Schwab
2014-09-12 14:12 ` Everyone, please stop making my life more difficult Sam Steingold
2014-09-12 14:36 ` David Kastrup
2014-09-12 14:44 ` Yuri Khan
2014-09-12 15:24 ` Sam Steingold
2014-09-12 15:59 ` David Kastrup
2014-09-12 16:12 ` Eric S. Raymond
2014-09-12 17:06 ` Stefan Monnier
2014-09-12 20:35 ` Thien-Thi Nguyen
2014-09-12 15:21 ` Sam Steingold
2014-09-12 15:34 ` Harald Hanche-Olsen
2014-09-12 15:51 ` David Kastrup
2014-09-12 17:44 ` Stephen J. Turnbull
2014-09-12 17:58 ` David Caldwell
2014-09-12 19:19 ` Stephen J. Turnbull
2014-09-12 18:01 ` Harald Hanche-Olsen
2014-09-12 19:36 ` Joshua Judson Rosen
2014-10-28 21:11 ` Randal L. Schwartz
2014-09-12 15:30 ` Phillip Lord
2014-09-12 15:57 ` David Kastrup
2014-09-12 17:10 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140914142117.GA935@thyrsus.com \
--to=esr@thyrsus.com \
--cc=emacs-devel@gnu.org \
--cc=hanche@math.ntnu.no \
--cc=stephen@xemacs.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.