* 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: 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: [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: 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: 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: 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: 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
* [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
* 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
* 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
* 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: 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: 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: 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: 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
* 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
* 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
* 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
* 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: Mercurial 0.4b vs git patchbomb benchmark
From: Bill Davidsen @ 2005-05-02 16:15 UTC (permalink / raw)
To: Sean; +Cc: Tom Lord, torvalds, mpm, linux-kernel, git
In-Reply-To: <2944.10.10.10.24.1114802002.squirrel@linux1>
Sean wrote:
> On Fri, April 29, 2005 2:54 pm, Tom Lord said:
>
>
>>The process should not rely on the security of every developer's
>>machine. The process should not rely on simply trusting quality
>>contributors by reputation (e.g., most cons begin by establishing
>>trust and continue by relying inappropriately on
>>trust-without-verification). This relates to why Linus'
>>self-advertised process should be raising yellow and red cards all
>>over the place: either he is wasting a huge amount of his own time and
>>should be largely replaced by an automated patch queue manager, or he
>>is being trusted to do more than is humanly possible.
>>
>
>
> Ahh, you don't believe in the development model that has produced Linux!
> Personally I do believe in it, so much so that I question the value of
> signatures at the changeset level. To me it doesn't matter where the code
> came from just so long as it works.
Lawyers must love you... That approach doesn't work in court.
Related: look at the new software patent law, it ignores the existing
law, judge and jury, and lets MS avoid paying the judgement for a suit
it already lost.
See Computerworld etc for details.
--
-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: Mercurial 0.4b vs git patchbomb benchmark
From: Valdis.Kletnieks @ 2005-05-02 16:14 UTC (permalink / raw)
To: Bill Davidsen
Cc: Andrea Arcangeli, Matt Mackall, Linus Torvalds, linux-kernel, git
In-Reply-To: <42764C0C.8030604@tmr.com>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On Mon, 02 May 2005 11:49:32 EDT, Bill Davidsen said:
> Andrea Arcangeli wrote:
> > On Fri, Apr 29, 2005 at 01:39:59PM -0700, Matt Mackall wrote:
> > -#!/usr/bin/python
> > +#!/usr/bin/env python
> > #
> > # mercurial - a minimal scalable distributed SCM
> > # v0.4b "oedipa maas"
>
> 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.
Most likely, his python lives elsewhere than /usr/bin, and the 'env' call
results in causing a walk across $PATH to find it....
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Andrea Arcangeli @ 2005-05-02 16:17 UTC (permalink / raw)
To: Bill Davidsen; +Cc: linux-kernel, git
In-Reply-To: <42764C0C.8030604@tmr.com>
On Mon, May 02, 2005 at 11:49:32AM -0400, Bill Davidsen wrote:
> Could you explain why this is necessary or desirable? I looked at what
This is necessary here because of this:
andrea@opteron:~> which python
/home/andrea/bin/x86_64/python/bin/python
Of course I've /home/andrea/bin/x86_64/python/bin in the path before
/usr/bin.
The generally accepted way to start it is through env, other scripts in
mercurial were already getting that right too so it was probably not
intentional to hardcode it in the hg binary.
^ permalink raw reply
* Re: How to get bash to shut up about SIGPIPE?
From: Paul Jackson @ 2005-05-02 16:10 UTC (permalink / raw)
To: dwheeler; +Cc: herbert, ryan, torvalds, rene.scharfe, git, pasky
In-Reply-To: <4274FB10.6090600@dwheeler.com>
David wrote:
> One approach is to install a trap for SIGPIPE in
> non-terminating command in a pipeline where the
> later items might not process all the data, e.g.:
> (trap {} SIGPIPE; find .) | head -1
Both the versions of bash that I looked at (2.05 and 3.0) _still_
complain even if SIGPIPE is trapped - they just complain with
a more terse message, unless DONT_REPORT_SIGPIPE is not defined.
Linus's version apparently isn't even more terse with this trap.
What bash do you have that this trap silences?
> ... rant ...
agreed
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: Mercurial 0.4b vs git patchbomb benchmark
From: Bill Davidsen @ 2005-05-02 15:49 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Matt Mackall, Linus Torvalds, linux-kernel, git
In-Reply-To: <20050430025211.GP17379@opteron.random>
Andrea Arcangeli wrote:
> On Fri, Apr 29, 2005 at 01:39:59PM -0700, Matt Mackall wrote:
>
>>Mercurial is ammenable to rsync provided you devote a read-only
>>repository to it on the client side. In other words, you rsync from
>>kernel.org/mercurial/linus to local/linus and then you merge from
>>local/linus to your own branch. Mercurial's hashing hierarchy is
>>similar to git's (and Monotone's), so you can sign a single hash of
>>the tree as well.
>
>
> Ok fine. It's also interesting how you already enabled partial transfers
> through http.
>
> Please apply this patch so it doesn't fail on my setup ;)
>
> --- mercurial-0.4b/hg.~1~ 2005-04-29 02:52:52.000000000 +0200
> +++ mercurial-0.4b/hg 2005-04-30 00:53:02.000000000 +0200
> @@ -1,4 +1,4 @@
> -#!/usr/bin/python
> +#!/usr/bin/env python
> #
> # mercurial - a minimal scalable distributed SCM
> # v0.4b "oedipa maas"
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.
--
-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: question on merges
From: Linus Torvalds @ 2005-05-02 15:56 UTC (permalink / raw)
To: Lennert Buytenhek; +Cc: git
In-Reply-To: <20050502151200.GA4592@xi.wantstofly.org>
On Mon, 2 May 2005, Lennert Buytenhek wrote:
>
> If a git user has X as his most recent local commit, and merges in a
> commit Y from someone else to create commit Z, shouldn't commit Z have
> both commit X and Y as parents? Or is is the other way round and is it
> perfectly well possible that a 'merge commit' only has one parent?
There are two classes of git merges:
- the "totally trivial one", where one side is fully contained within the
other (ie one side has not done any development at all)
In this case, the "merge" ends up being a no-op, and just ends up being
a trivial "update" to the bigger set of objects. There are no two
parents, because the merge never even creates a new commit - it just
takes the top commit from the other side.
- a real merge, where both repositories have had concurrent development,
and then you see a new merge commit that has two parents (and they'll
be the two HEAD commits of the repositories).
So I assume you're just seeing the trivial case, but if what you're seeing
doesn't seem to match that pattern, then holler.
NOTE! There's a real reason why the trivial merge _has_ to be just a plain
"fast-forward the history to the new state", namely the fact that if you
create a new merge-node for that, then you can never ever "stabilize":
people merging back and forth will always get new nodes, and you end up
with this run-away situation where you can never get the same tree on both
sides.
Linus
^ 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