Re: your mail

Re: your mail

[Elfyn McBratney]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Wed, Oct 05, 2005 at 08:10:24AM +0200, Willem Swart wrote:
 > subscribe git
 > -
 > To unsubscribe from this list: send the line "unsubscribe git" in
 > the body of a message to majordomo@vger.kernel.org
 > More majordomo info at  http://vger.kernel.org/majordomo-info.html
s/unsubscribe/subscribe/g

Might want to re-send that to majordomo@vger.kernel.org ;)

Best,
Elfyn

-- 
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

(unknown)

[J. Bruce Fields]

>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:52:34 -0400
Subject: [PATCH 1/3] tutorial: replace "whatchanged" by "log"

Junio suggested changing references to git-whatchanged to git-log.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

---

d1177b299b449e9eb63d963ee118a5e0283aa611
 Documentation/tutorial.txt |   12 ++++++------
 1 files changed, 6 insertions(+), 6 deletions(-)

d1177b299b449e9eb63d963ee118a5e0283aa611
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index fa79b01..cd0f0df 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -80,13 +80,13 @@ file; just remove it, then commit.
 At any point you can view the history of your changes using
 
 ------------------------------------------------
-$ git whatchanged
+$ git log
 ------------------------------------------------
 
 If you also want to see complete diffs at each step, use
 
 ------------------------------------------------
-$ git whatchanged -p
+$ git log -p
 ------------------------------------------------
 
 Managing branches
@@ -216,7 +216,7 @@ This actually pulls changes from the bra
 "master".  Alice could request a different branch by adding the name
 of the branch to the end of the git pull command line.
 
-This merges Bob's changes into her repository; "git whatchanged" will
+This merges Bob's changes into her repository; "git log" will
 now show the new commits.  If Alice has made her own changes in the
 meantime, then Bob's changes will be merged in, and she will need to
 manually fix any conflicts.
@@ -234,7 +234,7 @@ named bob-incoming.  (Unlike git pull, g
 of Bob's line of development without doing any merging).  Then
 
 -------------------------------------
-$ git whatchanged -p master..bob-incoming
+$ git log -p master..bob-incoming
 -------------------------------------
 
 shows a list of all the changes that Bob made since he branched from
@@ -330,13 +330,13 @@ But you may find it more useful to see t
 the experimental branch but not in the current branch, and
 
 -------------------------------------
-git whatchanged HEAD..experimental
+git log HEAD..experimental
 -------------------------------------
 
 will do that, just as
 
 -------------------------------------
-git whatchanged experimental..HEAD
+git log experimental..HEAD
 -------------------------------------
 
 will show the list of commits made on the HEAD but not included in
-- 
1.3.3.gff62

(unknown)

[J. Bruce Fields]

>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 16:54:05 -0400
Subject: [PATCH 2/3] tutorial: expanded discussion of commit history

Expand the history-browsing section of the tutorial a bit, in part to
address Junio's suggestion that we mention "git grep" and Linus's
complaint that people are missing the flexibility of the commandline
interfaces for selecting commits.

This reads a little more like a collection of examples than a
"tutorial", but maybe that's what people need at this point.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

---

bb2450ce2145bfdc5b3b7c967a5ed3571437f5d4
 Documentation/tutorial.txt |  165 ++++++++++++++++++++++++++++++--------------
 1 files changed, 112 insertions(+), 53 deletions(-)

bb2450ce2145bfdc5b3b7c967a5ed3571437f5d4
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index cd0f0df..4c298c6 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -288,103 +288,162 @@ Git can also be used in a CVS-like mode,
 that various users push changes to; see gitlink:git-push[1] and
 link:cvs-migration.html[git for CVS users].
 
-Keeping track of history
-------------------------
+Exploring history
+-----------------
 
-Git history is represented as a series of interrelated commits.  The
-most recent commit in the currently checked-out branch can always be
-referred to as HEAD, and the "parent" of any commit can always be
-referred to by appending a caret, "^", to the end of the name of the
-commit.  So, for example,
+Git history is represented as a series of interrelated commits.  We
+have already seen that the git log command can list those commits.
+Note that first line of each git log entry also gives a name for the
+commit:
 
 -------------------------------------
-git diff HEAD^ HEAD
+$ git log
+commit c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
+Author: Junio C Hamano <junkio@cox.net>
+Date:   Tue May 16 17:18:22 2006 -0700
+
+    merge-base: Clarify the comments on post processing.
 -------------------------------------
 
-shows the difference between the most-recently checked-in state of
-the tree and the previous state, and
+We can give this name to git show to see the details about this
+commit.
 
 -------------------------------------
-git diff HEAD^^ HEAD^
+$ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
 -------------------------------------
 
-shows the difference between that previous state and the state two
-commits ago.  Also, HEAD~5 can be used as a shorthand for HEAD{caret}{caret}{caret}{caret}{caret},
-and more generally HEAD~n can refer to the nth previous commit.
-Commits representing merges have more than one parent, and you can
-specify which parent to follow in that case; see
-gitlink:git-rev-parse[1].
+But there other ways to refer to commits.  You can use any initial
+part of the name that is long enough to uniquely identify the commit:
 
-The name of a branch can also be used to refer to the most recent
-commit on that branch; so you can also say things like
+-------------------------------------
+$ git show c82a22c39c	# the first few characters of the name are
+			# usually enough
+$ git show HEAD		# the tip of the current branch
+$ git show experimental	# the tip of the "experimental" branch
+-------------------------------------
+
+Every commit has at least one "parent" commit, which points to the
+previous state of the project:
 
 -------------------------------------
-git diff HEAD experimental
+$ git show HEAD^  # to see the parent of HEAD
+$ git show HEAD^^ # to see the grandparent of HEAD
+$ git show HEAD~4 # to see the great-great grandparent of HEAD
 -------------------------------------
 
-to see the difference between the most-recently committed tree in
-the current branch and the most-recently committed tree in the
-experimental branch.
+Note that merge commits may have more than one parent:
+
+-------------------------------------
+$ git show HEAD^1 # show the first parent of HEAD (same as HEAD^)
+$ git show HEAD^2 # show the second parent of HEAD
+-------------------------------------
 
-But you may find it more useful to see the list of commits made in
-the experimental branch but not in the current branch, and
+You can also give commits names of your own; after running
 
 -------------------------------------
-git log HEAD..experimental
+$ git-tag v2.5 1b2e1d63ff
 -------------------------------------
 
-will do that, just as
+you can refer to 1b2e1d63ff by the name "v2.5".  If you intend to
+share this name with other people (for example, to identify a release
+version), you should create a "tag" object, and perhaps sign it; see
+gitlink:git-tag[1] for details.
+
+Any git command that needs to know a commit can take any of these
+names.  For example:
 
 -------------------------------------
-git log experimental..HEAD
+$ git diff v2.5 HEAD	 # compare the current HEAD to v2.5
+$ git branch stable v2.5 # start a new branch named "stable" based
+			 # at v2.5
+$ git reset --hard HEAD^ # reset your current branch and working
+			 # directory its state at HEAD^
 -------------------------------------
 
-will show the list of commits made on the HEAD but not included in
-experimental.
+Be careful with that last command: in addition to losing any changes
+in the working directory, it will also remove all later commits from
+this branch.  If this branch is the only branch containing those
+commits, they will be lost.  (Also, don't use "git reset" on a
+publicly-visible branch that other developers pull from, as git will
+be confused by history that disappears in this way.)
 
-You can also give commits convenient names of your own: after running
+The git grep command can search for strings in any version of your
+project, so
 
 -------------------------------------
-$ git-tag v2.5 HEAD^^
+$ git grep "hello" v2.5
 -------------------------------------
 
-you can refer to HEAD^^ by the name "v2.5".  If you intend to share
-this name with other people (for example, to identify a release
-version), you should create a "tag" object, and perhaps sign it; see
-gitlink:git-tag[1] for details.
+searches for all occurences of "hello" in v2.5.
 
-You can revisit the old state of a tree, and make further
-modifications if you wish, using git branch: the command
+If you leave out the commit name, git grep will search any of the
+files it manages in your current directory.  So
 
 -------------------------------------
-$ git branch stable-release v2.5
+$ git grep "hello"
 -------------------------------------
 
-will create a new branch named "stable-release" starting from the
-commit which you tagged with the name v2.5.
+is a quick way to search just the files that are tracked by git.
 
-You can reset the state of any branch to an earlier commit at any
-time with
+Many git commands also take sets of commits, which can be specified
+in a number of ways.  Here are some examples with git log:
 
 -------------------------------------
-$ git reset --hard v2.5
+$ git log v2.5..v2.6            # commits between v2.5 and v2.6
+$ git log v2.5..                # commits since v2.5
+$ git log --since="2 weeks ago" # commits from the last 2 weeks
+$ git log v2.5.. Makefile       # commits since v2.5 which modify
+				# Makefile
 -------------------------------------
 
-This will remove all later commits from this branch and reset the
-working tree to the state it had when the given commit was made.  If
-this branch is the only branch containing the later commits, those
-later changes will be lost.  Don't use "git reset" on a
-publicly-visible branch that other developers pull from, as git will
-be confused by history that disappears in this way.
+You can also give git log a "range" of commits where the first is not
+necessarily an ancestor of the second; for example, if the tips of
+the branches "stable-release" and "master" diverged from a common
+commit some time ago, then
+
+-------------------------------------
+$ git log stable..experimental
+-------------------------------------
+
+will list commits made in the experimental branch but not in the
+stable branch, while
+
+-------------------------------------
+$ git log experimental..stable
+-------------------------------------
+
+will show the list of commits made on the stable branch but not
+the experimental branch.
+
+The "git log" command has a weakness: it must present commits in a
+list.  When the history has lines of development that diverged and
+then merged back together, the order in which "git log" presents
+those commits is meaningless.
+
+Most projects with multiple contributors (such as the linux kernel,
+or git itself) have frequent merges, and gitk does a better job of
+visualizing their history.  For example,
+
+-------------------------------------
+$ gitk --since="2 weeks ago" drivers/
+-------------------------------------
+
+allows you to browse any commits from the last 2 weeks of commits
+that modified files under the "drivers" directory.
+
+Finally, most commands that take filenames will optionally allow you
+to precede any filename by a commit, to specify a particular version
+fo the file:
+
+-------------------------------------
+$ git diff v2.5:Makefile HEAD:Makefile.in
+-------------------------------------
 
 Next Steps
 ----------
 
 Some good commands to explore next:
 
-  * gitlink:git-diff[1]: This flexible command does much more than
-    we've seen in the few examples above.
-
   * gitlink:git-format-patch[1], gitlink:git-am[1]: These convert
     series of git commits into emailed patches, and vice versa,
     useful for projects such as the linux kernel which rely heavily
-- 
1.3.3.gff62

(unknown)

[J. Bruce Fields]

>From nobody Mon Sep 17 00:00:00 2001
From: J. Bruce Fields <bfields@citi.umich.edu>
Date: Sun, 21 May 2006 19:49:34 -0400
Subject: [PATCH 3/3] tutorial: add discussion of index file, object database

Add a sequel to tutorial.txt which discusses the index file and
the object database.

Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>

---

e84a9b9a34794c5b9dd36f6ccc11e60daecd3003
 Documentation/Makefile       |    1 
 Documentation/tutorial-2.txt |  391 ++++++++++++++++++++++++++++++++++++++++++
 Documentation/tutorial.txt   |   28 ++-
 3 files changed, 414 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/tutorial-2.txt

e84a9b9a34794c5b9dd36f6ccc11e60daecd3003
diff --git a/Documentation/Makefile b/Documentation/Makefile
index c1af22c..2a08f59 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -7,6 +7,7 @@ MAN7_TXT=git.txt
 DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT))
 
 ARTICLES = tutorial
+ARTICLES += tutorial-2
 ARTICLES += core-tutorial
 ARTICLES += cvs-migration
 ARTICLES += diffcore
diff --git a/Documentation/tutorial-2.txt b/Documentation/tutorial-2.txt
new file mode 100644
index 0000000..a3d45ee
--- /dev/null
+++ b/Documentation/tutorial-2.txt
@@ -0,0 +1,391 @@
+A tutorial introduction to git: part two
+========================================
+
+You should work through link:tutorial.html[A tutorial introduction to
+git] before reading this tutorial.
+
+The goal of this tutorial is to introduce two fundamental pieces of
+git's architecture--the object database and the index file--and to
+provide the reader with everything necessary to understand the rest
+of the git documentation.
+
+The git object database
+-----------------------
+
+Let's start a new project and create a small amount of history:
+
+------------------------------------------------
+$ mkdir test-project
+$ cd test-project
+$ git init-db
+defaulting to local storage area
+$ echo 'hello world' > file.txt
+$ git add .
+$ git commit -a -m "initial commit"
+Committing initial tree 92b8b694ffb1675e5975148e1121810081dbdffe
+$ echo 'hello world!' >file.txt
+$ git commit -a -m "add emphasis"
+------------------------------------------------
+
+What are the 40 digits of hex that git responded to the first commit
+with?
+
+We saw in part one of the tutorial that commits have names like this.
+It turns out that every object in the git history is stored under
+such a 40-digit hex name.  That name is the SHA1 hash of the object's
+contents; among other things, this ensures that git will never store
+the same data twice (since identical data is given an identical SHA1
+name), and that the contents of a git object will never change (since
+that would change the object's name as well).
+
+We can ask git about this particular object with the cat-file
+command--just cut-and-paste from the reply to the initial commit, to
+save yourself typing all 40 hex digits:
+
+------------------------------------------------
+$ git cat-file -t 92b8b694ffb1675e5975148e1121810081dbdffe
+tree
+------------------------------------------------
+
+A tree can refer to one or more "blob" objects, each corresponding to
+a file.  In addition, a tree can also refer to other tree objects,
+thus creating a directory heirarchy.  You can examine the contents of
+any tree using ls-tree (remember that a long enough initial portion
+of the SHA1 will also work):
+
+------------------------------------------------
+$ git ls-tree 92b8b694
+100644 blob 3b18e512dba79e4c8300dd08aeb37f8e728b8dad    file.txt
+------------------------------------------------
+
+Thus we see that this tree has one file in it.  The SHA1 hash is a
+reference to that file's data:
+
+------------------------------------------------
+$ git cat-file -t 3b18e512
+blob
+------------------------------------------------
+
+A "blob" is just file data, which we can also examine with cat-file:
+
+------------------------------------------------
+$ git cat-file blob 3b18e512
+hello world
+------------------------------------------------
+
+Note that this is the old file data; so the object that git named in
+its response to the initial tree was a tree with a snapshot of the
+directory state that was recorded by the first commit.
+
+All of these objects are stored under their SHA1 names inside the git
+directory:
+
+------------------------------------------------
+$ find .git/objects/
+.git/objects/
+.git/objects/pack
+.git/objects/info
+.git/objects/3b
+.git/objects/3b/18e512dba79e4c8300dd08aeb37f8e728b8dad
+.git/objects/92
+.git/objects/92/b8b694ffb1675e5975148e1121810081dbdffe
+.git/objects/54
+.git/objects/54/196cc2703dc165cbd373a65a4dcf22d50ae7f7
+.git/objects/a0
+.git/objects/a0/423896973644771497bdc03eb99d5281615b51
+.git/objects/d0
+.git/objects/d0/492b368b66bdabf2ac1fd8c92b39d3db916e59
+.git/objects/c4
+.git/objects/c4/d59f390b9cfd4318117afde11d601c1085f241
+------------------------------------------------
+
+and the contents of these files is just the compressed data plus a
+header identifying their length and their type.  The type is either a
+blob, a tree, a commit, or a tag.  We've seen a blob and a tree now,
+so next we should look at a commit.
+
+The simplest commit to find is the HEAD commit, which we can find
+from .git/HEAD:
+
+------------------------------------------------
+$ cat .git/HEAD
+ref: refs/heads/master
+------------------------------------------------
+
+As you can see, this tells us which branch we're currently on, and it
+tells us this by naming a file under the .git directory, which itself
+contains a SHA1 name referring to a commit object, which we can
+examine with cat-file:
+
+------------------------------------------------
+$ cat .git/refs/heads/master
+c4d59f390b9cfd4318117afde11d601c1085f241
+$ git cat-file -t c4d59f39
+commit
+$ git cat-file commit c4d59f39
+tree d0492b368b66bdabf2ac1fd8c92b39d3db916e59
+parent 54196cc2703dc165cbd373a65a4dcf22d50ae7f7
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143418702 -0500
+
+add emphasis
+------------------------------------------------
+
+The "tree" object here refers to the new state of the tree:
+
+------------------------------------------------
+$ git ls-tree d0492b36
+100644 blob a0423896973644771497bdc03eb99d5281615b51    file.txt
+$ git cat-file commit a0423896
+hello world!
+------------------------------------------------
+
+and the "parent" object refers to the previous commit:
+
+------------------------------------------------
+$ git-cat-file commit 54196cc2
+tree 92b8b694ffb1675e5975148e1121810081dbdffe
+author J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+committer J. Bruce Fields <bfields@puzzle.fieldses.org> 1143414668 -0500
+
+initial commit
+------------------------------------------------
+
+The tree object is the tree we examined first, and this commit is
+unusual in that it lacks any parent.
+
+Most commits have only one parent, but it is also common for a commit
+to have multiple parents.   In that case the commit represents a
+merge, with the parent references pointing to the heads of the merged
+branches.
+
+Besides blobs, trees, and commits, the only remaining type of object
+is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
+for details.
+
+So now we know how git uses the object database to represent a
+project's history:
+
+  * "commit" objects refer to "tree" objects representing the
+    snapshot of a directory tree at a particular point in the
+    history, and refer to "parent" commits to show how they're
+    connected into the project history.
+  * "tree" objects represent the state of a single directory,
+    associating directory names to "blob" objects containing file
+    data and "tree" objects containing subdirectory information.
+  * "blob" objects contain file data without any other structure.
+  * References to commit objects at the head of each branch are
+    stored in files under .git/refs/heads/.
+  * The name of the current branch is stored in .git/HEAD.
+
+Note, by the way, that lots of commands take a tree as an argument.
+But as we can see above, a tree can be referred to in many different
+ways--by the SHA1 name for that tree, by the name of a commit that
+refers to the tree, by the name of a branch whose head refers to that
+tree, etc.--and most such commands can accept any of these names.
+
+In command synopses, the word "tree-ish" is sometimes used to
+designate such an argument.
+
+The index file
+--------------
+
+The primary tool we've been using to create commits is "git commit
+-a", which creates a commit including every change you've made to
+your working tree.  But what if you want to commit changes only to
+certain files?  Or only certain changes to certain files?
+
+If we look at the way commits are created under the cover, we'll see
+that there are more flexible ways creating commits.
+
+Continuing with our test-project, let's modify file.txt again:
+
+------------------------------------------------
+$ echo "hello world, again" >>file.txt
+------------------------------------------------
+
+but this time instead of immediately making the commit, let's take an
+intermediate step, and ask for diffs along the way to keep track of
+what's happening:
+
+------------------------------------------------
+$ git diff
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
+ +hello world, again
+$ git update-index file.txt
+$ git diff
+------------------------------------------------
+
+The last diff is empty, but no new commits have been made, and the
+head still doesn't contain the new line:
+
+------------------------------------------------
+$ git-diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
+ +hello world, again
+------------------------------------------------
+
+So "git diff" is comparing against something other than the head.
+The thing that it's comparing against is actually the index file,
+which is stored in .git/index in a binary format, but whose contents
+we can examine with ls-files:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0       file.txt
+$ git cat-file -t 513feba2
+blob
+$ git cat-file blob 513feba2
+hello world, again
+------------------------------------------------
+
+So what our "git update-index" did was store a new blob and then put
+a reference to it in the index file.  If we modify the file again,
+we'll see that the new modifications are reflected in the "git-diff"
+output:
+
+------------------------------------------------
+$ echo 'again?' >>file.txt
+$ git diff
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+With the right arguments, git diff can also show us the difference
+between the working directory and the last commit, or between the
+index and the last commit:
+
+------------------------------------------------
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index a042389..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,3 @@
+ hello world!
++hello world, again
++again?
+$ git diff --cached
+diff --git a/file.txt b/file.txt
+index a042389..513feba 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1 +1,2 @@
+ hello world!
++hello world, again
+------------------------------------------------
+
+At any time, we can create a new commit using "git commit" (without
+the -a option), and verify that the state committed only includes the
+changes stored in the index file, not the additional change that is
+still only in our working tree:
+
+------------------------------------------------
+$ git commit -m "repeat"
+$ git diff HEAD
+diff --git a/file.txt b/file.txt
+index 513feba..ba3da7b 100644
+--- a/file.txt
++++ b/file.txt
+@@ -1,2 +1,3 @@
+ hello world!
+ hello world, again
++again?
+------------------------------------------------
+
+So by default "git commit" uses the index to create the commit, not
+the working tree; the -a option to commit tells it to first update
+the index with all changes in the working tree.
+
+Finally, it's worth looking at the effect of "git add" on the index
+file:
+
+------------------------------------------------
+$ echo "goodbye, world" >closing.txt
+$ git add closing.txt
+------------------------------------------------
+
+The effect of the "git add" was to add one entry to the index file:
+
+------------------------------------------------
+$ git ls-files --stage
+100644 8b9743b20d4b15be3955fc8d5cd2b09cd2336138 0       closing.txt
+100644 513feba2e53ebbd2532419ded848ba19de88ba00 0       file.txt
+------------------------------------------------
+
+And, as you can see with cat-file, this new entry refers to the
+current contents of the file:
+
+------------------------------------------------
+$ git cat-file blob a6b11f7a
+goodbye, word
+------------------------------------------------
+
+The "status" command is a useful way to get a quick summary of the
+situation:
+
+------------------------------------------------
+$ git status
+#
+# Updated but not checked in:
+#   (will commit)
+#
+#       new file: closing.txt
+#
+#
+# Changed but not updated:
+#   (use git-update-index to mark for commit)
+#
+#       modified: file.txt
+#
+------------------------------------------------
+
+Since the current state of closing.txt is cached in the index file,
+it is listed as "updated but not checked in".  Since file.txt has
+changes in the working directory that aren't reflected in the index,
+it is marked "changed but not updated".  At this point, running "git
+commit" would create a commit that added closing.txt (with its new
+contents), but that didn't modify file.txt.
+
+Also, note that a bare "git diff" shows the changes to file.txt, but
+not the addition of closing.txt, because the version of closing.txt
+in the index file is identical to the one in the working directory.
+
+In addition to being the staging area for new commits, the index file
+is also populated from the object database when checking out a
+branch, and is used to hold the trees involved in a merge operation.
+See the link:core-tutorial.txt[core tutorial] and the relevant man
+pages for details.
+
+What next?
+----------
+
+At this point you should know everything necessary to read the man
+pages for any of the git commands; one good place to start would be
+with the commands mentioned in link:everday.html[Everyday git].  You
+should be able to find any unknown jargon in the
+link:glossary.html[Glosssay].
+
+The link:cvs-migration.html[CVS migration] document explains how to
+import a CVS repository into git, and shows how to use git in a
+CVS-like way.
+
+For some interesting examples of git use, see the
+link:howto-index.html[howtos].
+
+For git developers, the link:core-tutorial.html[Core tutorial] goes
+into detail on the lower-level git mechanisms involved in, for
+example, creating a new commit.
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 4c298c6..79781ad 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -442,7 +442,25 @@ fo the file:
 Next Steps
 ----------
 
-Some good commands to explore next:
+This tutorial should be enough to perform basic distributed revision
+control for your projects.  However, to fully understand the depth
+and power of git you need to understand two simple ideas on which it
+is based:
+
+  * The object database is the rather elegant system used to
+    store the history of your project--files, directories, and
+    commits.
+
+  * The index file is a cache of the state of a directory tree,
+    used to create commits, check out working directories, and
+    hold the various trees involved in a merge.
+
+link:tutorial-2.html[Part two of this tutorial] explains the object
+database, the index file, and a few other odds and ends that you'll
+need to make the most of git.
+
+If you don't want to consider with that right away, a few other
+digressions that may be interesting at this point are:
 
   * gitlink:git-format-patch[1], gitlink:git-am[1]: These convert
     series of git commits into emailed patches, and vice versa,
@@ -456,8 +474,6 @@ Some good commands to explore next:
     smart enough to perform a close-to-optimal search even in the
     case of complex non-linear history with lots of merged branches.
 
-Other good starting points include link:everyday.html[Everday GIT
-with 20 Commands Or So] and link:cvs-migration.html[git for CVS
-users].  Also, link:core-tutorial.html[A short git tutorial] gives an
-introduction to lower-level git commands for advanced users and
-developers.
+  * link:everyday.html[Everday GIT with 20 Commands Or So]
+
+  * link:cvs-migration.html[git for CVS users].
-- 
1.3.3.gff62

Re: your mail

[J. Bruce Fields]

On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>

Oops, sorry, I screwed up sending those; let me know if you'd like them
resent....

--b.

Re: your mail

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
>> >From nobody Mon Sep 17 00:00:00 2001
>> From: J. Bruce Fields <bfields@citi.umich.edu>
>
> Oops, sorry, I screwed up sending those; let me know if you'd like them
> resent....

That's OK.  I just cooked up this one ;-).

-- >8 --
From 03946787890c12fbb6ecfbe0382cbf02ac209801 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun, 21 May 2006 17:15:06 -0700
Subject: [PATCH] mailinfo: skip bogus UNIX From line inside body

Sometimes people just include the whole format-patch output in
the commit e-mail.  Detect it and skip the bogus ">From " line.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
 mailinfo.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/mailinfo.c b/mailinfo.c
index b276519..a133e6d 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -237,10 +237,17 @@ static int eatspace(char *line)
 #define SEEN_FROM 01
 #define SEEN_DATE 02
 #define SEEN_SUBJECT 04
+#define SEEN_BOGUS_UNIX_FROM 010
 
 /* First lines of body can have From:, Date:, and Subject: */
 static int handle_inbody_header(int *seen, char *line)
 {
+	if (!memcmp(">From", line, 5) && isspace(line[5])) {
+		if (!(*seen & SEEN_BOGUS_UNIX_FROM)) {
+			*seen |= SEEN_BOGUS_UNIX_FROM;
+			return 1;
+		}
+	}
 	if (!memcmp("From:", line, 5) && isspace(line[5])) {
 		if (!(*seen & SEEN_FROM) && handle_from(line+6)) {
 			*seen |= SEEN_FROM;
-- 
1.3.3.g292f

Re: totorial-2 Re: (unknown)

[Junio C Hamano]

"J. Bruce Fields" <bfields@fieldses.org> writes:

> From nobody Mon Sep 17 00:00:00 2001
> From: J. Bruce Fields <bfields@citi.umich.edu>
> Date: Sun, 21 May 2006 19:49:34 -0400
> Subject: [PATCH 3/3] tutorial: add discussion of index file, object database

Thanks.  I like the changes to tutorial.txt too btw.

> @@ -0,0 +1,391 @@
> +A tutorial introduction to git: part two
>...
> +and the contents of these files is just the compressed data plus a
> +header identifying their length and their type.  The type is either a
> +blob, a tree, a commit, or a tag.  We've seen a blob and a tree now,
> +so next we should look at a commit.
>...
> +Besides blobs, trees, and commits, the only remaining type of object
> +is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
> +for details.

We have created a tag in tutorial#1, so it _might_ make sense to
just tell the user to cat-file it.

> +------------------------------------------------
> +$ git diff
> +--- a/file.txt
> ++++ b/file.txt
> +@@ -1 +1,2 @@
> + hello world!
> + +hello world, again
> +$ git update-index file.txt
> +$ git diff
> +------------------------------------------------

Is the second line of the diff " +" intentional?  The same
comment to the example that immediately follows this part.

Re: totorial-2 Re: (unknown)

[J. Bruce Fields]

On Sun, May 21, 2006 at 05:35:46PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> > +Besides blobs, trees, and commits, the only remaining type of object
> > +is a "tag", which we won't discuss here; refer to gitlink:git-tag[1]
> > +for details.
> 
> We have created a tag in tutorial#1, so it _might_ make sense to
> just tell the user to cat-file it.

The example in tutorial.txt is a "lightweight" tag.

The original tutorial.txt (unlike this sequel) doesn't actually try to
stick to a consistent example throughout, so it's awkward to refer back.
Probably something to fix some day....

> 
> > +------------------------------------------------
> > +$ git diff
> > +--- a/file.txt
> > ++++ b/file.txt
> > +@@ -1 +1,2 @@
> > + hello world!
> > + +hello world, again
> > +$ git update-index file.txt
> > +$ git diff
> > +------------------------------------------------
> 
> Is the second line of the diff " +" intentional?  The same
> comment to the example that immediately follows this part.

Oops, no--those look like cut'n'paste errors.  Would you like a revised
patch?--b.

Re: your mail

[J. Bruce Fields]

On Sun, May 21, 2006 at 05:16:44PM -0700, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> 
> > On Sun, May 21, 2006 at 07:53:18PM -0400, J. Bruce Fields wrote:
> >> >From nobody Mon Sep 17 00:00:00 2001
> >> From: J. Bruce Fields <bfields@citi.umich.edu>
> >
> > Oops, sorry, I screwed up sending those; let me know if you'd like them
> > resent....
> 
> That's OK.  I just cooked up this one ;-).

Thanks!--b.

Re: [PATCH 2/3] tutorial: expanded discussion of commit history

[Jakub Narebski]

J. Bruce Fields wrote:

> +Finally, most commands that take filenames will optionally allow you
> +to precede any filename by a commit, to specify a particular version
> +fo the file:
> +
> +-------------------------------------
> +$ git diff v2.5:Makefile HEAD:Makefile.in
> +-------------------------------------

Why not mention also :<stage>:<filename>, or would <stage> be not defined in
this place of tutorial?

-- 
Jakub Narebski
Warsaw, Poland

Re: [PATCH 2/3] tutorial: expanded discussion of commit history

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

> J. Bruce Fields wrote:
>
>> +Finally, most commands that take filenames will optionally allow you
>> +to precede any filename by a commit, to specify a particular version
>> +fo the file:
>> +
>> +-------------------------------------
>> +$ git diff v2.5:Makefile HEAD:Makefile.in
>> +-------------------------------------
>
> Why not mention also :<stage>:<filename>, or would <stage> be not defined in
> this place of tutorial?

I do not think being able to do diff with arbitrary stage is
often used in practice.  By definition, you would want to do
diff with a stage during a conflicted merge, and most of the
time the default combined diff without any colon form should
give you the most useful results.  Also, ":<path>" to mean the
entry in the index is often equivalent to "git diff --cached".

IOW, these are obscure special purpose notation, and I do not
think tutorial is a good place to cover them.

Re: [PATCH 2/3] tutorial: expanded discussion of commit history

[Jakub Narebski]

Junio C Hamano wrote:

> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> J. Bruce Fields wrote:
>>
>>> +Finally, most commands that take filenames will optionally allow you
>>> +to precede any filename by a commit, to specify a particular version
>>> +fo the file:
>>> +
>>> +-------------------------------------
>>> +$ git diff v2.5:Makefile HEAD:Makefile.in
>>> +-------------------------------------
>>
>> Why not mention also :<stage>:<filename>, or would <stage> be not defined
in
>> this place of tutorial?
> 
> I do not think being able to do diff with arbitrary stage is
> often used in practice.  By definition, you would want to do
> diff with a stage during a conflicted merge, and most of the
> time the default combined diff without any colon form should
> give you the most useful results.  Also, ":<path>" to mean the
> entry in the index is often equivalent to "git diff --cached".
> 
> IOW, these are obscure special purpose notation, and I do not
> think tutorial is a good place to cover them.

Hmmm... perhaps in tutorial-3.txt, covering merges and how to resolve
conflicted merge, cherry picking, reverting and rebasing. And of course
some git workflows covering usage of branches (including pull/push,
fast-forward and "union" branches like 'pu' branch in git).

Well, perhaps not tutorial, but Git Cookbook, or Git Receipies, 
or Git Usage Examples,...

-- 
Jakub Narebski
Warsaw, Poland

[PATCH] git help: remove whatchanged from list of common commands

[Martin Waitz]

whatchanged is replaced by git log now.

Signed-off-by: Martin Waitz

---

7da71dafe75f2a682b07cd1140a29e6fd2705583
 generate-cmdlist.sh |    1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

7da71dafe75f2a682b07cd1140a29e6fd2705583
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 6c59dbd..ec1eda2 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -37,7 +37,6 @@ show-branch
 status
 tag
 verify-tag
-whatchanged
 EOF
 while read cmd
 do
-- 
1.3.3.g288c

-- 
Martin Waitz

Re: [PATCH 2/3] tutorial: expanded discussion of commit history

[J. Bruce Fields]

On Mon, May 22, 2006 at 11:01:20AM +0200, Jakub Narebski wrote:
> Junio C Hamano wrote:
> > I do not think being able to do diff with arbitrary stage is
> > often used in practice.  By definition, you would want to do
> > diff with a stage during a conflicted merge, and most of the
> > time the default combined diff without any colon form should
> > give you the most useful results.  Also, ":<path>" to mean the
> > entry in the index is often equivalent to "git diff --cached".
> > 
> > IOW, these are obscure special purpose notation, and I do not
> > think tutorial is a good place to cover them.
> 
> Hmmm... perhaps in tutorial-3.txt, covering merges and how to resolve
> conflicted merge, cherry picking, reverting and rebasing.

Even then I had the impression that stages were pretty much invisible to
users.  So that should stay in core-tutorial.txt.  Which could use some
revision (Junio had some ideas) but I'm personally more interested in
end-user documentation than developer documentation for now.

So I'd imagined future tutorial parts cannibalizing everyday.txt and the
howto's.

--b.

Re: [PATCH 3/3] tutorial: add discussion of index file, object database

[Jakub Narebski]

J. Bruce Fields wrote:

> +With the right arguments, git diff can also show us the difference
> +between the working directory and the last commit, or between the
> +index and the last commit:
> +
> +------------------------------------------------
> +$ git diff HEAD
[...]
> +$ git diff --cached


Junio C Hamano wrote:

> Also, ":<path>" to mean the
> entry in the index is often equivalent to "git diff --cached".
> 
> IOW, these are obscure special purpose notation, and I do not
> think tutorial is a good place to cover them.

Hmm, wouldn't it be nice to have here :<path> mentioned as 
alternative/extension to --cached, and <ref>:<path> including 
HEAD:<path> as an extension of HEAD, and <path> as an extension
to not having arguments? By extension I mean adding path limiting
and some more advanced selection of things to diff.

-- 
Jakub Narebski
Warsaw, Poland

Re: your mail

[Linus Torvalds]

On Tue, 26 Sep 2006, Zhao, Jing wrote:
> 
>  I subscribed git emailing list (git@vger.kernel.org). I don't know for 
> what reason, my post emails all have been rejected. Could you post this 
> for me and shed some light on this issue? thanks,

The vger.kernel.org lists have various spam detectors, and I suspect a 
combination of your email address and the signature you use just triggers 
that system to believe that you are trying to sell us house payment plans 
or something..

So I would suggest removing your signature in particular, that points to a 
web-site that is associated with an industry that has over-used the email 
medium for selling their services...

> I tried to port git to VOS system (Stratus). When i compiled it, i 
> found it did not have 'regex.h' and its library. Do you know any 
> workaround for this problem? Or which package contains these code i can 
> port at first?

I do not know if stratus has regex libraries anywhere, but googling for 
"VOS Stratus regex" seems to be saying that this isn't the first time that 
platform has had problems compiling various programs.

I suspect you'd just have to compile one of the regex libraries that are 
out there as source. I think Henry Spencer's libraries are likely the 
canonical ones, but there's a "GNU regex" too, and that's probably the 
basis for the ones that are used in glibc. Dunno.

Google for either of those, you'll find them. It's not new code, but I 
doubt it needs to be ;)

			Linus

Re: your mail

[Johannes Schindelin]

Hi,

your email is horridly mixed here. I get an empty subject here, and the 
complete email header at the beginning of the email:

On Fri, 20 Oct 2006, andyparkins@gmail.com wrote:

> >From 9c128bc4b9b85385b7b98ceae0c89283d70e5d45 Mon Sep 17 00:00:00 2001
> From: Andy Parkins <andyparkins@gmail.com>
> [... complete email header including MIME header ...]
> Content-Disposition: inline
> 
> git-send-email doesn't exist; so don't refer to it in the documentation.

But it does! I just removed it, and "make" remade it. I don't even see in 
the Makefile why it should _not_ be made...

Ciao,
Dscho

Re: your mail

[Davide Libenzi]

On Tue, 21 Nov 2006, Johannes Schindelin wrote:

> [PATCH] xdiff: add xdl_merge()
> 
> This new function implements the functionality of RCS merge, but
> in-memory. It returns < 0 on error, otherwise the number of conflicts.
> 
> Finding the conflicting lines can be a very expensive task. You can
> control the eagerness of this algorithm:
> 
> - a level value of 0 means that all overlapping changes are treated
>   as conflicts,
> - a value of 1 means that if the overlapping changes are identical,
>   it is not treated as a conflict.
> - If you set level to 2, overlapping changes will be analyzed, so that
>   almost identical changes will not result in huge conflicts. Rather,
>   only the conflicting lines will be shown inside conflict markers.
> 
> With each increasing level, the algorithm gets slower, but more accurate.
> Note that the code for level 2 depends on the simple definition of
> mmfile_t specific to git, and therefore it will be harder to port that
> to LibXDiff.

Johannes, at the moment I'm chased by a huge storm of never ending emails, 
so I won't be able to follow up this one soon. A smart 3-way merge is in 
my plans for LibXDiff though.
There is quite some nice code around, that does pretty smart tricks and 
goes down to resolve sub-hunk non-trivial conflicts. You may want to take 
a look at that code too.



- Davide

Re: your mail

[Jeff King]

On Sat, Oct 13, 2007 at 12:01:04AM -0400, Michael Witten wrote:

> Now that you mention it, I think the best approach would be to:
> 	
> 	(1) cvsexportcommit
> 	(2) git reset --hard LAST_CVS_IMPORT_AND_MERGE
> 	(3) git cvsimport ..... # and merge
>
> I think this is what you mean; it seems to me that rebasing isn't quite 
> that.

No, I mean rebasing instead of merge. As in, you have a history like
this:

    /--C---D  <-- your master
A--B
    \--C'--D' <-- cvsimport merge tip

where "C" and "D" are your commits in git, and C' and D' are pulled in
from cvsimport. You want to rebase your work like this:

A--B--C'--D'--C--D

except that git-rebase is smart enough to realize that C == C' and skip
it (so it's a "safe" way of moving forward).

> However, this will not preserve more complicated history such as merges
> from another git repository.

Correct. Rebasing doesn't really handle merges, but I assumed you were
just making simple commits on top of a cvs master.

> Basically, I want to treat my git repository as the official
> repository; the CVS repo is just their for the old farts to get the
> latest stuff ;-P

Then my suggestion doesn't really work. You might consider using git as
the official server and letting the old farts use git-cvsserver.

HTH,
-Peff

Re: your mail

[Johannes Schindelin]

Hi,

On Wed, 5 Dec 2007, Johannes Schindelin wrote:

> [PATCH 1/6] path-list: add functions to work with unsorted lists

Ooops.

Sorry,
Dscho

Re: your mail

[Aneesh Kumar K.V]

On Wed, Aug 13, 2008 at 08:24:28PM +0530, aneesh.kumar@gmail.com wrote:
> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> topgit: Implement tg-import
> 
> This can be used to import a set of commits
> between range specified by range1..range2
> This should help us to convert an already
> existing quilt, stgit branches to topgit
> managed one
> 
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
> 
> ---
>  Makefile     |    2 +-
>  README       |    7 ++++++
>  tg-create.sh |   22 ++++++++----------
>  tg-export.sh |    2 +-
>  tg-import.sh |   68 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  5 files changed, 87 insertions(+), 14 deletions(-)
> 

tg-create.sh and tg-export.sh should not be part of this patch. I will
send a new version.

-aneesh

Re: your mail

[Marcus Karlsson]

On Sun, May 06, 2012 at 10:17:07PM +0800, Bruce Zu wrote:
> I want subscribe this git mail list
> thanks!
> Bruce Zu

Great idea. The instructions for how to subscribe can be found on
http://vger.kernel.org/. Then subscribe to the list named 'git'.

	Marcus

Re: your mail

[Magnus Bäck]

On Friday, May 17, 2013 at 14:02 EDT,
     ASHISH VERMA <ashunew1989@gmail.com> wrote:

> Hi,  i am using git to push my code from eclipse to heroku , but
> recently iam  getting error like::
> 
> master:master rejected:non fast forward
> 
> and i am not able to resolve it .I tried a git pull but that says -
> conflicts shud be resolved before git pull can be implemented.I can;t
> find the solution Please help ASAP...

Resolve the conflicts by either hand-editing the files (you'll see the
markers where the conflicts are) add running 'git add' to tell git that
you're done resolving them, or set up Git to use a graphical tool like
kdiff3. When you're done, run 'git commit' to create the merge commit.
After that you'll be able to push to your upstream (unless things have
moved again while you were resolving the initial conflict).

This guide to merge conflicts looks pretty good:
http://gitguru.com/2009/02/22/integrating-git-with-a-visual-merge-tool/

-- 
Magnus Bäck
baeck@google.com

Re: your mail

[Jeff King]

On Mon, Apr 11, 2016 at 07:04:23PM +0000, miwilliams@google.com wrote:

> From 7201fe08ede76e502211a781250c9a0b702a78b2 Mon Sep 17 00:00:00 2001
> From: Mike Williams <miwilliams@google.com>
> Date: Mon, 11 Apr 2016 14:18:39 -0400
> Subject: [PATCH 1/1] wt-status: Remove '!!' from
> wt_status_collect_changed_cb

These bits (minus the initial "From ..." line) should go into your
actual email headers. As it is, your email has no subject line.

> The wt_status_collect_changed_cb function uses an extraneous double
> negation (!!) when determining whether or not a submodule has new
> commits.
> [...]
> -			d->new_submodule_commits = !!hashcmp(p->one->sha1, p->two->sha1);
> +			d->new_submodule_commits = hashcmp(p->one->sha1, p->two->sha1);

It's not extraneous. hashcmp() returns 0 for equality, but an arbitrary
positive or negative value depending on how the two arguments differ.
The assigned "new_submodule_commits" is a bitfield of size 1. So the
"!!" is normalizing the value into "0" or "1".

-Peff

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 11:50:01AM +0200, Jessie Hernandez wrote:
> subscribe git

You need to write to majordomo@vger.kernel.org (with subscribe
git in the body) to subscribe.

Regards
Simon
-- 
+ privacy is necessary
+ using gnupg http://gnupg.org
+ public key id: 0x92FEFDB7E44C32F9

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 01:35:33PM +0000, Patrick Lehmann wrote:
> But how can he write to the mailing list without a subscription?
> Is this a security bug or is he already subscribed?

Everybody can send to this mailing list. This is by design so
contributors/bug reporters can send mails without having to
subscribe.

Regards
Simon
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

Re: your mail

[Simon Ruderich]

On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
> The description on https://github.com/git/git doesn't reflect that policy.
>
> a)
> It explains that discussions take place in the mentioned mailing list.
> b)
> It describes how to subscribe.

However it doesn't say that you have to subscribe to send, only
how to subscribe.

> With knowledge of other mailing lists (mostly managed by mailman),
> subscription is required for participation.

That depends on the mailing list, some require subscription to
prevent spams but not all do.

Somebody might want to update the documentation, but personally
I see no reason to change anything. If you want to send a patch
to improve it, that would be great of course.

Regards
Simon

PS: Please don't top-post on this mailing list.
-- 
+ Privatsphäre ist notwendig
+ Ich verwende GnuPG http://gnupg.org
+ Öffentlicher Schlüssel: 0x92FEFDB7E44C32F9

Re: your mail

[Junio C Hamano]

Simon Ruderich <simon@ruderich.org> writes:

> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>> The description on https://github.com/git/git doesn't reflect that policy.
>>
>> a)
>> It explains that discussions take place in the mentioned mailing list.
>> b)
>> It describes how to subscribe.
>
> However it doesn't say that you have to subscribe to send, only
> how to subscribe.

For that matter, we also say "everyone is welcome to post", which
makes it clear that no subscription is required.

But I view these merely being technically correct.  And making it
absolutely obvious does not cost too much.

>> With knowledge of other mailing lists (mostly managed by mailman),
>> subscription is required for participation.
>
> That depends on the mailing list, some require subscription to
> prevent spams but not all do.

Yes.  But not many people realize that the world they know is the
only world.  We are used to an open list and are shocked when we
encouter a closed one; let's not forget that shock.

How about doing it like this?

 README.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/README.md b/README.md
index f17af66a97..bbaf54bffb 100644
--- a/README.md
+++ b/README.md
@@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
 mailing list -- everyone is welcome to post bug reports, feature
 requests, comments and patches to git@vger.kernel.org (read
 [Documentation/SubmittingPatches][] for instructions on patch submission).
+
+You can send messages without subscribing to the list, but it is 
+recommended to read what other people are saying on the list before
+you speak.
 To subscribe to the list, send an email with just "subscribe git" in
 the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,

Re: your mail

[Ævar Arnfjörð Bjarmason]

On Thu, Jun 22 2017, Junio C. Hamano jotted:

> Simon Ruderich <simon@ruderich.org> writes:
>
>> On Thu, Jun 22, 2017 at 01:55:27PM +0000, Patrick Lehmann wrote:
>>> The description on https://github.com/git/git doesn't reflect that policy.
>>>
>>> a)
>>> It explains that discussions take place in the mentioned mailing list.
>>> b)
>>> It describes how to subscribe.
>>
>> However it doesn't say that you have to subscribe to send, only
>> how to subscribe.
>
> For that matter, we also say "everyone is welcome to post", which
> makes it clear that no subscription is required.
>
> But I view these merely being technically correct.  And making it
> absolutely obvious does not cost too much.
>
>>> With knowledge of other mailing lists (mostly managed by mailman),
>>> subscription is required for participation.
>>
>> That depends on the mailing list, some require subscription to
>> prevent spams but not all do.
>
> Yes.  But not many people realize that the world they know is the
> only world.  We are used to an open list and are shocked when we
> encouter a closed one; let's not forget that shock.
>
> How about doing it like this?
>
>  README.md | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/README.md b/README.md
> index f17af66a97..bbaf54bffb 100644
> --- a/README.md
> +++ b/README.md
> @@ -31,6 +31,10 @@ The user discussion and development of Git take place on the Git
>  mailing list -- everyone is welcome to post bug reports, feature
>  requests, comments and patches to git@vger.kernel.org (read
>  [Documentation/SubmittingPatches][] for instructions on patch submission).
> +
> +You can send messages without subscribing to the list, but it is
> +recommended to read what other people are saying on the list before
> +you speak.
>  To subscribe to the list, send an email with just "subscribe git" in
>  the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,

It's unclear what that means. I *think* it means "consider taking a look
around the list before you post", but then it's probably better advice
to tell people to skim the archives first to get an idea of the traffic.

E.g. if I page through the first 2 pages of public-inbox.org I get
messages going back to the 19th, but if I were to subscribe to the list
I'd need to wait 4 days to get the same mail.

Which, in the context of what this follows (how to submit a bug,
questions etc.) isn't a good use of time for the person reading the
instructions.

Maybe something more like:

diff --git a/README.md b/README.md
index f17af66a97..dc175757fa 100644
--- a/README.md
+++ b/README.md
@@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
 available at <https://public-inbox.org/git/>,
 <http://marc.info/?l=git> and other archival sites.

+You don't need to be subscribed to the list to send mail to it, and
+others on-list will generally CC you when replying (although some
+forget this). It's adviced to subscribe to the list if you want to be
+sure you're not missing follow-up discussion, or if your interest in
+the project is wider than a one-off bug report, question or patch.
+
 The maintainer frequently sends the "What's cooking" reports that
 list the current status of various development topics to the mailing
 list.  The discussion following them give a good reference for

Re: your mail

[Junio C Hamano]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> Maybe something more like:

Much better.

> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
>
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

Re: your mail

[Jeff King]

On Thu, Jun 22, 2017 at 11:58:08PM +0200, Ævar Arnfjörð Bjarmason wrote:

> Which, in the context of what this follows (how to submit a bug,
> questions etc.) isn't a good use of time for the person reading the
> instructions.
> 
> Maybe something more like:
> 
> diff --git a/README.md b/README.md
> index f17af66a97..dc175757fa 100644
> --- a/README.md
> +++ b/README.md
> @@ -36,6 +36,12 @@ the body to majordomo@vger.kernel.org. The mailing list archives are
>  available at <https://public-inbox.org/git/>,
>  <http://marc.info/?l=git> and other archival sites.
> 
> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be
> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.
> +
>  The maintainer frequently sends the "What's cooking" reports that
>  list the current status of various development topics to the mailing
>  list.  The discussion following them give a good reference for

You perhaps already read it, but you may want to steal wording or
suggestions from the mailing list section at:

  https://git-scm.com/community

which is covering the same ideas (and vice versa, patches to that page
are welcome if the README says something better).

-Peff

Re: your mail

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

>> +You don't need to be subscribed to the list to send mail to it, and
>> +others on-list will generally CC you when replying (although some
>> +forget this). It's adviced to subscribe to the list if you want to be
>> +sure you're not missing follow-up discussion, or if your interest in
>> +the project is wider than a one-off bug report, question or patch.
>> +
>>  The maintainer frequently sends the "What's cooking" reports that
>>  list the current status of various development topics to the mailing
>>  list.  The discussion following them give a good reference for
>
> You perhaps already read it, but you may want to steal wording or
> suggestions from the mailing list section at:
>
>   https://git-scm.com/community
>
> which is covering the same ideas (and vice versa, patches to that page
> are welcome if the README says something better).

OK, so... Ævar's version does not mention:

 - text/plain, which is a very good addition.

 - note about CC in a way as useful as the "community" page does,
   which may want to steal from the latter.

 - the archive, but it may not be needed in the context of this
   document.  "Read the archive to make sure you are not repeating
   somebody else said before speaking" is something we silently wish
   everybody to follow, but it is something we do not want to say
   out loud, especially to new people.

 - Windows, but I am not sure if it is necessary or even healthy.
   One thing I would rather not to see is the Windows mailing list
   becomes the first line triage place for any and all issues that
   were experienced by a user who happened to be using Windows, and
   majority of the issues turn out to be unspecific to Windows.  I'd
   suspect that all of us rather would want to see the referral go
   the other way around.

Otoh, "community" page does not encourage subscription as a way to
ensure you'll see follow-up discussion, which may be a good thing to
add.

A tangent I just found funny is this paragraph on the "community"
page:

    The archive can be found on public-inbox. Click here to
    subscribe.

Of course clicking does not take you to a subscription page for
public-inbox, even though the two sentences appear to be related.

Perhaps swap the order of the two, like so, with a bit richer
explanation taken from Ævar's version:

	... disable HTML in your outgoing messages.

	By subscribing (click here), you can make sure you're not
	missing follow-up discussion and also learn from other
	development in the community.  The list archive can be found
	on public-inbox.

Re: your mail

[demerphq]

On 22 June 2017 at 23:58, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

> +You don't need to be subscribed to the list to send mail to it, and
> +others on-list will generally CC you when replying (although some
> +forget this). It's adviced to subscribe to the list if you want to be

FWIW: "adviced" is misspelled, it should be "advised", and IMO, it
feels like poor style to begin a sentence with a contraction. Not
strictly wrong, but sufficiently informal that I think it is out of
place in docs like this. Better to just say "It is", or even just "You
are", especially as you use "you" later in the sentence.

I actually think simplifying that sentence considerably is preferable:

"To be sure you receive all follow-up mails you should subscribe to the list."

flows better and is more succinct than

"It's advised to subscribe to the list if you want to be sure you're
not missing follow-up discussion".

> +sure you're not missing follow-up discussion, or if your interest in
> +the project is wider than a one-off bug report, question or patch.

cheers,
yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: your mail

[Jeff King]

On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:

> Otoh, "community" page does not encourage subscription as a way to
> ensure you'll see follow-up discussion, which may be a good thing to
> add.
> 
> A tangent I just found funny is this paragraph on the "community"
> page:
> 
>     The archive can be found on public-inbox. Click here to
>     subscribe.
> 
> Of course clicking does not take you to a subscription page for
> public-inbox, even though the two sentences appear to be related.
> 
> Perhaps swap the order of the two, like so, with a bit richer
> explanation taken from Ævar's version:
> 
> 	... disable HTML in your outgoing messages.
> 
> 	By subscribing (click here), you can make sure you're not
> 	missing follow-up discussion and also learn from other
> 	development in the community.  The list archive can be found
> 	on public-inbox.

Yeah, I think that's a good suggestion. Do you want to phrase it in the
form of a patch? :)

-Peff

Re: your mail

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Jun 22, 2017 at 10:23:17PM -0700, Junio C Hamano wrote:
>
>> Otoh, "community" page does not encourage subscription as a way to
>> ensure you'll see follow-up discussion, which may be a good thing to
>> add.
>> 
>> A tangent I just found funny is this paragraph on the "community"
>> page:
>> 
>>     The archive can be found on public-inbox. Click here to
>>     subscribe.
>> 
>> Of course clicking does not take you to a subscription page for
>> public-inbox, even though the two sentences appear to be related.
>> 
>> Perhaps swap the order of the two, like so, with a bit richer
>> explanation taken from Ævar's version:
>> 
>> 	... disable HTML in your outgoing messages.
>> 
>> 	By subscribing (click here), you can make sure you're not
>> 	missing follow-up discussion and also learn from other
>> 	development in the community.  The list archive can be found
>> 	on public-inbox.
>
> Yeah, I think that's a good suggestion. Do you want to phrase it in the
> form of a patch? :)

OK. Letme try.

Re: your mail

[Kevin Daudt]

On Fri, Jan 25, 2019 at 12:47:35PM +0300, Furkan DURUL wrote:
> Hello,
> My name is Furkan. I'm a new graduated Electronics and Communication
> Engineer in Turkey. In my current workplace, we use Git in all our
> projects and I really learned a lot from your Pro Git Book. I would
> like to contribute to translation of this book to Turkish. I'm also a
> freelance translator and have experience about translation.
> Look forward to hear you
> Cheers

Hello Furkan,

Welcome to the community. Pro Git is not maintained by the git
community, but is a separate project.

You can find details on how to provide translations here[0]. It looks
from that document that someone started translating the book in Turkish
as well[1].

Kind regards, Kevin


[0]:https://github.com/progit/progit2/blob/master/TRANSLATING.md
[1]:https://github.com/progit/progit2-tr

Re: your mail

[Kevin Daudt]

On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git

You need to send this to majordomo@vger.kernel.org. Sending it to the
git mailing list will not do a lot.

Kevin

Re: your mail

[Robert Morgan]

Apologies list!  Thanks Kevin.  That's what I get for troubleshooting
plain-text in Gmail and quickly sending a subscribe email before
walking out.

Robert


On Thu, Jul 11, 2019 at 3:18 PM Kevin Daudt <me@ikke.info> wrote:
>
> On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> > subscribe git
>
> You need to send this to majordomo@vger.kernel.org. Sending it to the
> git mailing list will not do a lot.
>
> Kevin

Re: your mail

[Taylor Blau]

Hi Han-Wen,


On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> Hey folks,
>
> I spent the last few weeks cobbling together an implementation of the
> reftable format in C and in Go. I thought this would be cool to add to
> git-core, but I doubt whether I will have enough time to see such an
> effort through. Maybe some of you would want to try integrating it
> into the Git-core code base?  Example code is here:
>
>   https://github.com/google/reftable/blob/master/c/api.h#L153

Very exciting, and thanks for your work on this. I haven't taken a
close look at the code yet, so I'm sure taking this further involves a
much more careful examination.

I know that Christian Couder (who you CC-d on this thread) was also
working on this for either GitLab or Booking.com.

Christian -- are you still working on this for either one of those
entities? If so, is there some way to unify these two efforts?

> cheers!
> --

Thanks,
Taylor

Re: your mail

[Christian Couder]

Hi Taylor and Han-Wen,

On Wed, Nov 20, 2019 at 6:30 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> On Tue, Nov 19, 2019 at 07:49:17PM -0800, Han-Wen Nienhuys wrote:
> >
> > I spent the last few weeks cobbling together an implementation of the
> > reftable format in C and in Go. I thought this would be cool to add to
> > git-core, but I doubt whether I will have enough time to see such an
> > effort through. Maybe some of you would want to try integrating it
> > into the Git-core code base?  Example code is here:
> >
> >   https://github.com/google/reftable/blob/master/c/api.h#L153

Interesting!

> Very exciting, and thanks for your work on this. I haven't taken a
> close look at the code yet, so I'm sure taking this further involves a
> much more careful examination.
>
> I know that Christian Couder (who you CC-d on this thread) was also
> working on this for either GitLab or Booking.com.
>
> Christian -- are you still working on this for either one of those
> entities? If so, is there some way to unify these two efforts?

Yeah, I started working on this last year for Booking.com, and I am
now slowly working on it for GitLab. It is not yet finished because it
has been low priority work.

I took a very quick look at Han-Wen's implementation and it looks very
different from mine from the outside. It seems more complete, but
might be less integrated into the Git code base.

Best,
Christian.

Re: your mail

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2847 bytes --]

On 2020-06-24 at 00:38:39, shejan shuza wrote:
> Hi, I have a repository with about 55GB of contents, with binary files
> that are less than 100MB each (so no LFS mode) from a project which
> has almost filled up an entire hard drive. I am trying to add all of
> the contents to a git repo and push it to GitHub but every time I do
> 
> git add .
> 
> in the folder with my contents after initializing and setting my
> remote, git starts caching all the files to .git/objects, making the
> .git folder grow in size rapidly. All the files are binaries, so git
> cannot stage changes between versions anyway, so there is no reason to
> cache versions.

What you're experiencing is normal; storing files in the .git directory
is how Git keeps track of them.  It can't rely on the copies in your
working tree because you can modify those files at any time, and if you
did so, relying on them would corrupt the repository.

Also, note that Git can and does deltify changes between revisions once
the data is packed, regardless of whether the file is binary, but how
well it does so depends on your data.  For example, if it's compressed,
it likely doesn't deltify very well, so storing things like compressed
images or zip files using deflate is generally going to result in a
bloated repository.

However, if you don't need versioning for these files, then you don't
need a Git repository.  Git is a tool for versioning files, not a
general storage mechanism.  You may find a cloud storage bucket or some
other artifact storage service may meet your needs better.

I will also tell you from a practical point of view that almost nobody
(including you) will want to host a 55 GB repository filled with binary
blobs.  Usually repacking these repositories is very expensive,
requiring extensive CPU and memory usage for a prolonged time for little
useful benefit.

> Is there any way, such as editing the git attributes or changing
> something about how files are staged in the git repository, to only
> just add indexes or references to files in the repository rather than
> cache them into the .git folder, while also being able to push all the
> data to GitHub?

This is how Git LFS and similar tools, like git-annex, work.  Git LFS
will create copies of the objects in your .git directory though, at
least until they're pushed to the server, at which point they can be
pruned.  Git LFS has the same limitation as Git here.  I'm less familiar
with git-annex, but it is also a popular choice.

However, as mentioned, it sounds like you don't need versioning at all,
so unless you do, Git with Git LFS will be no more suitable for this
than plain Git.  If that's the case, I encourage you to explore
alternate solutions.
-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]