[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: resolving ambiguity in action stamps

From: David Kastrup
Subject: Re: resolving ambiguity in action stamps
Date: Sun, 14 Sep 2014 17:59:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

"Stephen J. Turnbull" <address@hidden> writes:

> Eric S. Raymond writes:
>  > 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.
> Fact!?  I would use the bzr revid, and insert the revid, SHA1 pair
> after I commit each new revision in git on Pass 1.  What am I missing?
> (Read your next paragraph and my reply first!)
>  > 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.
> Of course my proposal needs a database that's writable, and must
> update the bzr id to git id mapping every time filter-branch makes a
> new commit.  It's not trivial, but it's not going to be hard.  Unless
> you think there are Emacs developers smart enough to refer to bugs
> that will occur in as-yet uncommitted revisions by revid?

When revisions are numbered consecutively, that can actually happen.
When creating a commit in some other project referencing an issue
number, I am sometimes lazy enough to create the full commit message
before the issue even exists.  Depending on how many people are active
on some project, this may require doubling up.

But with Bzr revisions, referencing as-yet uncommitted revisions is
slightly more believable than with Git.

David Kastrup

reply via email to

[Prev in Thread] Current Thread [Next in Thread]