* Re: Feature request: Allow extracting revisions into directories
From: Junio C Hamano @ 2013-02-10 3:45 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git, Phil Hord
In-Reply-To: <7vehgpum7n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I am not Phil, but if you ask me, I think it is borderline between
> "meh" and "no way we would give a short-and-sweet -i to something
> like this".
I think one reason it was "meh" for me is that we never did an
equivalent of "cvs export" and "svn export", primarily because
we had "tar-tree" (aka "archive --format=tar") first, and it was
sufficient to pipe its outputto "tar xf -" if somebody wanted to do
the non-existent "git export". Also "tar-tree" was more useful for
people who wanted to eventually want to have a tarball (you can
first "export" and then "tar cf" the resulting directory).
But I think it is fine to add "git export <revision> <directory>",
which may look like this, perhaps.
#!/bin/sh
# git export <rev> <directory>
rev=${1?revision} dir=${2?directory}
. $(git --exec-path)/git-sh-setup
mkdir -p "$dir" || exit
git archive --format=tar "$rev" |
tar Cxf "$dir" -
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-10 3:57 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vpq08u903.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
There are two things git archive is missing that are needed in my use
case:
First, git archive in combination with tar won't remove unneeded files.
You have to run rm -rf before manually which brings me to the next
point; git archive can't really make incremental updates. Consider an
export that overwrites a tree that resembles the state of an export two
commits before and contains a lot of files. I don't like to idea of
needing to remove all files and write all of them again just to change
one or two lines.
Perhaps my real problem is not "export" but rather "Can I have multiple
work trees with multiple checked out revisions?"...
Am Samstag, den 09.02.2013, 19:45 -0800 schrieb Junio C Hamano:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I am not Phil, but if you ask me, I think it is borderline between
> > "meh" and "no way we would give a short-and-sweet -i to something
> > like this".
>
> I think one reason it was "meh" for me is that we never did an
> equivalent of "cvs export" and "svn export", primarily because
> we had "tar-tree" (aka "archive --format=tar") first, and it was
> sufficient to pipe its outputto "tar xf -" if somebody wanted to do
> the non-existent "git export". Also "tar-tree" was more useful for
> people who wanted to eventually want to have a tarball (you can
> first "export" and then "tar cf" the resulting directory).
>
> But I think it is fine to add "git export <revision> <directory>",
> which may look like this, perhaps.
>
> #!/bin/sh
> # git export <rev> <directory>
> rev=${1?revision} dir=${2?directory}
> . $(git --exec-path)/git-sh-setup
>
> mkdir -p "$dir" || exit
> git archive --format=tar "$rev" |
> tar Cxf "$dir" -
>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Jonathan Nieder @ 2013-02-10 4:06 UTC (permalink / raw)
To: Robert Clausecker; +Cc: Junio C Hamano, git
In-Reply-To: <1360468628.6610.5.camel@t520>
Hi Robert,
Robert Clausecker wrote:
> There are two things git archive is missing that are needed in my use
> case:
>
> First, git archive in combination with tar won't remove unneeded files.
> You have to run rm -rf before manually which brings me to the next
> point; git archive can't really make incremental updates.
My advice is to keep a separate index file for your exported files.
Like this:
GIT_DIR=$(readlink -f $(git rev-parse --git-dir))
GIT_INDEX_FILE=$GIT_DIR/index-for-deployment
export GIT_DIR GIT_INDEX_FILE
cd $dest
git read-tree -m -u <tree>
Hope that helps,
Jonathan
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Robert Clausecker @ 2013-02-10 4:10 UTC (permalink / raw)
To: Jonathan Nieder, git
In-Reply-To: <20130210040621.GA8584@elie.Belkin>
That is actually a pretty interesting approach. I can use a different
index file for different deployments. How does this cooperate with bare
repositories? Aren't they supposed to have no index file at all?
Am Samstag, den 09.02.2013, 20:06 -0800 schrieb Jonathan Nieder:
> My advice is to keep a separate index file for your exported files.
> Like this:
>
> GIT_DIR=$(readlink -f $(git rev-parse --git-dir))
> GIT_INDEX_FILE=$GIT_DIR/index-for-deployment
> export GIT_DIR GIT_INDEX_FILE
>
> cd $dest
> git read-tree -m -u <tree>
>
> Hope that helps,
> Jonathan
^ permalink raw reply
* Re: Feature request: Allow extracting revisions into directories
From: Jonathan Nieder @ 2013-02-10 4:19 UTC (permalink / raw)
To: Robert Clausecker; +Cc: git
In-Reply-To: <1360469440.6610.8.camel@t520>
Robert Clausecker wrote:
> That is actually a pretty interesting approach. I can use a different
> index file for different deployments. How does this cooperate with bare
> repositories? Aren't they supposed to have no index file at all?
It should work fine in a bare repo.
If you can think of a good place to sneak hints about this into the
documentation (maybe as an example in git-archive(1) or a new
gitenvironment(7) page), that would be very welcome.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v3 0/8] Hiding refs
From: Jed Brown @ 2013-02-10 4:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael Haggerty, git, Jeff King, Shawn Pearce
In-Reply-To: <7v38x5ul4s.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I am not sure about "pushing" part, but the jc/fetch-raw-sha1 topic
> (split from the main jc/hidden-refs topic) should allow your script,
> after the client learns the set of smudged object names, to ask for
>
> git fetch $there $sha1_1 $sha1_2 ...
Well, my out-of-band knowledge is currently the sha1 of the data
contained in the blob I want, not the blob sha1 itself [1]. After
experimenting with jc/hidden-refs, I think it already does exactly what
I want. Specifically, I set this on the server
git config uploadpack.hiderefs refs/fat
so that 'git ls-remote' no longer transfers these refs. Then on the
client, I do
contentid=$(sha1sum thefile | cut -f1 -d \ )
blobid=$(git hash-object -w thefile)
git update-ref refs/fat/$contentid $blobid
.... more like this
git push the-remote refs/fat/$contentid ...
and later, I can fetch specific refs using
git fetch the-remote refs/fat/$wanted:refs/fat/$wanted ...
The client knows the desired refs out-of-band so this looks okay. It
would be convenient to have '--stdin' options to 'git push' and 'git
fetch'. Would a patch for that be welcome?
[1] The reason for using $contentid instead of $blobid in the key here
is to avoid etching the backend=git detail into the cleaned commits.
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 5:24 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <CALkWK0=6_n4rf6AWci6J+uhGHpjTUmK7YFdVHuSJedN2zLWtMA@mail.gmail.com>
On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Finn notes in the commit message that it offers no speedup, because
> .gitignore files in every directory still have to be read. I think
> this is silly: we really should be caching .gitignore, and touching it
> only when lstat() reports that the file has changed.
>
> ...
>
> Really, the elephant in the room right now seems to be .gitignore.
> Until that is fixed, there is really no use of writing this inotify
> daemon, no? Can someone enlighten me on how exactly .gitignore files
> are processed?
.gitignore is a different issue. I think it's mainly used with
read_directory/fill_directory to collect ignored files (or not-ignored
files). And it's not always used (well, status and add does, but diff
should not). I think wee need to measure how much mass lstat
elimination gains us (especially on big repos) and how much
.gitignore/.gitattributes caching does. I don't think .gitignore has
such a big impact though. strace on git.git tells me "git status"
issues about 2500 lstat calls, and just 740 open+getdents calls (on
total 3800 syscalls). I will think if we can do something about
.gitignore/.gitattributes.
--
Duy
^ permalink raw reply
* Re: [Request] Git export with hardlinks
From: Thomas Koch @ 2013-02-10 10:33 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20130208095819.GA17220@sigill.intra.peff.net>
Jeff King:
> [...]
> So a full checkout is 24M. For the next deploy, we'll start by asking
> "cp" to duplicate the old, using hard links:
Hi Jeff,
thank you very much for your idea! It's good and simple. It just breaks down
for the case when a large folder got renamed.
But I already hacked the basic layout of the algorithm and it's not
complicated at all, I believe:
https://github.com/thkoch2001/git_export_hardlinks/blob/master/git_export_hardlinks.py
I had to interrupt work on this and could not yet finish and test it. But I
thought you might be interested. Maybe something like this might one day be
rewritten in C and become part of git core?
Regards,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 11:17 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <CACsJy8DeM5--WVXg3b65RxLBS7Jho-7KmcGwWk7B5uAx77yOEw@mail.gmail.com>
On Sun, Feb 10, 2013 at 12:24:58PM +0700, Duy Nguyen wrote:
> On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
> > Finn notes in the commit message that it offers no speedup, because
> > .gitignore files in every directory still have to be read. I think
> > this is silly: we really should be caching .gitignore, and touching it
> > only when lstat() reports that the file has changed.
> >
> > ...
> >
> > Really, the elephant in the room right now seems to be .gitignore.
> > Until that is fixed, there is really no use of writing this inotify
> > daemon, no? Can someone enlighten me on how exactly .gitignore files
> > are processed?
>
> .gitignore is a different issue. I think it's mainly used with
> read_directory/fill_directory to collect ignored files (or not-ignored
> files). And it's not always used (well, status and add does, but diff
> should not). I think wee need to measure how much mass lstat
> elimination gains us (especially on big repos) and how much
> .gitignore/.gitattributes caching does.
OK let's count. I start with a "standard" repository, linux-2.6. This
is the number from strace -T on "git status" (*). The first column is
accumulated time, the second the number of syscalls.
top syscalls sorted top syscalls sorted
by acc. time by number
----------------------------------------------
0.401906 40950 lstat 0.401906 40950 lstat
0.190484 5343 getdents 0.150055 5374 open
0.150055 5374 open 0.190484 5343 getdents
0.074843 2806 close 0.074843 2806 close
0.003216 157 read 0.003216 157 read
The following patch pretends every entry is uptodate without
lstat. With the patch, we can see refresh code is the cause of mass
lstat, as lstat disappears:
0.185347 5343 getdents 0.144173 5374 open
0.144173 5374 open 0.185347 5343 getdents
0.071844 2806 close 0.071844 2806 close
0.004918 135 brk 0.003378 157 read
0.003378 157 read 0.004918 135 brk
-- 8< --
diff --git a/read-cache.c b/read-cache.c
index 827ae55..94d8ed8 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1018,6 +1018,10 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
if (ce_uptodate(ce))
return ce;
+#if 1
+ ce_mark_uptodate(ce);
+ return ce;
+#endif
/*
* CE_VALID or CE_SKIP_WORKTREE means the user promised us
* that the change to the work tree does not matter and told
-- 8< --
The following patch eliminates untracked search code. As we can see,
open+getdents also disappears with this patch:
0.462909 40950 lstat 0.462909 40950 lstat
0.003417 129 brk 0.003417 129 brk
0.000762 53 read 0.000762 53 read
0.000720 36 open 0.000720 36 open
0.000544 12 munmap 0.000454 33 close
So from syscalls point of view, we know what code issues most of
them. Let's see how much time we gain be these patches, which is an
approximate of the gain by inotify support. This time I measure on
gentoo-x86.git [1] because this one has really big worktree (100k
files)
unmodified read-cache.c dir.c both
real 0m0.550s 0m0.479s 0m0.287s 0m0.213s
user 0m0.305s 0m0.315s 0m0.201s 0m0.182s
sys 0m0.240s 0m0.157s 0m0.084s 0m0.030s
and the syscall picture on gentoo-x86.git:
1.106615 101942 lstat 1.106615 101942 lstat
0.667235 47083 getdents 0.641604 47114 open
0.641604 47114 open 0.667235 47083 getdents
0.286711 23573 close 0.286711 23573 close
0.005842 350 brk 0.005842 350 brk
We can see that shortcuting untracked code gives bigger gain than
index refresh code. So I have to agree that .gitignore may be the big
elephant in this particular case.
Bear in mind though this is Linux, where lstat is fast. On systems
with slow lstat, these timings could look very different due to the
large number of lstat calls compared to open+getdents. I really like
to see similar numbers on Windows.
read_directory/fill_directory code is mostly used by "git add" (not
with -u) and "git status", while refresh code is executed in add,
checkout, commit/status, diff, merge. So while smaller gain, reducing
lstat calls could benefit in more cases.
A relatively slow "git add" is acceptable. "git status" should be
fast. Although in my workflow, I do "git diff [--stat] [--cached]"
much more often than "git status" so relatively slow "git status" does
not hurt me much. But people may do it differently.
On speeding up read_directory with inotify support. I haven't thought
it through, but I think we could save (or get it via socket) a list of
untracked files in .git, regardless ignore status, with the help from
inotify. When this list is verified valid, read_directory could be
modified to traverse the tree using this list (plus the index) instead
of opendir+readdir. Not sure how the change might look though.
[1] http://git-exp.overlays.gentoo.org/gitweb/?p=exp/gentoo-x86.git;a=summary
(*) the script to produce those numbers is
-- 8< --
#!/bin/sh
export LANG=C
strace -T "$@" 2>&1 >/dev/null |
sed 's/\(^[^(]*\)(.*<\([0-9.]*\)>$/\1 \2/' |
awk '{
sec[$1]+=$2;
count[$1]++;
}
END {
for (i in sec)
printf("%f %d %s\n", sec[i], count[i], i);
}' >/tmp/s
sort -nr /tmp/s | head -n5
sort -nrk2 /tmp/s | head -n5
-- 8< --
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: Duy Nguyen @ 2013-02-10 11:22 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Robert Zeh, Junio C Hamano, Git List, finnag
In-Reply-To: <20130210111732.GA24377@lanh>
On Sun, Feb 10, 2013 at 06:17:32PM +0700, Duy Nguyen wrote:
> The following patch eliminates untracked search code. As we can see,
> open+getdents also disappears with this patch:
>
> 0.462909 40950 lstat 0.462909 40950 lstat
> 0.003417 129 brk 0.003417 129 brk
> 0.000762 53 read 0.000762 53 read
> 0.000720 36 open 0.000720 36 open
> 0.000544 12 munmap 0.000454 33 close
.. and the patch is missing:
-- 8< --
diff --git a/dir.c b/dir.c
index 57394e4..1963c6f 100644
--- a/dir.c
+++ b/dir.c
@@ -1439,8 +1439,10 @@ int read_directory(struct dir_struct *dir, const char *path, int len, const char
return dir->nr;
simplify = create_simplify(pathspec);
+#if 0
if (!len || treat_leading_path(dir, path, len, simplify))
read_directory_recursive(dir, path, len, 0, simplify);
+#endif
free_simplify(simplify);
qsort(dir->entries, dir->nr, sizeof(struct dir_entry *), cmp_name);
qsort(dir->ignored, dir->ignored_nr, sizeof(struct dir_entry *), cmp_name);
-- 8< --
^ permalink raw reply related
* Re: Feature request: Allow extracting revisions into directories
From: Thomas Koch @ 2013-02-10 12:16 UTC (permalink / raw)
To: Robert Clausecker, git
In-Reply-To: <1359980045.24730.32.camel@t520>
Robert Clausecker:
> I have a server that hosts a bare git repository. This git repository
> contains a branch production. Whenever somebody pushes to production a
> hook automatically puts a copy of the current production branch
> into /var/www/foo. I could of course use pull for that but it just does
> not feels right. Why should I have a repository twice on the server?
Hallo Robert,
I've mostly the same requirement for a friend with a PHP webshop and started
to implement my own git_export with the additional feature that it tries to
reuse already exported trees as hardlink targets instead of writing the same
file again. (I'm aware of the dangers of hardlinks.)
https://github.com/thkoch2001/git_export_hardlinks
See also the current mailing list thread: "[Request] Git export with
hardlinks".
Beste Grüße,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* [PATCH] fixup! graph: output padding for merge subsequent parents
From: John Keeping @ 2013-02-10 13:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthieu Moy
In-Reply-To: <7vtxplt5u2.fsf@alter.siamese.dyndns.org>
---
On Sat, Feb 09, 2013 at 03:39:33PM -0800, Junio C Hamano wrote:
> * jk/diff-graph-cleanup (2013-02-07) 6 commits
> - combine-diff.c: teach combined diffs about line prefix
> - diff.c: use diff_line_prefix() where applicable
> - diff: add diff_line_prefix function
> - diff.c: make constant string arguments const
> - diff: write prefix to the correct file
> - graph: output padding for merge subsequent parents
>
> Refactors a lot of repetitive code sequence from the graph drawing
> code and adds it to the combined diff output.
>
> Will merge to 'next'.
Can you squash this into the first commit before you do?
Matthieu is correct that the graph_is_commit_finished() check isn't
needed in the loop now that we've pulled it out to be checked first -
the value returned can't change during the loop. I've left the early
return out.
graph.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/graph.c b/graph.c
index 2a3fc5c..56f970f 100644
--- a/graph.c
+++ b/graph.c
@@ -1237,7 +1237,7 @@ void graph_show_commit(struct git_graph *graph)
shown_commit_line = 1;
}
- while (!shown_commit_line && !graph_is_commit_finished(graph)) {
+ while (!shown_commit_line) {
shown_commit_line = graph_next_line(graph, &msgbuf);
fwrite(msgbuf.buf, sizeof(char), msgbuf.len, stdout);
if (!shown_commit_line)
--
1.8.1.2
^ permalink raw reply related
* Re: inotify to minimize stat() calls
From: demerphq @ 2013-02-10 13:26 UTC (permalink / raw)
To: Duy Nguyen
Cc: Ramkumar Ramachandra, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <20130210111732.GA24377@lanh>
On 10 February 2013 12:17, Duy Nguyen <pclouds@gmail.com> wrote:
> Bear in mind though this is Linux, where lstat is fast. On systems
> with slow lstat, these timings could look very different due to the
> large number of lstat calls compared to open+getdents. I really like
> to see similar numbers on Windows.
Is windows stat really so slow? I encountered this perception in
windows Perl in the past, and I know that on windows Perl stat
*appears* slow compared to *nix, because in order to satisfy the full
*nix stat interface, specifically the nlink field, it must open and
close the file*. As of 5.10 this can be disabled by setting a magic
var ${^WIN32_SLOPPY_STAT} to a true value, which makes a significant
improvement to the performance of the Perl level stat implementation.
I would not be surprised if the cygwin implementation of stat() has
the same issue as Perl did, and that stat appears much slower than it
actually need be if you don't care about the nlink field.
Yves
* http://perl5.git.perl.org/perl.git/blob/HEAD:/win32/win32.c#l1492
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH v2 03/15] user-manual: Use 'remote add' to setup push URLs
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
There is no need to use here documents to setup this configuration.
It is easier, less confusing, and more robust to use Git's
configuration tools directly.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 17 ++++++++++-------
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8524c08..53f73c3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1994,14 +1994,17 @@ default. See the description of the receive.denyCurrentBranch option
in linkgit:git-config[1] for details.
As with `git fetch`, you may also set up configuration options to
-save typing; so, for example, after
+save typing; so, for example, after either
--------------------------------------------------
-$ cat >>.git/config <<EOF
-[remote "public-repo"]
- url = ssh://yourserver.com/~you/proj.git
-EOF
--------------------------------------------------
+------------------------------------------------
+$ git remote add public-repo ssh://yourserver.com/~you/proj.git
+------------------------------------------------
+
+or, more explicitly,
+
+------------------------------------------------
+$ git config remote.public-repo.url ssh://yourserver.com/~you/proj.git
+------------------------------------------------
you should be able to perform the above push with just
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 14/15] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
If you try and update a submodule with a dirty working directory, you
get an error message like:
$ git submodule update
error: Your local changes to the following files would be overwritten by checkout:
...
Please, commit your changes or stash them before you can switch branches.
Aborting
...
Mention this in the submodule notes. The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index dbd0143..8024758 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3751,7 +3751,9 @@ module a
NOTE: The changes are still visible in the submodule's reflog.
-This is not the case if you did not commit your changes.
+If you did not commit your submodule changes, the changes will *not*
+be silently overwritten. Instead, you get the usual warning about not
+being able switch from a dirty branch.
[[low-level-operations]]
Low-level Git operations
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 04/15] user-manual: Use git branch --merged
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Use 'git branch --merged origin'. This feature was introduced by
049716b (branch --merged/--no-merged: allow specifying arbitrary
commit, 2008-07-08), after the documentation that's being replaced
moved into the manual with 9e2163ea (user-manual: move
howto/using-topic-branches into manual, 2007-05-13).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 53f73c3..a8f792d 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2267,10 +2267,10 @@ then pulled by Linus, and finally coming back into your local
You detect this when the output from:
-------------------------------------------------
-$ git log origin..branchname
+$ git branch --merged origin
-------------------------------------------------
-is empty. At this point the branch can be deleted:
+lists the branch. At this point the branch can be deleted:
-------------------------------------------------
$ git branch -d branchname
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 11/15] user-manual: Fix 'http' -> 'HTTP' typos
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
HTTP is an acronym which has not (yet) made the transition to word
status (unlike "laser", probably because lasers are inherently cooler
than HTTP ;).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 07e07c1..31054a2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1938,7 +1938,7 @@ Exporting a Git repository via http
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Git protocol gives better performance and reliability, but on a
-host with a web server set up, http exports may be simpler to set up.
+host with a web server set up, HTTP exports may be simpler to set up.
All you need to do is place the newly created bare Git repository in
a directory that is exported by the web server, and make some
@@ -1964,7 +1964,7 @@ $ git clone http://yourserver.com/~you/proj.git
(See also
link:howto/setup-git-server-over-http.txt[setup-git-server-over-http]
for a slightly more sophisticated setup using WebDAV which also
-allows pushing over http.)
+allows pushing over HTTP.)
[[pushing-changes-to-a-public-repository]]
Pushing changes to a public repository
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 12/15] user-manual: Use request-pull to generate "please pull" text
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Less work and more error checking (e.g. does a merge base exist?).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 31054a2..6446791 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2298,17 +2298,14 @@ 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:
+pull" request to Linus you can use linkgit:git-request-pull[1]:
-------------------------------------------------
-$ git diff --stat origin..release
+$ git request-pull origin git://example.com/proj.git release
-------------------------------------------------
-and
-
--------------------------------------------------
-$ git log -p origin..release | git shortlog
--------------------------------------------------
+where the `git://` URL points to your <<public-repositories,public
+repository>>.
Here are some of the scripts that simplify all this even further.
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 06/15] user-manual: Give 'git push -f' as an alternative to +master
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This mirrors existing language in the description of 'git fetch'.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5d80b40..a68d6b9 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2045,6 +2045,13 @@ branch name with a plus sign:
$ git push ssh://yourserver.com/~you/proj.git +master
-------------------------------------------------
+Note the addition of the `+` sign. Alternatively, you can use the
+`-f` flag to force the remote update, as in:
+
+-------------------------------------------------
+$ git push -f ssh://yourserver.com/~you/proj.git master
+-------------------------------------------------
+
Normally whenever a branch head in a public repository is modified, it
is modified to point to a descendant of the commit that it pointed to
before. By forcing a push in this situation, you break that convention.
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 10/15] user-manual: Fix 'both: so' -> 'both; so' typo
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
The clause "so `git log ...` will return no commits..." is
independent, not a description of "both", so a semicolon is more
appropriate.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e2e0c86..07e07c1 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -782,7 +782,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b
Or you could recall that the `...` operator selects all commits
contained reachable from either one reference or the other but not
-both: so
+both; so
-------------------------------------------------
$ git log origin...master
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 09/15] user-manual: Use 'git config --global user.*' for setup
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
A simple command line call is easier than spawning an editor,
especially for folks new to ideas like the "command line" and "text
editors". This is also the approach suggested by 'git commit' if you
try and commit without having configured user.name or user.email.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8bf37b3..e2e0c86 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -991,9 +991,16 @@ Developing with Git
Telling Git your name
---------------------
-Before creating any commits, you should introduce yourself to Git. The
-easiest way to do so is to make sure the following lines appear in a
-file named `.gitconfig` in your home directory:
+Before creating any commits, you should introduce yourself to Git.
+The easiest way to do so is to use linkgit:git-config[1]:
+
+------------------------------------------------
+$ git config --global user.name 'Your Name Comes Here'
+$ git config --global user.email 'you@yourdomain.example.com'
+------------------------------------------------
+
+Which will add the following stanza to a file named `.gitconfig` in
+your home directory:
------------------------------------------------
[user]
@@ -1001,8 +1008,9 @@ file named `.gitconfig` in your home directory:
email = you@yourdomain.example.com
------------------------------------------------
-(See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
-details on the configuration file.)
+See the "CONFIGURATION FILE" section of linkgit:git-config[1] for
+details on the configuration file. The file is plain text, so you can
+also edit it with your favorite editor.
[[creating-a-new-repository]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 01/15] user-manual: Rewrite git-gc section for automatic packing
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This should have happened back in 2007, when `git gc` learned about
auto (e9831e8, git-gc --auto: add documentation, 2007-09-17).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 16 +++++-----------
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 5077e7c..222545b 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1562,17 +1562,11 @@ Ensuring good performance
-------------------------
On large repositories, Git depends on compression to keep the history
-information from taking up too much space on disk or in memory.
-
-This compression is not performed automatically. Therefore you
-should occasionally run linkgit:git-gc[1]:
-
--------------------------------------------------
-$ git gc
--------------------------------------------------
-
-to recompress the archive. This can be very time-consuming, so
-you may prefer to run `git gc` when you are not doing other work.
+information from taking up too much space on disk or in memory. Some
+git commands may automatically run linkgit:git-gc[1], so you don't
+have to worry about running it manually. However, compressing a large
+repository may take a while, so you may want to call `gc` explicitly
+to avoid automatic compression kicking in when it is not convenient.
[[ensuring-reliability]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 13/15] user-manual: Fix 'you - Git' -> 'you--Git' typo
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Use an em-dash, not a hyphen, to join these clauses.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 6446791..dbd0143 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3436,7 +3436,7 @@ $ git log --raw --all
------------------------------------------------
and just looked for the sha of the missing object (4b9458b..) in that
-whole thing. It's up to you - Git does *have* a lot of information, it is
+whole thing. It's up to you--Git does *have* a lot of information, it is
just missing one particular blob version.
[[the-index]]
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v2 00/15] User manual updates
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <7vzjzexv8l.fsf@alter.siamese.dyndns.org>
From: "W. Trevor King" <wking@tremily.us>
This combines my ealier patches:
* user-manual: Rewrite git-gc section for automatic packing
* user-manual: Update for receive.denyCurrentBranch=refuse
With a number of additional fixups. Changes since v1:
* user-manual: Rewrite git-gc section for automatic packing:
- Reworded following suggestions from Junio. This removed the
phrase containing the 'comression' typo pointed out by Javier.
* user-manual: Update for receive.denyCurrentBranch=refuse
- No changes.
Most of the patches are well-focused, with the exception of
"Standardize backtick quoting". I can break this up into smaller
chunks (e.g. "Standardize backtick quoting in Chapter 1", "Standardize
backtick quoting in Chapter 2", …) if this is too much to bite off in
one patch.
I may add additional patches onto the end of this series as I make new
fixes and the series cooks on the list.
W. Trevor King (15):
user-manual: Rewrite git-gc section for automatic packing
user-manual: Update for receive.denyCurrentBranch=refuse
user-manual: Use 'remote add' to setup push URLs
user-manual: Use git branch --merged
user-manual: Add a few references to 'git rebase -i'
user-manual: Give 'git push -f' as an alternative to +master
user-manual: Mention 'git remote add' for remote branch config
user-manual: Standardize backtick quoting
user-manual: Use 'git config --global user.*' for setup
user-manual: Fix 'both: so' -> 'both; so' typo
user-manual: Fix 'http' -> 'HTTP' typos
user-manual: Use request-pull to generate "please pull" text
user-manual: Fix 'you - Git' -> 'you--Git' typo
user-manual: Flesh out uncommitted changes and submodule updates
user-manual: Use --format=tar.gz to create a gzipped tarball
Documentation/user-manual.txt | 436 +++++++++++++++++++++++-------------------
1 file changed, 243 insertions(+), 193 deletions(-)
--
1.8.1.336.g94702dd
^ permalink raw reply
* [PATCH v2 15/15] user-manual: Use --format=tar.gz to create a gzipped tarball
From: W. Trevor King @ 2013-02-10 15:10 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, W. Trevor King
In-Reply-To: <cover.1360508415.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
This functionality was introduced by 0e804e09 (archive: provide
builtin .tar.gz filter, 2011-07-21) for v1.7.7.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 8024758..c04ea51 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -931,12 +931,19 @@ The linkgit: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
+$ git archive --format=tar.gz --prefix=project/ HEAD >latest.tar.gz
-------------------------------------------------
will use HEAD to produce a tar archive in which each filename is
preceded by `project/`.
+Versions of Git older than 1.7.7 don't know about the 'tar.gz' format,
+you'll need to use gzip explicitly:
+
+-------------------------------------------------
+$ git archive --format=tar --prefix=project/ HEAD | gzip >latest.tar.gz
+-------------------------------------------------
+
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.
--
1.8.1.336.g94702dd
^ permalink raw reply related
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