* Re: [PATCH] Use $Id$ as the ident attribute keyword rather than $ident$ to be consistent with other VCSs
From: Junio C Hamano @ 2007-05-14 14:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <46486FE6.16A82D9A@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Andy Parkins wrote:
>> I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
>> monotone has $Id$ on its wishlist. I can't think of a good reason not
>> to stick with the de-facto standard and call ours $Id$ instead of
>> $ident$.
>
> I very much agree. I wondered why it was named $ident$ in the first
> place. Now that I'm not alone, I thought I'd throw my 2 cents in...
My take when I did the $ident$ stuff on this issue was quite the
opposite. CVS "$Id$" means quite a different thing (pathname,
per-file revision number, date, and status) and it would not be
right to overwrite it with $ident$ which does not record any of
those "context sensitive" information.
I did not think other systems making that mistake was not an
excuse for us to do so, but on the other hand, if the users of
those other systems are happy to lose the information from CVS
then perhaps the users do want $Id$.
Obviously I do not care much about this feature and I have not
look at Andy's patch too deeply yet, but in any case I think the
inverse conversion needs to be modified to match it, if it
hasn't been done so.
^ permalink raw reply
* user-manual patches
From: J. Bruce Fields @ 2007-05-14 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since Johannes Schindelin said he'd be offline I thought I'd go ahead
and pick up his source code overview for the user manual. I tried to
address your comments in a subsequent patch.
Also rework some of the glossary definitions, start moving some of
Documentation/howto into the manual, revise the preface a little, and
move the quick-start to an appendix.
Also available in the maint branch of my git repo:
git://linux-nfs.org/~bfields/git.git maint
--b.
^ permalink raw reply
* [PATCH 02/10] user-manual: revise birdseye-view chapter
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields, Johannes Schindelin
In-Reply-To: <11791560893572-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
Some revisions suggested by Junio along with some minor style fixes and
one compile fix (asterisks need escaping).
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 43 +++++++++++++++++++---------------------
1 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index bac9660..7abdc3e 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3161,8 +3161,12 @@ contrast, running "git prune" while somebody is actively changing the
repository is a *BAD* idea).
[[birdview-on-the-source-code]]
-A birdview on Git's source code
------------------------------
+A birds-eye view of Git's source code
+-------------------------------------
+
+It is not always easy for new developers to find their way through Git's
+source code. This section gives you a gentle guidance to show where to
+start.
While Git's source code is quite elegant, it is not always easy for
new developers to find their way through it. A good idea is to look
@@ -3171,33 +3175,26 @@ _e83c5163316f89bfbde7d9ab23ca2e25604af290_ (also known as _v0.99~954_).
Tip: you can see what files are in there with
+A good place to start is with the contents of the initial commit, with:
+
----------------------------------------------------
-$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:
+$ git checkout e83c5163
----------------------------------------------------
-and look at those files with something like
-
------------------------------------------------------------
-$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:cache.h
------------------------------------------------------------
-
-Be sure to read the README in that revision _after_ you are familiar with
-the terminology (<<glossary>>), since the terminology has changed a little
-since then. For example, we call the things "commits" now, which are
-described in that README as "changesets".
+The initial revision lays the foundation for almost everything git has
+today, but is small enough to read in one sitting.
-Actually a lot of the structure as it is now can be explained by that
-initial commit.
+Note that terminology has changed since that revision. For example, the
+README in that revision uses the word "changeset" to describe what we
+now call a <<def_commit_object,commit>>.
-For example, we do not call it "cache" any more, but "index", however, the
+Also, we do not call it "cache" any more, but "index", however, the
file is still called `cache.h`. Remark: Not much reason to change it now,
especially since there is no good single name for it anyway, because it is
basically _the_ header file which is included by _all_ of Git's C sources.
-If you grasp the ideas in that initial commit (it is really small and you
-can get into it really fast, and it will help you recognize things in the
-much larger code base we have now), you should go on skimming `cache.h`,
-`object.h` and `commit.h` in the current version.
+If you grasp the ideas in that initial commit, you should check out a
+more recent version and skim `cache.h`, `object.h` and `commit.h`.
In the early days, Git (in the tradition of UNIX) was a bunch of programs
which were extremely simple, and which you used in scripts, piping the
@@ -3320,11 +3317,11 @@ Two things are interesting here:
negative numbers in case of different errors -- and 0 on success.
- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
- char *`, but is actually expected to be a pointer to `unsigned
+ char \*`, but is actually expected to be a pointer to `unsigned
char[20]`. This variable will contain the 160-bit SHA-1 of the given
- commit. Note that whenever a SHA-1 is passed as "unsigned char *", it
+ commit. Note that whenever a SHA-1 is passed as `unsigned char \*`, it
is the binary representation, as opposed to the ASCII representation in
- hex characters, which is passed as "char *".
+ hex characters, which is passed as `char *`.
You will see both of these things throughout the code.
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 01/10] Add a birdview-on-the-source-code section to the user manual
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
J. Bruce Fields suggested that my reply should be included in the
user manual, and there was nothing of an outcry, so here it is,
not 2 months later.
It includes modifications as suggested by J. Bruce Fields, Karl
Hasselström and Daniel Barkalow.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Documentation/user-manual.txt | 219 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 219 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 13db969..bac9660 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3160,6 +3160,225 @@ confusing and scary messages, but it won't actually do anything bad. In
contrast, running "git prune" while somebody is actively changing the
repository is a *BAD* idea).
+[[birdview-on-the-source-code]]
+A birdview on Git's source code
+-----------------------------
+
+While Git's source code is quite elegant, it is not always easy for
+new developers to find their way through it. A good idea is to look
+at the contents of the initial commit:
+_e83c5163316f89bfbde7d9ab23ca2e25604af290_ (also known as _v0.99~954_).
+
+Tip: you can see what files are in there with
+
+----------------------------------------------------
+$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:
+----------------------------------------------------
+
+and look at those files with something like
+
+-----------------------------------------------------------
+$ git show e83c5163316f89bfbde7d9ab23ca2e25604af290:cache.h
+-----------------------------------------------------------
+
+Be sure to read the README in that revision _after_ you are familiar with
+the terminology (<<glossary>>), since the terminology has changed a little
+since then. For example, we call the things "commits" now, which are
+described in that README as "changesets".
+
+Actually a lot of the structure as it is now can be explained by that
+initial commit.
+
+For example, we do not call it "cache" any more, but "index", however, the
+file is still called `cache.h`. Remark: Not much reason to change it now,
+especially since there is no good single name for it anyway, because it is
+basically _the_ header file which is included by _all_ of Git's C sources.
+
+If you grasp the ideas in that initial commit (it is really small and you
+can get into it really fast, and it will help you recognize things in the
+much larger code base we have now), you should go on skimming `cache.h`,
+`object.h` and `commit.h` in the current version.
+
+In the early days, Git (in the tradition of UNIX) was a bunch of programs
+which were extremely simple, and which you used in scripts, piping the
+output of one into another. This turned out to be good for initial
+development, since it was easier to test new things. However, recently
+many of these parts have become builtins, and some of the core has been
+"libified", i.e. put into libgit.a for performance, portability reasons,
+and to avoid code duplication.
+
+By now, you know what the index is (and find the corresponding data
+structures in `cache.h`), and that there are just a couple of object types
+(blobs, trees, commits and tags) which inherit their common structure from
+`struct object`, which is their first member (and thus, you can cast e.g.
+`(struct object *)commit` to achieve the _same_ as `&commit->object`, i.e.
+get at the object name and flags).
+
+Now is a good point to take a break to let this information sink in.
+
+Next step: get familiar with the object naming. Read <<naming-commits>>.
+There are quite a few ways to name an object (and not only revisions!).
+All of these are handled in `sha1_name.c`. Just have a quick look at
+the function `get_sha1()`. A lot of the special handling is done by
+functions like `get_sha1_basic()` or the likes.
+
+This is just to get you into the groove for the most libified part of Git:
+the revision walker.
+
+Basically, the initial version of `git log` was a shell script:
+
+----------------------------------------------------------------
+$ git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | \
+ LESS=-S ${PAGER:-less}
+----------------------------------------------------------------
+
+What does this mean?
+
+`git-rev-list` is the original version of the revision walker, which
+_always_ printed a list of revisions to stdout. It is still functional,
+and needs to, since most new Git programs start out as scripts using
+`git-rev-list`.
+
+`git-rev-parse` is not as important any more; it was only used to filter out
+options that were relevant for the different plumbing commands that were
+called by the script.
+
+Most of what `git-rev-list` did is contained in `revision.c` and
+`revision.h`. It wraps the options in a struct named `rev_info`, which
+controls how and what revisions are walked, and more.
+
+The original job of `git-rev-parse` is now taken by the function
+`setup_revisions()`, which parses the revisions and the common command line
+options for the revision walker. This information is stored in the struct
+`rev_info` for later consumption. You can do your own command line option
+parsing after calling `setup_revisions()`. After that, you have to call
+`prepare_revision_walk()` for initialization, and then you can get the
+commits one by one with the function `get_revision()`.
+
+If you are interested in more details of the revision walking process,
+just have a look at the first implementation of `cmd_log()`; call
+`git-show v1.3.0~155^2~4` and scroll down to that function (note that you
+no longer need to call `setup_pager()` directly).
+
+Nowadays, `git log` is a builtin, which means that it is _contained_ in the
+command `git`. The source side of a builtin is
+
+- a function called `cmd_<bla>`, typically defined in `builtin-<bla>.c`,
+ and declared in `builtin.h`,
+
+- an entry in the `commands[]` array in `git.c`, and
+
+- an entry in `BUILTIN_OBJECTS` in the `Makefile`.
+
+Sometimes, more than one builtin is contained in one source file. For
+example, `cmd_whatchanged()` and `cmd_log()` both reside in `builtin-log.c`,
+since they share quite a bit of code. In that case, the commands which are
+_not_ named like the `.c` file in which they live have to be listed in
+`BUILT_INS` in the `Makefile`.
+
+`git log` looks more complicated in C than it does in the original script,
+but that allows for a much greater flexibility and performance.
+
+Here again it is a good point to take a pause.
+
+Lesson three is: study the code. Really, it is the best way to learn about
+the organization of Git (after you know the basic concepts).
+
+So, think about something which you are interested in, say, "how can I
+access a blob just knowing the object name of it?". The first step is to
+find a Git command with which you can do it. In this example, it is either
+`git show` or `git cat-file`.
+
+For the sake of clarity, let's stay with `git cat-file`, because it
+
+- is plumbing, and
+
+- was around even in the initial commit (it literally went only through
+ some 20 revisions as `cat-file.c`, was renamed to `builtin-cat-file.c`
+ when made a builtin, and then saw less than 10 versions).
+
+So, look into `builtin-cat-file.c`, search for `cmd_cat_file()` and look what
+it does.
+
+------------------------------------------------------------------
+ git_config(git_default_config);
+ if (argc != 3)
+ usage("git-cat-file [-t|-s|-e|-p|<type>] <sha1>");
+ if (get_sha1(argv[2], sha1))
+ die("Not a valid object name %s", argv[2]);
+------------------------------------------------------------------
+
+Let's skip over the obvious details; the only really interesting part
+here is the call to `get_sha1()`. It tries to interpret `argv[2]` as an
+object name, and if it refers to an object which is present in the current
+repository, it writes the resulting SHA-1 into the variable `sha1`.
+
+Two things are interesting here:
+
+- `get_sha1()` returns 0 on _success_. This might surprise some new
+ Git hackers, but there is a long tradition in UNIX to return different
+ negative numbers in case of different errors -- and 0 on success.
+
+- the variable `sha1` in the function signature of `get_sha1()` is `unsigned
+ char *`, but is actually expected to be a pointer to `unsigned
+ char[20]`. This variable will contain the 160-bit SHA-1 of the given
+ commit. Note that whenever a SHA-1 is passed as "unsigned char *", it
+ is the binary representation, as opposed to the ASCII representation in
+ hex characters, which is passed as "char *".
+
+You will see both of these things throughout the code.
+
+Now, for the meat:
+
+-----------------------------------------------------------------------------
+ case 0:
+ buf = read_object_with_reference(sha1, argv[1], &size, NULL);
+-----------------------------------------------------------------------------
+
+This is how you read a blob (actually, not only a blob, but any type of
+object). To know how the function `read_object_with_reference()` actually
+works, find the source code for it (something like `git grep
+read_object_with | grep ":[a-z]"` in the git repository), and read
+the source.
+
+To find out how the result can be used, just read on in `cmd_cat_file()`:
+
+-----------------------------------
+ write_or_die(1, buf, size);
+-----------------------------------
+
+Sometimes, you do not know where to look for a feature. In many such cases,
+it helps to search through the output of `git log`, and then `git show` the
+corresponding commit.
+
+Example: If you know that there was some test case for `git bundle`, but
+do not remember where it was (yes, you _could_ `git grep bundle t/`, but that
+does not illustrate the point!):
+
+------------------------
+$ git log --no-merges t/
+------------------------
+
+In the pager (`less`), just search for "bundle", go a few lines back,
+and see that it is in commit 18449ab0... Now just copy this object name,
+and paste it into the command line
+
+-------------------
+$ git show 18449ab0
+-------------------
+
+Voila.
+
+Another example: Find out what to do in order to make some script a
+builtin:
+
+-------------------------------------------------
+$ git log --no-merges --diff-filter=A builtin-*.c
+-------------------------------------------------
+
+You see, Git is actually the best tool to find out about the source of Git
+itself!
+
[[glossary]]
include::glossary.txt[]
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 08/10] user-manual: add a "counting commits" example
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <11791560901-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
This is partly just an excuse to mention --pretty= and rev-list.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 3f51522..e86e46c 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -690,6 +690,25 @@ may be any path to a file tracked by git.
Examples
--------
+[[counting-commits-on-a-branch]]
+Counting the number of commits on a branch
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Suppose you want to know how many commits you've made on "mybranch"
+since it diverged from "origin":
+
+-------------------------------------------------
+$ git log --pretty=oneline origin..maint | wc -l
+-------------------------------------------------
+
+Alternatively you may often see this sort of thing done with the
+lower-level command gitlink:git-rev-list[1], which just lists the SHA1's
+of all the given commits:
+
+-------------------------------------------------
+$ git rev-list origin..maint | wc -l
+-------------------------------------------------
+
[[checking-for-equal-branches]]
Check whether two branches point at the same history
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 05/10] Documentation: remove howto's now incorporated into manual
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <11791560891179-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
These two howto's have both been copied into the manual. I'd rather not
maintain both versions if possible, and I think the user-manual will be
more visible than the howto directory. (Though I wouldn't mind some
duplication if people really like having them here.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/howto/dangling-objects.txt | 109 ----------------------
Documentation/howto/isolate-bugs-with-bisect.txt | 65 -------------
2 files changed, 0 insertions(+), 174 deletions(-)
delete mode 100644 Documentation/howto/dangling-objects.txt
delete mode 100644 Documentation/howto/isolate-bugs-with-bisect.txt
diff --git a/Documentation/howto/dangling-objects.txt b/Documentation/howto/dangling-objects.txt
deleted file mode 100644
index e82ddae..0000000
--- a/Documentation/howto/dangling-objects.txt
+++ /dev/null
@@ -1,109 +0,0 @@
-From: Linus Torvalds <torvalds@linux-foundation.org>
-Subject: Re: Question about fsck-objects output
-Date: Thu, 25 Jan 2007 12:01:06 -0800 (PST)
-Message-ID: <Pine.LNX.4.64.0701251144290.25027@woody.linux-foundation.org>
-Archived-At: <http://permalink.gmane.org/gmane.comp.version-control.git/37754>
-Abstract: Linus describes what dangling objects are, when they
- are left behind, and how to view their relationship with branch
- heads in gitk
-
-On Thu, 25 Jan 2007, Larry Streepy wrote:
-
-> Sorry to ask such a basic question, but I can't quite decipher the output of
-> fsck-objects. When I run it, I get this:
->
-> git fsck-objects
-> dangling commit 2213f6d4dd39ca8baebd0427723723e63208521b
-> dangling commit f0d4e00196bd5ee54463e9ea7a0f0e8303da767f
-> dangling blob 6a6d0b01b3e96d49a8f2c7addd4ef8c3bd1f5761
->
->
-> Even after a "repack -a -d" they still exist. The man page has a short
-> explanation, but, at least for me, it wasn't fully enlightening. :-)
->
-> The man page says that dangling commits could be "root" commits, but since my
-> repo started as a clone of another repo, I don't see how I could have any root
-> commits. Also, the page doesn't really describe what a dangling blob is.
->
-> So, can someone explain what these artifacts are and if they are a problem
-> that I should be worried about?
-
-The most common situation is that you've rebased a branch (or you have
-pulled from somebody else who rebased a branch, like the "pu" branch in
-the git.git archive itself).
-
-What happens is that the old head of the original branch still exists, as
-does obviously everything it pointed to. The branch pointer itself just
-doesn't, since you replaced it with another one.
-
-However, there are certainly other situations too that cause dangling
-objects. For example, the "dangling blob" situation you have tends to be
-because you did a "git add" of a file, but then, before you actually
-committed it and made it part of the bigger picture, you changed something
-else in that file and committed that *updated* thing - the old state that
-you added originally ends up not being pointed to by any commit/tree, so
-it's now a dangling blob object.
-
-Similarly, when the "recursive" merge strategy runs, and finds that there
-are criss-cross merges and thus more than one merge base (which is fairly
-unusual, but it does happen), it will generate one temporary midway tree
-(or possibly even more, if you had lots of criss-crossing merges and
-more than two merge bases) as a temporary internal merge base, and again,
-those are real objects, but the end result will not end up pointing to
-them, so they end up "dangling" in your repository.
-
-Generally, dangling objects aren't anything to worry about. They can even
-be very useful: if you screw something up, the dangling objects can be how
-you recover your old tree (say, you did a rebase, and realized that you
-really didn't want to - you can look at what dangling objects you have,
-and decide to reset your head to some old dangling state).
-
-For commits, the most useful thing to do with dangling objects tends to be
-to do a simple
-
- gitk <dangling-commit-sha-goes-here> --not --all
-
-which means exactly what it sounds like: it says that you want to see the
-commit history that is described by the dangling commit(s), but you do NOT
-want to see the history that is described by all your branches and tags
-(which are the things you normally reach). That basically shows you in a
-nice way what the danglign commit was (and notice that it might not be
-just one commit: we only report the "tip of the line" as being dangling,
-but there might be a whole deep and complex commit history that has gotten
-dropped - rebasing will do that).
-
-For blobs and trees, you can't do the same, but you can examine them. You
-can just do
-
- git show <dangling-blob/tree-sha-goes-here>
-
-to show what the contents of the blob were (or, for a tree, basically what
-the "ls" for that directory was), and that may give you some idea of what
-the operation was that left that dangling object.
-
-Usually, dangling blobs and trees aren't very interesting. They're almost
-always the result of either being a half-way mergebase (the blob will
-often even have the conflict markers from a merge in it, if you have had
-conflicting merges that you fixed up by hand), or simply because you
-interrupted a "git fetch" with ^C or something like that, leaving _some_
-of the new objects in the object database, but just dangling and useless.
-
-Anyway, once you are sure that you're not interested in any dangling
-state, you can just prune all unreachable objects:
-
- git prune
-
-and they'll be gone. But you should only run "git prune" on a quiescent
-repository - it's kind of like doing a filesystem fsck recovery: you don't
-want to do that while the filesystem is mounted.
-
-(The same is true of "git-fsck-objects" itself, btw - but since
-git-fsck-objects never actually *changes* the repository, it just reports
-on what it found, git-fsck-objects itself is never "dangerous" to run.
-Running it while somebody is actually changing the repository can cause
-confusing and scary messages, but it won't actually do anything bad. In
-contrast, running "git prune" while somebody is actively changing the
-repository is a *BAD* idea).
-
- Linus
-
diff --git a/Documentation/howto/isolate-bugs-with-bisect.txt b/Documentation/howto/isolate-bugs-with-bisect.txt
deleted file mode 100644
index 926bbdc..0000000
--- a/Documentation/howto/isolate-bugs-with-bisect.txt
+++ /dev/null
@@ -1,65 +0,0 @@
-From: Linus Torvalds <torvalds () osdl ! org>
-To: git@vger.kernel.org
-Date: 2005-11-08 1:31:34
-Subject: Real-life kernel debugging scenario
-Abstract: Short-n-sweet, Linus tells us how to leverage `git-bisect` to perform
- bug isolation on a repository where "good" and "bad" revisions are known
- in order to identify a suspect commit.
-
-
-How To Use git-bisect To Isolate a Bogus Commit
-===============================================
-
-The way to use "git bisect" couldn't be easier.
-
-Figure out what the oldest bad state you know about is (that's usually the
-head of "master", since that's what you just tried to boot and failed at).
-Also, figure out the most recent known-good commit (usually the _previous_
-kernel you ran: and if you've only done a single "pull" in between, it
-will be ORIG_HEAD).
-
-Then do
-
- git bisect start
- git bisect bad master <- mark "master" as the bad state
- git bisect good ORIG_HEAD <- mark ORIG_HEAD as good (or
- whatever other known-good
- thing you booted last)
-
-and at this point "git bisect" will churn for a while, and tell you what
-the mid-point between those two commits are, and check that state out as
-the head of the new "bisect" branch.
-
-Compile and reboot.
-
-If it's good, just do
-
- git bisect good <- mark current head as good
-
-otherwise, reboot into a good kernel instead, and do (surprise surprise,
-git really is very intuitive):
-
- git bisect bad <- mark current head as bad
-
-and whatever you do, git will select a new half-way point. Do this for a
-while, until git tells you exactly which commit was the first bad commit.
-That's your culprit.
-
-It really works wonderfully well, except for the case where there was
-_another_ commit that broke something in between, like introduced some
-stupid compile error. In that case you should not mark that commit good or
-bad: you should try to find another commit close-by, and do a "git reset
---hard <newcommit>" to try out _that_ commit instead, and then test that
-instead (and mark it good or bad).
-
-You can do "git bisect visualize" while you do all this to see what's
-going on by starting up gitk on the bisection range.
-
-Finally, once you've figured out exactly which commit was bad, you can
-then go back to the master branch, and try reverting just that commit:
-
- git checkout master
- git revert <bad-commit-id>
-
-to verify that the top-of-kernel works with that single commit reverted.
-
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 04/10] user-manual: move quick-start to an appendix
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <11791560893022-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
The quick start interrupts the flow of the manual a bit. Move it to
"appendix A" but add a reference to it in the preface. Also rename the
todo chapter to "appendix B", and revise the preface a little.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 484 +++++++++++++++++++++--------------------
1 files changed, 245 insertions(+), 239 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 7abdc3e..986e617 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4,15 +4,13 @@ ______________________________________________
This manual is designed to be readable by someone with basic unix
command-line skills, but no previous knowledge of git.
-Chapter 1 gives a brief overview of git commands, without any
-explanation; you may prefer to skip to chapter 2 on a first reading.
+<<repositories-and-branches>> and <<exploring-git-history>> explain how
+to fetch and study a project using git--read these chapters to learn how
+to build and test a particular version of a software project, search for
+regressions, and so on.
-Chapters 2 and 3 explain how to fetch and study a project using
-git--the tools you'd need to build and test a particular version of a
-software project, to search for regressions, and so on.
-
-Chapter 4 explains how to do development with git, and chapter 5 how
-to share that development with others.
+People needing to do actual development will also want to read
+<<Developing-with-git>> and <<sharing-development>>.
Further chapters cover more specialized topics.
@@ -23,237 +21,12 @@ pages. For a command such as "git clone", just use
$ man git-clone
------------------------------------------------
-[[git-quick-start]]
-Git Quick Start
-===============
-
-This is a quick summary of the major commands; the following chapters
-will explain how these work in more detail.
-
-[[quick-creating-a-new-repository]]
-Creating a new repository
--------------------------
-
-From a tarball:
-
------------------------------------------------
-$ tar xzf project.tar.gz
-$ cd project
-$ git init
-Initialized empty Git repository in .git/
-$ git add .
-$ git commit
------------------------------------------------
-
-From a remote repository:
-
------------------------------------------------
-$ git clone git://example.com/pub/project.git
-$ cd project
------------------------------------------------
-
-[[managing-branches]]
-Managing branches
------------------
-
------------------------------------------------
-$ git branch # list all local branches in this repo
-$ git checkout test # switch working directory to branch "test"
-$ git branch new # create branch "new" starting at current HEAD
-$ git branch -d new # delete branch "new"
------------------------------------------------
-
-Instead of basing new branch on current HEAD (the default), use:
-
------------------------------------------------
-$ git branch new test # branch named "test"
-$ git branch new v2.6.15 # tag named v2.6.15
-$ git branch new HEAD^ # commit before the most recent
-$ git branch new HEAD^^ # commit before that
-$ git branch new test~10 # ten commits before tip of branch "test"
------------------------------------------------
-
-Create and switch to a new branch at the same time:
-
------------------------------------------------
-$ git checkout -b new v2.6.15
------------------------------------------------
-
-Update and examine branches from the repository you cloned from:
-
------------------------------------------------
-$ git fetch # update
-$ git branch -r # list
- origin/master
- origin/next
- ...
-$ git checkout -b masterwork origin/master
------------------------------------------------
-
-Fetch a branch from a different repository, and give it a new
-name in your repository:
-
------------------------------------------------
-$ git fetch git://example.com/project.git theirbranch:mybranch
-$ git fetch git://example.com/project.git v2.6.15:mybranch
------------------------------------------------
-
-Keep a list of repositories you work with regularly:
-
------------------------------------------------
-$ git remote add example git://example.com/project.git
-$ git remote # list remote repositories
-example
-origin
-$ git remote show example # get details
-* remote example
- URL: git://example.com/project.git
- Tracked remote branches
- master next ...
-$ git fetch example # update branches from example
-$ git branch -r # list all remote branches
------------------------------------------------
-
-
-[[exploring-history]]
-Exploring history
------------------
-
------------------------------------------------
-$ gitk # visualize and browse history
-$ git log # list all commits
-$ git log src/ # ...modifying src/
-$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15
-$ git log master..test # ...in branch test, not in branch master
-$ git log test..master # ...in branch master, but not in test
-$ git log test...master # ...in one branch, not in both
-$ git log -S'foo()' # ...where difference contain "foo()"
-$ git log --since="2 weeks ago"
-$ git log -p # show patches as well
-$ git show # most recent commit
-$ git diff v2.6.15..v2.6.16 # diff between two tagged versions
-$ git diff v2.6.15..HEAD # diff with current head
-$ git grep "foo()" # search working directory for "foo()"
-$ git grep v2.6.15 "foo()" # search old tree for "foo()"
-$ git show v2.6.15:a.txt # look at old version of a.txt
------------------------------------------------
-
-Search for regressions:
-
------------------------------------------------
-$ git bisect start
-$ git bisect bad # current version is bad
-$ git bisect good v2.6.13-rc2 # last known good revision
-Bisecting: 675 revisions left to test after this
- # test here, then:
-$ git bisect good # if this revision is good, or
-$ git bisect bad # if this revision is bad.
- # repeat until done.
------------------------------------------------
-
-[[making-changes]]
-Making changes
---------------
-
-Make sure git knows who to blame:
-
-------------------------------------------------
-$ cat >>~/.gitconfig <<\EOF
-[user]
- name = Your Name Comes Here
- email = you@yourdomain.example.com
-EOF
-------------------------------------------------
-
-Select file contents to include in the next commit, then make the
-commit:
-
------------------------------------------------
-$ git add a.txt # updated file
-$ git add b.txt # new file
-$ git rm c.txt # old file
-$ git commit
------------------------------------------------
+See also <<git-quick-start>> for a brief overview of git commands,
+without any explanation.
-Or, prepare and create the commit in one step:
+Also, see <<todo>> for ways that you can help make this manual more
+complete.
------------------------------------------------
-$ git commit d.txt # use latest content only of d.txt
-$ git commit -a # use latest content of all tracked files
------------------------------------------------
-
-[[merging]]
-Merging
--------
-
------------------------------------------------
-$ git merge test # merge branch "test" into the current branch
-$ git pull git://example.com/project.git master
- # fetch and merge in remote branch
-$ git pull . test # equivalent to git merge test
------------------------------------------------
-
-[[sharing-your-changes]]
-Sharing your changes
---------------------
-
-Importing or exporting patches:
-
------------------------------------------------
-$ git format-patch origin..HEAD # format a patch for each commit
- # in HEAD but not in origin
-$ git am mbox # import patches from the mailbox "mbox"
------------------------------------------------
-
-Fetch a branch in a different git repository, then merge into the
-current branch:
-
------------------------------------------------
-$ git pull git://example.com/project.git theirbranch
------------------------------------------------
-
-Store the fetched branch into a local branch before merging into the
-current branch:
-
------------------------------------------------
-$ git pull git://example.com/project.git theirbranch:mybranch
------------------------------------------------
-
-After creating commits on a local branch, update the remote
-branch with your commits:
-
------------------------------------------------
-$ git push ssh://example.com/project.git mybranch:theirbranch
------------------------------------------------
-
-When remote and local branch are both named "test":
-
------------------------------------------------
-$ git push ssh://example.com/project.git test
------------------------------------------------
-
-Shortcut version for a frequently used remote repository:
-
------------------------------------------------
-$ git remote add example ssh://example.com/project.git
-$ git push example test
------------------------------------------------
-
-[[repository-maintenance]]
-Repository maintenance
-----------------------
-
-Check for corruption:
-
------------------------------------------------
-$ git fsck
------------------------------------------------
-
-Recompress, remove unused cruft:
-
------------------------------------------------
-$ git gc
------------------------------------------------
[[repositories-and-branches]]
Repositories and Branches
@@ -3379,9 +3152,242 @@ itself!
[[glossary]]
include::glossary.txt[]
+[[git-quick-start]]
+Appendix A: Git Quick Start
+===========================
+
+This is a quick summary of the major commands; the following chapters
+will explain how these work in more detail.
+
+[[quick-creating-a-new-repository]]
+Creating a new repository
+-------------------------
+
+From a tarball:
+
+-----------------------------------------------
+$ tar xzf project.tar.gz
+$ cd project
+$ git init
+Initialized empty Git repository in .git/
+$ git add .
+$ git commit
+-----------------------------------------------
+
+From a remote repository:
+
+-----------------------------------------------
+$ git clone git://example.com/pub/project.git
+$ cd project
+-----------------------------------------------
+
+[[managing-branches]]
+Managing branches
+-----------------
+
+-----------------------------------------------
+$ git branch # list all local branches in this repo
+$ git checkout test # switch working directory to branch "test"
+$ git branch new # create branch "new" starting at current HEAD
+$ git branch -d new # delete branch "new"
+-----------------------------------------------
+
+Instead of basing new branch on current HEAD (the default), use:
+
+-----------------------------------------------
+$ git branch new test # branch named "test"
+$ git branch new v2.6.15 # tag named v2.6.15
+$ git branch new HEAD^ # commit before the most recent
+$ git branch new HEAD^^ # commit before that
+$ git branch new test~10 # ten commits before tip of branch "test"
+-----------------------------------------------
+
+Create and switch to a new branch at the same time:
+
+-----------------------------------------------
+$ git checkout -b new v2.6.15
+-----------------------------------------------
+
+Update and examine branches from the repository you cloned from:
+
+-----------------------------------------------
+$ git fetch # update
+$ git branch -r # list
+ origin/master
+ origin/next
+ ...
+$ git checkout -b masterwork origin/master
+-----------------------------------------------
+
+Fetch a branch from a different repository, and give it a new
+name in your repository:
+
+-----------------------------------------------
+$ git fetch git://example.com/project.git theirbranch:mybranch
+$ git fetch git://example.com/project.git v2.6.15:mybranch
+-----------------------------------------------
+
+Keep a list of repositories you work with regularly:
+
+-----------------------------------------------
+$ git remote add example git://example.com/project.git
+$ git remote # list remote repositories
+example
+origin
+$ git remote show example # get details
+* remote example
+ URL: git://example.com/project.git
+ Tracked remote branches
+ master next ...
+$ git fetch example # update branches from example
+$ git branch -r # list all remote branches
+-----------------------------------------------
+
+
+[[exploring-history]]
+Exploring history
+-----------------
+
+-----------------------------------------------
+$ gitk # visualize and browse history
+$ git log # list all commits
+$ git log src/ # ...modifying src/
+$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15
+$ git log master..test # ...in branch test, not in branch master
+$ git log test..master # ...in branch master, but not in test
+$ git log test...master # ...in one branch, not in both
+$ git log -S'foo()' # ...where difference contain "foo()"
+$ git log --since="2 weeks ago"
+$ git log -p # show patches as well
+$ git show # most recent commit
+$ git diff v2.6.15..v2.6.16 # diff between two tagged versions
+$ git diff v2.6.15..HEAD # diff with current head
+$ git grep "foo()" # search working directory for "foo()"
+$ git grep v2.6.15 "foo()" # search old tree for "foo()"
+$ git show v2.6.15:a.txt # look at old version of a.txt
+-----------------------------------------------
+
+Search for regressions:
+
+-----------------------------------------------
+$ git bisect start
+$ git bisect bad # current version is bad
+$ git bisect good v2.6.13-rc2 # last known good revision
+Bisecting: 675 revisions left to test after this
+ # test here, then:
+$ git bisect good # if this revision is good, or
+$ git bisect bad # if this revision is bad.
+ # repeat until done.
+-----------------------------------------------
+
+[[making-changes]]
+Making changes
+--------------
+
+Make sure git knows who to blame:
+
+------------------------------------------------
+$ cat >>~/.gitconfig <<\EOF
+[user]
+ name = Your Name Comes Here
+ email = you@yourdomain.example.com
+EOF
+------------------------------------------------
+
+Select file contents to include in the next commit, then make the
+commit:
+
+-----------------------------------------------
+$ git add a.txt # updated file
+$ git add b.txt # new file
+$ git rm c.txt # old file
+$ git commit
+-----------------------------------------------
+
+Or, prepare and create the commit in one step:
+
+-----------------------------------------------
+$ git commit d.txt # use latest content only of d.txt
+$ git commit -a # use latest content of all tracked files
+-----------------------------------------------
+
+[[merging]]
+Merging
+-------
+
+-----------------------------------------------
+$ git merge test # merge branch "test" into the current branch
+$ git pull git://example.com/project.git master
+ # fetch and merge in remote branch
+$ git pull . test # equivalent to git merge test
+-----------------------------------------------
+
+[[sharing-your-changes]]
+Sharing your changes
+--------------------
+
+Importing or exporting patches:
+
+-----------------------------------------------
+$ git format-patch origin..HEAD # format a patch for each commit
+ # in HEAD but not in origin
+$ git am mbox # import patches from the mailbox "mbox"
+-----------------------------------------------
+
+Fetch a branch in a different git repository, then merge into the
+current branch:
+
+-----------------------------------------------
+$ git pull git://example.com/project.git theirbranch
+-----------------------------------------------
+
+Store the fetched branch into a local branch before merging into the
+current branch:
+
+-----------------------------------------------
+$ git pull git://example.com/project.git theirbranch:mybranch
+-----------------------------------------------
+
+After creating commits on a local branch, update the remote
+branch with your commits:
+
+-----------------------------------------------
+$ git push ssh://example.com/project.git mybranch:theirbranch
+-----------------------------------------------
+
+When remote and local branch are both named "test":
+
+-----------------------------------------------
+$ git push ssh://example.com/project.git test
+-----------------------------------------------
+
+Shortcut version for a frequently used remote repository:
+
+-----------------------------------------------
+$ git remote add example ssh://example.com/project.git
+$ git push example test
+-----------------------------------------------
+
+[[repository-maintenance]]
+Repository maintenance
+----------------------
+
+Check for corruption:
+
+-----------------------------------------------
+$ git fsck
+-----------------------------------------------
+
+Recompress, remove unused cruft:
+
+-----------------------------------------------
+$ git gc
+-----------------------------------------------
+
+
[[todo]]
-Notes and todo list for this manual
-===================================
+Appendix B: Notes and todo list for this manual
+===============================================
This is a work in progress.
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 09/10] user-manual: introduce git
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <11791560901645-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
Well, we should say at least something about what git is.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e86e46c..d6ac29b 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1,6 +1,9 @@
Git User's Manual (for version 1.5.1 or newer)
______________________________________________
+
+Git is a fast distributed revision control system.
+
This manual is designed to be readable by someone with basic unix
command-line skills, but no previous knowledge of git.
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 03/10] glossary: expand and clarify some definitions, prune cross-references
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields, Linus Torvalds
In-Reply-To: <1179156089759-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
Revise and expand some of the definitions in the glossary, based in part
on a recent thread started by a user looking for help with some of the
jargon. I've borrowed some of the language from Linus's email on that
thread. (I'm assuming standing permission to plagiarize Linus's
email....)
Also start making a few changes to mitigate the appearance of
"circularity" mentioned in that thread:
- feel free to use somewhat longer definitions and to explain
some things more than once instead of relying purely on
cross-references
- don't use cross-references when they're redundant: eliminate
self-references and repeated references to the same entry.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/glossary.txt | 229 ++++++++++++++++++++++++++------------------
1 files changed, 135 insertions(+), 94 deletions(-)
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
index 2465514..fcf5d59 100644
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -2,12 +2,12 @@ GIT Glossary
============
[[def_alternate_object_database]]alternate object database::
- Via the alternates mechanism, a <<def_repository,repository>> can
- inherit part of its <<def_object_database,object database>> from another
- <<def_object_database,object database>>, which is called "alternate".
+ Via the alternates mechanism, a <<def_repository,repository>>
+ can inherit part of its <<def_object_database,object database>>
+ from another object database, which is called "alternate".
[[def_bare_repository]]bare repository::
- A <<def_bare_repository,bare repository>> is normally an appropriately
+ A bare repository is normally an appropriately
named <<def_directory,directory>> with a `.git` suffix that does not
have a locally checked-out copy of any of the files under
<<def_revision,revision>> control. That is, all of the `git`
@@ -21,10 +21,15 @@ GIT Glossary
Untyped <<def_object,object>>, e.g. the contents of a file.
[[def_branch]]branch::
- A non-cyclical graph of revisions, i.e. the complete history of a
- particular <<def_revision,revision>>, which is called the
- branch <<def_head,head>>. The heads
- are stored in `$GIT_DIR/refs/heads/`.
+ A "branch" is an active line of development. The most recent
+ <<def_commit,commit>> on a branch is referred to as the tip of
+ that branch. The tip of the branch is referenced by a branch
+ <<def_head,head>>, which moves forward as additional development
+ is done on the branch. A single git
+ <<def_repository,repository>> can track an arbitrary number of
+ branches, but your <<def_working_tree,working tree>> is
+ associated with just one of them (the "current" or "checked out"
+ branch), and <<def_HEAD,HEAD>> points to that branch.
[[def_cache]]cache::
Obsolete for: <<def_index,index>>.
@@ -50,18 +55,25 @@ GIT Glossary
as a new series of changes on top of different codebase. In GIT, this is
performed by "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
- of the current <<def_branch,branch>> as a new <<def_commit,commit>>.
+ of the current <<def_branch,branch>> as a new commit.
[[def_clean]]clean::
- A <<def_working_tree,working tree>> is <<def_clean,clean>>, if it
+ A <<def_working_tree,working tree>> is clean, if it
corresponds to the <<def_revision,revision>> referenced by the current
<<def_head,head>>. Also see "<<def_dirty,dirty>>".
[[def_commit]]commit::
- As a verb: The action of storing the current state of the
- <<def_index,index>> in the <<def_object_database,object database>>. The
- result is a <<def_revision,revision>>. As a noun: Short hand for
- <<def_commit_object,commit object>>.
+ As a noun: A single point in the
+ git history; the entire history of a project is represented as a
+ set of interrelated commits. The word "commit" is used often
+ used by git in the same places other revision control systems
+ use the words "revision" or "version". Also used as a short
+ hand for <<def_commit_object,commit object>>.
++
+As a verb: The action of storing a new snapshot of the project's
+state in the git history, by creating a new commit representing the current
+state of the <<def_index,index>> and advancing <<def_HEAD,HEAD>>
+to point at the new commit.)
[[def_commit_object]]commit object::
An <<def_object,object>> which contains the information about a
@@ -77,16 +89,22 @@ GIT Glossary
[[def_DAG]]DAG::
Directed acyclic graph. The <<def_commit,commit>> objects form a
directed acyclic graph, because they have parents (directed), and the
- graph of <<def_commit,commit>> objects is acyclic (there is no
+ graph of commit objects is acyclic (there is no
<<def_chain,chain>> which begins and ends with the same
<<def_object,object>>).
[[def_dangling_object]]dangling object::
An <<def_unreachable_object,unreachable object>> which is not
<<def_reachable,reachable>> even from other unreachable objects; a
- <<def_dangling_object,dangling object>> has no references to it from any
+ dangling object has no references to it from any
reference or <<def_object,object>> in the <<def_repository,repository>>.
+[[def_detached_HEAD]]detached HEAD::
+ Normally HEAD refers to the tip of a
+ <<def_branch,branch>>. However, git also allows you to check
+ out an arbitrary commit that isn't necessarily the tip of any
+ particular branch. In this case HEAD is said to be "detached".
+
[[def_dircache]]dircache::
You are *waaaaay* behind.
@@ -94,7 +112,7 @@ GIT Glossary
The list you get with "ls" :-)
[[def_dirty]]dirty::
- A <<def_working_tree,working tree>> is said to be <<def_dirty,dirty>> if
+ A <<def_working_tree,working tree>> is said to be "dirty" if
it contains modifications which have not been committed to the current
<<def_branch,branch>>.
@@ -109,16 +127,16 @@ GIT Glossary
<<def_branch,branch>>'s changes that happen to be a descendant of what
you have. In such these cases, you do not make a new <<def_merge,merge>>
<<def_commit,commit>> but instead just update to his
- <<def_revision,revision>>. This will happen frequently on a
+ revision. This will happen frequently on a
<<def_tracking_branch,tracking branch>> of a remote
<<def_repository,repository>>.
[[def_fetch]]fetch::
Fetching a <<def_branch,branch>> means to get the
- <<def_branch,branch>>'s <<def_head_ref,head ref>> from a remote
- <<def_repository,repository>>, to find out which objects are missing
- from the local <<def_object_database,object database>>, and to get them,
- too.
+ branch's <<def_head_ref,head ref>> from a remote
+ <<def_repository,repository>>, to find out which objects are
+ missing from the local <<def_object_database,object database>>,
+ and to get them, too. See also gitlink:git-fetch[1].
[[def_file_system]]file system::
Linus Torvalds originally designed git to be a user space file system,
@@ -132,61 +150,84 @@ GIT Glossary
Grafts enables two otherwise different lines of development to be joined
together by recording fake ancestry information for commits. This way
you can make git pretend the set of parents a <<def_commit,commit>> has
- is different from what was recorded when the <<def_commit,commit>> was
+ is different from what was recorded when the commit was
created. Configured via the `.git/info/grafts` file.
[[def_hash]]hash::
In git's context, synonym to <<def_object_name,object name>>.
[[def_head]]head::
- The top of a <<def_branch,branch>>. It contains a <<def_ref,ref>> to the
- corresponding <<def_commit_object,commit object>>.
+ A named reference to the <<def_commit,commit>> at the tip of a
+ <<def_branch,branch>>. Heads are stored in
+ `$GIT_DIR/refs/heads/`, except when using packed refs. (See
+ gitlink:git-packed-refs[1].)
+
+[[def_HEAD]]HEAD::
+ The current branch. In more detail: a reference to the most
+ recent <<def_commit,commit>> on the branch that you are
+ currently working on. Your <<def_working_tree,working tree>> is
+ normally derived from the state of the tree referred to by HEAD.
+ HEAD is a reference to one of the <<def_head,heads>> in your
+ repository, except when using a <<def_detached_HEAD,detached
+ HEAD>>, in which case it may reference an arbitrary commit.
[[def_head_ref]]head ref::
- A <<def_ref,ref>> pointing to a <<def_head,head>>. Often, this is
- abbreviated to "<<def_head,head>>". Head refs are stored in
- `$GIT_DIR/refs/heads/`.
+ A synonym for <<def_head,head>>.
[[def_hook]]hook::
During the normal execution of several git commands, call-outs are made
to optional scripts that allow a developer to add functionality or
checking. Typically, the hooks allow for a command to be pre-verified
and potentially aborted, and allow for a post-notification after the
- operation is done. The <<def_hook,hook>> scripts are found in the
+ operation is done. The hook scripts are found in the
`$GIT_DIR/hooks/` <<def_directory,directory>>, and are enabled by simply
making them executable.
[[def_index]]index::
A collection of files with stat information, whose contents are stored
- as objects. The <<def_index,index>> is a stored version of your working
+ as objects. The index is a stored version of your working
<<def_tree,tree>>. Truth be told, it can also contain a second, and even
a third version of a <<def_working_tree,working tree>>, which are used
when merging.
[[def_index_entry]]index entry::
The information regarding a particular file, stored in the
- <<def_index,index>>. An <<def_index_entry,index entry>> can be unmerged,
- if a <<def_merge,merge>> was started, but not yet finished (i.e. if the
- <<def_index,index>> contains multiple versions of that file).
+ <<def_index,index>>. An index entry can be unmerged, if a
+ <<def_merge,merge>> was started, but not yet finished (i.e. if
+ the index contains multiple versions of that file).
[[def_master]]master::
- The default development <<def_branch,branch>>. Whenever you create a git
- <<def_repository,repository>>, a <<def_branch,branch>> named
- "<<def_master,master>>" is created, and becomes the active
- <<def_branch,branch>>. In most cases, this contains the local
- development, though that is purely conventional and not required.
+ The default development <<def_branch,branch>>. Whenever you
+ create a git <<def_repository,repository>>, a branch named
+ "master" is created, and becomes the active branch. In most
+ cases, this contains the local development, though that is
+ purely by convention and is not required.
[[def_merge]]merge::
- To <<def_merge,merge>> branches means to try to accumulate the changes
- since a common ancestor and apply them to the first
- <<def_branch,branch>>. An automatic <<def_merge,merge>> uses heuristics
- to accomplish that. Evidently, an automatic <<def_merge,merge>> can
- fail.
+ As a verb: To bring the contents of another
+ <<def_branch,branch>> (possibly from an external
+ <<def_repository,repository>>) into the current branch. In the
+ case where the merged-in branch is from a different repository,
+ this is done by first <<def_fetch,fetching>> the remote branch
+ and then merging the result into the current branch. This
+ combination of fetch and merge operations is called a
+ <<def_pull,pull>>. Merging is performed by an automatic process
+ that identifies changes made since the branches diverged, and to
+ apply all those changes together. In cases where changes
+ conflict, manual intervention may be required to complete the
+ merge.
++
+As a noun: unless it is a <<def_fast_forward,fast forward>>, a
+successful merge results in the creation of a new <<def_commit,commit>>
+representing the result of the merge, and having as
+<<def_parent,parents>> the tips of the merged <<def_branch,branches>>.
+This commit is referred to as a "merge commit", or sometimes just a
+"merge".
[[def_object]]object::
The unit of storage in git. It is uniquely identified by the
<<def_SHA1,SHA1>> of its contents. Consequently, an
- <<def_object,object>> can not be changed.
+ object can not be changed.
[[def_object_database]]object database::
Stores a set of "objects", and an individual <<def_object,object>> is
@@ -198,9 +239,9 @@ GIT Glossary
[[def_object_name]]object name::
The unique identifier of an <<def_object,object>>. The <<def_hash,hash>>
- of the <<def_object,object>>'s contents using the Secure Hash Algorithm
+ of the object's contents using the Secure Hash Algorithm
1 and usually represented by the 40 character hexadecimal encoding of
- the <<def_hash,hash>> of the <<def_object,object>> (possibly followed by
+ the <<def_hash,hash>> of the object (possibly followed by
a white space).
[[def_object_type]]object type::
@@ -215,7 +256,7 @@ GIT Glossary
[[def_origin]]origin::
The default upstream <<def_repository,repository>>. Most projects have
at least one upstream project which they track. By default
- '<<def_origin,origin>>' is used for that purpose. New upstream updates
+ 'origin' is used for that purpose. New upstream updates
will be fetched into remote tracking branches named
origin/name-of-upstream-branch, which you can see using
"git <<def_branch,branch>> -r".
@@ -227,7 +268,7 @@ GIT Glossary
[[def_pack_index]]pack index::
The list of identifiers, and other information, of the objects in a
<<def_pack,pack>>, to assist in efficiently accessing the contents of a
- <<def_pack,pack>>.
+ pack.
[[def_parent]]parent::
A <<def_commit_object,commit object>> contains a (possibly empty) list
@@ -247,29 +288,29 @@ GIT Glossary
[[def_porcelain]]porcelain::
Cute name for programs and program suites depending on
<<def_core_git,core git>>, presenting a high level access to
- <<def_core_git,core git>>. Porcelains expose more of a <<def_SCM,SCM>>
+ core git. Porcelains expose more of a <<def_SCM,SCM>>
interface than the <<def_plumbing,plumbing>>.
[[def_pull]]pull::
Pulling a <<def_branch,branch>> means to <<def_fetch,fetch>> it and
- <<def_merge,merge>> it.
+ <<def_merge,merge>> it. See also gitlink:git-pull[1].
[[def_push]]push::
- Pushing a <<def_branch,branch>> means to get the <<def_branch,branch>>'s
+ Pushing a <<def_branch,branch>> means to get the branch's
<<def_head_ref,head ref>> from a remote <<def_repository,repository>>,
- find out if it is an ancestor to the <<def_branch,branch>>'s local
- <<def_head_ref,head ref>> is a direct, and in that case, putting all
+ find out if it is an ancestor to the branch's local
+ head ref is a direct, and in that case, putting all
objects, which are <<def_reachable,reachable>> from the local
- <<def_head_ref,head ref>>, and which are missing from the remote
- <<def_repository,repository>>, into the remote
+ head ref, and which are missing from the remote
+ repository, into the remote
<<def_object_database,object database>>, and updating the remote
- <<def_head_ref,head ref>>. If the remote <<def_head,head>> is not an
- ancestor to the local <<def_head,head>>, the <<def_push,push>> fails.
+ head ref. If the remote <<def_head,head>> is not an
+ ancestor to the local head, the push fails.
[[def_reachable]]reachable::
All of the ancestors of a given <<def_commit,commit>> are said to be
- <<def_reachable,reachable>> from that <<def_commit,commit>>. More
- generally, one <<def_object,object>> is <<def_reachable,reachable>> from
+ "reachable" from that commit. More
+ generally, one <<def_object,object>> is reachable from
another if we can reach the one from the other by a <<def_chain,chain>>
that follows <<def_tag,tags>> to whatever they tag,
<<def_commit_object,commits>> to their parents or trees, and
@@ -288,24 +329,23 @@ GIT Glossary
[[def_refspec]]refspec::
A <<def_refspec,refspec>> is used by <<def_fetch,fetch>> and
- <<def_push,push>> to describe the mapping between remote <<def_ref,ref>>
- and local <<def_ref,ref>>. They are combined with a colon in the format
- <src>:<dst>, preceded by an optional plus sign, +. For example: `git
- fetch $URL refs/heads/master:refs/heads/origin` means
- "grab the master <<def_branch,branch>> <<def_head,head>>
- from the $URL and store it as my origin
- <<def_branch,branch>> <<def_head,head>>". And `git <<def_push,push>>
- $URL refs/heads/master:refs/heads/to-upstream` means
- "publish my master <<def_branch,branch>>
- <<def_head,head>> as to-upstream <<def_branch,branch>> at $URL". See
- also gitlink:git-push[1]
+ <<def_push,push>> to describe the mapping between remote
+ <<def_ref,ref>> and local ref. They are combined with a colon in
+ the format <src>:<dst>, preceded by an optional plus sign, +.
+ For example: `git fetch $URL
+ refs/heads/master:refs/heads/origin` means "grab the master
+ <<def_branch,branch>> <<def_head,head>> from the $URL and store
+ it as my origin branch head". And `git push
+ $URL refs/heads/master:refs/heads/to-upstream` means "publish my
+ master branch head as to-upstream branch at $URL". See also
+ gitlink:git-push[1]
[[def_repository]]repository::
- A collection of refs together with an <<def_object_database,object
- database>> containing all objects which are <<def_reachable,reachable>>
- from the refs, possibly accompanied by meta data from one or more
- porcelains. A <<def_repository,repository>> can share an
- <<def_object_database,object database>> with other repositories.
+ A collection of refs together with an
+ <<def_object_database,object database>> containing all objects
+ which are <<def_reachable,reachable>> from the refs, possibly
+ accompanied by meta data from one or more porcelains. A
+ repository can share an object database with other repositories.
[[def_resolve]]resolve::
The action of fixing up manually what a failed automatic
@@ -327,36 +367,37 @@ GIT Glossary
Synonym for <<def_object_name,object name>>.
[[def_shallow_repository]]shallow repository::
- A <<def_shallow_repository,shallow repository>> has an incomplete
+ A shallow repository has an incomplete
history some of whose commits have parents cauterized away (in other
words, git is told to pretend that these commits do not have the
parents, even though they are recorded in the <<def_commit_object,commit
object>>). This is sometimes useful when you are interested only in the
recent history of a project even though the real history recorded in the
- upstream is much larger. A <<def_shallow_repository,shallow repository>>
+ upstream is much larger. A shallow repository
is created by giving the `--depth` option to gitlink:git-clone[1], and
its history can be later deepened with gitlink:git-fetch[1].
[[def_symref]]symref::
- Symbolic reference: instead of containing the <<def_SHA1,SHA1>> id
- itself, it is of the format 'ref: refs/some/thing' and when
- referenced, it recursively dereferences to this reference. 'HEAD' is a
- prime example of a <<def_symref,symref>>. Symbolic references are
- manipulated with the gitlink:git-symbolic-ref[1] command.
+ Symbolic reference: instead of containing the <<def_SHA1,SHA1>>
+ id itself, it is of the format 'ref: refs/some/thing' and when
+ referenced, it recursively dereferences to this reference.
+ '<<def_HEAD,HEAD>>' is a prime example of a symref. Symbolic
+ references are manipulated with the gitlink:git-symbolic-ref[1]
+ command.
[[def_tag]]tag::
- A <<def_ref,ref>> pointing to a <<def_tag,tag>> or
+ A <<def_ref,ref>> pointing to a tag or
<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
a tag is not changed by a <<def_commit,commit>>. Tags (not
<<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A
git tag has nothing to do with a Lisp tag (which would be
called an <<def_object_type,object type>> in git's context). A
tag is most typically used to mark a particular point in the
- <<def_commit,commit>> ancestry <<def_chain,chain>>.
+ commit ancestry <<def_chain,chain>>.
[[def_tag_object]]tag object::
An <<def_object,object>> containing a <<def_ref,ref>> pointing to
- another <<def_object,object>>, which can contain a message just like a
+ another object, which can contain a message just like a
<<def_commit_object,commit object>>. It can also contain a (PGP)
signature, in which case it is called a "signed <<def_tag_object,tag
object>>".
@@ -370,16 +411,16 @@ GIT Glossary
[[def_tracking_branch]]tracking branch::
A regular git <<def_branch,branch>> that is used to follow changes from
- another <<def_repository,repository>>. A <<def_tracking_branch,tracking
- branch>> should not contain direct modifications or have local commits
- made to it. A <<def_tracking_branch,tracking branch>> can usually be
+ another <<def_repository,repository>>. A tracking
+ branch should not contain direct modifications or have local commits
+ made to it. A tracking branch can usually be
identified as the right-hand-side <<def_ref,ref>> in a Pull:
<<def_refspec,refspec>>.
[[def_tree]]tree::
Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
- object>> together with the dependent blob and <<def_tree,tree>> objects
- (i.e. a stored representation of a <<def_working_tree,working tree>>).
+ object>> together with the dependent blob and tree objects
+ (i.e. a stored representation of a working tree).
[[def_tree_object]]tree object::
An <<def_object,object>> containing a list of file names and modes along
@@ -389,8 +430,7 @@ GIT Glossary
[[def_tree-ish]]tree-ish::
A <<def_ref,ref>> pointing to either a <<def_commit_object,commit
object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag
- object>> pointing to a <<def_tag,tag>> or <<def_commit,commit>> or
- <<def_tree_object,tree object>>.
+ object>> pointing to a tag or commit or tree object.
[[def_unmerged_index]]unmerged index::
An <<def_index,index>> which contains unmerged
@@ -401,5 +441,6 @@ GIT Glossary
<<def_branch,branch>>, <<def_tag,tag>>, or any other reference.
[[def_working_tree]]working tree::
- The set of files and directories currently being worked on, i.e. you can
- work in your <<def_working_tree,working tree>> without using git at all.
+ The tree of actual checked out files. The working tree is
+ normally equal to the <<def_HEAD,HEAD>> plus any local changes
+ that you have made but not yet committed.
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 06/10] user-manual: move howto/make-dist.txt into user manual
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <1179156089470-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
There seems to be a perception that the howto's are bit-rotting a
little. The manual might be a more visible location for some of them,
and make-dist.txt seems like a good candidate to include as an example
in the manual.
For now, incorporate much of it verbatim. Later we may want to update
the example a bit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/howto/make-dist.txt | 52 -------------------------------------
Documentation/user-manual.txt | 43 ++++++++++++++++++++++++++++++
2 files changed, 43 insertions(+), 52 deletions(-)
delete mode 100644 Documentation/howto/make-dist.txt
diff --git a/Documentation/howto/make-dist.txt b/Documentation/howto/make-dist.txt
deleted file mode 100644
index 00e330b..0000000
--- a/Documentation/howto/make-dist.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-Date: Fri, 12 Aug 2005 22:39:48 -0700 (PDT)
-From: Linus Torvalds <torvalds@osdl.org>
-To: Dave Jones <davej@redhat.com>
-cc: git@vger.kernel.org
-Subject: Re: Fwd: Re: git checkout -f branch doesn't remove extra files
-Abstract: In this article, Linus talks about building a tarball,
- incremental patch, and ChangeLog, given a base release and two
- rc releases, following the convention of giving the patch from
- the base release and the latest rc, with ChangeLog between the
- last rc and the latest rc.
-
-On Sat, 13 Aug 2005, Dave Jones wrote:
->
-> > Git actually has a _lot_ of nifty tools. I didn't realize that people
-> > didn't know about such basic stuff as "git-tar-tree" and "git-ls-files".
->
-> Maybe its because things are moving so fast :) Or maybe I just wasn't
-> paying attention on that day. (I even read the git changes via RSS,
-> so I should have no excuse).
-
-Well, git-tar-tree has been there since late April - it's actually one of
-those really early commands. I'm pretty sure the RSS feed came later ;)
-
-I use it all the time in doing releases, it's a lot faster than creating a
-tar tree by reading the filesystem (even if you don't have to check things
-out). A hidden pearl.
-
-This is my crappy "release-script":
-
- [torvalds@g5 ~]$ cat bin/release-script
- #!/bin/sh
- stable="$1"
- last="$2"
- new="$3"
- echo "# git-tag v$new"
- echo "git-tar-tree v$new linux-$new | gzip -9 > ../linux-$new.tar.gz"
- echo "git-diff-tree -p v$stable v$new | gzip -9 > ../patch-$new.gz"
- echo "git-rev-list --pretty v$new ^v$last > ../ChangeLog-$new"
- echo "git-rev-list --pretty=short v$new ^v$last | git-shortlog > ../ShortLog"
- echo "git-diff-tree -p v$last v$new | git-apply --stat > ../diffstat-$new"
-
-and when I want to do a new kernel release I literally first tag it, and
-then do
-
- release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
-
-and check that things look sane, and then just cut-and-paste the commands.
-
-Yeah, it's stupid.
-
- Linus
-
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 986e617..5404d6f 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -808,6 +808,49 @@ available
Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
from v1.5.0-rc2, but not from v1.5.0-rc0.
+[[making-a-release]]
+Creating a changelog and tarball for a software release
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The gitlink:git-archive[1] command can create a tar or zip archive from
+any version of a project; for example:
+
+-------------------------------------------------
+$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+-------------------------------------------------
+
+Will use HEAD to produce a tar archive in which each filename is
+preceded by "prefix/".
+
+If you're releasing a new version of a software project, you may want
+to simultaneously make a changelog to include in the release
+announcement.
+
+Linus Torvalds, for example, makes new kernel releases by running
+
+-------------------------------------------------
+$ release-script 2.6.12 2.6.13-rc6 2.6.13-rc7
+-------------------------------------------------
+
+where release-script is a shell script that looks like:
+
+-------------------------------------------------
+#!/bin/sh
+stable="$1"
+last="$2"
+new="$3"
+echo "# git-tag v$new"
+echo "git-tar-tree v$new linux-$new | gzip -9 > ../linux-$new.tar.gz"
+echo "git-diff-tree -p v$stable v$new | gzip -9 > ../patch-$new.gz"
+echo "git-rev-list --pretty v$new ^v$last > ../ChangeLog-$new"
+echo "git-rev-list --pretty=short v$new ^v$last | git-shortlog > ../ShortLog"
+echo "git-diff-tree -p v$last v$new | git-apply --stat > ../diffstat-$new"
+-------------------------------------------------
+
+(Note that gitlink:git-rev-list[1] and gitlink:git-diff-tree[1] are low-level
+commands with functionality similar to gitlink:git-log[1] and
+gitlink:git-diff[1].)
+
[[Developing-with-git]]
Developing with git
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 07/10] user-manual: move howto/using-topic-branches into manual
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields, Tony Luck
In-Reply-To: <11791560892667-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
Move howto/using-topic-branches into the user manual as an example for
the "sharing development" chapter. While we're at it, remove some
discussion that's covered in earlier chapters, modernize somewhat (use
separate-heads setup, remotes, replace "whatchanged" by "log", etc.),
and replace syntax we'd need to explain by syntax we've already covered
(e.g. old..new instead of new ^old).
The result may not really describe what Tony Luck does any more.... Hope
that's not annoying.
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/howto/using-topic-branches.txt | 296 -------------------------
Documentation/user-manual.txt | 297 +++++++++++++++++++++++++-
2 files changed, 296 insertions(+), 297 deletions(-)
delete mode 100644 Documentation/howto/using-topic-branches.txt
diff --git a/Documentation/howto/using-topic-branches.txt b/Documentation/howto/using-topic-branches.txt
deleted file mode 100644
index 2c98194..0000000
--- a/Documentation/howto/using-topic-branches.txt
+++ /dev/null
@@ -1,296 +0,0 @@
-Date: Mon, 15 Aug 2005 12:17:41 -0700
-From: tony.luck@intel.com
-Subject: Some tutorial text (was git/cogito workshop/bof at linuxconf au?)
-Abstract: In this article, Tony Luck discusses how he uses GIT
- as a Linux subsystem maintainer.
-
-Here's something that I've been putting together on how I'm using
-GIT as a Linux subsystem maintainer.
-
--Tony
-
-Last updated w.r.t. GIT 1.1
-
-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 by 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 git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
-
-Change directory into the cloned tree you just created
-
- $ cd work
-
-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: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
- Pull: master:linus
- ^D
-
-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 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).
-
-If you need to keep track of other public trees, you can add remote 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
-
-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.
-
- $ git branch test linus
- $ git branch release linus
-
-These can be easily kept up to date by merging from the "linus" branch:
-
- $ git checkout test && git merge "Auto-update from upstream" test linus
- $ git checkout release && git merge "Auto-update from upstream" release linus
-
-Important note! If you have any local changes in these branches, then
-this merge will create a commit object in the history (with no local
-changes git will simply do a "Fast forward" merge). Many people dislike
-the "noise" that this creates in the Linux history, so you should avoid
-doing this capriciously in the "release" branch, as these noisy commits
-will become part of the permanent history when you ask Linus to pull
-from the release branch.
-
-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).
-
- $ cat > .git/remotes/mytree
- URL: master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
- Push: release
- Push: test
- ^D
-
-and the push both the test and release trees using:
-
- $ 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
-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 merge "Pull speed-up-spinlock changes" test speed-up-spinlocks
-
-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 merge "Pull speed-up-spinlock changes" release speed-up-spinlocks
-
-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
-
-[If this branch has not yet been merged you will see a set of SHA1 values
-for the commits, if it has been merged, then there will be no output]
-
-Once a patch completes the great cycle (moving from test to release, then
-pulled by Linus, and finally coming back into your local "linus" branch)
-the branch for this change is no longer needed. You detect this when the
-output from:
-
- $ git-rev-list branchname ^linus
-
-is empty. At this point the branch can be deleted:
-
- $ git branch -d branchname
-
-Some changes are so trivial that it is not necessary to create a separate
-branch and then merge into each of the test and release branches. For
-these changes, just apply directly to the "release" branch, and then
-merge that into the "test" branch.
-
-To create diffstat and shortlog summaries of changes to include in a "please
-pull" request to Linus you can use:
-
- $ git-whatchanged -p release ^linus | diffstat -p1
-and
- $ git-whatchanged release ^linus | git-shortlog
-
-
-Here are some of the scripts that I use to simplify all this even further.
-
-==== update script ====
-# Update a branch in my GIT tree. If the branch to be updated
-# is "linus", then pull from kernel.org. Otherwise merge local
-# linus branch into test|release branch
-
-case "$1" in
-test|release)
- git checkout $1 && git merge "Auto-update from upstream" $1 linus
- ;;
-linus)
- 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
- fi
- ;;
-*)
- echo "Usage: $0 linus|test|release" 1>&2
- exit 1
- ;;
-esac
-
-==== merge script ====
-# Merge a branch into either the test or release branch
-
-pname=$0
-
-usage()
-{
- echo "Usage: $pname branch test|release" 1>&2
- exit 1
-}
-
-if [ ! -f .git/refs/heads/"$1" ]
-then
- echo "Can't see branch <$1>" 1>&2
- usage
-fi
-
-case "$2" in
-test|release)
- if [ $(git-rev-list $1 ^$2 | wc -c) -eq 0 ]
- then
- echo $1 already merged into $2 1>&2
- exit 1
- fi
- git checkout $2 && git merge "Pull $1 into $2 branch" $2 $1
- ;;
-*)
- usage
- ;;
-esac
-
-==== status script ====
-# report on status of my ia64 GIT tree
-
-gb=$(tput setab 2)
-rb=$(tput setab 1)
-restore=$(tput setab 9)
-
-if [ `git-rev-list release ^test | wc -c` -gt 0 ]
-then
- echo $rb Warning: commits in release that are not in test $restore
- git-whatchanged release ^test
-fi
-
-for branch in `ls .git/refs/heads`
-do
- if [ $branch = linus -o $branch = test -o $branch = release ]
- then
- continue
- fi
-
- echo -n $gb ======= $branch ====== $restore " "
- status=
- for ref in test release linus
- do
- if [ `git-rev-list $branch ^$ref | wc -c` -gt 0 ]
- then
- status=$status${ref:0:1}
- fi
- done
- case $status in
- trl)
- echo $rb Need to pull into test $restore
- ;;
- rl)
- echo "In test"
- ;;
- l)
- echo "Waiting for linus"
- ;;
- "")
- echo $rb All done $restore
- ;;
- *)
- echo $rb "<$status>" $restore
- ;;
- esac
- git-whatchanged $branch ^linus | git-shortlog
-done
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5404d6f..3f51522 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1790,7 +1790,302 @@ gitweb/INSTALL in the git source tree for instructions on setting it up.
Examples
--------
-TODO: topic branches, typical roles as in everyday.txt, ?
+[[maintaining-topic-branches]]
+Maintaining topic branches for a Linux subsystem maintainer
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This describes how Tony Luck uses git in his role as maintainer of the
+IA64 architecture for the Linux kernel.
+
+He uses two public branches:
+
+ - 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.
+
+ - 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.)
+
+He also uses a set of temporary branches ("topic branches"), each
+containing a logical grouping of patches.
+
+To set this up, first create your work tree by cloning Linus's public
+tree:
+
+-------------------------------------------------
+$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git work
+$ cd work
+-------------------------------------------------
+
+Linus's tree will be stored in the remote branch named origin/master,
+and can be updated using gitlink:git-fetch[1]; you can track other
+public trees using gitlink:git-remote[1] to set up a "remote" and
+git-fetch[1] to keep them up-to-date; see <<repositories-and-branches>>.
+
+Now create the branches in which you are going to work; these start out
+at the current tip of the linus branch, and should be set up (using the
+--track option to gitlink:git-branch[1]) to merge changes in from linus
+by default.
+
+-------------------------------------------------
+$ git branch --track test origin/master
+$ git branch --track release origin/master
+-------------------------------------------------
+
+These can be easily kept up to date using gitlink:git-pull[1]
+
+-------------------------------------------------
+$ git checkout test && git pull
+$ git checkout release && git pull
+-------------------------------------------------
+
+Important note! If you have any local changes in these branches, then
+this merge will create a commit object in the history (with no local
+changes git will simply do a "Fast forward" merge). Many people dislike
+the "noise" that this creates in the Linux history, so you should avoid
+doing this capriciously in the "release" branch, as these noisy commits
+will become part of the permanent history when you ask Linus to pull
+from the release branch.
+
+A few configuration variables (see gitlink:git-config[1]) can
+make it easy to push both branches to your public tree. (See
+<<setting-up-a-public-repository>>.)
+
+-------------------------------------------------
+$ cat >> .git/config <<EOF
+[remote "mytree"]
+ url = master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
+ push = release
+ push = test
+EOF
+-------------------------------------------------
+
+Then you can push both the test and release trees using
+gitlink:git-push[1]:
+
+-------------------------------------------------
+$ 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
+patches), and create a new branch from the current tip of the
+linus branch:
+
+-------------------------------------------------
+$ git checkout -b speed-up-spinlocks origin
+-------------------------------------------------
+
+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 pull . speed-up-spinlocks
+-------------------------------------------------
+
+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 pull . speed-up-spinlocks
+-------------------------------------------------
+
+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 log linux..branchname | git-shortlog
+-------------------------------------------------
+
+To see whether it has already been merged into the test or release branches
+use:
+
+-------------------------------------------------
+$ git log test..branchname
+-------------------------------------------------
+
+or
+
+-------------------------------------------------
+$ git log release..branchname
+-------------------------------------------------
+
+(If this branch has not yet been merged you will see some log entries.
+If it has been merged, then there will be no output.)
+
+Once a patch completes the great cycle (moving from test to release, then
+pulled by Linus, and finally coming back into your local "linus" branch)
+the branch for this change is no longer needed. You detect this when the
+output from:
+
+-------------------------------------------------
+$ git log linus..branchname
+-------------------------------------------------
+
+is empty. At this point the branch can be deleted:
+
+-------------------------------------------------
+$ git branch -d branchname
+-------------------------------------------------
+
+Some changes are so trivial that it is not necessary to create a separate
+branch and then merge into each of the test and release branches. For
+these changes, just apply directly to the "release" branch, and then
+merge that into the "test" branch.
+
+To create diffstat and shortlog summaries of changes to include in a "please
+pull" request to Linus you can use:
+
+-------------------------------------------------
+$ git diff --stat origin..release
+-------------------------------------------------
+
+and
+
+-------------------------------------------------
+$ git log -p origin..release | git shortlog
+-------------------------------------------------
+
+Here are some of the scripts that simplify all this even further.
+
+-------------------------------------------------
+==== update script ====
+# Update a branch in my GIT tree. If the branch to be updated
+# is "linus", then pull from kernel.org. Otherwise merge local
+# linus branch into test|release branch
+
+case "$1" in
+test|release)
+ git checkout $1 && git pull . origin
+ ;;
+linus)
+ before=$(cat .git/refs/heads/origin/master)
+ git fetch linus
+ after=$(cat .git/refs/heads/origin/master)
+ if [ $before != $after ]
+ then
+ git log $before..$after | git shortlog
+ fi
+ ;;
+*)
+ echo "Usage: $0 linus|test|release" 1>&2
+ exit 1
+ ;;
+esac
+-------------------------------------------------
+
+-------------------------------------------------
+==== merge script ====
+# Merge a branch into either the test or release branch
+
+pname=$0
+
+usage()
+{
+ echo "Usage: $pname branch test|release" 1>&2
+ exit 1
+}
+
+if [ ! -f .git/refs/heads/"$1" ]
+then
+ echo "Can't see branch <$1>" 1>&2
+ usage
+fi
+
+case "$2" in
+test|release)
+ if [ $(git log $2..$1 | wc -c) -eq 0 ]
+ then
+ echo $1 already merged into $2 1>&2
+ exit 1
+ fi
+ git checkout $2 && git pull . $1
+ ;;
+*)
+ usage
+ ;;
+esac
+-------------------------------------------------
+
+-------------------------------------------------
+==== status script ====
+# report on status of my ia64 GIT tree
+
+gb=$(tput setab 2)
+rb=$(tput setab 1)
+restore=$(tput setab 9)
+
+if [ `git rev-list test..release | wc -c` -gt 0 ]
+then
+ echo $rb Warning: commits in release that are not in test $restore
+ git log test..release
+fi
+
+for branch in `ls .git/refs/heads`
+do
+ if [ $branch = linus -o $branch = test -o $branch = release ]
+ then
+ continue
+ fi
+
+ echo -n $gb ======= $branch ====== $restore " "
+ status=
+ for ref in test release linus
+ do
+ if [ `git rev-list $ref..$branch | wc -c` -gt 0 ]
+ then
+ status=$status${ref:0:1}
+ fi
+ done
+ case $status in
+ trl)
+ echo $rb Need to pull into test $restore
+ ;;
+ rl)
+ echo "In test"
+ ;;
+ l)
+ echo "Waiting for linus"
+ ;;
+ "")
+ echo $rb All done $restore
+ ;;
+ *)
+ echo $rb "<$status>" $restore
+ ;;
+ esac
+ git log origin/master..$branch | git shortlog
+done
+-------------------------------------------------
[[cleaning-up-history]]
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* [PATCH 10/10] user-manual: listing commits reachable from some refs not others
From: J. Bruce Fields @ 2007-05-14 15:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <1179156090113-git-send-email->
From: J. Bruce Fields <bfields@citi.umich.edu>
This is just an amusing example raised by someone in irc.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 44 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 44 insertions(+), 0 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index d6ac29b..9fc2bba 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -830,6 +830,50 @@ available
Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
from v1.5.0-rc2, but not from v1.5.0-rc0.
+[[showing-commits-unique-to-a-branch]]
+Showing commits unique to a given branch
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Suppose you would like to see all the commits reachable from the branch
+head named "master" but not from any other head in your repository.
+
+You can list all the heads in this repository with
+gitlink:git-show-ref[1]:
+
+-------------------------------------------------
+$ git show-ref --heads
+bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial
+db768d5504c1bb46f63ee9d6e1772bd047e05bf9 refs/heads/maint
+a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
+24dbc180ea14dc1aebe09f14c8ecf32010690627 refs/heads/tutorial-2
+1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
+-------------------------------------------------
+
+We can get just the branch-head names, and remove "maint", with
+the help of the standard utilities cut and grep:
+
+-------------------------------------------------
+$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/maint'
+-------------------------------------------------
+
+And then we can ask to see all the commits reachable from maint
+but not from these other heads:
+
+-------------------------------------------------
+$ gitk maint --not $( git show-ref --heads | cut -d' ' -f2 |
+ grep -v '^refs/heads/maint' )
+-------------------------------------------------
+
+Obviously endless variations are possible; to see all commits
+reachable from some head but not from any tag in the repository:
+
+-------------------------------------------------
+$ gitk ($ git show-ref --heads ) --not $( git show-ref --tags )
+-------------------------------------------------
+
+(See gitlink:git-rev-parse[1] for explanations of commit-selecting
+syntax such as `--not`.)
+
[[making-a-release]]
Creating a changelog and tarball for a software release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* Re: Rebase max-pack-size?
From: Dana How @ 2007-05-14 15:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, danahow
[-- Attachment #1: Type: text/plain, Size: 856 bytes --]
"Junio C Hamano" <junkio@cox.net> writes:
> "Dana How" <danahow@gmail.com> writes:
> > Since max-pack-size has appeared, and disappeard, in "pu" twice
> > and never made it into "next", I'm guessing I should rebase/merge it on
> > top of the other recent pack-objects work. I may get to this tonight;
> > perhaps I'll send the patchset in one email with multiple attachments?
> I am still holding onto the series on its own topic branch, but
> merging it to 'pu' and resolving conflicts seem pointless while
> I am (and hopefully the rest of the list ought to be ;-)
> primarily concentrating on last-minute bugfixes in preparation
> for v1.5.2.
>
> A rebase to be queued in 'next' would be good, though.
Yes, the conflicts were extensive.
The rebased patches are attached.
Let me know if you want them re-sent inline and/or separately.
Thanks
Dana
[-- Attachment #2: 0001-Alter-sha1close-3rd-argument-to-request-flush-only.patch --]
[-- Type: text/plain, Size: 1345 bytes --]
>From 781820f147bcb12dae576734585b27f42faca3ea Mon Sep 17 00:00:00 2001
From: Dana L. How <danahow@gmail.com>
Date: Sun, 13 May 2007 11:28:19 -0700
Subject: [PATCH] Alter sha1close() 3rd argument to request flush only
update=0 suppressed writing the final SHA-1 but was not used.
Now final=0 suppresses SHA-1 finalization, SHA-1 writing,
and closing -- in other words, only flush the buffer.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
csum-file.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index 7088f6e..5109342 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -29,18 +29,20 @@ static void sha1flush(struct sha1file *f, unsigned int count)
}
}
-int sha1close(struct sha1file *f, unsigned char *result, int update)
+int sha1close(struct sha1file *f, unsigned char *result, int final)
{
unsigned offset = f->offset;
if (offset) {
SHA1_Update(&f->ctx, f->buffer, offset);
sha1flush(f, offset);
+ f->offset = 0;
}
+ if (!final)
+ return 0; /* only want to flush (no checksum write, no close) */
SHA1_Final(f->buffer, &f->ctx);
if (result)
hashcpy(result, f->buffer);
- if (update)
- sha1flush(f, 20);
+ sha1flush(f, 20);
if (close(f->fd))
die("%s: sha1 file error on close (%s)", f->name, strerror(errno));
free(f);
--
1.5.2.rc3.726.g279d
[-- Attachment #3: 0001-git-repack-max-pack-size-new-file-statics-and-cod.patch --]
[-- Type: text/plain, Size: 4900 bytes --]
>From 0c75fd66aa6a758e245d85b9304e85a38e977f94 Mon Sep 17 00:00:00 2001
From: Dana L. How <danahow@gmail.com>
Date: Sun, 13 May 2007 11:34:56 -0700
Subject: [PATCH 1/4] git-repack --max-pack-size: new file statics and code restructuring
Add "pack_size_limit", the limit specified by --max-pack-size,
"written_list", the list of objects written to the current pack,
and "nr_written", the number of objects in written_list.
Put "base_name" at file scope again and add forward declarations.
Move write_index_file() call from cnd_pack_objects() to
write_pack_file() since only the latter will know how
many times to call write_index_file().
Signed-off-by: Dana L. How <danahow@gmail.com>
---
builtin-pack-objects.c | 68 +++++++++++++++++++++++++----------------------
1 files changed, 36 insertions(+), 32 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index d165f10..7c17ea0 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -52,7 +52,8 @@ struct object_entry {
* nice "minimum seek" order.
*/
static struct object_entry *objects;
-static uint32_t nr_objects, nr_alloc, nr_result;
+static struct object_entry **written_list;
+static uint32_t nr_objects, nr_alloc, nr_result, nr_written;
static int non_empty;
static int no_reuse_delta, no_reuse_object;
@@ -61,9 +62,11 @@ static int incremental;
static int allow_ofs_delta;
static const char *pack_tmp_name, *idx_tmp_name;
static char tmpname[PATH_MAX];
+static const char *base_name;
static unsigned char pack_file_sha1[20];
static int progress = 1;
static int window = 10;
+static uint32_t pack_size_limit;
static int depth = 50;
static int pack_to_stdout;
static int num_preferred_base;
@@ -501,7 +504,11 @@ static int open_object_dir_tmp(const char *path)
return mkstemp(tmpname);
}
-static off_t write_pack_file(void)
+/* forward declarations for write_pack_file */
+static void write_index_file(off_t last_obj_offset, unsigned char *sha1);
+static int adjust_perm(const char *path, mode_t mode);
+
+static void write_pack_file(void)
{
uint32_t i;
struct sha1file *f;
@@ -543,7 +550,32 @@ static off_t write_pack_file(void)
die("wrote %u objects while expecting %u", written, nr_result);
sha1close(f, pack_file_sha1, 1);
- return last_obj_offset;
+ if (!pack_to_stdout) {
+ unsigned char object_list_sha1[20];
+ mode_t mode = umask(0);
+
+ umask(mode);
+ mode = 0444 & ~mode;
+
+ write_index_file(last_obj_offset, object_list_sha1);
+ snprintf(tmpname, sizeof(tmpname), "%s-%s.pack",
+ base_name, sha1_to_hex(object_list_sha1));
+ if (adjust_perm(pack_tmp_name, mode))
+ die("unable to make temporary pack file readable: %s",
+ strerror(errno));
+ if (rename(pack_tmp_name, tmpname))
+ die("unable to rename temporary pack file: %s",
+ strerror(errno));
+ snprintf(tmpname, sizeof(tmpname), "%s-%s.idx",
+ base_name, sha1_to_hex(object_list_sha1));
+ if (adjust_perm(idx_tmp_name, mode))
+ die("unable to make temporary index file readable: %s",
+ strerror(errno));
+ if (rename(idx_tmp_name, tmpname))
+ die("unable to rename temporary index file: %s",
+ strerror(errno));
+ puts(sha1_to_hex(object_list_sha1));
+ }
}
static int sha1_sort(const void *_a, const void *_b)
@@ -1537,8 +1569,6 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
int use_internal_rev_list = 0;
int thin = 0;
uint32_t i;
- off_t last_obj_offset;
- const char *base_name = NULL;
const char **rp_av;
int rp_ac_alloc = 64;
int rp_ac;
@@ -1707,33 +1737,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
fprintf(stderr, "Result has %u objects.\n", nr_result);
if (nr_result)
prepare_pack(window, depth);
- last_obj_offset = write_pack_file();
- if (!pack_to_stdout) {
- unsigned char object_list_sha1[20];
- mode_t mode = umask(0);
-
- umask(mode);
- mode = 0444 & ~mode;
-
- write_index_file(last_obj_offset, object_list_sha1);
- snprintf(tmpname, sizeof(tmpname), "%s-%s.pack",
- base_name, sha1_to_hex(object_list_sha1));
- if (adjust_perm(pack_tmp_name, mode))
- die("unable to make temporary pack file readable: %s",
- strerror(errno));
- if (rename(pack_tmp_name, tmpname))
- die("unable to rename temporary pack file: %s",
- strerror(errno));
- snprintf(tmpname, sizeof(tmpname), "%s-%s.idx",
- base_name, sha1_to_hex(object_list_sha1));
- if (adjust_perm(idx_tmp_name, mode))
- die("unable to make temporary index file readable: %s",
- strerror(errno));
- if (rename(idx_tmp_name, tmpname))
- die("unable to rename temporary index file: %s",
- strerror(errno));
- puts(sha1_to_hex(object_list_sha1));
- }
+ write_pack_file();
if (progress)
fprintf(stderr, "Total %u (delta %u), reused %u (delta %u)\n",
written, written_delta, reused, reused_delta);
--
1.5.2.rc3.726.g279d
[-- Attachment #4: 0002-git-repack-max-pack-size-write_-object-one-res.patch --]
[-- Type: text/plain, Size: 8068 bytes --]
>From 40ac2f294ec68cae27f8a9262db4cab84f1d2257 Mon Sep 17 00:00:00 2001
From: Dana L. How <danahow@gmail.com>
Date: Sun, 13 May 2007 12:06:18 -0700
Subject: [PATCH 2/4] git-repack --max-pack-size: write_{object,one}() respect pack limit
With --max-pack-size, generate the appropriate write limit
for each object and check against it before each group of writes.
Update delta usability rules to handle base being in a previously-
written pack. Inline sha1write_compress() so we know the
exact size of the written data when it needs to be compressed.
Detect and return write "failure".
Signed-off-by: Dana L. How <danahow@gmail.com>
---
builtin-pack-objects.c | 131 ++++++++++++++++++++++++++++++++++++++----------
1 files changed, 104 insertions(+), 27 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 7c17ea0..3023aac 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -352,16 +352,31 @@ static void copy_pack_data(struct sha1file *f,
}
static unsigned long write_object(struct sha1file *f,
- struct object_entry *entry)
+ struct object_entry *entry,
+ off_t write_offset)
{
unsigned long size;
enum object_type type;
void *buf;
unsigned char header[10];
+ unsigned char dheader[10];
unsigned hdrlen;
off_t datalen;
enum object_type obj_type;
int to_reuse = 0;
+ /* write limit if limited packsize and not first object */
+ unsigned long limit = pack_size_limit && nr_written ?
+ pack_size_limit - write_offset : 0;
+ /* no if no delta */
+ int usable_delta = !entry->delta ? 0 :
+ /* yes if unlimited packfile */
+ !pack_size_limit ? 1 :
+ /* no if base written to previous pack */
+ entry->delta->offset == (off_t)-1 ? 0 :
+ /* otherwise double-check written to this
+ * pack, like we do below
+ */
+ entry->delta->offset ? 1 : 0;
if (!pack_to_stdout)
crc32_begin(f);
@@ -372,7 +387,9 @@ static unsigned long write_object(struct sha1file *f,
else if (!entry->in_pack)
to_reuse = 0; /* can't reuse what we don't have */
else if (obj_type == OBJ_REF_DELTA || obj_type == OBJ_OFS_DELTA)
- to_reuse = 1; /* check_object() decided it for us */
+ /* check_object() decided it for us ... */
+ to_reuse = usable_delta;
+ /* ... but pack split may override that */
else if (obj_type != entry->in_pack_type)
to_reuse = 0; /* pack has delta which is unusable */
else if (entry->delta)
@@ -383,24 +400,48 @@ static unsigned long write_object(struct sha1file *f,
*/
if (!to_reuse) {
+ z_stream stream;
+ unsigned long maxsize;
+ void *out;
buf = read_sha1_file(entry->sha1, &type, &size);
if (!buf)
die("unable to read %s", sha1_to_hex(entry->sha1));
if (size != entry->size)
die("object %s size inconsistency (%lu vs %lu)",
sha1_to_hex(entry->sha1), size, entry->size);
- if (entry->delta) {
+ if (usable_delta) {
buf = delta_against(buf, size, entry);
size = entry->delta_size;
obj_type = (allow_ofs_delta && entry->delta->offset) ?
OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ } else {
+ /*
+ * recover real object type in case
+ * check_object() wanted to re-use a delta,
+ * but we couldn't since base was in previous split pack
+ */
+ obj_type = type;
}
+ /* compress the data to store and put compressed length in datalen */
+ memset(&stream, 0, sizeof(stream));
+ deflateInit(&stream, pack_compression_level);
+ maxsize = deflateBound(&stream, size);
+ out = xmalloc(maxsize);
+ /* Compress it */
+ stream.next_in = buf;
+ stream.avail_in = size;
+ stream.next_out = out;
+ stream.avail_out = maxsize;
+ while (deflate(&stream, Z_FINISH) == Z_OK)
+ /* nothing */;
+ deflateEnd(&stream);
+ datalen = stream.total_out;
+ deflateEnd(&stream);
/*
* The object header is a byte of 'type' followed by zero or
* more bytes of length.
*/
hdrlen = encode_header(obj_type, size, header);
- sha1write(f, header, hdrlen);
if (obj_type == OBJ_OFS_DELTA) {
/*
@@ -409,21 +450,41 @@ static unsigned long write_object(struct sha1file *f,
* base from this object's position in the pack.
*/
off_t ofs = entry->offset - entry->delta->offset;
- unsigned pos = sizeof(header) - 1;
- header[pos] = ofs & 127;
+ unsigned pos = sizeof(dheader) - 1;
+ dheader[pos] = ofs & 127;
while (ofs >>= 7)
- header[--pos] = 128 | (--ofs & 127);
- sha1write(f, header + pos, sizeof(header) - pos);
- hdrlen += sizeof(header) - pos;
+ dheader[--pos] = 128 | (--ofs & 127);
+ if (limit && hdrlen + sizeof(dheader) - pos + datalen + 20 >= limit) {
+ free(out);
+ free(buf);
+ return 0;
+ }
+ sha1write(f, header, hdrlen);
+ sha1write(f, dheader + pos, sizeof(dheader) - pos);
+ hdrlen += sizeof(dheader) - pos;
} else if (obj_type == OBJ_REF_DELTA) {
/*
* Deltas with a base reference contain
* an additional 20 bytes for the base sha1.
*/
+ if (limit && hdrlen + 20 + datalen + 20 >= limit) {
+ free(out);
+ free(buf);
+ return 0;
+ }
+ sha1write(f, header, hdrlen);
sha1write(f, entry->delta->sha1, 20);
hdrlen += 20;
+ } else {
+ if (limit && hdrlen + datalen + 20 >= limit) {
+ free(out);
+ free(buf);
+ return 0;
+ }
+ sha1write(f, header, hdrlen);
}
- datalen = sha1write_compressed(f, buf, size, pack_compression_level);
+ sha1write(f, out, datalen);
+ free(out);
free(buf);
}
else {
@@ -438,20 +499,6 @@ static unsigned long write_object(struct sha1file *f,
reused_delta++;
}
hdrlen = encode_header(obj_type, entry->size, header);
- sha1write(f, header, hdrlen);
- if (obj_type == OBJ_OFS_DELTA) {
- off_t ofs = entry->offset - entry->delta->offset;
- unsigned pos = sizeof(header) - 1;
- header[pos] = ofs & 127;
- while (ofs >>= 7)
- header[--pos] = 128 | (--ofs & 127);
- sha1write(f, header + pos, sizeof(header) - pos);
- hdrlen += sizeof(header) - pos;
- } else if (obj_type == OBJ_REF_DELTA) {
- sha1write(f, entry->delta->sha1, 20);
- hdrlen += 20;
- }
-
offset = entry->in_pack_offset;
revidx = find_packed_object(p, offset);
datalen = revidx[1].offset - offset;
@@ -460,6 +507,29 @@ static unsigned long write_object(struct sha1file *f,
die("bad packed object CRC for %s", sha1_to_hex(entry->sha1));
offset += entry->in_pack_header_size;
datalen -= entry->in_pack_header_size;
+ if (obj_type == OBJ_OFS_DELTA) {
+ off_t ofs = entry->offset - entry->delta->offset;
+ unsigned pos = sizeof(dheader) - 1;
+ dheader[pos] = ofs & 127;
+ while (ofs >>= 7)
+ dheader[--pos] = 128 | (--ofs & 127);
+ if (limit && hdrlen + sizeof(dheader) - pos + datalen + 20 >= limit)
+ return 0;
+ sha1write(f, header, hdrlen);
+ sha1write(f, dheader + pos, sizeof(dheader) - pos);
+ hdrlen += sizeof(dheader) - pos;
+ } else if (obj_type == OBJ_REF_DELTA) {
+ if (limit && hdrlen + 20 + datalen + 20 >= limit)
+ return 0;
+ sha1write(f, header, hdrlen);
+ sha1write(f, entry->delta->sha1, 20);
+ hdrlen += 20;
+ } else {
+ if (limit && hdrlen + datalen + 20 >= limit)
+ return 0;
+ sha1write(f, header, hdrlen);
+ }
+
if (!pack_to_stdout && p->index_version == 1 &&
check_pack_inflate(p, &w_curs, offset, datalen, entry->size))
die("corrupt packed object for %s", sha1_to_hex(entry->sha1));
@@ -467,7 +537,7 @@ static unsigned long write_object(struct sha1file *f,
unuse_pack(&w_curs);
reused++;
}
- if (entry->delta)
+ if (usable_delta)
written_delta++;
written++;
if (!pack_to_stdout)
@@ -486,11 +556,18 @@ static off_t write_one(struct sha1file *f,
return offset;
/* if we are deltified, write out base object first. */
- if (e->delta)
+ if (e->delta) {
offset = write_one(f, e->delta, offset);
+ if (!offset)
+ return 0;
+ }
e->offset = offset;
- size = write_object(f, e);
+ size = write_object(f, e, offset);
+ if (!size) {
+ e->offset = 0;
+ return 0;
+ }
/* make sure off_t is sufficiently large not to wrap */
if (offset > offset + size)
--
1.5.2.rc3.726.g279d
[-- Attachment #5: 0003-git-repack-max-pack-size-split-packs-as-asked-by.patch --]
[-- Type: text/plain, Size: 6712 bytes --]
>From 9ec3af1f52f41d0737b6271fded5e94527eb0466 Mon Sep 17 00:00:00 2001
From: Dana L. How <danahow@gmail.com>
Date: Sun, 13 May 2007 12:09:16 -0700
Subject: [PATCH 3/4] git-repack --max-pack-size: split packs as asked by write_{object,one}()
Rewrite write_pack_file() to break to a new packfile
whenever write_object/write_one request it, and
correct the header's object count in the previous packfile.
Change write_index_file() to write an index
for just the objects in the most recent packfile.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
builtin-pack-objects.c | 120 ++++++++++++++++++++++++++++-------------------
1 files changed, 71 insertions(+), 49 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3023aac..ce9eb2d 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -568,6 +568,7 @@ static off_t write_one(struct sha1file *f,
e->offset = 0;
return 0;
}
+ written_list[nr_written++] = e;
/* make sure off_t is sufficiently large not to wrap */
if (offset > offset + size)
@@ -587,47 +588,57 @@ static int adjust_perm(const char *path, mode_t mode);
static void write_pack_file(void)
{
- uint32_t i;
+ uint32_t i = 0, j;
struct sha1file *f;
- off_t offset, last_obj_offset = 0;
+ off_t offset, offset_one, last_obj_offset = 0;
struct pack_header hdr;
- int do_progress = progress;
-
- if (pack_to_stdout) {
- f = sha1fd(1, "<stdout>");
- do_progress >>= 1;
- } else {
- int fd = open_object_dir_tmp("tmp_pack_XXXXXX");
- if (fd < 0)
- die("unable to create %s: %s\n", tmpname, strerror(errno));
- pack_tmp_name = xstrdup(tmpname);
- f = sha1fd(fd, pack_tmp_name);
- }
+ int do_progress = progress >> pack_to_stdout;
+ uint32_t nr_remaining = nr_result;
if (do_progress)
start_progress(&progress_state, "Writing %u objects...", "", nr_result);
+ written_list = xmalloc(nr_objects * sizeof(struct object_entry *));
- hdr.hdr_signature = htonl(PACK_SIGNATURE);
- hdr.hdr_version = htonl(PACK_VERSION);
- hdr.hdr_entries = htonl(nr_result);
- sha1write(f, &hdr, sizeof(hdr));
- offset = sizeof(hdr);
- if (!nr_result)
- goto done;
- for (i = 0; i < nr_objects; i++) {
- last_obj_offset = offset;
- offset = write_one(f, objects + i, offset);
- if (do_progress)
- display_progress(&progress_state, written);
- }
- if (do_progress)
- stop_progress(&progress_state);
- done:
- if (written != nr_result)
- die("wrote %u objects while expecting %u", written, nr_result);
- sha1close(f, pack_file_sha1, 1);
+ do {
+ if (pack_to_stdout) {
+ f = sha1fd(1, "<stdout>");
+ } else {
+ int fd = open_object_dir_tmp("tmp_pack_XXXXXX");
+ if (fd < 0)
+ die("unable to create %s: %s\n", tmpname, strerror(errno));
+ pack_tmp_name = xstrdup(tmpname);
+ f = sha1fd(fd, pack_tmp_name);
+ }
- if (!pack_to_stdout) {
+ hdr.hdr_signature = htonl(PACK_SIGNATURE);
+ hdr.hdr_version = htonl(PACK_VERSION);
+ hdr.hdr_entries = htonl(nr_remaining);
+ sha1write(f, &hdr, sizeof(hdr));
+ offset = sizeof(hdr);
+ nr_written = 0;
+ for (; i < nr_objects; i++) {
+ last_obj_offset = offset;
+ offset_one = write_one(f, objects + i, offset);
+ if (!offset_one)
+ break;
+ offset = offset_one;
+ if (do_progress)
+ display_progress(&progress_state, written);
+ }
+
+ /*
+ * Did we write the wrong # entries in the header?
+ * If so, rewrite it like in fast-import
+ */
+ if (pack_to_stdout || nr_written == nr_remaining) {
+ sha1close(f, pack_file_sha1, 1);
+ } else {
+ sha1close(f, pack_file_sha1, 0);
+ fixup_pack_header_footer(f->fd, pack_file_sha1, pack_tmp_name, nr_written);
+ close(f->fd);
+ }
+
+ if (!pack_to_stdout) {
unsigned char object_list_sha1[20];
mode_t mode = umask(0);
@@ -652,7 +663,26 @@ static void write_pack_file(void)
die("unable to rename temporary index file: %s",
strerror(errno));
puts(sha1_to_hex(object_list_sha1));
+ }
+
+ /* mark written objects as written to previous pack */
+ for (j = 0; j < nr_written; j++) {
+ written_list[j]->offset = (off_t)-1;
+ }
+ nr_remaining -= nr_written;
+ } while (nr_remaining && i < nr_objects);
+
+ free(written_list);
+ if (do_progress)
+ stop_progress(&progress_state);
+ if (written != nr_result)
+ die("wrote %u objects while expecting %u", written, nr_result);
+ for (j = 0; i < nr_objects; i++) {
+ struct object_entry *e = objects + i;
+ j += !e->offset && !e->preferred_base;
}
+ if (j)
+ die("wrote %u objects as expected but %u unwritten", written, j);
}
static int sha1_sort(const void *_a, const void *_b)
@@ -679,18 +709,11 @@ static void write_index_file(off_t last_obj_offset, unsigned char *sha1)
idx_tmp_name = xstrdup(tmpname);
f = sha1fd(fd, idx_tmp_name);
- if (nr_result) {
- uint32_t j = 0;
- sorted_by_sha =
- xcalloc(nr_result, sizeof(struct object_entry *));
- for (i = 0; i < nr_objects; i++)
- if (!objects[i].preferred_base)
- sorted_by_sha[j++] = objects + i;
- if (j != nr_result)
- die("listed %u objects while expecting %u", j, nr_result);
- qsort(sorted_by_sha, nr_result, sizeof(*sorted_by_sha), sha1_sort);
+ if (nr_written) {
+ sorted_by_sha = written_list;
+ qsort(sorted_by_sha, nr_written, sizeof(*sorted_by_sha), sha1_sort);
list = sorted_by_sha;
- last = sorted_by_sha + nr_result;
+ last = sorted_by_sha + nr_written;
} else
sorted_by_sha = list = last = NULL;
@@ -728,7 +751,7 @@ static void write_index_file(off_t last_obj_offset, unsigned char *sha1)
/* Write the actual SHA1 entries. */
list = sorted_by_sha;
- for (i = 0; i < nr_result; i++) {
+ for (i = 0; i < nr_written; i++) {
struct object_entry *entry = *list++;
if (index_version < 2) {
uint32_t offset = htonl(entry->offset);
@@ -743,7 +766,7 @@ static void write_index_file(off_t last_obj_offset, unsigned char *sha1)
/* write the crc32 table */
list = sorted_by_sha;
- for (i = 0; i < nr_objects; i++) {
+ for (i = 0; i < nr_written; i++) {
struct object_entry *entry = *list++;
uint32_t crc32_val = htonl(entry->crc32);
sha1write(f, &crc32_val, 4);
@@ -751,7 +774,7 @@ static void write_index_file(off_t last_obj_offset, unsigned char *sha1)
/* write the 32-bit offset table */
list = sorted_by_sha;
- for (i = 0; i < nr_objects; i++) {
+ for (i = 0; i < nr_written; i++) {
struct object_entry *entry = *list++;
uint32_t offset = (entry->offset <= index_off32_limit) ?
entry->offset : (0x80000000 | nr_large_offset++);
@@ -776,7 +799,6 @@ static void write_index_file(off_t last_obj_offset, unsigned char *sha1)
sha1write(f, pack_file_sha1, 20);
sha1close(f, NULL, 1);
- free(sorted_by_sha);
SHA1_Final(sha1, &ctx);
}
--
1.5.2.rc3.726.g279d
[-- Attachment #6: 0004-git-repack-max-pack-size-add-option-parsing-to-en.patch --]
[-- Type: text/plain, Size: 4311 bytes --]
>From 279d1f9e0e7265c6ccf8759bbe8c5539bf3089fa Mon Sep 17 00:00:00 2001
From: Dana L. How <danahow@gmail.com>
Date: Sun, 13 May 2007 12:47:09 -0700
Subject: [PATCH 4/4] git-repack --max-pack-size: add option parsing to enable feature
Add --max-pack-size parsing and usage messages.
Upgrade git-repack.sh to handle multiple packfile names,
and build packfiles in GIT_OBJECT_DIRECTORY not GIT_DIR.
Update documentation.
Signed-off-by: Dana L. How <danahow@gmail.com>
---
Documentation/git-pack-objects.txt | 5 +++++
Documentation/git-repack.txt | 5 +++++
builtin-pack-objects.c | 9 ++++++++-
git-repack.sh | 14 ++++++++------
4 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 2531238..cfe127a 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -85,6 +85,11 @@ base-name::
times to get to the necessary object.
The default value for --window is 10 and --depth is 50.
+--max-pack-size=<n>::
+ Maximum size of each output packfile, expressed in MiB.
+ If specified, multiple packfiles may be created.
+ The default is unlimited.
+
--incremental::
This flag causes an object already in a pack ignored
even if it appears in the standard input.
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index cc3b0b2..2847c9b 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -65,6 +65,11 @@ OPTIONS
to be applied that many times to get to the necessary object.
The default value for --window is 10 and --depth is 50.
+--max-pack-size=<n>::
+ Maximum size of each output packfile, expressed in MiB.
+ If specified, multiple packfiles may be created.
+ The default is unlimited.
+
Configuration
-------------
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index ce9eb2d..930b57a 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -15,7 +15,7 @@
#include "progress.h"
static const char pack_usage[] = "\
-git-pack-objects [{ -q | --progress | --all-progress }] \n\
+git-pack-objects [{ -q | --progress | --all-progress }] [--max-pack-size=N] \n\
[--local] [--incremental] [--window=N] [--depth=N] \n\
[--no-reuse-delta] [--no-reuse-object] [--delta-base-offset] \n\
[--non-empty] [--revs [--unpacked | --all]*] [--reflog] \n\
@@ -1713,6 +1713,13 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
pack_compression_level = level;
continue;
}
+ if (!prefixcmp(arg, "--max-pack-size=")) {
+ char *end;
+ pack_size_limit = strtoul(arg+16, &end, 0) * 1024 * 1024;
+ if (!arg[16] || *end)
+ usage(pack_usage);
+ continue;
+ }
if (!prefixcmp(arg, "--window=")) {
char *end;
window = strtoul(arg+9, &end, 0);
diff --git a/git-repack.sh b/git-repack.sh
index 8bf66a4..4ea6e5b 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]'
+USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--depth=N]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
@@ -18,6 +18,7 @@ do
-q) quiet=-q ;;
-f) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
+ --max-pack-size=*) extra="$extra $1" ;;
--window=*) extra="$extra $1" ;;
--depth=*) extra="$extra $1" ;;
*) usage ;;
@@ -35,7 +36,7 @@ true)
esac
PACKDIR="$GIT_OBJECT_DIRECTORY/pack"
-PACKTMP="$GIT_DIR/.tmp-$$-pack"
+PACKTMP="$GIT_OBJECT_DIRECTORY/.tmp-$$-pack"
rm -f "$PACKTMP"-*
trap 'rm -f "$PACKTMP"-*' 0 1 2 3 15
@@ -62,11 +63,12 @@ case ",$all_into_one," in
esac
args="$args $local $quiet $no_reuse$extra"
-name=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git-pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
-if [ -z "$name" ]; then
+if [ -z "$names" ]; then
echo Nothing new to pack.
-else
+fi
+for name in $names ; do
chmod a-w "$PACKTMP-$name.pack"
chmod a-w "$PACKTMP-$name.idx"
if test "$quiet" != '-q'; then
@@ -92,7 +94,7 @@ else
exit 1
}
rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
-fi
+done
if test "$remove_redundant" = t
then
--
1.5.2.rc3.726.g279d
^ permalink raw reply related
* Re: [PATCH 10/10] user-manual: listing commits reachable from some refs not others
From: Frank Lichtenheld @ 2007-05-14 15:48 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
On Mon, May 14, 2007 at 11:21:29AM -0400, J. Bruce Fields wrote:
> +Suppose you would like to see all the commits reachable from the branch
> +head named "master" but not from any other head in your repository.
This should probably be "maint", because later you have:
> +And then we can ask to see all the commits reachable from maint
> +but not from these other heads:
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 08/10] user-manual: add a "counting commits" example
From: Frank Lichtenheld @ 2007-05-14 15:51 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Junio C Hamano, git
On Mon, May 14, 2007 at 11:21:27AM -0400, J. Bruce Fields wrote:
> +Suppose you want to know how many commits you've made on "mybranch"
> +since it diverged from "origin":
> +
> +-------------------------------------------------
> +$ git log --pretty=oneline origin..maint | wc -l
> +-------------------------------------------------
Shouldn't that be mybranch instead of maint?
> +Alternatively you may often see this sort of thing done with the
> +lower-level command gitlink:git-rev-list[1], which just lists the SHA1's
> +of all the given commits:
> +
> +-------------------------------------------------
> +$ git rev-list origin..maint | wc -l
> +-------------------------------------------------
Same here.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 08/10] user-manual: add a "counting commits" example
From: J. Bruce Fields @ 2007-05-14 16:03 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Junio C Hamano, git
In-Reply-To: <20070514155111.GE5272@planck.djpig.de>
On Mon, May 14, 2007 at 05:51:11PM +0200, Frank Lichtenheld wrote:
> On Mon, May 14, 2007 at 11:21:27AM -0400, J. Bruce Fields wrote:
> > +Suppose you want to know how many commits you've made on "mybranch"
> > +since it diverged from "origin":
> > +
> > +-------------------------------------------------
> > +$ git log --pretty=oneline origin..maint | wc -l
> > +-------------------------------------------------
>
> Shouldn't that be mybranch instead of maint?
>
> > +Alternatively you may often see this sort of thing done with the
> > +lower-level command gitlink:git-rev-list[1], which just lists the SHA1's
> > +of all the given commits:
> > +
> > +-------------------------------------------------
> > +$ git rev-list origin..maint | wc -l
> > +-------------------------------------------------
>
> Same here.
Yep, thanks for the sharp eyes.
--b.
^ permalink raw reply
* [PATCH] user-manual: fix branch names in examples
From: J. Bruce Fields @ 2007-05-14 16:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Frank Lichtenheld, git
In-Reply-To: <20070514160335.GA20736@fieldses.org>
Thanks to Frank Lichtenheld for pointing out inconsistent use of branch
names in a couple examples.
Add a little more example output while I'm at it.
At some point actually it might be good for someone to figure out a good
example to use consistently throughout the manual and tutorials; it
might make them a little easier to read.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
Documentation/user-manual.txt | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 9fc2bba..5fb86f2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -701,7 +701,7 @@ Suppose you want to know how many commits you've made on "mybranch"
since it diverged from "origin":
-------------------------------------------------
-$ git log --pretty=oneline origin..maint | wc -l
+$ git log --pretty=oneline origin..mybranch | wc -l
-------------------------------------------------
Alternatively you may often see this sort of thing done with the
@@ -709,7 +709,7 @@ lower-level command gitlink:git-rev-list[1], which just lists the SHA1's
of all the given commits:
-------------------------------------------------
-$ git rev-list origin..maint | wc -l
+$ git rev-list origin..mybranch | wc -l
-------------------------------------------------
[[checking-for-equal-branches]]
@@ -849,19 +849,23 @@ a07157ac624b2524a059a3414e99f6f44bebc1e7 refs/heads/master
1e87486ae06626c2f31eaa63d26fc0fd646c8af2 refs/heads/tutorial-fixes
-------------------------------------------------
-We can get just the branch-head names, and remove "maint", with
+We can get just the branch-head names, and remove "master", with
the help of the standard utilities cut and grep:
-------------------------------------------------
-$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/maint'
+$ git show-ref --heads | cut -d' ' -f2 | grep -v '^refs/heads/master'
+refs/heads/core-tutorial
+refs/heads/maint
+refs/heads/tutorial-2
+refs/heads/tutorial-fixes
-------------------------------------------------
-And then we can ask to see all the commits reachable from maint
+And then we can ask to see all the commits reachable from master
but not from these other heads:
-------------------------------------------------
-$ gitk maint --not $( git show-ref --heads | cut -d' ' -f2 |
- grep -v '^refs/heads/maint' )
+$ gitk master --not $( git show-ref --heads | cut -d' ' -f2 |
+ grep -v '^refs/heads/master' )
-------------------------------------------------
Obviously endless variations are possible; to see all commits
--
1.5.1.4.19.g69e2
^ permalink raw reply related
* git log and merge commits
From: Geert Uytterhoeven @ 2007-05-14 16:13 UTC (permalink / raw)
To: git; +Cc: Geert Uytterhoeven
Hi,
I noticed `git log -p' doesn't show the changes introduced by merge commits.
This is true for plain `git log -p' and for `git log -p <filename>'.
Using `git show <commit-id>' does show the changes.
As I noticed the problem originally in a non-public repository, it was a bit
difficult to report. But I've just found an example in linux.git, too:
`git show 5cd47155155a32e5b944ac9fc3f3dc578e429aa0' shows the merge commit.
But `git log -p include/asm-arm/arch-ixp4xx/io.h' doesn't show it.
It happens in git 1.4.4.4 (what I'm using regularly), but also in 1.5.1.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium
^ permalink raw reply
* Re: git.or.cz IPv6
From: Jeffrey C. Ollie @ 2007-05-14 16:30 UTC (permalink / raw)
To: git
In-Reply-To: <20070514124518.GO18965@albany.tokkee.org>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
On Mon, 2007-05-14 at 14:45 +0200, Sebastian Harl wrote:
>
> It works fine for me - might be fixed by now:
>
> traceroute to rover.or.cz (2a01:b0:0:2::) from 2001:780:106::f1, 30 hops max, 1s
> [...]
> 5 so-1-0-0.fra40.ip6.tiscali.net (2001:668:0:2::4b0) 4.971 ms 4.962 ms 4.9s 6 so-0-0-0.dus11.ip6.tiscali.net (2001:668:0:2::1:1) 8.468 ms 8.45 ms 8.55s
> 7 so-0-0-0.ham10.ip6.tiscali.net (2001:668:0:2::101) 13.964 ms 13.683 ms 1s
> 8 rover.xs26.eu (2a01:b0:0:2::) 37.079 ms 37.146 ms 37.145 ms
Nope, I still get timeouts after so-0-0-0.ham10.ip6.tiscali.net. Can
you check the ipv6 routing table on rover.xs26.eu?
Jeff
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: [PATCH 07/10] user-manual: move howto/using-topic-branches into manual
From: Luck, Tony @ 2007-05-14 16:30 UTC (permalink / raw)
To: J. Bruce Fields, Junio C Hamano; +Cc: git
In-Reply-To: <11791560901-git-send-email->
Not annoying at all.
There are a few places where the text still references my "linus"
branch ... you fixed up the start of the document to switch this
over to the more standard "origin".
-Tony
^ permalink raw reply
* Re: [RFC] Optimize diff-delta.c
From: Nicolas Pitre @ 2007-05-14 16:34 UTC (permalink / raw)
To: Martin Koegler; +Cc: git
In-Reply-To: <1179089413753-git-send-email-mkoegler@auto.tuwien.ac.at>
On Sun, 13 May 2007, Martin Koegler wrote:
> ---
> On Fri, 04 May 2007, Nicolas Pitre wrote:
> > On Fri, 4 May 2007, Martin Koegler wrote:
> > > On 2007-05-01 16:05:24, Nicolas Pitre wrote:
> > > In the long term, I think, that the delta generation code needs to get
> > > tunable.
> >
> > No. It should be self-tunable certainly, but there are way too many
> > config options already, and another one for the inner working of the
> > delta algorithm would be a bit too esoteric for most users and they
> > won't get advantage of it. This thing really has to self tune itself.
>
> I would like that too, but that will probably not the case for
> everybody.
>
> Why does git has options to control the zlib compression?
>
> Why are patches like "Custom compression levels for objects and packs"
> (http://www.spinics.net/lists/git/msg30244.html) sent to the mailing
> list?
Because there is no nice ways to auto-tune them given the current zlib
interface.
> > > > > I tried to speed up the delta generation by searching for a common
> > > > > prefix, as my blobs are mostly append only. I tested it with about
> > > > > less than 1000 big blobs. The time for finding the deltas decreased
> > > > > from 17 to 14 minutes cpu time.
> > > >
> > > > I'm surprised that your patch makes so much of a difference. Normally
> > > > the first window should always match in the case you're trying to
> > > > optimize and the current code should already perform more or less the
> > > > same as your common prefix match does.
> > >
> > > A block is limited to 64k. If the file has some hundred MBs, it has to
> > > match many blocks.
> >
> > Only if the first match is smaller than 64K. If the first match is 64K
> > in size then the rest of the file is not considered at all.
>
> If I read the code correctly, the currect code does a new hash table
> search after writing a block.
Right.
> As my original patch is not considering other and possibly better
> matches, I rewrote the patch. The new version matches block of
> unlimited length (stopping after finding a match >=64kB). If the block
> it bigger than 64kB, it writes block of 64kB in a loop.
I like this idea a lot.
> The patch recomputes the hash of 16 bytes after writing a block, as I
> haven't had time to correct the hash update code for blocks < 16
> bytes. (By the way, is this code path necessary?)
It certainly helps in those cases where the block match is smaller than
a Rabin window size, although I don't know how much. Sliding the window
over 8 bytes might be approximately the same cost as computing the
hash from scratch over 16 bytes since in the sliding case there are
twice the amount of pointer dereferences. So the test should probably
be "if (msize >= RABIN_WINDOW/2) ..." for the full reinitialization.
> I did some tests on differenent machines:
>
> Repacking a test repository with big blobs:
>
> - original version:
> Total 6452 (delta 4582), reused 1522 (delta 0)
> 11752.26user 4256.21system 4:26:52elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (576major+1042499851minor)pagefaults 0swaps
> =>92 MB pack size
> - your patch (stop at 4096 bytes block size):
> Total 6452 (delta 4582), reused 1522 (delta 0)
> 11587.41user 4064.73system 4:20:54elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+1042500427minor)pagefaults 0swaps
> =>92 MB pack size
> - my first patch
> Total 6452 (delta 4706), reused 1450 (delta 0)
> 10316.93user 4220.67system 4:02:20elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+1045003394minor)pagefaults 0swaps
> =>92 MB pack size
> - attached patch
> Total 6452 (delta 4581), reused 1522 (delta 0)
> 11354.38user 5451.60system 4:40:09elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+1371504762minor)pagefaults 0swaps
> =>75 MB pack size
This is quite weird. I wonder what might cause such a large difference
in pack size.
Your first patch is probably faster due to the use of memcmp() which is
certainly highly optimized, more than the comparison loop we have. It
is unfortunate that there is no library function to find the number of
identical bytes between two buffers. Or is there some?
But the size difference? That has certainly something to do with your
data set since your patch makes no significant difference on the git.git
nor the Linux kernel repos. Would it be possible for me to have a copy
of your repo for further analysis?
Nicolas
^ permalink raw reply
* Re: suggestions for gitweb
From: Jakub Narebski @ 2007-05-14 16:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Michael Niedermayer, Junio C Hamano, git
In-Reply-To: <20070514095857.GI4489@pasky.or.cz>
On Mon, 14 May 2007, Petr Baudis <pasky@suse.cz> wrote:
> On Mon, May 14, 2007 at 10:53:15AM CEST, Michael Niedermayer wrote:
>> also file size and last modified dates would be interresting on the tree
>> page
>> viewvc displays on its equivalent page, time since last change
>> svn revission of the last change, the author/commiter of the last change
>> and the corresponding abbreviated log entry
>
> I guess this is much easier to retrieve in svn than in git - you
> actually have to walk all the history to figure out this information as
> there's no global per-file info; so this is very troublesome
> performance-wise. I think there were some patches on the mailinglist
> that dit this, though I'm not sure. Might be reasonable to cache this
> (and git history properties make it possible to nicely make a very
> easily reusable cache for this information).
I have sent some implementations of tree_blame, without any core
support, directly in Perl (in gitweb), just like early versions of
git-annotate. It did suck performance-wise quite a bit. You can find
it in 'gitweb/tree_blame' branch in my git repository at repo.or.cz
http://repo.or.cz/w/git/jnareb-git.git?a=shortlog;h=gitweb/tree_blame
I think it would be nice to have --blame option to git-ls-tree
(optionally copuled with --porcelain and perhaps --incremental, like
in git-blame), which would return blame information for tree entries.
It means that for each tree entry return commit closest to given commit
(or furthest from a given commit) which has changed entry to current
version. It should be much easier and faster than to do "blob"-blame.
The --porcelain would also return 'last changed' info, like committer
info for a commit-which-changed.
But is this info actually interesting, or is it there in ViewVC because
it is easy to get this info in CVS and Subversion? The "last changed"
info for tree entries encourages to think of a history as a collection
of per file histories... while git is all about whole project history.
Note that history of two files is *more* than concatenation of
histories of those individual files. See entries on GitFaq wiki page:
> About file sizes, that also has some extra performance hit, but in
> this case I suspect that it would be totally negligible (if implemented
> at the plumbing level) - and I admit that I would like to see file sizes
> too, they can help orientation in a foreign source tree a lot.
It should be very easy to add --long / --sizes option to git-ls-tree
which would return file sizes, perhaps after mode info.
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: Do not use absolute font sizes
From: Jakub Narebski @ 2007-05-14 16:53 UTC (permalink / raw)
To: git
In-Reply-To: <20070509014150.7477.48489.stgit@rover>
Petr Baudis wrote:
> Note that this patch actually does change visual look of gitweb in Firefox
> with my resolution and default settings - everything is bigger and I can't
> explain the joy of actually seeing gitweb text that is in _readable_ size;
> also, my horizontal screen real estate feels better used now.
Not everyone has those huge monitors with extreme resultion. For me new
gitweb look uses much to big font, so not very much fits in screen.
I'd remove
> --- a/gitweb/gitweb.css
> +++ b/gitweb/gitweb.css
> @@ -1,6 +1,5 @@
> body {
> font-family: sans-serif;
> - font-size: 12px;
> border: solid #d9d8d1;
> border-width: 1px;
> margin: 10px;
chunk
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git log and merge commits
From: Jakub Narebski @ 2007-05-14 16:56 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.62.0705141803590.11269@pademelon.sonytel.be>
[Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
git@vger.kernel.org]
Geert Uytterhoeven wrote:
> I noticed `git log -p' doesn't show the changes introduced by merge commits.
> This is true for plain `git log -p' and for `git log -p <filename>'.
Have you tried `git log -p --cc'?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 03/10] glossary: expand and clarify some definitions, prune cross-references
From: Jakub Narebski @ 2007-05-14 17:00 UTC (permalink / raw)
To: git
In-Reply-To: <5520.48510076037$1179156136@news.gmane.org>
J. Bruce Fields wrote:
> +[[def_detached_HEAD]]detached HEAD::
> + Normally HEAD refers to the tip of a
> + <<def_branch,branch>>.
Normally HEAD refers to the branch _name_ (names current branch).
From this sentence one can think that normally HEAD is pointer
to commit which is tip of current branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox