Re: [PATCH] commit: Add -f, --fixes option to add Fixes: line
On Sat, Oct 26, 2013 at 6:34 PM, Josh Triplett wrote:
> + format_commit_message(commit, "Fixes: %h ('%s')\n", sb, &ctx);
What is the value of double wrapping the commit message inside '...'
and then ('...')?
-Tony
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Design for http-pull on repo with packs
> The big problem, however, comes when Jeff (or anyone else) decides to > repack. Then, if you fetch both his repo and Linus', you might end up > with several really big pack files, that mostly overlap. That could > easily mean storing most objects many times, if you don't do some smart > selective un/repacking when fetching. So although it is possible to pack and re-pack at any time, perhaps we need some guidelines? Maybe Linus should just do a re-pack as each 2.6.x release is made (or perhaps just every 2.6.even release if that is too often). It has already been noted offlist that repositories hosted on kernel.org can just copy pack files from Linus (or even better hardlink them). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git: fix trivial warning from show_rename_copy()
apply.c: In function `show_rename_copy':
apply.c:1147: warning: field precision is not type int (arg 3)
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -1143,7 +1143,7 @@ static void show_rename_copy(struct patc
*/
if (old != p->old_name)
printf(" %s %.*s{%s => %s} (%d%%)\n", renamecopy,
- old - p->old_name, p->old_name,
+ (int)(old - p->old_name), p->old_name,
old, new, p->score);
else
printf(" %s %s => %s (%d%%)\n", renamecopy,
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
Linus Torvalds wrote: > I'll happily help anybody who wants to try to write some nice > documentation (answer questions etc), but I'm just not very good at doing > it myself. Here's something that I've been putting together on how I'm using GIT as a Linux subsystem maintainer. I suspect that I'm a bit slap-happy with the "git checkout" commands in the examples below, and perhaps missing some of the _true-git_ ways of doing things. -Tony Linux subsystem maintenance using GIT - My requirements here are to be able to create two public trees: 1) A "test" tree into which patches are initially placed so that they can get some exposure when integrated with other ongoing development. This tree is available to Andrew for pulling into -mm whenever he wants. 2) A "release" tree into which tested patches are moved for final sanity checking, and as a vehicle to send them upstream to Linus (by sending him a "please pull" request.) Note that the period of time that each patch spends in the "test" tree is dependent on the complexity of the change. Since GIT does not support cherry picking, it is not practical to simply apply all patches to the test tree and then pull to the release tree as that would leave trivial patches blocked in the test tree waiting for complex changes to accumulate enough test time to graduate. Back in the BitKeeper days I achieved this my creating small forests of temporary trees, one tree for each logical grouping of patches, and then pulling changes from these trees first to the test tree, and then to the release tree. At first I replicated this in GIT, but then I realised that I could so this far more efficiently using branches inside a single GIT repository. So here is the step-by-step guide how this all works for me. First create your work tree by cloning Linus's public tree: $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work Change directory into the cloned tree you just created $ cd work Make a GIT branch named "linus", and rename the "origin" branch as linus too: $ git checkout -b linus $ mv .git/branches/origin .git/branches/linus The "linus" branch will be used to track the upstream kernel. To update it, you simply run: $ git checkout linus && git pull linus you can do this frequently (as long as you don't have any uncommited work in your tree). If you need to keep track of other public trees, you can add branches for them too: $ git checkout -b another linus $ echo URL-for-another-public-tree > .git/branches/another Now create the branches in which you are going to work, these start out at the current tip of the linus branch. $ git checkout -b test linus $ git checkout -b release linus These can be easily kept up to date by merging from the "linus" branch: $ git checkout test && git resolve test linus "Auto-update from upstream" $ git checkout release && git resolve release linus "Auto-update from upstream" Set up so that you can push upstream to your public tree: $ echo master.kernel.org:/ftp/pub/scm/linux/kernel/git/aegl/linux-2.6.git > .git/branches/origin and then push each of the test and release branches using: $ git push origin test and $ git push origin release Now to apply some patches from the community. Think of a short snappy name for a branch to hold this patch (or related group of patches), and create a new branch from the current tip of the linus branch: $ git checkout -b speed-up-spinlocks linus Now you apply the patch(es), run some tests, and commit the change(s). If the patch is a multi-part series, then you should apply each as a separate commit to this branch. $ ... patch ... test ... commit [ ... patch ... test ... commit ]* When you are happy with the state of this change, you can pull it into the "test" branch in preparation to make it public: $ git checkout test && git resolve test speed-up-spinlocks "Pull speed-up-spinlock changes" It is unlikely that you would have any conflicts here ... but you might if you spent a while on this step and had also pulled new versions from upstream. Some time later when enough time has passed and testing done, you can pull the same branch into the "release" tree ready to go upstream. This is where you see the value of keeping each patch (or patch series) in its own branch. It means that the patches can be moved into the "release" tree in any order. $ git checkout release && git resolve release speed-up-spinlocks "Pull speed-up-spinlock changes" After a while, you will have a number of branches, and despite the well chosen names you picked for each of them, you may forget what they are for, or what status they are in. To get a reminder of what changes are in a specific branch, use: $ git-whatchanged branchname ^linus | git-shortlog To see whether it has already been merged into the test or release branches use: $ git-rev-list branchname ^test or $ git-rev-list branchname ^release [
"git checkout" says Entry blah would be overwritten by merge ...
I'm a little closer to understanding how I got into the situation where I made that ugly commit last week that included 10 files that I didn't want, because I just had another failed merge (but this time I know how to recover :). The approximate sequence of events was: SGI told me one of the pending fixes in my test tree was causing an oops during boot on a whole class of machines. They asked whether it could get into 2.6.13. I agreed it was a good candidate, and ran my script to pull it from its temporary branch (named prarit-bus-sysdata in this case) into my release branch. The script is trivial after the argument sanity checks it just does: $ git checkout release && git resolve release prarit-bus-sysdata "Pull prarit-bus-sysdata into release branch" Only one file was touched by this: arch/ia64/sn/kernel/io_init.c I think that this would have gone through a non-trivial merge as this file had subsequently been touched by another patch, but the merge did complete automatically. Next I pushed the release branch up to kernel.org, asked Linus to pull. I then applied a totally independent patch to a new branch, pulled it to the test branch, and pushed to kernel.org ... net effect was that my tree ended up in "git checkout test" state. Later I noticed that Linus had pulled from my tree (and from other trees too), so I pulled his latest tree down from kernel.org using: $ git checkout linus && git pull linus Then I tried to update my test branch with these changes using: $ git checkout test && git resolve test linus "Auto-update from upstream" This spat out these messages: fatal: Entry 'arch/ia64/sn/kernel/io_init.c' would be overwritten by merge. Cannot merge. Trying to merge 8065e2... into cde7fe... fatal: Entry 'arch/ia64/hp/sim/boot/boot_head.S' would be overwritten by merge. Cannot merge. There is one obvious bug here: "git checkout test" failed with the first error (from its invocation of git-read-tree) ... but returned an exit status of 0, so my script went ahead and tried to do the resolve, which the && should have prevented. The less obvious (i.e. I have no clue what I did wrong) thing is why the "git checkout" had a problem with this file. Yes, it had been touched earlier ... but in a way that should have left the index up to date. And two subsequent "git checkout" commands had switched first to the test branch, and then to the linus branch without a complaint. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Fix git-checkout-script exit status
Sometimes the git-read-tree in git-checkout-script fails for me. Make sure that the failed status is passed up to caller. Signed-off-by: Tony Luck <[EMAIL PROTECTED]> --- diff --git a/git-checkout-script b/git-checkout-script --- a/git-checkout-script +++ b/git-checkout-script @@ -72,4 +72,6 @@ if [ "$?" -eq 0 ]; then fi [ "$branch" ] && ln -sf "refs/heads/$branch" "$GIT_DIR/HEAD" rm -f "$GIT_DIR/MERGE_HEAD" +else + exit 1 fi - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
baffled again
So I have another anomaly in my GIT tree. A patch to
back out a bogus change to arch/ia64/hp/sim/boot/bootloader.c
in my release branch at commit
62d75f3753647656323b0365faa43fc1a8f7be97
appears to have been lost when I merged the release branch to
the test branch at commit
0c3e091838f02c537ccab3b6e8180091080f7df2
So now this file still has this:
/* SSC_WAIT_COMPLETION appears to want this large alignment. gcc < 4
* seems to give it by default, however gcc > 4 is smarter and may
* not.
*/
struct disk_stat {
int fd;
unsigned count;
} __attribute__ ((aligned (16)));
in the test branch, when I think the comment and __attribute__
should have been backout out.
-Tony
Tree is at rsync://rsync.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
I'm at home, and too lazy to log in to work to look at my tree. But I have a theory as to what went wrong for me. At the start I had a file, same contents in test and release branch. I applied a patch to release, and pulled to test. So the contents are still the same, both with the patch applied. Next, I was given a better patch (the first one just masked the real problem and happened to make the symptoms go away). This patch touches a completely different file. So I applied a patch to revert the change in release, and the new patch. Now ... when I try to merge release into test, my guess is that GIT is looking at the common ancestor before I touched anything. So when it compares the current state of this file it sees that I have the bad patch in the test tree, and the release tree has the "original" version (which has had the patch applied and reverted ... so the contents are back at the original state). So GIT decides that the test branch has had a patch, and the release branch hasn't ... and so it merges by keeping the version in test. Plausible? -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: baffled again
> * Even if it does always choose the nicer choice of the two, >Tony was lucky (no pun intended). Rather, we were lucky that >Tony was observant. A careless merger may well have easily >missed this mismerge (from the human point of view). Actually I can't take credit here. This was a case of the "many-eyes" of open source working at its finest ... someone e-mailed me and told me that I should have backed out the old patch before applying the new one. While typing the e-mail to say that I already had in the release branch, I found the problem that it had been "lost" in the merge into the test branch. But this is a good reminder that merging is not a precise science, and there is more than one plausible merge in many situations ... and while GIT will pick the one that you want far more often than not, there is the possibility that it will surprise you. Maybe there should be a note to this effect in the tutorial. Git is not magic, nor is it imbued with DWIM technology. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
cache status after git pull
>* When the branch head pointed by $GIT_DIR/HEAD changes while > the index file and working tree are looking the other way > (e.g. somebody pushed into your repository, or you ran "git > fetch" to update the ref your working tree is on), "git > checkout" without -f gets confused. Figure out a good way to > handle this. Aha ... is this the problem that caught me out last week (when I ended up with 10 extra files attached to one of my commits)? At the time the blame was placed on a failed merge not being backed out correctly. But I only had the failed merge because "get checkout" had failed to switch branches (and not provided an exit code to stop my script from trying the merge). Here's what I did this morning. 1) Updated my "linus" branch: $ git checkout linus && git pull linus This appeared to work just fine ... except that when I check the status of my tree I see: $ git status # # Updated but not checked in: # (will commit) # # modified: arch/ia64/pci/pci.c # modified: arch/ppc64/kernel/setup.c # modified: arch/sparc64/kernel/pci.c # modified: arch/x86_64/defconfig # modified: drivers/block/cfq-iosched.c # modified: include/asm-m68k/page.h # modified: kernel/cpuset.c # # # On branch refs/heads/linus Which looks like a set of landmines just waiting for me to step on them! Today these didn't bite me. "git checkout release" worked and switched to my release branch (and git status went back to saying "nothing to commit"). But in the past I think this is the situation that has caused "git checkout" to fail with the "fatal: Entry 'blah' would be overwritten by merge. Cannot merge." -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] update howto/using-topic-branches.txt
Various updates and cleanups for my howto on using branches in GIT as a Linux subsystem maintainer. Three categories of changes: 1) Updates for new features in GIT 0.99.5 2) Changes to use "git fetch" rather than "git pull" to update local linus branch. 3) Cleanups suggested by Len Brown Signed-off-by: Tony Luck <[EMAIL PROTECTED]> --- diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt --- a/Documentation/howto/using-topic-branches.txt +++ b/Documentation/howto/using-topic-branches.txt @@ -5,12 +5,10 @@ Subject: Some tutorial text (was git/cog Here's something that I've been putting together on how I'm using GIT as a Linux subsystem maintainer. -I suspect that I'm a bit slap-happy with the "git checkout" commands in -the examples below, and perhaps missing some of the _true-git_ ways of -doing things. - -Tony +Last updated w.r.t. GIT 0.99.5 + Linux subsystem maintenance using GIT - @@ -48,24 +46,38 @@ Change directory into the cloned tree yo $ cd work -Make a GIT branch named "linus", and rename the "origin" branch as linus too: +Set up a remotes file so that you can fetch the latest from Linus' master +branch into a local branch named "linus": + + $ cat > .git/remotes/linus + URL: rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git + Pull: master:linus + ^D - $ git checkout -b linus - $ mv .git/branches/origin .git/branches/linus +and create the linus branch: + + $ git branch linus The "linus" branch will be used to track the upstream kernel. To update it, you simply run: - $ git checkout linus && git pull linus + $ git fetch linus + +you can do this frequently (and it should be safe to do so with pending +work in your tree, but perhaps not if you are in mid-merge). -you can do this frequently (as long as you don't have any uncommited work -in your tree). +If you need to keep track of other public trees, you can add remote branches +for them too: -If you need to keep track of other public trees, you can add branches for -them too: + $ git branch another + $ cat > .git/remotes/another + URL: ... insert URL here ... + Pull: name-of-branch-in-this-remote-tree:another + ^D - $ git checkout -b another linus - $ echo URL-for-another-public-tree > .git/branches/another +and run: + + $ git fetch another Now create the branches in which you are going to work, these start out at the current tip of the linus branch. @@ -78,15 +90,25 @@ These can be easily kept up to date by m $ git checkout test && git resolve test linus "Auto-update from upstream" $ git checkout release && git resolve release linus "Auto-update from upstream" -Set up so that you can push upstream to your public tree: +Set up so that you can push upstream to your public tree (you need to +log-in to the remote system and create an empty tree there before the +first push). - $ echo master.kernel.org:/ftp/pub/scm/linux/kernel/git/aegl/linux-2.6.git > .git/branches/origin + $ cat > .git/remotes/mytree + URL: master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git + Push: release + Push: test + ^D -and then push each of the test and release branches using: +and the push both the test and release trees using: - $ git push origin test -and - $ git push origin release + $ git push mytree + +or push just one of the test and release branches using: + + $ git push mytree test +or + $ git push mytree release Now to apply some patches from the community. Think of a short snappy name for a branch to hold this patch (or related group of @@ -169,9 +191,9 @@ test|release) git checkout $1 && git resolve $1 linus "Auto-update from upstream" ;; linus) - before=$(cat .git/HEAD) - git checkout linus && git pull linus - after=$(cat .git/HEAD) + before=$(cat .git/refs/heads/linus) + git fetch linus + after=$(cat .git/refs/heads/linus) if [ $before != $after ] then git-whatchanged $after ^$before | git-shortlog - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] git: remove redundant getenv() in init-db
From: Tony Luck <[EMAIL PROTECTED]>
init-db calls getenv(DB_ENVIRONMENT) twice. Once should be enough.
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
---
init-db.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- init-db.c
+++ init-db.c 2005-04-14 11:01:52.0 -0700
@@ -7,7 +7,7 @@
int main(int argc, char **argv)
{
- char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
+ char *sha1_dir, *path;
int len, i;
if (mkdir(".git", 0755) < 0) {
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Date handling.
> OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's > what you're going to want to feed it. We store seconds since UTC epoch, > we add the author's or committer's timezone as auxiliary data so that > dates can be pretty-printed in the original timezone later if anyone > cares. With a UTC date, why would anyone care in which timezone the commit was made? Any pretty printing would most likely be prettiest if it is done relative to the timezone of the person looking at the commit record, not the person who created the record. If we do need the timezone, then I think we also need the latitude of the committer too, so that we know whether to interpret "July" as summer or winter :-) -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git for beginners
If the mechanics of git still have you stumped, then here are a couple of
examples of using the really low level tools to do some basic operations.
In real life you would have higher level wrappers around these tools so
that you don't have to remember to update .git/HEAD with the new SHA1 after
you do a commit ... but knowing what the low-level tools do may help you
understand what is going on.
-Tony
$ # How to create your own project from scratch
$ mkdir tmp
$ cd tmp
$ # Create initial empty git filesystem
$ init-db
defaulting to private storage area
$ # Look around ... lots of directories, but no files yet
$ ls -l .git
total 4
drwxr-xr-x 258 aegl aegl 4096 Apr 14 14:54 objects
$ ls .git/objects/
00 09 12 1b 24 2d 36 3f 48 51 5a 63 6c 75 7e 87 90 99 a2 ab
b4 bd c6 cf d8 e1 ea f3 fc
01 0a 13 1c 25 2e 37 40 49 52 5b 64 6d 76 7f 88 91 9a a3 ac
b5 be c7 d0 d9 e2 eb f4 fd
02 0b 14 1d 26 2f 38 41 4a 53 5c 65 6e 77 80 89 92 9b a4 ad
b6 bf c8 d1 da e3 ec f5 fe
03 0c 15 1e 27 30 39 42 4b 54 5d 66 6f 78 81 8a 93 9c a5 ae
b7 c0 c9 d2 db e4 ed f6 ff
04 0d 16 1f 28 31 3a 43 4c 55 5e 67 70 79 82 8b 94 9d a6 af
b8 c1 ca d3 dc e5 ee f7
05 0e 17 20 29 32 3b 44 4d 56 5f 68 71 7a 83 8c 95 9e a7 b0
b9 c2 cb d4 dd e6 ef f8
06 0f 18 21 2a 33 3c 45 4e 57 60 69 72 7b 84 8d 96 9f a8 b1
ba c3 cc d5 de e7 f0 f9
07 10 19 22 2b 34 3d 46 4f 58 61 6a 73 7c 85 8e 97 a0 a9 b2
bb c4 cd d6 df e8 f1 fa
08 11 1a 23 2c 35 3e 47 50 59 62 6b 74 7d 86 8f 98 a1 aa b3
bc c5 ce d7 e0 e9 f2 fb
$ find . -type f
$
$ # create some files ready to check in ... use a subdirectory just to show
$ # how subdirs work
$ mkdir src
$ cat > src/hello.c
#include
main()
{
printf("Hello, world!\n");
}
$ cat > Makefile
hello: src/hello.c
cc -o hello -O src/hello.c
$ # Now add these two files to the cache, ready for checkin (use the
$ # "--add" option because these files are new)
$ update-cache --add Makefile src/hello.c
$ # save a tree listing these files
$ write-tree
eab75ce51622aa312bb0b03572d43769f420c347
$ # commit the change. We tell it the SHA1 of the tree we just made
$ commit-tree eab75ce51622aa312bb0b03572d43769f420c347
Committing initial tree eab75ce51622aa312bb0b03572d43769f420c347
First revision of the hello system.
0107d57e748b2f01601adb6749a03aed7b3f5a84
$ # Save the SHA1 for that changeset ... we need it later
$ echo 0107d57e748b2f01601adb6749a03aed7b3f5a84 > .git/HEAD
$
$ # Take a look at the changeset
$ cat-file commit 0107d57e748b2f01601adb6749a03aed7b3f5a84
tree eab75ce51622aa312bb0b03572d43769f420c347
author Tony Luck <[EMAIL PROTECTED]> Thu Apr 14 14:57:27 2005
committer Tony Luck <[EMAIL PROTECTED]> Thu Apr 14 14:57:27 2005
First revision of the hello system.
$ # And dig into the tree we saved
$ ls-tree eab75ce51622aa312bb0b03572d43769f420c347
100664 blob3a7a1c51dbc62797d6c903203de44cc6a734c05cMakefile
4 treeba103f91defa4b3885b826d6630a055f27800398src
$ # see that git automatically made a tree for the "src" subdir, look at it
$ ls-tree ba103f91defa4b3885b826d6630a055f27800398
100664 blob522fff361ad5c07351479ea8504b7c370d189524hello.c
$ # This blob is our src/hello.c file
$ cat-file blob 522fff361ad5c07351479ea8504b7c370d189524
#include
main()
{
printf("Hello, world!\n");
}
$ # Look at all the files we have now, a blob for each file, a
$ # pair of tree objects for the directory and subdir, and a lone
$ # changeset.
$ find .git -type f
.git/index
.git/objects/01/07d57e748b2f01601adb6749a03aed7b3f5a84
.git/objects/ba/103f91defa4b3885b826d6630a055f27800398
.git/objects/ea/b75ce51622aa312bb0b03572d43769f420c347
.git/objects/52/2fff361ad5c07351479ea8504b7c370d189524
.git/objects/3a/7a1c51dbc62797d6c903203de44cc6a734c05c
.git/HEAD
$ # Now make a change
$ ed src/hello.c
59
$i
return 0;
.
w
70
q
$ # We need to tell .git/index which file(s) are going to be
$ # in this changeset. Don't need "--add" option because we are
$ # changing a file that already exists
$ update-cache src/hello.c
$ # Now we can write a new tree incorporating the change
$ write-tree
8f5ba0203e31204c5c052d995a5b4449226bcfb5
$ # and finally create a changeset ... this time we tell commit that
$ # the parent of this change is the previous change
$ commit-tree 8f5ba0203e31204c5c052d995a5b4449226bcfb5 -p `cat .git/HEAD`
Fix hello program to return successful exit code.
5403689e0c29607f57da8f751d4ba40637134e87
$ # save the new changeset in .git/HEAD
$ echo 5403689e0c29607f57da8f751d4ba40637134e87 > .git/HEAD
$ # walk the tree from HEAD to the new version of hello.c
$ cat-file commit 5403689e0c29607f57da8f751d4ba40637134e87
tree 8f5ba0203e31204c5c052d995a5b4449226bcfb
Re: trying to figure out this git thing - some questions
>I'm trying to understand how it works and I'll appreciate if someone could >help. >1. git uses object abstraction for the different types and so >everything is in one directory (objects). From what I've seen in the >implementation, the different kind of objects are not of the same type >(there aren't any operations which work on two different types) and >thus in each step when an object is used its type is verified. >What's the benefit of having them all in the same tree? An alternative >would be to separate the different object types into different >directories which trivially allows getting a list of all commits, or >trees or blobs. If all the commits were in ".git/objects/commits/xx/x", etc. then every time git opened a file the kernel would have one extra level of directory to walk to get to the file ... so opens would be fractionally slower. There is no normal-use upside to this overhead. While it would be easier to find all the blobs if they were kept separate from the trees and commits, there isn't any time that we'd ever want to scan through just the blobs. Git never goes searching through a directory opening files to see what they are (exception: fsck-cache does scan all objects). >2. A commit can have more than one parent. Can anyone draw an example >of such a case? When do we get a commit graph which is not linear? When a merge happens. E.g. I take a snapshot of Linus' tree when a file is at version 1.2. We both make a couple of changes before I ask him to pull from my tree: 1.1 -> 1.2 -> 1.3 -> 1.4 -> 1.5 \ / 1.2.1 -> 1.2.2 ---/ The changeset to create 1.5 has two parents ... the changeset that Linus made to create 1.4, and the changeset that I made to create 1.2.2 >3. How does git handle binary files? I guess it doesn't really care if >it's binary or text, but how would the diff and merge scripts handle >them? Yes, git doesn't care. Diff is somewhat smart about noticing that its input files aren't text: $ diff /bin/cat /bin/ls Binary files /bin/cat and /bin/ls differ But in general this will be an issue for the SCM layer if there are binary files checked into the tree. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Get commits from remote repositories by HTTP
On 4/16/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote: > +buffer = read_sha1_file(sha1, type, &size); You never free this buffer. It would also be nice if you saved "tree" objects in some temporary file and did not install them until after you had fetched all the blobs and trees that this tree references. Then if your connection is interrupted you can just restart it. Otherwise this looks really nice. I was going to script something similar using "wget" ... but that would have made zillions of seperate connections. Not so kind to the server. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Get commits from remote repositories by HTTP
>How about building a file list and doing a batch download via 'wget -i
>/tmp/foo'? A quick test (on my ancient wget-1.7) indicates that it reuses
>connectionss when successive URLs point to the same server.
Here's a script that does just that. So there is a burst of individual
wget commands to get HEAD, the top commit object, and all the tree
objects. The just one to get all the missing blobs.
Subsequent runs will do far less work as many of the tree objects will
not have changed, so we don't descend into any tree that we already have.
-Tony
Not a patch ... it is a whole file. I called it "git-wget", but it might
also want to be called "git-pulltop".
Signed-off-by: Tony Luck <[EMAIL PROTECTED]>
-- script starts here -
#!/bin/sh
# Copyright (C) 2005 Tony Luck
REMOTE=http://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/
rm -rf .gittmp
# set up a temp git repository so that we can use cat-file and ls-tree on the
# objects we pull without installing them into our tree. This allows us to
# restart if the download is interrupted
mkdir .gittmp
cd .gittmp
init-db
wget -q $REMOTE/HEAD
if cmp -s ../.git/HEAD HEAD
then
echo Already have HEAD = `cat ../.git/HEAD`
cd ..
rm -rf .gittmp
exit 0
fi
sha1=`cat HEAD`
sha1file=${sha1:0:2}/${sha1:2}
if [ -f ../.git/objects/$sha1file ]
then
echo Already have most recent commit. Update HEAD to $sha1
cd ..
rm -rf .gittmp
exit 0
fi
wget -q $REMOTE/objects/$sha1file -O .git/objects/$sha1file
treesha1=`cat-file commit $sha1 | (read tag tree ; echo $tree)`
get_tree()
{
treesha1file=${1:0:2}/${1:2}
if [ -f ../.git/objects/$treesha1file ]
then
return
fi
wget -q $REMOTE/objects/$treesha1file -O .git/objects/$treesha1file
ls-tree $1 | while read mode tag sha1 name
do
subsha1file=${sha1:0:2}/${sha1:2}
if [ -f ../.git/objects/$subsha1file ]
then
continue
fi
if [ $mode = 4 ]
then
get_tree $sha1 `expr $2 + 1`
else
echo objects/$subsha1file >> needbloblist
fi
done
}
# get all the tree objects to our .gittmp area, and create list of needed blobs
get_tree $treesha1
# now get the blobs
cd ../.git
if [ -s ../.gittmp/needbloblist ]
then
wget -q -r -nH --cut-dirs=6 --base=$REMOTE -i ../.gittmp/needbloblist
fi
# Now we have the blobs, move the trees and commit from .gitttmp
cd ../.gittmp/.git/objects
find ?? -type f -print | while read f
do
mv $f ../../../.git/objects/$f
done
# update HEAD
cd ../..
mv HEAD ../.git
cd ..
rm -rf .gittmp
-- script ends here -
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Get commits from remote repositories by HTTP
>Not a patch ... it is a whole file. I called it "git-wget", but it might >also want to be called "git-pulltop". It's been pointed out to me that I based this script on a pre-historic version of ls-tree from sometime last week. Modern versions print the mode with %06o so there is a leading 0 on the mode for a directory. Just change if [ $mode = 4 ] to if [ $mode = 04 ] to fix it. The script might also be useful for anyone behind a firewall that blocks rsync transfers. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Get commits from remote repositories by HTTP
> ...and this is precisely why ls-tree actually outputs those "blob" and
> "tree" tags. ;-)
Doh!
Here's a fresh copy with "if [ $tag = tree ]". I just used it to pull
from Linus into an "empty" directory (just ran init-db to make the .git
.git/objects and .git/objects/xx directories).
-Tony
#!/bin/bash
# Copyright (C) 2005 Tony Luck
REMOTE=http://www.kernel.org/pub/linux/kernel/people/torvalds/linux-2.6.git/
rm -rf .gittmp
# set up a temp git repository so that we can use cat-file and ls-tree on the
# objects we pull without installing them into our tree. This allows us to
# restart if the download is interrupted
mkdir .gittmp
cd .gittmp
init-db
wget -q $REMOTE/HEAD
if cmp -s ../.git/HEAD HEAD
then
echo Already have HEAD = `cat ../.git/HEAD`
cd ..
rm -rf .gittmp
exit 0
fi
sha1=`cat HEAD`
sha1file=${sha1:0:2}/${sha1:2}
if [ -f ../.git/objects/$sha1file ]
then
echo Already have most recent commit. Update HEAD to $sha1
cd ..
rm -rf .gittmp
exit 0
fi
wget -q $REMOTE/objects/$sha1file -O .git/objects/$sha1file
treesha1=`cat-file commit $sha1 | (read tag tree ; echo $tree)`
get_tree()
{
treesha1file=${1:0:2}/${1:2}
if [ -f ../.git/objects/$treesha1file ]
then
return
fi
wget -q $REMOTE/objects/$treesha1file -O .git/objects/$treesha1file
ls-tree $1 | while read mode tag sha1 name
do
subsha1file=${sha1:0:2}/${sha1:2}
if [ -f ../.git/objects/$subsha1file ]
then
continue
fi
if [ $tag = tree ]
then
get_tree $sha1 `expr $2 + 1`
else
echo objects/$subsha1file >> needbloblist
fi
done
}
# get all the tree objects to our .gittmp area, and create list of needed blobs
get_tree $treesha1
# now get the blobs
cd ../.git
if [ -s ../.gittmp/needbloblist ]
then
wget -q -r -nH --cut-dirs=6 --base=$REMOTE -i ../.gittmp/needbloblist
fi
# Now we have the blobs, move the trees and commit from .gitttmp
cd ../.gittmp/.git/objects
find ?? -type f -print | while read f
do
mv $f ../../../.git/objects/$f
done
# update HEAD
cd ../..
mv HEAD ../.git
cd ..
rm -rf .gittmp
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [3/5] Add http-pull
On Wed, 20 Apr 2005, Brad Roberts wrote: > How about fetching in the inverse order. Ie, deepest parents up towards > current. With that method the repository is always self consistent, even > if not yet current. Daniel Barkalow replied: > You don't know the deepest parents to fetch until you've read everything > more recent, since the history you'd have to walk is the history you're > downloading. You "just" need to defer adding tree/commit objects to the repository until after you have inserted all objects on which they depend. That's what my "wget" based version does ... it's very crude, in that it loads all tree & commit objects into a temporary repository (.gittmp) ... since you can only use "cat-file" and "ls-tree" on things if they live in objects/xx/xxx..xxx The blobs can go directly into the real repo (but to be really safe you'd have to ensure that the whole blob had been pulled from the network before inserting it ... it's probably a good move to validate everything that you pull from the outside world too). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Where'd my GIT tree go?
http://www.kernel.org/git has stopped showing my linux-2.6 tree (the "to Linus" one, my "test-2.6" tree is still there). This is probably my fault ... but I'm not sure exactly why. Here's what I did. Last Thursday I applied a set of patches ... and my "apply" script choked on one of them. Some casual inspection convinced me that the changes had been applied, and I pushed the tree up to kernel.org. But I was wrong, the 2nd out od a series of six was all messed up. And I'd applied a couple more patches on top of that. Since none of this had been pulled by Linus, I thought I'd clean it up and apologise to anyone who had pulled from my tree. So I backed HEAD up to the last good commit. Re-applied the changes with a fixed version of the script, and then expected to find some detritus from the first application in .git/objects. But "git-fsck-cache --unreachable ..." only complained about the 2.6.11 tag/tree. Odd. Then I pushed up to master.kernel.org ... and an hour later when the mirrors did their thing, git-web stopped showing my tree. HEAD is still a symlink to refs/heads/master. And that has the SHA1 of my most recent commit ... which is present in .git/objects. So what's wrong??? -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Where'd my GIT tree go?
On 7/6/05, Jon Seymour <[EMAIL PROTECTED]> wrote: > Ok, you asked for it: > > ...the GIT bucket. > > jon. > > ... ducks for cover ... Groan ... as well you should. My tree has re-appeared now. Thanks to whoever fixed it. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Cogito-0.12
> > So, what _is_ then the way to pull now, actually? If we use rsync, won't > > we end up with having the objects we previous had twice now? > > Rsync works fine. You can either unpack the pack you get, or, if you > prefer, just run > > git-prune-packed cg-update from a local repo that contains packs is broken though :-( Also "git-fsck-cache" in a repo that is fully packed complains: fatal: No default references -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Cogito-0.12
> > cg-update from a local repo that contains packs is broken though :-(
>
> Is this with cg-0.12? The most recent release should be happy with packs.
Yes ... I pulled, built and installed the latest cogito this afternoon
before trying
to touch anything involving packs. cg-version says:
cogito-0.12 (b21855b8734ca76ea08c0c17e4a204191b6e3add)
This is what happens ("linus" is a local branch just pulled from kernel.org,
so it just contains one pack file and its index).
$ cg-update linus
`/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'
does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69
798458e067
Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067
while processing commit .
cg-pull: objects pull failed
If I try it again, it thinks things are up to date (since it
mistakenly updated the
.git/refs/heads/linus), but then fails to apply (since it doesn't have
the objects
it needs).
-Tony
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linus kernel tree corrupt?
On 7/8/05, Jon Smirl <[EMAIL PROTECTED]> wrote: > What happened in this session... Linus has "packed" his GIT tree ... and now http-pull doesn't work. rsync still does (provided you have a new enough cogito). -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
