Re: Storing state in $GIT_DIR

[ebiederm@xmission.com (Eric W. Biederman)]

Martin Langhoff <martin.langhoff@gmail.com> writes:

> 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 ;)

I guess if you have the tla branch names it won't be necessary.
If you are careful how you do the import you can have two parallel
imports of the same data and produce exactly the same git tree.
That is largely why I care about a stable algorithm for the hashes.

>> 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...

One of my interests, and if I get the time to worry about it
is to get a scm that is a sufficient superset of what other
scms do so it can serve as a bidirectional gateway.

git is fairly close to what is needed to implement that.

Hmm.  I wonder if a git metadata branch in general is sufficient to
store information that does not map to git natively?

>> 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 ;)

<pouts> No flamewar </pouts>

> 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.

I looked at least back to the StGit announcement and it helped to
clarify my thinking.  A patch is equivalent to a branch with
just one change. This makes cherry picking a single patch roughly
equivalent to describing that patch as a single commit branch
at the fork point from the common ancestor of the two branches,
and then having the single commit merged.

The fact that the original branch that was cherry picked from
can really only be represented as a an graft.  Like the original
linux kernel history.

The shortcoming I see in git-applypatch is that it doesn't attempt
to find the original base of a patch and instead simply assumes it
is against the current tree.

There is a similar short coming in git-diff-tree where it reports
the commit that you are on when take the diff, but it does not
report the commit the diff is against. 

......

Thinking a little more there is also a connection with reverting
patches.  Cherry picking changes from a branch may also be thought of
as reverting all of the other changes from a branch and then merging
the branch.

The practical impact of all of these things is there a form that
will allow future merges to realize the same change has already
been applied so it can skip it the second time.

Inter-operating with darcs, tla, quilt, and raw diff/patch brings up
these issues.

So my practical questions are:
- What information can a current git merge algorithms and more
  sophisticated merge algorithms use to avoid having conflicts when
  the same changes are merged into the same branch multiple times?

- Is the git meta data sufficient to represent the history
  sophisticated merge algorithms can use.

- Is the git meta data sufficient to represent the result
  of sufficient meta data operations.

- Is the current representation of a reverted change sufficient
  for the merge algorithms, or could they do a better job if
  they new a change was revert of a previous change.

I'm just trying to think through the issues that working with patch
based systems bring up.

Eric