git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Lord <lord@emf.net>
To: torvalds@osdl.org
Cc: hpa@zytor.com, git@vger.kernel.org
Subject: Re: A shortcoming of the git repo format
Date: Wed, 27 Apr 2005 19:14:23 -0700 (PDT)	[thread overview]
Message-ID: <200504280214.TAA19991@emf.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0504271722260.18901@ppc970.osdl.org> (message from Linus Torvalds on Wed, 27 Apr 2005 17:57:07 -0700 (PDT))


   > I think a lot of people understand it intellectually, but I really do 
   > think that we're lackign the kind of "institutionalized" knowledge
   > where people understand things at a much more visceral level.

I know that Arch and its progeny, as they stand, don't seduce you
but you should be made aware that the Arch community is one where
good SCM sense that you would agree with (although you might not
recognize it at once) is well on the path to being institutionalized.
It's gratifying/amazing/inspiring to see a bunch of folk catch up 
on the topic.

One thing there's still a shortage of in my world is folks steeped
in both perspectives: "unix" /and/ SCM.  Thus, I get folks who have
pretty decent SCM ideas in the abstract -- plus utterly terrible 
ideas about how to make them real.

There is a higher-level bug I think you'll eventually viscerally 
feel yourself, related to:

   > I think a lot of people understand it intellectually, but I really do 
   > think that we're lackign the kind of "institutionalized" knowledge
   > where people understand things at a much more visceral level.

Once you get to the BK or Arch level of SCM, beyond that there are
many possible paths.  Many of those are false paths -- imaginary
(unrealizable) ideals about how things like merging can work and
be good.   Some people seem to get stuck on those paths.

   > With git, this isn't the case. The _only_ reason I started git in the 
   > first place is that I knew better than pretty much anybody else what my
   > needs were, and I was forced to act on them because nothing out there 
   > really solved the problem for me.

That's debatable but neither here nor there.  Supposing that Arch
were /perfect/ for your needs today (which I don't claim) -- `git'
would still have been the better route to take (though my reasons
probably aren't the same as yours).

   > I'm not actually all that interested in SCM's.

In a certain way: same here, oddly enough.  Go figure.

   > Quite the reverse: such a person "knows" a lot of things, but I'm pretty
   > damn sure that such a person has _never_ actually worked on a system that
   > works the way the kernel development does

I've been avoiding the topic of how kernel development works ever since
i realized, that with each additional detail you reveal, i have little
but yellow and red cards to raise.   Doesn't seem productive to have that
fight when the option of simply improving the situation is open.

   > And I really _am_ sorry. I don't actually _like_ being nasty about these 
   > things.

It's healthy enough that you are, for your sanity and others.  Just 
be tolerant of others pointing that out.

   > The good news? I actually think my needs are very basic.

So it would seem.  This is partly because the process you advertise
yourself as doing is, sorry, garbage.  It's understandable why it
happens to work for now, but it's garbage nonetheless.  Not your fault --
you haven't been afforded the degrees of freedom to do better, afaict.

   > But for now, the _only_ point of git is as a kernel maintenance tool. 

Math is math.  You don't get to say what it means.

-t



  parent reply	other threads:[~2005-04-28  2:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-27  5:43 A shortcoming of the git repo format H. Peter Anvin
2005-04-27 15:00 ` C. Scott Ananian
2005-04-27 15:22 ` Linus Torvalds
2005-04-27 18:03   ` H. Peter Anvin
2005-04-27 18:32     ` Dave Jones
2005-04-27 18:47       ` H. Peter Anvin
2005-04-27 22:51         ` Jon Seymour
2005-04-27 19:15       ` Linus Torvalds
2005-04-27 19:39       ` Petr Baudis
2005-04-27 19:11     ` Linus Torvalds
2005-04-27 19:47       ` The " Brian O'Mahoney
2005-04-27 20:40       ` A shortcoming of the " H. Peter Anvin
2005-04-27 20:49         ` Tom Lord
2005-04-27 20:59           ` H. Peter Anvin
2005-04-28  0:57           ` Linus Torvalds
2005-04-28  1:34             ` Paul Jackson
2005-04-28  2:14             ` Tom Lord [this message]
2005-04-28  3:37             ` Ryan Anderson
2005-04-28  8:31             ` Morgan Schweers
2005-04-28 15:08             ` Barry Silverman
2005-04-27 20:56         ` Linus Torvalds
2005-04-28  0:45           ` David A. Wheeler
2005-04-28  0:46             ` David Lang
2005-04-27 23:50         ` Daniel Barkalow
2005-04-27 23:56           ` H. Peter Anvin
2005-04-28  1:51             ` Daniel Barkalow
2005-04-28  1:56               ` H. Peter Anvin
2005-04-28 13:39     ` David Woodhouse
2005-04-27 20:58 ` Gerhard Schrenk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200504280214.TAA19991@emf.net \
    --to=lord@emf.net \
    --cc=git@vger.kernel.org \
    --cc=hpa@zytor.com \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).