Ok, I'm at the point where I really think it's getting close to a 1.0, and
make another tar-ball etc. I obviously feel that it's already way superior
to CVS, but I also realize that somebody who is used to CVS may not
actually realize that very easily.
So before I do a 1.0 release, I want to write some stupid git tutorial for
a complete beginner that has only used CVS before, with a real example of
how to use raw git, and along those lines I actually want the thing to
show how to do something useful.
So before I do that, is there something people think is just too hard for
somebody coming from the CVS world to understand? I already realized that
the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard
to put into a sane tutorial.
I was showing off raw git to Steve Chamberlain yesterday, and showing it
to him made some things pretty obvious - one of them being that
"git-init-db" really needed to set up the initial refs etc). So I wrote
this silly "git-commit-script" to make it at least half-way palatable, but
what else do people feel is "too hard"?
I think I'll move the "cvs2git" script thing to git proper before the 1.0
release (again, in order to have the tutorial able to show what to do if
you already have an existing CVS tree), what else?
Linus
From: jeff millar <hidden> Date: 2016-06-15 22:41:58
Linus Torvalds wrote:
So before I do that, is there something people think is just too hard for
somebody coming from the CVS world to understand?
I'm a fairly clueless cvs user, trying to use cg/git as a way to track a
single
user project...using cogito, because that's easier, right?
The usage pattern that causing me problems right now.
cg-init a whole directory tree (trying with /etc and a software project
directory)
note that too many files got included (*.cache, *.backup, *.o, binaries,
etc)
want to stop tracking them, cg-rm also removes the file, don't want that.
What's the best way to stop tracking files?
jeff
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:41:58
On Mon, 30 May 2005, Linus Torvalds wrote:
Ok, I'm at the point where I really think it's getting close to a 1.0, and
make another tar-ball etc.
Any chance you could merge my latest mkdelta patch _please_ ???
I just posted it twice in the last 4 days and it still didn't appear in
your repository.
Again, the current version of mkdelta in your tree has a bug that can
screw things up, and it is fixed in the latest patch of course.
Nicolas
From: David Greaves <hidden> Date: 2016-06-15 22:41:58
Linus Torvalds wrote:
So before I do a 1.0 release, I want to write some stupid git tutorial for
a complete beginner that has only used CVS before, with a real example of
how to use raw git, and along those lines I actually want the thing to
show how to do something useful.
So before I do that, is there something people think is just too hard for
somebody coming from the CVS world to understand? I already realized that
the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard
to put into a sane tutorial.
I was showing off raw git to Steve Chamberlain yesterday, and showing it
to him made some things pretty obvious - one of them being that
"git-init-db" really needed to set up the initial refs etc). So I wrote
this silly "git-commit-script" to make it at least half-way palatable, but
what else do people feel is "too hard"?
I think I'll move the "cvs2git" script thing to git proper before the 1.0
release (again, in order to have the tutorial able to show what to do if
you already have an existing CVS tree), what else?
It seems to me that a tutorial for end users is inappropriate.
You should be writing a tutorial for porcelain implementors :)
Anyway, a while back I split the commands into manipulation and
interrogation and then into ancillary commands and scripts. Do you
actually agree with this grouping?
http://www.kernel.org/pub/software/scm/git/docs/git.html
It may help to position who should be doing what.
Also, if you're writing a git-init-script, it may be that you're simply
scripting common processes and could helpfully maintain consistency by
either pulling some of the really trivial Cogito scripts (cg-init,
cg-add, cg-rm) into the core 'ancillary' area or suggesting
modifications to Cogito as the current 'best of breed' implementation of
the low-level git usage process. Cogito also 'fixes' some useability
issues such as using "git-update-cache --add" == "cg-add"
I know you _can_ use git as an end user - but it seems that it's
designed to be used by plumbers.
Oh, I'd also like to see something along the lines of my cg-Xignore
before git hits 1.0
On the tutorial side - yesterday I started pulling together stuff from
the list about merging to complete the README where it says [ fixme:
talk about resolving merges here ]
I haven't done much other than collect some discussion from the list and
the text from git-read-tree.txt.
I do think this area needs more explanation as the whole 'stage' thing
is pretty alien to CVS.
I also noted a few people asking "so I did this merge - what do I do now?"
The working directory/cache/repository is also confusing sometimes -
especially when the cache and working-dir unexpectedly don't match.
I also see in my notes: "improve the docs around update-cache."
David
From: Dave Jones <hidden> Date: 2016-06-15 22:41:59
On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote:
>
> Ok, I'm at the point where I really think it's getting close to a 1.0, and
> make another tar-ball etc. I obviously feel that it's already way superior
> to CVS, but I also realize that somebody who is used to CVS may not
> actually realize that very easily.
>
> So before I do a 1.0 release, I want to write some stupid git tutorial for
> a complete beginner that has only used CVS before, with a real example of
> how to use raw git, and along those lines I actually want the thing to
> show how to do something useful.
>
> So before I do that, is there something people think is just too hard for
> somebody coming from the CVS world to understand? I already realized that
> the "git-write-tree" + "git-commit-tree" interfaces were just _too_ hard
> to put into a sane tutorial.
>
> I was showing off raw git to Steve Chamberlain yesterday, and showing it
> to him made some things pretty obvious - one of them being that
> "git-init-db" really needed to set up the initial refs etc). So I wrote
> this silly "git-commit-script" to make it at least half-way palatable, but
> what else do people feel is "too hard"?
I finally got around to actually trying to use git to maintain the
cpufreq repository the last few days after reading Jeff Garzik's mini-howto[1]
It's not particularly complicated, but the number one thing that's bugged me is this..
# commit changes
GIT_AUTHOR_NAME="John Doe" \
GIT_AUTHOR_EMAIL="jdoe@foo.com" \
GIT_COMMITTER_NAME="Jeff Garzik" \
GIT_COMMITTER_EMAIL="jgarzik@pobox.com" \
git-commit-tree `git-write-tree` \
-p $(cat .git/HEAD ) \
< changelog.txt \
> .git/HEAD
For merging a lot of csets, thats a lot of typing per cset. So my .bashrc
now sets up GIT_COMMITTER_NAME & GIT_COMMITTER_EMAIL, because I don't
foresee myself changing either of those anytime soon, which takes it down
to
GIT_AUTHOR_NAME="John Doe" \
GIT_AUTHOR_EMAIL="jdoe@foo.com" \
git-commit-tree `git-write-tree` \
-p $(cat .git/HEAD ) \
< changelog.txt \
> .git/HEAD
per-cset. Maybe I have early on-set dementia, but the number of times
I've typoed those two remaining environment variables is bizarre.
I must've hit every known combination possible in my merge of ~30 patches.
I could make the latter 4 lines of the above a shell alias to save some
typing, but those shell vars still bug me. Hmm, maybe I could create a
wrapper that splits a "Dave Jones <davej@redhat.com" style string into two vars.
I realise you've got a nifty bunch of tools to apply a whole mbox of
patches, but that's not ideal if all of my patches aren't in mboxes
(some I create myself and toss in my spool, some I pull from bugzilla etc..)
Typos aside, the other thing that seems non-intuitive is the splitting up
of the patch & changelog comment into seperate files during the patch-apply
stage.
Maybe your new git-commit-script wonder-tool fixes up all these problems
already, I'll take a look after food.
Its pretty nifty stuff, but for merging a lot of patches in non-mbox format,
either I'm doing something wrong, or its, well.. painful.
Dave
[1] http://lkml.org/lkml/2005/5/26/11/index.html
From: Ryan Anderson <hidden> Date: 2016-06-15 22:41:59
On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote:
I think I'll move the "cvs2git" script thing to git proper before the 1.0
release (again, in order to have the tutorial able to show what to do if
you already have an existing CVS tree), what else?
Umm, why do you maintain two seperate "git" related trees?
Why not merge all of git-tools in, in a tools/ subdirectory?
I've been meaning to ask the same question about "gitweb" for that
matter. The distributions that want seperate packages for dependency
reasons can handle that easily inside one tree, anyway, I believe.
I'd guess part of this is a holdover from the fact that you needed an
independent tree for BitKeeper, but does it still make sense?
--
Ryan Anderson
sometimes Pug Majere
From: Chris Wedgwood <hidden> Date: 2016-06-15 22:41:59
On Mon, May 30, 2005 at 01:00:42PM -0700, Linus Torvalds wrote:
So before I do that, is there something people think is just too
hard for somebody coming from the CVS world to understand? I already
realized that the "git-write-tree" + "git-commit-tree" interfaces
were just _too_ hard to put into a sane tutorial.
I'm still at a loss how to do the equivalent of annotate. I know a
couple of front ends can do this but I have no idea what command line
magic would be equivalent.
I realise you've got a nifty bunch of tools to apply a whole mbox of
patches, but that's not ideal if all of my patches aren't in mboxes
(some I create myself and toss in my spool, some I pull from bugzilla etc..)
I mercilessly hacked Linus's scripts from git-tools repo to work with
non-mailbox patches, maybe you can make use of them too. Note that
stripspace.c is not changed in any way whatsoever and mailsplit.c was
changed to handle my personal preference of having patch description
in the form of:
Input: make blah blah change
---
And Linus's script would eat that line.
--
Dmitry
On Monday 30 May 2005 17:55, Dmitry Torokhov wrote:
On Monday 30 May 2005 17:12, Dave Jones wrote:
quoted
I realise you've got a nifty bunch of tools to apply a whole mbox of
patches, but that's not ideal if all of my patches aren't in mboxes
(some I create myself and toss in my spool, some I pull from bugzilla etc..)
I mercilessly hacked Linus's scripts from git-tools repo to work with
non-mailbox patches, maybe you can make use of them too. Note that
stripspace.c is not changed in any way whatsoever and mailsplit.c was
changed to handle my personal preference of having patch description
in the form of:
Input: make blah blah change
---
And Linus's script would eat that line.
Oops, make it mailinfo.c, not mailsplit.c
--
Dmitry
From: Chris Wedgwood <hidden> Date: 2016-06-15 22:41:59
On Mon, May 30, 2005 at 03:32:42PM -0700, Chris Wedgwood wrote:
I'm still at a loss how to do the equivalent of annotate. I know a
couple of front ends can do this but I have no idea what command line
magic would be equivalent.
From: Petr Baudis <hidden> Date: 2016-06-15 22:41:59
Dear diary, on Mon, May 30, 2005 at 10:00:42PM CEST, I got a letter
where Linus Torvalds [off-list ref] told me that...
Ok, I'm at the point where I really think it's getting close to a 1.0, and
make another tar-ball etc. I obviously feel that it's already way superior
to CVS, but I also realize that somebody who is used to CVS may not
actually realize that very easily.
Can we (well, me) count on the output format of the git commands being
stabilized now and not change in a backwards-incompatible way from now
on? I would like to finally remove the git itself from Cogito, but for
that I have to be able to rely on the fact that as long as the user has
git version >=N, it will work (assuming that Cogito is bugless ;-).
So before I do a 1.0 release, I want to write some stupid git tutorial for
a complete beginner that has only used CVS before, with a real example of
how to use raw git, and along those lines I actually want the thing to
show how to do something useful.
Is there actually much point in using raw git directly? You don't
usually invoke the syscalls directly from the user programs either (and
you usually actually use stdio for the casual stuff). I guess the
raw git usage can get quite long and tiresome sometimes.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
You _really_ want to script this.
Also, I'd seriously suggest you avoid using ".git/HEAD" _and_ writing to
.git/HEAD in the same command. Maybe it works, maybe it doesn't.
So script it with something like
#!/bin/sh
export GIT_AUTHOR_NAME="$1"
export GIT_AUTHOR_EMAIL="$2"
tree=$(git-write-tree) || exit 1
commit=$(git-commit-tree $tree -p HEAD) || exit 1
echo $commit > .git/HEAD
and now you can just do
commit-as "John Doe" "jdoe@foo.com" < changelog.txt
or something like that.
The git commands really are designed to be scripted.
Linus
Umm, why do you maintain two seperate "git" related trees?
Well, my "tools" thing really isn't git proper, and may not make much
sense in the git distribution.
That said, I'm actually moving things into git as they turn useful. For
example, I move the "stripspace" program into git (which means it got
renamed into "git-stripspace", since it ended up being useful for the
stand-alone git-commit-scripts too.
But how many non-Linux projects really apply mailboxes of patches? It
doesn't seem to be very "core".
Why not merge all of git-tools in, in a tools/ subdirectory?
I'll think about it. It does look like at least about half of the git
tools end up being pretty core.
I've been meaning to ask the same question about "gitweb" for that
matter.
Well, there the issue definitely boils down to "different maintainers". I
don't want to connect things that don't need to be connected.
I'd guess part of this is a holdover from the fact that you needed an
independent tree for BitKeeper, but does it still make sense?
Well, I see the "tools" thing really as my private tools that may or may
not make sense for anybody else. Even the cvs2git thing is just so
_stupid_, since I bet you can do it quite cleanly in perl without having
that strange "convert cvsps output into a shellscript" stage (admittedly,
it was _really_ convenient for debugging to have that separate stage, so
while it looks a bit hacky, it ended up being very powerful).
Linus
I'm still at a loss how to do the equivalent of annotate. I know a
couple of front ends can do this but I have no idea what command line
magic would be equivalent.
There isn't any. It's actually pretty nasty to do, following history
backwards and keeping track of lines as they are added. I know how, I'm
just really lazy and hoping somebody else will do it, since I really end
up not caring that much myself.
I notice that Thomas Gleixner seems to have one, but that one is based on
a database, and doesn't look usable as a standalone command..
Linus
From: Eric W. Biederman <hidden> Date: 2016-06-15 22:41:59
Linus Torvalds [off-list ref] writes:
Ok, I'm at the point where I really think it's getting close to a 1.0, and
make another tar-ball etc. I obviously feel that it's already way superior
to CVS, but I also realize that somebody who is used to CVS may not
actually realize that very easily.
I way behind the power curve on learning git at this point but
one piece of the puzzle that CVS has that I don't believe git does
are multiple people committing to the same repository, especially
remotely. I don't see that as a down side of git but it is a common
way people CVS so it is worth documenting.
Eric
I way behind the power curve on learning git at this point but
one piece of the puzzle that CVS has that I don't believe git does
are multiple people committing to the same repository, especially
remotely. I don't see that as a down side of git but it is a common
way people CVS so it is worth documenting.
It's actually one thing git doesn't do per se.
You have to do a "git-pull-script" from the common repository side,
there's no "git-push-script". Ugly.
Anyway, I wrote just a _very_ introductory thing in
Documentation/tutorial.txt, I'll try to update and expand on it later. It
basically has a really stupid example of "how to set up a new project".
Linus
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:41:59
On Tue, 31 May 2005, Linus Torvalds wrote:
On Tue, 31 May 2005, Eric W. Biederman wrote:
quoted
I way behind the power curve on learning git at this point but
one piece of the puzzle that CVS has that I don't believe git does
are multiple people committing to the same repository, especially
remotely. I don't see that as a down side of git but it is a common
way people CVS so it is worth documenting.
It's actually one thing git doesn't do per se.
You have to do a "git-pull-script" from the common repository side,
there's no "git-push-script". Ugly.
It shouldn't be hard to do one, except that locking with rsync is going to
be a pain. I had a patch to make it work with the rpush/rpull pair, but I
didn't get its dependancies in at the time. I can dust those patches off
again if you want that functionality included.
The patches are essentially:
- make the transport protocol handle things other than objects
- library procedure for locking atomic update of refs files
- fetching refs in general
- rpull/rpush that updates a specified ref file atomically
At least the first would be very nice to get in before 1.0, since it is an
incompatible change to the protocol.
-Daniel
*This .sig left intentionally blank*
From: Eric W. Biederman <hidden> Date: 2016-06-15 22:41:59
Linus Torvalds [off-list ref] writes:
Anyway, I wrote just a _very_ introductory thing in
Documentation/tutorial.txt, I'll try to update and expand on it later. It
basically has a really stupid example of "how to set up a new project".
So I need to do a git checkout of the latest version of git to
read the tutorial? So I can figure out how to use git?
Catch 22? :)
Eric
From: Kay Sievers <hidden> Date: 2016-06-15 22:41:59
On Thu, Jun 02, 2005 at 01:15:59AM -0600, Eric W. Biederman wrote:
Linus Torvalds [off-list ref] writes:
quoted
Anyway, I wrote just a _very_ introductory thing in
Documentation/tutorial.txt, I'll try to update and expand on it later. It
basically has a really stupid example of "how to set up a new project".
So I need to do a git checkout of the latest version of git to
read the tutorial? So I can figure out how to use git?
@@ -298,7 +298,7 @@ have committed something, we can also le Unlike "git-diff-files", which showed the difference between the index file and the working directory, "git-diff-cache" shows the differences-between a committed _tree_ and the index file. In other words,+between a committed _tree_ and the working directory. In other words, git-diff-cache wants a tree to be diffed against, and before we did the commit, we couldn't do that, because we didn't have anything to diff against.
@@ -423,8 +423,8 @@ With that, you should now be having some can explore on your own.- Copoying archives- -----------------+ Copying archives+ ---------------- Git arhives are normally totally self-sufficient, and it's worth noting that unlike CVS, for example, there is no separate notion of
@@ -298,7 +298,7 @@ have committed something, we can also le Unlike "git-diff-files", which showed the difference between the index file and the working directory, "git-diff-cache" shows the differences-between a committed _tree_ and the index file. In other words,+between a committed _tree_ and the working directory. In other words, git-diff-cache wants a tree to be diffed against, and before we did the commit, we couldn't do that, because we didn't have anything to diff against.
@@ -423,10 +423,10 @@ With that, you should now be having some can explore on your own.- Copoying archives- -----------------+ Copying archives+ -----------------Git arhives are normally totally self-sufficient, and it's worth noting+Git archives are normally totally self-sufficient, and it's worth noting that unlike CVS, for example, there is no separate notion of "repository" and "working tree". A git repository normally _is_ the working tree, with the local git information hidden in the ".git"
From: Adam Kropelin <hidden> Date: 2016-06-15 22:41:59
Linus Torvalds wrote:
Anyway, I wrote just a _very_ introductory thing in
Documentation/tutorial.txt, I'll try to update and expand on it later.
It
basically has a really stupid example of "how to set up a new
project".
I've been working my way thru the tutorial, trying to up my git clue
level a bit. One part where things start to go a bit pear-shaped for me
is in the description of git-diff-files vs. git-diff-cache. The tutorial
takes pains to emphasize the difference between "working directory
contents", "index file", and "committed tree", and I'm on board with
that. What confuses me is the following:
Unlike "git-diff-files", which showed the difference between the index
file and the working directory, "git-diff-cache" shows the differences
between a committed _tree_ and the index file.
...
[example where git-diff-cache shows difference between working
directory and committed tree]
...
"git-diff-cache" also has a specific flag "--cached", which is used to
tell it to show the differences purely with the index file, and ignore
the current working directory state entirely
The example and the description of --cached seem to contradict the first
sentence's description the tool's purpose in life. If it shows you
differences between a committed tree and the index file, why is it
looking in my working directory at all? In order to get the behavior the
first sentence describes you actually have to use --cached.
Am I on right track?
--Adam
From: Adam Kropelin <hidden> Date: 2016-06-15 22:41:59
Linus Torvalds wrote:
On Thu, 2 Jun 2005, Linus Torvalds wrote:
quoted
Yeah, I'll try to clarify.
Adam, do you find the current version a bit more clear on this?
Absolutely. I especially like the new digression explaining that
the --cached flag controls where file _content_ is fetched from and
reinforcing that the index file always governs which files are involved
in the diff.
Thanks!
--Adam
From: Petr Baudis <hidden> Date: 2016-06-15 22:41:59
Dear diary, on Thu, Jun 02, 2005 at 12:00:55AM CEST, I got a letter
where Daniel Barkalow [off-list ref] told me that...
It shouldn't be hard to do one, except that locking with rsync is going to
be a pain. I had a patch to make it work with the rpush/rpull pair, but I
didn't get its dependancies in at the time.
Was that the patch I was replying to recently? It didn't seem to have
any dependencies.
I can dust those patches off again if you want that functionality included.
The patches are essentially:
- make the transport protocol handle things other than objects
- library procedure for locking atomic update of refs files
- fetching refs in general
- rpull/rpush that updates a specified ref file atomically
At least the first would be very nice to get in before 1.0, since it is an
incompatible change to the protocol.
I would like to have this a lot too. Pulling tags now is a PITA, and I
definitively want to go in this way. So it will land at least in git-pb.
:-) (But that's a little troublesome if you say it's incompatible
change.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:41:59
On Fri, 3 Jun 2005, Petr Baudis wrote:
Dear diary, on Thu, Jun 02, 2005 at 12:00:55AM CEST, I got a letter
where Daniel Barkalow [off-list ref] told me that...
quoted
It shouldn't be hard to do one, except that locking with rsync is going to
be a pain. I had a patch to make it work with the rpush/rpull pair, but I
didn't get its dependancies in at the time.
Was that the patch I was replying to recently? It didn't seem to have
any dependencies.
The rpush/rpull changes were at the end of a series that you were replying
to the beginning of.
quoted
I can dust those patches off again if you want that functionality included.
The patches are essentially:
- make the transport protocol handle things other than objects
- library procedure for locking atomic update of refs files
- fetching refs in general
- rpull/rpush that updates a specified ref file atomically
At least the first would be very nice to get in before 1.0, since it is an
incompatible change to the protocol.
I would like to have this a lot too. Pulling tags now is a PITA, and I
definitively want to go in this way. So it will land at least in git-pb.
:-) (But that's a little troublesome if you say it's incompatible
change.)
The ssh-based protocol has to change, because the current version doesn't
have any way of being extended. The first patch in the new set makes the
incompatible change without adding anything new (so as to be as
uncontroversial as possible), and now also adds a version number so that
future additions should be less of a big deal. The rest of the series will
add the transfer of refs to the transfer mechanism and the protocol.
-Daniel
*This .sig left intentionally blank*