Re: BUG or FEATURE? Use of '/' in branch names
On vr, 2014-05-02 at 15:16 -0700, Jonathan Nieder wrote: $ git checkout -b hotfix/b2 error: unable to resolve reference refs/heads/hotfix/b2: Not a directory fatal: Failed to lock ref for update: Not a directory $ That's an ugly message. I think we can do better. (hint hint) 2.0.0-rc2 has a better message already: $ git checkout -b hotfix/b2 error: 'refs/heads/hotfix' exists; cannot create 'refs/heads/hotfix/b2' fatal: Failed to lock ref for update: Not a directory -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Should git-remote-hg/bzr be part of the core?
the best in your future endeavors. Michael [1] http://article.gmane.org/gmane.comp.version-control.git/227750 -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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: Error fatal: not a git repository after auto packing
On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote: raven:/home/luke/vispy (transform-cache)$ git checkout master Switched to branch 'master' Deleted 103 .pyc files Deleted 11 empty directories This looks like you have a local post-checkout hook that deletes empty directories. Fix that hook to not do anything in .git and it should be fine. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Wishlist: git fetch --reference
On do, 2014-08-21 at 19:57 -0700, Howard Chu wrote: I maintain multiple copies of the same repo because I keep each one checked out to different branch/rev levels. It would be nice if, similar to clone --reference, we could also use git fetch --reference to reference a local repo when doing a fetch to pull in updates. Alternatively, you can use Duy's multiple-work-trees patches to safely make multiple checkouts of one repository. These patches are in next. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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 fetch (http) hanging/failing on one specific repository, http only
and suddenly this one is misbehaving. However I have no idea where to look next and would really appreciate some help. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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
Bug in fetch-pack causing ever-growing http requests. (Was: git fetch (http) hanging/failing on one specific repository, http only)
On ma, 2014-10-20 at 16:29 +0200, Dennis Kaarsemaker wrote: Since a few days, one of our repos is causing problems during git fetch, basically git fetch over http hangs during find_common. When using ssh, this does not happen. snip things that may not be relevant. And for the hanging git-upload-pack: #0 0x7f7c8034b4d0 in __write_nocancel () from /lib64/libpthread.so.0 #1 0x0043c9dc in xwrite (fd=1, buf=0x6c70e0, len=56) at wrapper.c:170 #2 0x0043ca5b in write_in_full (fd=1, buf=value optimized out, count=56) at wrapper.c:220 #3 0x0043d019 in write_or_die (fd=value optimized out, buf=value optimized out, count=value optimized out) at write_or_die.c:61 #4 0x004131fa in packet_write (fd=1, fmt=value optimized out) at pkt-line.c:93 #5 0x0040538c in get_common_commits (argc=value optimized out, argv=0x7fff0001) at upload-pack.c:420 #6 upload_pack (argc=value optimized out, argv=0x7fff0001) at upload-pack.c:778 #7 main (argc=value optimized out, argv=0x7fff0001) at upload-pack.c:846 And the hanging git-http-backend: #0 0x7f4c9553d4d0 in __write_nocancel () from /lib64/libpthread.so.0 #1 0x0042d31c in xwrite (fd=4, buf=0x7fff394ea570, len=8192) at wrapper.c:170 #2 0x0042d39b in write_in_full (fd=4, buf=value optimized out, count=8192) at wrapper.c:220 #3 0x00403e5d in inflate_request (prog_name=0x490d98 upload-pack, out=4) at http-backend.c:305 #4 0x0040405d in run_service (argv=0x7fff394ee6d0) at http-backend.c:355 #5 0x004041d2 in service_rpc (service_name=value optimized out) at http-backend.c:508 #6 0x00404b35 in main (argc=value optimized out, argv=value optimized out) at http-backend.c:631 Both git-http-backend and git-upload-pack are trying to write at the same time. I'm *guessing* I've hit some buffer limit here, given that the have/ack exchanges are increasing in size and suddenly this one is misbehaving. However I have no idea where to look next and would really appreciate some help. I think the reasoning in 44d8dc54e73e8010c4bdf57a422fc8d5ce709029 is incomplete: there's still a pipe involved in the case of gzip'ed request bodies, and it's here that it hangs. However, I now do think that this is merely a symptom, because after inspecting the output a bit further I noticed that all reponses start with the same lines: got ack 3 a669f13aab3a2c192c15574ead70f92b303e8aee got ack 3 360530ff695a4deb01575e85976060a083e17245 got ack 3 bab20d62a5a4c34885cf2acbf83aca91908f9af8 In fact, response N, is the same as response N-1 plus acks for the commits in the 'have' lines of the debug output for the next request. So it looks like every request sends all common commits again, which seems wrong but does explain the ever-growing request size. After commenting out line 413 in fetch-pack.c (state_len = req_buf.len) the requests and responses don't increase in size, and fetch completes, though the received pack seems too large (http response is 400MB), which makes me think it's not actually ack'ing. Subsequent HTTP fetches don't get a big pack in response though, so maybe the pack is the right size. THis is a *very* busy repo with thousands of commits between the last succesful fetch 5 days ago and the first succesfil fetch after my hack. In any case, I think there's a bug here, but I don't know nearly enough about the protocol to judge if my fix is even close to correct. I've also not tested my fix with any other protocol yet. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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] fetch-pack: don't resend known-common refs in find_common
By not clearing the request buffer in stateless-rpc mode, fetch-pack would keep sending already known-common commits, leading to ever bigger http requests, eventually getting too large for git-http-backend to handle properly without filling up the pipe buffer in inflate_request. --- I'm still not quite sure whether this is the right thing to do, but make test still passes :) The new testcase demonstrates the problem, when running t5551 with EXPENSIVE, this test will hang without the patch to fetch-pack.c and succeed otherwise. fetch-pack.c| 1 - t/t5551-http-fetch-smart.sh | 32 2 files changed, 32 insertions(+), 1 deletion(-) diff --git a/fetch-pack.c b/fetch-pack.c index 655ee64..258245c 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -410,7 +410,6 @@ static int find_common(struct fetch_pack_args *args, */ const char *hex = sha1_to_hex(result_sha1); packet_buf_write(req_buf, have %s\n, hex); - state_len = req_buf.len; } mark_common(commit, 0, 1); retval = 0; diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index 6cbc12d..2aac237 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -245,5 +245,37 @@ test_expect_success EXPENSIVE 'clone the 50,000 tag repo to check OS command lin ) ' +test_expect_success EXPENSIVE 'create 50,000 more tags' ' + ( + cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git + for i in `test_seq 50001 10` + do + echo commit refs/heads/too-many-refs-again + echo mark :$i + echo committer git g...@example.com $i + + echo data 0 + echo M 644 inline bla.txt + echo data 4 + echo bla + # make every commit dangling by always + # rewinding the branch after each commit + echo reset refs/heads/too-many-refs-again + echo from :50001 + done | git fast-import --export-marks=marks + + # now assign tags to all the dangling commits we created above + tag=$(perl -e print \bla\ x 30) + sed -e s|^:\([^ ]*\) \(.*\)$|\2 refs/tags/$tag-\1| marks packed-refs + ) +' + +test_expect_success EXPENSIVE 'fetch the new tags' ' + ( + cd too-many-refs + git fetch --tags + test $(git for-each-ref refs/tags | wc -l) = 10 + ) +' + stop_httpd test_done -- 2.1.0-245-g26e60d4 -- 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] fetch-pack: don't resend known-common refs in find_common
On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: By not clearing the request buffer in stateless-rpc mode, fetch-pack would keep sending already known-common commits, leading to ever bigger http requests, eventually getting too large for git-http-backend to handle properly without filling up the pipe buffer in inflate_request. --- I'm still not quite sure whether this is the right thing to do, but make test still passes :) The new testcase demonstrates the problem, when running t5551 with EXPENSIVE, this test will hang without the patch to fetch-pack.c and succeed otherwise. IIUC, because stateless is just that, i.e. the server-end does not keep track of what is already known, not telling what is known to be common in each request would fundamentally break the protocol. Am I mistaken? That sounds plausible, but why then does the fetch complete with this line removed, and why does 'make test' still pass? I tried to understand the protocol, but the documentation has TODO's in some critical places :) And if that's true, it means the inflate_request / upload-pack interaction should be fixed, so more than 64k (current linux pipe buffer size) of uncompressed data is supported. I see two options: * Turning that interaction into a more cooperative process, with a select/poll loop * Make upload-pack buffer its entire response when run in stateless_rpc mode until it has consumed all of the request The latter sounds easier to do, but not being very familiar with the protocol, I may have missed something obvious. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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] fetch-pack: don't resend known-common refs in find_common
On Wed, Oct 22, 2014 at 10:11:40AM -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: On di, 2014-10-21 at 10:56 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: By not clearing the request buffer in stateless-rpc mode, fetch-pack would keep sending already known-common commits, leading to ever bigger http requests, eventually getting too large for git-http-backend to handle properly without filling up the pipe buffer in inflate_request. --- I'm still not quite sure whether this is the right thing to do, but make test still passes :) The new testcase demonstrates the problem, when running t5551 with EXPENSIVE, this test will hang without the patch to fetch-pack.c and succeed otherwise. IIUC, because stateless is just that, i.e. the server-end does not keep track of what is already known, not telling what is known to be common in each request would fundamentally break the protocol. Am I mistaken? That sounds plausible, but why then does the fetch complete with this line removed, and why does 'make test' still pass? The fetch-pack program tries to help the upload-pack program(s) running on the other end find what nodes in the graph both repositories have in common by sending what the repository on its end has. Some commits may not be known by the other side (e.g. your new commits that haven't been pushed there that are made on a branch forked from the common history), and some others may be known (i.e. you drilled down the history from the tips of your refs and reached a commit that you fetched from the common history previously). The latter are ACKed by the upload-pack process and are remembered to be re-sent to the _next_ incarnation of the upload-pack process when stateless RPC is in use. With your patch, you stop telling the upload-pack process what these two programs already found to be common in their exchange. After the first exchange, fetch-pack and upload-pack may have noticed that both ends have version 2.0, but because you do not convey that fact to the other side, the new incarnation of upload-pack may end up deciding that the version 1.9 is the newest common commit between the two, and sending commits between 1.9 and 2.0. If you imagine an extreme case, it would be easy to see why the fetch completes and make test passes are not sufficient to say anything about this change. Even if you break the protocol in in a way different from your patch, by not sending any have, such a butchered fetch-pack will become fetch everything from scratch, aka clone. The end result will still have correct history and fetch completes would be true. But I'd prefer deferring a more detailed analysis/explanation to Shawn, as stateless RPC is his creation. Thanks for the explanation, that makes it quite clear that this approach is wrong. The patch below (apologies for the formatting, I'm not quite sure how to use format-patch in this situation) does it differently: by buffering upload-pack's output until it has read all the input, the new test still succeeds and again 'make test' passes. --- t/t5551-http-fetch-smart.sh | 32 upload-pack.c | 29 +++-- 2 files changed, 51 insertions(+), 10 deletions(-) diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh index 6cbc12d..2aac237 100755 --- a/t/t5551-http-fetch-smart.sh +++ b/t/t5551-http-fetch-smart.sh @@ -245,5 +245,37 @@ test_expect_success EXPENSIVE 'clone the 50,000 tag repo to check OS command lin ) ' +test_expect_success EXPENSIVE 'create 50,000 more tags' ' + ( + cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git + for i in `test_seq 50001 10` + do + echo commit refs/heads/too-many-refs-again + echo mark :$i + echo committer git g...@example.com $i + + echo data 0 + echo M 644 inline bla.txt + echo data 4 + echo bla + # make every commit dangling by always + # rewinding the branch after each commit + echo reset refs/heads/too-many-refs-again + echo from :50001 + done | git fast-import --export-marks=marks + + # now assign tags to all the dangling commits we created above + tag=$(perl -e print \bla\ x 30) + sed -e s|^:\([^ ]*\) \(.*\)$|\2 refs/tags/$tag-\1| marks packed-refs + ) +' + +test_expect_success EXPENSIVE 'fetch the new tags' ' + ( + cd too-many-refs + git fetch --tags + test $(git for-each-ref refs/tags | wc -l) = 10 + ) +' + stop_httpd test_done diff --git a/upload-pack.c b/upload-pack.c index ac9ac15..3d76750 100644 --- a/upload-pack.c +++ b/upload-pack.c @@ -373,6 +373,7 @@ static int get_common_commits(void) int got_common = 0
Re: [PATCH] fetch-pack: don't resend known-common refs in find_common
On Wed, Oct 22, 2014 at 05:07:31PM +0700, Duy Nguyen wrote: On Wed, Oct 22, 2014 at 2:41 PM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: I see two options: * Turning that interaction into a more cooperative process, with a select/poll loop * Make upload-pack buffer its entire response when run in stateless_rpc mode until it has consumed all of the request Or add a helper daemon and support stateful smart http. Or maybe that's what you meant in the first option. No, I meant that get-http-backend should have a select/poll loop that can read from and write to git-upload-pack at the same time, but option two was easier to implement :) Stateful smart http seems to be against the design goals of smart http if I interpret Documentation/technical/http-protocol.txt correctly though, so that doesn't seem to be the right approach. -- Dennis Kaarsemaker den...@kaarsemaker.net http://twitter.com/seveas -- 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: Editing git changelog automatically
On zo, 2014-10-26 at 22:27 -0700, Cong Wang wrote: My question is how to edit dozens of git commit changelogs automatically? You can use git filter-branch in --msg-filter mode. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] tests: allow sha1's as part of the path
When running 'make test' from a path such as
.../daily-build/master@bdff0e3a374617dce784f801b97500d9ba2e4705, the
logic in fuzz.sed as generated by t5105-request-pull.sh was backwards,
replacing object names before replacing urls, making the test fail.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
t/t5150-request-pull.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t5150-request-pull.sh b/t/t5150-request-pull.sh
index 432f98c..1afa0d5 100755
--- a/t/t5150-request-pull.sh
+++ b/t/t5150-request-pull.sh
@@ -80,12 +80,12 @@ test_expect_success 'setup: two scripts for reading pull
requests' '
cat -EOT fuzz.sed
#!/bin/sed -nf
+ s/$downstream_url_for_sed/URL/g
s/$_x40/OBJECT_NAME/g
s/A U Thor/AUTHOR/g
s/[-0-9]\{10\} [:0-9]\{8\} [-+][0-9]\{4\}/DATE/g
s/[^ ].*/SUBJECT/g
s/ [^ ].* (DATE)/ SUBJECT (DATE)/g
- s/$downstream_url_for_sed/URL/g
s/for-upstream/BRANCH/g
s/mnemonic.txt/FILENAME/g
s/^version [0-9]/VERSION/
--
1.8.2.4.g940421e
--
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] GIT-VERSION-GEN: support non-standard $GIT_DIR path
make and make test both work when $GIT_DIR isn't .git, but make dist included a bogus GIT-VERSION-FILE. Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net --- I'm doing daily builds of git, using many workers and a shared git.git, with per-worker checkouts, it would be really useful if GIT-VERSION-GEN actually supports this and doesn't generate a fairly bogus GIT-VERSION-FILE. GIT-VERSION-GEN | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index 390782f..7dcca28 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -11,7 +11,7 @@ LF=' if test -f version then VN=$(cat version) || VN=$DEF_VER -elif test -d .git -o -f .git +elif test -d .git -o -f .git -o test -d $GIT_DIR VN=$(git describe --match v[0-9]* --abbrev=7 HEAD 2/dev/null) case $VN in *$LF*) (exit 1) ;; -- 1.8.2.4.g940421e -- 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] GIT-VERSION-GEN: support non-standard $GIT_DIR path
On ma, 2013-06-17 at 13:09 -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Dennis Kaarsemaker den...@kaarsemaker.net writes:
I'm doing daily builds of git, using many workers and a shared git.git,
with per-worker checkouts
OK, so GIT_DIR is explicitly specified in these workers.
Yes, both GIT_DIR and GIT_WORK_TREE are set and the use of .git/HEAD and
anything relying on it is shunned, so workers can run checkout as they
please.
Makes sense.
Actually it does not. What if GIT_DIR is an empty string or not set
at all? The patch breaks the build for everybody else, doesn't it?
It does indeed, I only tested in my setup and not with a normal make
test. Apologies.
Perhaps like this instead?
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 2908204..91ec831 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -11,7 +11,7 @@ LF='
if test -f version
then
VN=$(cat version) || VN=$DEF_VER
-elif test -d .git -o -f .git
+elif test -d ${GIT_DIR:-.git} -o -f .git
VN=$(git describe --match v[0-9]* --abbrev=7 HEAD 2/dev/null)
case $VN in
*$LF*) (exit 1) ;;
Yes, that makes a lot more sense and actually works in normal make test
and with a detached .git. Do you want me to send an updated patch?
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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
Daily deb/rpm builds of git
Hi all, To make it easier to help test changes that are in-flight, I've started using and publishing daily snapshots of -next as packages for Ubuntu 12.10, 13.04 and 13.10, Debian 7.0 and Fedora 17 and 18. If anyone else wants to use these, they can be found on launchpad and openSUSE's build service. They could also be useful to give to people who report issues, as a simple way to check against the latest git development. The .deb packages use Debian's packaging, with only the version numbers changed. The .rpm packages use Fedora's packaging, with only the version numbers changed. So neither are 'vanilla' git, but what people are used to on the respective operating systems. For Ubuntu: sudo apt-add-repository ppa:dennis/git-next Ubuntu alternative, because launchpad is seeing long delays (12.10, quantal) echo 'deb http://download.opensuse.org/repositories/home:/seveas:/git-next/xUbuntu_12.10/ ./' | sudo tee -a /etc/apt/sources.list (13.04, raring) echo 'deb http://download.opensuse.org/repositories/home:/seveas:/git-next/xUbuntu_13.04/ ./' | sudo tee -a /etc/apt/sources.list For Debian 7.0: echo 'deb http://download.opensuse.org/repositories/home:/seveas:/git-next/Debian_7.0/ ./' | sudo tee -a /etc/apt/sources.list For Fedora: (17) sudo wget http://download.opensuse.org/repositories/home:/seveas:/git-next/Fedora_17/home:seveas:git-next.repo -O /etc/yum.repos.d/git-next.repo (18) sudo wget http://download.opensuse.org/repositories/home:/seveas:/git-next/Fedora_18/home:seveas:git-next.repo -O /etc/yum.repos.d/git-next.repo -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
[BUG?] remote prune origin interacts badly with clone --mirror and multiple remotes
[git version: next as of yesterday afternoon] If I clone a repo with git clone --mirror, and add other remotes later, 'git remote prune origin' deletes all branches and tags of the other remotes. Easily repeatable example: [core] repositoryformatversion = 0 filemode = true bare = true logallrefupdates = false [remote origin] url = git://github.com/git/git.git fetch = +refs/*:refs/* mirror = true [remote peff] url = git://github.com/peff/git.git fetch = +refs/heads/*:refs/remotes/peff/* 'git remote prune origin' will delete all peff's branches in this case. I'm guessing the wildcards refs/* and refs/remotes/peff/* interact badly in some place, and I'm trying to understand builtin/remote.c to see if I can fix it, but haven't gotten very far yet. git fetch --prune origin and git remote update --prune also show this behaviour. git remote prune peff does not delete non-peff branches in this scenario, further strengthening my belief that the refs/* and refs/remotes/peff/* wildcards interact badly with prune. Or is this considered normal behaviour and is what I'm trying to do simply unsupported? In that case a warning would be welcome when adding remotes to a --mirror'ed repository. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] remote: make prune work for mixed mirror/non-mirror repos
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs-dst both equal to refs/*, we should
ignore refs/remotes/* when looking for stale refs to prevent this from
happening.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
remote.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index e71f66d..863c183 100644
--- a/remote.c
+++ b/remote.c
@@ -1884,6 +1884,7 @@ struct stale_heads_info {
struct ref **stale_refs_tail;
struct refspec *refs;
int ref_count;
+ int ignore_remotes;
};
static int get_stale_heads_cb(const char *refname,
@@ -1903,7 +1904,8 @@ static int get_stale_heads_cb(const char *refname,
* remote we consider it to be stale.
*/
if (!((flags REF_ISSYMREF) ||
- string_list_has_string(info-ref_names, query.src))) {
+ string_list_has_string(info-ref_names, query.src) ||
+ (info-ignore_remotes !prefixcmp(refname, refs/remotes/ {
struct ref *ref = make_linked_ref(refname,
info-stale_refs_tail);
hashcpy(ref-new_sha1, sha1);
}
@@ -1917,6 +1919,8 @@ struct ref *get_stale_heads(struct refspec *refs, int
ref_count, struct ref *fet
struct ref *ref, *stale_refs = NULL;
struct string_list ref_names = STRING_LIST_INIT_NODUP;
struct stale_heads_info info;
+ if(!strcmp(refs-src, refs/*) !strcmp(refs-dst, refs/*))
+ info.ignore_remotes = 1;
info.ref_names = ref_names;
info.stale_refs_tail = stale_refs;
info.refs = refs;
--
1.8.3.1-619-gbec0aa7
--
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 v2] remote: make prune work for mixed mirror/non-mirror repos
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as stale. In
this situation, with refs-src and refs-dst both equal to refs/*, we should
ignore refs/remotes/* and refs/tags/* when looking for stale refs to
prevent this from happening.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
The previous attempt only ignored refs/remotes, but that's not good enough as
that will still delete tags. So let's ignore refs/tags too. The downside is
that tags removed at the origin don't get removed, but prune should only be
pruning branches anyway if I read the documentation correctly.
remote.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/remote.c b/remote.c
index e71f66d..efc5481 100644
--- a/remote.c
+++ b/remote.c
@@ -1884,6 +1884,7 @@ struct stale_heads_info {
struct ref **stale_refs_tail;
struct refspec *refs;
int ref_count;
+ int is_mirror;
};
static int get_stale_heads_cb(const char *refname,
@@ -1896,6 +1897,13 @@ static int get_stale_heads_cb(const char *refname,
if (query_refspecs(info-refs, info-ref_count, query))
return 0; /* No matches */
+ /*
+* If we're pruning a clone that was --mirror'ed, let's ignore refs/tags
+* and refs/remotes
+*/
+ if (info-is_mirror (!prefixcmp(refname, refs/tags/) ||
+ !prefixcmp(refname, refs/remotes/)))
+ return 0;
/*
* If we did find a suitable refspec and it's not a symref and
@@ -1917,6 +1925,8 @@ struct ref *get_stale_heads(struct refspec *refs, int
ref_count, struct ref *fet
struct ref *ref, *stale_refs = NULL;
struct string_list ref_names = STRING_LIST_INIT_NODUP;
struct stale_heads_info info;
+ if(!strcmp(refs-src, refs/*) !strcmp(refs-dst, refs/*))
+ info.is_mirror = 1;
info.ref_names = ref_names;
info.stale_refs_tail = stale_refs;
info.refs = refs;
--
1.8.3.1-619-gbec0aa7
--
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] remote: make prune work for mixed mirror/non-mirror repos
(Sorry, I sent v2 before seeing this mail) On do, 2013-06-20 at 15:46 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: When cloning a repo with --mirror, and adding more remotes later, get_stale_heads for origin would mark all refs from other repos as stale. In this situation, with refs-src and refs-dst both equal to refs/*, we should ignore refs/remotes/* when looking for stale refs to prevent this from happening. I do not think it is a right solution to single out refs/remotes/*. Going back to your original example: [remote origin] url = git://github.com/git/git.git fetch = +refs/*:refs/* mirror = true [remote peff] url = git://github.com/peff/git.git fetch = +refs/heads/*:refs/remotes/peff/* Wouldn't you obtain refs/remotes/github/html from your origin via git pull origin? What happens to your local copy of that ref, when it goes away from the origin and then you try to fetch --prune origin the next time with this patch (and without this patch)? git pull origin gives me refs/html in this case. I did not try fetch --prune, but prune origin DTRT: if the html branch goes away at the origin, it goes away locally. Both with and without this patch. It's refs/remotes/peff/somebranch that in this case *also* goes away without this patch, but is untouched with this patch What should happen? Exactly that. What if you had this instead of the above version of remote.peff.*? [remote peff] url = git://github.com/peff/git.git fetch = +refs/heads/*:refs/remotes/github/* That doesn't change anything. I think this is an unsolvable problem, and I _think_ the root cause of the issue is the configuration above that allows the RHS of different fetch refspecs to overlap. refs/* is more generic and covers refs/remotes/peff/* and refs/remotes/github/*. You cannot even know, just by looking at origin and your local repository, if refs/remotes/github/html you have should go away or it might have come from somewhere else. The best we _could_ do, without contacting all the defined remotes, is probably to check each ref that we did not see from origin (for example, you find refs/remotes/peff/frotz that your origin does not have) and see if it could match RHS of fetch refspec of somebody else (e.g. RHS of refs/heads/*:refs/remotes/peff/* matches that ref). Then we can conclude that refs/remotes/peff/frotz _might_ have come from Peff's repository and not from origin, and then we can optionally issue a warning and refrain from removing it. I like that idea, though I also like the simplicity of simply singling out remotes as that's where normal remotes usually sit. And don't forget about tags (see patch v2). This inevitably will have false positives and leave something that did originally came from origin, because peff may no longer have 'frotz' branch in his repository. I do not think we can do better than that, because we are trying to see if we can improve things without having to contact all the remotes. But then the ref would have to be called refs/remotes/peff/frotz upstream. Hmm, that is of course completely possible: cloning something that's already a clone. But if you go that route, the logic needs to go the same way when you are pruning against 'peff', and anything that you do not see in his repository right now but you have in refs/remotes/peff/ cannot be pruned, because it might have come from your origin via more generic refs/*:refs/* mapping. It follows that you could never prune anything under refs/remotes/peff/* hierarchy. You could introduce a assume that more specific mapping never overlaps with a more generic mapping rule (i.e. refs/* from RHS of remote.origin.fetch is more generic than refs/remotes/peff/* from RHS of remote.peff.fetch, and assume everything that you see in your local refs/remotes/peff/* came from peff and not from origin, I think, but at that point, is it worth the possible complexity to code that rule in the prune codepath and brittleness of that assumption that your origin will never add a new ref under that hierarchy, e.g. refs/remotes/peff/xyzzy? So, I dunno. Yeah, I'm starting to think this is not such a good idea. How about plan B: issuing a warning when adding a remote with a refspec that also matches another remote's refspec? Or plan C: add a per-remote pruneIgnore setting that in this case I could set to refs/tags/* refs/remotes/* as I know it's correct? Could even be combined with plan B. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] remote: make prune work for mixed mirror/non-mirror repos
On do, 2013-06-20 at 19:08 -0400, Jeff King wrote: I wonder why Dennis wants to refs/*:refs/* in the first place. It is not usually a useful thing to have in a non-bare repository, because fetches will overwrite local work on branches. If he just wanted the automatic git push --mirror setting, that does not depend on the fetch refspec. I'm not doing that in non-bare repositories, neither do I use it for pushing. It's for a continuous integration system, which never has any locally created branches or commits, but does integrate things from different remotes in some cases. The example with git.git is used roughly as follows: * git fetch all remotes (for most projects that will be 1 remote) * rebuild reflogs from github events (or fetch via http/ssh) * per push to next, check out to a separate $GIT_WORK_TREE and run make test * for the last push, also build and publish daily tarball+deb+rpm Then, for further testing of local requirements: * cherry-pick your jk/blame_tree branch * test, build and install package Given that this system works with clones of what should be considered canonical copies of repositories, those remotes shouldn't have any remotes defined themselves, so at least being able to configure prune to ignore refs/remotes/* and refs/tags/* would help me a lot. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] remote: make prune work for mixed mirror/non-mirror repos
On do, 2013-06-20 at 16:30 -0700, Junio C Hamano wrote: Maybe there is a miscommunication. $ git ls-remote git://github.com/git/git.git | grep remotes/ shows that that repository, your origin, has refs/remotes/github/html Yes, I misunderstood you and see the problem now. Thanks for being patient with me :) Yeah, I'm starting to think this is not such a good idea. How about plan B: issuing a warning when adding a remote with a refspec that also matches another remote's refspec? Surely that will make things safer. Or plan C: add a per-remote pruneIgnore setting that in this case I could set to refs/tags/* refs/remotes/* as I know it's correct? Could even be combined with plan B. As I already said I dunno, I am not sure if it is worth the effort to support overlapping RHSs of fetch refspecs, so between B and C, I would vote for B. I'm halfway through cooking up a patch for B, as I agree that it will make things safer. I'd really like to have C as well though, would you accept a patch that implements it? -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 0/3] Handling overlapping refspecs slightly smarter
1/3 should be pretty sane, just adding a warning in documentation and 'git remote add' about overlapping refspecs. 2/3 only makes sense if 3/3 is accepted, as it's a test for that change. 3/3 I'm not 100% sure about, though the approach feels reasonably ok. It changes get_stale_heads to also detect overlapping refspecs and abort any prune action if it finds them. What I'm not sure about is whether this is the right place to do it, or to do it in the callers of get_stale_heads and exit(1) in this situation. Both 1/3 and 3/3 ignore exactly matching refspecs, as that's a supported thing already, another test in t5505 broke before I made both ignore exactly matching refspecs. Dennis Kaarsemaker (3): remote: Add warnings about mixin --mirror and other remotes remote: Add test for prune and mixed --mirror and normal remotes remote: don't prune when detecting overlapping refspecs Documentation/git-remote.txt | 6 +- builtin/remote.c | 17 + remote.c | 23 +++ t/t5505-remote.sh| 9 + 4 files changed, 54 insertions(+), 1 deletion(-) -- 1.8.3.1-619-gbec0aa7 -- 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 3/3] remote: don't prune when detecting overlapping refspecs
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin would mark all refs from other repos as
stale. There's no good way to solve, this so the best thing we can do
is refusing to prune if we detect this and warning the user.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
remote.c | 23 +++
t/t5505-remote.sh | 2 +-
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/remote.c b/remote.c
index e71f66d..39a9405 100644
--- a/remote.c
+++ b/remote.c
@@ -1912,11 +1912,34 @@ static int get_stale_heads_cb(const char *refname,
return 0;
}
+static int check_overlapping_remotes(struct remote *first, void *priv) {
+ struct remote *second = priv;
+ int i, j;
+ if(!second)
+ return for_each_remote(check_overlapping_remotes, first);
+ if(first == second)
+ return 0;
+ for (i = 0; i first-fetch_refspec_nr; i++) {
+ for (j = 0; j second-fetch_refspec_nr; j++) {
+ if(strcmp(first-fetch[i].dst, second-fetch[j].dst)
+ (!fnmatch(first-fetch[i].dst, second-fetch[j].dst,
0) ||
+ !fnmatch(second-fetch[j].dst, first-fetch[i].dst,
0))) {
+ warning(_(Overlapping refspecs detected: '%s'
and '%s', not pruning.),
+ first-fetch[i].dst,
second-fetch[j].dst);
+ return 1;
+ }
+ }
+ }
+ return 0;
+}
+
struct ref *get_stale_heads(struct refspec *refs, int ref_count, struct ref
*fetch_map)
{
struct ref *ref, *stale_refs = NULL;
struct string_list ref_names = STRING_LIST_INIT_NODUP;
struct stale_heads_info info;
+ if(for_each_remote(check_overlapping_remotes, NULL))
+ return NULL;
info.ref_names = ref_names;
info.stale_refs_tail = stale_refs;
info.refs = refs;
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 439e996..d4ac6ce 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -428,7 +428,7 @@ test_expect_success 'add alt prune' '
git rev-parse --verify refs/remotes/origin/side2)
'
-test_expect_failure 'prune and overlapping refspecs' '
+test_expect_success 'prune and overlapping refspecs' '
(git clone --mirror one prunetst
cd prunetst
git remote add two ../two
--
1.8.3.1-619-gbec0aa7
--
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 2/3] remote: Add test for prune and mixed --mirror and normal remotes
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net --- t/t5505-remote.sh | 9 + 1 file changed, 9 insertions(+) diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh index dd10ff0..439e996 100755 --- a/t/t5505-remote.sh +++ b/t/t5505-remote.sh @@ -428,6 +428,15 @@ test_expect_success 'add alt prune' ' git rev-parse --verify refs/remotes/origin/side2) ' +test_expect_failure 'prune and overlapping refspecs' ' + (git clone --mirror one prunetst +cd prunetst +git remote add two ../two + git fetch two +git remote prune origin + git rev-parse --verify refs/remotes/two/another) +' + cat test/expect \EOF some-tag EOF -- 1.8.3.1-619-gbec0aa7 -- 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 1/3] remote: Add warnings about mixin --mirror and other remotes
When cloning a repo with --mirror, and adding more remotes later,
get_stale_heads for origin will mark all refs from other repos as stale.
Add a warning to the documentation, and warn the user when we detect
such things during git remote add.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
Documentation/git-remote.txt | 6 +-
builtin/remote.c | 17 +
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index 581bb4c..d7457df 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -71,7 +71,11 @@ When a fetch mirror is created with `--mirror=fetch`, the
refs will not
be stored in the 'refs/remotes/' namespace, but rather everything in
'refs/' on the remote will be directly mirrored into 'refs/' in the
local repository. This option only makes sense in bare repositories,
-because a fetch would overwrite any local commits.
+because a fetch would overwrite any local commits. If you want to add extra
+remotes to a repository created with `--mirror=fetch`, you will need to change
+the configuration of the mirrored remote to fetch only `refs/heads/*`,
+otherwise `git remote prune remote` will remove all branches for the extra
+remotes.
+
When a push mirror is created with `--mirror=push`, then `git push`
will always behave as if `--mirror` was passed.
diff --git a/builtin/remote.c b/builtin/remote.c
index 5e54d36..a4f9cb8 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -112,6 +112,21 @@ enum {
#define MIRROR_PUSH 2
#define MIRROR_BOTH (MIRROR_FETCH|MIRROR_PUSH)
+static int check_overlapping_refspec(struct remote *remote, void *priv)
+{
+ char *refspec = priv;
+ int i;
+ for (i = 0; i remote-fetch_refspec_nr; i++) {
+ if(strcmp(refspec, remote-fetch[i].dst)
+ (!fnmatch(refspec, remote-fetch[i].dst, 0) ||
+ !fnmatch(remote-fetch[i].dst, refspec, 0))) {
+ warning(_(Overlapping refspecs detected: '%s' and
'%s'),
+ refspec, remote-fetch[i].dst);
+ }
+ }
+ return 0;
+}
+
static int add_branch(const char *key, const char *branchname,
const char *remotename, int mirror, struct strbuf *tmp)
{
@@ -123,6 +138,8 @@ static int add_branch(const char *key, const char
*branchname,
else
strbuf_addf(tmp, refs/heads/%s:refs/remotes/%s/%s,
branchname, remotename, branchname);
+
+ for_each_remote(check_overlapping_refspec, strchr((const
char*)tmp-buf, ':') + 1);
return git_config_set_multivar(key, tmp-buf, ^$, 0);
}
--
1.8.3.1-619-gbec0aa7
--
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] remote: Add warnings about mixin --mirror and other remotes
On vr, 2013-06-21 at 11:42 -0700, Junio C Hamano wrote:
+(!fnmatch(refspec, remote-fetch[i].dst, 0) ||
+ !fnmatch(remote-fetch[i].dst, refspec, 0))) {
Does .dst always exist and is never a NULL? My quick scan of
remote.c::parse_refspec_internal() tells me otherwise.
Also what are you matching with what? refs/* against
refs/remotes/origin/*?
What if remote-fetch[i] is not a wildcarded refspec, e.g.
[remote origin]
fetch = +refs/heads/master:refs/heads/origin
fetch = +refs/heads/next:refs/remotes/origin/next
You would want to check for equality in such a case against the RHS
of the refspeec you have.
Thanks for all the feedback, I've incorporated it all in a reroll that's
in progress, except for the above.
I've added a prefix check, so refs/foo and refs/foo/bar will be
considered clashes, but not yet an equality check. Equality for
wildcards is allowed and tested for, so do we really want to 'outlaw'
equality of non-wildcard refspecs?
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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] remote: Add warnings about mixin --mirror and other remotes
On zo, 2013-06-23 at 14:22 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: Equality for wildcards is allowed and tested for, so do we really want to 'outlaw' equality of non-wildcard refspecs? I am not sure what you mean by equality for wildcards is allowed. Do you mean this pair of remote definition is sane and not warned? [remote one] fetch = refs/heads/*:refs/remotes/mixed/* [remote two] fetch = refs/heads/*:refs/remotes/mixed/* I personally don't consider them very sane and didn't originally support that. But this behavior is tested for in t5505-remote.sh test 27, which started failing until I stopped warning for equal refspecs. This support for alt remotes in prune was added by c175a7ad in 2008. The commit message for that commit give a plausible reason for using them. For non-wildcard ones, I think these pairs are both suspects for possible clashes and want to be warned. (1) literal-vs-literal [remote one] fetch = refs/heads/master:refs/heads/origin [remote two] fetch = refs/heads/master:refs/heads/origin I agree, but c175a7ad would disagree. (2) literal-vs-wildcard [remote one] fetch = refs/heads/*:refs/remotes/origin/* [remote two] fetch = refs/heads/master:refs/remotes/origin/master Agreed and was already covered in v1. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] remote: Add warnings about mixin --mirror and other remotes
On zo, 2013-06-23 at 15:33 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: On zo, 2013-06-23 at 14:22 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: Equality for wildcards is allowed and tested for, so do we really want to 'outlaw' equality of non-wildcard refspecs? I am not sure what you mean by equality for wildcards is allowed. Do you mean this pair of remote definition is sane and not warned? [remote one] fetch = refs/heads/*:refs/remotes/mixed/* [remote two] fetch = refs/heads/*:refs/remotes/mixed/* I personally don't consider them very sane and didn't originally support that. But this behavior is tested for in t5505-remote.sh test 27, which started failing until I stopped warning for equal refspecs. This support for alt remotes in prune was added by c175a7ad in 2008. The commit message for that commit give a plausible reason for using them. I actually do not read it that way. What it wanted to do primarily was to avoid pruning refs/remotes/alt/* based on what it observed at the remote named alt, when the refs fetched from that remote is set to update refs/remotes/origin/*. The example in the log message is a special case where two physically different remotes are actually copies of a single logical repository, so in that narrow use case, it may be OK, but it is an unusual thing to do and we should warn about it, I think. Apart from the exactly matching refspecs, does git in any other way treat this as a special case? In any case, I've been assuming in this discussion allow is to silently accept, and overlaps are warned but not rejected. So if you meant by 'outlaw' to die and refuse to run, that is not what I meant. Well, 1/3 is a warning on add, 3/3 is a warning and refusing to prune. Should 3/3 do something else instead? Perhaps prompt for confirmation or require some sort of --force? -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Python version auditing followup
On do, 2012-12-20 at 10:30 -0800, Junio C Hamano wrote: Which platforms that are long-term-maintained by their vendors still pin their Python at 2.4.X? RHEL 5.x and its clones still use python 2.4. It is supported by red hat until at least 2017 (though end of production phase two, Q1 2014, seems like a reasonable cut-off point). -- Dennis Kaarsemaker -- 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: Segfault in git 1.8.1.5
On za, 2013-03-09 at 21:16 +0100, Strasser Pablo wrote: Hello, I segfault with the following command: git checkout HEAD~1 git branch -u origin/master I think it's because i'm in detached head. A error message like cannot use this command in would be a better responce than a segfault. Confirmed. dennis@lightning:/tmp/hacks$ gdb --args ~/code/git/git branch -u origin/master (gdb) run Starting program: /home/dennis/code/git/git branch -u origin/master [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/i386-linux-gnu/libthread_db.so.1. Program received signal SIGSEGV, Segmentation fault. cmd_branch (argc=0, argv=0xbfffec08, prefix=0x0) at builtin/branch.c:886 886 if (!ref_exists(branch-refname)) (gdb) bt #0 cmd_branch (argc=0, argv=0xbfffec08, prefix=0x0) at builtin/branch.c:886 #1 0x0804c26c in run_builtin (argv=0xbfffec08, argc=3, p=0x819f3f4 commands.21695+84) at git.c:273 #2 handle_internal_command (argc=3, argv=0xbfffec08) at git.c:435 #3 0x0804b656 in run_argv (argv=0xbfffeb74, argcp=0xbfffeb70) at git.c:481 #4 main (argc=3, argv=0xbfffec08) at git.c:556 But it's already been fixed by 8efb889: branch: segfault fixes and validation. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
Reading remote reflogs
Is it possible to somehow fetch the reflog of a remote? I would like to delegate some post-receive actions to an automatically mirrored clone of some repositories. Mirrored repositories don't maintain a reflog, even with core.logAllRefUpdates = true, so to be able to know what was pushed per push, it would need to somehow know the reflog of the origin. Of course a post-receive hook can send this information downstream, but I'd like to keep the origin 'dumb' and not do that. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Reading remote reflogs
On vr, 2013-03-29 at 15:45 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: ... Mirrored repositories don't maintain a reflog, even with core.logAllRefUpdates = true,... Are you sure about this? When log_all_ref_updates is not set, by default we do not log for bare repositories, but other than that, we do not do anything special with respect to reflogs. I was, as I tried the recipe below, though with a different repo. Must have goofed something up, as it works now. Thanks for the braincheck :) That gives me a reasonable approximation of distinct pushes if I pull the mirror often enough. It's always going to be an approximation though, so the original question still stands. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Reading remote reflogs
On vr, 2013-03-29 at 15:58 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: On vr, 2013-03-29 at 15:45 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: ... Mirrored repositories don't maintain a reflog, even with core.logAllRefUpdates = true,... Are you sure about this? When log_all_ref_updates is not set, by default we do not log for bare repositories, but other than that, we do not do anything special with respect to reflogs. I was, as I tried the recipe below, though with a different repo. Must have goofed something up, as it works now. Thanks for the braincheck :) That gives me a reasonable approximation of distinct pushes if I pull the mirror often enough. Instead of polling, why not git push --mirror whenever the original gets updated? I considered that, but it has two downsides: - Slows down the push as it needs to wait for this to complete - Only works if you control the master, so it won't work with e.g. github hosted repositories -- Dennis Kaarsemaker www.kaarsemaker.net -- 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_DIR not auto ignored
On za, 2013-11-30 at 23:06 -0800, Ingy dot Net wrote: Greetings, I found this probable bug: https://gist.github.com/anonymous/01979fd9e6e285df41a2 Summary: $ mv .git .foo $ export GIT_DIR=$PWD/.foo $ git status # On branch master # # Initial commit # # Untracked files: # .foo/ nothing added to commit but untracked files present I checked with 1.8.5 and this still happens. And this also happens: $ mv .git .foo $ export GIT_DIR=.foo dennis@lightning:~/code/git$ touch .git dennis@lightning:~/code/git$ git status On branch master Untracked files: (use git add file... to include in what will be committed) .foo/ nothing added to commit but untracked files present (use git add to track) (Note the absence of .git there) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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_DIR not auto ignored
On zo, 2013-12-01 at 19:08 +0100, Dennis Kaarsemaker wrote: On za, 2013-11-30 at 23:06 -0800, Ingy dot Net wrote: Greetings, I found this probable bug: https://gist.github.com/anonymous/01979fd9e6e285df41a2 Summary: $ mv .git .foo $ export GIT_DIR=$PWD/.foo $ git status # On branch master # # Initial commit # # Untracked files: # .foo/ nothing added to commit but untracked files present I checked with 1.8.5 and this still happens. This makes it go away: diff --git a/dir.c b/dir.c index 23b6de4..884b37d 100644 --- a/dir.c +++ b/dir.c @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir, return path_none; strbuf_setlen(path, baselen); strbuf_addstr(path, de-d_name); - if (simplify_away(path-buf, path-len, simplify)) + if (simplify_away(path-buf, path-len, simplify) || is_git_directory(path-buf)) return path_none; dtype = DTYPE(de); I'll add a test and submit a proper patch. And this also happens: $ mv .git .foo $ export GIT_DIR=.foo dennis@lightning:~/code/git$ touch .git dennis@lightning:~/code/git$ git status On branch master Untracked files: (use git add file... to include in what will be committed) .foo/ nothing added to commit but untracked files present (use git add to track) (Note the absence of .git there) Comments in dir.c indicate that this is expected, so I didn't try to fix that. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] path_treatment: also ignore $GIT_DIR if it's not .git
We always ignore anything named .git, but we should also ignore the git
directory if the user overrides it by setting $GIT_DIR
Reported-By: Ingy döt Net i...@ingy.net
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
dir.c | 2 +-
t/t7508-status.sh | 7 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/dir.c b/dir.c
index 23b6de4..884b37d 100644
--- a/dir.c
+++ b/dir.c
@@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct
*dir,
return path_none;
strbuf_setlen(path, baselen);
strbuf_addstr(path, de-d_name);
- if (simplify_away(path-buf, path-len, simplify))
+ if (simplify_away(path-buf, path-len, simplify) ||
is_git_directory(path-buf))
return path_none;
dtype = DTYPE(de);
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index c987b5e..2bd7ef1 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -198,6 +198,13 @@ test_expect_success 'status -s' '
'
+test_expect_success 'status -s with non-standard $GIT_DIR' '
+ mv .git .foo
+ GIT_DIR=.foo git status -s output
+ test_cmp expect output
+ mv .foo .git
+'
+
test_expect_success 'status with gitignore' '
{
echo .gitignore
--
1.8.5-386-gb78cb96
--
Dennis Kaarsemaker den...@kaarsemaker.net
http://twitter.com/seveas
--
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] path_treatment: also ignore $GIT_DIR if it's not .git
On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote: Duy Nguyen pclo...@gmail.com writes: On Mon, Dec 2, 2013 at 2:04 AM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: We always ignore anything named .git, but we should also ignore the git directory if the user overrides it by setting $GIT_DIR [...] + if (simplify_away(path-buf, path-len, simplify) || is_git_directory(path-buf)) return path_none; this adds 2 access, 1 lstat, 1 open, 1 read, 1 close to _every_ path we check. Is it worth the cost? Moreover it is a much more inclusive check than what the commit message claims: it will ignore anything that looks like a .git directory, regardless of the name. In particular GIT_DIR doesn't have anything to do with it. Ah, yes thanks, that's rather incorrect indeed. How about the following instead? Passes all tests, including the new one. --- a/dir.c +++ b/dir.c @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir, return path_none; strbuf_setlen(path, baselen); strbuf_addstr(path, de-d_name); - if (simplify_away(path-buf, path-len, simplify)) + if (simplify_away(path-buf, path-len, simplify) || !strncmp(get_git_dir(), path-buf, path-len)) return path_none; -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] path_treatment: also ignore $GIT_DIR if it's not .git
On ma, 2013-12-02 at 07:38 +0700, Duy Nguyen wrote: On Mon, Dec 2, 2013 at 6:38 AM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote: Duy Nguyen pclo...@gmail.com writes: On Mon, Dec 2, 2013 at 2:04 AM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: We always ignore anything named .git, but we should also ignore the git directory if the user overrides it by setting $GIT_DIR [...] + if (simplify_away(path-buf, path-len, simplify) || is_git_directory(path-buf)) return path_none; this adds 2 access, 1 lstat, 1 open, 1 read, 1 close to _every_ path we check. Is it worth the cost? Moreover it is a much more inclusive check than what the commit message claims: it will ignore anything that looks like a .git directory, regardless of the name. In particular GIT_DIR doesn't have anything to do with it. Ah, yes thanks, that's rather incorrect indeed. How about the following instead? Passes all tests, including the new one. --- a/dir.c +++ b/dir.c @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir, return path_none; strbuf_setlen(path, baselen); strbuf_addstr(path, de-d_name); - if (simplify_away(path-buf, path-len, simplify)) + if (simplify_away(path-buf, path-len, simplify) || !strncmp(get_git_dir(), path-buf, path-len)) return path_none; get_git_dir() may return a relative or absolute path, depending on GIT_DIR/GIT_WORK_TREE. path-buf is always relative. You'll pass one case with this (relative vs relative) and fail another. It might be simpler to just add get_git_dir(), after converting to relative path and check if it's in worktree, to the exclude list and let the current exclude mechanism handle it. This type of invocation really only works from the root of the workdir anyway and both a relative and absolute path work just fine: dennis@lightning:~/code/git$ GIT_DIR=$(pwd)/.foo ./git status On branch master nothing to commit, working directory clean dennis@lightning:~/code/git$ GIT_DIR=./.foo ./git status On branch master nothing to commit, working directory clean Well, unless you set GIT_WORK_TREE as well, but then it still works: dennis@lightning:~/code/git/t$ GIT_DIR=$(pwd)/../.foo GIT_WORK_TREE=.. ../git status On branch master nothing to commit, working directory clean dennis@lightning:~/code/git/t$ GIT_DIR=../.foo GIT_WORK_TREE=.. ../git status On branch master nothing to commit, working directory clean So I'm wondering when you think this will fail. Because then I can add a test for that case too. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] path_treatment: also ignore $GIT_DIR if it's not .git
On ma, 2013-12-02 at 16:35 +0700, Duy Nguyen wrote: On Mon, Dec 2, 2013 at 3:01 PM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: On ma, 2013-12-02 at 07:38 +0700, Duy Nguyen wrote: On Mon, Dec 2, 2013 at 6:38 AM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: On ma, 2013-12-02 at 00:08 +0100, Thomas Rast wrote: Duy Nguyen pclo...@gmail.com writes: On Mon, Dec 2, 2013 at 2:04 AM, Dennis Kaarsemaker den...@kaarsemaker.net wrote: We always ignore anything named .git, but we should also ignore the git directory if the user overrides it by setting $GIT_DIR [...] + if (simplify_away(path-buf, path-len, simplify) || is_git_directory(path-buf)) return path_none; this adds 2 access, 1 lstat, 1 open, 1 read, 1 close to _every_ path we check. Is it worth the cost? Moreover it is a much more inclusive check than what the commit message claims: it will ignore anything that looks like a .git directory, regardless of the name. In particular GIT_DIR doesn't have anything to do with it. Ah, yes thanks, that's rather incorrect indeed. How about the following instead? Passes all tests, including the new one. --- a/dir.c +++ b/dir.c @@ -1198,7 +1198,7 @@ static enum path_treatment treat_path(struct dir_struct *dir, return path_none; strbuf_setlen(path, baselen); strbuf_addstr(path, de-d_name); - if (simplify_away(path-buf, path-len, simplify)) + if (simplify_away(path-buf, path-len, simplify) || !strncmp(get_git_dir(), path-buf, path-len)) return path_none; get_git_dir() may return a relative or absolute path, depending on GIT_DIR/GIT_WORK_TREE. path-buf is always relative. You'll pass one case with this (relative vs relative) and fail another. It might be simpler to just add get_git_dir(), after converting to relative path and check if it's in worktree, to the exclude list and let the current exclude mechanism handle it. This type of invocation really only works from the root of the workdir anyway and both a relative and absolute path work just fine: dennis@lightning:~/code/git$ GIT_DIR=$(pwd)/.foo ./git status On branch master nothing to commit, working directory clean dennis@lightning:~/code/git$ GIT_DIR=./.foo ./git status On branch master nothing to commit, working directory clean Well, unless you set GIT_WORK_TREE as well, but then it still works: dennis@lightning:~/code/git/t$ GIT_DIR=$(pwd)/../.foo GIT_WORK_TREE=.. ../git status On branch master nothing to commit, working directory clean dennis@lightning:~/code/git/t$ GIT_DIR=../.foo GIT_WORK_TREE=.. ../git status On branch master nothing to commit, working directory clean So I'm wondering when you think this will fail. Because then I can add a test for that case too. ~/w/git $ cd t ~/w/git/t $ GIT_TRACE_SETUP=1 ../git --git-dir=../.git --work-tree=.. --no-pager status setup: git_dir: /home/pclouds/w/git/.git setup: worktree: /home/pclouds/w/git setup: cwd: /home/pclouds/w/git setup: prefix: t/ On branch exclude-pathspec Your branch and 'origin/master' have diverged, and have 2 and 5 different commits each, respectively. I can't say this is the only case though. One has to audit to all possible setup cases in setup_git_directory() to make that claim. I'm probably missing something, but that's the same as my second example, and works. I also tried running it from completely outside the repo: dennis@lightning:~$ code/git/git --git-dir=code/git/.foo --work-tree=code/git status On branch master nothing to commit, working directory clean dennis@lightning:~$ code/git/git --git-dir=/home/dennis/code/git/.foo --work-tree=code/git status On branch master nothing to commit, working directory clean -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Can we stage all files using git add command, except some specific files ?
On di, 2014-05-27 at 00:33 +0630, Arup Rakshit wrote: Now, you can see, I have staged all the files first using *git add -A*, then _unstaging_ those I don't want to _stage_ right now. Now can this be done, in the *staging* time ? I mean any way to tell `git add` command, that add all the files from the current directory, except some specific files. No, there is no such option to do that, but you could use git add --interactive and use its interface to quickly pick the files you want to add. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 in shallow clone?
On wo, 2014-05-28 at 21:16 +0700, Duy Nguyen wrote: On Wed, May 28, 2014 at 9:02 PM, Thomas Kieffer thomaskief...@web.de wrote: I then clone the bare repository with --depth 1. git clone file:///path/to/bare.git ./clone --depth 1 It always returns the last two commits. If I specify --depth 2 it returns the last 3 commits. If I use --depth 1 on a Github repository it works as expected. Am I doing something wrong or is it really a bug? Depth calculation has been corrected lately. It depends on your version, maybe it's older than 1.8.2? If it's the latest, we screwed something up again.. 2.0.0-rc4 does this correctly. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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 REPORT] Git log pretty date
On do, 2014-05-29 at 11:29 +0100, Rodrigo Fernandes wrote: The problem happens when I try to get a pretty log for a commit with a wrong date. The commit is: === $ git cat-file commit e9dddaf24c9de45d9b4efdf38eff7c30eb200f48 tree d63aeb159635cb231e191505a95a129a3b4a7b38 parent 9276202f1c0dcc360433df222c90f7874558f072 author SamWM s...@webmonkeysolutions.com 1288370243 --700 committer SamWM s...@webmonkeysolutions.com 1288370243 --700 Update version number, make text formatting and indentation consistent with the rest of the code Those dates are indeed wrong, I'm not surprised git refuses to parse them. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] Makefile: don't hardcode HEAD in dist target
Instead of calling git-archive HEAD^{tree}, use $(GIT_VERSION)^{tree}.
This makes sure the archive name and contents are consistent, if HEAD
has moved, but GIT-VERSION-FILE hasn't been regenerated yet.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
I have a somewhat odd setup in which I share a .git between multiple
checkouts for automated builds. To minimize locking time for parallel
builds with different options, there's only a lock around checkout and
running git describe $commit version, the builds themselves run in
parallel.
This works just fine except during 'make dist', which is hardcoded to
package up HEAD, but that's not always the commit that is actually
checked out, another process may have checked out something else.
I realize this setup is somewhat strange, but the only change necessary
to make this work is this one-line patch, so I hope that's acceptable.
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a53f3a8..63d9bac 100644
--- a/Makefile
+++ b/Makefile
@@ -2433,7 +2433,7 @@ git.spec: git.spec.in GIT-VERSION-FILE
GIT_TARNAME = git-$(GIT_VERSION)
dist: git.spec git-archive$(X) configure
./git-archive --format=tar \
- --prefix=$(GIT_TARNAME)/ HEAD^{tree} $(GIT_TARNAME).tar
+ --prefix=$(GIT_TARNAME)/ $(GIT_VERSION)^{tree}
$(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git.spec configure $(GIT_TARNAME)
@echo $(GIT_VERSION) $(GIT_TARNAME)/version
--
2.0.0-538-ga6b2d95
--
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] Makefile: don't hardcode HEAD in dist target
On Mon, Jun 02, 2014 at 11:53:36AM -0700, Junio C Hamano wrote:
Dennis Kaarsemaker den...@kaarsemaker.net writes:
Instead of calling git-archive HEAD^{tree}, use $(GIT_VERSION)^{tree}.
This makes sure the archive name and contents are consistent, if HEAD
has moved, but GIT-VERSION-FILE hasn't been regenerated yet.
Signed-off-by: Dennis Kaarsemaker den...@kaarsemaker.net
---
I have a somewhat odd setup in which I share a .git between multiple
checkouts for automated builds. To minimize locking time for parallel
builds with different options, there's only a lock around checkout and
running git describe $commit version, the builds themselves run in
parallel.
This works just fine except during 'make dist', which is hardcoded to
package up HEAD, but that's not always the commit that is actually
checked out, another process may have checked out something else.
I realize this setup is somewhat strange, but the only change necessary
to make this work is this one-line patch, so I hope that's acceptable.
The dist target happens to do a clean checkout to a temporary
directory with git archive and then muck with its contents before
tarring up the result, so moving HEAD around may appear to work for
this particular target, but htmldocs/manpages targets use what is in
the current checkout of Documentation/ area. Turning the HEAD^{tree}
into $(GIT_VERSION)^{tree} would make the inconsistency between the
two worse, wouldn't it?
I'd say it would make the consistency better, because now both look at
what is checked out instead of at HEAD. I agree that it's a game of
whack-a-mole though and it's really easy to add another dependency on
HEAD and GIT-VERSION-FILE agreeing with each other.
If we were to change the dist rules, we may want to go in the
opposite direction. Instead of using git archive to make a
temporary copy of a directory from a commit, make such a temporary
copy from the contents of the current working tree (or the index).
And then tar-up a result after adding configure, version etc. to it.
That would mean what will be in the tarball can be different from
even HEAD, which is more consistent with the way how documentation
tarballs are made.
Alternatively, you can update the dist-doc rules to make a temporary
copy of documentation area and generate the documentation tarballs
out of a pristine source of a known version---which would also make
these two consistent. I am not sure which one is more preferrable,
though.
Why are you sharing the .git/HEAD across multiple checkouts in the
first place? If they are to build all different versions, surely
these working trees are derived from different commits, no?
I'm sharing all of .git using explicit GIT_DIR and GIT_WORK_TREE
environment variables, sharing .git/HEAD comes with that. What I'm
actually doing is a continuos integration setup that can run many
actions at once in freshly checked-out work trees, but sharing .git to
save space.
What it specifically doing is running 'make test' for master, next and
pu, and make dist for next. As long as I protect the 'git checkout
$sha1' with a lock, that all works just fine.
Have you considered using contrib/workdir/git-new-workdir, perhaps?
I have not, thanks for the pointer. That approach is definitely cleaner
than what I am currently doing.
I dunno.
With the hint above, I actually don't need this patch anymore. And if
you're not convinced it's a good idea, it's probably better to drop it :)
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a53f3a8..63d9bac 100644
--- a/Makefile
+++ b/Makefile
@@ -2433,7 +2433,7 @@ git.spec: git.spec.in GIT-VERSION-FILE
GIT_TARNAME = git-$(GIT_VERSION)
dist: git.spec git-archive$(X) configure
./git-archive --format=tar \
- --prefix=$(GIT_TARNAME)/ HEAD^{tree} $(GIT_TARNAME).tar
+ --prefix=$(GIT_TARNAME)/ $(GIT_VERSION)^{tree}
$(GIT_TARNAME).tar
@mkdir -p $(GIT_TARNAME)
@cp git.spec configure $(GIT_TARNAME)
@echo $(GIT_VERSION) $(GIT_TARNAME)/version
--
Dennis Kaarsemaker den...@kaarsemaker.net
http://twitter.com/seveas
--
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 REPORT] Git log pretty date
On Mon, Jun 02, 2014 at 11:46:19PM -0400, Jeff King wrote: On Fri, May 30, 2014 at 09:08:57AM +0100, Rodrigo Fernandes wrote: Do you have any idea how does github understand that is a bug and fixes it automatically? (I'm saying this because on Github the date is correct). I looked into this. The dates you see on GitHub's web UI are actually parsed by Rugged/libgit2. The libgit2 parser is slightly more forgiving in this instance; if it sees a broken timezone, it will leave the timestamp intact, and only omit the timezone. Whereas git says no, it's broken, and the timestamp cannot be trusted. I think both are equally valid strategies, and I do not even think it is a problem that they diverge between the two implementations. I'd be OK with a patch to make git handle errors in each independently, assuming it is not too invasive. I think what libgit2 does is more wrong than what git does. It displays the timestamp subtly wrong (off by 7 hours) instead of making it completely clear that the timestamp is bogus. -- Dennis Kaarsemaker den...@kaarsemaker.net http://twitter.com/seveas -- 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 v5 00/28] Support multiple checkouts
On ma, 2014-07-07 at 17:25 +0700, Duy Nguyen wrote: I also have a comment about how it interacts with submodules. Would it be more appropriate to mark modules as a per-checkout directory? Because each of the working tree's submodule is obviously a separated directory in filesystem, and in most cases (at least in my practice) they are checked-out to different revisions. Submodule interaction is something I have avoided so far because I'm not a big user and admittedly does not follow its development closely. I think we could get this in first, then let submodule people aware about this feature and let them decide how to use it. I do intend to use checkout --to and submodule update on the same repository, but have not yet done so. I will poke at that later this month. If you can easily reproduce errors, I would appreciate to know how, because my use of submodules is very limited. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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 v6 00/32] Support multiple checkouts
Tested-by: Dennis Kaarsemaker den...@kaarsemaker.net I've been using this branch for a little while now and have no breakages to report. Max Kirillov reported some bugs in the interaction with submodules which I plan to chase when I have some time unless someone beats me to it :) On wo, 2014-07-09 at 14:32 +0700, Nguyễn Thái Ngọc Duy wrote: This is basically a reroll from what was parked on 'pu' with two new patches at the end: one to not share info/sparse-checkout across worktrees, and one to allow 'checkout --to` from a bare repository. I cherry-picked two patches from jk/xstrfmt (on next) because they result in non-trivial conflicts. When this series is merged with jk/xstrfmt, you still get conflicts in environment.c, but you can just pick up my changes and drop Jeff's. Dennis Kaarsemaker (1): checkout: don't require a work tree when checking out into a new one Jeff King (2): setup_git_env: use git_pathdup instead of xmalloc + sprintf setup_git_env(): introduce git_path_from_env() helper Nguyễn Thái Ngọc Duy (29): path.c: make get_pathname() return strbuf instead of static buffer path.c: make get_pathname() call sites return const char * git_snpath(): retire and replace with strbuf_git_path() path.c: rename vsnpath() to do_git_path() path.c: group git_path(), git_pathdup() and strbuf_git_path() together git_path(): be aware of file relocation in $GIT_DIR *.sh: respect $GIT_INDEX_FILE reflog: avoid constructing .lock path with git_path fast-import: use git_path() for accessing .git dir instead of get_git_dir() commit: use SEQ_DIR instead of hardcoding sequencer $GIT_COMMON_DIR: a new environment variable git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects *.sh: avoid hardcoding $GIT_DIR/hooks/... git-stash: avoid hardcoding $GIT_DIR/logs/ setup.c: convert is_git_directory() to use strbuf setup.c: detect $GIT_COMMON_DIR in is_git_directory() setup.c: convert check_repository_format_gently to use strbuf setup.c: detect $GIT_COMMON_DIR check_repository_format_gently() setup.c: support multi-checkout repo setup wrapper.c: wrapper to open a file, fprintf then close use new wrapper write_file() for simple file writing checkout: support checking out into a new working directory checkout: clean up half-prepared directories in --to mode checkout: detach if the branch is already checked out elsewhere prune: strategies for linked checkouts gc: style change -- no SP before closing bracket gc: support prune --repos count-objects: report unused files in $GIT_DIR/repos/... git_path(): keep info/sparse-checkout per work-tree Documentation/config.txt | 9 ++ Documentation/git-checkout.txt | 34 + Documentation/git-prune.txt| 3 + Documentation/git-rev-parse.txt| 10 ++ Documentation/git.txt | 9 ++ Documentation/gitrepository-layout.txt | 75 -- builtin/branch.c | 4 +- builtin/checkout.c | 248 - builtin/clone.c| 9 +- builtin/commit.c | 2 +- builtin/count-objects.c| 4 +- builtin/fetch.c| 5 +- builtin/fsck.c | 4 +- builtin/gc.c | 21 ++- builtin/init-db.c | 7 +- builtin/prune.c| 74 ++ builtin/receive-pack.c | 2 +- builtin/reflog.c | 2 +- builtin/remote.c | 2 +- builtin/repack.c | 8 +- builtin/rev-parse.c| 11 ++ cache.h| 17 ++- daemon.c | 11 +- environment.c | 45 -- fast-import.c | 7 +- git-am.sh | 22 +-- git-pull.sh| 2 +- git-rebase--interactive.sh | 6 +- git-rebase--merge.sh | 6 +- git-rebase.sh | 4 +- git-sh-setup.sh| 2 +- git-stash.sh | 6 +- git.c | 2 +- notes-merge.c | 6 +- path.c | 234 +-- refs.c | 86 +++- refs.h | 2 +- run-command.c | 4 +- run-command.h | 2 +- setup.c| 124 + sha1_file.c| 2 +- submodule.c| 9 +- t/t0060-path-utils.sh | 35 + t/t1501-worktree.sh
Re: [PATCH] checkout: indicate when a detached head is checked out for a branch
On vr, 2014-07-18 at 10:36 -0700, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: I really like the new --to feature and will convert all my new workdir checkouts to that. But that detached checkout is so easy to miss - in fact I noticed it only when I compared new-workdir to checkout --to for a test repo with one branch, to see what a converter would need to do. I'm even wondering whether we should do this DWIMmery at all, given how dangerous a detached head is for those who are not aware of it before gc kicks in. As long as the amount of warning about 'detached HEAD' is about the same between this case and a git checkout v1.2.3 in a normal repository, I do not think there is no additional danger you need to be worried about. But I do agree that there should not be any DWIM here. The reason to introduce this new set of rather intrusive changes is so that working trees can be aware of branches other working trees have checked out. And the whole point of wanting to have that mutual awareness is to enable us to forbid users from mucking with the same branch from two different places. But Git is not in the position to dictate which alternative action the user would want to take, when her git checkout foo is prevented by this mechanism. In one scenario, she may say I only wanted to take a peek and run git checkout foo^0 instead. In another, she may say Ah, I forgot I already was doing this change in the other one and run cd ../foo. There may be other classes of alternative actions. Don't make it easier for the first class of scenario and make it less useful and more dangerous for the second class, especially the second class involve forgetful users who are likely to forget seeing the we've warned you that we detached without being asked message. Please fix it to always just error out. I really would appreciate it if it wouldn't always error out. Erroring out by default is fine, but please keep it overridable. My use case for this is checking out the same branch (or commit, so already on a detached HEAD) in multiple different places to run independent actions (e.g. make test with different compiler options, or creating several different packages) and I would really appreciate it if that would keep working. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Is there a way to mark a branch as published?
On di, 2014-07-29 at 17:40 -0500, Nico Williams wrote: (or all of a repo's branches) Teamware recorded whether it had any children and warned about rebasing published contents. Perhaps git could do the same. Git doesn't record this directly, but you can see which known remote branches contain the tip of a branch: git branch -a --contains yourbranchnamehere | grep remotes/ That doesn't say anything about remotes you don't know about of course. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 report about symlinks
On wo, 2014-07-30 at 15:30 +0400, NickKolok wrote: Greetings from Russia, comrads! I've noticed something strange with git status when replacing a folder with symlink to another folder. There is a git repo with script with demo in the attachment. I think there is a bug here: + mkdir bug + cd bug + git init Initialized empty Git repository in /tmp/bug/.git/ + mkdir dir1 dir2 + echo 1 + echo 1 + echo 2a + echo 2b + git add dir1/1.txt dir1/2.txt dir2/1.txt dir2/2.txt + git commit -m first [master (root-commit) b60ecc8] first 4 files changed, 4 insertions(+) create mode 100644 dir1/1.txt create mode 100644 dir1/2.txt create mode 100644 dir2/1.txt create mode 100644 dir2/2.txt + rm -r dir2 + ln -s dir1 dir2 + git status On branch master Changes not staged for commit: (use git add/rm file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) deleted:dir2/2.txt Untracked files: (use git add file... to include in what will be committed) dir2 no changes added to commit (use git add and/or git commit -a) It looks like git status is thinking dir2/1.txt still exists with the same content, even though dir2 is gone, and now an untracked symlink. Moreover, git diff and git status disagree with each other: dennis@spirit:/tmp/bug$ git status On branch master Changes not staged for commit: (use git add/rm file... to update what will be committed) (use git checkout -- file... to discard changes in working directory) deleted:dir2/2.txt Untracked files: (use git add file... to include in what will be committed) dir2 no changes added to commit (use git add and/or git commit -a) dennis@spirit:/tmp/bug$ git --no-pager diff diff --git a/dir2/1.txt b/dir2/1.txt deleted file mode 100644 index d00491f..000 --- a/dir2/1.txt +++ /dev/null @@ -1 +0,0 @@ -1 diff --git a/dir2/2.txt b/dir2/2.txt deleted file mode 100644 index b8a4cf4..000 --- a/dir2/2.txt +++ /dev/null @@ -1 +0,0 @@ -2b -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 0/3] nd/multiple-work-trees updates
On do, 2015-02-12 at 14:57 -0800, Junio C Hamano wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: These patches are on top of what's in 'pu'. They add --ignore-other-worktrees and make a note about current submodule support status. I don't think submodule support is ready yet even with Max Kirillov's series [1]. His 03/03 is already fixed in 'pu' though, so only 01/03 and 02/03 are new. [1] http://thread.gmane.org/gmane.comp.version-control.git/261107 With the understanding (perhaps a strongly-worded paragraph in the release notes) that this is not suitable for submodule users yet, is this in a good enough shape to go to 'next'? I've been using this for a while and really like it. However, it needs a few fixups to merge with next as there are a few merge conflicts. (A version of this branch that I stuck on top of next last week can be found at https://github.com/seveas/git/tree/nd/multiple-work-trees ) -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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
'make test' fails in pu
Make test has been failing for 'pu' yesterday for and today at t4016-diff-quote.sh. Full log: http://ci.kaarsemaker.net/git/refs/heads/pu/1df29c71a731c679de9055ae5e407f3a4e18740a/artefact/test/log I noticed this a few times before and it tends to get fixed again relatively quickly. So I'm wondering: - Should I even mention that it's failing, or is that just useless noise? - If I should report this, I could also make my testing thing send mails. Would that be useful? -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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: [RFH] GSoC 2015 application
On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote: The ~/.git-credential-cache may be a bit harder, but the case of ~/.git-credentials should follow the same pattern as files for which this is already done. So, doing it by mimicking existing code shouldn't be too hard. But maybe that's me being optimistic ;-) Having just copied that logic to one of my tools, I reaclly would have fount if useful to have something that, given a config file name tells you where it should be, maybe in the resident kitchen-sink that is rev-parse: $ git rev-parse --config git /home/dennis/.gitconfig $ git rev-parse --config gitk /home/dennis/.gitk $ git rev-parse --config foobar /home/dennis/.foobar Or, when XDG config files are used: $ git rev-parse --config gitk /home/dennis/.config/git/gitk $ git rev-parse --config git /home/dennis/.config/git/config $ git rev-parse --config foobar /home/dennis/.config/git/foobar So, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case only for git itself, with consistent selection of which to use (currently gitk and git are inconsistent). -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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: How to rebase one branch of the merge commit?
On zo, 2015-02-01 at 19:42 +0100, Hans Ginzel wrote: Hello! Suppose following git history: A–M–C / B How to achieve this with commits metadata preserving? A–M'–C' / B' I did git checkout B git add something_not_in_other_commits git commit --amend So I have B'. How to continue, please? My git version is 1.7.1 (Centos 6.5). Assuming you have a branch pointing to C and no uncommitted changes: 1) git checkout branch-that-points-to-c 2) git rev-parse branch-that-point-to-c 3) git reset --hard A 4) git merge B' 5) git cherry-pick sha1-that-was-the-output-of-step-2 -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: FW: Time Date on file
On di, 2015-03-17 at 13:19 -0400, Patrice Monette wrote: I did not find any config, but is there one configuration somewhere to preserve the real date creation by author somewhere? No, there is no such configuration as git does not track timestamps of files. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] clone: Warn if clone lacks LICENSE or COPYING file
On za, 2015-03-21 at 14:06 -0400, David A. Wheeler wrote: Warn cloners if there is no LICENSE* or COPYING* file that makes the license clear. This is a useful warning, because if there is no license somewhere, then local copyright laws (which forbid many uses) and terms of service apply - and the cloner may not be expecting that. Please no, especially not without an option to switch this off. Git is not only used in open source settings, this would be highly annoying at $work, where no repo has (or needs) such a file. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 Newbie - GSoC mini Project
On wo, 2015-03-04 at 11:50 +0530, Prudhvee Narasimha Sadha wrote: I'm a newbie to git. I started working on git. I cloned the git repository and started hacking it. I need a suggestion on how to start working on the micro project Make git -C '' cmd not to barf. git -C '' cmd currently throws an error: $ git -C '' status fatal: Cannot change to '': No such file or directory So the two things you should do are - Determine what the desired behavior would be - Implementing that behavior For the first step, I'd send a mail to this list asking people for input, paying special attention to the responses of the core maintainers and possible GSOC mentors (I'm not one of them, but I think the error is actually the right behavior, I'd prefer git -C $repodir to bomb out if $repodir is unset. On the other hand cd '' is equivalent to not cd'ing at all so there's precedent to change this). For the second step, you'll need to find the bit of code where the -C option is handled and add a special case for the empty string to do what came out of the discussion about wanted behavior. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: [cosmetic bug?] needlessly(?) executable files
On zo, 2015-02-22 at 10:44 -0800, Junio C Hamano wrote: Christoph Anton Mitterer cales...@scientia.net writes: Just a question about files like: .git/config .git/hooks/*.sample Is there any reason that these are created executable? Especially the config file? In a new repository I just did git init, I see this: $ rm -fr stupid $ umask 0027 $ git init stupid $ ls -l stupid/.git/config | sed -e 's/ .*//' -rw-r- So no, config is not created executable. It used to be for a brief period in history, between daa22c6f8d (2.1.0) and 1f32ecf (2.2.2). -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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: support git+mosh for unreliable connections
On wo, 2015-04-15 at 18:37 +0530, Pirate Praveen wrote: Hi, When working with big projects over a slow, unreliable connection, currently there is no way to resume a clone or pull when the connection breaks. mosh is a better replacement for ssh over unreliable connections. supporting git+mosh protocol will go a long way in supporting people who work with unreliable, mobile networks, especially in developed countries (I personally have to try many times when working with large projects as my 3g mobile connection keeps dropping. I recently discovered mosh and it works like a charm. More about mosh https://mosh.mit.edu/ mosh isn't a generic transport though, it's a udp-based session state synchronization protocol. I don't think it can be used as a git transport. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: support git+mosh for unreliable connections
On wo, 2015-04-15 at 19:46 +0200, Johannes Schindelin wrote: On 2015-04-15 17:33, Trevor Saunders wrote: but it certainly does support ssh host command and then doing IO. Yes, in interactive sessions. mosh synchronizes terminal state, it doesn't allow random I/O between client and server. Ah, so mosh's README lied to me! If `mosh user@host command` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it? It does not and cannot work. The way mosh works, is that it uses ssh to log in and launch a mosh-server daemon. This daemon and the mosh client then communicate via a custom UDP protocol. The SSH connection is closed after the mosh-server has been launched as it is no longer needed. The communication between the mosh client and server synchronizes terminal state, somewhat like what screen/tmux do. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
assert failed in submodule edge case
Reported by djanos_ in #git: git add segfaults when you manage to confuse it with a submodule in the index that is no longer a submodule. Here's his script to reproduce the segfault: mkdir segfault cd segfault mkdir subrepo cd subrepo git init . echo a a git add a git commit -m a cd .. git init . git add . cd subrepo rm -rf .git git add . This last git add will now barf: git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. These all work as I think they are intended to: $ git -C segfault add subrepo/a fatal: Pathspec 'subrepo/a' is in submodule 'subrepo' $ git -C segfault/subrepo add a fatal: Pathspec 'a' is in submodule 'subrepo' And this does nothing, it also doesn't crash: $ git -C segfault add subrepo GDB backtrace below, this is with next as of e6f3401. Starting program: /home/dennis/code/git/git -C segfault/subrepo add . [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. Program received signal SIGABRT, Aborted. 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7702c528 in __GI_abort () at abort.c:89 #2 0x77023ce6 in __assert_fail_base (fmt=0x77173c08 %s%s%s:%u: %s%sAssertion `%s' failed.\n%n, assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:92 #3 0x77023d92 in __GI___assert_fail (assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:101 #4 0x004d6a37 in prefix_pathspec (elt=0x7fffdaf1 ., prefixlen=8, prefix=0x7dd09f subrepo/, flags=50, raw=0x7fffd648, p_short_magic=synthetic pointer, item=optimized out) at pathspec.c:316 #5 parse_pathspec (pathspec=pathspec@entry=0x7fffd240, magic_mask=magic_mask@entry=0, flags=flags@entry=50, prefix=prefix@entry=0x7dd09f subrepo/, argv=argv@entry=0x7fffd648) at pathspec.c:417 #6 0x0040698c in cmd_add (argc=optimized out, argv=0x7fffd648, prefix=0x7dd09f subrepo/) at builtin/add.c:370 #7 0x00406001 in run_builtin (argv=0x7fffd640, argc=2, p=0x79d740 commands) at git.c:350 #8 handle_builtin (argc=2, argv=0x7fffd640) at git.c:532 #9 0x00405151 in run_argv (argv=0x7fffd458, argcp=0x7fffd43c) at git.c:578 #10 main (argc=2, av=optimized out) at git.c:686 I dig a bit into pathspec.c and it looks like the PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE code in prefix_pathspec is only stripping out paths inside the submodule, not the submodule itself. I also guess that it shouldn't as otherwise you can't ever 'git add' a submodule. So I have no idea how to proceed, or even what the correct behaviour of 'git add' should be in this case. I do think that failing an assert() to tell a user he's doing something unexpected/silly/wrong isn't the right thing to do though :) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: assert failed in submodule edge case
Err, ignore the 'segfault' bits. It's an assert() failure. He called it a segfault at first and that got stuck in my head. On ma, 2015-04-13 at 18:55 +0200, Dennis Kaarsemaker wrote: Reported by djanos_ in #git: git add segfaults when you manage to confuse it with a submodule in the index that is no longer a submodule. Here's his script to reproduce the segfault: mkdir segfault cd segfault mkdir subrepo cd subrepo git init . echo a a git add a git commit -m a cd .. git init . git add . cd subrepo rm -rf .git git add . This last git add will now barf: git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. These all work as I think they are intended to: $ git -C segfault add subrepo/a fatal: Pathspec 'subrepo/a' is in submodule 'subrepo' $ git -C segfault/subrepo add a fatal: Pathspec 'a' is in submodule 'subrepo' And this does nothing, it also doesn't crash: $ git -C segfault add subrepo GDB backtrace below, this is with next as of e6f3401. Starting program: /home/dennis/code/git/git -C segfault/subrepo add . [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. git: pathspec.c:317: prefix_pathspec: Assertion `item-nowildcard_len = item-len item-prefix = item-len' failed. Program received signal SIGABRT, Aborted. 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7702ae37 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7702c528 in __GI_abort () at abort.c:89 #2 0x77023ce6 in __assert_fail_base (fmt=0x77173c08 %s%s%s:%u: %s%sAssertion `%s' failed.\n%n, assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:92 #3 0x77023d92 in __GI___assert_fail (assertion=assertion@entry=0x560660 item-nowildcard_len = item-len item-prefix = item-len, file=file@entry=0x560826 pathspec.c, line=line@entry=317, function=function@entry=0x560850 __PRETTY_FUNCTION__.22237 prefix_pathspec) at assert.c:101 #4 0x004d6a37 in prefix_pathspec (elt=0x7fffdaf1 ., prefixlen=8, prefix=0x7dd09f subrepo/, flags=50, raw=0x7fffd648, p_short_magic=synthetic pointer, item=optimized out) at pathspec.c:316 #5 parse_pathspec (pathspec=pathspec@entry=0x7fffd240, magic_mask=magic_mask@entry=0, flags=flags@entry=50, prefix=prefix@entry=0x7dd09f subrepo/, argv=argv@entry=0x7fffd648) at pathspec.c:417 #6 0x0040698c in cmd_add (argc=optimized out, argv=0x7fffd648, prefix=0x7dd09f subrepo/) at builtin/add.c:370 #7 0x00406001 in run_builtin (argv=0x7fffd640, argc=2, p=0x79d740 commands) at git.c:350 #8 handle_builtin (argc=2, argv=0x7fffd640) at git.c:532 #9 0x00405151 in run_argv (argv=0x7fffd458, argcp=0x7fffd43c) at git.c:578 #10 main (argc=2, av=optimized out) at git.c:686 I dig a bit into pathspec.c and it looks like the PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE code in prefix_pathspec is only stripping out paths inside the submodule, not the submodule itself. I also guess that it shouldn't as otherwise you can't ever 'git add' a submodule. So I have no idea how to proceed, or even what the correct behaviour of 'git add' should be in this case. I do think that failing an assert() to tell a user he's doing something unexpected/silly/wrong isn't the right thing to do though :) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] pull: handle --log=n
On di, 2015-05-19 at 19:19 -0700, Junio C Hamano wrote: Hopefully now you have some idea how your approach is problematic. Yes, thanks for the thorough explanation! Two more bad sideeffects, so two more reasons not to take this approach: - test_must_fail tests might now fail for the wrong reason, undetectedly (ref does not exist instead of can't handle ref) - same for TODO tests -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Minor bug report
On di, 2015-06-02 at 23:48 -0700, Junio C Hamano wrote: I am kind of surprised after reading these two threads that my take on this issue has changed over time, as my knee-jerk reaction before reading them was the opposite, something along the lines of This is only immediately after 'git init'; why bother?. Or depending on my mood, that How stupid do you have to be... sounds exactly like a message I may advocate for us to send. Perhaps I grew more bitter with age. The fatal: Failed to resolve 'HEAD' as a valid ref. message, closely related to the fatal: bad default revision 'HEAD' message that started this thread just came by in #git with the following situation: $ git init $ git add . # Oops, didn't want to add foo.xyz $ git reset foo.xyz fatal: Failed to resolve 'HEAD' as a valid ref. The solution there is simple, git rm --cached, but I think git could produce more helpful messages when a repo is empty. I think you are growing bitter with age ;) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
incomplete footers added by list server?
Since last friday between 10:39 and 10:50 UTC, mails to git@vger suddenly get an incomplete footer added. Instead of the normal footer: 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 Only the first line is now added, actually making it fairly useless :) -- Dennis Kaarsemaker http://www.kaarsemaker.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: reverse history tree, for faster background clones
On vr, 2015-06-12 at 13:39 +0200, Andres G. Aragoneses wrote: On 12/06/15 13:33, Dennis Kaarsemaker wrote: On vr, 2015-06-12 at 13:26 +0200, Andres G. Aragoneses wrote: AFAIU git stores the contents of a repo as a sequence of patches in the .git metadata folder. It does not, it stores full snapshots of files. In bare repos too? Yes. A bare repo is nothing more than the .git dir of a non-bare repo with the core.bare variable set to True :) 1. `git clone --depth 1` would be way faster, and without the need of on-demand compressing of packfiles in the server side, correct me if I'm wrong? You're wrong due to the misunderstanding of how git works :) Thanks for pointing this out, do you mind giving me a link of some docs where I can correct my knowledge about this? http://git-scm.com/book/en/v2/Git-Internals-Git-Objects should help. 2. `git clone` would be able to allow a fast operation, complete in the background mode that would allow you to download the first snapshot of the repo very quickly, so that the user would be able to start working on his working directory very quickly, while a background job keeps retreiving the history data in the background. This could actually be a good thing, and can be emulated now with git clone --depth=1 and subsequent fetches in the background to deepen the history. I can see some value in clone doing this by itself, first doing a depth=1 fetch, then launching itself into the background, giving you a worktree to play with earlier. You're right, didn't think about the feature that converts a --depth=1 repo to a normal one. Then a patch that would create a --progressive flag (for instance, didn't think of a better name yet) for the `clone` command would actually be trivial to create, I assume, because it would just use `depth=1` and then retrieve the rest of the history in the background, right? A naive implementation that does just clone --depth=1 and then fetch --unshallow would probably not be too hard, no. But whether that would be the 'right' way of implementing it, I wouldn't know. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: reverse history tree, for faster background clones
On vr, 2015-06-12 at 13:26 +0200, Andres G. Aragoneses wrote: AFAIU git stores the contents of a repo as a sequence of patches in the .git metadata folder. It does not, it stores full snapshots of files. [I've cut the example, as it's not how git works] 1. `git clone --depth 1` would be way faster, and without the need of on-demand compressing of packfiles in the server side, correct me if I'm wrong? You're wrong due to the misunderstanding of how git works :) 2. `git clone` would be able to allow a fast operation, complete in the background mode that would allow you to download the first snapshot of the repo very quickly, so that the user would be able to start working on his working directory very quickly, while a background job keeps retreiving the history data in the background. This could actually be a good thing, and can be emulated now with git clone --depth=1 and subsequent fetches in the background to deepen the history. I can see some value in clone doing this by itself, first doing a depth=1 fetch, then launching itself into the background, giving you a worktree to play with earlier. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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
[Bug] incomplete defence agains creating a branch named HEAD
So git branch doesn't like to create a branch named HEAD $ git branch HEAD fatal: it does not make sense to create 'HEAD' manually But, you can trick it into doing so anyway: $ git branch @ $ git branch -a HEAD * master At which point git status becomes a bit confused: $ git status warning: refname 'HEAD' is ambiguous. warning: refname 'HEAD' is ambiguous. On branch master nothing to commit, working directory clean Oh, and git checkout will accept either HEAD or @ to create a branch with the name HEAD anyway: $ git checkout -b HEAD Switched to a new branch 'HEAD' $ git checkout -b @ Switched to a new branch 'HEAD' imho none of these should create a branch named HEAD, but should do what 'git branch HEAD' does and fail with a sensible error message. All these shenanigans came up when trying to help an user who is mirroring a mercurial repo that has a branch named '@'. Whether or not git should allow branches named '@' I don't have an opinion on, I know '@' is pretty special when dealing with refs. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 branch -v output ambiguous for parser
On do, 2015-07-23 at 15:29 +0200, Thibault Kruse wrote: Hi, trying to write a git wrapper, I wanted to parse the output of git branch -v The output of git branch is not meant to be machine-parsed. Try using git for-each-ref :) -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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-gui is still using old-style git-merge invocation
On do, 2015-10-29 at 18:50 +0100, Johannes Sixt wrote: > Performing a merge with git gui presents the following message in the > merge result window: > > warning: old-style 'git merge HEAD ' is deprecated. > Merge made by the 'recursive' strategy. > a | 1 + > 1 file changed, 1 insertion(+) > create mode 100644 a > > But I am unable to find where the invocation happens. Can somebody > help? git-gui/lib/merge.tcl, method _start The command is constructed on lines 115-120 (master as of today, 37023ba3) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] t5813: avoid creating urls that break on cygwin
The fake ssh used by this test simply strips ssh://host from the url, leaving paths behind that start with //, which cygwin interprets as UNC paths, causing the test to fail. We may want to actually fix this in git itself, making it remove extra slashes from urls before feeding them to transports or helpers, but that's for another topic as it could cause regressions. Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net> --- t/t5813-proto-disable-ssh.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5813-proto-disable-ssh.sh b/t/t5813-proto-disable-ssh.sh index ad877d7..a954ead 100755 --- a/t/t5813-proto-disable-ssh.sh +++ b/t/t5813-proto-disable-ssh.sh @@ -14,7 +14,7 @@ test_expect_success 'setup repository to clone' ' ' test_proto "host:path" ssh "remote:repo.git" -test_proto "ssh://" ssh "ssh://remote/$PWD/remote/repo.git" -test_proto "git+ssh://" ssh "git+ssh://remote/$PWD/remote/repo.git" +test_proto "ssh://" ssh "ssh://remote$PWD/remote/repo.git" +test_proto "git+ssh://" ssh "git+ssh://remote$PWD/remote/repo.git" test_done -- 2.6.3-495-gf0a7f49 -- Dennis Kaarsemaker <den...@kaarsemaker.net> http://twitter.com/seveas -- 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] t5813: avoid creating urls that break on cygwin
When passed an ssh:// url, git strips ssh://host from the url but does not remove leading slashes from the path. So when this test used ssh://remote//path/to/pwd, the path accessed by our fake SSH is //path/to/pwd, which cygwin interprets as a UNC path, causing the test to fail. We may want to actually fix this in git itself, making it remove extra slashes from urls before feeding them to transports or helpers, but that's for another topic as it could cause regressions. Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net> --- You're right of course. Somehow I remembered that the fake ssh was doing the stripping, but didn't check that when writing the commit message. How about this version? t/t5813-proto-disable-ssh.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5813-proto-disable-ssh.sh b/t/t5813-proto-disable-ssh.sh index ad877d7..a954ead 100755 --- a/t/t5813-proto-disable-ssh.sh +++ b/t/t5813-proto-disable-ssh.sh @@ -14,7 +14,7 @@ test_expect_success 'setup repository to clone' ' ' test_proto "host:path" ssh "remote:repo.git" -test_proto "ssh://" ssh "ssh://remote/$PWD/remote/repo.git" -test_proto "git+ssh://" ssh "git+ssh://remote/$PWD/remote/repo.git" +test_proto "ssh://" ssh "ssh://remote$PWD/remote/repo.git" +test_proto "git+ssh://" ssh "git+ssh://remote$PWD/remote/repo.git" test_done -- 2.6.3-495-gf0a7f49 -- Dennis Kaarsemaker <den...@kaarsemaker.net> http://twitter.com/seveas -- 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] check-ignore: correct documentation about output
By default git check-ignore shows only the filenames that will be ignored, not the pattern that causes their exclusion. Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net> --- Documentation/git-check-ignore.txt | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/Documentation/git-check-ignore.txt b/Documentation/git-check-ignore.txt index 59531ab..0a628ac 100644 --- a/Documentation/git-check-ignore.txt +++ b/Documentation/git-check-ignore.txt @@ -16,10 +16,9 @@ DESCRIPTION --- For each pathname given via the command-line or from a file via -`--stdin`, show the pattern from .gitignore (or other input files to -the exclude mechanism) that decides if the pathname is excluded or -included. Later patterns within a file take precedence over earlier -ones. +`--stdin`, check whether the file is excluded by .gitignore (or other +input files to the exclude mechanism) and output the path if it is +excluded. By default, tracked files are not shown at all since they are not subject to exclude rules; but see `--no-index'. -- 2.6.3-495-gf0a7f49 -- Dennis Kaarsemaker <den...@kaarsemaker.net> http://twitter.com/seveas -- 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: gitk fails to start after upgrading to 2.6.3 (cannot load translation)
On di, 2015-11-10 at 10:48 +0100, Peter Krefting wrote: > Hi! > > After upgrading Git to 2.6.3 (from 2.5.0), gitk refuses to start when > trying to load the Swedish translation if I pass it a commit range: Hi Peter, This bug has been reported a few times already and a fix will be in git 2.7. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] check-ignore: correct documentation about output
Ping. On zo, 2015-11-08 at 21:10 +0100, Dennis Kaarsemaker wrote: > By default git check-ignore shows only the filenames that will be > ignored, not the pattern that causes their exclusion. > > Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net> > --- > Documentation/git-check-ignore.txt | 7 +++ > 1 file changed, 3 insertions(+), 4 deletions(-) > > diff --git a/Documentation/git-check-ignore.txt b/Documentation/git > -check-ignore.txt > index 59531ab..0a628ac 100644 > --- a/Documentation/git-check-ignore.txt > +++ b/Documentation/git-check-ignore.txt > @@ -16,10 +16,9 @@ DESCRIPTION > --- > > For each pathname given via the command-line or from a file via > -`--stdin`, show the pattern from .gitignore (or other input files to > -the exclude mechanism) that decides if the pathname is excluded or > -included. Later patterns within a file take precedence over earlier > -ones. > +`--stdin`, check whether the file is excluded by .gitignore (or > other > +input files to the exclude mechanism) and output the path if it is > +excluded. > > By default, tracked files are not shown at all since they are not > subject to exclude rules; but see `--no-index'. > -- > 2.6.3-495-gf0a7f49 > > -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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: how to check for uncommitted/unstaged changes on remote side before pushing
On zo, 2015-11-08 at 22:23 +0100, Marc Haber wrote: > Hi, > > I am trying to abuse git as a code distribution channel and would > like > to be able to trigger redistribution just by git push. [insert obligatory remark about git not being a deployment tool] > The idea is to push to a remote to the branch that is currently > checked out followed by a git reset --hard in the post-receive hook. > I > have already figured out that I need to set receive.denyCurrentBranch > to ignore to be able to push to the currently checked out branch. You'll need a new enough git, so you can set it to updateInstead (and maybe use a push-to-checkout hook). > I am also aware that it is a good idea to git pull before git push > just in case there were local commits on the remote. No, hooks should never pull, merge or do anything that could be interactive. > git reset --hard will unconditionally throw away local uncommitted > changes. I would like to detect this situation on the remote and > abort > the receive progress. But my pre-receive hook does not work as > intended. Here is my code: > > [snip code] > > What is going wrong here? You mention a post-receive hook first, but have written a pre-receive hook. Not sure if that's what you intended (or even if that's what's going wrong). > If my entire approach is wrong, what is the recommended way to > prevent a repository with unstaged or uncommitted changes from being > pushed to? Push-to-checkout is a very simplistic way of deploying and while it works in simple cases, I'd not recommend it. Two safer/saner approaches are: - Have a separate non-bare repo, and make the post-receive hook in a bare repo trigger a fetch+reset in the non-bare one - Use git archive and symlink trickery for even better deploys Questions like this come up in #git all the time, so I wrote up a few more detailed recipes here, including working hooks and config for all three ways of deploying: http://git.seveas.net/simple-deployments-with-git.html -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: how to check for uncommitted/unstaged changes on remote side before pushing
On ma, 2015-11-09 at 10:31 +0100, Marc Haber wrote: > Abusing git here has the advantage that one can save local changes > and merge them, which is handy for the task at hand (which is > deploying my dotfiles to "my" servers). For this I really like vcsh (https://github.com/RichiH/vcsh/) in combination with a .bashrc.d snippet that updates dotfiles upon login when possible ( https://github.com/seveas/dotfiles/blob/master/.bashrc.d/vcsh.sh) -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: t5813 failing on Cygwin
On za, 2015-11-07 at 19:20 +, Adam Dinwoodie wrote: > On Sat, Nov 07, 2015 at 01:45:27PM -0500, Jeff King wrote: > > On Sat, Nov 07, 2015 at 12:11:29PM +, Adam Dinwoodie wrote: > > > > > Specifically, I'm seeing t5813 subtests 9-13 and 15-19 failing. > > > This happens > > > with a clean build straight from the Git source tree (git clean > > > -dfx && make > > > configure && ./configure && make && cd t && ./t5813-proto-disable > > > -ssh.sh) as > > > well as builds using the Cygwin packaging paraphernalia. > > > > What does the output of "./t5813-proto-disable-ssh.sh -v -i" show? > > > > It seems strange that it would fail only on Cygwin; this code > > doesn't > > really use any platform-dependent features. It's also weird that it > > fails _only_ for ssh, and _only_ on the tests that are using > > "ssh://" > > URLs are not "host:path" syntax. > > Ah! I thought I'd checked that already, but looking at the output > now I > can see what's going wrong. Cutting down to the relevant error: > > ssh: remote git-upload-pack '//home/Adam/vcs/Cygwin-Git/git-2.6.2 > -1.x86_64/build/t/trash directory.t5813-proto-disable > -ssh/remote/repo.git' fatal: '//home/Adam/vcs/Cygwin-Git/git-2.6.2 > -1.x86_64/build/t/trash directory.t5813-proto-disable > -ssh/remote/repo.git' does not appear to be a git repository > > Note the '//' at the start of the path -- on most *nix systems '//' > is > effectively identical to '/'. On Cygwin, however, '//' is used to > access Windows UNC paths: what Windows calls "\\server\share", Cygwin > calls "//server/share". If you replace the '//' with '/' you get the > locatoin of the repository; but here Cygwin is looking for the > repository in a share called "Adam" on a network server called > "home"... > > I suspect the correct fix here is to fix whatever's causing Git to > generate a path with that '//'. If nobody else gets to it soon > (probably on the order of a week before I'll get the chance), I'll go > code diving and submit a patch. > > > I tried building on Linux with the Cygwin build knobs found in > > config.mak.uname, but I couldn't get it to fail. I also wondered if > > the > > test was doing something with the shell that might not be portable, > > but > > I don't see anything interesting. > > If I recall correctly, the correct interpretation of '//' isn't > defined > in POSIX, so whatever's causing that path to be generated is the bit > that's not fully portable. It looks as though t5813 throwing this up > is > just a coincidence rather than it being particularly related to the > function those tests are actually testing. Looks like lib-proto-disable.sh's fake SSH doesn't strip double leading /'es from the path. Try this patch: diff --git a/t/t5813-proto-disable-ssh.sh b/t/t5813-proto-disable -ssh.sh index ad877d7..a954ead 100755 --- a/t/t5813-proto-disable-ssh.sh +++ b/t/t5813-proto-disable-ssh.sh @@ -14,7 +14,7 @@ test_expect_success 'setup repository to clone' ' ' test_proto "host:path" ssh "remote:repo.git" -test_proto "ssh://" ssh "ssh://remote/$PWD/remote/repo.git" -test_proto "git+ssh://" ssh "git+ssh://remote/$PWD/remote/repo.git" +test_proto "ssh://" ssh "ssh://remote$PWD/remote/repo.git" +test_proto "git+ssh://" ssh "git+ssh://remote$PWD/remote/repo.git" test_done -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: t5813 failing on Cygwin
On za, 2015-11-07 at 23:05 +, Ramsay Jones wrote: > > On 07/11/15 21:21, Ramsay Jones wrote: > > > > > > On 07/11/15 21:02, Dennis Kaarsemaker wrote: > > > On za, 2015-11-07 at 19:20 +, Adam Dinwoodie wrote: > > > > On Sat, Nov 07, 2015 at 01:45:27PM -0500, Jeff King wrote: > > > > > On Sat, Nov 07, 2015 at 12:11:29PM +, Adam Dinwoodie > > > > > wrote: > > > > > > > > > > > Specifically, I'm seeing t5813 subtests 9-13 and 15-19 > > > > > > failing. > > > > > > This happens > > > > > > with a clean build straight from the Git source tree (git > > > > > > clean > > > > > > -dfx && make > > > > > > configure && ./configure && make && cd t && ./t5813-proto > > > > > > -disable > > > > > > -ssh.sh) as > > > > > > well as builds using the Cygwin packaging paraphernalia. > > > > > > > > > > What does the output of "./t5813-proto-disable-ssh.sh -v -i" > > > > > show? > > > > > > > > > > It seems strange that it would fail only on Cygwin; this code > > > > > doesn't > > > > > really use any platform-dependent features. It's also weird > > > > > that it > > > > > fails _only_ for ssh, and _only_ on the tests that are using > > > > > "ssh://" > > > > > URLs are not "host:path" syntax. > > > > > > > > Ah! I thought I'd checked that already, but looking at the > > > > output > > > > now I > > > > can see what's going wrong. Cutting down to the relevant > > > > error: > > > > > > > > ssh: remote git-upload-pack '//home/Adam/vcs/Cygwin-Git/git > > > > -2.6.2 > > > > -1.x86_64/build/t/trash directory.t5813-proto-disable > > > > -ssh/remote/repo.git' fatal: '//home/Adam/vcs/Cygwin-Git/git > > > > -2.6.2 > > > > -1.x86_64/build/t/trash directory.t5813-proto-disable > > > > -ssh/remote/repo.git' does not appear to be a git repository > > > > > > > > Note the '//' at the start of the path -- on most *nix systems > > > > '//' > > > > is > > > > effectively identical to '/'. On Cygwin, however, '//' is used > > > > to > > > > access Windows UNC paths: what Windows calls "\\server\share", > > > > Cygwin > > > > calls "//server/share". If you replace the '//' with '/' you > > > > get the > > > > locatoin of the repository; but here Cygwin is looking for the > > > > repository in a share called "Adam" on a network server called > > > > "home"... > > > > > > > > I suspect the correct fix here is to fix whatever's causing Git > > > > to > > > > generate a path with that '//'. If nobody else gets to it soon > > > > (probably on the order of a week before I'll get the chance), > > > > I'll go > > > > code diving and submit a patch. > > > > > > > > > I tried building on Linux with the Cygwin build knobs found > > > > > in > > > > > config.mak.uname, but I couldn't get it to fail. I also > > > > > wondered if > > > > > the > > > > > test was doing something with the shell that might not be > > > > > portable, > > > > > but > > > > > I don't see anything interesting. > > > > > > > > If I recall correctly, the correct interpretation of '//' isn't > > > > defined > > > > in POSIX, so whatever's causing that path to be generated is > > > > the bit > > > > that's not fully portable. It looks as though t5813 throwing > > > > this up > > > > is > > > > just a coincidence rather than it being particularly related to > > > > the > > > > function those tests are actually testing. > > > > > > Looks like lib-proto-disable.sh's fake SSH doesn't strip double > > > leading > > > /'es from the path. Try this patch: > > > > > > diff --git a/t/t5813-proto-disable-ssh.sh b/t/t5813-proto-disable > > > -ssh.sh > > > index ad877d7..a954ead 100755 > > > --- a/t/t5813-proto-disable-ssh.sh > > > +++ b/t/t5813-proto-disable-ssh
[PATCH] git-p4: import the ctypes module
The ctypes module is used on windows to calculate free disk space, so it must be imported. Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net> --- git-p4.py | 1 + 1 file changed, 1 insertion(+) On di, 2015-10-20 at 09:00 -0700, Junio C Hamano wrote: > Luke Diamand <l...@diamand.org> writes: > > > On 20 October 2015 at 11:34, Etienne Girard < > > etienne.g.gir...@gmail.com> wrote: > > > Hello, > > > > > > Git-p4 fail when I try to rebase with the error: "NameError: > > > global > > > name 'ctypes' is not defined". The error occurs when I use python > > > 2.7.2 that is installed by default on my company's computers (it > > > goes > > > without saying that everything works fine with python 2.7.10). > > > > > > I'm a beginner in python, but simply importing ctypes at the > > > beginning > > > of the script does the trick. I was wondering if submitting a > > > patch > > > for this issue is worth the trouble, when a satisfying solution > > > is not > > > using a 4 years old version of python. > > > > If you're able to submit a patch that would be great! > > Lars's (git-p4: check free space during streaming, > 2015-09-26) introduced two references to ctypes.* and there is no > 'import ctypes' anywhere in the script. > > I do not follow Python development, but does the above mean that > with recent 2.x you can say ctypes without first saying "import > ctypes"? It feels somewhat non-pythonesque that identifiers like > this is given to you without you asking with an explicit 'import', > so I am puzzled. No, you cannot do that. The reason others may not have noticed this bug is that in git-p4.py, ctypes is only used on windows. 111 if platform.system() == 'Windows': 112 free_bytes = ctypes.c_ulonglong(0) 113 ctypes.windll.kernel32.GetDiskFreeSpaceExW(ctypes.c_wchar_p(os.getcwd()), None, None, ctypes.pointer(free_bytes)) The fact that it works for the OP with 2.7.10 is puzzling (assuming that it's on the same system). But this patch should help. diff --git a/git-p4.py b/git-p4.py index daa60c6..212ef2b 100755 --- a/git-p4.py +++ b/git-p4.py @@ -24,6 +24,7 @@ import shutil import stat import zipfile import zlib +import ctypes try: from subprocess import CalledProcessError -- 2.6.2-323-g60bd420 -- 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
Reset sometimes updates mtime
I'm seeing some behaviour with git reset that I find odd. Basically if I do git fetch \ git reset --hard simple-tag-that-points-to-the-current-commit sometimes the reset will update the mtime of all files and directories in the repo and sometimes it will leave them alone. Changing it to git fetch \ git status \ git reset --hard simple-tag-that-points-to-the-current-commit Cause the mtime update to reliably not happen. Bad thing is that I am relying on the mtime updates not to happen if the files don't actually change. Is this an assumption I can safely make? If it is, then I'll debug further (e.g. I don't even know yet if the file gets rewritten or just touched, why the index gets updated as well etc.). -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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: Reset sometimes updates mtime
On do, 2015-07-09 at 10:56 -0700, Junio C Hamano wrote: Dennis Kaarsemaker den...@kaarsemaker.net writes: I'm seeing some behaviour with git reset that I find odd. Basically if I do git fetch \ git reset --hard simple-tag-that-points-to-the-current-commit sometimes the reset will update the mtime of all files and directories in the repo and sometimes it will leave them alone. Changing it to git fetch \ git status \ git reset --hard simple-tag-that-points-to-the-current-commit Cause the mtime update to reliably not happen. If my theory on what is happening is correct, I do not think there is any bug in what reset --hard is doing. My theory is that something is causing the stat info that is cached in your index and the lstat(2) return you get from your working tree files go out of sync. Even though you are not actively touching any working tree files (otherwise, you wouldn't be complaining about mtime changing in the first place), perhaps your build of Git records timestamps in NS but your filesystem and the operating system does not preserve nanosecond resolution of timestamps when it evicts inode data from the core, or something like that? If that is what is happening, I think that fetch is a red herring, but any operation that takes some time and/or hits filesystem reasonably hard would trigger it. And the reason why I say there is no bug in what reset --hard is doing here, if the above theory is correct, is because: - The user asked reset --hard to make sure that my working tree files are identical to those of HEAD; - reset --hard looks at lstat(2) return and the cached stat info in the index and find them not to match. It can do one of two things: (1) see if the user did something stupid, like touch file, that modifies only lstat(2) info without actually changing its contents, by reading from the working tree, reading HEAD:file from the object database, and comparing them, and overwrite the working tree file only when they do not match. or (2) the contents might happen to be the same, but the end result user desires to have is that the contents of the working tree file is the same as that from the HEAD, so overwrite it without wasting time reading two and compare before doing so. and it is perfectly reasonable to do the latter. After all, the whole point of having its cached lstat(2) data in the index is to so that we do not have to always compare the contents before deciding something has changed in the working tree. Running git update-index --refresh immediately before reset may alleviate the issue. git status has the same effect, only because it does update-index --refresh at the beginning of its processing, but it wastes a lot more time and resource doing other things. But unless/until you know _why_ the cached stat info in your index goes stale relative to what lstat(2) tells you, it would not solve it, because that magical thing (and my theory is cached data in your operating system that keeps a file timestamp with more precision than your underlying filesystem can represent is being flushed, and reading the file timestamp back from the disk has to truncate the nanoseconds part) can happen at any time between the --refresh and your reset. Thanks Junio! If I understand you correctly, reset should not touch files if it thinks they are up-to-date, so at least that assumption is safe to make. I'll test your theory about why reset thinks all the files are outdated. I did notice 'fetch' updates the index (well, mtime of .git/index changes, I didn't look at index content yet), so maybe fetch isn't quite a red herring. I'll try to eliminate this variable as well. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 43/43] refs: tests for db backend
On Mon, Sep 28, 2015 at 06:02:18PM -0400, David Turner wrote:
> Add tests for the database backend.
>
> Signed-off-by: David Turner <dtur...@twopensource.com>
> ---
> t/t1460-refs-be-db.sh| 1103
> ++
> t/t1470-refs-be-db-reflog.sh | 353 ++
> 2 files changed, 1456 insertions(+)
> create mode 100755 t/t1460-refs-be-db.sh
> create mode 100755 t/t1470-refs-be-db-reflog.sh
These break 'make test' on builds without the db backend. Maybe squash
in something like the following:
diff --git a/t/t1460-refs-be-db.sh b/t/t1460-refs-be-db.sh
index f13b0f0..c8222ed 100755
--- a/t/t1460-refs-be-db.sh
+++ b/t/t1460-refs-be-db.sh
@@ -9,6 +9,11 @@ test_description='Test lmdb refs backend'
TEST_NO_CREATE_REPO=1
. ./test-lib.sh
+if ! test -e ../../test-refs-be-lmdb; then
+ skip_all="Skipping lmdb refs backend tests, lmdb backend not built"
+ test_done
+fi
+
raw_ref() {
test-refs-be-lmdb "$1"
}
diff --git a/t/t1470-refs-be-db-reflog.sh b/t/t1470-refs-be-db-reflog.sh
index 99a705d..2538a58 100755
--- a/t/t1470-refs-be-db-reflog.sh
+++ b/t/t1470-refs-be-db-reflog.sh
@@ -8,6 +8,11 @@ test_description='Test prune and reflog expiration'
TEST_NO_CREATE_REPO=1
. ./test-lib.sh
+if ! test -e ../../test-refs-be-lmdb; then
+ skip_all="Skipping lmdb refs backend tests, lmdb backend not built"
+ test_done
+fi
+
raw_reflog() {
cat .git/logs/$1 2>/dev/null || test-refs-be-lmdb -l "$1"
}
Also, test 18 in t1460 is broken:
expecting success:
git symbolic-ref refs/heads/self refs/heads/self &&
test_when_finished "delete_ref refs/heads/self" &&
test_must_fail git update-ref -d refs/heads/self
test_must_fail: command succeeded: git update-ref -d refs/heads/self
not ok 18 - update-ref -d is not confused by self-reference
#
# git symbolic-ref refs/heads/self refs/heads/self &&
# test_when_finished "delete_ref refs/heads/self" &&
# test_must_fail git update-ref -d refs/heads/self
#
--
Dennis Kaarsemaker <den...@kaarsemaker.net>
http://twitter.com/seveas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v1] Add Travis CI support
On za, 2015-10-03 at 18:37 -0700, Junio C Hamano wrote: > If somebody says "I've been maintaining a clone of git/git with > Travis webhooks enabled and as the result caught this many glitches > during the past two months without any ill side effect. I've been maintaining a clone of git/git with a different ci system enabled, and it hasn't really caught anything. Only the occasional test failure in pu like the one I mailed about yesterday. The automated testing of pull requests could be useful, but pull requests don't seem to be used much yet. -- Dennis Kaarsemaker www.kaarsemaker.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v1] Add Travis CI support
On zo, 2015-10-04 at 10:46 -0700, Junio C Hamano wrote: > One final question. Which configuration file does the CI use when > running a PR-initiated test? The one already in the repository > i.e. the target of the proposed pull, or the one that is possibly > updated by the PR? > > I am wondering if that can be an avenue for a possible mischief. The latter. And it can, as it can enable notifications. -- Dennis Kaarsemaker www.kaarsemaker.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v1] Add Travis CI support
On do, 2015-09-24 at 17:41 -0700, Junio C Hamano wrote: > larsxschnei...@gmail.com writes: > > > My idea is that the owner of "https://github.com/git/git; enables this > > account > > for Travis (it's free!). Then we would automatically get the test state for > > all > > official branches. > > The last time I heard about this "it's free" thing, I thought I > heard that it wants write access to the repository. It does not need write access to the git data, only to auxiliary GitHub data: commit status and deployment status (where it can put "this commit failed tests"), repository hooks (to set up build triggers), team membership (ro) and email addresses (ro). -- Dennis Kaarsemaker www.kaarsemaker.net -- 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
Push --follow tags does not agree with its documentation
When deleting an annotated tag with git push -d while having push.follwTags set to true, causes push to push other annotated tags. I was surprised by this as this does not agree with the documentation Push all the refs that would be pushed without this option, and also push annotated tags in refs/tags that are missing from the remote but are pointing at commit-ish that are reachable from the refs being pushed. This can also be specified with configuration variable push.followTags. For more information, see push.followTags in git-config(1). Note also that the tag pushed in error is not even reachable from the tag that's being deleted. $ git config push.followTags true $ git push origin --delete v2.5.1 To /tmp/whelk.git/ - [deleted] v2.5.1 $ git push origin --delete 2.5 Counting objects: 1, done. Writing objects: 100% (1/1), 166 bytes | 0 bytes/s, done. Total 1 (delta 0), reused 1 (delta 0) To /tmp/whelk.git/ - [deleted] 2.5 * [new tag] v2.5.1 -> v2.5.1 Which one is correct in this case, the behaviour or the documentation? -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Corruption of branch?
On ma, 2015-12-14 at 14:59 -0500, Thomas Nyberg wrote: > I'm guessing you're looking for namecollisions of some kind? I was thinking the same. Can you share the (sanitised) output of git for-each-ref? -- Dennis Kaarsemaker www.kaarsemaker.net -- 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: Corruption of branch?
On ma, 2015-12-14 at 15:33 -0500, Thomas Nyberg wrote: > What exactly are you looking for? Here's the results of the following > command: > > $ git for-each-ref | grep frus > 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit > refs/heads/frus_body_cleaning > 3a1dbe48299f6eda1cc4b69cab35284c0f0355eb commit refs/remotes/o > rigin/frus > 1750cba5a94b3fe6041aaf49de430a558a3b9bc8 commit > refs/remotes/origin/frus_body_cleaning > > Sorry if this isn't what you're looking for. I'm actually not very > familiar with these different internal git commands... This is what I was looking for. Unfortunately it doesn't show any of the smoking guns I had hoped for. That leaves only one option: you also have a file or directory named 'frus' in the root of your repository. In this case 'git checkout frus' does the same as 'git checkout -- frus' instead of DWIM'ing 'git checkout frus' to 'git checkout -b frus origin/frus' -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] Add a test for subtree rebase that loses commits
On di, 2016-01-05 at 09:47 +0100, Torsten Bögershausen wrote: > Need to drop > David Greene <gree...@obbligato.org> > from List, no MX record seahawk:~$ dig MX obbligato.org obbligato.org. 1800IN MX 10 mail.obbligato.org. seahawk:~$ dig mail.obbligato.org mail.obbligato.org. 1800IN CNAME obbligato .org. obbligato.org. 1800IN A 173.255.19 9.253 So it has an MX record, it's just incorrect: MX records must not point to things that are CNAMEs. -- Dennis Kaarsemaker http://www.kaarsemaker.net -- 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] reflog-walk: don't segfault on non-commit sha1's in the reflog
On wo, 2015-12-30 at 16:02 -0800, Junio C Hamano wrote:
> Dennis Kaarsemaker <den...@kaarsemaker.net> writes:
>
> > diff --git a/reflog-walk.c b/reflog-walk.c
> > index 85b8a54..0ebd1da 100644
> > --- a/reflog-walk.c
> > +++ b/reflog-walk.c
> > @@ -221,6 +221,7 @@ void fake_reflog_parent(struct reflog_walk_info
> > *info, struct commit *commit)
> > struct commit_info *commit_info =
> > get_commit_info(commit, >reflogs, 0);
> > struct commit_reflog *commit_reflog;
> > + struct object *logobj;
>
> This thing is not initialized...
>
> > struct reflog_info *reflog;
> >
> > info->last_commit_reflog = NULL;
> > @@ -232,15 +233,20 @@ void fake_reflog_parent(struct
> > reflog_walk_info *info, struct commit *commit)
> > commit->parents = NULL;
> > return;
> > }
> > -
> > - reflog = _reflog->reflogs->items[commit_reflog
> > ->recno];
> > info->last_commit_reflog = commit_reflog;
> > - commit_reflog->recno--;
> > - commit_info->commit = (struct commit *)parse_object(reflog
> > ->osha1);
> > - if (!commit_info->commit) {
> > +
> > + do {
> > + reflog = _reflog->reflogs
> > ->items[commit_reflog->recno];
> > + commit_reflog->recno--;
> > + logobj = parse_object(reflog->osha1);
> > + } while (commit_reflog->recno && (logobj && logobj->type
> > != OBJ_COMMIT));
>
> But this loop runs at least once, so logobj will always have some
> sane value when the loop exits.
>
> > + if (!logobj || logobj->type != OBJ_COMMIT) {
>
> And the only case where this should trigger is when we ran out of
> recno. Am I reading the updated code correctly?
Yes, your description matches what I tried to implement.
> With the updated code, the number of times we return from this
> function is different from the number initially set to recno. I had
> to wonder if the caller cares and misbehaves, but the caller does
> not know how long the reflog is before starting to call
> get_revision() in a loop anyway, so it already has to deal with a
> case where it did .recno=20 and get_revision() did not return that
> many times. So this probably is safe.
That corresponds to what I see when experimenting with different
reflogs.
> > +test_expect_success 'reflog containing non-commit sha1s displays
> > properly' '
>
> In general, "properly" is a poor word to use in test description (or
> a commit log message or a bug report, for that matter), as the whole
> point of a test is to precisely define what is "proper".
>
> And the code change declares that a proper thing to do is to omit
> non-commit entries without segfaulting, so something like
>
> s/displays properly/omits them/
>
> perhaps?
I did find the test title a bit iffy but couldn't really figure out
why. What you're saying makes a lot of sense, will fix.
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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: Can not 'git add file'
On zo, 2016-01-03 at 16:53 +0200, KES wrote: > Untracked files: > (use "git add ..." to include in what will be committed) > > 4 ../lib/Devel/DebugHooks/ > > $ git add -p ../lib/Devel/DebugHooks/Commands.pm > No changes. > > I want to start track file here, but I do not want to stage while > file. > > It seems the git can not process this case and do not allow me to > complete that. Correct, add -p for a new file is not supported, as it doesn't really make sense. There's no patch, it's a whole new file. What you can do instead is first git add -N ../lib/Devel/DebugHooks/Commands.pm to mark the file as tracked without adding content. Then git add -p will allow you to add the contents partially.-- Dennis Kaarsemaker www.kaarsemaker.net -- 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] reflog-walk: don't segfault on non-commit sha1's in the reflog
On di, 2016-01-05 at 20:52 -0500, Eric Sunshine wrote:
> On Tue, Jan 5, 2016 at 8:28 PM, Eric Sunshine <
> sunsh...@sunshineco.com> wrote:
> > On Tue, Jan 5, 2016 at 8:20 PM, Dennis Kaarsemaker
> > <den...@kaarsemaker.net> wrote:
> > > On di, 2016-01-05 at 20:05 -0500, Eric Sunshine wrote:
> > > > Hmm, this test is successful for me on OS X even without the
> > > > reflog-walk.c changes applied.
> > > >
> > > > And this test actually fails (inversely) because it's expecting
> > > > a
> > > > failure, but doesn't get one since the command produces the
> > > > expected
> > > > output.
> > >
> > > That's... surprising to say the least. What's the content of
> > > 'actual',
> > > and which git.git commit are you on?
> >
> > % cat t/trash\ directory.t1410-reflog/actual
> > b60a214 refs/tests/tree-in-reflog@{0}: Restoring to commit
> > 140c527 refs/tests/tree-in-reflog@{1}: Forcing tree
> > b60a214 refs/tests/tree-in-reflog@{2}: Creating ref
> > %
> >
> > This is with only the t/t1410-reflog.sh changes from your patch
> > applied atop current 'master' (SHA1 7548842).
>
> By the way, the segfault does occur for me on Linux and FreeBSD.
>
> And, in all cases, on all tested platforms, with the full patch
> applied, both tests behave sanely (in the expected fashion). So, even
> though the crash doesn't manifest everywhere, the fact that the tests
> are meaningfully testing it on the "affected" platforms may mean that
> it's not worth worrying about why it doesn't segfault on OS X.
>
> (Of course, practicality aside, one might want to satisfy one's
> intellectual curiosity about why it behaves differently on OS X.)
The only explanation I can think of (and that's with practically no
knowledge of OS X internals) is that OS X's memory allocation strategy
is unlucky. Git is definitely writing to a location it should not write
to. On linux and freebsd this is unallocated memory, so you get a
segfault. On OS X, it happens to be memory actually allocated by git,
resulting not in a segfault but in silent corruption of other in-memory
data. I would argue that this is a much worse result, even though in
this small test that corruption seems to not trigger a crash.
--
Dennis Kaarsemaker
http://www.kaarsemaker.net
--
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] reflog-walk: don't segfault on non-commit sha1's in the reflog
On do, 2015-12-31 at 09:57 +0100, Dennis Kaarsemaker wrote: > > > +test_expect_success 'reflog containing non-commit sha1s displays > > > properly' ' > > > > In general, "properly" is a poor word to use in test description > (or > > a commit log message or a bug report, for that matter), as the > whole > > point of a test is to precisely define what is "proper". > > > > And the code change declares that a proper thing to do is to omit > > non-commit entries without segfaulting, so something like > > > > s/displays properly/omits them/ > > > > perhaps? > > I did find the test title a bit iffy but couldn't really figure out > why. What you're saying makes a lot of sense, will fix. Thinking about it a bit more: 'proper' would be to show everything, we just expect that not to work yet. So I'll make it test_expect_failure 'reflog with non-commit entries displays all entries' ' git reflog refs/tests/tree-in-reflog >actual && test_line_count = 3 actual ' -- Dennis Kaarsemaker www.kaarsemaker.net -- 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] Graph log and orphan branches
On wo, 2015-12-30 at 11:54 -0800, Junio C Hamano wrote:
> Carlos Pita <carlosjosep...@gmail.com> writes:
>
> > the graph output of log show orphan branches in a way that suggests
> > they have a parent.
>
> Reminds me of this ancient RFH topic
>
> http://thread.gmane.org/gmane.comp.version-control.git/236708/focus
> =239580
>
> which unfortunately got no help...
Instead of a blank line, why not something like this to make root
commits stand out a bit?
diff --git a/revision.c b/revision.c
index 0a282f5..e69a992 100644
--- a/revision.c
+++ b/revision.c
@@ -3346,7 +3346,7 @@ char *get_revision_mark(const struct rev_info *revs,
const struct commit *commit
else
return ">";
} else if (revs->graph)
- return "*";
+ return commit->parents ? "*" : "^" ;
else if (revs->cherry_mark)
return "+";
return "";
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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 v4] reflog-walk: don't segfault on non-commit sha1's in the reflog
git reflog (ab)uses the log machinery to display its list of log
entries. To do so it must fake commit parent information for the log
walker.
For refs in refs/heads this is no problem, as they should only ever
point to commits. Tags and other refs however can point to anything,
thus their reflog may contain non-commit objects.
To avoid segfaulting, we check whether reflog entries are commits before
feeding them to the log walker and skip any non-commits. This means that
git reflog output will be incomplete for such refs, but that's one step
up from segfaulting. A more complete solution would be to decouple git
reflog from the log walker machinery.
Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net>
Helped-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
Helped-by: Junio C Hamano <gits...@pobox.com>
---
Changes since v3: tweaks to the second test.
reflog-walk.c | 16 +++-
t/t1410-reflog.sh | 13 +
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/reflog-walk.c b/reflog-walk.c
index 85b8a54..0ebd1da 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -221,6 +221,7 @@ void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit)
struct commit_info *commit_info =
get_commit_info(commit, >reflogs, 0);
struct commit_reflog *commit_reflog;
+ struct object *logobj;
struct reflog_info *reflog;
info->last_commit_reflog = NULL;
@@ -232,15 +233,20 @@ void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit)
commit->parents = NULL;
return;
}
-
- reflog = _reflog->reflogs->items[commit_reflog->recno];
info->last_commit_reflog = commit_reflog;
- commit_reflog->recno--;
- commit_info->commit = (struct commit *)parse_object(reflog->osha1);
- if (!commit_info->commit) {
+
+ do {
+ reflog = _reflog->reflogs->items[commit_reflog->recno];
+ commit_reflog->recno--;
+ logobj = parse_object(reflog->osha1);
+ } while (commit_reflog->recno && (logobj && logobj->type !=
OBJ_COMMIT));
+
+ if (!logobj || logobj->type != OBJ_COMMIT) {
+ commit_info->commit = NULL;
commit->parents = NULL;
return;
}
+ commit_info->commit = (struct commit *)logobj;
commit->parents = xcalloc(1, sizeof(struct commit_list));
commit->parents->item = commit_info->commit;
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index b79049f..17a194b 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -325,4 +325,17 @@ test_expect_success 'parsing reverse reflogs at BUFSIZ
boundaries' '
test_cmp expect actual
'
+test_expect_success 'no segfaults for reflog containing non-commit sha1s' '
+ git update-ref --create-reflog -m "Creating ref" \
+ refs/tests/tree-in-reflog HEAD &&
+ git update-ref -m "Forcing tree" refs/tests/tree-in-reflog HEAD^{tree}
&&
+ git update-ref -m "Restoring to commit" refs/tests/tree-in-reflog HEAD
&&
+ git reflog refs/tests/tree-in-reflog
+'
+
+test_expect_failure 'reflog with non-commit entries displays all entries' '
+ git reflog refs/tests/tree-in-reflog >actual &&
+ test_line_count = 3 actual
+'
+
test_done
--
2.7.0-rc3-219-g24972d4
--
Dennis Kaarsemaker <den...@kaarsemaker.net>
http://twitter.com/seveas
--
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] reflog-walk: don't segfault on non-commit sha1's in the reflog
On di, 2016-01-05 at 20:05 -0500, Eric Sunshine wrote:
> On Tue, Jan 5, 2016 at 4:12 PM, Dennis Kaarsemaker
> <den...@kaarsemaker.net> wrote:
> > git reflog (ab)uses the log machinery to display its list of log
> > entries. To do so it must fake commit parent information for the
> > log
> > walker.
> >
> > For refs in refs/heads this is no problem, as they should only ever
> > point to commits. Tags and other refs however can point to
> > anything,
> > thus their reflog may contain non-commit objects.
> >
> > To avoid segfaulting, we check whether reflog entries are commits
> > before
> > feeding them to the log walker and skip any non-commits. This means
> > that
> > git reflog output will be incomplete for such refs, but that's one
> > step
> > up from segfaulting. A more complete solution would be to decouple
> > git
> > reflog from the log walker machinery.
> >
> > Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net>
> > ---
> > diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
> > @@ -325,4 +325,17 @@ test_expect_success 'parsing reverse reflogs
> > at BUFSIZ boundaries' '
> > +test_expect_success 'no segfaults for reflog containing non-commit
> > sha1s' '
>
> Nit: It's kind of strange for a test title to talk about not
> segfaulting; that's behavior you'd expect to be true for all tests.
> Perhaps describe it as "non-commit reflog entries handled sanely" or
> something.
To paraphrase what Junio said earlier in this thread: tests determine
what is sane behavior, so using the word 'sanely' isn't really
appropriate. This is a regression test to make sure we don't
accidentally reintroduce behavior that segfaults, which I think is an
easy mistake to make with the current code, so I think the title is
appropriate.
> > + git update-ref --create-reflog -m "Creating ref" \
> > + refs/tests/tree-in-reflog HEAD &&
> > + git update-ref -m "Forcing tree" refs/tests/tree-in-reflog
> > HEAD^{tree} &&
> > + git update-ref -m "Restoring to commit" refs/tests/tree-in
> > -reflog HEAD &&
> > + git reflog refs/tests/tree-in-reflog
> > +'
>
> Hmm, this test is successful for me on OS X even without the
> reflog-walk.c changes applied.
>
> > +test_expect_failure 'reflog with non-commit entries displays all
> > entries' '
> > + git reflog refs/tests/tree-in-reflog >actual &&
> > + test_line_count = 3 actual
> > +'
>
> And this test actually fails (inversely) because it's expecting a
> failure, but doesn't get one since the command produces the expected
> output.
That's... surprising to say the least. What's the content of 'actual',
and which git.git commit are you on?
> By the way, it may make sense to combine these two tests. If a
> segfault occurs, the actual output likely will not match the expected
> output, thus the test will fail anyhow (unless the segfault occurs
> after all output).
I kept them separate to show that while this no longer segfaults, it's
still not the correct output, but showing correct output is a much
bigger project.
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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 v2] reflog-walk: don't segfault on non-commit sha1's in the reflog
Use lookup_commit instead of parse_object to look up commits mentioned
in the reflog. This avoids a segfault in save_parents if somehow a sha1
for something other than a commit ends up in the reflog.
Signed-off-by: Dennis Kaarsemaker <den...@kaarsemaker.net>
Helped-by: Nguyễn Thái Ngọc Duy <pclo...@gmail.com>
Helped-by: Junio C Hamano <gits...@pobox.com>
---
reflog-walk.c | 7 +--
t/t1410-reflog.sh | 13 +
2 files changed, 18 insertions(+), 2 deletions(-)
This version implements Junio's way of doing this, to avoid spurious warnings
and to handle broken commit objects better.
I also added a failing test to show that git reflog still fails to display the
full reflog when it encounters such non-commit objects (it just stops when it
seems them). I don't know how to fix that.
The really correct way of fixing this bug may actually be a level higher, and
making git reflog not rely on information about parent commits, whether they
are fake or not.
diff --git a/reflog-walk.c b/reflog-walk.c
index 85b8a54..861d7c4 100644
--- a/reflog-walk.c
+++ b/reflog-walk.c
@@ -221,6 +221,7 @@ void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit)
struct commit_info *commit_info =
get_commit_info(commit, >reflogs, 0);
struct commit_reflog *commit_reflog;
+ struct object *logobj;
struct reflog_info *reflog;
info->last_commit_reflog = NULL;
@@ -236,11 +237,13 @@ void fake_reflog_parent(struct reflog_walk_info *info,
struct commit *commit)
reflog = _reflog->reflogs->items[commit_reflog->recno];
info->last_commit_reflog = commit_reflog;
commit_reflog->recno--;
- commit_info->commit = (struct commit *)parse_object(reflog->osha1);
- if (!commit_info->commit) {
+ logobj = parse_object(reflog->osha1);
+ if (!logobj || logobj->type != OBJ_COMMIT) {
+ commit_info->commit = NULL;
commit->parents = NULL;
return;
}
+ commit_info->commit = (struct commit *)logobj;
commit->parents = xcalloc(1, sizeof(struct commit_list));
commit->parents->item = commit_info->commit;
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index b79049f..130d671 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -325,4 +325,17 @@ test_expect_success 'parsing reverse reflogs at BUFSIZ
boundaries' '
test_cmp expect actual
'
+test_expect_success 'no segfaults for reflog containing non-commit sha1s' '
+ git update-ref --create-reflog -m "Creating ref" \
+ refs/tests/tree-in-reflog HEAD &&
+ git update-ref -m "Forcing tree" refs/tests/tree-in-reflog HEAD^{tree}
&&
+ git update-ref -m "Restoring to commit" refs/tests/tree-in-reflog HEAD
&&
+ git reflog refs/tests/tree-in-reflog
+'
+
+test_expect_failure 'reflog containing non-commit sha1s displays fully' '
+ git reflog refs/tests/tree-in-reflog > actual &&
+ test_line_count = 3 actual
+'
+
test_done
--
2.7.0-rc1-207-ga35084c
--
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] reflog-walk: don't segfault on non-commit sha1's in the reflog
On wo, 2015-12-30 at 13:20 -0800, Junio C Hamano wrote:
> Dennis Kaarsemaker <den...@kaarsemaker.net> writes:
>
> > diff --git a/reflog-walk.c b/reflog-walk.c
> > index 85b8a54..b85c8e8 100644
> > --- a/reflog-walk.c
> > +++ b/reflog-walk.c
> > @@ -236,8 +236,8 @@ void fake_reflog_parent(struct reflog_walk_info
> > *info, struct commit *commit)
> > reflog = _reflog->reflogs->items[commit_reflog
> > ->recno];
> > info->last_commit_reflog = commit_reflog;
> > commit_reflog->recno--;
> > - commit_info->commit = (struct commit *)parse_object(reflog
> > ->osha1);
> > - if (!commit_info->commit) {
> > + commit_info->commit = lookup_commit(reflog->osha1);
> > + if (!commit_info->commit || parse_commit(commit_info
> > ->commit)) {
> > commit->parents = NULL;
> > return;
>
> This looks somewhat roundabout and illogical. The original was bad
> because it blindly assumed reflgo->osha1 refers to a commit without
> making sure that assumption holds. Calling lookup_commit() blindly
> is not much better, even though you are helped that the function
> happens not to barf if the given object is not a commit.
>
> Also this changes semantics, no? Trace the original flow and think
> what happens, when we see a commit object that cannot be parsed in
> parse_commit_buffer(). parse_object() calls parse_object_buffer()
> which in turn calls parse_commit_buffer() and the entire callchain
> returns NULL. commit_info->commit will become NULL in such a case.
>
> With your code, lookup_commit() will store a non NULL in
> commit_info->commit, and parse_commit() calls parse_commit_buffer()
> and that would fail, so you clear commit->parents to NULL but fail
> to set commit_info->commit to NULL.
>
> Why not keep the parse_object() as-is and make sure we error out
> unless the result is a commit with a more explicit check, perhaps
> like this, instead?
lookup_commit actually returns NULL (via object_as_type) for objects
that are not commits, so I don't think the above is true. The code
below also loses the diagnostic message about the object not being a
commit.
> reflog-walk.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/reflog-walk.c b/reflog-walk.c
> index 85b8a54..861d7c4 100644
> --- a/reflog-walk.c
> +++ b/reflog-walk.c
> @@ -221,6 +221,7 @@ void fake_reflog_parent(struct reflog_walk_info
> *info, struct commit *commit)
> struct commit_info *commit_info =
> get_commit_info(commit, >reflogs, 0);
> struct commit_reflog *commit_reflog;
> + struct object *logobj;
> struct reflog_info *reflog;
>
> info->last_commit_reflog = NULL;
> @@ -236,11 +237,13 @@ void fake_reflog_parent(struct reflog_walk_info
> *info, struct commit *commit)
> reflog = _reflog->reflogs->items[commit_reflog
> ->recno];
> info->last_commit_reflog = commit_reflog;
> commit_reflog->recno--;
> - commit_info->commit = (struct commit *)parse_object(reflog
> ->osha1);
> - if (!commit_info->commit) {
> + logobj = parse_object(reflog->osha1);
> + if (!logobj || logobj->type != OBJ_COMMIT) {
> + commit_info->commit = NULL;
> commit->parents = NULL;
> return;
> }
> + commit_info->commit = (struct commit *)logobj;
>
> commit->parents = xcalloc(1, sizeof(struct commit_list));
> commit->parents->item = commit_info->commit;
>
>
> > +test_expect_success 'reflog containing non-commit sha1s' '
> > + git checkout -b broken-reflog &&
> > + echo "$(git rev-parse HEAD^{tree}) $(git rev-parse HEAD)
> > abc 01 +" >> .git/logs/refs/heads/broken-reflog
> > &&
> > + git reflog broken-reflog
> > +'
> > +
>
> This will negatively affect the ongoing effort to abstract out the
> on-disk implementation of the reflog. In some future installation
> of Git, the reflog may not even be in .git/logs/refs/whatever file.
I was following the style of the test above it, will fix.
> Use a non-branch ref, so that you can store any valid object not
> just commits, and use a Git command (e.g. "git update-ref" or "git
> tag") instead of the raw filesystem access to update it, perhaps
> like this?
>
> git tag --create-reflog test-logs HEAD^ &&
> git tag -f test-logs HEAD^{tree} &&
> git tag -f test-logs HEAD &&
> git reflog test-logs
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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] reflog-walk: don't segfault on non-commit sha1's in the reflog
On wo, 2015-12-30 at 13:41 -0800, Junio C Hamano wrote:
> Dennis Kaarsemaker <den...@kaarsemaker.net> writes:
>
> > On wo, 2015-12-30 at 13:20 -0800, Junio C Hamano wrote:
> > > Dennis Kaarsemaker <den...@kaarsemaker.net> writes:
> > >
> > > > diff --git a/reflog-walk.c b/reflog-walk.c
> > > > index 85b8a54..b85c8e8 100644
> > > > --- a/reflog-walk.c
> > > > +++ b/reflog-walk.c
> > > > @@ -236,8 +236,8 @@ void fake_reflog_parent(struct
> > > > reflog_walk_info
> > > > *info, struct commit *commit)
> > > > reflog = _reflog->reflogs->items[commit_reflog
> > > > ->recno];
> > > > info->last_commit_reflog = commit_reflog;
> > > > commit_reflog->recno--;
> > > > - commit_info->commit = (struct commit
> > > > *)parse_object(reflog
> > > > ->osha1);
> > > > - if (!commit_info->commit) {
> > > > + commit_info->commit = lookup_commit(reflog->osha1);
> > > > + if (!commit_info->commit || parse_commit(commit_info
> > > > ->commit)) {
> > > > commit->parents = NULL;
> > > > return;
> > >
> > > This looks somewhat roundabout and illogical. The original was
> > > bad
> > > because it blindly assumed reflgo->osha1 refers to a commit
> > > without
> > > making sure that assumption holds. Calling lookup_commit()
> > > blindly
> > > is not much better, even though you are helped that the function
> > > happens not to barf if the given object is not a commit.
> > >
> > > Also this changes semantics, no? Trace the original flow and
> > > think
> > > what happens, when we see a commit object that cannot be parsed
> > > in
> > > parse_commit_buffer(). parse_object() calls
> > > parse_object_buffer()
> > > which in turn calls parse_commit_buffer() and the entire
> > > callchain
> > > returns NULL. commit_info->commit will become NULL in such a
> > > case.
> > >
> > > With your code, lookup_commit() will store a non NULL in
> > > commit_info->commit, and parse_commit() calls
> > > parse_commit_buffer()
> > > and that would fail, so you clear commit->parents to NULL but
> > > fail
> > > to set commit_info->commit to NULL.
> > >
> > > Why not keep the parse_object() as-is and make sure we error out
> > > unless the result is a commit with a more explicit check, perhaps
> > > like this, instead?
> >
> > lookup_commit actually returns NULL (via object_as_type) for
> > objects
> > that are not commits, so I don't think the above is true.
>
> I think you did not read what you are responding to. I was talking
> about the error case where the object _is_ a commit (hence lookup
> returns it), but parse_commit_buffer() does not like its contents.
I read it, but misunderstood it. Thanks for clarifying.
> > The code below also loses the diagnostic message about the object
> > not being a commit.
>
> Giving such a diagnostic message is a BUG.
>
> A ref can legitimately point at any type of object (only refs under
> refs/heads/, aka "branches", must point at commits), so you MUST NOT
> complain about seeing a non-commit in a reflog in general.
Yeah, that makes sense, didn't think of that.
--
Dennis Kaarsemaker
www.kaarsemaker.net
--
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
