* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Linus Torvalds @ 2005-05-02 16:31 UTC (permalink / raw)
To: Bill Davidsen; +Cc: Andrea Arcangeli, Matt Mackall, linux-kernel, git
In-Reply-To: <42764C0C.8030604@tmr.com>
On Mon, 2 May 2005, Bill Davidsen wrote:
> > -#!/usr/bin/python
> > +#!/usr/bin/env python
> Could you explain why this is necessary or desirable? I looked at what
> env does, and I am missing the point of duplicating bash normal
> behaviour regarding definition of per-process environment entries.
It's not about environment.
It's about the fact that many people have things like python in
/usr/local/bin/python, because they compiled it themselves or similar.
Pretty much the only path you can _really_ depend on for #! stuff is
/bin/sh.
Any system that doesn't have /bin/sh is so fucked up that it's not worth
worrying about. Anything else can be in /bin, /usr/bin or /usr/local/bin
(and sometimes other strange places).
That said, I think the /usr/bin/env trick is stupid too. It may be more
portable for various Linux distributions, but if you want _true_
portability, you use /bin/sh, and you do something like
#!/bin/sh
exec perl perlscript.pl "$@"
instead.
Linus
^ permalink raw reply
* Re: Anyone working on a CVS->git converter?
From: Juliusz Chroboczek @ 2005-05-02 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <4275857A.1050106@zytor.com>
> Anyone working on a CVS->git converter?
Not directly, but you might get your wish Real Soon Now.
I'm currently putting the finishing touches on commit support for
darcs-git. Once that's finished, you should be able to run tailor
(the CVS to Darcs converter) over a Git repository.
So hold on for a few days, and drop me a mail if you don't hear from
me.
Juliusz
^ permalink raw reply
* Git Traffic #1 is available
From: Zack Brown @ 2005-05-02 17:06 UTC (permalink / raw)
To: git
Hi folks,
http://kerneltraffic.org/git/gt20050502_1.html
I just put Git Traffic #1 up. It's *huge*! This issue covers about 2 weeks of
list traffic, starting roughly from the beginning. Maybe it'll be useful.
Be well,
Zack
--
Zack Brown
^ permalink raw reply
* cogito: linux-2.6 merge fails due to cg-rm
From: Matt Porter @ 2005-05-02 17:12 UTC (permalink / raw)
To: git
I guess it was bound to happen after reading rmk's issues. I finally
had a working tree of mine fail to merge from linus' tree while doing
a cg-update. I'm using cogito 0.8. I had to hand merge something
due to DocBook Makefile changes but the real problem was in the
set of files that were removed:
Documentation/DocBook/tulip-user.tmpl
Documentation/DocBook/via-audio.tmpl
arch/um/kernel/sys_call_table.c
drivers/video/intelfb/intelfbdrv.h
scripts/makeman
scripts/split-man
These kept showing up as "needs merged" even though I explicitly
tried to cg-rm them or "update-cache --remove" them. It turns out
that cg-rm is 'rm -f'ing the files before calling update-cache.
By touching each file, and then modifying cg-rm as follows, I
was able to complete the merge. I'm not sure yet if this is the
proper fix to the cogito script. It at least made update-cache
happy for this remove case.
-Matt
--- c3aa1e6b53cc59d5fbe261f3f859584904ae3a63/cg-rm (mode:100755 sha1:029a03128eb7a8dd807335fea2ff52cb2bcda4fa)
+++ uncommitted/cg-rm (mode:100755)
@@ -10,5 +10,5 @@
[ "$1" ] || die "usage: cg-rm FILE..."
-rm -f "$@"
update-cache --remove -- "$@"
+rm -f "$@"
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Daniel Jacobowitz @ 2005-05-02 17:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Bill Davidsen, Andrea Arcangeli, Matt Mackall, linux-kernel, git
In-Reply-To: <Pine.LNX.4.58.0505020921080.3594@ppc970.osdl.org>
On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:
> It's not about environment.
>
> It's about the fact that many people have things like python in
> /usr/local/bin/python, because they compiled it themselves or similar.
>
> Pretty much the only path you can _really_ depend on for #! stuff is
> /bin/sh.
>
> Any system that doesn't have /bin/sh is so fucked up that it's not worth
> worrying about. Anything else can be in /bin, /usr/bin or /usr/local/bin
> (and sometimes other strange places).
>
> That said, I think the /usr/bin/env trick is stupid too. It may be more
> portable for various Linux distributions, but if you want _true_
> portability, you use /bin/sh, and you do something like
>
> #!/bin/sh
> exec perl perlscript.pl "$@"
>
> instead.
Do you know any vaguely Unix-like system where #!/usr/bin/env does not
work? I don't; I've used it on Solaris, HP-UX, OSF/1...
--
Daniel Jacobowitz
CodeSourcery, LLC
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Ryan Anderson @ 2005-05-02 17:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: Bill Davidsen, Andrea Arcangeli, Matt Mackall, linux-kernel, git
In-Reply-To: <Pine.LNX.4.58.0505020921080.3594@ppc970.osdl.org>
On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:
> That said, I think the /usr/bin/env trick is stupid too. It may be more
> portable for various Linux distributions, but if you want _true_
> portability, you use /bin/sh, and you do something like
>
> #!/bin/sh
> exec perl perlscript.pl "$@"
if 0;
You don't really want Perl to get itself into an exec loop.
--
Ryan Anderson
sometimes Pug Majere
^ permalink raw reply
* Re: cogito: linux-2.6 merge fails due to cg-rm
From: Matt Porter @ 2005-05-02 17:20 UTC (permalink / raw)
To: git
In-Reply-To: <20050502101250.A21716@cox.net>
On Mon, May 02, 2005 at 10:12:50AM -0700, Matt Porter wrote:
> These kept showing up as "needs merged" even though I explicitly
> tried to cg-rm them or "update-cache --remove" them. It turns out
> that cg-rm is 'rm -f'ing the files before calling update-cache.
> By touching each file, and then modifying cg-rm as follows, I
> was able to complete the merge. I'm not sure yet if this is the
> proper fix to the cogito script. It at least made update-cache
> happy for this remove case.
Looking a bit further, I see the cg-Xmergefile also removes the
file before update-cache --remove which doesn't seem to work. This
seems to be the actual culprit during the merge, but cg-rm needed
fixed to manually fix without calling git commands directly.
-Matt
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Linus Torvalds @ 2005-05-02 17:31 UTC (permalink / raw)
To: Ryan Anderson
Cc: Bill Davidsen, Andrea Arcangeli, Matt Mackall, linux-kernel, git
In-Reply-To: <20050502172012.GD11726@mythryan2.michonline.com>
On Mon, 2 May 2005, Ryan Anderson wrote:
>
> On Mon, May 02, 2005 at 09:31:06AM -0700, Linus Torvalds wrote:
> > That said, I think the /usr/bin/env trick is stupid too. It may be more
> > portable for various Linux distributions, but if you want _true_
> > portability, you use /bin/sh, and you do something like
> >
> > #!/bin/sh
> > exec perl perlscript.pl "$@"
> if 0;
>
> You don't really want Perl to get itself into an exec loop.
This would _not_ be "perlscript.pl" itself. This is the shell-script, and
it's not called ".pl".
In other words, you'd put this as ~/bin/cg-xxxx, and then "perlscript.pl"
wouldn't be in the path at all, it would be in some separate install
directory.
But hey, if people want to be safe for bad installations, add the extra
line. Shell won't care ;)
Linus
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Linus Torvalds @ 2005-05-02 17:32 UTC (permalink / raw)
To: Daniel Jacobowitz
Cc: Bill Davidsen, Andrea Arcangeli, Matt Mackall, linux-kernel, git
In-Reply-To: <20050502171802.GA28045@nevyn.them.org>
On Mon, 2 May 2005, Daniel Jacobowitz wrote:
>
> Do you know any vaguely Unix-like system where #!/usr/bin/env does not
> work? I don't; I've used it on Solaris, HP-UX, OSF/1...
I've used unixes where "#!" didn't work.
Things like bash still have support for such unixes, I think - you can
tell them to parse the #! line themselves, to make it appear to do the
right thing.
Are these common? Hell no. But they definitely existed.
Linus
^ permalink raw reply
* Re: [PATCH] add git.spec and adapt Makefile for RPM build
From: Horst von Brand @ 2005-05-02 17:41 UTC (permalink / raw)
To: Kay Sievers; +Cc: git, Linus Torvalds
In-Reply-To: <20050502145255.GA26439@vrfy.org>
Kay Sievers <kay.sievers@vrfy.org> said:
> On Mon, May 02, 2005 at 12:23:03PM +0200, Kay Sievers wrote:
> > Add support for building the rpm package directly from the git tree.
>
> This version creates the git.spec from a git.spec.in with the version
> number from the Makefile.
Please don't. The spec file /controls/ the building of the package, it can't
be generated as part of the build process.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Linus' Git (or cogito) tree
From: AsterixTheGaul @ 2005-05-02 17:53 UTC (permalink / raw)
To: linux-kernel, git
Hi,
my cg-pull stopped working and I have
"origin rsync://kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git"
as by branch. Does the location changed recently?
thanks,
Muthu.
^ permalink raw reply
* [patch-git] Fix warning in convert-cache
From: tony.luck @ 2005-05-02 17:57 UTC (permalink / raw)
To: torvalds; +Cc: git
gcc 3.4.3 kicks out this warning:
convert-cache.c: In function `write_subdirectory':
convert-cache.c:102: warning: field precision is not type int (arg 4)
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
--- k/convert-cache.c
+++ l/convert-cache.c
@@ -99,7 +99,7 @@ static int write_subdirectory(void *buff
continue;
}
- newlen += sprintf(new + newlen, "%o %.*s", S_IFDIR, slash - path, path);
+ newlen += sprintf(new + newlen, "%o %.*s", S_IFDIR, (int)(slash - path), path);
new[newlen++] = 0;
sha1 = (unsigned char *)(new + newlen);
newlen += 20;
^ permalink raw reply
* Re: Linus' Git (or cogito) tree
From: Randy.Dunlap @ 2005-05-02 17:57 UTC (permalink / raw)
To: AsterixTheGaul; +Cc: linux-kernel, git
In-Reply-To: <54b5dbf505050210535f2c4937@mail.gmail.com>
On Mon, 2 May 2005 23:23:15 +0530 AsterixTheGaul wrote:
| Hi,
| my cg-pull stopped working and I have
| "origin rsync://kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git"
| as by branch. Does the location changed recently?
http://www.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
---
~Randy
^ permalink raw reply
* Re: Linus' Git (or cogito) tree
From: Tommy Reynolds @ 2005-05-02 18:10 UTC (permalink / raw)
To: AsterixTheGaul; +Cc: linux-kernel, git
In-Reply-To: <54b5dbf505050210535f2c4937@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 283 bytes --]
Uttered AsterixTheGaul <asterixthegaul@gmail.com>, spake thus:
> my cg-pull stopped working and I have
> "origin rsync://kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git"
> as by branch. Does the location changed recently?
This is a case for "Archives Searchman!"
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Edgar Toernig @ 2005-05-02 18:17 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: git
In-Reply-To: <20050502171802.GA28045@nevyn.them.org>
Daniel Jacobowitz wrote:
>
> Do you know any vaguely Unix-like system where #!/usr/bin/env does not
> work? I don't; I've used it on Solaris, HP-UX, OSF/1...
On old System-Vs (that includes *caugh* SCO-Unix) env was in /bin not
/usr/bin.
Ciao, ET.
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Bill Davidsen @ 2005-05-02 16:10 UTC (permalink / raw)
To: Matt Mackall; +Cc: Morten Welinder, Linus Torvalds, Sean, linux-kernel, git
In-Reply-To: <20050429165232.GV21897@waste.org>
Matt Mackall wrote:
> On Fri, Apr 29, 2005 at 11:18:20AM -0400, Morten Welinder wrote:
>
>>>I had three design goals. "disk space" wasn't one of them
>>
>>And, if at some point it should become an issue, it's fixable. Since
>>access to objects is fairly centralized and since they are
>>immutable, it would be quite simple to move an arbitrary selection
>>of the objects into some other storage form which could take
>>similarities between objects into account.
>
>
> This is not a fix, this is a band-aid. A fix is fitting all the data
> in 10 times less space without sacrificing too much performance.
>
>
>>So disk space and its cousin number-of-files are both when-and-if
>>problems. And not scary ones at that.
>
>
> But its sibling bandwidth _is_ a problem. The delta between 2.6.10 and
> 2.6.11 in git terms will be much larger than a _full kernel tarball_.
> Simply checking in patch-2.6.11 on top of 2.6.10 as a single changeset
> takes 41M. Break that into a thousand overlapping deltas (ie the way
> it is actually done) and it will be much larger.
>
At this level of performance I would say it doesn't matter. If a full
checkin take two minutes or three minutes doesn't concern me, because
I'm not going to sit and watch it, I'm going to read LKML or write my
beer blog in another window. I would care about two vs. three hours, but
minutes are too long to wait and too short to care.
Now look at pulling 41MB over a T1 link. All of a sudden I care bigtime!
I want very much to use my bandwidth for other things, I don't want 41MB
added to my backup, etc. Disk space is cheap, but unless you ignore
backups and have an OC3 or so, these numbers are large enough to be
irritating. Not a huge issue, just one of those "piss me off every time
I do it" things.
If there is a functional reason to use git, something Mercurial doesn't
do, then developers will and should use git. But the associated hassles
with large change size, rather than the absolute size, are worth
considering.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
^ permalink raw reply
* Re: [PATCH] add git.spec and adapt Makefile for RPM build
From: Chris Wright @ 2005-05-02 18:39 UTC (permalink / raw)
To: Horst von Brand; +Cc: Kay Sievers, git, Linus Torvalds
In-Reply-To: <200505021741.j42HfUZx013620@laptop11.inf.utfsm.cl>
* Horst von Brand (vonbrand@inf.utfsm.cl) wrote:
> Kay Sievers <kay.sievers@vrfy.org> said:
> > On Mon, May 02, 2005 at 12:23:03PM +0200, Kay Sievers wrote:
> > > Add support for building the rpm package directly from the git tree.
> >
> > This version creates the git.spec from a git.spec.in with the version
> > number from the Makefile.
>
> Please don't. The spec file /controls/ the building of the package, it can't
> be generated as part of the build process.
It certainly can. It simply means a structured release process. IOW,
the git.spec would be generated for a release tarball.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] add git.spec and adapt Makefile for RPM build
From: Horst von Brand @ 2005-05-02 18:58 UTC (permalink / raw)
To: Chris Wright; +Cc: Kay Sievers, git, Linus Torvalds
In-Reply-To: <20050502183902.GD5324@shell0.pdx.osdl.net>
Chris Wright <chrisw@osdl.org> said:
> * Horst von Brand (vonbrand@inf.utfsm.cl) wrote:
> > Kay Sievers <kay.sievers@vrfy.org> said:
> > > On Mon, May 02, 2005 at 12:23:03PM +0200, Kay Sievers wrote:
> > > This version creates the git.spec from a git.spec.in with the version
> > > number from the Makefile.
> > Please don't. The spec file /controls/ the building of the package, it
> > can't be generated as part of the build process.
> It certainly can.
Yep. Maybe "can't" was a bit too strong. "Should never be" is right.
> It simply means a structured release process. IOW,
> the git.spec would be generated for a release tarball.
Come on, you have to fix the spec file for the changelog and version by
hand anyway, autoconfiscating it doesn't help one iota there.
And yes, I've seen quite a few packages autogenerating the spec file. As a
result, you /can't/ build the package from pristine sources, you have to
unpack and configure to get enough for building. For me that just isn't
acceptable, as it completely misses the point of RPM.
(You can go "rpmbuild -ta whatever-2.3.1.tar.bz2" if the tarball is set up
correctly, your idea prevents that).
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Sean @ 2005-05-02 19:02 UTC (permalink / raw)
To: Bill Davidsen
Cc: Matt Mackall, Morten Welinder, Linus Torvalds, linux-kernel, git
In-Reply-To: <427650E7.2000802@tmr.com>
On Mon, May 2, 2005 12:10 pm, Bill Davidsen said:
> Now look at pulling 41MB over a T1 link. All of a sudden I care bigtime!
> I want very much to use my bandwidth for other things, I don't want 41MB
> added to my backup, etc. Disk space is cheap, but unless you ignore
> backups and have an OC3 or so, these numbers are large enough to be
> irritating. Not a huge issue, just one of those "piss me off every time
> I do it" things.
That 41MB or lets say 200MB is spread over several months between
releases. Pulling once a day from the git public repository, makes this
barely noticeable. In the future there may be optimized protocols to
handle this more efficiently.
You bring up a good point about backups though. Eventually it might be
nice to have a utility that exports/imports a git repository in a flat
file using deltas rather than snapshots. Such an export format would
make backups and tarballs cheaper.
Sean
^ permalink raw reply
* Re: [PATCH] add git.spec and adapt Makefile for RPM build
From: Paul Jakma @ 2005-05-02 19:06 UTC (permalink / raw)
To: Horst von Brand; +Cc: Chris Wright, Kay Sievers, git, Linus Torvalds
In-Reply-To: <200505021858.j42Iw4M1029427@laptop11.inf.utfsm.cl>
On Mon, 2 May 2005, Horst von Brand wrote:
> And yes, I've seen quite a few packages autogenerating the spec
> file. As a result, you /can't/ build the package from pristine
> sources, you have to unpack and configure to get enough for
> building. For me that just isn't acceptable, as it completely
> misses the point of RPM.
I think maybe you're missing the point of what is sometimes known as
a 'make dist' target. (eg in autoconf type build systems).
> (You can go "rpmbuild -ta whatever-2.3.1.tar.bz2" if the tarball is set up
> correctly, your idea prevents that).
Then the tarball wasn't of distributable (ie end-user buildable)
source.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
"Now this is a totally brain damaged algorithm. Gag me with a smurfette."
-- P. Buhr, Computer Science 354
^ permalink raw reply
* Re: [PATCH] add git.spec and adapt Makefile for RPM build
From: Chris Wright @ 2005-05-02 19:08 UTC (permalink / raw)
To: Horst von Brand; +Cc: Chris Wright, Kay Sievers, git, Linus Torvalds
In-Reply-To: <200505021858.j42Iw4M1029427@laptop11.inf.utfsm.cl>
* Horst von Brand (vonbrand@inf.utfsm.cl) wrote:
> Chris Wright <chrisw@osdl.org> said:
> > It simply means a structured release process. IOW,
> > the git.spec would be generated for a release tarball.
>
> Come on, you have to fix the spec file for the changelog and version by
> hand anyway, autoconfiscating it doesn't help one iota there.
That's the point, you don't _have_ to do that.
> And yes, I've seen quite a few packages autogenerating the spec file. As a
> result, you /can't/ build the package from pristine sources, you have to
> unpack and configure to get enough for building. For me that just isn't
> acceptable, as it completely misses the point of RPM.
>
> (You can go "rpmbuild -ta whatever-2.3.1.tar.bz2" if the tarball is set up
> correctly, your idea prevents that).
You just place the generated spec file in a release tarball. IOW, your
'release' Makefile target depends on foo.spec, and creates a clean release
tarball with all you need to do an -ta build.
thanks,
-chris
^ permalink raw reply
* Re: [PATCH] add git.spec and adapt Makefile for RPM build
From: Paul Jakma @ 2005-05-02 19:13 UTC (permalink / raw)
To: Horst von Brand; +Cc: git
In-Reply-To: <Pine.LNX.4.62.0505022005200.14200@sheen.jakma.org>
On Mon, 2 May 2005, Paul Jakma wrote:
> I think maybe you're missing the point of what is sometimes known as a 'make
> dist' target. (eg in autoconf type build systems).
Apologies: /Or/ the project which provided such a tarball missed the
point.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
"MacDonald has the gift on compressing the largest amount of words into
the smallest amount of thoughts."
-- Winston Churchill
^ permalink raw reply
* Re: on when to checksum
From: Tom Lord @ 2005-05-02 19:21 UTC (permalink / raw)
To: torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504201601130.6467@ppc970.osdl.org>
The thing is, I don't "trickle" things in. That would be horribly
inefficient for me. So I go over the patches, make a mbox, and do them all
in one go. And then they need to happen _fast_. If it takes 20 minutes, I
go away for coffee or something, and then if something didn't apply
half-way through, I will have lost my "context".
That's why I want things instant. Not because I have huge daily throughput
issues, but I have huge _latency_ issues.
I'm curious about what is the value of the "batch" nature of that
proces?
Presumably most patches apply cleanly and most or orthogonal (order
independent). I'm sure that there are frequently interesting exceptions
but am I generally right about "most" here?
So, if I understand, you review each change before stuffing it in a
mailbox, then you apply all the patches in that mailbox in batch.
In the majority of cases, the buffering of changes in the mailbox
adds nothing.
Why isn't that more automated: when you approve a change, it could be
applied at once, in the background. If conflictless, it can be committed,
tested, whatever. If conflicting, *then* the change can be buffered
up for you to look at. Explicit declarations from programmers or
text-based computations about dependencies among the patches can help
improve the queue management in more complicated cases.
In other words, a more asynchronous process might save you time *and*
pay off by reserving more of your attention for areas where it's
really needed.
-t
^ permalink raw reply
* Re: More problems...
From: Petr Baudis @ 2005-05-02 19:33 UTC (permalink / raw)
To: Anton Altaparmakov
Cc: Russell King, Junio C Hamano, Linus Torvalds, Ryan Anderson, git
In-Reply-To: <Pine.LNX.4.60.0504292254430.25700@hermes-1.csi.cam.ac.uk>
Dear diary, on Fri, Apr 29, 2005 at 11:57:53PM CEST, I got a letter
where Anton Altaparmakov <aia21@cam.ac.uk> told me that...
> There should definitely be an option to either enable or disable this as
> there are legitimate cases for not wanting hard links or indeed using
> file systems which do not support them.
Are there legitimate cases for not wanting hard links when you are able
to create them? (Same filesystem, filesystem supports them...)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: More problems...
From: Dave Kleikamp @ 2005-05-02 19:44 UTC (permalink / raw)
To: Petr Baudis
Cc: Anton Altaparmakov, Russell King, Junio C Hamano, Linus Torvalds,
Ryan Anderson, git
In-Reply-To: <20050502193327.GB20818@pasky.ji.cz>
On Mon, 2005-05-02 at 21:33 +0200, Petr Baudis wrote:
> Dear diary, on Fri, Apr 29, 2005 at 11:57:53PM CEST, I got a letter
> where Anton Altaparmakov <aia21@cam.ac.uk> told me that...
> > There should definitely be an option to either enable or disable this as
> > there are legitimate cases for not wanting hard links or indeed using
> > file systems which do not support them.
>
> Are there legitimate cases for not wanting hard links when you are able
> to create them? (Same filesystem, filesystem supports them...)
Cloning a different user's repo?
--
David Kleikamp
IBM Linux Technology Center
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox