Re: [PATCH] builtin-clone: fix for new unpack_trees() semantics

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Mar 9, 2008, 23:02 UTC
Message-ID: <alpine.LNX.1.00.0803091857540.19665@iabervon.org>
In-Reply-To: <alpine.LSU.1.00.0803092354310.3975@racer.site>

On Sun, 9 Mar 2008, Johannes Schindelin wrote:

Show 37 quoted lines

> Hi,
> 
> On Sun, 9 Mar 2008, Daniel Barkalow wrote:
> 
> > On Sun, 9 Mar 2008, Johannes Schindelin wrote:
> > 
> > > In git.git's "next" branch, unpack_trees() must specify source and target 
> > > index.
> > > 
> > > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > > ---
> > > 
> > > 	To be squashed into 10/11
> > > 
> > >  builtin-clone.c |    2 ++
> > >  1 files changed, 2 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/builtin-clone.c b/builtin-clone.c
> > > index e4047ed..3890e12 100644
> > > --- a/builtin-clone.c
> > > +++ b/builtin-clone.c
> > > @@ -534,6 +534,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
> > >  		opts.verbose_update = !option_quiet;
> > >  		opts.merge = 1;
> > >  		opts.fn = twoway_merge;
> > > +		opts.src_index = &the_index;
> > > +		opts.dst_index = &the_index;
> > 
> > Actually, I think the sensible thing is to just not do a merge here, since 
> > we know there's no index beforehand and the two trees are the same.
> > 
> > I think the odd twoway merge of two copies of HEAD is just an artifact of 
> > clone originally just doing "git checkout HEAD", and that got translated 
> > various times failing to notice the special cases.
> 
> Okay, but would oneway_merge not want to write the index, too (rightfully 
> so)?

I'm thinking:

  memset(&opts, 0, sizeof opts);
  opts.update = 1;
  opts.verbose_update = !option_quiet;
  opts.dst_index = &the_index;

  init_tree_desc(&t[0], tree->buffer, tree->size);
  unpack_trees(1, t, &opts);

That is, write it, but not read it, and only have one tree.

	-Daniel
*This .sig left intentionally blank*