git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Langhoff <martin.langhoff@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Linus Torvalds <torvalds@osdl.org>, GIT <git@vger.kernel.org>,
	Junio C Hamano <junkio@cox.net>
Subject: Re: Storing state in $GIT_DIR
Date: Fri, 26 Aug 2005 19:08:47 +1200	[thread overview]
Message-ID: <46a038f90508260008d1013ea@mail.gmail.com> (raw)
In-Reply-To: <m17je9tcj0.fsf@ebiederm.dsl.xmission.com>

On 8/26/05, Eric W. Biederman <ebiederm@xmission.com> wrote:
> Thinking about it going from arch to git should be just a matter
> of checking sha1 hashes, possibly back to the beginning of the
> arch tree.

Yup, though actually replaying the tree to compute the hashes is
something I just _won't_ do ;)

> Going from git to arch is the trickier mapping, because you
> need to know the full repo--category--branch--version--patch
> mapping.

My plan doesn't include git->arch support... yet...

> Hmm.  Thinking about arch from a git perspective arch tags every
> commit.  So the really sane thing to do (I think) is to create
> a git tag object for every arch commit.

Now I like that interesting idea. It doesn't solve all my problems,
but is a reasonable mapping point. Will probably do it.

> With patch trading (Martin I think I know what you are refering to)
> arch does seem to have a concept that does not map very well to git,
> and this I think is a failing in git.

I won't get into _that_ flamewar ;)

My plan for merges is to detect when two branches up until what point
branches are fully merged, and mark that in git -- because that is
what git considers a merge. The rest will be known to the importer,
but nothing else.

cheers,


martin

  reply	other threads:[~2005-08-26  7:09 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-25  3:32 Storing state in $GIT_DIR Martin Langhoff
2005-08-25 18:16 ` Linus Torvalds
2005-08-26  1:30   ` Martin Langhoff
2005-08-26  3:54     ` Linus Torvalds
2005-08-26  4:15       ` Martin Langhoff
2005-08-26  4:31         ` Junio C Hamano
2005-08-26  5:08           ` Daniel Barkalow
2005-08-26  5:31             ` Linus Torvalds
2005-08-26  5:49               ` Junio C Hamano
2005-08-27  0:23                 ` Linus Torvalds
2005-08-26  5:52             ` Junio C Hamano
2005-08-26  6:43           ` Martin Langhoff
2005-08-26  6:53         ` Eric W. Biederman
2005-08-26  7:08           ` Martin Langhoff [this message]
2005-08-26 14:26             ` Eric W. Biederman
     [not found]   ` <7vwtm9u5jj.fsf@assigned-by-dhcp.cox.net>
2005-08-26  1:57     ` Martin Langhoff
2005-08-26  2:03   ` [PATCH] Accept -m and friends for initial commits and merge commits Junio C Hamano

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=46a038f90508260008d1013ea@mail.gmail.com \
    --to=martin.langhoff@gmail.com \
    --cc=ebiederm@xmission.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=torvalds@osdl.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.
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).