git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Potapov <dpotapov@gmail.com>
To: Jelmer Vernooij <jelmer@samba.org>
Cc: Jeff King <peff@peff.net>, Avery Pennarun <apenwarr@gmail.com>,
	Ben Gamari <bgamari@gmail.com>, git <git@vger.kernel.org>
Subject: Re: Storing (hidden) per-commit metadata
Date: Mon, 22 Feb 2010 08:17:48 +0300	[thread overview]
Message-ID: <20100222051748.GB10191@dpotapov.dyndns.org> (raw)
In-Reply-To: <1266754646.12035.23.camel@ganieda>

On Sun, Feb 21, 2010 at 01:17:26PM +0100, Jelmer Vernooij wrote:
> 
> For each file we would need to store:
> 
>  * the Bazaar revision id
>  * any Bazaar revision properties. This is typically a list of URLs of
> bugs that were fixed, name of the branch the commit was on, any
> additional parents, or anything arbitrary set by plugins (e.g. the
> rebase plugin sets 'rebase-of' to the id of the original revision)
>  * For each file that was added or moved around in the revision, a path
> to fileid mapping
>  * Optionally, a list of ghost parent ids and "unusual" revisions for
> each file but these should be rare.
> 
> This is at least a couple of lines of data and in some cases a lot more.
> I would rather avoid confronting git users who don't care about Bazaar
> with it.

The problem with storying this meta data in the commit object is that
any newly created commits in Git will not have this information, and you
probably have to add it later when you export these commits to Bazaar,
which means that the history in Git should be re-written, and Git users
will have to rebase their branches from one commit to another that are
identical except this Bazaar-specific information, which you try to hide
from them. So much for don't care about Bazaar!

In other words, no matter what git-log displays, as long as you put this
meta data wherever it changes commit-id, it is visible to Git users, and
trying to hide this fact is utterly stupid.

There are many ways to store Bazaar data in Git without confronting git
users who don't care about Bazaar with it. For instance, you can create
a separate branch that will hold this meta data.

   master      bzr/master

      /---------o
     o          |
     |          |
     |/---------o
     o          |
     |          |

Commits on bzr/master are fast-forward merges that have the same tree-id
as corresponding commits on master, but the commit message contains
Bazaar specific information. So, if someone does not care about Bazaar,
this is a throw away branch for him. Also, there is no problem to add
Bazaar specific information to any git commit later when it is pushed
to Bazaar. The only problem is if you try to rebase commits that were
pushed to Bazaar, but AFAIK Bazaar does not support overwriting history,
so you cannot expect anything good of this attempt anyway. The published
history should not rebased.


Dmitry

  reply	other threads:[~2010-02-22  5:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-19 17:11 Storing (hidden) per-commit metadata Jelmer Vernooij
2010-02-20 17:41 ` Ben Gamari
2010-02-20 18:57   ` Avery Pennarun
2010-02-21  6:34     ` Jeff King
2010-02-21  8:49       ` Johannes Schindelin
2010-02-21  8:52         ` Jeff King
2010-02-21 12:17       ` Jelmer Vernooij
2010-02-22  5:17         ` Dmitry Potapov [this message]
2010-02-22  9:56           ` Jelmer Vernooij
2010-02-22 11:28             ` Dmitry Potapov
2010-02-22 11:59               ` Jelmer Vernooij
2010-02-22 13:08                 ` Dmitry Potapov
2010-02-22 13:44                   ` Jelmer Vernooij
2010-02-22 14:20                     ` Dmitry Potapov
2010-02-22 19:13                       ` Jelmer Vernooij
2010-02-22 14:57       ` Jelmer Vernooij
2010-02-22  5:11 ` Gabriel Filion
2010-02-22  9:49   ` Jelmer Vernooij
2010-02-22 22:13 ` "Alejandro R. Sedeño"

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=20100222051748.GB10191@dpotapov.dyndns.org \
    --to=dpotapov@gmail.com \
    --cc=apenwarr@gmail.com \
    --cc=bgamari@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jelmer@samba.org \
    --cc=peff@peff.net \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).