All of lore.kernel.org
 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 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.