Re: [PATCH] Cogito documentation updates

From: Andreas Ericsson <ae@op5.se>
Date: Nov 23, 2005, 14:58 UTC
Message-ID: <438483A4.6040802@op5.se>
In-Reply-To: <8664qjph7d.fsf@blue.stonehenge.com>

Randal L. Schwartz wrote:

Show 16 quoted lines

>>>>>>"Jonas" == Jonas Fonseca <fonseca@diku.dk> writes:
> 
> 
> Jonas> Ah, yes. I just recently tried local cloning on a FreeBSD box and it
> Jonas> worked fine (apart from it spitting out a few errors, see the log below)
> Jonas> and since the caveat section only mentioned the -u option I thought
> Jonas> everything was fine. However, cloning a specific branch hits the error.
> Jonas> So maybe the caveat section should just be updated to say that the -d
> Jonas> option is required. 
> 
> But instead of targeting GNU tools, why not target POSIX tools where
> possible?
> 
> Delete the -d switch, or explain to me why it is there, and let's work
> out a POSIX workaround.
>

        -d     same as --no-dereference --preserve=link

        --no-dereference
               never follow symbolic links

        --preserve[=ATTR_LIST]
               preserve   the   specified   attributes  (default:
               mode,ownership,timestamps) and security contexts,
               if possible
               additional attributes: links, all

I don't know how to get those options with POSIX only cp.

Show 8 quoted lines

> I'm not asking for everyone to be cautious when contributing code.
> I'll be happy to be "mr portability" and figure out how to make it
> still work on OpenBSD and Darwin (my two platforms of choice).
> 
> However, as I said in another posting, maybe I just need to understand
> the target market first.  (I realize that goal #1 is Linux Kernel
> development.)
>

I'm not Junio, but I think the priorities right now are ordererd like this; good performance, fast development, portability.

Good performance because it's designed to handle one of the largest open projects there is.

Fast development because it's still a young project but has more momentum than most projects, open or closed, ever get. If it slows down now it will stay slow until the kernel team needs new features and there's no way of recycling inertia.

Portability because that's nice but not vital for the project as a whole (it's a linuxish tool, so most users run it on linux so far). I think portability usually ends up a bit behind in the race because it often hinders #1 and #2.

Again, I'm not Junio. I might be dead wrong.

However, most of the plumbing works on just about anything with a CPU, so unless you really need cg-clone you should be able to do it with git-clone, which AFAIU uses 'tar' and 'cpio' instead of cp to transfer files (for portability reasons, I imagine).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231