Re: commit-id fails after cg-init

From: Alexey Nezhdanov <snake@penza-gsm.ru>
Date: May 5, 2005, 07:22 UTC
Message-ID: <200505051122.03111.snake@penza-gsm.ru>
In-Reply-To: <4278E6D4.6060807@dwheeler.com>

Wensday, 04 May 2005 19:14 David A. Wheeler wrote:

Show 21 quoted lines

> Joel Becker said:
> > Well, cg-init in this case creates no objects.  I'd say,
> >instead, it should create an empty tree object (representing a project
> >with no files) and commit that.  That would be your initial commit, and
> >would put something valid in heads/master.
>
> That would actually make sense; commits would go all the way
> back to the "empty tree" as the ultimate initial tree.
>
> There's an interesting side-effect of this; I _think_ it's
> fine but it might be worth thinking through. If all
> new projects start with an empty tree, that creates a
> "common root" that all projects can appeal to.
> That means that in theory a merge between any two project root
> trees can eventually find a common ancestor: the empty tree.
> I _think_ that's okay... is it?
>
> That also means that empty directories will end up with the
> "empty tree" as well.  Is there a risk of multiple empty directories
> causing problems later?  As far as I can tell, there aren't
> any problems with that, and does seem logically sound.

I think this problem can be easily solved with:
1) Restricting to auto-select empty commit as the merge base
2) Make an exception from rule (1) for first real commit

By (1) we will restrict accidental bad merges that can happen due to crasy operator - he will need to explicitly select empty commit as merge base.

By (2) we will allow to pull and merge projects that is just started envolving.

-- 
Respectfully
Alexey Nezhdanov