git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* [PATCH 0/8] builtin-clone
@ 2008-04-17 23:32 Daniel Barkalow
  2008-04-18  0:50 ` Johan Herland
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Barkalow @ 2008-04-17 23:32 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git, Johannes Schindelin

This is my latest version, rebased approximately on current master (or 
recent maint, I guess). It's missing all of Johan's stuff, which is tests 
for stuff I've fixed and (after this series) a series to make the clone 
generate packed refs. I believe Johannes has a bunch of changes, and I 
haven't been working on this lately, and it needs review more than 
anything, so I'm sending it out.

Daniel Barkalow (8):
  Mark the list of refs to fetch as const
  Add a lockfile function to append to a file
  Add a library function to add an alternate to the alternates file
  Add a function to set a non-default work tree
  Have a constant extern refspec for "--tags"
  Allow for having for_each_ref() list extra refs
  Provide API access to init_db()
  Build in clone

 Makefile                      |    2 +-
 builtin-clone.c               |  546 +++++++++++++++++++++++++++++++++++++++++
 builtin-fetch.c               |   10 +-
 builtin-init-db.c             |  180 +++++++-------
 builtin.h                     |    1 +
 cache.h                       |    7 +
 contrib/examples/git-clone.sh |  522 +++++++++++++++++++++++++++++++++++++++
 environment.c                 |    6 +
 git-clone.sh                  |  522 ---------------------------------------
 git.c                         |    1 +
 lockfile.c                    |   17 ++
 refs.c                        |   18 ++
 refs.h                        |    9 +
 remote.c                      |    9 +
 remote.h                      |    2 +
 sha1_file.c                   |   12 +
 transport.c                   |   16 +-
 transport.h                   |    4 +-
 18 files changed, 1256 insertions(+), 628 deletions(-)
 create mode 100644 builtin-clone.c
 create mode 100755 contrib/examples/git-clone.sh
 delete mode 100755 git-clone.sh

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/8] builtin-clone
  2008-04-17 23:32 [PATCH 0/8] builtin-clone Daniel Barkalow
@ 2008-04-18  0:50 ` Johan Herland
  2008-04-18  0:56   ` Daniel Barkalow
  0 siblings, 1 reply; 4+ messages in thread
From: Johan Herland @ 2008-04-18  0:50 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: git, Junio C Hamano, Johannes Schindelin

On Friday 18 April 2008, Daniel Barkalow wrote:
> This is my latest version, rebased approximately on current master (or 
> recent maint, I guess). It's missing all of Johan's stuff, which is tests 
> for stuff I've fixed

Does this mean you no longer need the tests, or that you want me to resend?

> and (after this series) a series to make the clone generate packed refs.

I'll resend the series once your work has settled down and landed in "next".

BTW, I noticed in your repo (at iabervon.org) that you put "if (0)" around
the code generating packed-refs (using the old one instead), and added the
following note to the commit message:

  I made this compile-time configurable because I'm not sure we want to
  pack unconditionally.

We should probably figure out the right thing to do here. AFAICS,
compile-time configurability is only a temporary measure, and we basically
have to choose between:

1. Add a command-line option (and config variable?) for controlling
   whether "git clone" generates packed refs.

2. Make "git clone" unconditionally generate packed refs.

Currently, I'm leaning towards (2), since I don't think there's enough
drawbacks with generating packed-refs to justify adding a command-line
option. AFAICS, the only drawback is that reflogs aren't
created/initialized on clone, but I got the feeling that this was not
particularly important. Quoting Junio from an earlier thread:

  Not writing reflogs is a _different_ behaviour from the previous, but I
  suspect it might even be an improvement.  When you have 1000 remote
  branches, probably most of them are not even active.

If there are good arguments for going with (1), I'd love to hear them.


Have fun, and thanks a lot for your hard work!

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/8] builtin-clone
  2008-04-18  0:50 ` Johan Herland
@ 2008-04-18  0:56   ` Daniel Barkalow
  2008-04-18  1:14     ` Johan Herland
  0 siblings, 1 reply; 4+ messages in thread
From: Daniel Barkalow @ 2008-04-18  0:56 UTC (permalink / raw)
  To: Johan Herland; +Cc: git, Junio C Hamano, Johannes Schindelin

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2388 bytes --]

On Fri, 18 Apr 2008, Johan Herland wrote:

> On Friday 18 April 2008, Daniel Barkalow wrote:
> > This is my latest version, rebased approximately on current master (or 
> > recent maint, I guess). It's missing all of Johan's stuff, which is tests 
> > for stuff I've fixed
> 
> Does this mean you no longer need the tests, or that you want me to resend?

I have them, but my patch-sending process isn't set up for sending other 
people's patches without forging their email, and I wanted to get this 
series out, and they're not critical, so I skipped them for now.

> > and (after this series) a series to make the clone generate packed refs.
> 
> I'll resend the series once your work has settled down and landed in "next".
> 
> BTW, I noticed in your repo (at iabervon.org) that you put "if (0)" around
> the code generating packed-refs (using the old one instead), and added the
> following note to the commit message:

It was really mostly that the version I have in there doesn't pass the 
tests, due to not having the thing to filter packed refs.

>   I made this compile-time configurable because I'm not sure we want to
>   pack unconditionally.
> 
> We should probably figure out the right thing to do here. AFAICS,
> compile-time configurability is only a temporary measure, and we basically
> have to choose between:
> 
> 1. Add a command-line option (and config variable?) for controlling
>    whether "git clone" generates packed refs.
> 
> 2. Make "git clone" unconditionally generate packed refs.
> 
> Currently, I'm leaning towards (2), since I don't think there's enough
> drawbacks with generating packed-refs to justify adding a command-line
> option. AFAICS, the only drawback is that reflogs aren't
> created/initialized on clone, but I got the feeling that this was not
> particularly important. Quoting Junio from an earlier thread:
> 
>   Not writing reflogs is a _different_ behaviour from the previous, but I
>   suspect it might even be an improvement.  When you have 1000 remote
>   branches, probably most of them are not even active.
> 
> If there are good arguments for going with (1), I'd love to hear them.

I think it's fine, actually (now that you've not test corrections that 
work for it); but I'd like to have builtin-clone land without any changes 
in behaviour, and then get this sort of improvement.

	-Daniel
*This .sig left intentionally blank*

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH 0/8] builtin-clone
  2008-04-18  0:56   ` Daniel Barkalow
@ 2008-04-18  1:14     ` Johan Herland
  0 siblings, 0 replies; 4+ messages in thread
From: Johan Herland @ 2008-04-18  1:14 UTC (permalink / raw)
  To: Daniel Barkalow; +Cc: git, Junio C Hamano, Johannes Schindelin

On Friday 18 April 2008, Daniel Barkalow wrote:
> On Fri, 18 Apr 2008, Johan Herland wrote:
> > On Friday 18 April 2008, Daniel Barkalow wrote:
> > > This is my latest version, rebased approximately on current master (or 
> > > recent maint, I guess). It's missing all of Johan's stuff, which is tests 
> > > for stuff I've fixed
> > 
> > Does this mean you no longer need the tests, or that you want me to resend?
> 
> I have them, but my patch-sending process isn't set up for sending other 
> people's patches without forging their email, and I wanted to get this 
> series out, and they're not critical, so I skipped them for now.

No problem. Feel free to do whatever you like with them. :)

> > 1. Add a command-line option (and config variable?) for controlling
> >    whether "git clone" generates packed refs.
> > 
> > 2. Make "git clone" unconditionally generate packed refs.
> > 
> > Currently, I'm leaning towards (2), [...]
> > 
> > If there are good arguments for going with (1), I'd love to hear them.
> 
> I think it's fine, actually (now that you've not test corrections that 
> work for it); but I'd like to have builtin-clone land without any changes 
> in behaviour, and then get this sort of improvement.

Yes, I agree that a pure rewrite (without changes in behaviour) should be
committed first.


Have fun :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2008-04-18  1:16 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-04-17 23:32 [PATCH 0/8] builtin-clone Daniel Barkalow
2008-04-18  0:50 ` Johan Herland
2008-04-18  0:56   ` Daniel Barkalow
2008-04-18  1:14     ` Johan Herland

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).