Re: rev-parse fails on objects that contain colon
On Sun, Feb 17, 2013 at 10:37 AM, Orgad Shaneh org...@gmail.com wrote: $ git stash save foo:bar HEAD is now at 9f88dce Foo $ git stash pop foo:bar fatal: Invalid object name 'foo'. $ git rev-parse foo:bar foo:bar fatal: Invalid object name 'foo'. Tested on Windows (msysGit) and Linux. - Orgad Oops! stash pop requires explicit stash. Disregard my message... - Orgad -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] pkt-line: teach packet_get_line a no-op mode
Jeff King wrote: --- a/pkt-line.c +++ b/pkt-line.c @@ -234,9 +234,10 @@ int packet_get_line(struct strbuf *out, *src_len -= 4; len -= 4; - strbuf_add(out, *src_buf, len); + if (out) + strbuf_add(out, *src_buf, len); + packet_trace(*src_buf, len, 0); *src_buf += len; *src_len -= len; - packet_trace(out-buf, out-len, 0); return len; For what it's worth, Reviewed-by: Jonathan Nieder jrnie...@gmail.com The above code has a structure of prepare to return(buf, len); trace(buf, len); discard used part of buf; return; which is nice and readable. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] remote-curl: verify smart-http metadata lines
Jeff King wrote: --- a/remote-curl.c +++ b/remote-curl.c [...] @@ -155,11 +166,13 @@ static struct discovery* discover_refs(const char *service) [...] - strbuf_reset(buffer); - while (packet_get_line(buffer, last-buf, last-len) 0) - strbuf_reset(buffer); + if (read_packets_until_flush(last-buf, last-len) 0) Style nit: this made me wonder What would it mean if read_packets_until_flush() 0? Since the convention for this function is 0 for success, I would personally find if (read_packets_until_flush(...)) handle error; easier to read. + die(smart-http metadata lines are invalid at %s, + refs_url); Especially given that other clients would be likely to run into trouble in the same situation, as long as this cooks in next for a suitable amount of time to catch bad servers, it looks like a good idea. Reviewed-by: Jonathan Nieder jrnie...@gmail.com Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] remote-curl: sanity check ref advertisement from server
Jeff King wrote: If the smart HTTP response from the server is truncated for any reason, we will get an incomplete ref advertisement. If we then feed this incomplete list to fetch-pack, one of a few things may happen: 1. If the truncation is in a packet header, fetch-pack will notice the bogus line and complain. 2. If the truncation is inside a packet, fetch-pack will keep waiting for us to send the rest of the packet, which we never will. Mostly harmless since the operator could hit ^C, but still unpleasant. [...] This fortunately doesn't happen in the normal fetching workflow, because git-fetch first uses the list command, which feeds the refs to get_remote_heads, which does notice the error. However, you can trigger it by sending a direct fetch to the remote-curl helper. Ah. Would a test for this make sense? [...] --- a/remote-curl.c +++ b/remote-curl.c [...] @@ -174,6 +183,9 @@ static struct discovery* discover_refs(const char *service) die(smart-http metadata lines are invalid at %s, refs_url); + if (verify_ref_advertisement(last-buf, last-len) 0) + die(ref advertisement is invalid at %s, refs_url); Won't this error out with protocol error: bad line length character: ERR instead of the current more helpful behavior for ERR lines? Same stylistic comment about what would it mean for the return value to be positive? as in patch 2/3. Aside from those two details, the idea looks sane, though. Good catch, and thanks for a pleasant read. Good night, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] t7800: modernize tests
David Aguilar wrote:
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -10,29 +10,11 @@ Testing basic diff tool invocation
[...]
-restore_test_defaults()
-{
- # Restores the test defaults used by several tests
- remove_config_vars
- unset GIT_DIFF_TOOL
- unset GIT_DIFFTOOL_PROMPT
- unset GIT_DIFFTOOL_NO_PROMPT
- git config diff.tool test-tool
- git config difftool.test-tool.cmd 'cat $LOCAL'
- git config difftool.bogus-tool.cmd false
Yay. :)
[...]
# Ensures that git-difftool ignores bogus --tool values
test_expect_success PERL 'difftool ignores bad --tool values' '
diff=$(git difftool --no-prompt --tool=bad-tool branch)
test $? = 1
- test $diff =
+ test -z $diff
'
Not about this patch: if I add more commands before that diff,
their exit status would be ignored. Could this be made more resilient
using test_expect_code? Something like
test_expect_code 1 git diff --no-prompt --tool=bad-tool branch actual
expect
test_cmp expect actual
[...]
# Specify the diff tool using $GIT_DIFF_TOOL
test_expect_success PERL 'GIT_DIFF_TOOL variable' '
- test_might_fail git config --unset diff.tool
+ difftool_test_setup
+ git config --unset diff.tool
+
GIT_DIFF_TOOL=test-tool
export GIT_DIFF_TOOL
diff=$(git difftool --no-prompt branch)
test $diff = branch
-
- restore_test_defaults
+ sane_unset GIT_DIFF_TOOL
If this test fails, GIT_DIFF_TOOL would remain set which could take
down later tests, too. Could it be set in a subprocess (e.g., a
subshell) to avoid that?
difftool_test_setup
git config --unset diff.tool
echo branch expect
GIT_DIFF_TOOL=test-tool git difftool --no-prompt branch actual
test_cmp expect actual
[...]
test_expect_success PERL 'GIT_DIFF_TOOL overrides' '
- git config diff.tool bogus-tool
- git config merge.tool bogus-tool
-
+ difftool_test_setup
+ test_config diff.tool bogus-tool
+ test_config merge.tool bogus-tool
GIT_DIFF_TOOL=test-tool
export GIT_DIFF_TOOL
diff=$(git difftool --no-prompt branch)
Likewise.
[...]
GIT_DIFF_TOOL=bogus-tool
export GIT_DIFF_TOOL
diff=$(git difftool --no-prompt --tool=test-tool branch)
Likewise.
[...]
test_expect_success PERL 'GIT_DIFFTOOL_NO_PROMPT variable' '
+ difftool_test_setup
GIT_DIFFTOOL_NO_PROMPT=true
export GIT_DIFFTOOL_NO_PROMPT
diff=$(git difftool branch)
Likewise.
[...]
test_expect_success PERL 'GIT_DIFFTOOL_PROMPT variable' '
- git config difftool.prompt false
+ difftool_test_setup
+ test_config difftool.prompt false
GIT_DIFFTOOL_PROMPT=true
export GIT_DIFFTOOL_PROMPT
prompt=$(echo | git difftool branch | tail -1)
Likewise. This one loses the exit status from 'git difftool',
which could be avoided by writing to temporary files:
echo input
GIT_DIFFTOOL_PROMPT=true git difftool branch input output
prompt=$(tail -1 output)
[...]
test_expect_success PERL 'difftool last flag wins' '
+ difftool_test_setup
diff=$(git difftool --prompt --no-prompt branch)
test $diff = branch
- restore_test_defaults
-
prompt=$(echo | git difftool --no-prompt --prompt branch | tail -1)
[...]
Likewise.
Thanks for cleaning up, and sorry I don't have anything more
substantial to offer.
Hope that helps,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] t7800: defaults is no longer a builtin tool name
David Aguilar wrote: t7800 tests that configured commands can override builtins, but this test was not adjusted when the defaults file was removed because the test continued to pass. Adjust the test to use the everlasting vimdiff Heh. :) tool name instead of defaults so that it correctly tests against a tool that is known by mergetool--lib. Makes sense. Thanks for a pleasant read. Good night, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] contrib/subtree/t: Added tests for .gitsubtree support
Paul Campbell wrote: Is there was a better way to verify that the push operation succeeds then grepping for a SHA1? IIRC then when a push fails, it will exit with nonzero status (so the usual -chaining would propagate the error). Alternatively, one can fetch, ls-remote, or enter the target repo and use history inspection tools to check that the result is as expected. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone combined with --depth, --branch and --single-branch
Hi all, Using git 1.7.10.4 I find the behavior or documentation of git clone --single-branch confusing. Docs currently say: man git-clone --single-branch Clone only the history leading to the tip of a single branch, either specified by the --branch option or the primary branch remote�8099s HEAD points at. When creating a shallow clone with the --depth option, this is the default, unless --no-single-branch is given to fetch the histories near the tips of all branches. based onthis documentation, I cannot understand any of the results I get when combining --depth and --singe-branch. I start with this repo1 (for how to createin linux, see bottom): git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 (bar) | * 432b5ec-m1 (HEAD, master) |/ * 39df203-0 git clone repo1 repo2 --depth 1 cd repo2 git log --pretty=format:'%h-%s %d' --graph --decorate --all * 432b5ec-m1 (HEAD, origin/master, origin/HEAD, master) * 39df203-0 # Why are branches foo and bar missing? cd .. git clone repo1 repo3 --depth 1 --branch foo git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (HEAD, origin/foo, foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 | * 432b5ec-m1 (origin/master, origin/HEAD) |/ * 39df203-0 # Why is --depth not having effect, and why is branch bar not there, yet master is? cd .. git clone repo1 repo4 --depth 1 --branch foo --single-branch git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (HEAD, origin/foo, foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 | * 432b5ec-m1 (origin/master, origin/HEAD) |/ * 39df203-0 # Why is --depth not having effect, and why is branch master still there? ### # Okay, so --depth seems to generally not work when cloning locally. So maybe when doing so from github: git clone https://github.com/git/git --depth 1 cd git git log --pretty=format:'%h-%s %d' --graph --decorate --all * 7b6e784-Update draft release notes to 1.8.2 (HEAD, origin/master, origin/HEAD, master) * 17e45f8-Merge branch 'wk/man-deny-current-branch-is-default-these-days' (grafted) git branch -a * master remotes/origin/HEAD - origin/master remotes/origin/master git tag # Why don't other branches appear here? # Hm, I'll add --branch master to the command git clone https://github.com/git/git git3 --depth 1 --branch master cd git3 git branch -a * master remotes/origin/HEAD - origin/master remotes/origin/master remotes/origin/next remotes/origin/pu remotes/origin/todo git tag gitgui-0.10.0 gitgui-0.10.1 gitgui-0.10.2 ... # And why DO they appear here? Why do I now get all tags? # Same result for --branch next # okay, let's try adding --single-branch git clone https://github.com/git/git git4 --depth 1 --branch next --single-branch cd git4 git branch -a * next remotes/origin/next remotes/origin/pu remotes/origin/todo # Now I don't get master, but I still get those other branches??? And also tags? Now I am aware that a bug was fixed in git 1.8.0: https://raw.github.com/gitster/git/master/Documentation/RelNotes/1.8.0.txt * A repository created with git clone --single had its fetch refspecs set up just like a clone without --single, leading the subsequent git fetch to slurp all the other branches, defeating the whole point of specifying only this branch. But even considering that bug (and assuming it also affected git clone), the results I get for 1.7.10.4 seem all weird, and not really following the documentation. So I am sorry I cannot phrase this as a single question, as the results are not consistent with each other or the documentation, and those results seem to be related. cheers, Thibault Kruse How to create local repo1: mkdir repo1 cd repo1 git init echo 0 foo.txt git add foo.txt git commit -m 0 git co master -b bar echo 1 bar.txt git add bar.txt git commit -m 1 git co bar -b foo echo 2 foo.txt git add foo.txt git commit -m 2 echo 3 foo.txt git add foo.txt git commit -m 3 echo 4 foo.txt git add foo.txt git commit -m 4 echo 5 foo.txt git add foo.txt git commit -m 5 git co master echo 1 master.txt git add master.txt git commit -m m1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Git clone of a bundle fails, but works (somewhat) when run with strace
On Fri, 15 Feb 2013 23:01:09 -0500, Jeff King wrote: On Sat, Feb 16, 2013 at 12:03:58AM +, Alain Kalker wrote: ---test.sh--- #!/bin/sh make clean make || return 125 GIT=$(pwd)/git cd /tmp rm -rf testrepo mkdir testrepo cd testrepo $GIT init echo test test.txt $GIT add test.txt $GIT commit -m Add test.txt $GIT bundle create ../testrepo.bundle master || return 125 cd .. rm -rf testrepofrombundle $GIT clone testrepo.bundle testrepofrombundle || return 1 --- I was unable to find a bad revision. After a lot more searching I found that I had `git` aliased to `hub`, a tool used to make Github actions easier. Eliminating `hub` from the equation resolved most problems. Great. The only ones remaining are the confusing error message from `git bundle create` and the missing HEAD (you can interpret that in different ways) ;-) I do not see any odd message from bundle create in the recipe above. Mine says: $ git bundle create ../repo.bundle master Counting objects: 3, done. Writing objects: 100% (3/3), 209 bytes, done. Total 3 (delta 0), reused 0 (delta 0) What you _might_ be seeing is the fact that the invocation above is likely to be running two different versions of git under the hood. git bundle will invoke git rev-list, and it will use the first git in your PATH, even if it is not $GIT. The proper way to test an un-installed version of git is to use $YOUR_GIT_BUILD/bin-wrappers/git, which will set up environment variables sufficient to make sure all sub-gits are from the same version. Sometimes mixing versions can have weird results (e.g., the new git bundle expects rev-list to have a particular option, but the older version does not have it). Thanks for the very useful tip! I will try to remember to use this for any future testing. Secondly, I do get the same warning about HEAD: $ git clone repo.bundle repofrombundle Cloning into 'repofrombundle'... Receiving objects: 100% (3/3), done. warning: remote HEAD refers to nonexistent ref, unable to checkout. but that warning makes sense. You did not create a bundle that contains HEAD, therefore when we clone it, we do not know what to point HEAD to. You probably wanted git bundle create ../repo.bundle --all which includes both master and HEAD. That explains it, thanks! Maybe this could be added as an example to the documentation for `git bundle`? People looking at `man git-bundle` hoping to use it as one possible way to make a backup of a Git repository might not realize right away that --all is the way to specify all refs, like with `git log`. It would be slightly more accurate to say the remote HEAD does not exist, rather than refers to nonexistent ref. It would perhaps be nicer still for git clone to make a guess about the correct HEAD when one is not present (especially in the single-branch case, it is easy to make the right guess). Patches welcome. In the meantime, you can clone with -b master to tell it explicitly, or you can git checkout master inside the newly-cloned repository. Thanks again for your help, very welcome :-) Alain -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Anybody know a website with up-to-date git documentation?
On Wed, Jan 30, 2013 at 6:07 PM, Sitaram Chamarty sitar...@gmail.com wrote: On Wed, Jan 30, 2013 at 09:18:24AM -0800, Junio C Hamano wrote: Max Horn m...@quendi.de writes: On 30.01.2013, at 16:59, Sitaram Chamarty wrote: I'm curious... what's wrong with 'git checkout html' from the git repo and just browsing them using a web browser? Armed with that knowledge, I think Sitaram may have something like this: [remote htmldocs] Hmm; I don't recall ever doing that. But I just realised that my html branch is stuck at 1.7.7: $ git branch -v -v | grep html html 8fb66e5 [origin/html] Autogenerated HTML docs for v1.7.7-138-g7f41b6 Is it possible that upto that point, the main git.git repo did carry this branch also? Yes. n1xim@atom:~/tmp/git_dev/git$ git branch -a dn/utf16_check * master remotes/origin/HEAD - origin/master remotes/origin/html remotes/origin/maint remotes/origin/man remotes/origin/master remotes/origin/next remotes/origin/pu remotes/origin/todo n1xim@atom:~/tmp/git_dev/git$ git remote show origin * remote origin Fetch URL: git://git.kernel.org/pub/scm/git/git.git Push URL: git://git.kernel.org/pub/scm/git/git.git HEAD branch: master Remote branches: mainttracked master tracked next tracked pu tracked refs/remotes/origin/html stale (use 'git remote prune' to remove) refs/remotes/origin/man stale (use 'git remote prune' to remove) todo tracked Local branch configured for 'git pull': master merges with remote master Local ref configured for 'git push': master pushes to master (local out of date) n1xim@atom:~/tmp/git_dev/git$ git log refs/remotes/origin/html commit 5723afaf3a61cef537e1f4dfa88f8faf31060ef0 Author: Junio C Hamano ju...@kernel.org Date: Wed Aug 31 00:49:23 2011 + Autogenerated HTML docs for v1.7.7-rc0-72-g4b5ea n1xim@atom:~/tmp/git_dev/git$ git log refs/remotes/origin/man commit e193e4189407968b3c46992e3eac60d38424286e Author: Junio C Hamano ju...@kernel.org Date: Wed Aug 31 00:49:25 2011 + Autogenerated manpages for v1.7.7-rc0-72-g4b5ea I haven't bothered to plunge and expunge my local repo yet as I never actually made use of those branches. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone combined with --depth, --branch and --single-branch
On Sun, Feb 17, 2013 at 7:29 PM, Thibault Kruse tibokr...@googlemail.com wrote: git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 (bar) | * 432b5ec-m1 (HEAD, master) |/ * 39df203-0 git clone repo1 repo2 --depth 1 cd repo2 git log --pretty=format:'%h-%s %d' --graph --decorate --all * 432b5ec-m1 (HEAD, origin/master, origin/HEAD, master) * 39df203-0 # Why are branches foo and bar missing? --depth implies --single-branch. Without explicit --branch, --single-branch will fetch HEAD. You need --no-single-branch to get foo and bar. cd .. git clone repo1 repo3 --depth 1 --branch foo git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (HEAD, origin/foo, foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 | * 432b5ec-m1 (origin/master, origin/HEAD) |/ * 39df203-0 # Why is --depth not having effect, and why is branch bar not there, yet master is? I'm not sure, but I can't reproduce it. There's an unreleased fix in depth calculation (682c7d2 (upload-pack: fix off-by-one depth calculation in shallow clone - 2013-01-11) that might affect this. You may want to try again with master. I got this with the same command * edbd6cb (grafted, HEAD, origin/foo, foo) 5 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] read_directory: avoid invoking exclude machinery on tracked files
pclo...@gmail.com wrote on Sun, 17 Feb 2013 11:39 +0700: On Sun, Feb 17, 2013 at 1:11 AM, Pete Wyckoff p...@padd.com wrote: pclo...@gmail.com wrote on Sat, 16 Feb 2013 14:17 +0700: Finally some numbers (best of 20 runs) that shows why it's worth all the hassle: git status | webkit linux-2.6 libreoffice-core gentoo-x86 -+-- before | 1.097s0.208s 0.399s 0.539s after| 0.736s0.159s 0.248s 0.501s nr. patterns |89 376 19 0 nr. tracked | 182k 40k 63k 101k Thanks for this work. I repeated some of the tests across NFS, where I'd expect to see bigger differences. This is about reducing CPU processing time, not I/O time. So no bigger differences is expected. I/O time can be reduced with inotify, or fam in nfs case because inotify does not support nfs. Numbers from the last mail were core.preloadindex=true. Here's time output from average runs: stock = 0m2.28s user 0m4.18s sys 0m11.28s elapsed 57.39 %CPU duy = 0m1.25s user 0m4.43s sys 0m7.45s elapsed 76.41 %CPU With this huge repo, preloadindex may be stressing directory cache behavior on the NFS server or client. Your patch helps both CPU and wait time by avoiding the 6000-odd open() of non-existent .gitignore. With core.preloadindex=false, it's a 1 sec speedup, all from CPU: stock = 0m2.18s user 0m1.59s sys 0m7.78s elapsed 48.45 %CPU duy = 0m1.17s user 0m1.63s sys 0m6.91s elapsed 40.59 %CPU -- Pete -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: [PATCH v2 02/15] user-manual: Update for receive.denyCurrentBranch=refuse
On Thu, Feb 14, 2013 at 10:57:21AM -0800, Junio C Hamano wrote: So let's tone everything down and do this instead: -- 8 -- From: W. Trevor King wk...@tremily.us Date: Fri, 8 Feb 2013 12:04:20 -0500 Subject: [PATCH] user-manual: Update for receive.denyCurrentBranch=refuse acd2a45 (Refuse updating the current branch in a non-bare repository via push, 2009-02-11) changed the default to refuse such a push, but it forgot to update the docs. 7d182f5 (Documentation: receive.denyCurrentBranch defaults to 'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to update the user manual. Signed-off-by: W. Trevor King wk...@tremily.us Signed-off-by: Junio C Hamano gits...@pobox.com --- Documentation/user-manual.txt | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 85651b5..7c534dc 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1986,9 +1986,10 @@ handling this case. Note that the target of a push is normally a def_bare_repository,bare repository. You can also push to a -repository that has a checked-out working tree, but the working tree -will not be updated by the push. This may lead to unexpected results if -the branch you push to is the currently checked-out branch! +repository that has a checked-out working tree, but a push to update the +currently checked-out branch is denied by default to prevent confusion. +See the description ofthe 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 Looks good to me. Thanks, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: git clone combined with --depth, --branch and --single-branch
Hi Duy, On Sun, Feb 17, 2013 at 3:32 PM, Duy Nguyen pclo...@gmail.com wrote: On Sun, Feb 17, 2013 at 7:29 PM, Thibault Kruse tibokr...@googlemail.com wrote: git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 (bar) | * 432b5ec-m1 (HEAD, master) |/ * 39df203-0 git clone repo1 repo2 --depth 1 cd repo2 git log --pretty=format:'%h-%s %d' --graph --decorate --all * 432b5ec-m1 (HEAD, origin/master, origin/HEAD, master) * 39df203-0 # Why are branches foo and bar missing? --depth implies --single-branch. Without explicit --branch, --single-branch will fetch HEAD. You need --no-single-branch to get foo and bar. Agreed, sorry. I forgot that --depth implied --single-branch. Probably because it don't like that being a default that breaks behavior to versions that did not have the --single-branch feature. So this example is the only one which I agree does actually what can be expected from the documentation (with respect to branches. --depth also does not restrict the history length, but the example does not show it). cd .. git clone repo1 repo3 --depth 1 --branch foo git log --pretty=format:'%h-%s %d' --graph --decorate --all * 4565162-5 (HEAD, origin/foo, foo) * 20ce846-4 * a0615eb-3 * fa4131d-2 * f0683bd-1 | * 432b5ec-m1 (origin/master, origin/HEAD) |/ * 39df203-0 # Why is --depth not having effect, and why is branch bar not there, yet master is? I'm not sure, but I can't reproduce it. Do you mean you cannot reproduce with 1.7.10.4? So far I used ubuntu packaged versions, Here is what I got with master: git --version git version 1.8.1.3.619.g7b6e784 # added commit m2 and m3 to master branch in repo1 to show that --depth is not working locally git clone repo1 repo2 --depth 1 git log --pretty=format:'%h-%s %d' --graph --decorate --all * 704f0c4-m3 (HEAD, origin/master, origin/HEAD, master) * 7b90b28-m2 * 1fa92bd-m1 * 5da3517-0 So I still get the --depth not having affect locally, but I confirm all other cases I posted work as expected with 1.8.1.3.619.g7b6e784. Meaning --depth works from a remote repo, and --single-branch (implied by depth) really just creates that branch locally. I don't even know where to start looking for why --depth has no effect for disk-local remotes. I don't have the git command aliased, and in repo1, I get: alias.br=branch alias.co=checkout alias.ci=commit alias.di=diff alias.st=status alias.mt=mergetool alias.pr=pull --rebase alias.ri=rebase --interactive alias.sa=stash apply alias.c-p=cherry-pick alias.lg=!git log --pretty=format:%h%x09%an%x09%ad%x09%s alias.lgg=log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)%an%Creset' --abbrev-commit --date=relative alias.top=!eval cd $(pwd)/$(git rev-parse --show-cdup) pwd core.excludesfile=/home/kruset/.bashconfig/gitignore.global core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true Not sure whether any of the core properties can cause this. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Git clone of a bundle fails, but works (somewhat) when run with strace
From: Alain Kalker a.c.kal...@gmail.com Sent: Sunday, February 17, 2013 1:01 PM On Fri, 15 Feb 2013 23:01:09 -0500, Jeff King wrote: On Sat, Feb 16, 2013 at 12:03:58AM +, Alain Kalker wrote: ---test.sh--- #!/bin/sh [...] but that warning makes sense. You did not create a bundle that contains HEAD, therefore when we clone it, we do not know what to point HEAD to. You probably wanted git bundle create ../repo.bundle --all which includes both master and HEAD. That explains it, thanks! Maybe this could be added as an example to the documentation for `git bundle`? People looking at `man git-bundle` hoping to use it as one possible way to make a backup of a Git repository might not realize right away that --all is the way to specify all refs, like with `git log`. I had posted a documentation patch back in Setemeber last year, http://thread.gmane.org/gmane.comp.version-control.git/205887/focus=205897, however Junio highlighted some additional concerns that I wasn't able to respond to at the time. It may be worth resurrecting once the concerns have been addressed. It would be slightly more accurate to say the remote HEAD does not exist, rather than refers to nonexistent ref. It would perhaps be nicer still for git clone to make a guess about the correct HEAD when one is not present (especially in the single-branch case, it is easy to make the right guess). Patches welcome. In the meantime, you can clone with -b master to tell it explicitly, or you can git checkout master inside the newly-cloned repository. Thanks again for your help, very welcome :-) Alain More majordomo info at http://vger.kernel.org/majordomo-info.html - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.2899 / Virus Database: 2639/6108 - Release Date: 02/16/13 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: git clone combined with --depth, --branch and --single-branch
Actually, using git 1.8.3, I get: git clone repo1 repo2 --depth 1 warning: --depth is ignored in local clones; use file:// instead. ... So I guess the warning says it all, it helps to read it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone tag shallow
Hi all, I notice that using git 1.8.3, I can call git clone repo1 repo2 --branch tagname with a tag, not a branch. Is this going to be a stable and documented feature? cheers, Thibault -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] remote-curl: verify smart-http metadata lines
On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote: Jeff King wrote: --- a/remote-curl.c +++ b/remote-curl.c [...] @@ -155,11 +166,13 @@ static struct discovery* discover_refs(const char *service) [...] - strbuf_reset(buffer); - while (packet_get_line(buffer, last-buf, last-len) 0) - strbuf_reset(buffer); + if (read_packets_until_flush(last-buf, last-len) 0) Style nit: this made me wonder What would it mean if read_packets_until_flush() 0? Since the convention for this function is 0 for success, I would personally find if (read_packets_until_flush(...)) handle error; easier to read. My intent was that it followed the error convention of negative is error, 0 is success, and positive is not used, but reserved for future use. And I tend to think the 0 makes it obvious that we are interested in error. But I don't feel that strongly, so if people would rather see it the other way, I can live with it. + die(smart-http metadata lines are invalid at %s, + refs_url); Especially given that other clients would be likely to run into trouble in the same situation, as long as this cooks in next for a suitable amount of time to catch bad servers, it looks like a good idea. Yeah, I have a slight concern that this series would break something in another implementation, so I would like to see this cook in next for a while (and would be slated for master probably not in this release, but in the next one). But I think this change is pretty straightforward. If an implementation is producing bogus packet lines and expecting us not to complain, it really needs to be fixed. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] remote-curl: sanity check ref advertisement from server
On Sun, Feb 17, 2013 at 03:05:34AM -0800, Jonathan Nieder wrote: Jeff King wrote: If the smart HTTP response from the server is truncated for any reason, we will get an incomplete ref advertisement. If we then feed this incomplete list to fetch-pack, one of a few things may happen: 1. If the truncation is in a packet header, fetch-pack will notice the bogus line and complain. 2. If the truncation is inside a packet, fetch-pack will keep waiting for us to send the rest of the packet, which we never will. Mostly harmless since the operator could hit ^C, but still unpleasant. Fetching is not always interactive. The deadlock I ran into (and again, I am not sure if this fixes it or not, but it is _a_ deadlock) was on a server farm doing a large number of fetch checkout deploy operations. Only some of them hung, but it took a while to figure out what was going on. [...] This fortunately doesn't happen in the normal fetching workflow, because git-fetch first uses the list command, which feeds the refs to get_remote_heads, which does notice the error. However, you can trigger it by sending a direct fetch to the remote-curl helper. Ah. Would a test for this make sense? A test would be great, if you can devise a way to reliably produce truncated git output (but still valid http output). In the real-world problem I had, I believe the truncation was caused by an intermediate reverse proxy that hit a timeout. I simulated truncation by using netcat to replay munged http headers and git output. I suspect the simplest portable thing would be a static file of truncated git output, served by apache, which would need custom configuration to serve it with the correct content-type header. It seemed like a lot of test infrastructure to check for a very specific thing, so I abandoned trying to make a test. + if (verify_ref_advertisement(last-buf, last-len) 0) + die(ref advertisement is invalid at %s, refs_url); Won't this error out with protocol error: bad line length character: ERR instead of the current more helpful behavior for ERR lines? I don't think so. Don't ERR lines appear inside their own packets? We are just verifying that our packets are syntactically correct here, and my reading of get_remote_heads is that the ERR appears inside the packetized data. The one thing we do also check, though, is that we end with a flush packet. So depending on what servers produce, it may mean we trigger this complaint instead of passing the ERR along to fetch-pack. Rather than doing this fake syntactic verification, I wonder if we should simply call get_remote_heads, which does a more thorough check (and is what we _would_ call in the list case, and what fetch-pack will call once we pass data to it). It's slightly less efficient, in that it starts a new thread and actually builds the linked list of refs. But it probably isn't that big a deal (and normal operation does a list first which does that _anyway_). Same stylistic comment about what would it mean for the return value to be positive? as in patch 2/3. Same response. :) -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git bundles for backup and cloning: the Zaphod Beeblebrox thread
From the current documentation for git-bundle(1), it may not be clear for users unfamilliar with Git, how to create a bundle which can be used for backup purposes, or, more generally, to clone to a completely new repository. Philip Oakley has posted a documentation patch some time ago, but Junio has pointed out several concerns. Ref: http://thread.gmane.org/gmane.comp.version-control.git/205887/ focus=205897 Here's my attempt to summarize the concerns, adding some of my own, and a possible solution. 1. Missing HEAD syndrome $ git bundle create bundle master -or- $ git bundle create bundle branchname... -or- $ git bundle create bundle --branches -then- $ git clone bundle dir will be unable to checkout any files due to a missing ref for HEAD. Though this can be fixed by going into dir and doing `git checkout ref`, this is not very user-friendly. 2. Detached HEAD syndrome $ git bundle create bundle HEAD $ git clone bundle dir will checkout files alright, but leaves one in a detached HEAD state. 3. Exploding HEAD syndrome $ git bundle create bundle --all will add the HEAD, but will add refs from refs/remotes/* too, which is not desirable when cloning, unless one sets up all the remotes (e.g. by restoring .git/config) as well. Finally, my solution for backing up only the local branches of a repository: $ git bundle create bundle --branches HEAD but this may not be very easy for new users to figure out on their own unless well documented (perhaps a new flag?) Any comments or suggestions (including HHGTTG references!) are very welcome. -Alain -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git bundles for backup and cloning: the Zaphod Beeblebrox thread
On Sun, 17 Feb 2013 19:28:33 +, Alain Kalker wrote: From the current documentation for git-bundle(1), it may not be clear for users unfamilliar with Git, how to create a bundle which can be used for backup purposes, or, more generally, to clone to a completely new repository. Philip Oakley has posted a documentation patch some time ago, but Junio has pointed out several concerns. Ref: http://thread.gmane.org/gmane.comp.version-control.git/205887/ focus=205897 Here's my attempt to summarize the concerns, adding some of my own, and a possible solution. 1. Missing HEAD syndrome $ git bundle create bundle master -or- $ git bundle create bundle branchname... -or- $ git bundle create bundle --branches -then- $ git clone bundle dir will be unable to checkout any files due to a missing ref for HEAD. Though this can be fixed by going into dir and doing `git checkout ref`, this is not very user-friendly. 2. Detached HEAD syndrome $ git bundle create bundle HEAD $ git clone bundle dir will checkout files alright, but leaves one in a detached HEAD state. 3. Exploding HEAD syndrome $ git bundle create bundle --all will add the HEAD, but will add refs from refs/*, including all remotes, which is not desirable when cloning, unless one sets up all the remotes as well. Finally, my solution for backing up only the local branches of a repository: $ git bundle create bundle --branches HEAD # for backup purposes -or- $ git bundle create bundle master HEAD # for hosting or redistribution but this may not be very easy for new users to figure out on their own unless well documented (perhaps a new flag?) Any comments or suggestions (including HHGTTG references!) are very welcome. -Alain -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] submodule: add 'deinit' command
With git submodule init the user is able to tell git he cares about one or more submodules and wants to have it populated on the next call to git submodule update. But currently there is no easy way he could tell git he does not care about a submodule anymore and wants to get rid of his local work tree (except he knows a lot about submodule internals and removes the submodule.$name.url setting from .git/config together with the work tree himself). Help those users by providing a 'deinit' command. This removes the whole submodule.name section from .git/config either for the given submodule(s) or for all those which have been initialized if '.' is given. Fail if the current work tree contains modifications unless forced. Complain when for a submodule given on the command line the url setting can't be found in .git/config, but nonetheless don't fail. Add tests and link the man pages of git submodule deinit and git rm to assist the user in deciding whether removing or unregistering the submodule is the right thing to do for him. Also add the deinit subcommand to the completion list. Signed-off-by: Jens Lehmann jens.lehm...@web.de --- Am 13.02.2013 20:56, schrieb Junio C Hamano: Jens Lehmann jens.lehm...@web.de writes: Junio, this looks like a we have v5 as soon as we decide what to do with the not initialized messages when '.' is used, right? OK. I myself do not deeply care if we end up special casing . or not; I'll leave it up to you and other submodule folks. Here we go, changes to v4 are: - I decided to do the proposed special casing for .; no messages about uninitialized submodules will show up anymore (this is also tested) - The spelling fixes and better 'uninitialized' message Phil proposed - Added the missing quotation for $sm_path in output strings - deinit is added to the submodule completion list - Added two missing in t7400 Documentation/git-rm.txt | 4 ++ Documentation/git-submodule.txt| 18 +- contrib/completion/git-completion.bash | 2 +- git-submodule.sh | 79 +- t/t7400-submodule-basic.sh | 101 + 5 files changed, 201 insertions(+), 3 deletions(-) diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt index 92bac27..1d876c2 100644 --- a/Documentation/git-rm.txt +++ b/Documentation/git-rm.txt @@ -149,6 +149,10 @@ files that aren't ignored are present in the submodules work tree. Ignored files are deemed expendable and won't stop a submodule's work tree from being removed. +If you only want to remove the local checkout of a submodule from your +work tree without committing the removal, +use linkgit:git-submodule[1] `deinit` instead. + EXAMPLES `git rm Documentation/\*.txt`:: diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index a0c9df8..bc06159 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -13,6 +13,7 @@ SYNOPSIS [--reference repository] [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] +'git submodule' [--quiet] deinit [-f|--force] [--] path... 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] @@ -134,6 +135,19 @@ init:: the explicit 'init' step if you do not intend to customize any submodule locations. +deinit:: + Unregister the given submodules, i.e. remove the whole + `submodule.$name` section from .git/config together with their work + tree. Further calls to `git submodule update`, `git submodule foreach` + and `git submodule sync` will skip any unregistered submodules until + they are initialized again, so use this command if you don't want to + have a local checkout of the submodule in your work tree anymore. If + you really want to remove a submodule from the repository and commit + that use linkgit:git-rm[1] instead. ++ +If `--force` is specified, the submodule's work tree will be removed even if +it contains local modifications. + update:: Update the registered submodules, i.e. clone missing submodules and checkout the commit specified in the index of the containing repository. @@ -213,8 +227,10 @@ OPTIONS -f:: --force:: - This option is only valid for add and update commands. + This option is only valid for add, deinit and update commands. When running add, allow adding an otherwise ignored submodule path. + When running deinit the submodule work trees will be removed even if + they contain local changes. When running update, throw away local changes in submodules when switching to a different commit; and always run a
Re: [PATCH v5] submodule: add 'deinit' command
Jens Lehmann jens.lehm...@web.de writes:
Here we go, changes to v4 are:
- I decided to do the proposed special casing for .; no messages
about uninitialized submodules will show up anymore (this is also
tested)
- The spelling fixes and better 'uninitialized' message Phil proposed
- Added the missing quotation for $sm_path in output strings
- deinit is added to the submodule completion list
- Added two missing in t7400
Thanks for being thorough. I honestly did not expect this topic to
take this many cycles before becoming 'next-ready'.
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..0fb6ee0 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -547,6 +548,82 @@ cmd_init()
}
#
+# Unregister submodules from .git/config and remove their work tree
+#
+# $@ = requested paths (use '.' to deinit all submodules)
+#
+cmd_deinit()
+{
+ # parse $args after submodule ... init.
+ while test $# -ne 0
+ do
..
+ done
+
+ if test $# = 0
+ then
+ die $(eval_gettext Use '.' if you really want to deinitialize
all submodules)
I do not think I saw anybody mentioned this so far, but how is
deinit supposed to work inside a subdirectory of a superproject?
If the answer is to work on submodules appear in that subdirectory,
'.' should probably not mean all in the superproject I think?
+ module_list $@ |
+ while read mode sha1 stage sm_path
+ do
+ die_if_unmatched $mode
+ name=$(module_name $sm_path) || exit
+ url=$(git config submodule.$name.url)
+ if test -z $url
+ then
+ test $# -ne 1 || test $@ = . ||
+ say $(eval_gettext Submodule '\$name' is not
initialized for path '\$sm_path')
+ continue
+ fi
This 'test $@ = .' makes readers feel uneasy. This particular
invocation happens to be safe only because it is protected with
test $# -ne 1 ||, but for all other values of $# this will result
in a syntax error. 'test $1 = .' would make the intention of
the check more clear.
But stepping back a bit, is the condition this test is trying to
warn against really worth warning?
It seems that this warn if user told us to deinitialize a submodule
that hasn't been initialized is from the very initial round of this
series, and not something other people asked for during the review.
If somebody did
git submodule deinit foo bar
and then later said:
git submodule deinit foo
would it a mistake that the user wants to be warned about?
Perhaps the user did not mean to deinitialize foo (e.g. wanted to
*initialize* foo instead, or wanted to deinitialize *foz* instead)
and that is worth warning about? I am not sure, but I have a
feeling that we can do without this check.
Also the value of submodule.$name.url is not used in the later
codepath to ensure that the named submodule is in the pristine state
in the superproject's working tree (i.e. no submodule.$name section
in the local configuration, no working tree for that submodule), so
it may be even a good change to remove the does submodule.$name.url
exist check and always do the deinitialize process. That would
give the users a way to recover from a state where a submodule is
only half initialized for some reason safely, no?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4.1 09/12] sequencer.c: teach append_signoff to avoid adding a duplicate newline
On Fri, Feb 15, 2013 at 10:58:38AM -0800, Brandon Casey wrote: On Thu, Feb 14, 2013 at 9:58 AM, John Keeping j...@keeping.me.uk wrote: As Jonathan Nieder wondered before [1], this changes the behaviour when the commit message is empty. Before this commit, there is an empty line followed by the S-O-B line; now the S-O-B is on the first line of the commit. The previous behaviour seems better to me since the empty line is hinting that the user should fill something in. It looks particularly strange if your editor has syntax highlighting for commit messages such that the first line is in a different colour. Are you talking about the output produced by format-patch? Or are you talking about what happens when you do 'commit --amend -s' for a commit with an empty commit message. (The email that you referenced was about the behavior of format-patch). I'm talking about plain 'commit -s' which seems to use the same code path. I'm thinking you must be talking about the 'commit --amend -s' behavior since you mentioned your editor. Is there another case that is affected by this? Normally, any extra blank lines that precede or follow a commit message are removed before the commit object is created. So, I guess it wouldn't hurt to insert a newline (or maybe it should be two?) before the signoff in this case. Would this provide an improvement or change for any other commands than 'commit --amend -s'? If we want to do this, then I'd probably do it like this: - if (len msgbuf-buf[len - 1] != '\n') + if (!len || msgbuf-buf[len - 1] != '\n') append_newlines = \n\n; - else if (len 1 msgbuf-buf[len - 2] != '\n') + else if (len == 1 || msgbuf-buf[len - 2] != '\n') append_newlines = \n; This would ensure there were two newlines preceding the sob. The editor would place its cursor on the top line where the user should begin typing in a commit message. If an editor was not opened up (e.g. if 'git cherry-pick -s --allow-empty-message ...' was used) then the normal mechanism that removes extra blank lines would trigger to remove the extra blank lines. I think that's reasonable. Two blank lines seems like an improvement to me, FWIW. John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] read_directory: avoid invoking exclude machinery on tracked files
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
If path_handled is returned, contents goes up. And if check_only is
true, the loop could be broken early. These will not happen when
treat_one_path (and its wrapper treat_path) returns
path_ignored. dir_add_name internally does a cache_name_exists() check
so it makes no difference.
To avoid this behavior change, treat_one_path is instructed to skip
the optimization when check_only or contents is used.
OK, that makes more understandable why this is safe.
@@ -1242,9 +1246,23 @@ enum path_treatment {
static enum path_treatment treat_one_path(struct dir_struct *dir,
struct strbuf *path,
const struct path_simplify *simplify,
- int dtype, struct dirent *de)
+ int dtype, struct dirent *de,
+ int exclude_shortcut_ok)
{
...
@@ -1331,18 +1347,29 @@ static int read_directory_recursive(struct dir_struct
*dir,
goto out;
while ((de = readdir(fdir)) != NULL) {
- switch (treat_path(dir, de, path, baselen, simplify)) {
+ switch (treat_path(dir, de, path, baselen,
+simplify,
+!check_only !contents)) {
...
Between these two places we may want to say what kind of short-cut
we are talking about, but there only is one kind of short-cut at
this moment, so let's leave that to other people who want to further
optimize things in this codepath by adding other short-cuts.
Thanks; will queue.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/9] User manual updates
From: W. Trevor King wk...@tremily.us
Changes since v2 (v2 numbering):
* 01: user-manual: Rewrite git-gc section for automatic packing
- Dropped (graduated to 'maint')
* 02: user-manual: Update for receive.denyCurrentBranch=refuse
- Dropped (graduated to 'master')
* 03: user-manual: Use 'remote add' to setup push URLs
- Removed 'git config' examples
- Show .git/config changes made by 'remote add'
* 04: user-manual: Use git branch --merged
- Dropped (not an improvement)
* 05: user-manual: Add a few references to 'git rebase -i'
- Removed an extra blank line
- Restructured reroll sections:
* cherry-pick suggestions removed
* commit --amend discussion isolated in its own section
* format-patch restructuring moved to its own section
* new interactive rebase section. The contents of this section
borrow liberally from git-rebase.txt.
* 06: user-manual: Give 'git push -f' as an alternative to +master
* 07: user-manual: Mention 'git remote add' for remote branch config
- Simplified section to avoid 'git config'
* 08: user-manual: Standardize backtick quoting
- Fix `{plus}` - `+` in backticked text
* 09: user-manual: Use 'git config --global user.*' for setup
- Remove reference to stanza.
* 10: user-manual: Fix 'both: so' - 'both; so' typo
- Dropped (graduated to 'maint')
* 11: user-manual: Fix 'http' - 'HTTP' typos
- Dropped (graduated to 'maint')
* 12: user-manual: Use request-pull to generate please pull text
- Add an explicit push before request-pull
- Use the `mytree` remote instead of an explicit example URL
* 13: user-manual: Fix 'you - Git' - 'you--Git' typo
- Dropped (graduated to 'maint')
* 14: user-manual: Flesh out uncommitted changes and submodule updates
* 15: user-manual: Use --format=tar.gz to create a gzipped tarball
- Use `-o latest.tar.gz` instead of `--format=tar.gz`.
W. Trevor King (9):
user-manual: Use 'remote add' to setup push URLs
user-manual: Reorganize the reroll sections, adding '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: Use request-pull to generate please pull text
user-manual: Flesh out uncommitted changes and submodule updates
user-manual: Use -o latest.tar.gz to create a gzipped tarball
Documentation/user-manual.txt | 504 ++
1 file changed, 267 insertions(+), 237 deletions(-)
--
1.8.1.336.g94702dd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/9] user-manual: Use 'remote add' to setup push URLs
From: W. Trevor King wk...@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 remote add` directly. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 5077e7c..a060eb6 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1998,16 +1998,21 @@ will not be updated by the push. This may lead to unexpected results if the branch you push to is the currently checked-out branch! As with `git fetch`, you may also set up configuration options to -save typing; so, for example, after +save typing; so, for example: + +- +$ git remote add public-repo ssh://yourserver.com/~you/proj.git +- + +adds the following to `.git/config`: - -$ cat .git/config EOF [remote public-repo] - url = ssh://yourserver.com/~you/proj.git -EOF + url = yourserver.com:proj.git + fetch = +refs/heads/*:refs/remotes/example/* - -you should be able to perform the above push with just +which lets you do the same push with just - $ git push public-repo master -- 1.8.1.336.g94702dd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/9] user-manual: Mention 'git remote add' for remote branch config
From: W. Trevor King wk...@tremily.us I hardly ever setup remote.name.url using 'git config'. While it may be instructive to do so, we should also point out 'git remote add'. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 40 +--- 1 file changed, 13 insertions(+), 27 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index ba06b7e..91f1822 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2878,48 +2878,34 @@ branch.master.merge=refs/heads/master If there are other repositories that you also use frequently, you can create similar configuration options to save typing; for example, -after - -$ git config remote.example.url git://example.com/proj.git +$ git remote add example git://example.com/proj.git - -then the following two commands will do the same thing: +adds the following to `.git/config`: - -$ git fetch git://example.com/proj.git master:refs/remotes/example/master -$ git fetch example master:refs/remotes/example/master +[remote example] + url = git://example.com/proj.git + fetch = +refs/heads/*:refs/remotes/example/* - -Even better, if you add one more option: - -- -$ git config remote.example.fetch master:refs/remotes/example/master -- +Also note that the above configuration can be performed by directly +editing the file `.git/config` instead of using linkgit:git-remote[1]. -then the following commands will all do the same thing: +After configuring the remote, the following two commands will do the +same thing: - -$ git fetch git://example.com/proj.git master:refs/remotes/example/master -$ git fetch example master:refs/remotes/example/master +$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/* +$ git fetch example +refs/heads/*:refs/remotes/example/* $ git fetch example - -You can also add a + to force the update each time: - -- -$ git config remote.example.fetch +master:refs/remotes/example/master -- - -Don't do this unless you're sure you won't mind git fetch possibly -throwing away commits on 'example/master'. - -Also note that all of the above configuration can be performed by -directly editing the file .git/config instead of using -linkgit:git-config[1]. - See linkgit:git-config[1] for more details on the configuration -options mentioned above. +options mentioned above and linkgit:git-fetch[1] for more details on +the refspec syntax. [[git-concepts]] -- 1.8.1.336.g94702dd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/9] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: W. Trevor King wk...@tremily.us I think this interface is often more convenient than extended cherry picking or using 'git format-patch'. In fact, I removed the cherry-pick section entirely. The entry-level suggestions for rerolling are now: 1. git commit --amend 2. git format-patch origin git reset --hard origin ...edit and reorder patches... git am *.patch 3. git rebase -i origin Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 110 -- 1 file changed, 63 insertions(+), 47 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index a060eb6..dbffd0a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2538,6 +2538,12 @@ return mywork to the state it had before you started the rebase: $ git rebase --abort - +If you need to reorder or edit a number of commits in a branch, it may +be easier to use `git rebase -i`, which allows you to reorder and +squash commits, as well as marking them for individual editing during +the rebase. See interactive-rebase for details, and +reordering-patch-series for alternatives. + [[rewriting-one-commit]] Rewriting a single commit - @@ -2552,71 +2558,81 @@ $ git commit --amend which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first. -You can also use a combination of this and linkgit:git-rebase[1] to -replace a commit further back in your history and recreate the -intervening changes on top of it. First, tag the problematic commit -with - -- -$ git tag bad mywork~5 -- - -(Either gitk or `git log` may be useful for finding the commit.) +[[reordering-patch-series]] +Reordering or selecting from a patch series +--- -Then check out that commit, edit it, and rebase the rest of the series -on top of it (note that we could check out the commit on a temporary -branch, but instead we're using a detached-head,detached head): +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches, +then reset the state to before the patches: - -$ git checkout bad -$ # make changes here and update the index -$ git commit --amend -$ git rebase --onto HEAD bad mywork +$ git format-patch origin +$ git reset --hard origin - -When you're done, you'll be left with mywork checked out, with the top -patches on mywork reapplied on top of your modified commit. You can -then clean up with +Then modify, reorder, or eliminate patches as preferred before applying +them again with linkgit:git-am[1]: - -$ git tag -d bad +$ git am *.patch - -Note that the immutable nature of Git history means that you haven't really -modified existing commits; instead, you have replaced the old commits with -new commits having new object names. +[[interactive-rebase]] +Using interactive rebases +- -[[reordering-patch-series]] -Reordering or selecting from a patch series +You can also edit a patch series with an interactive rebase. This is +the same as reordering-patch-series,reordering a patch series using +`format-patch`, so use whichever interface you like best. -Given one existing commit, the linkgit:git-cherry-pick[1] command -allows you to apply the change introduced by that commit and create a -new commit that records it. So, for example, if mywork points to a -series of patches on top of origin, you might do something like: +Rebase your current HEAD on the last commit you want to retain as-is. +For example, if you want to reorder the last 5 commits, use: - -$ git checkout -b mywork-new origin -$ gitk origin..mywork +$ git rebase -i HEAD~5 - -and browse through the list of patches in the mywork branch using gitk, -applying them (possibly in a different order) to mywork-new using -cherry-pick, and possibly modifying them as you go using `git commit --amend`. -The linkgit:git-gui[1] command may also help as it allows you to -individually select diff hunks for inclusion in the index (by -right-clicking on the diff hunk and choosing Stage Hunk for Commit). - -Another technique is to use `git format-patch` to create a series of -patches, then reset the state to before the patches: +This will open your editor with a list of the commits you're rebasing - -$ git format-patch origin
[PATCH v3 7/9] user-manual: Use request-pull to generate please pull text
From: W. Trevor King wk...@tremily.us Less work and more error checking (e.g. does a merge base exist?). Add an explicit push before request-pull to satisfy request-pull, which checks to make sure the references are publically available. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index d9276d7..cf09ddf 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2304,16 +2304,11 @@ 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 -- - -and - -- -$ git log -p origin..release | git shortlog +$ git push mytree +$ git request-pull origin mytree release - Here are some of the scripts that simplify all this even further. -- 1.8.1.336.g94702dd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/9] user-manual: Give 'git push -f' as an alternative to +master
From: W. Trevor King wk...@tremily.us This mirrors existing language in the description of 'git fetch'. Signed-off-by: W. Trevor King wk...@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 dbffd0a..ba06b7e 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2051,6 +2051,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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 9/9] user-manual: Use -o latest.tar.gz to create a gzipped tarball
From: W. Trevor King wk...@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 wk...@tremily.us --- Documentation/user-manual.txt | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 3381c22..af6c09d 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -931,11 +931,20 @@ 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 -o latest.tar.gz --prefix=project/ HEAD - -will use HEAD to produce a tar archive in which each filename is -preceded by `project/`. +will use HEAD to produce a gzipped tar archive in which each filename +is preceded by `project/`. The output file format is inferred from +the output file extension if possible, see linkgit:git-archive[1] for +details. + +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 -- 1.8.1.336.g94702dd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/9] user-manual: Use 'git config --global user.*' for setup
From: W. Trevor King wk...@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 wk...@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 a79b3e31..d9276d7 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 'y...@yourdomain.example.com' + + +Which will adds the following to a file named `.gitconfig` in your +home directory: [user] @@ -1001,8 +1008,9 @@ file named `.gitconfig` in your home directory: email = y...@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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/9] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King wk...@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 wk...@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 cf09ddf..3381c22 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3729,7 +3729,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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] contrib/subtree/t: Added tests for .gitsubtree support
Paul Campbell wrote: Here's the updated version of the tests: Just a few more nits: --- a/contrib/subtree/t/t7900-subtree.sh +++ b/contrib/subtree/t/t7900-subtree.sh @@ -465,4 +465,37 @@ test_expect_success 'verify one file change per commit' ' [...] +test_expect_success 'change in subtree is pushed okay' ' + (cd copy0 create new_file git commit -mAdded new_file) Style: this would be easier to read with each command on a separate line, like so: ( cd copy0 create new_file test_tick git commit -m Add new_file ) [...] +test_expect_success 'pull into subtree okay' ' + git subtree add --prefix=copy1 sub1 + git subtree add --prefix=copy2 sub1 + (cd copy1 create new_file_in_copy1 git commit -mAdded new_file_in_copy1) Likewise (and as a nice side-benefit, it would avoid a long line that mailers like to wrap). + git subtree push --prefix=copy1 + git subtree pull --prefix=copy2 | grep ^ create mode 100644 copy2/new_file_in_copy1$ Likewise. More importantly, this forgets the exit status from git subtree pull, so if it were to segfault after writing appropriate output, the test wouldn't notice. How about: git subtree pull --prefix=copy2 output grep ^ create mode 100644 copy2/new_file_in_copy1\$ output Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.8.2-rc0
An early preview Git v1.8.2-rc0 for the upcoming release is now available for testing at the usual places. The preview includes contributions from 80+ people, totaling some 570+ no-merge changes since v1.8.1 and should give you more or less a complete picture of what the upcoming 1.8.2 would look like. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: 3d19b5bc224a7a3427b21c4587c4ab342435e8b6 git-1.8.2.rc0.tar.gz 77dcebd8856cb6c8600dcf2a56ca3554aef9866f git-htmldocs-1.8.2.rc0.tar.gz 26a75c32c75ed05939c13684581698f2daa0feae git-manpages-1.8.2.rc0.tar.gz Also the following public repositories all have a copy of the v1.8.2-rc0 tag and the master branch that the tag points at: url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.8.2 Release Notes (draft) Backward compatibility notes In the upcoming major release (tentatively called 1.8.2), we will change the behavior of the git push command. When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). We will use the simple semantics that pushes the current branch to the branch with the same name, only when the current branch is set to integrate with that remote branch. There is a user preference configuration variable push.default to change this. git push $there tag v1.2.3 used to allow replacing a tag v1.2.3 that already exists in the repository $there, if the rewritten tag you are pushing points at a commit that is a decendant of a commit that the old tag v1.2.3 points at. This was found to be error prone and starting with this release, any attempt to update an existing ref under refs/tags/ hierarchy will fail, without --force. Updates since v1.8.1 UI, Workflows Features * Initial ports to QNX and z/OS UNIX System Services have started. * Output from the tests is coloured using green is okay, yellow is questionable, red is bad and blue is informative scheme. * Mention of GIT/Git/git in the documentation have been updated to be more uniform and consistent. The name of the system and the concept it embodies is Git; the command the users type is git. All-caps GIT was merely a way to imitate Git typeset in small caps in our ASCII text only documentation and to be avoided. * The completion script (in contrib/completion) used to let the default completer to suggest pathnames, which gave too many irrelevant choices (e.g. git add would not want to add an unmodified path). It learnt to use a more git-aware logic to enumerate only relevant ones. * In bare repositories, git shortlog and other commands now read mailmap files from the tip of the history, to help running these tools in server settings. * Color specifiers, e.g. %C(blue)Hello%C(reset), used in the --format= option of git log and friends can be disabled when the output is not sent to a terminal by prefixing them with auto,, e.g. %C(auto,blue)Hello%C(auto,reset). * Scripts can ask Git that wildcard patterns in pathspecs they give do not have any significance, i.e. take them as literal strings. * The patterns in .gitignore and .gitattributes files can have **/, as a pattern that matches 0 or more levels of subdirectory. E.g. foo/**/bar matches bar in foo itself or in a subdirectory of foo. * When giving arguments without -- disambiguation, object names that come earlier on the command line must not be interpretable as pathspecs and pathspecs that come later on the command line must not be interpretable as object names. This disambiguation rule has been tweaked so that :/ (no other string before or after) is always interpreted as a pathspec; git cmd -- :/ is no longer needed, you can just say git cmd :/. * Various hint lines Git gives when it asks the user to edit messages in the editor are commented out with '#' by default. The core.commentchar configuration variable can be used to customize this '#' to a different character. * git add -u and git add -A without pathspec issues warning to make users aware that they are only operating on paths inside the subdirectory they are in. Use :/ (everything from the top) or . (everything from the $cwd) to disambiguate. * git blame (and git diff) learned the --no-follow option. * git branch now rejects some nonsense combinations of command line arguments (e.g. giving more than one branch name to rename) with more case-specific error messages. * git check-ignore command to help debugging .gitignore files has been added. * git
What's cooking in git.git (Feb 2013, #07; Sun, 17)
What's cooking in git.git (Feb 2013, #07; Sun, 17) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of the 'master' is at 1.8.2-rc0; new topics that are not listed in this report are likely to be too late for the upcoming release. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * da/difftool-fixes (2013-02-17) 5 commits - [DONTMERGE] expect reroll $gmane/216376 - t7800: defaults is no longer a builtin tool name - t7800: modernize tests - t7800: Update copyright notice - difftool: silence uninitialized variable warning Minor maintenance updates to difftool, and updates to its tests. Expecting a reroll. $gmane/216376 * jk/smart-http-robustify (2013-02-17) 3 commits - remote-curl: sanity check ref advertisement from server - remote-curl: verify smart-http metadata lines - pkt-line: teach packet_get_line a no-op mode Parse the HTTP exchange that implements the native Git protocol as a series of stateless RPC more carefully to diagnose protocol breakage better. Will merge to and hold in 'next'. * nd/read-directory-recursive-optim (2013-02-17) 1 commit - read_directory: avoid invoking exclude machinery on tracked files git status has been optimized by taking advantage of the fact that paths that are already known to the index do not have to be checked against the .gitignore mechanism under some conditions. Will merge to and hold in 'next'. -- [Graduated to master] * da/p4merge-mktemp-fix (2013-02-10) 1 commit (merged to 'next' on 2013-02-14 at c5fc5ba) + p4merge: fix printf usage * ef/non-ascii-parse-options-error-diag (2013-02-11) 1 commit (merged to 'next' on 2013-02-14 at 10cbdf8) + parse-options: report uncorrupted multi-byte options * jc/hidden-refs (2013-02-07) 3 commits (merged to 'next' on 2013-02-14 at b69f9cc) + upload/receive-pack: allow hiding ref hierarchies + upload-pack: simplify request validation + upload-pack: share more code (this branch is used by jc/fetch-raw-sha1.) Allow the server side to redact the refs/ namespace it shows to the client. * jk/read-commit-buffer-data-after-free (2013-02-11) 1 commit (merged to 'next' on 2013-02-14 at 220e3a8) + log: re-encode commit messages before grepping git log --grep=pattern has been taught to honor the logoutput encoding when matching the log message against the given pattern. * jk/rebase-i-comment-char (2013-02-12) 1 commit (merged to 'next' on 2013-02-14 at 0ed2f48) + rebase -i: respect core.commentchar Finishing touches to core.commentchar topic to teach it to rebase -i as well. * mk/make-rm-depdirs-could-be-empty (2013-02-13) 1 commit (merged to 'next' on 2013-02-14 at d966248) + Makefile: don't run rm without any files make COMPUTE_HEADER_DEPENDENCIES=no clean would try to run rm -rf $(dep_dirs) with an empty dep_dir, but some implementations of rm -rf barf on an empty argument list. * mk/old-expat (2013-02-11) 1 commit (merged to 'next' on 2013-02-14 at 5fb47ce) + Allow building with xmlparse.h Old expat needs to include xmlparse.h instead of expat.h header file. * mm/config-local-completion (2013-02-12) 1 commit (merged to 'next' on 2013-02-14 at 26bf6c2) + completion: support 'git config --local' * mp/diff-algo-config (2013-01-16) 3 commits (merged to 'next' on 2013-02-14 at cd765dc) + diff: Introduce --diff-algorithm command line option + config: Introduce diff.algorithm variable + git-completion.bash: Autocomplete --minimal and --histogram for git-diff Add diff.algorithm configuration so that the user does not type diff --histogram. * mw/bash-prompt-show-untracked-config (2013-02-13) 3 commits (merged to 'next' on 2013-02-14 at 809dbcf) + t9903: add extra tests for bash.showDirtyState + t9903: add tests for bash.showUntrackedFiles + shell prompt: add bash.showUntrackedFiles option Allows skipping the untracked check GIT_PS1_SHOWUNTRACKEDFILES asks for the git-prompt (in contrib/) per repository. * wk/man-deny-current-branch-is-default-these-days (2013-02-14) 1 commit (merged to 'next' on 2013-02-14 at 6fab9d4) + user-manual: Update for receive.denyCurrentBranch=refuse -- [Stalled] * mb/gitweb-highlight-link-target (2012-12-20) 1 commit - Highlight the link target line in Gitweb using CSS Expecting a reroll. $gmane/211935 * jc/add-delete-default (2012-08-13) 1 commit - git add: notice removal of tracked paths by default git add dir/ updated modified files and added new files, but does not notice removed files, which may be Huh? to some users. They can of course use git add -A
Re: [PATCH 2/3] remote-curl: verify smart-http metadata lines
Jeff King wrote: On Sun, Feb 17, 2013 at 02:49:39AM -0800, Jonathan Nieder wrote: Jeff King wrote: --- a/remote-curl.c [...] + if (read_packets_until_flush(last-buf, last-len) 0) Style nit: this made me wonder What would it mean if read_packets_until_flush() 0? [...] My intent was that it followed the error convention of negative is error, 0 is success, and positive is not used, but reserved for future use. From a maintainability perspective, that kind of contract would be dangerous, since some *other* caller could arrive and use the function without a 0 without knowing it is doing anything wrong. When new return values appear, the function should be renamed to help the patch author and reviewers remember to check all callers. That is, from the point of view of maintainability, there is no distinction between if (read_packets_until_... 0) and if (read_packets_until_...) and either form is fine. My comment was just to say the 0 forced me to pause a moment and check out the implementation. This is basically a stylistic thing and if you prefer to keep the 0, that's fine with me. If an implementation is producing bogus packet lines and expecting us not to complain, it really needs to be fixed. Agreed completely. Thanks again for the patch. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] remote-curl: sanity check ref advertisement from server
Jeff King wrote:
On Sun, Feb 17, 2013 at 03:05:34AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
+ if (verify_ref_advertisement(last-buf, last-len) 0)
+ die(ref advertisement is invalid at %s, refs_url);
Won't this error out with
protocol error: bad line length character: ERR
instead of the current more helpful behavior for ERR lines?
I don't think so. Don't ERR lines appear inside their own packets?
Yes, I misread get_remote_heads for some reason. Thanks for checking.
[...]
The one thing we do also check, though, is that we end with a flush
packet. So depending on what servers produce, it may mean we trigger
this complaint instead of passing the ERR along to fetch-pack.
Rather than doing this fake syntactic verification, I wonder if we
should simply call get_remote_heads, which does a more thorough check
I'm not sure whether servers are expected to send a flush after an
ERR packet. The only codepath I know of in git itself that sends
such packets is git-daemon, which does not flush after the error (but
is not used in the stateless-rpc case). http-backend uses HTTP error
codes for its errors.
If I am reading get_remote_heads correctly, calling it with the
following tweak should work ok. The extra thread is just to feed a
string into a fd-based interface and could be avoided for list, too,
if it costs too much.
diff --git i/connect.c w/connect.c
index 49e56ba3..55ee7de7 100644
--- i/connect.c
+++ w/connect.c
@@ -68,7 +68,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
{
int got_at_least_one_head = 0;
- *list = NULL;
+ if (list)
+ *list = NULL;
for (;;) {
struct ref *ref;
unsigned char old_sha1[20];
@@ -92,6 +93,9 @@ struct ref **get_remote_heads(int in, struct ref **list,
die(protocol error: expected sha/ref, got '%s',
buffer);
name = buffer + 41;
+ if (!list)
+ continue;
+
name_len = strlen(name);
if (len != name_len + 41) {
free(server_capabilities);
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/9] user-manual: Use 'remote add' to setup push URLs
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@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 remote add` directly. Signed-off-by: W. Trevor King wk...@tremily.us --- This looks like a good 'maint' material that can be applied straight away there in preparation for 1.8.1.4 to me; reviewers watching from the sideline, please stop me if you see issues. Documentation/user-manual.txt | 15 ++- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 5077e7c..a060eb6 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -1998,16 +1998,21 @@ will not be updated by the push. This may lead to unexpected results if the branch you push to is the currently checked-out branch! As with `git fetch`, you may also set up configuration options to -save typing; so, for example, after +save typing; so, for example: + +- +$ git remote add public-repo ssh://yourserver.com/~you/proj.git +- + +adds the following to `.git/config`: - -$ cat .git/config EOF [remote public-repo] - url = ssh://yourserver.com/~you/proj.git -EOF + url = yourserver.com:proj.git + fetch = +refs/heads/*:refs/remotes/example/* - -you should be able to perform the above push with just +which lets you do the same push with just As the additional remote.public-repo.fetch line hints, this does more than lets you do the same push with just [lazily]; it also starts pretending to have run a fetch from there immediately after you pushed and update the remote tracking branches. I couldn't decide if it is a good idea to point it out in this point of the flow as well, or it is too much detail that is not exactly relevant while teaching git push. I tend to think it would be the latter. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/9] user-manual: Use 'remote add' to setup push URLs
Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: There is no need to use here documents to setup this configuration. It is easier, less confusing, and more robust to use `git remote add` directly. [...] This looks like a good 'maint' material that can be applied straight away there in preparation for 1.8.1.4 to me; reviewers watching from the sideline, please stop me if you see issues. Agreed --- this looks good. [...] As the additional remote.public-repo.fetch line hints, this does more than lets you do the same push with just [lazily]; it also starts pretending to have run a fetch from there immediately after you pushed and update the remote tracking branches. I couldn't decide if it is a good idea to point it out in this point of the flow as well, or it is too much detail that is not exactly relevant while teaching git push. I tend to think it would be the latter. I think it's possible to improve the text here to hint that there's more to learn (maybe a forward-reference to a section about the remotes/* hierarchy) without getting lost in the details. But that problem was already there, and I don't think it should block this improvement. Thanks. Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@tremily.us I think this interface is often more convenient than extended cherry picking or using 'git format-patch'. In fact, I removed the cherry-pick section entirely. The entry-level suggestions for rerolling are now: 1. git commit --amend 2. git format-patch origin git reset --hard origin ...edit and reorder patches... git am *.patch 3. git rebase -i origin Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 110 -- 1 file changed, 63 insertions(+), 47 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index a060eb6..dbffd0a 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2538,6 +2538,12 @@ return mywork to the state it had before you started the rebase: $ git rebase --abort - +If you need to reorder or edit a number of commits in a branch, it may +be easier to use `git rebase -i`, which allows you to reorder and +squash commits, as well as marking them for individual editing during +the rebase. See interactive-rebase for details, and +reordering-patch-series for alternatives. + [[rewriting-one-commit]] Rewriting a single commit - @@ -2552,71 +2558,81 @@ $ git commit --amend which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first. ... A lot of lines removed here ... +[[reordering-patch-series]] This change makes the [[rewriting-one-commit]] section say We already saw you can do 'commit --amend' and nothing else. It makes me wonder if the remaining section is worth keeping if we go this route. +[[reordering-patch-series]] +Reordering or selecting from a patch series +--- +Sometimes you want to edit a commit deeper in your history. One +approach is to use `git format-patch` to create a series of patches, +then reset the state to before the patches: - +$ git format-patch origin +$ git reset --hard origin - +Then modify, reorder, or eliminate patches as preferred before applying +them again with linkgit:git-am[1]: - +$ git am *.patch - It may be just me, but s/preferred/needed/, perhaps? +This will open your editor with a list of the commits you're rebasing - +pick deadbee The oneline of this commit +pick fa1afe1 The oneline of the next commit +... +# Rebase c0ffeee..deadbee onto c0ffeee +# +# Commands: ... +# Note that empty commits are commented out +- + +As explained in the comments, you can reorder commits, squash them +together, edit commit messages, etc. by editing the list. Once you +are satisfied, save the list and close your editor, and the rebase +will begin. + +The rebase will stop when `pick` has been replaced with `edit` or when +a command fails due to merge errors. When you are done editing and/or +resolving conflicts... I am afraid that due to merge errors and resolving conflicts do not look corresponding to each other for a new reader. Also here we say when a command fails, but the explanation before this part never says list of commands. Besides, command itself is not a very good word to use as pick is not really a command (we do not have git pick or git squash---that is why I almost always call this insn sheet myself, by the way). A way to reword the above to reduce possible confusion may be to start with: This will open your editor with a list of steps to be taken to perform your rebase. and then say ... with `edit` or when a step in the list fails to mechanically resolve conflicts and needs your help. When you are done editing ... or something. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/9] user-manual: Give 'git push -f' as an alternative to +master
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@tremily.us This mirrors existing language in the description of 'git fetch'. Signed-off-by: W. Trevor King wk...@tremily.us --- This looks like a good 'maint' material that can be applied straight away there in preparation for 1.8.1.4 to me; reviewers watching from the sideline, please stop me if you see issues. Documentation/user-manual.txt | 7 +++ 1 file changed, 7 insertions(+) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index dbffd0a..ba06b7e 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2051,6 +2051,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. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/9] user-manual: Mention 'git remote add' for remote branch config
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@tremily.us I hardly ever setup remote.name.url using 'git config'. While it may be instructive to do so, we should also point out 'git remote add'. Signed-off-by: W. Trevor King wk...@tremily.us --- This looks like a good 'maint' material that can be applied straight away there in preparation for 1.8.1.4 to me (modulo one nit); reviewers watching from the sideline, please stop me if you see issues. +After configuring the remote, the following two commands will do the +same thing: - +$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/* +$ git fetch example +refs/heads/*:refs/remotes/example/* $ git fetch example - These _three_ commands will do the same. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git] Re: [PATCH v3 4/9] user-manual: Mention 'git remote add' for remote branch config
On Sun, Feb 17, 2013 at 06:26:25PM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: - +$ git fetch git://example.com/proj.git +refs/heads/*:refs/remotes/example/* +$ git fetch example +refs/heads/*:refs/remotes/example/* $ git fetch example - These _three_ commands will do the same. Oops. Feel free to fix this for me, and consider the revised version signed off by me ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 6/9] user-manual: Use 'git config --global user.*' for setup
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@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 wk...@tremily.us --- Documentation/user-manual.txt | 18 +- 1 file changed, 13 insertions(+), 5 deletions(-) This looks like a good 'maint' material that can be applied straight away there in preparation for 1.8.1.4 to me (modulo typo); reviewers watching from the sideline, please stop me if you see issues. diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index a79b3e31..d9276d7 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 'y...@yourdomain.example.com' + + +Which will adds the following to a file named `.gitconfig` in your s/adds/add/; +home directory: [user] @@ -1001,8 +1008,9 @@ file named `.gitconfig` in your home directory: email = y...@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]] -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 7/9] user-manual: Use request-pull to generate please pull text
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@tremily.us Less work and more error checking (e.g. does a merge base exist?). Add an explicit push before request-pull to satisfy request-pull, which checks to make sure the references are publically available. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/user-manual.txt | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index d9276d7..cf09ddf 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2304,16 +2304,11 @@ 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]: The command you refer to does the _whole_ thing, not just to create diffstat and shortlog summaries to be included. - +$ git push mytree +$ git request-pull origin mytree release - The introductory text to tell the reader what they are being taught needs to be updated a bit more, I think. After pushing your work to mytree, you can use request-pull command to prepare a please pull request message to send to Linus, like so: or something. Here are some of the scripts that simplify all this even further. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 8/9] user-manual: Flesh out uncommitted changes and submodule updates
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@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 wk...@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 cf09ddf..3381c22 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -3729,7 +3729,9 @@ module a NOTE: The changes are still visible in the submodule's reflog. +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. The scenario this talks about is to commit changes in the superproject and then to run submodule update. I think the above clarification is still incomplete. You may have committed in the submodule some changes but not all. If you have uncommitted changes in your submodule working tree, git submodule update will not overwrite them. Instead... would be an improvement, I think. [[low-level-operations]] Low-level Git operations -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 9/9] user-manual: Use -o latest.tar.gz to create a gzipped tarball
W. Trevor King wk...@tremily.us writes: From: W. Trevor King wk...@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 wk...@tremily.us --- This looks like a good 'maint' material that can be applied straight away there if the patch did not depend on 5/9 to cause needless conflicts. It is easy for me to deal with conflicts in this particular case, but in general it would have been more straightforward to manage if these more localized phrasing fixes came earlier and a larger file-wide cosmetic change was done after all the others have settled. diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 3381c22..af6c09d 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -931,11 +931,20 @@ 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 -o latest.tar.gz --prefix=project/ HEAD - -will use HEAD to produce a tar archive in which each filename is -preceded by `project/`. +will use HEAD to produce a gzipped tar archive in which each filename +is preceded by `project/`. The output file format is inferred from +the output file extension if possible, see linkgit:git-archive[1] for +details. + +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 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/9] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
On Sun, Feb 17, 2013 at 06:23:11PM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: [[rewriting-one-commit]] Rewriting a single commit - @@ -2552,71 +2558,81 @@ $ git commit --amend which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first. ... A lot of lines removed here ... +[[reordering-patch-series]] This change makes the [[rewriting-one-commit]] section say We already saw you can do 'commit --amend' and nothing else. It makes me wonder if the remaining section is worth keeping if we go this route. I think there should be some mention of `commit --amend` in the rewriting history section. It's a pretty straightforward idea though, so there's not all that much to say about it ;). +Then modify, reorder, or eliminate patches as preferred before applying +them again with linkgit:git-am[1]: - +$ git am *.patch - It may be just me, but s/preferred/needed/, perhaps? Sure. I was just shifting the existing text. Will fix in v4. +The rebase will stop when `pick` has been replaced with `edit` or when +a command fails due to merge errors. When you are done editing and/or +resolving conflicts... I am afraid that due to merge errors and resolving conflicts do not look corresponding to each other for a new reader. Also here we say when a command fails, but the explanation before this part never says list of commands. Oops. s/command/commit/. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 2/9] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
W. Trevor King wk...@tremily.us writes: On Sun, Feb 17, 2013 at 06:23:11PM -0800, Junio C Hamano wrote: W. Trevor King wk...@tremily.us writes: [[rewriting-one-commit]] Rewriting a single commit - @@ -2552,71 +2558,81 @@ $ git commit --amend which will replace the old commit by a new commit incorporating your changes, giving you a chance to edit the old commit message first. ... A lot of lines removed here ... +[[reordering-patch-series]] This change makes the [[rewriting-one-commit]] section say We already saw you can do 'commit --amend' and nothing else. It makes me wonder if the remaining section is worth keeping if we go this route. I think there should be some mention of `commit --amend` in the rewriting history section. It's a pretty straightforward idea though, so there's not all that much to say about it ;). I do think teaching commit --amend, rebase and rebase -i together makes sense. It just felt that the remaining piece on commit --amend looked too thin in the substance, but it may be a good change in the existing flow of text. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Please pull l10n updates for 1.8.2 round 2
Hi, Junio Please pull l10n updates for git 1.8.2 round 2. BTW, I find there are new updates in master branch and next branch: $ po-helper.sh check update New l10n updates found in master branch of remote kernel: 5 new messages. New l10n updates found in next branch of remote kernel: 6 new, 2 removed messages. So there will be another 1 or 2 rounds of translations. The following changes since commit 5bf72ed2e7ef82d5ef7a35c978dc72576fdb0efc: Merge branch 'maint' (2013-02-12 12:23:12 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to a77c07d9747fdba7aef22374a91d4b6aaf2f7b2f: l10n: zh_CN.po: translate 35 new messages (2013-02-18 09:52:33 +0800) Jiang Xin (2): l10n: Update git.pot (35 new, 14 removed messages) l10n: zh_CN.po: translate 35 new messages Tran Ngoc Quan (1): l10n: vi.po: update new strings (2004t0u0f) po/git.pot | 1323 +- po/vi.po| 1442 --- po/zh_CN.po | 1392 ++-- 3 files changed, 2284 insertions(+), 1873 deletions(-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone tag shallow
On Mon, Feb 18, 2013 at 2:13 AM, Thibault Kruse tibokr...@googlemail.com wrote: Hi all, I notice that using git 1.8.3, I can call git clone repo1 repo2 --branch tagname with a tag, not a branch. Is this going to be a stable and documented feature? There is a test for --branch=tag in t5601, so I say it's supported. If the document is not clear, patches are welcome. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
