Your Dirty Close family By using Minor Parental Regulate With cheap pandora bracelets
You're keen on all those excellent * http://www.buycheappandorarings.co.uk/ pandora uk* , not? I actually do believe that most people conduct, plus there's a simple cause for this. They really are attractive, personally special. Precisely what definitely to not ever for instance, once all of? They can be manufactured from the perfect pieces plus produced by folks that assume a number of among us will be personalised plus have earned to implement excellent rings which is a description of the private personalised personas. *http://www.buycheappandorarings.co.uk/* -- View this message in context: http://git.661346.n2.nabble.com/Your-Dirty-Close-family-By-using-Minor-Parental-Regulate-With-cheap-pandora-bracelets-tp7581463.html Sent from the git mailing list archive at Nabble.com. -- 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] count-objects: output KiB instead of kilobytes
I'm really sorry about that. I'll make sure to run the tests before sending patches in the future. On Wed, Apr 3, 2013 at 12:01 AM, Junio C Hamano gits...@pobox.com wrote: Mihai Capotă mi...@mihaic.ro writes: The code uses division by 1024. Also, the manual uses KiB. Signed-off-by: Mihai Capotă mi...@mihaic.ro --- builtin/count-objects.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/count-objects.c b/builtin/count-objects.c index 9afaa88..ecc13b0 100644 --- a/builtin/count-objects.c +++ b/builtin/count-objects.c @@ -124,7 +124,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix) printf(garbage: %lu\n, garbage); } else - printf(%lu objects, %lu kilobytes\n, + printf(%lu objects, %lu KiB\n, loose, (unsigned long) (loose_size / 1024)); return 0; } This breaks existing tests (5301, 7408 and 5700); I noticed it too late and wasted 20 minutes, having to re-run today's integration cycle. Next time, please run the testsuite before sending a patch. -- 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
microsoft windows 8 Operating system Is actually Functioned With Computer system Products
Various facts are beginning to crop up connected with cures can expect on the primary creation connected with Intel-based * http://www.win8ultimatekey.net/ microsoft windows 8* . When the leaked available requirements on the Dell Microsoft windows 8 gadget usually are almost any clue, nevertheless, products can be enormously underwhelming. * http://www.win8ultimatekey.net/* -- View this message in context: http://git.661346.n2.nabble.com/microsoft-windows-8-Operating-system-Is-actually-Functioned-With-Computer-system-Products-tp7581466.html Sent from the git mailing list archive at Nabble.com. -- 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
Desired so that you can office 2010 key online website!
Desired so that you can Business 2010 online website! [url=http://www.buyoffice2010keyshop.com/] office 2010[/url] by using quite a few innovative benefits involve innovative theme auto-highlight, a lot quicker synchronization, real-time variations demonstrate, release aid plus article writer watering hole color-coding. You'll find it comprises of a useful acoustic plus training video updating, interpretation gear, freshly written and published photographic results plus enable direct. A program with Business 2010 Qualified And also comprises of a superior preferred things about Statement, PowerPoint, OneNote, Obtain, Outlook on life plus Excel in life. Ms Business 2010 Qualified And also benefits a superior SharePoint integration to get fantastic online organizing uses. Around Business 2010 Major key term you decide to do currently have even more ability. http://www.buyoffice2010keyshop.com/ -- View this message in context: http://git.661346.n2.nabble.com/Desired-so-that-you-can-office-2010-key-online-website-tp7581467.html Sent from the git mailing list archive at Nabble.com. -- 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
thomas sabo uk carry an exceptional verity about designs and additionally ways
The new magnifying glaas thomas sabo uk http://www.cheapsthomassoboshop.co.uk carry an exceptional verity about designs and additionally ways equally, all the texture and consistency along with the phenomena experience smaller bubble magnifying glaas golf balls throughout the working surface. With trolls drops you will express feeling, message and additionally novel idea. They are are made up of various creations want Disney roles. You can even insure any necklace completely unique, permit you to type any with different shades or possibly imagery, you're able to revise the plan. Other designs about jones sabo necklaces really are lovelinks. Eventhough high-quality Necklaces would be exhibited a great value range listed, pet owners love to decide to buy top-quality Necklaces stunning drink up money real deal cheaper team Precious jewelry which is certainly sold at put faitth on range listed. The best quality you’re magnifying glaas. Supplementary, all the jewelries you can see nearly every one of superior and additionally wonderful type; My personal opinion which usually although you may decide to buy precious jewelry in that respect there, no one will ok a fabulous equal a, all of us about thomas sabo charm club http://www.cheapsthomassoboshop.co.uk will be a. Other, wedding reception really do the VIP when lots of content is normally beyond 210 francs, in the case of celebrations and additionally annual vacations, they’re preparing to delivery service a lot of trinkets by means of style and it also pushes modern knowledge about jewelrys for your needs. People always demand the reason Document consider great precious jewelry, Let me teach you the software to you. First of all Jones sabo Precious jewelry is a really recognized listed also . indicate to from in this article, far better set in place your body free of cost. after we talk about singer precious jewelry, thomas sabo charms uk http://www.cheapsthomassoboshop.co.uk is for certain to indicate to up in this emotions. Just for owners about silver precious jewelry, jones sabo Down under is often a fabulous known trademark. Businesses are for recognize working with all the specific and additionally effective types of precious jewelry. is it doesn't Jones Sabo Charm bracelets organization arranged through corp in which shows up to grant you will just about the most recommended elements. For those completely unique circumstances, Jones Sabo Anh? nger absolutely nothing may be greater or all the assortment of precious jewelry given by Sabo. All the assortment of Jones Sabo’s arranged just for Fall-Winter ’09 is actually a fabulous craze within owners about silver. This approach wide range first got it is normally contemplation style the favourite the well-known teen toy identified as Barbie. All the business venture makes a fabulous unisex solar panels in which helps out for cleaning out all the routine difference anywhere between precious jewelry just for boyfriend and also about girls. http://www.cheapsthomassoboshop.co.uk -- View this message in context: http://git.661346.n2.nabble.com/thomas-sabo-uk-carry-an-exceptional-verity-about-designs-and-additionally-ways-tp7581468.html Sent from the git mailing list archive at Nabble.com. -- 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
pandora bracelet charms guaranteed the standard of the majority of the valuable jewellery for top level form
What is much better within [url=http://www.pndoracharmonlineshop.ca/] pandora charms[/url] is usually which often as the trinket would have been a large number of masterpieces, all of the provider additionally offers a number of items you could make use of. Computer mindset for that recipient, all of the provider might potentially often find, and discover a very ideal design that will complement with the fascinates and also pursuits for that recipient. To mention a few, Pandora appeal anklet bracelets encounter veggies, treats, the blossom bridal bouquet, animals, because of this several other people. Regularly, [url=http://www.pndoracharmonlineshop.ca/] pandora bracelet charms[/url] guaranteed the standard of the majority of the valuable jewellery for top level form. People made certain that each little valuable jewellery made from by having an aesthetic indicates placing a good increased exposure of specifically kind and also artwork. Many people started selecting cognizance out of this fact, and also instantly just about everyone is usually using the combined associated with Pandora valuable jewellery. And also, because of this particular, appeal anklet bracelets made by Pandora have grown to be because of this acknowledged which males started to have them such as mementos for any loved-ones. http://www.pndoracharmonlineshop.ca/ -- View this message in context: http://git.661346.n2.nabble.com/pandora-bracelet-charms-guaranteed-the-standard-of-the-majority-of-the-valuable-jewellery-for-top-lem-tp7581469.html Sent from the git mailing list archive at Nabble.com. -- 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
I merely ended up being generally in close proximity to a lot of don't known tiffany uk variety
Most of the food morning ended up being generally fantastic. Most of the spouses shifted by way of, [url=http://www.buytiffanyringsshop.co.uk/] tiffany uk[/url] the majority of by way of shimmering is appropriate for. Surely your current sister-in-law, as opposed to using whom I ran across a number of bias, seemed just as if your main wonderful smelling plant life in financial trouble clothe. Let alone the as well as her's works with are generally as well warm by making use of well-being. Your major time acquired below. The as well as her's holy marriage ended up being generally presented let alone your current in-law angling in direction of make out his or her. http://www.buytiffanyringsshop.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/I-merely-ended-up-being-generally-in-close-proximity-to-a-lot-of-don-t-known-tiffany-uk-variety-tp7581470.html Sent from the git mailing list archive at Nabble.com. -- 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
You'll also find complex Pandora sale who are a popular topic
You might seeking out [url=http://www.cheappandorabuyshop.co.uk/] pandora uk[/url] for Connecticut, most definitely all the truly trendy style anklet bracelets. They can be a completely unique and additionally basic version of precious jewelry which usually arose in Denmark. There is other designs about Pandora precious jewelry along with anklet bracelets. You'll also find silver necklaces, much more and additionally diamond earrings. The matter that may make one of these precious jewelry for that reason completely unique is normally you ought to be able to type your current precious jewelry product just by blending together multiple drops and additionally charm bracelets at the same time. The main reason why any product will get unique. You’re able to whether decide to buy this approach precious jewelry actually designed for carry out identifies or possibly you are able to consider generate your current completely unique item of precious jewelry just by purchasing the drops singularly and additionally personalizing any product. http://www.cheappandorabuyshop.co.uk/ -- View this message in context: http://git.661346.n2.nabble.com/You-ll-also-find-complex-Pandora-sale-who-are-a-popular-topic-tp7581471.html Sent from the git mailing list archive at Nabble.com. -- 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: ZSH segmentation fault while completing git mv dir/
Manlio Perillo manlio.peri...@gmail.com writes: By the way: have you filled a bug report to Debian? No, but this is a bug touching very few users, in Debian stable which is reaching its end of life. I do not think the Debian folks would be interested in fixing this non-security, non-critical bug now. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- 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 00/13] remote-hg: general updates
On Tue, Apr 2, 2013 at 7:31 PM, Felipe Contreras felipe.contre...@gmail.com wrote: * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg) I ran these test-cases with remote-hg, and the same test-cases pass. I only had to do minor modifications, most of the failures came from subtle differences such as different strategies to sanitize authors, and which branch to pick for HEAD. After doing some modifications in remote-hg, here are the test cases of gitifyhg v0.8 without modifications: = test session starts == platform linux2 -- Python 2.7.3 -- pytest-2.3.4 collected 80 items test/test_author.py F test/test_clone.py ..xx.x...x.. test/test_notes.py ..FxF test/test_pull.py x..xx.. test/test_push.py ..xFF... test/test_special_cases.py ... === FAILURES === /home/felipec/tmp/gitifyhg/test/helpers.py:118: assert 'totally bad...e used in hg' == 'totally unknown' /usr/lib/python2.7/site-packages/sh.py:309: ErrorReturnCode_128: /home/felipec/tmp/gitifyhg/test/test_notes.py:107: assert not 'error' in 'searching for changes\nno changes found\nFrom hg::file:///tmp/pytest-91/test_simple_push_updates_notes_after_contentf...rror: refs/notes/hg does not point to a valid object!\nerror: refs/notes/hg-origin does not point to a valid object!\n' /home/felipec/tmp/gitifyhg/test/helpers.py:108: assert [u'Added tag ...780a9c', u'a'] == ['I tagged thi...nd user', 'a'] /home/felipec/tmp/gitifyhg/test/test_push.py:410: assert 'default' == 'branch_one' === 5 failed, 66 passed, 9 xfailed in 75.23 seconds -- Felipe Contreras -- 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 00/13] remote-hg: general updates
* internally, the marks are using the hg sha1s instead of the hg rev ids. The latter are not necessarily invariant, and using the sha1s makes it much easier to recover from semi-broken states. I doubt this makes any difference (except for more wasted space). I think this is definitely wrong. If you happen to strip a changeset from the mercurial repository, and redo a completely different commit on top of it, the new commit will never be seen on git end (because it will have the same rev id and will thus be identified as identical from git point of view). -- 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] cherry-pick: better error message when the parameter is a non-commit
When copypaste goes wrong, and the user e.g. tries to cherry-pick a
blob, the error message used to be:
fatal: BUG: expected exactly one commit from walk
Instead, now it is:
fatal: Can't cherry-pick a blob
Signed-off-by: Miklos Vajna vmik...@suse.cz
---
sequencer.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index baa0310..0ac00d4 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1082,8 +1082,15 @@ int sequencer_pick_revisions(struct replay_opts *opts)
if (prepare_revision_walk(opts-revs))
die(_(revision walk setup failed));
cmit = get_revision(opts-revs);
- if (!cmit || get_revision(opts-revs))
+ if (!cmit || get_revision(opts-revs)) {
+ unsigned char sha1[20];
+ if (!get_sha1(opts-revs-cmdline.rev-name, sha1)) {
+ enum object_type type = sha1_object_info(sha1,
NULL);
+ if (type 0 type != OBJ_COMMIT)
+ die(_(Can't cherry-pick a %s),
typename(type));
+ }
die(BUG: expected exactly one commit from walk);
+ }
return single_pick(cmit, opts);
}
--
1.8.1.4
--
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 https transport and wrong password
Maybe my git installation was incomplete before when running from ~/bin since I was not able to set break points to http_request() and some debug code was not there until I ran git through bin-wrappers in the source tree. I added some debug prints to http.c functions http_request() and handle_curl_result(), and now I see this chain of events: http_request_reauth() http_request() GET ...info/refs?service=git-upload-pack HTTP/1.1 401 Authorization Required * Ignoring the response-body * Issue another request to this URL: '...' GET ...info/refs?service=git-upload-pack HTTP/1.1 401 Authorization Required handle_curl_result: res = 22, http_code = 401, user = ..., pass = (null) Password for '...': (enter valid password) GET ...info/refs?service=git-upload-pack HTTP/1.1 200 OK So, for some reason the first GET request is issued twice and first 401 is ignored. I'll try to debug run_active_slot() next... -Mikko -- 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: check-attr doesn't respect recursive definitions
Thanks for the clarifications. Just a quick comment about the summary: Jeff King p...@peff.net wrote: Yeah, I had the same thought. So you would have to either: 1. Hook the feature into git-archive, which knows about how it recurses, and can report the correct set of paths. or 2. Tell check-attr (or some post-processor) to apply the attribute to elements below the path (or possibly to prune out such paths). This is not the same as recursive application, because you cannot negate it (i.e., you actually find out the final attrs for both foo and foo/bar, and then say the attr for 'foo' overrides the attr for 'foo/bar'. I posted a patch for (1), but it felt not-very-general. But (2) also feels gross and not very general. Even though it could in theory be used for things besides git-archive, it is really just applying git-archive's pruning rule, which other programs likely don't care about. I actually think the first approach is not such a bad idea, it would make archive more of a general-purpose archiving tool/helper for the repository rather than just something for the special cases of tars and zips. But I guess that's somewhat subjective. Cheers, Jan -- 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] count-objects: output KiB instead of kilobytes
The code uses division by 1024. The master branch count-objects manual also
uses KiB.
Also updated the code that reads count-objects output (t5301, t5700, t7408, and
git-cvsimport) and the Git User's Manual.
Signed-off-by: Mihai Capotă mi...@mihaic.ro
---
Documentation/user-manual.txt |4 ++--
builtin/count-objects.c|2 +-
git-cvsimport.perl |8
t/t5301-sliding-window.sh |4 ++--
t/t5700-clone-reference.sh |4 ++--
t/t7408-submodule-reference.sh |4 ++--
6 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index e831cc2..b61a09c 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3175,7 +3175,7 @@ lot of objects. Try this on an old project:
$ git count-objects
-6930 objects, 47620 kilobytes
+6930 objects, 47620 KiB
The first number is the number of objects which are kept in
@@ -3215,7 +3215,7 @@ You can verify that the loose objects are gone by looking
at the
$ git count-objects
-0 objects, 0 kilobytes
+0 objects, 0 KiB
Although the object files are gone, any commands that refer to those
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index 9afaa88..ecc13b0 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -124,7 +124,7 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
printf(garbage: %lu\n, garbage);
}
else
- printf(%lu objects, %lu kilobytes\n,
+ printf(%lu objects, %lu KiB\n,
loose, (unsigned long) (loose_size / 1024));
return 0;
}
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 73d367c..de44e33 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -1126,12 +1126,12 @@ unless ($opt_P) {
}
# The heuristic of repacking every 1024 commits can leave a
-# lot of unpacked data. If there is more than 1MB worth of
+# lot of unpacked data. If there is more than 1MiB worth of
# not-packed objects, repack once more.
my $line = `git count-objects`;
-if ($line =~ /^(\d+) objects, (\d+) kilobytes$/) {
- my ($n_objects, $kb) = ($1, $2);
- 1024 $kb
+if ($line =~ /^(\d+) objects, (\d+) KiB$/) {
+ my ($n_objects, $kib) = ($1, $2);
+ 1024 $kib
and system(qw(git repack -a -d));
}
diff --git a/t/t5301-sliding-window.sh b/t/t5301-sliding-window.sh
index 2fc5af6..37931d2 100755
--- a/t/t5301-sliding-window.sh
+++ b/t/t5301-sliding-window.sh
@@ -20,7 +20,7 @@ test_expect_success \
commit1=`git commit-tree $tree /dev/null`
git update-ref HEAD $commit1
git repack -a -d
- test `git count-objects` = 0 objects, 0 kilobytes
+ test `git count-objects` = 0 objects, 0 KiB
pack1=`ls .git/objects/pack/*.pack`
test -f $pack1'
@@ -46,7 +46,7 @@ test_expect_success \
commit2=`git commit-tree $tree -p $commit1 /dev/null`
git update-ref HEAD $commit2
git repack -a -d
- test `git count-objects` = 0 objects, 0 kilobytes
+ test `git count-objects` = 0 objects, 0 KiB
pack2=`ls .git/objects/pack/*.pack`
test -f $pack2
test $pack1 \!= $pack2'
diff --git a/t/t5700-clone-reference.sh b/t/t5700-clone-reference.sh
index c47d450..e5cfd6a 100755
--- a/t/t5700-clone-reference.sh
+++ b/t/t5700-clone-reference.sh
@@ -46,7 +46,7 @@ cd $base_dir
test_expect_success 'that reference gets used' \
'cd C
-echo 0 objects, 0 kilobytes expected
+echo 0 objects, 0 KiB expected
git count-objects current
test_cmp expected current'
@@ -73,7 +73,7 @@ test_expect_success 'pulling from reference' \
cd $base_dir
test_expect_success 'that reference gets used' \
-'cd D echo 0 objects, 0 kilobytes expected
+'cd D echo 0 objects, 0 KiB expected
git count-objects current
test_cmp expected current'
diff --git a/t/t7408-submodule-reference.sh b/t/t7408-submodule-reference.sh
index b770b2f..aeface6 100755
--- a/t/t7408-submodule-reference.sh
+++ b/t/t7408-submodule-reference.sh
@@ -49,7 +49,7 @@ cd $base_dir
test_expect_success 'that reference gets used with add' \
'cd super/sub
-echo 0 objects, 0 kilobytes expected
+echo 0 objects, 0 KiB expected
git count-objects current
diff expected current'
@@ -72,7 +72,7 @@ cd $base_dir
test_expect_success 'that reference gets used with update' \
'cd super-clone/sub
-echo 0 objects, 0 kilobytes expected
+echo 0 objects, 0 KiB expected
git count-objects current
diff expected current'
--
1.7.9.5
--
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] Documentation/git-commit: reword the --amend explanation
The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. --- The current text is from 2006, which I guess explains the wording. Documentation/git-commit.txt | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 42c22bb..48dac29 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -198,14 +198,11 @@ OPTIONS without changing its commit message. --amend:: - Used to amend the tip of the current branch. Prepare the tree - object you would want to replace the latest commit as usual - (this includes the usual -i/-o and explicit paths), and the - commit log editor is seeded with the commit message from the - tip of the current branch. The commit you create replaces the - current tip -- if it was a merge, it will have the parents of - the current tip as parents -- so the current top commit is - discarded. + Amend the tip of the current branch. The commit is prepared as + usual (including -i/-o and explicit paths) and the editor + starts off with the current tip's commit message. The new + commit has the same parents and author as the current one and + replaces it as the tip. + -- It is a rough equivalent for: -- 1.8.2.524.g8f8def7 -- 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 https transport and wrong password
[+cc Daniel for curl questions below] On Wed, Apr 03, 2013 at 12:43:02PM +0300, Mikko Rapeli wrote: Maybe my git installation was incomplete before when running from ~/bin since I was not able to set break points to http_request() and some debug code was not there until I ran git through bin-wrappers in the source tree. Debugging git-over-http is somewhat difficult because the interesting bits happen in sub-processes. You can get much closer to the http calls by running the transport helper directly, like: gdb --args git-remote-https https://yourhost/ which will start by reading commands from stdin (try list to get it to fetch the remote refs). I added some debug prints to http.c functions http_request() and handle_curl_result(), and now I see this chain of events: http_request_reauth() http_request() GET ...info/refs?service=git-upload-pack HTTP/1.1 401 Authorization Required * Ignoring the response-body * Issue another request to this URL: '...' GET ...info/refs?service=git-upload-pack HTTP/1.1 401 Authorization Required handle_curl_result: res = 22, http_code = 401, user = ..., pass = (null) Password for '...': (enter valid password) GET ...info/refs?service=git-upload-pack HTTP/1.1 200 OK So, for some reason the first GET request is issued twice and first 401 is ignored. I'll try to debug run_active_slot() next... Right, I think that's curl trying to make use of the username in the URL. Try this (I'm using github here as a convenient http servers, but you should be able to replicate with your internal server): $ GIT_CURL_VERBOSE=1 git ls-remote https://f...@github.com/requires/auth \ 21 /dev/null | egrep '^|^ HTTP|^Authorization|requested URL' GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 HTTP/1.1 401 Authorization Required GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOg== HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 Password for 'https://f...@github.com': GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOmJhcg== HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 So you can see that curl makes _two_ requests internally before it returns the 401. One unadorned, and one with just the username (Zm9vOg==, which decodes to foo:) for the auth. Then git prompts for the password, and we retry (and of course I am feeding it a bogus username/password combo, so we get another 401). I would expect without the username in the URL for it to make only two requests: one to get the first 401, then git collects the credentials, then a follow-up with the credentials. But instead we get: $ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/requires/auth \ 21 /dev/null | egrep '^|^ HTTP|^Authorization|requested URL' GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 * The requested URL returned error: 401 Authorization Required Username for 'https://github.com': foo Password for 'https://f...@github.com': GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 HTTP/1.1 401 Authorization Required GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOmJhcg== HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 So we get a 401, as expected, git prompts for the credentials and feeds them directly to curl, but then we still get _two_ requests: we trigger another 401, and only then does curl provide the authorization header to the server. I'm not sure if that extra auth is intended or not. It's also possible that git is screwing up in providing the credentials to curl, but I don't think so. We feed them to the curl handle as soon as we get them, and there should be only one handle in use here. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-tag(1): we tag HEAD by default
The commit|object argument is actually not explained anywhere (except implicitly in the description of an unannotated tag). Write a little explanation, in particular to cover the default. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Prompted by a question on IRC about the default value. Do we actually read our own docs? ;-) Documentation/git-tag.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index e3032c4..697df50 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -126,6 +126,11 @@ This option is only applicable when listing tags without annotation lines. linkgit:git-check-ref-format[1]. Some of these checks may restrict the characters allowed in a tag name. +commit, object:: + The object that the new tag will refer to, usually a commit. + Defaults to HEAD. + + CONFIGURATION - By default, 'git tag' in sign-with-default mode (-s) will use your -- 1.8.2.548.g7173465 -- 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] test-lint-duplicates: Only check for numbered test cases
On Wed, Apr 03, 2013 at 07:54:02AM +0200, Torsten Bögershausen wrote:
Running make inside contrib/remote-helpers fails in test-lint-duplicates
This was because the regexp checking for duplicate numbers strips everything
after the first - in the filename, including the prefix.
As a result, 2 pathnames like
/contrib/remote-helpers/test-bzr.sh and
/contrib/remote-helpers/test-hg-bidi.sh
are both converted into
/contrib/remote, and reported as duplicate.
Improve the regexp:
Remove everything after t- (where X stand for a digit)
I think the approach to just make test-lint-duplicates a no-op on
non-numbered tests is reasonable, but this is side-stepping half of the
issue. The problems are:
1. We do not have numbers in our test names.
2. We _do_ have full paths in the test names, which might have
elements which look like test script names.
Your patch tightens the match so that a hyphen in the path name does not
confuse our script. But it trades it for being confused by t in the
pathname. Which is admittedly less likely, but is not addressing the
fundamental issues that we should only be processing basenames.
So something like sed 's,.*/,,' would fix that. But that still leaves
us with a bunch of tests called test-foo, test-bar, etc, which will
appear as duplicates. So we would still want to tighten the number
parsing.
Like:
diff --git a/t/Makefile b/t/Makefile
index 5c6de81..e5afa4c 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -47,7 +47,9 @@ test-lint-duplicates:
test-lint: test-lint-duplicates test-lint-executable
test-lint-duplicates:
- @dups=`echo $(T) | tr ' ' '\n' | sed 's/-.*//' | sort | uniq -d` \
+ @dups=`echo $(T) | tr ' ' '\n' | \
+ sed -e 's,.*/,,' -e 's/\(t[0-9][0-9][0-9][0-9]\)-.*/\1/' | \
+ sort | uniq -d` \
test -z $$dups || { \
echo 2 duplicate test numbers: $$dups; exit 1; }
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
cd
Hi all, We are students from Universidade do Minho in Portugal, and we are using git in project as a case study. While experimenting with git we found an unexpected behavior with git rm. Here is a trace of the unexpected behavior: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey D $ git rm D/F warning: 'D/F': Not a directory rm 'D/F' fatal: git rm: 'D/F': Not a directory If the file D created with last echo did not exist or was named differently then no error would occur as expected. For example: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey F $ git rm D/F This works as expected, and the only difference is the name of the file of the last echo. Is this the expected behavior of git rm? -- View this message in context: http://git.661346.n2.nabble.com/cd-tp7581484.html Sent from the git mailing list archive at Nabble.com. -- 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
Behavior of git rm
Hi all, We are students from Universidade do Minho in Portugal, and we are using git in project as a case study. While experimenting with git we found an unexpected behavior with git rm. Here is a trace of the unexpected behavior: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey D $ git rm D/F warning: 'D/F': Not a directory rm 'D/F' fatal: git rm: 'D/F': Not a directory If the file D created with last echo did not exist or was named differently then no error would occur as expected. For example: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey F $ git rm D/F This works as expected, and the only difference is the name of the file of the last echo. Is this the expected behavior of git rm? -- View this message in context: http://git.661346.n2.nabble.com/Behavior-of-git-rm-tp7581485.html Sent from the git mailing list archive at Nabble.com. -- 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-helpers: fix the run of all tests
Jeff King p...@peff.net writes: On Tue, Apr 02, 2013 at 06:53:28PM +0200, Torsten Bögershausen wrote: I think the check for duplicate-numbers is the only one that does not make sense. [] Not sure about that, I send a suggestion of a patch in a minute. Highlights: 1) - rename the contrib test cases and assigns real TC numbers 2) - Forward the numbers into the main test Makefile I'm not sure if this is a good idea or not. If that's a polite way to say that this is not a good idea, I'd agree for all the reasons you mentioned. It puts the contrib/remote-helpers into the same number namespace as the rest of the test scripts, and enforces uniqueness with test-lint-duplicates, when make test is run from contrib/remote-helpers. But people working on the main test scripts would not get any such check, and would happily break contrib/remote-helpers by adding duplicate test numbers. It makes sense to me to either: 1. Have the contrib/remote-helpers test live in their own test namespace completely, with their own numbers and test-results, and pull in relevant bits from the main test harness. We do this already with contrib/subtree. I suggested this when the tests first appeared, but there was some argument, and I don't remember the details. This makes more sense than the alternative, given that contrib/ material is optional from the main tree's point of view, at least to me. Thanks. 2. Just integrate contrib test scripts into the main repository, but leave them off by default. For example, add: if test -z $GIT_TEST_REMOTE_HELPERS; then skip_all=Remote helper tests disabled (define GIT_TEST_REMOTE_HELPERS) test_done fi to the top of the scripts, and then set GIT_TEST_REMOTE_HELPERS in contrib/remote-helpers/Makefile before chaining to the test Makefile. -- 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] Documentation/git-commit: reword the --amend explanation
Carlos Martín Nieto c...@elego.de writes: The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. --- Sign-off? The current text is from 2006, which I guess explains the wording. Yes, and since then we gained --no-edit option and such, so editor starts off also needs to be rethought, no? The original wording with seeded may have a better chance of survival, I suspect, but still needs some adjustment. Thanks for looking into this. Documentation/git-commit.txt | 13 + 1 file changed, 5 insertions(+), 8 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 42c22bb..48dac29 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -198,14 +198,11 @@ OPTIONS without changing its commit message. --amend:: - Used to amend the tip of the current branch. Prepare the tree - object you would want to replace the latest commit as usual - (this includes the usual -i/-o and explicit paths), and the - commit log editor is seeded with the commit message from the - tip of the current branch. The commit you create replaces the - current tip -- if it was a merge, it will have the parents of - the current tip as parents -- so the current top commit is - discarded. + Amend the tip of the current branch. The commit is prepared as + usual (including -i/-o and explicit paths) and the editor + starts off with the current tip's commit message. The new + commit has the same parents and author as the current one and + replaces it as the tip. + -- It is a rough equivalent for: -- 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-tag(1): we tag HEAD by default
Thomas Rast tr...@inf.ethz.ch writes: The commit|object argument is actually not explained anywhere (except implicitly in the description of an unannotated tag). Write a little explanation, in particular to cover the default. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Prompted by a question on IRC about the default value. Do we actually read our own docs? ;-) Perhaps among us some of them are real men ;-) Documentation/git-tag.txt | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index e3032c4..697df50 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -126,6 +126,11 @@ This option is only applicable when listing tags without annotation lines. linkgit:git-check-ref-format[1]. Some of these checks may restrict the characters allowed in a tag name. +commit, object:: + The object that the new tag will refer to, usually a commit. + Defaults to HEAD. Shouldn't this be more like this: commit:: object:: Your explanation here... Other than that, I think this is a reasonable change. Thanks. + + CONFIGURATION - By default, 'git tag' in sign-with-default mode (-s) will use your -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Sharness v0.3.0
Hi, I've released a new version of Sharness [1] -- the test harness library derived from Git's test lib [2]. This release is all about bringing upstream fixes and improvements from Git to Sharness [3]. Now Sharness only lacks a few of the generic functions provided by Git's test lib, e.g. test_declared_prereq, test_lazy_prereq or test_pause, which I might add in the future as well. If you want to test your Unix tools like Git does, give Sharness a try. [1] https://github.com/mlafeldt/sharness [2] https://github.com/git/git/blob/master/t/test-lib.sh [3] https://github.com/mlafeldt/sharness/blob/master/CHANGELOG.md#v030-2013-04-03 -Mathias -- 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-tag(1): we tag HEAD by default
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
+commit, object::
+The object that the new tag will refer to, usually a commit.
+Defaults to HEAD.
Shouldn't this be more like this:
commit::
object::
Your explanation here...
Hmm, you're right, but we seem to be fairly inconsistent in that
department. There are some instances with the comma style:
$ git grep ',.*::$' Documentation/*.txt
Documentation/blame-options.txt:-L start,end, -L :regex::
Documentation/config.txt:gitcvs.dbuser, gitcvs.dbpass::
Documentation/config.txt:http.lowSpeedLimit, http.lowSpeedTime::
Documentation/diff-options.txt:--stat[=width[,name-width[,count]]]::
Documentation/diff-options.txt:--dirstat[=param1,param2,...]::
Documentation/git-add.txt:-e, \--edit::
Documentation/git-check-attr.txt:-a, --all::
Documentation/git-check-ignore.txt:-q, --quiet::
Documentation/git-check-ignore.txt:-v, --verbose::
Documentation/git-index-pack.txt:--index-version=version[,offset]::
Documentation/git-log.txt:-L start,end:file, -L :regex:file::
Documentation/git-log.txt:git log -L '/int main/',/^}/:main.c::
Documentation/git-p4.txt:--verbose, -v::
Documentation/git-p4.txt:--dry-run, -n::
Documentation/git-p4.txt://depot/my/project@1,6::
Documentation/git-pack-objects.txt:--index-version=version[,offset]::
Documentation/git-remote-fd.txt:`git push fd::7,8 master (as URL)`::
Documentation/git-remote-fd.txt:`git push fd::7,8/bar master`::
Documentation/git-reset.txt:Undo a commit, making it a topic branch::
Documentation/git-shortlog.txt:-w[width[,indent1[,indent2]]]::
Documentation/git-show-branch.txt:--reflog[=n[,base]] [ref]::
Documentation/git-tag.txt:commit, object::
Documentation/revisions.txt:'sha1', e.g.
'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
Documentation/revisions.txt:'describeOutput', e.g. 'v1.7.4.2-679-g3bee7fb'::
Documentation/revisions.txt:'refname', e.g. 'master', 'heads/master',
'refs/heads/master'::
Documentation/revisions.txt:'refname@\{date\}', e.g.
'master@\{yesterday\}', 'HEAD@\{5 minutes ago\
Documentation/revisions.txt:'refname@\{n\}', e.g. 'master@\{1\}'::
Documentation/revisions.txt:'@\{n\}', e.g. '@\{1\}'::
Documentation/revisions.txt:'@\{-n\}', e.g. '@\{-1\}'::
Documentation/revisions.txt:'branchname@\{upstream\}', e.g.
'master@\{upstream\}', '@\{u\}'::
Documentation/revisions.txt:'rev{caret}', e.g. 'HEAD{caret},
v1.5.1{caret}0'::
Documentation/revisions.txt:'rev{tilde}n', e.g. 'master{tilde}3'::
Documentation/revisions.txt:'rev{caret}\{type\}', e.g.
'v0.99.8{caret}\{commit\}'::
Documentation/revisions.txt:'rev{caret}\{\}', e.g. 'v0.99.8{caret}\{\}'::
Documentation/revisions.txt:'rev{caret}\{/text\}', e.g. 'HEAD^{/fix nasty
bug}'::
Documentation/revisions.txt:':/text', e.g. ':/fix nasty bug'::
Documentation/revisions.txt:'rev:path', e.g. 'HEAD:README', ':README',
'master:./README'::
Documentation/revisions.txt:':n:path', e.g. ':0:README', ':README'::
Documentation/revisions.txt:'rev{caret}@', e.g. 'HEAD{caret}@'::
Documentation/revisions.txt:'rev{caret}!', e.g. 'HEAD{caret}!'::
But the majority uses the two-line style:
$ git grep -A1 '::$' Documentation/*.txt | egrep '^--$|::$' | perl -ne
'$lastbreak=$. if /^--/; if ($lastbreak$.-1) {print $last$_; $last=;} else
{$last=$_;}'
Documentation/blame-options.txt:-p::
Documentation/blame-options.txt:--porcelain::
Documentation/config.txt:add.ignore-errors::
Documentation/config.txt:add.ignoreErrors::
Documentation/config.txt:format.to::
Documentation/config.txt:format.cc::
Documentation/config.txt:gc.reflogexpire::
Documentation/config.txt:gc.pattern.reflogexpire::
Documentation/config.txt:gc.reflogexpireunreachable::
Documentation/config.txt:gc.ref.reflogexpireunreachable::
Documentation/config.txt:gitweb.category::
Documentation/config.txt:gitweb.description::
[snip 800+ more lines]
Should we fix that?
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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
Build system bugs related to handling of 'LIBS' environment variable
Hello,
Git fails to build if LIBS contains -lpthread. To reproduce:
export LIBS=-lpthread
./configure
make V=1 git-credential-store
The bug is that linker command line does not contain -lpthread, so
linking fails.
configure respects LIBS and finds that it does not have to add
anything for pthread:
checking for POSIX Threads with ''... yes
But (first bug) configure does not pass the LIBS variable in
config.mak.autogen. Even if it did, Makefile would overwrite (second
bug) LIBS with:
LIBS = $(GITLIBS) $(EXTLIBS)
Makefile should rather append to LIBS.
Dmitri Gribenko
--
main(i,j){for(i=2;;i++){for(j=2;ji;j++){if(!(i%j)){j=0;break;}}if
(j){printf(%d\n,i);}}} /*Dmitri Gribenko griboz...@gmail.com*/
--
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-tag(1): we tag HEAD by default
Thomas Rast tr...@inf.ethz.ch writes: Junio C Hamano gits...@pobox.com writes: Thomas Rast tr...@inf.ethz.ch writes: +commit, object:: + The object that the new tag will refer to, usually a commit. + Defaults to HEAD. Shouldn't this be more like this: commit:: object:: Your explanation here... Hmm, you're right, but we seem to be fairly inconsistent in that department. There are some instances with the comma style: That is because we did not know better in the olden days, until somebody noticed and started using the separate-line form. We might have a patch or two to only convert from the comma-style but I do not recall us doing a whole-tree style clean-ups. Should we fix that? I personally do not think the churn is warranted. Fix the existing ones you notice as you touch the vicinity, and avoid introducing new ones is good enough. -- 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-tag(1): we tag HEAD by default
Hi,
Le 03.04.2013 16:27, Thomas Rast a écrit :
The commit|object argument is actually not explained anywhere
(except implicitly in the description of an unannotated tag). Write
a
little explanation, in particular to cover the default.
+commit, object::
+ The object that the new tag will refer to, usually a commit.
+ Defaults to HEAD.
+
+
This puzzled me a lot, so I try various configuration:
- I was able to create an annotated tag on an annotated tag (this can
be recursively)
git tag -a -m tagged a tag test_tag_tag v1.8.2
git show test_tag_tag
- I was able to tag a file
git tag -a -m tagged a file test_tag_file `git ls-tree HEAD | awk
'{ print $3; exit; }'`
git show test_tag_file
git show -p test_tag_file
Is there any other kind of object that can be tagged ... and what is
the purpose of this ?
Regards.
--
Yann Droneaud
OPTEYA
--
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-tag(1): we tag HEAD by default
Yann Droneaud ydrone...@opteya.com writes:
Hi,
Le 03.04.2013 16:27, Thomas Rast a écrit :
+commit, object::
+The object that the new tag will refer to, usually a commit.
+Defaults to HEAD.
Is there any other kind of object that can be tagged ... and what is
the purpose of this ?
Any object type, including tags. Signed tags of other tags probably
make sense if you want to express extra approval on top of the original
signature.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
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: Behavior of git rm
On Wed, Apr 03, 2013 at 07:50:24AM -0700, jpinheiro wrote:
While experimenting with git we found an unexpected behavior with git rm.
Here is a trace of the unexpected behavior:
$ git init
$ mkdir D
$ echo Hi D/F
$ git add D/F
$ rm -r D
$ echo Hey D
$ git rm D/F
warning: 'D/F': Not a directory
rm 'D/F'
fatal: git rm: 'D/F': Not a directory
We drop the D/F entry from the index, but then fail to actually remove
it from the filesystem, because it has already been replaced. It is
impossible to tell from this toy example what the true intent was, but
in such a situation, there is a reasonable chance that the user should
have invoked rm --cached in the first place.
That being said, we do try to handle files which have already gone
missing; when unlink() fails, we do not consider it an error if we got
ENOENT. We could perhaps add ENOTDIR to that list, as it also indicates
that the file is gone (it just happens that one of its prefix
directories was replaced with something else).
The opposite case is also interesting:
$ git init
$ echo 1 D
$ git add D
$ rm D
$ mkdir D
$ echo 2 D/F
$ git rm D
rm 'D'
fatal: git rm: 'D': Is a directory
We expect to see 'D' as a file, but it is now a directory. We _could_
recursively remove the directory, but that has the potential to delete
files that the user does not expect.
So in both cases, git rm could certainly detect the situation and
proceed with the destructive operation. But when there is such a
conflict between what's in the working tree and what's in the index, I
think we may be better off erring on the conservative side and bailing,
and letting the user reconcile the differences themselves (using either
git add or git rm --cached to update the index, or deciding how to
handle the working tree contents themselves with regular rm).
Of the two situations, I think the first one is less likely to be
destructive (noticing that a file is already gone via ENOTDIR), as we
are only proceeding with the index deletion, and we end up not touching
the filesystem at all. That patch would look something like:
diff --git a/builtin/rm.c b/builtin/rm.c
index dabfcf6..7b91d52 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -110,7 +110,7 @@ static int check_local_mod(unsigned char *head, int
index_only)
ce = active_cache[pos];
if (lstat(ce-name, st) 0) {
- if (errno != ENOENT)
+ if (errno != ENOENT errno != ENOTDIR)
warning('%s': %s, ce-name, strerror(errno));
/* It already vanished from the working tree */
continue;
diff --git a/dir.c b/dir.c
index 57394e4..f9e7355 100644
--- a/dir.c
+++ b/dir.c
@@ -1603,7 +1603,7 @@ int remove_path(const char *name)
{
char *slash;
- if (unlink(name) errno != ENOENT)
+ if (unlink(name) errno != ENOENT errno != ENOTDIR)
return -1;
slash = strrchr(name, '/');
--
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] http-backend: respect GIT_NAMESPACE with dumb clients
On Wed, Apr 03, 2013 at 08:52:09AM -0700, John Koleszar wrote: + SMART=smart + git ls-remote public expected + grep /$NS/ expected /dev/null + GET_BODY info/refs actual + test_cmp expected actual + GET_BODY info/refs?service=git-upload-pack | grep /$NS/ /dev/null + + SMART=smart_namespace + GIT_NAMESPACE=$NS export GIT_NAMESPACE + git ls-remote public expected + ! grep /$NS/ expected/dev/null + GET_BODY info/refs actual + test_cmp expected actual + ! (GET_BODY info/refs?service=git-upload-pack | grep /$NS/ /dev/null) +)' Hmm. This is testing just the ref advertisement. It would be nice to see a complete transaction tested with namespaces turned on. Something like this (squashed into your patch) seems to work for me: diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh index 47eb769..9fd8bbf 100755 --- a/t/t5551-http-fetch.sh +++ b/t/t5551-http-fetch.sh @@ -162,6 +162,18 @@ test_expect_success 'invalid Content-Type rejected' ' grep not valid: actual ' +test_expect_success 'create namespaced refs' ' + test_commit namespaced + git push public HEAD:refs/namespaces/ns/refs/heads/master +' + +test_expect_success 'clone respects namespace' ' + git clone --bare $HTTPD_URL/smart_namespace/repo.git ns.git + echo namespaced expect + git --git-dir=ns.git log -1 --format=%s actual + test_cmp expect actual +' + test -n $GIT_TEST_LONG test_set_prereq EXPENSIVE test_expect_success EXPENSIVE 'create 50,000 tags in the repo' ' -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git https transport and wrong password
On Wed, Apr 03, 2013 at 10:12:12AM -0400, Jeff King wrote: I would expect without the username in the URL for it to make only two requests: one to get the first 401, then git collects the credentials, then a follow-up with the credentials. But instead we get: $ GIT_CURL_VERBOSE=1 git ls-remote https://github.com/requires/auth \ 21 /dev/null | egrep '^|^ HTTP|^Authorization|requested URL' GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 * The requested URL returned error: 401 Authorization Required Username for 'https://github.com': foo Password for 'https://f...@github.com': GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 HTTP/1.1 401 Authorization Required GET /requires/auth/info/refs?service=git-upload-pack HTTP/1.1 Authorization: Basic Zm9vOmJhcg== HTTP/1.1 401 Authorization Required * The requested URL returned error: 401 So we get a 401, as expected, git prompts for the credentials and feeds them directly to curl, but then we still get _two_ requests: we trigger another 401, and only then does curl provide the authorization header to the server. I'm not sure if that extra auth is intended or not. git uses CURLAUTH_ANY which means: first try without authentication (CURLAUTH_NONE), if that fails it will try (I guess) CURLAUTH_BASIC|DIGEST| GSS|NTML and so on, and only then it will fail with the 401. It seems that skipping CURLAUTH_NONE try is not possible even if it's not a good idea when a username and possibly password is available. Changing CURLAUTH_ANY to skip CURLAUTH_NONE could also break other users. Since netrc support really needs this one try from git to curl before password prompt I guess in our case using HTTPS with git is simply not feasible. Changing the corporate single sign-on policies is also hard so I will now try to get SSH transport running on the server. Account locking will still be quite easy but hopefully only after multiple false passwords to the SSH promp. -Mikko -- 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] http-backend: respect GIT_NAMESPACE with dumb clients
On Wed, Apr 03, 2013 at 12:10:38PM -0400, Jeff King wrote: Hmm. This is testing just the ref advertisement. It would be nice to see a complete transaction tested with namespaces turned on. Something like this (squashed into your patch) seems to work for me: Actually, I guess the point of your patch was to fix the dumb-via-http-backend transport. So this would be more complete: diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh index 47eb769..b5032bd 100755 --- a/t/t5551-http-fetch.sh +++ b/t/t5551-http-fetch.sh @@ -162,6 +162,28 @@ test_expect_success 'invalid Content-Type rejected' ' grep not valid: actual ' +test_expect_success 'create namespaced refs' ' + test_commit namespaced + git push public HEAD:refs/namespaces/ns/refs/heads/master +' + +test_expect_success 'smart clone respects namespace' ' + git clone --bare $HTTPD_URL/smart_namespace/repo.git ns-smart.git + echo namespaced expect + git --git-dir=ns-smart.git log -1 --format=%s actual + test_cmp expect actual +' + +test_expect_success 'dumb clone via http-backend respects namespace' ' + git --git-dir=$HTTPD_DOCUMENT_ROOT_PATH/repo.git \ + config http.getanyfile true + GIT_SMART_HTTP=0 git clone --bare \ + $HTTPD_URL/smart_namespace/repo.git ns-dumb.git + echo namespaced expect + git --git-dir=ns-dumb.git log -1 --format=%s actual + test_cmp expect actual +' + test -n $GIT_TEST_LONG test_set_prereq EXPENSIVE test_expect_success EXPENSIVE 'create 50,000 tags in the repo' ' -- 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: Behavior of git rm
Jeff King p...@peff.net writes:
Of the two situations, I think the first one is less likely to be
destructive (noticing that a file is already gone via ENOTDIR), as we
are only proceeding with the index deletion, and we end up not touching
the filesystem at all.
Nice to see sound reasoning.
diff --git a/builtin/rm.c b/builtin/rm.c
index dabfcf6..7b91d52 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -110,7 +110,7 @@ static int check_local_mod(unsigned char *head, int
index_only)
ce = active_cache[pos];
if (lstat(ce-name, st) 0) {
- if (errno != ENOENT)
+ if (errno != ENOENT errno != ENOTDIR)
OK. We may be running lstat() on D/F but there may be D that is not
a directory. If it is a file, we get ENOTDIR.
By the way, if D is a dangling symlink, we get ENOENT; in such a
case, we report rm 'D/F' on the output and remove the index entry.
$ rm -f .git/index rm -fr D E
$ mkdir D D/F git add D rm -fr D
$ ln -s erewhon D git rm D/F git ls-files
rm 'D/F'
Also if D is a symlink that point at a directory E, git rm does
something interesting.
(1) Perhaps we want a complaint in this case.
$ rm -f .git/index rm -fr D E
$ mkdir D D/F git add D rm -fr D
$ mkdir E ln -s E D git rm D/F
(2) Perhaps we want to make sure D/F is not beyond a symlink in this
case.
$ rm -f .git/index rm -fr D E
$ mkdir D D/F git add D rm -fr D
$ mkdir E ln -s E D date E/F git rm D/F
$ git rm -f D/F
diff --git a/dir.c b/dir.c
index 57394e4..f9e7355 100644
--- a/dir.c
+++ b/dir.c
@@ -1603,7 +1603,7 @@ int remove_path(const char *name)
{
char *slash;
- if (unlink(name) errno != ENOENT)
+ if (unlink(name) errno != ENOENT errno != ENOTDIR)
return -1;
Ditto.
slash = strrchr(name, '/');
--
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] http-backend: respect GIT_NAMESPACE with dumb clients
John Koleszar jkoles...@google.com writes:
diff --git a/t/t5561-http-backend.sh b/t/t5561-http-backend.sh
index b5d7fbc..97f97a1 100755
--- a/t/t5561-http-backend.sh
+++ b/t/t5561-http-backend.sh
@@ -23,6 +23,10 @@ GET() {
test_cmp exp act
}
+GET_BODY() {
+ curl $HTTPD_URL/$SMART/repo.git/$1
+}
+
POST() {
curl --include --data $2 \
--header Content-Type: application/x-$1-request \
@@ -134,6 +138,13 @@ POST /smart/repo.git/git-receive-pack HTTP/1.1 200 -
###
GET /smart/repo.git/info/refs?service=git-receive-pack HTTP/1.1 403 -
POST /smart/repo.git/git-receive-pack HTTP/1.1 403 -
+
+### namespace test
+###
+GET /smart/repo.git/info/refs HTTP/1.1 200
+GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
+GET /smart_namespace/repo.git/info/refs HTTP/1.1 200
+GET /smart_namespace/repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
EOF
test_expect_success 'server request log matches test results' '
sed -e
diff --git a/t/t556x_common b/t/t556x_common
index 82926cf..6c34f33 100755
--- a/t/t556x_common
+++ b/t/t556x_common
@@ -120,3 +120,28 @@ test_expect_success 'http.receivepack false' '
GET info/refs?service=git-receive-pack 403 Forbidden
POST git-receive-pack 403 Forbidden
'
+test_expect_success 'backend respects namespaces' '(
A blank line before this new test would be easier to read.
+ log_div namespace test
+ config http.uploadpack true
+ config http.getanyfile true
+
+ NS=ns
+ (cd $HTTPD_DOCUMENT_ROOT_PATH/repo.git
+ git update-ref refs/namespaces/$NS/refs/heads/master HEAD
+ )
+
+ SMART=smart
+ git ls-remote public expected
+ grep /$NS/ expected /dev/null
The standard output is not shown while running tests without -v,
and matches like these are useful while diagnosing what went wrong,
so there is no upside in sending it to /dev/null in general.
+ GET_BODY info/refs actual
+ test_cmp expected actual
+ GET_BODY info/refs?service=git-upload-pack | grep /$NS/ /dev/null
Can GET_BODY fail for some reason with non-zero status (perhaps the
backend by mistake barfs, refuses to serve that request and dies)?
It does not sounds like a good idea to hide that status behind a pipe.
+ SMART=smart_namespace
+ GIT_NAMESPACE=$NS export GIT_NAMESPACE
+ git ls-remote public expected
+ ! grep /$NS/ expected/dev/null
Is it sufficient to make sure that GIT_NAMESPACE hides /ns/ from the
advertisement and not test that everything in that namespace is
actually shown?
+ GET_BODY info/refs actual
+ test_cmp expected actual
+ ! (GET_BODY info/refs?service=git-upload-pack | grep /$NS/ /dev/null)
Likewise, also for the pipe. If GET_BODY died and failed to produce
any output, we would certainly not see /ns/ in its output and the
test will pass.
+)'
--
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] http-backend: respect GIT_NAMESPACE with dumb clients
Jeff King p...@peff.net writes: On Wed, Apr 03, 2013 at 12:10:38PM -0400, Jeff King wrote: Hmm. This is testing just the ref advertisement. It would be nice to see a complete transaction tested with namespaces turned on. Something like this (squashed into your patch) seems to work for me: Actually, I guess the point of your patch was to fix the dumb-via-http-backend transport. So this would be more complete: Yeah, sounds sensible to me. diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh index 47eb769..b5032bd 100755 --- a/t/t5551-http-fetch.sh +++ b/t/t5551-http-fetch.sh @@ -162,6 +162,28 @@ test_expect_success 'invalid Content-Type rejected' ' grep not valid: actual ' +test_expect_success 'create namespaced refs' ' + test_commit namespaced + git push public HEAD:refs/namespaces/ns/refs/heads/master +' + +test_expect_success 'smart clone respects namespace' ' + git clone --bare $HTTPD_URL/smart_namespace/repo.git ns-smart.git + echo namespaced expect + git --git-dir=ns-smart.git log -1 --format=%s actual + test_cmp expect actual +' + +test_expect_success 'dumb clone via http-backend respects namespace' ' + git --git-dir=$HTTPD_DOCUMENT_ROOT_PATH/repo.git \ + config http.getanyfile true + GIT_SMART_HTTP=0 git clone --bare \ + $HTTPD_URL/smart_namespace/repo.git ns-dumb.git + echo namespaced expect + git --git-dir=ns-dumb.git log -1 --format=%s actual + test_cmp expect actual +' + test -n $GIT_TEST_LONG test_set_prereq EXPENSIVE test_expect_success EXPENSIVE 'create 50,000 tags in the repo' ' -- 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-tag(1): we tag HEAD by default
Thomas Rast tr...@inf.ethz.ch writes:
There are some instances with the comma style:
$ git grep ',.*::$' Documentation/*.txt
Documentation/blame-options.txt:-L start,end, -L :regex::
Documentation/config.txt:gitcvs.dbuser, gitcvs.dbpass::
Documentation/config.txt:http.lowSpeedLimit, http.lowSpeedTime::
Documentation/git-add.txt:-e, \--edit::
Documentation/git-check-attr.txt:-a, --all::
Documentation/git-check-ignore.txt:-q, --quiet::
Documentation/git-check-ignore.txt:-v, --verbose::
Documentation/git-log.txt:-L start,end:file, -L :regex:file::
Documentation/git-p4.txt:--verbose, -v::
Documentation/git-p4.txt:--dry-run, -n::
Documentation/git-tag.txt:commit, object::
The above are clearly candidate for clean-ups (the last one is your
making I already killed in this thread, isn't it?).
These are false matches, I think.
Documentation/diff-options.txt:--stat[=width[,name-width[,count]]]::
Documentation/diff-options.txt:--dirstat[=param1,param2,...]::
Documentation/git-index-pack.txt:--index-version=version[,offset]::
Documentation/git-log.txt:git log -L '/int main/',/^}/:main.c::
Documentation/git-p4.txt://depot/my/project@1,6::
Documentation/git-pack-objects.txt:--index-version=version[,offset]::
Documentation/git-remote-fd.txt:`git push fd::7,8 master (as URL)`::
Documentation/git-remote-fd.txt:`git push fd::7,8/bar master`::
Documentation/git-reset.txt:Undo a commit, making it a topic branch::
Documentation/git-shortlog.txt:-w[width[,indent1[,indent2]]]::
Documentation/git-show-branch.txt:--reflog[=n[,base]] [ref]::
I am not sure about these A, e.g. B, C:: entries. I tend to think
that they are all logically a single entry, that happen to have
commas in their entry heading, and fall into the same false
matches category as above.
Documentation/revisions.txt:'sha1', e.g.
'dae86e1950b1277e545cee180551750029cfe735', 'dae86e'::
Documentation/revisions.txt:'describeOutput', e.g.
'v1.7.4.2-679-g3bee7fb'::
Documentation/revisions.txt:'refname', e.g. 'master', 'heads/master',
'refs/heads/master'::
Documentation/revisions.txt:'refname@\{date\}', e.g.
'master@\{yesterday\}', 'HEAD@\{5 minutes ago\
Documentation/revisions.txt:'refname@\{n\}', e.g. 'master@\{1\}'::
Documentation/revisions.txt:'@\{n\}', e.g. '@\{1\}'::
Documentation/revisions.txt:'@\{-n\}', e.g. '@\{-1\}'::
Documentation/revisions.txt:'branchname@\{upstream\}', e.g.
'master@\{upstream\}', '@\{u\}'::
Documentation/revisions.txt:'rev{caret}', e.g. 'HEAD{caret},
v1.5.1{caret}0'::
Documentation/revisions.txt:'rev{tilde}n', e.g. 'master{tilde}3'::
Documentation/revisions.txt:'rev{caret}\{type\}', e.g.
'v0.99.8{caret}\{commit\}'::
Documentation/revisions.txt:'rev{caret}\{\}', e.g. 'v0.99.8{caret}\{\}'::
Documentation/revisions.txt:'rev{caret}\{/text\}', e.g. 'HEAD^{/fix
nasty bug}'::
Documentation/revisions.txt:':/text', e.g. ':/fix nasty bug'::
Documentation/revisions.txt:'rev:path', e.g. 'HEAD:README', ':README',
'master:./README'::
Documentation/revisions.txt:':n:path', e.g. ':0:README', ':README'::
Documentation/revisions.txt:'rev{caret}@', e.g. 'HEAD{caret}@'::
Documentation/revisions.txt:'rev{caret}!', e.g. 'HEAD{caret}!'::
--
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-tag(1): we tag HEAD by default
Thomas Rast tr...@inf.ethz.ch writes: Yann Droneaud ydrone...@opteya.com writes: ... Is there any other kind of object that can be tagged ... and what is the purpose of this ? Any object type, including tags. Signed tags of other tags probably make sense if you want to express extra approval on top of the original signature. I looked at what git show implements, and it seems to peel each level of tags to show all of them, which is very good. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] bisect: avoid signed integer overflow
Signed-off-by: John Keeping j...@keeping.me.uk
---
Changes since v1:
- Change the function signature instead of casting a value in the
function.
- This lets us remove an existing cast.
bisect.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bisect.c b/bisect.c
index bd1b7b5..374d9e2 100644
--- a/bisect.c
+++ b/bisect.c
@@ -525,9 +525,9 @@ struct commit_list *filter_skipped(struct commit_list *list,
* is increased by one between each call, but that should not matter
* for this application.
*/
-static int get_prn(int count) {
+static unsigned get_prn(unsigned count) {
count = count * 1103515245 + 12345;
- return ((unsigned)(count/65536) % PRN_MODULO);
+ return (count/65536) % PRN_MODULO;
}
/*
--
1.8.2.540.gf023cfe
--
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] diffcore-break: don't divide by zero
When the source file is empty, the calculation of the merge score results in a division by zero. In the situation: == preimage == == postimage == F (empty file) F (a large file) E (a new empty file) it does not make sense to consider F-E as a rename, so it is better not to break the pre- and post-image of F. Bail out early in this case to avoid hitting the divide-by-zero. This causes the merge score to be left at zero. Signed-off-by: John Keeping j...@keeping.me.uk --- On Tue, Apr 02, 2013 at 03:41:10PM -0700, Junio C Hamano wrote: John Keeping j...@keeping.me.uk writes: The message for commit 6dd4b66 (Fix diffcore-break total breakage) indicates that don't bother to break small files is wrong in some cases, but it I wonder if don't bother to break empty files is okay. This has a rather subtle ramifications, and we would need to think carefully. break does two very different things, and the criteria you would want to use to decide to break a filepair depends on which one you are interested in. The very original motivation of break was to show a patch that rewrites an existing file completely in a way different from the usual diff -u output, which will try to minimize the output by finding (rare) lines that happen to be the same between the preimage and postimage, intersparsed in many lines of - (deletion) and + (addition). Such a change is often easier to understand when shown as a single block of - (deletion) of the entire original contents, followed by a single block of + (addition) of the entire new contents. A totally separate motivation of break is the one Linus talks about in the log message of the said commit. A path filename.h was moved to filename_32.h, and a new (and much smaller) filename.h was introduced, that #includes filename_32.h. diff -M that pairs deleted files with created files to compute renames in such a case would not consider the original filename.h as a possible source of filename_32.h that was created. You want to break modification of filename.h into (virtual) deletion and addition of filename.h. For the purpose of the former, you would want not to break a file too aggressively. If you started from a file with 1000 lines in it, and deleted 910 lines and added 10 lines to result in a file with 100 lines, you still have 90 lines of shared contents between the preimage and the postimage, and you do not want to show it as delete 1000 lines and add 100 lines. You would want to base your decision on how much common material exists between the two. For the purpose of the latter, however, it is better to err on the side of breaking than not breaking. After breaking a suspicious modification into addition and deletion, if rename comparison does not find a suitable destination for the virtual deletion, the broken halves will be merged back, so breaking too little can hurt by missing potential renames, but breaking too much will not. You do want to break the 900 deleted out of 1000 and then added 10 case, as that 900 lines may have gone to another file that was created in the same commit. But we have 90 lines of common material does not matter for the decision to break. In today's code, the return value of should_break() is about the latter, while the score it stores in *merge_score is about the former. Thanks for this explanation. Following it through, it seems that bailing out early when the destination is empty will do the wrong thing, whereas letting the code carry on should result in a merge score of MAX_SCORE and the function returning 1. So it seems that the patch you proposed is the best way to handle this. diffcore-break.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/diffcore-break.c b/diffcore-break.c index 44f8678..1d9e530 100644 --- a/diffcore-break.c +++ b/diffcore-break.c @@ -68,6 +68,9 @@ static int should_break(struct diff_filespec *src, if (max_size MINIMUM_BREAK_SIZE) return 0; /* we do not break too small filepair */ + if (!src-size) + return 0; /* we do not let empty files get renamed */ + if (diffcore_count_changes(src, dst, src-cnt_data, dst-cnt_data, 0, -- 1.8.2.540.gf023cfe -- 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] Documentation: Strip texinfo anchors to avoid duplicates
This keeps texinfo 5.x happy. See https://bugs.gentoo.org/464210.
Signed-off-by: Martin von Gagern martin.vgag...@gmx.net
---
Documentation/cat-texi.perl | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl
index dbc133c..b52660d 100755
--- a/Documentation/cat-texi.perl
+++ b/Documentation/cat-texi.perl
@@ -12,6 +12,7 @@ while (STDIN) {
push @menu, $1;
}
s/\(\@pxref{\[(URLS|REMOTES)\]}\)//;
+ s/\@anchor\{[^{}]*\}//g;
print TMP;
}
close TMP;
--
1.8.1.5
--
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/RFC 0/3] Teach mv to move submodules
This is the last topic I intend to finish before preparing the recursive submodule update. The other prerequisites for that next step are Heiko's allow more sources for config values and fetch moved submodules on-demand topics, which are necessary to populate submodules that were not present in the currently checked out commit and to have all commits of moved or currently not present submodules fetched for later checkout respectively. But these are other threads ... Let's enable users to move submodules (just as easy as they can already remove them with current Git with git rm) by using a plain git mv. While using git submodule update on a moved submodule cloned by a coworker will still leave the submodule's work tree lying around at the old path, that will be fixed by the recursive submodule update (and is not different from what Git currently does with removed submodules). Replacing a directory containing files tracked by Git or vice versa is still not possible, another issue to be fixed by the recursive submodule update. I tried to CC all parties which showed interest in this topic, hopefully I didn't forget anyone. Jens Lehmann (3): Teach mv to move submodules together with their work trees Teach mv to move submodules using a gitfile Teach mv to update the path entry in .gitmodules for moved submodules builtin/mv.c | 126 ++ submodule.c | 126 ++ submodule.h | 3 ++ t/t7001-mv.sh | 94 +++ 4 files changed, 297 insertions(+), 52 deletions(-) -- 1.8.2.377.g1bdb7d0 -- 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/RFC 2/3] Teach mv to move submodules using a gitfile
When moving a submodule which uses a gitfile to point to the git directory
stored in .git/modules/name of the superproject two changes must be made
to make the submodule work: the .git file and the core.worktree setting
must be adjusted to point from work tree to git directory and back.
Achieve that by remembering which submodule uses a gitfile by storing the
result of read_gitfile() of each submodule. If that is not NULL the new
function connect_work_tree_and_git_dir() is called after renaming the
submodule's work tree which updates the two settings to the new values.
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---
builtin/mv.c | 19 ++
submodule.c | 64 +++
submodule.h | 1 +
t/t7001-mv.sh | 19 ++
4 files changed, 99 insertions(+), 4 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 361028d..609bbb8 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -9,6 +9,7 @@
#include cache-tree.h
#include string-list.h
#include parse-options.h
+#include submodule.h
static const char * const builtin_mv_usage[] = {
N_(git mv [options] source... destination),
@@ -65,7 +66,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('k', NULL, ignore_errors, N_(skip move/rename
errors)),
OPT_END(),
};
- const char **source, **destination, **dest_path;
+ const char **source, **destination, **dest_path, **submodule_gitfile;
enum update_mode { BOTH = 0, WORKING_DIRECTORY, INDEX } *modes;
struct stat st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
@@ -84,6 +85,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
source = copy_pathspec(prefix, argv, argc, 0);
modes = xcalloc(argc, sizeof(enum update_mode));
dest_path = copy_pathspec(prefix, argv + argc, 1, 0);
+ submodule_gitfile = xcalloc(argc, sizeof(char *));
if (dest_path[0][0] == '\0')
/* special case: . was normalized to */
@@ -119,8 +121,14 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
else if (src_is_dir) {
int first = cache_name_pos(src, length);
if (first = 0) {
+ struct strbuf submodule_dotgit = STRBUF_INIT;
if (!S_ISGITLINK(active_cache[first]-ce_mode))
die (_(Huh? Directory %s is in index
and no submodule?), src);
+ strbuf_addf(submodule_dotgit, %s/.git, src);
+ submodule_gitfile[i] =
read_gitfile(submodule_dotgit.buf);
+ if (submodule_gitfile[i])
+ submodule_gitfile[i] =
xstrdup(submodule_gitfile[i]);
+ strbuf_release(submodule_dotgit);
} else {
const char *src_w_slash = add_slash(src);
int last, len_w_slash = length + 1;
@@ -215,9 +223,12 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
int pos;
if (show_only || verbose)
printf(_(Renaming %s to %s\n), src, dst);
- if (!show_only mode != INDEX
- rename(src, dst) 0 !ignore_errors)
- die_errno (_(renaming '%s' failed), src);
+ if (!show_only mode != INDEX) {
+ if (rename(src, dst) 0 !ignore_errors)
+ die_errno (_(renaming '%s' failed), src);
+ if (submodule_gitfile[i])
+ connect_work_tree_and_git_dir(dst,
submodule_gitfile[i]);
+ }
if (mode == WORKING_DIRECTORY)
continue;
diff --git a/submodule.c b/submodule.c
index 975bc87..eba9b42 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1001,3 +1001,67 @@ int merge_submodule(unsigned char result[20], const char
*path,
free(merges.objects);
return 0;
}
+
+/* Update gitfile and core.worktree setting to connect work tree and git dir */
+void connect_work_tree_and_git_dir(const char *work_tree, const char *git_dir)
+{
+ struct strbuf core_worktree_setting = STRBUF_INIT;
+ struct strbuf configfile_name = STRBUF_INIT;
+ struct strbuf gitfile_content = STRBUF_INIT;
+ struct strbuf gitfile_name = STRBUF_INIT;
+ const char *real_work_tree = real_path(work_tree);
+ const char *pathspec[] = { real_work_tree, git_dir, NULL };
+ const char *max_prefix = common_prefix(pathspec);
+ FILE *fp;
+
+ if (max_prefix) { /* skip common prefix */
+ size_t max_prefix_len = strlen(max_prefix);
+ real_work_tree += max_prefix_len;
+ git_dir +=
[PATCH/RFC 3/3] Teach mv to update the path entry in .gitmodules for moved submodules
Currently using git mv on a submodule moves the submodule's work tree in
that of the superproject. But the submodule's path setting in .gitmodules
is left untouched, which is now inconsistent with the work tree and makes
git commands that rely on the proper path - name mapping (like status and
diff) behave strangely.
Let git mv help here by not only moving the submodule's work tree but
also updating the submodule.submodule name.path setting from the
.gitmodules file and stage both. This doesn't happen when no .gitmodules
file is found and only issues a warning when it doesn't have a section for
this submodule. This is because the user might just use plain gitlinks
without the .gitmodules file or has already updated the path setting by
hand before issuing the git mv command (in which case the warning
reminds him that mv would have done that for him). Only when .gitmodules
is found and contains merge conflicts the mv command will fail and tell
the user to resolve the conflict before trying again.
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---
builtin/mv.c | 8 +++-
submodule.c | 62 +++
submodule.h | 2 ++
t/t7001-mv.sh | 41 +++
4 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 609bbb8..36e5605 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -57,7 +57,7 @@ static struct lock_file lock_file;
int cmd_mv(int argc, const char **argv, const char *prefix)
{
- int i, newfd;
+ int i, newfd, gitmodules_modified = 0;
int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
struct option builtin_mv_options[] = {
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -71,6 +71,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
struct stat st;
struct string_list src_for_dst = STRING_LIST_INIT_NODUP;
+ gitmodules_config();
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_mv_options,
@@ -228,6 +229,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
die_errno (_(renaming '%s' failed), src);
if (submodule_gitfile[i])
connect_work_tree_and_git_dir(dst,
submodule_gitfile[i]);
+ if (!update_path_in_gitmodules(src, dst))
+ gitmodules_modified = 1;
}
if (mode == WORKING_DIRECTORY)
@@ -239,6 +242,9 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
rename_cache_entry_at(pos, dst);
}
+ if (gitmodules_modified)
+ stage_updated_gitmodules();
+
if (active_cache_changed) {
if (write_cache(newfd, active_cache, active_nr) ||
commit_locked_index(lock_file))
diff --git a/submodule.c b/submodule.c
index eba9b42..fb742b4 100644
--- a/submodule.c
+++ b/submodule.c
@@ -10,6 +10,7 @@
#include string-list.h
#include sha1-array.h
#include argv-array.h
+#include blob.h
static struct string_list config_name_for_path;
static struct string_list config_fetch_recurse_submodules_for_name;
@@ -30,6 +31,67 @@ static struct sha1_array ref_tips_after_fetch;
*/
static int gitmodules_is_unmerged;
+/*
+ * Try to update the path entry in the submodule.name section of the
+ * .gitmodules file.
+ */
+int update_path_in_gitmodules(const char *oldpath, const char *newpath)
+{
+ struct strbuf entry = STRBUF_INIT;
+ struct string_list_item *path_option;
+
+ if (!file_exists(.gitmodules)) /* Do nothing whithout .gitmodules */
+ return -1;
+
+ if (gitmodules_is_unmerged)
+ die(_(Cannot change unmerged .gitmodules, resolve merge
conflicts first));
+
+ path_option = unsorted_string_list_lookup(config_name_for_path,
oldpath);
+ if (!path_option) {
+ warning(_(Could not find section in .gitmodules where
path=%s), oldpath);
+ return -1;
+ }
+ strbuf_addstr(entry, submodule.);
+ strbuf_addstr(entry, path_option-util);
+ strbuf_addstr(entry, .path);
+ if (git_config_set_in_file(.gitmodules, entry.buf, newpath) 0) {
+ /* Maybe the user already did that, don't error out here */
+ warning(_(Could not update .gitmodules entry %s), entry.buf);
+ return -1;
+ }
+ strbuf_release(entry);
+ return 0;
+}
+
+void stage_updated_gitmodules(void)
+{
+ struct strbuf buf = STRBUF_INIT;
+ struct stat st;
+ int pos;
+ struct cache_entry *ce;
+ int namelen = strlen(.gitmodules);
+
+ pos = cache_name_pos(.gitmodules, strlen(.gitmodules));
+ if (pos 0) {
+ warning(_(could not find .gitmodules in index));
+ return;
+ }
+ ce = active_cache[pos];
+
[PATCH/RFC 1/3] Teach mv to move submodules together with their work trees
Currently the attempt to use git mv on a submodule errors out with:
fatal: source directory is empty, source=src, destination=dest
The reason is that mv searches for the submodule with a trailing slash in
the index, which it doesn't find (because it is stored without a trailing
slash). As it doesn't find any index entries inside the submodule it
claims the directory would be empty even though it isn't.
Fix that by searching for the name without a trailing slash and continue
if it is a submodule. Then rename() will move the submodule work tree just
like it moves a file.
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---
builtin/mv.c | 99 +++
t/t7001-mv.sh | 34
2 files changed, 86 insertions(+), 47 deletions(-)
diff --git a/builtin/mv.c b/builtin/mv.c
index 034fec9..361028d 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -117,55 +117,60 @@ int cmd_mv(int argc, const char **argv, const char
*prefix)
lstat(dst, st) == 0)
bad = _(cannot move directory over file);
else if (src_is_dir) {
- const char *src_w_slash = add_slash(src);
- int len_w_slash = length + 1;
- int first, last;
-
- modes[i] = WORKING_DIRECTORY;
-
- first = cache_name_pos(src_w_slash, len_w_slash);
- if (first = 0)
- die (_(Huh? %.*s is in index?),
- len_w_slash, src_w_slash);
-
- first = -1 - first;
- for (last = first; last active_nr; last++) {
- const char *path = active_cache[last]-name;
- if (strncmp(path, src_w_slash, len_w_slash))
- break;
- }
- free((char *)src_w_slash);
-
- if (last - first 1)
- bad = _(source directory is empty);
- else {
- int j, dst_len;
-
- if (last - first 0) {
- source = xrealloc(source,
- (argc + last - first)
- * sizeof(char *));
- destination = xrealloc(destination,
- (argc + last - first)
- * sizeof(char *));
- modes = xrealloc(modes,
- (argc + last - first)
- * sizeof(enum
update_mode));
+ int first = cache_name_pos(src, length);
+ if (first = 0) {
+ if (!S_ISGITLINK(active_cache[first]-ce_mode))
+ die (_(Huh? Directory %s is in index
and no submodule?), src);
+ } else {
+ const char *src_w_slash = add_slash(src);
+ int last, len_w_slash = length + 1;
+
+ modes[i] = WORKING_DIRECTORY;
+
+ first = cache_name_pos(src_w_slash,
len_w_slash);
+ if (first = 0)
+ die (_(Huh? %.*s is in index?),
+ len_w_slash,
src_w_slash);
+
+ first = -1 - first;
+ for (last = first; last active_nr; last++) {
+ const char *path =
active_cache[last]-name;
+ if (strncmp(path, src_w_slash,
len_w_slash))
+ break;
}
-
- dst = add_slash(dst);
- dst_len = strlen(dst);
-
- for (j = 0; j last - first; j++) {
- const char *path =
- active_cache[first + j]-name;
- source[argc + j] = path;
- destination[argc + j] =
- prefix_path(dst, dst_len,
- path + length + 1);
- modes[argc + j] = INDEX;
+ free((char *)src_w_slash);
+
+ if (last - first 1)
+ bad = _(source directory
Re: [PATCH] Documentation/git-commit: reword the --amend explanation
Junio C Hamano gits...@pobox.com writes: Yes, and since then we gained --no-edit option and such, so editor starts off also needs to be rethought, no? The original wording with seeded may have a better chance of survival, I suspect, but still needs some adjustment. So here is my attempt. We still need a sign-off from you even if we decide to use this version. Relative to your original patch: * Using amend to explain what --amend does felt a bit tautological; I moved the replaces it to the opening. * We do not necessarily launch the editor, and if you give the message in some other way we do not even reuse the original log message. * Mention --reset-author at the same time mentioning that by default the authorship is carried forward. * The commit is prepared as usual was meant to describe how the content to be recorded (i.e. the tree object contained in the resulting commit) is shaped, but I felt it a bit too unclear without saying either content or tree (it could be some other aspects of the commit like the log message and authorship, etc.) I tentatively replaced it with The recorded tree is prepared, but there may be a better phrasing. -- 8 -- From: Carlos Martín Nieto c...@elego.de The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. --- Documentation/git-commit.txt | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 19cbb90..bc919ac 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -190,14 +190,15 @@ OPTIONS without changing its commit message. --amend:: - Used to amend the tip of the current branch. Prepare the tree - object you would want to replace the latest commit as usual - (this includes the usual -i/-o and explicit paths), and the - commit log editor is seeded with the commit message from the - tip of the current branch. The commit you create replaces the - current tip -- if it was a merge, it will have the parents of - the current tip as parents -- so the current top commit is - discarded. + Create a new commit and replace the tip of the current + branch. The recorded tree is prepared as usual (including + the effect of the `-i` and `-o` options and explicit + pathspec), and the message from the original commit is used + as the starting point, instead of an empty message, when no + other message is specified from the command line via options + such as `-m`, `-F`, `-c`, etc. The new commit has the same + parents and author as the current one (the `--reset-author` + option can countermand this). + -- It is a rough equivalent for: -- 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] Documentation: Strip texinfo anchors to avoid duplicates
Martin von Gagern martin.vgag...@gmx.net writes:
This keeps texinfo 5.x happy. See https://bugs.gentoo.org/464210.
I see why duplicates are bad, but does that mean not having any is
better?
Signed-off-by: Martin von Gagern martin.vgag...@gmx.net
---
Documentation/cat-texi.perl | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/cat-texi.perl b/Documentation/cat-texi.perl
index dbc133c..b52660d 100755
--- a/Documentation/cat-texi.perl
+++ b/Documentation/cat-texi.perl
@@ -12,6 +12,7 @@ while (STDIN) {
push @menu, $1;
}
s/\(\@pxref{\[(URLS|REMOTES)\]}\)//;
+ s/\@anchor\{[^{}]*\}//g;
print TMP;
}
close TMP;
--
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: allowing multiple parallel sequencers
On Tue, Apr 02, 2013 at 03:06:51PM -0400, Neil Horman wrote: On Tue, Apr 02, 2013 at 11:06:28AM -0700, Junio C Hamano wrote: Neil Horman nhor...@tuxdriver.com writes: I've recently started looking into the possibility of having git support multiple in-progress sequencers, and wanted to solicit opinions for how best to do it The thoughts I had were: 1) A per branch sequence directory... 2) Augment the git-stash command... 3) A per branch working tree. That is how I would do this myself, anyway ;-) Not sure I completely follow. Are you suggesting that all untracked files, indexes and meta data in .git be saved during a branch switch? Thanks Neil -- Scratch that, after some digging I located the git-new-workdir script in the contrib directory, which does what we're talking about here. Thanks! Neil 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 -- 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
Github Data Challenge
Hi, hat jemand Lust da mit zu machen: https://github.com/blog/1450-the-github-data-challenge-ii ? V- -- 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: Behavior of git rm
On Wed, Apr 03, 2013 at 10:35:52AM -0700, Junio C Hamano wrote:
diff --git a/builtin/rm.c b/builtin/rm.c
index dabfcf6..7b91d52 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -110,7 +110,7 @@ static int check_local_mod(unsigned char *head, int
index_only)
ce = active_cache[pos];
if (lstat(ce-name, st) 0) {
- if (errno != ENOENT)
+ if (errno != ENOENT errno != ENOTDIR)
OK. We may be running lstat() on D/F but there may be D that is not
a directory. If it is a file, we get ENOTDIR.
By the way, if D is a dangling symlink, we get ENOENT; in such a
case, we report rm 'D/F' on the output and remove the index entry.
$ rm -f .git/index rm -fr D E
$ mkdir D D/F git add D rm -fr D
$ ln -s erewhon D git rm D/F git ls-files
rm 'D/F'
That seems sane to me, and makes me feel like handling ENOTDIR here is
the right direction. What that conditional is trying to say is if it
is because the file is not there..., and so far we know of three
conditions where it is not there:
1. There is no entry at that path.
2. There is a non-directory in the prefix of that path.
3. There is a dangling symlink in the prefix of that path.
(1) and (3) we already handle via ENOENT. I think it is sane to handle
(2) the same as (3), but we do not do so currently.
Also if D is a symlink that point at a directory E, git rm does
something interesting.
(1) Perhaps we want a complaint in this case.
$ rm -f .git/index rm -fr D E
$ mkdir D D/F git add D rm -fr D
$ mkdir E ln -s E D git rm D/F
I think that is OK without complaint; the user asked to get rid of D/F,
and it is indeed gone (as well as its index entry) after the call
finishes. And we did not even need to delete anything, so we cannot be
losing data. I am much more concerned about this case:
(2) Perhaps we want to make sure D/F is not beyond a symlink in this
case.
$ rm -f .git/index rm -fr D E
$ mkdir D D/F git add D rm -fr D
$ mkdir E ln -s E D date E/F git rm D/F
where the user is deleting something that may or may not be related to
the original D/F. On the other hand, I don't have that much sympathy;
rm would make the same deletion. But hmm...shouldn't we be doing an
up-to-date check? Indeed:
$ git rm D/F
error: 'D/F' has staged content different from both the file and the HEAD
(use -f to force removal)
$ git commit -m foo git rm D/F
$ git rm D/F
error: 'D/F' has local modifications
(use --cached to keep the file, or -f to force removal)
So I do not think we need any extra safety; the content-level checks
should be enough to make sure we are not losing anything.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: Strip texinfo anchors to avoid duplicates
On 03.04.2013 22:07, Junio C Hamano wrote: I see why duplicates are bad, but does that mean not having any is better? I'd say yes: duplicate anchors cause current versions of texinfo to reject the document outright, and older versions will likely cause a broken interpretation of any anchor names. What are possible scenarios where anchors could be useful? a) Internal cross reference. I'm not sure whether texinfo checks for broken internal links. If it does, it did not report any. b) Goto command issued by the user. I suppose most users would be happy with node-level navigation, and not use it for navigation to sub-node sections. c) URLs in bookmarks or mails. I suppose people are more likely to use the html documents built by asciidoc, instead of a version constructed from the texinfo document. So not our issue. Did I miss a relevant use case? Automatically (or even manually?) generated unique names might be better than none. But I'm not sure they are worth the trouble. Martin von Gagern signature.asc Description: OpenPGP digital signature
Re: Github Data Challenge
Please disregard this email, I made a mistake. * Valentin Haenel vhae...@elego.de [2013-04-03]: Hi, hat jemand Lust da mit zu machen: https://github.com/blog/1450-the-github-data-challenge-ii ? V- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/5] Help.c use OPT_BOOL and refactor logic
Sent: Wednesday, April 03, 2013 2:13 AM Junio C Hamano gits...@pobox.com writes: You are creating a gap in the output so that you can add some more stuff in later patches, which is fine, but I do not think we call that kind of change a refactor ;-). The change looks fine. I'll queue what I suggested on 'pu' for now. It looks good. I'm happy with your suggestions as queued. Acked-by: Philip Oakley philipoak...@iee.org Longer term I'd like to be able to show all the guides as a double -gg option, but this is a great start. Thanks. - -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/git-commit: reword the --amend explanation
Sent: Wednesday, April 03, 2013 9:04 PM Junio C Hamano gits...@pobox.com writes: Yes, and since then we gained --no-edit option and such, so editor starts off also needs to be rethought, no? The original wording with seeded may have a better chance of survival, I suspect, but still needs some adjustment. So here is my attempt. We still need a sign-off from you even if we decide to use this version. Relative to your original patch: * Using amend to explain what --amend does felt a bit tautological; I moved the replaces it to the opening. * We do not necessarily launch the editor, and if you give the message in some other way we do not even reuse the original log message. * Mention --reset-author at the same time mentioning that by default the authorship is carried forward. * The commit is prepared as usual was meant to describe how the content to be recorded (i.e. the tree object contained in the resulting commit) is shaped, but I felt it a bit too unclear without saying either content or tree (it could be some other aspects of the commit like the log message and authorship, etc.) I tentatively replaced it with The recorded tree is prepared, but there may be a better phrasing. -- 8 -- From: Carlos Martín Nieto c...@elego.de The explanation for 'git commit --amend' talks about preparing a tree object, which shouldn't be how user-facing documentation talks about commit. Reword it to say it works as usual, but replaces the current commit. --- Documentation/git-commit.txt | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 19cbb90..bc919ac 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -190,14 +190,15 @@ OPTIONS without changing its commit message. --amend:: - Used to amend the tip of the current branch. Prepare the tree - object you would want to replace the latest commit as usual - (this includes the usual -i/-o and explicit paths), and the - commit log editor is seeded with the commit message from the - tip of the current branch. The commit you create replaces the - current tip -- if it was a merge, it will have the parents of - the current tip as parents -- so the current top commit is - discarded. + Create a new commit and replace the tip of the current + branch. I don't think we should say Create New at the start of the sentence, which may confuse some, rather we should start with the key 'Replace' verb, essentially swapping the parts to say: + Replace the tip of the current branch with a fresh commit. [or updated commit, or new commit, or ...] The recorded tree is prepared as usual (including + the effect of the `-i` and `-o` options and explicit + pathspec), and the message from the original commit is used + as the starting point, instead of an empty message, when no + other message is specified from the command line via options + such as `-m`, `-F`, `-c`, etc. The new commit has the same + parents and author as the current one (the `--reset-author` + option can countermand this). + -- It is a rough equivalent for: -- Philip -- 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] perl: redirect stderr to /dev/null instead of closing
On my system, t9100.1 triggers the following warning:
==352== Syscall param write(buf) points to uninitialised byte(s)
==352==at 0x57119C0: __write_nocancel (in /lib64/libc-2.17.so)
==352==by 0x56AC1D2: _IO_file_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352==by 0x56AC0B1: new_do_write (in /lib64/libc-2.17.so)
==352==by 0x56AD3B4: _IO_do_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352==by 0x56AD6FE: _IO_file_overflow@@GLIBC_2.2.5 (in
/lib64/libc-2.17.so)
==352==by 0x56AE3D8: _IO_default_xsputn (in /lib64/libc-2.17.so)
==352==by 0x56ACAA2: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352==by 0x5682133: buffered_vfprintf (in /lib64/libc-2.17.so)
==352==by 0x567CE9D: vfprintf (in /lib64/libc-2.17.so)
==352==by 0x5687096: fprintf (in /lib64/libc-2.17.so)
==352==by 0x4E7AC5: vreportf (usage.c:15)
==352==by 0x4E7B14: die_builtin (usage.c:38)
The actual complaint appears to be a bug in the underlying
implementation. What's interesting here is that it is apparently
_triggered_ by closing stderr, which results in (from strace)
write(2, fatal: Needed a single revision\n, 32) = -1 EBADF (Bad file
descriptor)
write(2, \0, 1) = -1 EBADF (Bad file descriptor)
Closing stderr is a bad idea anyway: there is a very real chance that
we print fatal error messages to some other file that just happens to
be opened on the now-free FD 2. So let's not do that.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
The commit message is intentionally overdramatic on the chance of
printing stuff to bad places. The code is actually from way back in
2006 (!).
The t9100 problem bisects to e3bd4dd (git-svn: don't create master if
another head exists, 2012-06-24), but that's just changing some
verify_ref(), which asks to close stderr on the git-rev-parse process.
I can easily reproduce the underlying issue with a small test: running
#include stdio.h
int main ()
{
fprintf(stderr, %s%s\n, fatal: , needed a single revision);
return 0;
}
with
valgrind --log-fd=3 ./die_test 32 2-
results in pretty much the same warnings. I fail to see a reason
other than a glibc bug why
fprintf(stderr, %s%s\n, ...);
should attempt to write \0 -- all its inputs are C strings. But
maybe I'm missing something?
perl/Git.pm | 3 +++
1 file changed, 3 insertions(+)
diff --git a/perl/Git.pm b/perl/Git.pm
index 96cac39..3b79a36 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1495,6 +1495,9 @@ sub _command_common_pipe {
if ($opts{STDERR}) {
open (STDERR, '', $opts{STDERR})
or die dup failed: $!;
+ } elsif (defined $opts{STDERR}) {
+ open (STDERR, '', '/dev/null')
+ or die opening /dev/null failed: $!;
}
_cmd_exec($self, $cmd, @args);
}
--
1.8.2.551.g91a1e48
--
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: cd
On 04/03/2013 04:49 PM, jpinheiro wrote: Hi all, We are students from Universidade do Minho in Portugal, and we are using git in project as a case study. While experimenting with git we found an unexpected behavior with git rm. Here is a trace of the unexpected behavior: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey D $ git rm D/F warning: 'D/F': Not a directory rm 'D/F' fatal: git rm: 'D/F': Not a directory If the file D created with last echo did not exist or was named differently then no error would occur as expected. For example: $ git init $ mkdir D $ echo Hi D/F $ git add D/F $ rm -r D $ echo Hey F $ git rm D/F This works as expected, and the only difference is the name of the file of the last echo. Is this the expected behavior of git rm? Yes. The only difference between 'git rm' and 'rm' is that git rm also removes the file from its index and prepares to commit a version without it. From git's point of view, it's not an error if the file doesn't exist. It *is* an error if the directory where the file should reside suddenly no longer a directory though. -- Andreas Ericsson andreas.erics...@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- 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-web--browse: recognize iTerm as a GUI terminal on OS X
On Wed, Mar 27, 2013 at 10:43 AM, Junio C Hamano gits...@pobox.com wrote: [snip] If that approach is better than what you originally sent, then yes. But I do not use OS X, so you may need to pay attention to possible complaints and comments from other Mac users on this list for a while---there may be people who run the program in question without that environment variable. Sorry it has taken me so long to get back to this. I searched around and tried out a few terminal programs that are available, and I think what you queued--checking that TERM_PROGRAM is non-empty--is the right fix. Thanks! -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] remote-hg: general updates
On 03.04.2013, at 03:31, Felipe Contreras wrote: On Tue, Apr 2, 2013 at 4:23 PM, Max Horn m...@quendi.de wrote: On 02.04.2013, at 22:09, John Keeping wrote: On Tue, Apr 02, 2013 at 01:02:49PM -0600, Felipe Contreras wrote: Here is the next round of patches for remote-hg, some which have been contributed through github. Fortunately it seems to be working for the most part, but there are some considerable issues while pushing branches and tags. How does this compare to the current state of gitifyhg[1]? That's built on top of this git-remote-hg script but seems to have been more actively developed recently. I only learned about it recently, I've looked at the history and to me it seems rather chaotic, and a lot of the code was simply copied from git-remote-hg without comment. gitifyhg was scrapped and completely restarted from scratch at some point. Based largely on your git-remote-hg code. A bit more on its history can be read here: http://archlinux.me/dusty/2013/01/06/gitifyhg-rewritten/ * added many new test cases, sadly still including some xfails. Several of these (both passing and xfailing) also apply to remote-hg (i.e. the issue is also present in contrib's remote-hg) I ran these test-cases with remote-hg, and the same test-cases pass. I only had to do minor modifications, most of the failures came from subtle differences such as different strategies to sanitize authors, and which branch to pick for HEAD. Yeah, that's because what I wrote was based on the situation before your recent patch series. Glad to see that git/contrib's remote-hg is improving! * improved handling of hg user names (remote-hg is not able to deal with some pathological cases, failing to import commits). Sadly, mercurial allows arbitrary strings as usernames, git doesn't... I wouldn't call it improved. In some cases the remote-hg result is better, in others gitifyhg is, I'd love to learn about cases where remote-hg's result is better in your opinion, so that I can see if the mapping in gitifyhg could be improved for those cases. That said, this part is really quite subjective I guess. In the end, since Mercurial names can be *anything*, one can never get a perfect mapping. Luckily, for most real repositories out there, user names will be quite sane and remote-hg and gitifyhg will produce identical results. (Although some hg repos out there have some really weird stuff going on. Yuck.) but there's only a single case where the author name becomes a significant problem. It's a trivial fix. Excellent, looking forward to it then. * failed pushes to hg are cleanly rolled back (using mq.strip() from the mq extension), instead of resulting in inconsistent internal state. This is quite important in real life, and has bitten me several times with remote-hg (and was the initial reason why I switched to gitifyhg). A typical way to reproduce this is to push to a remote repository that has commits not yet in my local clone. This is not an issue in remote-hg any more since now we force the push. It's not nice, but there's no other way to push multiple bookmarks (aka git branches) to the same branch (aka commit label). Uhh, what? The push is forced? That sounds to me like a much, much bigger issue with remote-hg than anything else ever was, from my point of view. That seems tobe akin to making --force default to git push, and I don't think anybody here would consider that a good idea. I doubt these inconsistent states can happen any more, but if they do, Seriously? This is triggered quite frequently in real life. And it will very likely cause somebody to mess up a hg repository they work on. As long is this in, using remote-hg is a total no-go for me. Just consider the following scenario: * user A clones a hg repository into a git repository * user A commits some commits in the git clone * meanwhile, user B pushes changes to the hg repository * user A tries to push his changes to the hg remote The last step causes this result in gitifyhg (similar to what one gets when the remote is a git repos): ! [rejected]master - master (non-fast-forward) error: failed to push some refs to 'gitifyhg::URL' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (e.g. 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. With remote-hg, you just force push the change, creating a new head in the remote repo. So, yeah, failed pushes which mess up the internal state don't happen anymore. But I rather have those than potentially mess up the upstream repository like that. the plan in remote-hg is to simply ignore those revisions, and only push the ones that have git refs. I have the code for that, but I'll not be pushing it to git.git for the time being. I am not quite sure what you mean here, but I'll just
You do not have permission to post to the ms...@lists.myitforum.com list
Sorry, you do not have permission to post to the ms...@lists.myitforum.com mailing list. -- 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] perl: redirect stderr to /dev/null instead of closing
Thomas Rast tr...@inf.ethz.ch wrote:
Closing stderr is a bad idea anyway: there is a very real chance that
we print fatal error messages to some other file that just happens to
be opened on the now-free FD 2. So let's not do that.
100% agreed. FD 0, 1, and 2 should not be closed, way too much
potential for triggering rare bugs and interop issues like these to be
worth it.
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1495,6 +1495,9 @@ sub _command_common_pipe {
if ($opts{STDERR}) {
open (STDERR, '', $opts{STDERR})
or die dup failed: $!;
+ } elsif (defined $opts{STDERR}) {
+ open (STDERR, '', '/dev/null')
+ or die opening /dev/null failed: $!;
}
_cmd_exec($self, $cmd, @args);
}
Perhaps we should also do the following:
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1489,9 +1489,6 @@ sub _command_common_pipe {
if (not defined $pid) {
throw Error::Simple(open failed: $!);
} elsif ($pid == 0) {
- if (defined $opts{STDERR}) {
- close STDERR;
- }
if ($opts{STDERR}) {
open (STDERR, '', $opts{STDERR})
or die dup failed: $!;
--
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
Recently banned from #git
Hello, I am somewhat new to git and I was asking a lot of questions in #git without properly checking the manuals or knowing enough about linux. I want to apologize for my behavior and explain that I will do everything on my part to help answer the question on my own and read the documentation. I really do need help with git and #git seems the only place I can turn. Would it be possible to have the ban removed? I've spoken to charon already and have taken his recommendations. Thanks Jim -- 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-svn: avoid self-referencing mergeinfo
Michael Contreras mich...@inetric.com wrote: When svn.pushmergeinfo is set, the target branch is included in the mergeinfo if it was previously merged into one of the source branches. SVN does not do this. Remove merge target branch path from resulting mergeinfo when svn.pushmergeinfo is set to better match the behavior of SVN. Update the svn-mergeinfo-push test. Signed-off-by: Michael Contreras mich...@inetric.com Reported-by: Avishay Lavie avishay.la...@gmail.com Acked-by: Eric Wong normalper...@yhbt.net 80-column wrapped version pushed to git://bogomips.org/git-svn master (commit e5ee78e1f0835410a37bfa38e1ff5e1a82f8c7b5) Will ask Junio to pull unless Sam (our mergeinfo expert) gives a NACK soon. -- 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] update pasky's email address
Mail to pa...@suse.cz is bouncing.
Signed-off-by: Eric Wong normalper...@yhbt.net
---
I noticed this when I attempted to reply to Thomas's email:
http://mid.gmane.org/f3d238a4c6cfbc6d68f2c4fa285aefa93acf4b7d.1365027616.git.tr...@inf.ethz.ch
.mailmap| 1 +
Documentation/howto/rebase-from-internal-branch.txt | 4 ++--
gitweb/static/js/blame_incremental.js | 2 +-
gitweb/static/js/javascript-detection.js| 2 +-
gitweb/static/js/lib/common-lib.js | 2 +-
gitweb/static/js/lib/datetime.js| 2 +-
perl/Git.pm | 2 +-
7 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/.mailmap b/.mailmap
index c7e8618..1f01263 100644
--- a/.mailmap
+++ b/.mailmap
@@ -73,6 +73,7 @@ Nguyễn Thái Ngọc Duy pclo...@gmail.com
n...@fluxnic.net n...@cam.org
Peter Krefting pe...@softwolves.pp.se pe...@svarten.intern.softwolves.pp.se
Peter Krefting pe...@softwolves.pp.se pe...@softwolves.pp.se
+Petr Baudis pa...@ucw.cz pa...@suse.de
Philippe Bruhat b...@cpan.org
Ralf Thielow ralf.thie...@gmail.com ralf.thie...@googlemail.com
Ramsay Allan Jones ram...@ramsay1.demon.co.uk
diff --git a/Documentation/howto/rebase-from-internal-branch.txt
b/Documentation/howto/rebase-from-internal-branch.txt
index 19ab604..914d011 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -1,6 +1,6 @@
From: Junio C Hamano gits...@pobox.com
To:git@vger.kernel.org
-Cc:Petr Baudis pa...@suse.cz, Linus Torvalds torva...@osdl.org
+Cc:Petr Baudis pa...@ucw.cz, Linus Torvalds torva...@osdl.org
Subject: Re: sending changesets from the middle of a git tree
Date: Sun, 14 Aug 2005 18:37:39 -0700
Abstract: In this article, JC talks about how he rebases the
@@ -14,7 +14,7 @@ How to rebase from an internal branch
=
--
-Petr Baudis pa...@suse.cz writes:
+Petr Baudis pa...@ucw.cz writes:
Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
where Junio C Hamano jun...@cox.net told me that...
diff --git a/gitweb/static/js/blame_incremental.js
b/gitweb/static/js/blame_incremental.js
index db6eb50..e162ec9 100644
--- a/gitweb/static/js/blame_incremental.js
+++ b/gitweb/static/js/blame_incremental.js
@@ -1,5 +1,5 @@
// Copyright (C) 2007, Fredrik Kuivinen fre...@gmail.com
-// 2007, Petr Baudis pa...@suse.cz
+// 2007, Petr Baudis pa...@ucw.cz
// 2008-2011, Jakub Narebski jna...@gmail.com
/**
diff --git a/gitweb/static/js/javascript-detection.js
b/gitweb/static/js/javascript-detection.js
index fa2596f..3da2d2e 100644
--- a/gitweb/static/js/javascript-detection.js
+++ b/gitweb/static/js/javascript-detection.js
@@ -1,5 +1,5 @@
// Copyright (C) 2007, Fredrik Kuivinen fre...@gmail.com
-// 2007, Petr Baudis pa...@suse.cz
+// 2007, Petr Baudis pa...@ucw.cz
// 2008-2011, Jakub Narebski jna...@gmail.com
/**
diff --git a/gitweb/static/js/lib/common-lib.js
b/gitweb/static/js/lib/common-lib.js
index 018bbb7..9c3c465 100644
--- a/gitweb/static/js/lib/common-lib.js
+++ b/gitweb/static/js/lib/common-lib.js
@@ -1,5 +1,5 @@
// Copyright (C) 2007, Fredrik Kuivinen fre...@gmail.com
-// 2007, Petr Baudis pa...@suse.cz
+// 2007, Petr Baudis pa...@ucw.cz
// 2008-2011, Jakub Narebski jna...@gmail.com
/**
diff --git a/gitweb/static/js/lib/datetime.js b/gitweb/static/js/lib/datetime.js
index f78c60a..fdd46d3 100644
--- a/gitweb/static/js/lib/datetime.js
+++ b/gitweb/static/js/lib/datetime.js
@@ -1,5 +1,5 @@
// Copyright (C) 2007, Fredrik Kuivinen fre...@gmail.com
-// 2007, Petr Baudis pa...@suse.cz
+// 2007, Petr Baudis pa...@ucw.cz
// 2008-2011, Jakub Narebski jna...@gmail.com
/**
diff --git a/perl/Git.pm b/perl/Git.pm
index 96cac39..7802afc 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -1434,7 +1434,7 @@ sub git_cmd_try($) {
=head1 COPYRIGHT
-Copyright 2006 by Petr Baudis Eltpa...@suse.czegt.
+Copyright 2006 by Petr Baudis Eltpa...@ucw.czegt.
This module is free software; it may be used, copied, modified
and distributed under the terms of the GNU General Public Licence,
--
Eric Wong
--
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
Two potential bugs in aliases that expand to shell commands
These might just be documentation bugs. Aliases that expand to shell commands are only documented fairly superficially, but `git help config` does say: If the alias expansion is prefixed with an exclamation point, it will be treated as a shell command. It also says, nearer the beginning: String values may be entirely or partially enclosed in double quotes. You need to enclose variable values in double quotes if you want to preserve leading or trailing whitespace, or if the variable value contains comment characters (i.e. it contains # or ;). There appears to be another case string values need to be enclosed in quotes, which is a shell command where you want to preserve quote characters (not leading or trailing); a minimal example is shortcut = !cd pwd will act like you ran, in bash, $ cd pwd and print your homedir path, whereas shortcut = !cd \\ pwd will act like you ran, in bash, $ cd pwd and stay in the top-level directory of the repo (which is where aliases that expand to shell commands are run from). This is problematic precisely because aliases that expand to shell commands are run from the top-level directory of the repo: if you had an alias that worked great at the top-level directory, like shortcut = !do_something but it was doing the wrong thing in subdirectories, my first instinct, at least, upon reading Note that shell commands will be executed from the top-level directory of a repository, which may not necessarily be the current directory. GIT_PREFIX is set as returned by running git rev-parse --show-prefix from the original current directory., is to do shortcut = !cd $GIT_PREFIX do_something which will now do the right thing in subdirectories, but at the top-level directory of the repo, $GIT_PREFIX is undefined/the empty string, and it cds to your homedir. The other bug I'm much more confused by. If you have an alias like shortcut = !echo -n lol; echo wut it will, in fact, print -n lol wut which is, uh, not what bash prints. Is git special-casing echo? (I discovered these while adding something semi-jokingly to my .gitconfig: https://github.com/laughinghan/dotfiles/commit/34f5528825b287ff40acfe57808b32931a87261c ) Han -- 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
