From: Jeff Garzik <hidden> Date: 2005-06-22 22:32:50
Things in git-land are moving at lightning speed, and usability has
improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
1) installing git
git requires bootstrapping, since you must have git installed in order
to check out git.git (git repo), and linux-2.6.git (kernel repo). I
have put together a bootstrap tarball of today's git repository.
Download tarball from:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
tarball build-deps: zlib, libcurl, libcrypto (openssl)
install tarball: unpack && make && sudo make prefix=/usr/local install
jgarzik helper scripts, not in official git distribution:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-new-branchhttp://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script
After reading the rest of this document, come back and update your copy
of git to the latest:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
2) download a linux kernel tree for the very first time
$ mkdir -p linux-2.6/.git
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
$ cd linux-2.6
$ git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
4) check out files from the git repository into the working directory
$ git checkout -f
5) check in your own modifications (e.g. do some hacking, or apply a patch)
# go to repo
$ cd linux-2.6
# make some modifications
$ patch -sp1 < /tmp/my.patch
$ diffstat -p1 < /tmp/my.patch
# NOTE: add '--add' and/or '--remove' if files were added or removed
$ git-update-cache <list of all files changed>
# check in changes
$ git commit
6) List all changes in working dir, in diff format.
$ git-diff-cache -p HEAD
7) List all changesets (i.e. show each cset's description text) in local
branch of local tree, that are not present in remote tree.
$ cd my-kernel-tree-2.6
$ git-changes-script -L ../linux-2.6 | less
8) List all changesets:
$ git-whatchanged
9) apply all patches in a Berkeley mbox-format file
First, download and add to your PATH Linus's git tools:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
$ cd my-kernel-tree-2.6
$ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
10) don't forget to download tags from time to time.
git-pull-script only downloads sha1-indexed object data, and the
requested remote head. This misses updates to the .git/refs/tags/ and
.git/refs/heads directories. It is advisable to update your kernel .git
directories periodically with a full rsync command, to make sure you got
everything:
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
11) list all branches, such as those found in my netdev-2.6 or
libata-dev trees.
Download
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
or
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
$ cd netdev-2.6
$ ls .git/refs/heads/
{ these are the current netdev-2.6 branches }
12) make desired branch current in working directory
$ git checkout -f $branch
13) create a new branch, and make it current
$ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
$ git checkout -f my-new-branch-name
14) examine which branch is current
$ ls -l .git/HEAD
15) undo all local modifications (same as checkout):
$ git checkout -f
16) obtain a diff between current branch, and master branch
In most trees WITH BRANCHES, .git/refs/heads/master contains the current
'vanilla' upstream tree, for easy diffing and merging. (in trees
without branches, 'master' simply contains your latest changes)
$ git-diff-tree -p master HEAD
From: Dave Jones <hidden> Date: 2005-06-22 22:56:11
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
>
>
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
<blatant self-promotion>
daily snapshots (refreshed once an hour) are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
</blatant self-promotion>
> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>
> install tarball: unpack && make && sudo make prefix=/usr/local install
the sudo thing isn't necessary. make install by itself installs it
in ~/bin/ just fine.
> After reading the rest of this document, come back and update your copy
> of git to the latest:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
See above, which allows you to skip this step ;)
Dave
From: Jeff Garzik <hidden> Date: 2005-06-22 22:56:11
Dave Jones wrote:
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
>
>
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
<blatant self-promotion>
daily snapshots (refreshed once an hour) are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
</blatant self-promotion>
> tarball build-deps: zlib, libcurl, libcrypto (openssl)
>
> install tarball: unpack && make && sudo make prefix=/usr/local install
the sudo thing isn't necessary. make install by itself installs it
in ~/bin/ just fine.
Clearly this does not work if installing in /usr/local, as I and others
do (and as the example shows).
> After reading the rest of this document, come back and update your copy
> of git to the latest:
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
See above, which allows you to skip this step ;)
huh? Nothing allows you to skip that step. Regardless of when you suck
the tarball, even from your snapshots, the users should not skip this step.
Jeff
From: Dave Jones <hidden> Date: 2005-06-22 23:02:06
On Wed, Jun 22, 2005 at 06:47:03PM -0400, Jeff Garzik wrote:
> > > install tarball: unpack && make && sudo make prefix=/usr/local install
> >
> >the sudo thing isn't necessary. make install by itself installs it
> >in ~/bin/ just fine.
>
> Clearly this does not work if installing in /usr/local, as I and others
> do (and as the example shows).
Sure, it just seemed to imply that it doesn't work with a non-root install,
which isn't true.
> > > After reading the rest of this document, come back and update your copy
> > > of git to the latest:
> > > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git.git
> >
> >See above, which allows you to skip this step ;)
>
> huh? Nothing allows you to skip that step. Regardless of when you suck
> the tarball, even from your snapshots, the users should not skip this step.
At worse, users will have tools 59 minutes old. If a situation arises
where git from an hour ago isn't new enough to pull from the repository,
we have bigger problems.
You seem to be proposing that everyone needs the shiniest newest things,
which clearly isn't true, and suggesting so just complicates things
further imo.
Dave
From: Jeff Garzik <hidden> Date: 2005-06-23 00:18:06
Dave Jones wrote:
At worse, users will have tools 59 minutes old. If a situation arises
where git from an hour ago isn't new enough to pull from the repository,
we have bigger problems.
You seem to be proposing that everyone needs the shiniest newest things,
which clearly isn't true, and suggesting so just complicates things
further imo.
For the purposes of the these instructions, it is highly recommended.
However, I was unaware that your snapshots were updated hourly. Yeah,
that's quite fine.
Jeff
From: Jeff Garzik <hidden> Date: 2005-06-25 03:33:53
Dave Jones wrote:
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
>
> Things in git-land are moving at lightning speed, and usability has
> improved a lot since my post a month ago: http://lkml.org/lkml/2005/5/26/11
>
>
>
> 1) installing git
>
> git requires bootstrapping, since you must have git installed in order
> to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> have put together a bootstrap tarball of today's git repository.
>
> Download tarball from:
> http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
<blatant self-promotion>
daily snapshots (refreshed once an hour) are available at:
http://www.codemonkey.org.uk/projects/git-snapshots/git/
</blatant self-promotion>
I was about to link to this, but a problem arose: your snapshots don't
include the .git/objects directory.
Also, a git-latest.tar.gz symlink would be nice.
Jeff
From: Dave Jones <hidden> Date: 2005-06-25 17:29:18
On Fri, Jun 24, 2005 at 11:33:38PM -0400, Jeff Garzik wrote:
> Dave Jones wrote:
> >On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
> > >
> > > Things in git-land are moving at lightning speed, and usability has
> > > improved a lot since my post a month ago:
> > http://lkml.org/lkml/2005/5/26/11
> > >
> > >
> > >
> > > 1) installing git
> > >
> > > git requires bootstrapping, since you must have git installed in order
> > > to check out git.git (git repo), and linux-2.6.git (kernel repo). I
> > > have put together a bootstrap tarball of today's git repository.
> > >
> > > Download tarball from:
> > >
> > http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-20050622.tar.bz2
> >
> ><blatant self-promotion>
> >daily snapshots (refreshed once an hour) are available at:
> >http://www.codemonkey.org.uk/projects/git-snapshots/git/
> ></blatant self-promotion>
>
> I was about to link to this, but a problem arose: your snapshots don't
> include the .git/objects directory.
This is intentional. Why is this a problem ?
In the same way, the bitkeeper snapshots I used to do never included
Bitkeeper/, and CVS snapshots don't include the CVS/ dirs.
> Also, a git-latest.tar.gz symlink would be nice.
That's doable.
Dave
On Wed, Jun 22, 2005 at 06:24:54PM -0400, Jeff Garzik wrote:
10) don't forget to download tags from time to time.
git-pull-script only downloads sha1-indexed object data, and the
requested remote head. This misses updates to the .git/refs/tags/ and
.git/refs/heads directories. It is advisable to update your kernel .git
directories periodically with a full rsync command, to make sure you got
everything:
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
Ok, this is annoying. Is there some reason why git doesn't pull the
tags in properly when doing a merge? Chris and I just hit this when I
pulled his 2.6.12.1 tree and and was wondering where the tag went.
thanks,
greg k-h
Ok, this is annoying. Is there some reason why git doesn't pull the
tags in properly when doing a merge? Chris and I just hit this when I
pulled his 2.6.12.1 tree and and was wondering where the tag went.
Tags are private in git (the same way branches are), which means that you
can have a million of your own tags and never disturb anybody else.
But, like branches, it means that if you want a tag, you need to know the
tag you want, and download it the same way you download a branch.
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 00:07:07
Linus Torvalds wrote:
On Wed, 22 Jun 2005, Greg KH wrote:
quoted
Ok, this is annoying. Is there some reason why git doesn't pull the
tags in properly when doing a merge? Chris and I just hit this when I
pulled his 2.6.12.1 tree and and was wondering where the tag went.
Tags are private in git (the same way branches are), which means that you
can have a million of your own tags and never disturb anybody else.
But, like branches, it means that if you want a tag, you need to know the
tag you want, and download it the same way you download a branch.
Still -- that's interesting data that no script currently tracks. You
gotta fall back to rsync.
Jeff
But, like branches, it means that if you want a tag, you need to know the
tag you want, and download it the same way you download a branch.
Still -- that's interesting data that no script currently tracks. You
gotta fall back to rsync.
Something like
git-ssh/http-pull -w tags/<tagname> tags/<tagname> <url>
_should_ hopefully work now (and the "-a" flag should mean that you also
get all the objects needed for the tag).
I've not tested it, as usual, but it should work as of today thanks to
Daniel Barkalow fixing the pulling of arbitrary objects.
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 01:50:23
Linus Torvalds wrote:
On Wed, 22 Jun 2005, Jeff Garzik wrote:
quoted
quoted
But, like branches, it means that if you want a tag, you need to know the
tag you want, and download it the same way you download a branch.
Still -- that's interesting data that no script currently tracks. You
gotta fall back to rsync.
Something like
git-ssh/http-pull -w tags/<tagname> tags/<tagname> <url>
_should_ hopefully work now (and the "-a" flag should mean that you also
get all the objects needed for the tag).
The problem isn't pulling tags, the problem is that nothing
automatically downloads the 41-byte tag files themselves. Pulling
linux-2.6.git after the 2.6.12 release did not cause refs/tags/v2.6.12
to be downloaded.
With BK, tags came with each pull. With git, you have to go "outside
the system" (rsync) just get the new tags.
Jeff
With BK, tags came with each pull. With git, you have to go "outside
the system" (rsync) just get the new tags.
You don't have to use rsync, and you don't have to go outside the system.
That was my point: you can use "git-ssh-pull" to pull the tags.
But yes, you have to explicitly ask for them by name, ie the other side
has to let you know: "Oh, btw, I created a 'xyz' tag for you". And having
another helper script to hide the details of how git-*-pull handles tags
is obviously also a good idea, although it's pretty low on my list of
things to worry about.
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 02:21:53
Linus Torvalds wrote:
On Wed, 22 Jun 2005, Jeff Garzik wrote:
quoted
With BK, tags came with each pull. With git, you have to go "outside
the system" (rsync) just get the new tags.
You don't have to use rsync, and you don't have to go outside the system.
That was my point: you can use "git-ssh-pull" to pull the tags.
OK, understood.
But yes, you have to explicitly ask for them by name, ie the other side
has to let you know: "Oh, btw, I created a 'xyz' tag for you". And having
another helper script to hide the details of how git-*-pull handles tags
is obviously also a good idea, although it's pretty low on my list of
things to worry about.
The problem is still that nothing says "oh, btw, I created 'xyz' tag for
you" AFAICS?
IMO the user (GregKH and me, at least) just wants to know their set of
tags and heads is up-to-date on local disk. Wants to know what tags are
out there. It's quite annoying when two data sets are out of sync
(.git/objects and .git/refs/tags).
Asking for the tag by name isn't useful at all, in that regard, because
that requires that the user already know what tags are available. To
get that info, one must use rsync, gitweb, or a subscription to Psychic
Friends Network.
Jeff
The problem is still that nothing says "oh, btw, I created 'xyz' tag for
you" AFAICS?
IMO the user (GregKH and me, at least) just wants to know their set of
tags and heads is up-to-date on local disk. Wants to know what tags are
out there. It's quite annoying when two data sets are out of sync
(.git/objects and .git/refs/tags).
Well, I really think this is the exact same issue as when you write any
annoucement, and say "please pull from branch xyz of repo abc".
What I'm saying is that for a tagged release, that really translates to
"please pull tag xyz from repo abc" and the tools like git-ssh-pull will
just do the right thing: they'll pull the tag itself _and_ they'll pull
the objects it points to.
Of course, right now "git fetch" is hardcoded to always write FETCH_HEAD
(not the tag name), but I'm saying ythat _literally_ you can do this
already:
git fetch repo-name tags/xyz &&
( cat .git/FETCH_HEAD > .git/tags/xyz )
and it should do exactly what you want. Hmm?
So if we script this (maybe teach "git-fetch-script" to take "tag" as its
first argument and do this on its own), and people learn to just do
git fetch tag v2.6.18.5
when Chris or Greg make an announcement about "v2.6.18.5", then you're all
done, no?
The change to "git-fetch-script" would look something like the appended..
Totally untested, of course. Give it a try,
Linus
---
From: Jeff Garzik <hidden> Date: 2005-06-23 03:06:27
Linus Torvalds wrote:
What I'm saying is that for a tagged release, that really translates to
"please pull tag xyz from repo abc" and the tools like git-ssh-pull will
just do the right thing: they'll pull the tag itself _and_ they'll pull
the objects it points to.
Yes, everything does the right there here.
Of course, right now "git fetch" is hardcoded to always write FETCH_HEAD
(not the tag name), but I'm saying ythat _literally_ you can do this
already:
git fetch repo-name tags/xyz &&
( cat .git/FETCH_HEAD > .git/tags/xyz )
and it should do exactly what you want. Hmm?
No, not at all. This sub-thread is all about tags/ dir updates. Users
should be able to do
git pull-more rsync://...
and get ALL of .git/refs/tags/* that have appeared since their last update.
Concrete example: I have a git tree on local disk. I need to find out
where, between 2.6.12-rc1 and 2.6.12, a driver broke. This requires
that I have -ALL- linux-2.6.git/refs/tags on disk already, so that I can
bounce quickly and easily between tags.
It is valuable to have a local copy of -all- tags, -before- you need
them. That is why people like me and GregKH use rsync directly. We
want EVERYTHING in the kernel.org linux-2.6.git tree, not just what we
know we need right now.
Jeff
Concrete example: I have a git tree on local disk. I need to find out
where, between 2.6.12-rc1 and 2.6.12, a driver broke. This requires
that I have -ALL- linux-2.6.git/refs/tags on disk already, so that I can
bounce quickly and easily between tags.
Absolutely not.
I might have my private tags in my kernel, and you might have your private
tags ("tested") in your kernel, so there is no such thing as "ALL".
The fact that BK had it was a BK deficiency, and just meant that you
basically couldn't use tags at all with BK, the "official ones" excepted.
It basically meant that nobody else than me could ever tag a tree. Do you
not see how that violates the very notion of "distributed"?
This is _exactly_ the same thing as if you said "I want to merge with ALL
BRANCHES". That notion doesn't exist. You can rsync the whole repository,
and you'll get all branches from that repository, that's really by virtue
of doing a filesystem operation, not because you asked git to get you all
branches.
A tag is even _implemented_ exactly like a branch, except it allows (but
does not require) that extra step of signing an object. The only
difference is literally whether it is in refs/branches or refs/tags.
It is valuable to have a local copy of -all- tags, -before- you need
them.
You seem to not realize that "all tags" is a nonsensical statement in a
distributed system.
If you want to have a list of official tags, why not just do exactly that?
What's so hard with saying "ok, that place has a list of 'official' tags,
let's fetch them".
How would you fetch them? You might use rsync, for example. Or maybe wget.
Or whatever. The point is that this works already. You're asking for
something nonsensical, outside of just a script that does
rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
See? What's your complaint with just doing that?
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 05:17:04
Linus Torvalds wrote:
rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
See? What's your complaint with just doing that?
No complaint with that operation. The complaint is that it's an
additional operation. Re-read what Greg said:
Is there some reason why git doesn't pull the
tags in properly when doing a merge? Chris and I just hit this when I
pulled his 2.6.12.1 tree and and was wondering where the tag went.
Multiple users -- not just me -- would prefer that git-pull-script
pulled the tags, too.
Suggested solution: add '--tags' to git-pull-script
(git-fetch-script?), which calls
rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
You seem to not realize that "all tags" is a nonsensical statement in a
distributed system.
If you want to have a list of official tags, why not just do exactly that?
What's so hard with saying "ok, that place has a list of 'official' tags,
let's fetch them".
I know how tags work, and I like the new flexibility above and beyond BK.
Kernel hackers are surprised when the tags aren't pulled, along with the
objects. BK and CVS trained us that tags came with the repo, no
additional steps needed. Why not give us the OPTION of working like
we've always worked?
Let the kernel hacker say "yes, I really do want to download the tags
Linus publicly posted in linux-2.6.git/refs/tags" because this was a
common operation in the previous workflow, a common operation that we
-made use of-.
Jeff
No complaint with that operation. The complaint is that it's an
additional operation. Re-read what Greg said:
Please re-read what I said.
Pulling a regular head _cannot_ and _must_not_ update tags. Tags are not
associated with the tree, and they _cannot_ and _must_not_ be so, exactly
because that would make them global instead of private, and it would
fundamentally make them not be distributed, and would mean that they'd be
pointless as anything but "Linus' official tags".
That's what we had in BK _AND IT DOES NOT WORK_!
Does it help when I scream?
quoted
Is there some reason why git doesn't pull the
tags in properly when doing a merge? Chris and I just hit this when I
pulled his 2.6.12.1 tree and and was wondering where the tag went.
And I suggested that if you want that, then you pull on the TAG. You take
my modification, you test it, and you see if
git fetch tag ..repo.. tagname
works.
That solves exactly the case that Greg is complaining about, and it solves
it in a _sane_ manner: you tell git that you want a tag, and git fetches
it for you. It's that simple, and it does not introduce the _BROKEN_
notion that tags are associated directly with the commit itself and
somehow visible to all.
Multiple users -- not just me -- would prefer that git-pull-script
pulled the tags, too.
And multiple users -- clearly including you -- aren't listening to me.
Tags are separate from the source they tag, and they HAVE TO BE. There is
no "you automatically get the tags when you get the tree", because the two
don't have a 1:1 relationship.
And not making them separate breaks a lot of things. As mentioned, it
fundamentally breaks the distributed nature, but that also means that it
breaks whenever two people use the same name for a tag, for example. You
can't "merge" tags. BK had a very strange form of merging, which was (I
think) to pick the one last in the BK ChangeSet file, but that didn't make
it "right". You just never noticed, because Linux could never use tags at
all due to the lack of privacy, except for big releases..
Suggested solution: add '--tags' to git-pull-script
(git-fetch-script?), which calls
rsync -r --ignore-existing repo/refs/tags/ .git/refs/tags/
How is this AT ALL different from just having a separate script that does
this? You've introduced nothing but syntactic fluff, and you've made it
less flexible at the same time. First off, you might want to get new tags
_without_ fetching anything else, and you might indeed want to get the
tags _first_ in order to decide what you want to fetch. In fact, in many
cases that's exactly what you want, namely you want to fetch the data
based on the tag.
Secondly, if your worry is that you forget, then hell, write a small shell
function, and be done with it.
BUT DO NOT MESS UP THINGS FOR OTHER PEOPLE.
When I fetch somebody elses head, I had better not fetch his tags. His
tags may not even make _sense_ in what I have - he may tag things in other
branches that I'm not fetching at all. In fact, his tag-namespace might be
_different_ from mine, ie he might have tagged something "broken" in his
tree, and I tagged something _else_ "broken" in mine, just because it
happens to be a very useful tag for when you want to mark "ok, that was a
broken tree".
It is wrong, wrong, _wrong_ to think that fetching somebody elses tree
means that you should fetch his tags. The _only_ reason you think it's
right is because you've only ever seen centralized tags: tags were the one
thing that BK kept centralized.
But once people realize that they can use tags in their own trees, and
nobody else will ever notice, they'll slowly start using them. Maybe it
takes a few months or even longer. But it will happen. And I refuse to
make stupid decisions that makes it not work.
And thinking that "fetching a tree fetches all the tags from that tree"
really _is_ a stupid decision. It's missing the big picture. It's missing
the fact that tags _should_ be normal every-day things that you just use
as "book-marks", and that the kind of big "synchronization point for many
people" tag should actually be the _rare_ case.
The fact that global tags make that private "bookmark" usage impossible
should be a big red blinking sign saying "don't do global tags".
Let the kernel hacker say "yes, I really do want to download the tags
Linus publicly posted in linux-2.6.git/refs/tags" because this was a
common operation in the previous workflow, a common operation that we
-made use of-.
And I already suggested a trivial script. Send me the script patch,
instead of arguing for stupid things.
Linus
On Wed, Jun 22, 2005 at 10:58:13PM -0700, Linus Torvalds wrote:
And I suggested that if you want that, then you pull on the TAG. You take
my modification, you test it, and you see if
git fetch tag ..repo.. tagname
works.
Hm, that doesn't work right now. Both:
git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1
or
git fetch tag rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git v2.6.12.1
die. Or am I just trying to take a point you were making about not
pulling all tags (which I can live with, just was not aware it was this
way, and I agree that it does offer up a lot of possiblities of me using
local tags in the future), and taking it literally?
thanks,
greg k-h
Yeah, my suggested mod sucks.
Try the following slightly modified version instead, with
git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1
and now it should work.
Linus
---
On Wed, Jun 22, 2005 at 11:51:40PM -0700, Linus Torvalds wrote:
On Wed, 22 Jun 2005, Greg KH wrote:
quoted
Hm, that doesn't work right now.
Yeah, my suggested mod sucks.
Try the following slightly modified version instead, with
git fetch rsync://rsync.kernel.org/pub/scm/linux/kernel/git/chrisw/linux-2.6.12.y.git tag v2.6.12.1
and now it should work.
From: Jeff Garzik <hidden> Date: 2005-06-23 08:19:23
Linus Torvalds wrote:
Pulling a regular head _cannot_ and _must_not_ update tags. Tags are not
associated with the tree, and they _cannot_ and _must_not_ be so, exactly
For general git implementation, strongly agreed.
And not making them separate breaks a lot of things. As mentioned, it
fundamentally breaks the distributed nature, but that also means that it
breaks whenever two people use the same name for a tag, for example. You
can't "merge" tags. BK had a very strange form of merging, which was (I
think) to pick the one last in the BK ChangeSet file, but that didn't make
it "right". You just never noticed, because Linux could never use tags at
all due to the lack of privacy, except for big releases..
Agreed.
How is this AT ALL different from just having a separate script that does
this? You've introduced nothing but syntactic fluff, and you've made it
less flexible at the same time. First off, you might want to get new tags
_without_ fetching anything else, and you might indeed want to get the
tags _first_ in order to decide what you want to fetch.
That's a fair point. A separate script would be better.
because that would make them global instead of private, and it would
fundamentally make them not be distributed, and would mean that they'd be
pointless as anything but "Linus' official tags".
[...]
the fact that tags _should_ be normal every-day things that you just use
as "book-marks", and that the kind of big "synchronization point for many
people" tag should actually be the _rare_ case.
For my use, I require all "Linus official tags" to be present in all my
kernel trees, precisely because it is a big sync point for many people.
User A sends me a patch against 2.6.12-rc2, user B sends me a patch
against 2.6.12-rc3, user C sends me a patch against 2.6.12... I create
a branch with
cp .git/refs/tags/$kversion .git/refs/heads/foo-net-drvr
git checkout -f foo-net-drvr
apply the patch, then pull linux-2.6.git to merge up to the latest version.
So in my case, the rare case is the 99% common case :)
I suppose this usage is just highly specific to me.
Jeff
From: Petr Baudis <hidden> Date: 2005-06-23 08:28:58
Dear diary, on Thu, Jun 23, 2005 at 07:58:13AM CEST, I got a letter
where Linus Torvalds [off-list ref] told me that...
Does it help when I scream?
Nope. I still think you are wrong. :-) (BTW, Cogito always fetches all
the tags now - but it's not that I would have a huge problem with
changing that to some better behaviour.)
quoted
Multiple users -- not just me -- would prefer that git-pull-script
pulled the tags, too.
And multiple users -- clearly including you -- aren't listening to me.
Tags are separate from the source they tag, and they HAVE TO BE. There is
no "you automatically get the tags when you get the tree", because the two
don't have a 1:1 relationship.
And not making them separate breaks a lot of things. As mentioned, it
fundamentally breaks the distributed nature, but that also means that it
breaks whenever two people use the same name for a tag, for example. You
can't "merge" tags. BK had a very strange form of merging, which was (I
think) to pick the one last in the BK ChangeSet file, but that didn't make
it "right". You just never noticed, because Linux could never use tags at
all due to the lack of privacy, except for big releases..
I think there should simply be two namespaces - public tags and private
tags. Private tags for stuff like "broken", "merged", or "funnychange".
Other people don't care about those, and they certainly shouldn't get
them by default (but they should have a way to get them explicitly, if
you tell them). But then there are the official tags, like "v2.6.13" or
even "v2.6.12-ck2" - if you merge with those branches, you should always
get those precisely for what Jeff says - they are big syncing points for
a lot of people and you should be always able to refer to v2.6.13 if you
have the commit in your tree.
Since there should be _few_ of those tags, you might even want to get
tags only from branches marked "tagtrusted" (Cogito's origin branch
would be by default), or want to interactively confirm new tag additions
during a pull. Also, ideally there would be no or only extremely rare
tag conflicts.
I think it would be simplest to use a special prefix for the private
tags. ~ and ! might get touched by shell, so what about %?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
From: Martin Langhoff <hidden> Date: 2005-06-23 10:14:26
On 6/23/05, Petr Baudis [off-list ref] wrote:
I think there should simply be two namespaces - public tags and private
tags. Private tags for stuff like "broken", "merged", or "funnychange".
I guess that public tags would also probably be in a different
location from the actual tree. With the split Linus advocates, several
people could be publishing sets of "public" tags, as well as having
the official tags hosted separately from the .git repo.
cheers,
martin
On Wed, Jun 22, 2005 at 10:58:13PM -0700, Linus Torvalds wrote:
And thinking that "fetching a tree fetches all the tags from that tree"
really _is_ a stupid decision. It's missing the big picture. It's missing
the fact that tags _should_ be normal every-day things that you just use
as "book-marks", and that the kind of big "synchronization point for many
people" tag should actually be the _rare_ case.
The fact that global tags make that private "bookmark" usage impossible
should be a big red blinking sign saying "don't do global tags".
Maybe it'd make sense to differentiate between the two types of tags?
To have local tags which don't propagate, and global (version) tags
which do? They could live in different namespaces and thus wouldn't
interfere.
--
Vojtech Pavlik
SuSE Labs, SuSE CR
2) download a linux kernel tree for the very first time
$ mkdir -p linux-2.6/.git
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
Gaah. I should do a "git-clone-script" or something that does this, and
then you could just do
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Anybody?
# make some modifications
$ patch -sp1 < /tmp/my.patch
$ diffstat -p1 < /tmp/my.patch
# NOTE: add '--add' and/or '--remove' if files were added or removed
$ git-update-cache <list of all files changed>
# check in changes
$ git commit
A few notes on these things:
git-apply --index /tmp/my.patch
will not only apply the patch (unified patches only!), but will do the
index updates for you while it's at it, so if the patch contains new files
(or it deletes files), you don't need to worry about it.
Also, you can do
git commit <list-of-files-to-commit>
as a shorthand for
git-update-cache <list-of-files-to-commit>
git commit
which some people will probably find more natural.
6) List all changes in working dir, in diff format.
$ git-diff-cache -p HEAD
Or, perhaps preferably:
git diff HEAD
since that is shorter ad will also show renames.
8) List all changesets:
$ git-whatchanged
No, if you just want the changesets listed, then
git log
is a lot better, since it shows merges.
"git-whatchanged" is useful if you actually want to see what the commits
_changed_, and then you often want to use the "-p" flag to see it as
patches. Also, it's worth pointing out the fact that you can limit it to
certain subdirectories (or individual files) etc, ie:
git-whatchanged -p drivers/net
since that is often what people want.
But if you just want the log, "git log" is faster and simpler and more
correct.
16) obtain a diff between current branch, and master branch
In most trees WITH BRANCHES, .git/refs/heads/master contains the current
'vanilla' upstream tree, for easy diffing and merging. (in trees
without branches, 'master' simply contains your latest changes)
$ git-diff-tree -p master HEAD
Again, I think is possibly more naturally expressed with "git diff":
git diff master..HEAD
which just says "show the differences from 'master' to 'HEAD'" and will
also show renames etc.
(A plain "git diff" will show just the difference to the index file, in
case you care).
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 00:18:41
Linus Torvalds wrote:
[snip]
Thanks, this is all good stuff. I'll update it and post another, in a
few days or so.
git-clone-script would indeed be nice, even if its only a 2-line script.
Jeff
git-clone-script would indeed be nice, even if its only a 2-line script.
Ok, added. You can update your tutorial to make the initial setup of a
kernel archive slightly less scary, ie it's now
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
cd linux-2.6
git checkout
which looks almost user-friendly.
(Of course, since the rsync protocol doesn't know anything about git
consistency, if the mirroring is half-way, you'll end up with something
less than wonderful, and confusing. Details, details)
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 08:19:24
Linus Torvalds wrote:
(Of course, since the rsync protocol doesn't know anything about git
consistency, if the mirroring is half-way, you'll end up with something
less than wonderful, and confusing. Details, details)
Would it make sense to add an fsck step to git-clone-script?
Jeff
(Of course, since the rsync protocol doesn't know anything about git
consistency, if the mirroring is half-way, you'll end up with something
less than wonderful, and confusing. Details, details)
Would it make sense to add an fsck step to git-clone-script?
Well, it's going to be slow. Of course, it's not as slow as pulling the
stuff over a DSL line or whatever, but still..
I think I need to make something that just verifies the top <n> commits or
whatever - I need that for "pull" anyway, so that you can do a
git fsck ORIG_HEAD..
and it will fsck only the new stuff that arrived as a result of the pull.
And we need to improve the git-ssh-pull/git-http-pull scripts so that they
do pipelined requests: right now it's usually a lot faster to do "rsync"
than it is to do git-ssh-pull (unless you do a small pull), because even
though the rsync ends up needing to compare the full directory contents,
it then transfers the data much faster.
Linus
A few notes on these things:
git-apply --index /tmp/my.patch
will not only apply the patch (unified patches only!), but will do the
index updates for you while it's at it, so if the patch contains new files
(or it deletes files), you don't need to worry about it.
Btw, if the patch contains rename/copy-patches or mode updates, you _need_
to use git-apply, since regular "patch" doesn't know about file modes and
can't handle file renames or copies.
Now, the rename/copy patches are easy to avoid by just not asking git to
generate them (so they'll show up as just straight file creates, with a
delete of the old file for a rename), but the file mode part in particular
is useful as more than just a way to create smaller (and more
human-readable) patches.
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 02:09:22
Linus Torvalds wrote:
A few notes on these things:
git-apply --index /tmp/my.patch
will not only apply the patch (unified patches only!), but will do the
index updates for you while it's at it, so if the patch contains new files
(or it deletes files), you don't need to worry about it.
The output isn't terribly helpful:
[jgarzik@pretzel netdev-2.6]$ git apply --index \
~/tmp/linux-2.6.12-rc4-cxgb2.1.1.patch
Fragment applied at offset 11
That is worse than no message at all... fragment? offset 11? did it
work? Did it apply only a "fragment" of my patch, not the whole thing?
I'm worried! </mental monologue>
Outputting the following (stolen from 'git commit') would be far more
useful:
modified: Documentation/networking/cxgb.txt
modified: drivers/net/chelsio/Makefile
deleted: drivers/net/chelsio/ch_ethtool.h
modified: drivers/net/chelsio/common.h
modified: drivers/net/chelsio/cphy.h
modified: drivers/net/chelsio/cpl5_cmd.h
modified: drivers/net/chelsio/cxgb2.c
deleted: drivers/net/chelsio/cxgb2.h
modified: drivers/net/chelsio/elmer0.h
modified: drivers/net/chelsio/espi.c
modified: drivers/net/chelsio/espi.h
modified: drivers/net/chelsio/gmac.h
modified: drivers/net/chelsio/mv88x201x.c
deleted: drivers/net/chelsio/osdep.h
modified: drivers/net/chelsio/pm3393.c
modified: drivers/net/chelsio/regs.h
modified: drivers/net/chelsio/sge.c
modified: drivers/net/chelsio/sge.h
modified: drivers/net/chelsio/subr.c
modified: drivers/net/chelsio/suni1x10gexp_regs.h
deleted: drivers/net/chelsio/tp.c
deleted: drivers/net/chelsio/tp.h
modified: include/linux/pci_ids.h
Also, you can do
git commit <list-of-files-to-commit>
as a shorthand for
git-update-cache <list-of-files-to-commit>
git commit
which some people will probably find more natural.
It would be natural if it functioned like 'bk citool' ;-)
git commit --figure-out-for-me-what-files-changed
'git diff' can do this, so it's certainly feasible.
Obviously added/removed files would still require git-update-cache or
git-commit<list of files>.
"git-whatchanged" is useful if you actually want to see what the commits
_changed_, and then you often want to use the "-p" flag to see it as
patches. Also, it's worth pointing out the fact that you can limit it to
certain subdirectories (or individual files) etc, ie:
git-whatchanged -p drivers/net
since that is often what people want.
But if you just want the log, "git log" is faster and simpler and more
correct.
I usually want just two things:
1) browse the log
2) list changes in local tree that are not in $remote_tree, a la
bk changes -L ../linux-2.6
I agree that seeing the merge csets is useful, that is why [being
ignorant of 'git log'] I used git-changes-script.
Jeff
Yeah. The good news is that if something bad happens, it surely lets you
know, and it's very verbose about that.
I should probably remove the "Fragment applied at offset xx" thing, it was
basically a debugging message to make sure that I applied patch fragments
correctly even if the line offset given in the patch was sligthly off..
Outputting the following (stolen from 'git commit') would be far more
useful:
modified: Documentation/networking/cxgb.txt
modified: drivers/net/chelsio/Makefile
deleted: drivers/net/chelsio/ch_ethtool.h
modified: drivers/net/chelsio/common.h
modified: drivers/net/chelsio/cphy.h
modified: drivers/net/chelsio/cpl5_cmd.h
modified: drivers/net/chelsio/cxgb2.c
deleted: drivers/net/chelsio/cxgb2.h
modified: drivers/net/chelsio/elmer0.h
modified: drivers/net/chelsio/espi.c
modified: drivers/net/chelsio/espi.h
modified: drivers/net/chelsio/gmac.h
modified: drivers/net/chelsio/mv88x201x.c
deleted: drivers/net/chelsio/osdep.h
modified: drivers/net/chelsio/pm3393.c
modified: drivers/net/chelsio/regs.h
modified: drivers/net/chelsio/sge.c
modified: drivers/net/chelsio/sge.h
modified: drivers/net/chelsio/subr.c
modified: drivers/net/chelsio/suni1x10gexp_regs.h
deleted: drivers/net/chelsio/tp.c
deleted: drivers/net/chelsio/tp.h
modified: include/linux/pci_ids.h
How about this patch? Then you can say
git-apply --stat --summary --apply --index /tmp/my.patch
and it will not only apply the patch, but also give a diffstat and a
summary or renames etc..
This also removes the "Fragment.." debugging message.
Btw, "--stat" and "--summary" normally turn off the "apply" flag, so
"--apply" has to come _after_ the stat/summary thing, fwiw:
@@ -860,7 +860,6 @@ static int find_offset(const char *buf, n=(i>>1)+1;if(i&1)n=-n;-fprintf(stderr,"Fragment applied at offset %d\n",n);returntry;}
@@ -1434,6 +1433,10 @@ int main(int argc, char **argv)check_index=1;continue;}+if(!strcmp(arg,"--apply")){+apply=1;+continue;+}if(!strcmp(arg,"--show-files")){show_files=1;continue;
quoted
Also, you can do
git commit <list-of-files-to-commit>
as a shorthand for
git-update-cache <list-of-files-to-commit>
git commit
which some people will probably find more natural.
It would be natural if it functioned like 'bk citool' ;-)
git commit --figure-out-for-me-what-files-changed
'git diff' can do this, so it's certainly feasible.
Well, it _does_ do that. That's what the "git status" thing does, and look
at the initial commit message comments that it prepares for you: it tells
you which files are modified but haven't been marked for check-in etc.
But the thing is, you need to have a graphical tool for that. I don't want
to have some silly command line that asks for each modified file whether
you want to include that file in the commit or not.
So this is where "git" ends, and a nice user interface (written by
somebody else than me) begins. Ie this is a cogito-like thing.
quoted
"git-whatchanged" is useful if you actually want to see what the commits
_changed_, and then you often want to use the "-p" flag to see it as
patches. Also, it's worth pointing out the fact that you can limit it to
certain subdirectories (or individual files) etc, ie:
git-whatchanged -p drivers/net
since that is often what people want.
But if you just want the log, "git log" is faster and simpler and more
correct.
I usually want just two things:
1) browse the log
2) list changes in local tree that are not in $remote_tree, a la
bk changes -L ../linux-2.6
I agree that seeing the merge csets is useful, that is why [being
ignorant of 'git log'] I used git-changes-script.
For (1) "bk log" is good. For (2) you'll have to use your own script, or
just have the remote tree as a branch in the same tree, in which case you
can do
git log remotebranch..mybranch
and it will do what you expect. In fact, since "HEAD" is the default
branch for the final one, you can do
git log remotebranch..
and you'll get the log of everything that is in your HEAD but it _not_ in
the "remotebranch" branch.
Btw, if you have the remote as a branch in your own tree, you can also do
gitk remotebranch..mybranch
which is a really nice way of graphically seeing "what is in 'mybranch'
that is not in 'remotebranch'".
Linus
From: Adam Kropelin <hidden> Date: 2005-06-23 04:28:09
Linus Torvalds wrote:
On Wed, 22 Jun 2005, Jeff Garzik wrote:
quoted
git commit --figure-out-for-me-what-files-changed
Well, it _does_ do that. That's what the "git status" thing does, and
look at the initial commit message comments that it prepares for you:
it
tells you which files are modified but haven't been marked for
check-in
etc.
But the thing is, you need to have a graphical tool for that. I don't
want to have some silly command line that asks for each modified file
whether you want to include that file in the commit or not.
I know I shouldn't invoke this particular acronym, but I rather like
CVS's approach. If the user does not specify any files on the command
line, assume he wants to check in everything that has changed (added and
removed files excluded). When you see the initial commit message you can
review the list of affected files and you can always abort and specify
files explictly if you realize you want to exclude some.
I like that method because it gives you a kick in the pants for having
mixed multiple unrelated changes in your working directory. "Oh, you
were lazy and changed six unrelated things without comitting, eh? You
will now pay for your lack of rigor by typing filenames..." On the flip
side, you get rewarded with less typing if you keep your working
directory clean.
--Adam
I know I shouldn't invoke this particular acronym, but I rather like
CVS's approach.
The problem I have with "git commit" committing everything dirty by
default is that it encourages exactly the wrong kind of behaviour, ie the
"commit it all in one go without thinking about it".
Also, CVS really doesn't have much choice, since CVS doesn't _have_ the
notion of marking files for commits. In contrast, in git the index file
really does end up beign a good way to say which files are ready to be
committed.
And "git status" really isn't that hard to type, and it will tell you
exactly what you've already marked for commit, and what you have dirty in
the tree but isn't marked for commit yet.
So I think the "git commit <file-list>" thing is very convenient, but it's
convenient exactly because it's concise yet still precise and doesn't
encourage the "just commit whatever random dirty state I have right now"
mentality.
And if you have more than a few files dirty in your tree, I really think
it's much better to do "git status" and think about it a bit and select
the files you do want to commit than it is to just do "git commit" and let
it rip.
Now, I could well imagine adding an "--all" flag (and not even allow the
shorthane version) to both git-update-cache and "git commit". So that you
could say "commit all the dirty state", but you'd at least have to think
about it before you did so.
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 05:36:09
Linus Torvalds wrote:
The problem I have with "git commit" committing everything dirty by
default is that it encourages exactly the wrong kind of behaviour, ie the
"commit it all in one go without thinking about it".
100% agreed
And "git status" really isn't that hard to type, and it will tell you
exactly what you've already marked for commit, and what you have dirty in
the tree but isn't marked for commit yet.
Having found about it recently, 'git status' is quite useful.
So I think the "git commit <file-list>" thing is very convenient, but it's
convenient exactly because it's concise yet still precise and doesn't
encourage the "just commit whatever random dirty state I have right now"
mentality.
And if you have more than a few files dirty in your tree, I really think
it's much better to do "git status" and think about it a bit and select
the files you do want to commit than it is to just do "git commit" and let
it rip.
For me at least, providing a file list is a pain, because I am so
precise [read: obsessive] about keeping an otherwise clean working dir
:) Except in rare occasions, I know precisely that the changes in the
working dir comprise 100% of what I plan to commit.
Locally I have scripted
git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst
git-update-cache `cat /tmp/lst`
because of this.
[again, clearly doesn't work with remove/add/mode change]
Now, I could well imagine adding an "--all" flag (and not even allow the
shorthane version) to both git-update-cache and "git commit". So that you
could say "commit all the dirty state", but you'd at least have to think
about it before you did so.
That's pretty much what I suggested when I said
git commit --figure-out-for-me-what-files-changed
:)
So I certainly agree there.
Jeff
Locally I have scripted
git-diff-cache -p HEAD | diffstat -p1 | awk '{print $1}' > /tmp/lst
git-update-cache `cat /tmp/lst`
because of this.
Btw, that's some extremely convoluted computation.
This is exactly when you do _not_ want the diff in "patch" form, and you
really want the native git format (which is just a strange "this file
changed from this mode/sha1 to that mode/sha1" format).
So instead, try to do just
git-diff-cache HEAD | cut -f2
and now it's going to be a whole lot simpler and faster - it won't turn
things into a diff only to do a "diffstat" on it to turn it into a name
again. I bet it's more reliable too.
[again, clearly doesn't work with remove/add/mode change]
Well, it actually can work with removes, and rewriting it to be a bit
more clean (and handle files that start with "-") gives you:
git-update-cache --remove -- $(git-diff-cache HEAD | cut -f2)
which should actually work fine for files that you have removed. But yes,
it fundamentally _cannot_ work for new files, of course, since git will
never even try to look for files you haven't told it about. So you always
have to add files by hand some way.
Note how the "--remove" parameter to git-update-cache really only means
"it's ok if some of the files mentioned don't exist any more, and that
means you should remove them from the cache".
Without the "--remove" flag, a filename that is listed but that doesn't
exist in the working tree is either considered an error, or is ignored
(depending on the "--ignore-missing" flag).
That's actually what "--add" means too: it means "it's ok if some of the
filenames on the command line don't currently exist in the index: if they
exist in the working directory, you should add them".
So even if it looks a bit strange, in a script it actually makes perfect
sense to write something that seems as _apparently_ senseless as:
git-update-cache --add --remove --refresh -- "$@"
and it will refresh all existing files, and add or remove any files
explicitly mentioned that either exist or have been removed in the working
directory.
Linus
From: Jeff Garzik <hidden> Date: 2005-06-23 08:29:05
Linus Torvalds wrote:
How about this patch? Then you can say
git-apply --stat --summary --apply --index /tmp/my.patch
and it will not only apply the patch, but also give a diffstat and a
summary or renames etc..
Quite nice.
quoted
I usually want just two things:
1) browse the log
2) list changes in local tree that are not in $remote_tree, a la
bk changes -L ../linux-2.6
I agree that seeing the merge csets is useful, that is why [being
ignorant of 'git log'] I used git-changes-script.
For (1) "bk log" is good.
Chuckle. What does one call a Freudian slip, in computer-land?
For (2) you'll have to use your own script, or
just have the remote tree as a branch in the same tree, in which case you
can do
git log remotebranch..mybranch
Very neat. That makes some things a bit easier, since I usually carry a
'vanilla' branch as .git/refs/heads/master, and do all my modifications
on other branches.
FWIW, git-changes-script (attached) facilitates #2 for me right now. I
use it just like BK's '-L' feature:
cd netdev-2.6
git checkout -f ieee80211
git-changes-script -L ../linux-2.6 | less
That will produce the same output as the feature you just taught me,
git log master..ieee80211
WARNING: You have previously called git-changes-script quite ugly (not
surprising), and this 'git log x..y' will probably replace it in my
usage, long term.
Jeff
Chuckle. What does one call a Freudian slip, in computer-land?
A "Knuthian slip"?
WARNING: You have previously called git-changes-script quite ugly (not
surprising), and this 'git log x..y' will probably replace it in my
usage, long term.
Even short-term, you could actually make it prettier.
You can actually use git across multiple directories by setting the
GIT_ALTERNATE_OBJECT_DIRECTORIES environment variable to point to the
alternate ones, so you should be able to do a "compare with remote" with
something like this:
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$remote/.git/objects
remote_head=$(cat $remote/.git/HEAD)
git log $remote_head..
which should literally give a nice log of what is in your HEAD but not in
$remote_head. And if you want to see it the other way? Just change the
last line to
git log HEAD..$remote_head
and voila, you're done.
The nice thing about this approach is that this works with other git
programs too, ie you can replace "git log" with "gitk", and suddenly you
see graphically the commits that are in your tree but not in the remote
HEAD or vice versa.
Yeah, yeah, totally untested and maybe I'm talking through by *ss, but it
should work in theory.
Linus
From: Anton Altaparmakov <hidden> Date: 2005-06-23 08:39:52
On Wed, 22 Jun 2005, Linus Torvalds wrote:
On Wed, 22 Jun 2005, Jeff Garzik wrote:
quoted
2) download a linux kernel tree for the very first time
$ mkdir -p linux-2.6/.git
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
Gaah. I should do a "git-clone-script" or something that does this, and
then you could just do
git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
Anybody?
What's wrong with Pasky's cogito scripts? There is a cg-pull as well as a
cg-clone in there already. If nothing else you could just copy the
relevant scripts and rename them to git-blah...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
From: Daniel Barkalow <hidden> Date: 2005-06-23 04:24:44
On Wed, 22 Jun 2005, Jeff Garzik wrote:
5) check in your own modifications (e.g. do some hacking, or apply a patch)
# go to repo
$ cd linux-2.6
# make some modifications
$ patch -sp1 < /tmp/my.patch
$ diffstat -p1 < /tmp/my.patch
# NOTE: add '--add' and/or '--remove' if files were added or removed
$ git-update-cache <list of all files changed>
There's actually "git add" for when you add a file (if you're actually
developing with git, rather than just applying patching with it). No
script, so far as I can tell, for removing a file, though.
-Daniel
*This .sig left intentionally blank*
Do you have some sort of magic bk-make-sum type util at all...
For sending trees to Linus I used to run bk-make-sum and gcapatch and
then just throw my own stuff in the top of the mail ....
I'm being lazy I probably could write it myself, but bk-make-sum was a
very useful script for me...
Dave.
2) download a linux kernel tree for the very first time
$ mkdir -p linux-2.6/.git
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
$ mkdir linux-2.6
$ cd linux-2.6
$ hg init http://www.kernel.org/hg/ # obviously you can also browse this
This downloads about 125M of data, which include the whole kernel history
back to 2.4.0 and everything in Linus' git repo as well.
3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
$ cd linux-2.6
$ git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ hg pull # defaults to where you originally pulled from
It takes about 4M of transfer and well under a minute to pull the
entire git history, starting from a base of 2.6.12-rc2.
4) check out files from the git repository into the working directory
$ git checkout -f
$ hg update # or up or checkout or co, depending on your SCM habits
5) check in your own modifications (e.g. do some hacking, or apply a patch)
# go to repo
$ cd linux-2.6
# make some modifications
$ patch -sp1 < /tmp/my.patch
$ diffstat -p1 < /tmp/my.patch
# NOTE: add '--add' and/or '--remove' if files were added or removed
$ git-update-cache <list of all files changed>
# check in changes
$ git commit
$ hg commit [files] # check in everything changed or just the named files
5.1) undo the last commit or pull
$ hg undo
6) List all changes in working dir, in diff format.
$ git-diff-cache -p HEAD
$ hg status # show changed files
7) List all changesets (i.e. show each cset's description text) in local
branch of local tree, that are not present in remote tree.
$ cd my-kernel-tree-2.6
$ git-changes-script -L ../linux-2.6 | less
$ hg history | less # How does git know what's not in the
# remote tree? Psychic?
8) List all changesets:
$ git-whatchanged
$ hg history | less
9) apply all patches in a Berkeley mbox-format file
First, download and add to your PATH Linus's git tools:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
$ cd my-kernel-tree-2.6
$ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
hg doesn't do mboxes directly, but you can do:
$ cat patch-list | xargs hg import
10) don't forget to download tags from time to time.
git-pull-script only downloads sha1-indexed object data, and the
requested remote head. This misses updates to the .git/refs/tags/ and
.git/refs/heads directories. It is advisable to update your kernel .git
directories periodically with a full rsync command, to make sure you got
everything:
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
Tags in mercurial are properly version controlled and come along for
the ride with pulls. Also, the right thing happens with merges.
11) list all branches, such as those found in my netdev-2.6 or
libata-dev trees.
Download
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
or
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
$ cd netdev-2.6
$ ls .git/refs/heads/
{ these are the current netdev-2.6 branches }
$ hg heads # Has Andrew mentioned your git forest gives him a headache?
12) make desired branch current in working directory
$ git checkout -f $branch
$ hg update -C <rev or id or tag>
13) create a new branch, and make it current
$ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
$ git checkout -f my-new-branch-name
Since the hg repo is lightweight, this is usually done by just having
different directories. Thus we don't explicitly name branches.
$ mkdir new-branch
$ cd new-branch
$ hg init -u ../linux # makes hardlinks and does a checkout
14) examine which branch is current
$ ls -l .git/HEAD
$ echo $PWD
15) undo all local modifications (same as checkout):
$ git checkout -f
$ hg update -C
16) obtain a diff between current branch, and master branch
In most trees WITH BRANCHES, .git/refs/heads/master contains the current
'vanilla' upstream tree, for easy diffing and merging. (in trees
without branches, 'master' simply contains your latest changes)
$ git-diff-tree -p master HEAD
$ hg diff -r <rev> -r <rev>
17) run a browsable, pullable repo server of the current repo on your
local machine
$ hg serve
18) push your changes to a remote server
$ hg push ssh://user@host/path/ # aliases and defaults in .hgrc
19) get per-file history
$ hg log <file> | less
20) get annotated file contents
$ hg annotate [file]
21) record that a file has been copied or renamed for the next commit
$ hg copy <source> <dest>
22) get online help
$ hg help [command]
More info at http://selenic.com/mercurial/
--
Mathematics is the supreme nostalgia of our time.
2) download a linux kernel tree for the very first time
$ mkdir -p linux-2.6/.git
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
$ mkdir linux-2.6
$ cd linux-2.6
$ hg init http://www.kernel.org/hg/ # obviously you can also browse this
$ cg-clone \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
(that will checkout to linux-2.6/ directory; you can specify the target
directory as the optional second parameter)
quoted
3) update local kernel tree to latest 2.6.x upstream ("fast-forward merge")
$ cd linux-2.6
$ git-pull-script \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ hg pull # defaults to where you originally pulled from
$ cg-update # defaults to where you originally pulled from
(cg-pull just gets the changes to your repository, but won't merge them
into your branch)
quoted
4) check out files from the git repository into the working directory
$ git checkout -f
$ hg update # or up or checkout or co, depending on your SCM habits
In Cogito, all files are always checked out.
quoted
5) check in your own modifications (e.g. do some hacking, or apply a patch)
# go to repo
$ cd linux-2.6
# make some modifications
$ patch -sp1 < /tmp/my.patch
$ diffstat -p1 < /tmp/my.patch
# NOTE: add '--add' and/or '--remove' if files were added or removed
$ git-update-cache <list of all files changed>
# check in changes
$ git commit
$ hg commit [files] # check in everything changed or just the named files
$ cg-commit [-m"Message"...] [files] # check in everything changed or just
# the named files
If you pass multiple -m arguments, they get formatted as separate
paragraphs in the log message. It is customary for the first -m argument
to contain a short one-line summary.
Note that you must add/remove files by
$ cg-add files...
and
$ cg-rm files...
5.1) undo the last commit or pull
$ hg undo
$ cg-admin-uncommit
Note that you should never do this if you already pushed the changes
out, or someone might get them. (That holds for regular Git too.) See
$ cg-help cg-admin-uncommit # (or cg-admin-uncommit --help)
for details. (That's another Cogito's cool feature. Handy docs! ;-)
quoted
6) List all changes in working dir, in diff format.
$ git-diff-cache -p HEAD
$ hg status # show changed files
$ cg-status # show changed files
$ cg-diff [-c] [files] # show the diffs, -c colourfully
quoted
7) List all changesets (i.e. show each cset's description text) in local
branch of local tree, that are not present in remote tree.
$ cd my-kernel-tree-2.6
$ git-changes-script -L ../linux-2.6 | less
$ hg history | less # How does git know what's not in the
# remote tree? Psychic?
# -c colourfully, -s prints only summaries, one line per changeset
$ cg-log [-c] [-s] -m -r linux-2.6 # List changes only in linux-2.6
Note that | less is unnecessary (even undesirable with -c).
quoted
8) List all changesets:
$ git-whatchanged
$ hg history | less
$ cg-log [-c] [-s]
8.1) List all changesets in the origin branch:
$ cg-log [-c] [-s] -r origin
8.2) List all changesets concerning files CREDITS and fs/inode.c:
$ cg-log [-c] [-s] CREDITS fs/inode.c
quoted
9) apply all patches in a Berkeley mbox-format file
First, download and add to your PATH Linus's git tools:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/git-tools.git
$ cd my-kernel-tree-2.6
$ dotest /path/to/mbox # yes, Linus has no taste in naming scripts
hg doesn't do mboxes directly, but you can do:
$ cat patch-list | xargs hg import
Theoretically, dotest should work just fine even if you use Cogito.
Anyone tested it?
quoted
10) don't forget to download tags from time to time.
git-pull-script only downloads sha1-indexed object data, and the
requested remote head. This misses updates to the .git/refs/tags/ and
.git/refs/heads directories. It is advisable to update your kernel .git
directories periodically with a full rsync command, to make sure you got
everything:
$ cd linux-2.6
$ rsync -a --delete --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
\ <- word-wrapped backslash; sigh
.git/
Tags in mercurial are properly version controlled and come along for
the ride with pulls. Also, the right thing happens with merges.
cg-update and cg-pull takes fetches new tags during a pull.
quoted
11) list all branches, such as those found in my netdev-2.6 or
libata-dev trees.
Download
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
or
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
$ cd netdev-2.6
$ ls .git/refs/heads/
{ these are the current netdev-2.6 branches }
$ hg heads # Has Andrew mentioned your git forest gives him a headache?
$ cg-branch-ls
# Note that Cogito supports only remote branches properly now; that
# will yet evolve (in some backwards-compatible way).
quoted
12) make desired branch current in working directory
$ git checkout -f $branch
$ hg update -C <rev or id or tag>
You can check the desired branch out into another directory:
$ cg-clone path/to/linux-2.6/.git#branch anotherdir
Switching branches in place will be supported soon (although I have
doubts about its usefulness).
quoted
13) create a new branch, and make it current
$ cp .git/refs/heads/master .git/refs/heads/my-new-branch-name
$ git checkout -f my-new-branch-name
Since the hg repo is lightweight, this is usually done by just having
different directories. Thus we don't explicitly name branches.
$ mkdir new-branch
$ cd new-branch
$ hg init -u ../linux # makes hardlinks and does a checkout
$ mkdir new-branch
$ cd new-branch
$ cg-clone -s ../linux-2.6
(Note that cg-clone given local path will do hardlinks too.)
We don't explicitly name branches either. You can make the branch
visible from the other tree by
$ cg-branch-add new-branch ../new-branch
and then refer to it as new-branch.
quoted
14) examine which branch is current
$ ls -l .git/HEAD
$ echo $PWD
Always the "master" branch.
quoted
15) undo all local modifications (same as checkout):
$ git checkout -f
$ hg update -C
$ cg-cancel
quoted
16) obtain a diff between current branch, and master branch
In most trees WITH BRANCHES, .git/refs/heads/master contains the current
'vanilla' upstream tree, for easy diffing and merging. (in trees
without branches, 'master' simply contains your latest changes)
$ git-diff-tree -p master HEAD
$ hg diff -r <rev> -r <rev>
$ cg-diff -r <rev> -r <rev>
17) run a browsable, pullable repo server of the current repo on your
local machine
$ hg serve
Make it accessible over HTTP, SSH, rsync, or for the local users if you
just want them to access it.
18) push your changes to a remote server
$ hg push ssh://user@host/path/ # aliases and defaults in .hgrc
Will be supported Real Soon (tm) (well, probably sometimes next week).
19) get per-file history
$ hg log <file> | less
$ cg-log [-c] [-s] <file>
20) get annotated file contents
$ hg annotate [file]
Planned.
22) get online help
$ hg help [command]
$ cg-help [command]
Cool. Except where the concepts are just different, Cogito mostly
appears at least equally simple to use as Mercurial. Yes, some features
are missing yet. I hope to fix that soon. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
From: Andrea Arcangeli <hidden> Date: 2005-06-24 13:08:50
On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
Cool. Except where the concepts are just different, Cogito mostly
appears at least equally simple to use as Mercurial. Yes, some features
are missing yet. I hope to fix that soon. :-)
The user interface and network protocol isn't the big deal, the big deal
is the more efficient on-disk storage format IMHO.
On Fri, Jun 24, 2005 at 03:06:04PM +0200, Andrea Arcangeli wrote:
On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
quoted
Cool. Except where the concepts are just different, Cogito mostly
appears at least equally simple to use as Mercurial. Yes, some features
are missing yet. I hope to fix that soon. :-)
The user interface and network protocol isn't the big deal, the big deal
is the more efficient on-disk storage format IMHO.
E2fsprogs with the full revision history imported into git is 100
megs, and that's with deltas. E2fsprogs imported into Mercurial is 17
megs (and actually, the imported repository was just a tad bit smaller
than e2fsprogs' BK repository).
Which do you think is going to be faster to operate from a cold start
using 4200 rpm laptop drives? :-)
- Ted
From: Paolo Ciarrocchi <hidden> Date: 2005-06-24 13:53:28
2005/6/24, Theodore Ts'o [off-list ref]:
On Fri, Jun 24, 2005 at 03:06:04PM +0200, Andrea Arcangeli wrote:
quoted
On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
quoted
Cool. Except where the concepts are just different, Cogito mostly
appears at least equally simple to use as Mercurial. Yes, some features
are missing yet. I hope to fix that soon. :-)
The user interface and network protocol isn't the big deal, the big deal
is the more efficient on-disk storage format IMHO.
E2fsprogs with the full revision history imported into git is 100
megs, and that's with deltas. E2fsprogs imported into Mercurial is 17
megs (and actually, the imported repository was just a tad bit smaller
than e2fsprogs' BK repository).
Which do you think is going to be faster to operate from a cold start
using 4200 rpm laptop drives? :-)
- Ted
That's quite intersting, what the rational behind such a difference in
terms of disk occupation ?
--
Paolo
From: Christopher Li <hidden> Date: 2005-06-24 15:31:31
On Fri, Jun 24, 2005 at 03:46:21PM +0200, Paolo Ciarrocchi wrote:
quoted
Which do you think is going to be faster to operate from a cold start
using 4200 rpm laptop drives? :-)
- Ted
That's quite intersting, what the rational behind such a difference in
terms of disk occupation ?
Let me see. Mercurial using delta or full storage for the repository.
It insert a full node when it detect that delta it need to reach
certain node is too big. It just like MPEG movies, most of the frame
is delta to the previous frame. Once a while you have full frame to
allow you seek to.
But git has delta as well right? Another factor is that all file has
same path in mercurial using the same storage file. So in mercurial
it has far less file to store in the repository. Each file has two repository
files, the data storage file and the index file. Remember that file system
like ext3 is using blocks, if you store very small stuff on a file, it is
still going to take at least one block on disk. So that will defeat the delta
compression if the delta is always on a new file.
Chris
From: Kevin Smith <hidden> Date: 2016-06-15 22:42:00
Andrea Arcangeli wrote:
> On Fri, Jun 24, 2005 at 08:41:01AM +0200, Petr Baudis wrote:
>
>>Cool. Except where the concepts are just different, Cogito mostly
>>appears at least equally simple to use as Mercurial. Yes, some
>>features are missing yet. I hope to fix that soon. :-)
>
>
> The user interface and network protocol isn't the big deal, the
> big deal is the more efficient on-disk storage format IMHO.
For me, efficient storage is not very important, because I mostly deal
with small projects. Likewise, speed isn't a factor for me, since both
tools are plenty fast on small repos.
For me, the big advantage of mercurial is that it is written in python,
instead of shell scripts. I know for some people that's a DISadvantage,
but I see the following benefits as a result:
- Can run on (native) MS Windows
(necessary for me because I often work on cross-platform projects)
- Python code can be more clear and expressive (IMHO)
In the long run, I think the python code base will be easier to maintain
and enhance. A rewrite of cogito in python or ruby would be cool.
One advantage that cogito has is that git viewing/browsing tools can
operate directly on cogito repos. But a psychological drawback is the
ongoing confusion between git and cogito. Questions: Would a git-based
tool that writes to the repo (such as StGIT) mess up a cogito repo? Can
you switch a repo between git and cogito or back, at any time?
Mercurial's tags use a radical approach, whereas cogito's are more
conventional. I haven't yet used mercurial's versioned-tags enough yet
to judge whether they are better, worse, or just different.
I am impressed with the vibrancy of the development communities of both
projects. Both are able to serve repos on a plain http server. Both are
easy to use and have decent basic feature sets. Both projects are
developing test suites.
Mostly, I'm thrilled with this new wave of lightweight distributed SCM
systems. Most of the established tools tended to be too heavy on
features and complexity, and have taken a long time to develop. I love
that a single developer or small team can now create a simple but usable
distributed SCM in a couple months.
Kevin