Re: gitpacker progress report and a question
Felipe Contreras felipe.contre...@gmail.com: Most of those old projects have a linear history, INTERCAL didn't. There were two branches for platform ports. But different commit/author and respective dates, and merges? Sounds like overkill. I felt it was important that the metadata format be able to specify git's entire metadata and DAG semantics. Otherwise, as sure as the sun rises, *somebody* would run into a corner case not covered, and (quite rightly) curse me for a shortsighted fool who had done a half-assed job. I don't do half-assed jobs. Not ever, no way, nohow. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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 sale is certainly worth it
pandora sale http://www.pandorajewelrybuy.co.uk is one of the most sought after items of jewellery. This is for many reasons. Firstly, a Pandora diamond or necklace can be bought initially, but after the first purchase, consumers will both want to and need to buy more Pandora jewellery to add to their initial purchase. pandora jewellery uk http://www.pandorajewelrybuy.co.uk is therefore extremely popular in the uk and will continue to be popular for many years to come. Hopefully this news article has given you enough of an overview about Pandora jewellery. There are thousands of different drops and charms consumers can purchase, and the ones they buy is up to them but there are millions of different mixtures so they really will never have the same combination as a friend, relative or neighbour. The main problem with one of these home broadband speed estimates have been their difficult to rely on nature. OFCOM, the telecoms regulator, has recently expressed its concerns in the matter as more and more ISPs provide claims of the ability to provide rates of speed higher than is realistically possible. www.pandorajewelrybuy.co.uk -- View this message in context: http://git.661346.n2.nabble.com/pandora-sale-is-certainly-worth-it-tp7572063.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
[PATCH 0/4] t4041 (diff-submodule-option): minor cleanup
Hi, This is the result of one lazy afternoon. Ram Ramkumar Ramachandra (4): t4041 (diff-submodule-option): parse digests sensibly t4041 (diff-submodule-option): rewrite add_file() routine t4041 (diff-submodule-option): modernize style t4041 (diff-submodule-option): change tense of test names t/t4041-diff-submodule-option.sh | 484 +++--- 1 files changed, 240 insertions(+), 244 deletions(-) -- 1.7.8.1.362.g5d6df.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] t4041 (diff-submodule-option): parse digests sensibly
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t4041-diff-submodule-option.sh | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index 5377639..cfb71e5 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -21,7 +21,7 @@ add_file () {
test_tick
git commit -m Add $name
done /dev/null
- git rev-parse --verify HEAD | cut -c1-7
+ git rev-parse --short --verify HEAD
cd $owd
}
commit_file () {
@@ -33,7 +33,7 @@ test_create_repo sm1
add_file . foo /dev/null
head1=$(add_file sm1 foo1 foo2)
-fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead1=$(cd sm1; git rev-parse --verify $head1)
test_expect_success 'added submodule'
git add sm1
@@ -116,8 +116,8 @@ EOF
test_cmp expected actual
-fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
test_expect_success 'modified submodule(forward) --submodule=short'
+fullhead2=$(cd sm1; git rev-parse --verify $head2)
git diff --submodule=short actual
cat expected -EOF
diff --git a/sm1 b/sm1
@@ -135,7 +135,7 @@ commit_file sm1
head3=$(
cd sm1
git reset --hard HEAD~2 /dev/null
- git rev-parse --verify HEAD | cut -c1-7
+ git rev-parse --short --verify HEAD
)
test_expect_success 'modified submodule(backward)'
@@ -220,8 +220,8 @@ EOF
rm -f sm1
test_create_repo sm1
head6=$(add_file sm1 foo6 foo7)
-fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
test_expect_success 'nonexistent commit'
+fullhead6=$(cd sm1; git rev-parse --verify $head6)
git diff-index -p --submodule=log HEAD actual
cat expected -EOF
Submodule sm1 $head4...$head6 (commits not present)
@@ -318,8 +318,8 @@ EOF
(cd sm1; git commit -mchange foo6 /dev/null)
-head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7)
test_expect_success 'submodule is modified'
+head8=$(cd sm1; git rev-parse --short --verify HEAD)
git diff-index -p --submodule=log HEAD actual
cat expected -EOF
Submodule sm1 $head6..$head8:
@@ -461,7 +461,7 @@ EOF
test_cmp expected actual
-fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+fullhead7=$(cd sm2; git rev-parse --verify $head7)
test_expect_success 'given commit --submodule=short'
git diff-index -p --submodule=short HEAD^ actual
--
1.7.8.1.362.g5d6df.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] t4041 (diff-submodule-option): rewrite add_file() routine
Instead of cd there and then come back, use the cd there in a
subshell pattern. Also fix '' chaining in one place.
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t4041-diff-submodule-option.sh | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh b/t/t4041-diff-submodule-option.sh
index cfb71e5..103c690 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -11,18 +11,15 @@ This test tries to verify the sanity of the --submodule
option of git diff.
. ./test-lib.sh
add_file () {
- sm=$1
- shift
- owd=$(pwd)
- cd $sm
- for name; do
+ (cd $1
+ shift
+ for name; do
echo $name $name
git add $name
test_tick
git commit -m Add $name
- done /dev/null
- git rev-parse --short --verify HEAD
- cd $owd
+ done /dev/null
+ git rev-parse --short --verify HEAD)
}
commit_file () {
test_tick
--
1.7.8.1.362.g5d6df.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Tue, Nov 27, 2012 at 8:54 AM, David Aguilar dav...@gmail.com wrote: On Mon, Nov 26, 2012 at 5:11 AM, Felipe Contreras felipe.contre...@gmail.com wrote: http://www.mediawiki.org/wiki/Git/Graphical_User_Interfaces *cough* git-cola *cough* it runs everywhere. Yes, windows too. It's written in python. It's been actively maintained since 2007. % sudo pacman -S git-cola error: target not found: git-cola http://aur.archlinux.org/packages/gi/git-cola/git-cola.tar.gz % makepkg == Missing Dependencies: - python2-pyqt=4.3 == Checking buildtime dependencies... == Missing Dependencies: - asciidoc - docbook-xsl - rsync - xmlto - python2-sphinx=1.1.3 Sorry, no. I'm not sure if you have been following, but msysgit doesn't seem to have good support for python, let alone Qt. In my view the fact that it uses python is not a good thing. It's modern and has features that don't exist anywhere else. It even has tests. It even comes with a building full of willing guinea-pigs^Wtesters that let me know right away when anything goes wrong. It uses Qt but that's really the whole point of Qt - cross-platform. (not sure how that wiki page ended up saying Gnome/GTK?) Yes, Qt is cross-platform *in theory*, but have you used any Qt application in Windows? I haven't. The DAG aka git-dag (in its master branch, about to be released) is nicer looking then gitk IMO. gitk still has some features that are better too--there's no silver bullet, but the delta is pretty small. If you mean this one: http://1.1.1.5/bmi/git-cola.github.com/images/dag.png Then I wholeheartedly disagree. The only point this doesn't fulfill is dependency-free-ness. With that requirement the answer can *only* be tcl/tk. So saying, go look for one you won't find it is really a tautology. It's not even an entertaining one. That's the whole point; there is nothing else. If there was something else, there would be something else. But there isn't. When the requirement is, what is the best user experience possible, then you use a mature GUI library. These are different requirements and probably different use cases. But those are not the requirements. Anyways, just sayin', you make it sound like this stuff doesn't exist, but it does. I've never proposed it for mainline git because I'm very aware of the dependency requirements. A lot of stuff exists. And people use a lot of those. But they don't fulfill the requirements that I think gitk does perfectly. But, if git recommended it I would very much appreciate the extra eyes and contributions. Being in mainline git could possibly help with that. A submodule under contrib/ would be an interesting experiment. It might be, if somebody actually tried to submit the code. But I honestly doubt so. In any case, I think documenting the python standards (even if within contrib/ only) is a good thing. We'd be increasing the overall portability by documenting what we support and sticking to it, just like what is done for shell scripts and perl versions. Eric is helping make that happen, let's not throw out the baby with the bathwater. FWIW, I would also make my python expertise available. Nobody has argued that there shouldn't be guidelines for python code. What I have objected is to 'strict rules'. This thread has gotten into meta-meta territory -- it's discussing code that has not yet even been written, and going off on all sorts of tangents. That is the point; why should we change the policy for code that hasn't been written yet? That's not how things evolve in git as far as I have seen. BTW, Felipe, if you're going to be rewriting python code to ruby, please, pretty please rewrite that darn GUI ;-) I would need to write a widget toolkit first =/ I think I'll pass. gitk is fine. Cheers. -- 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: gitpacker progress report and a question
On Tue, Nov 27, 2012 at 9:36 AM, Eric S. Raymond e...@thyrsus.com wrote: Felipe Contreras felipe.contre...@gmail.com: Most of those old projects have a linear history, INTERCAL didn't. There were two branches for platform ports. Fine: tag v0.1 gst-av-0.1.tar Release 0.1 tag v0.2 gst-av-0.2.tar Release 0.2 checkout port1 tag v0.2-p1 gst-av-0.2-p1.tar Release 0.2 p1 checkout port2 v0.2 tag v0.2-p2 gst-av-0.2-p2.tar Release 0.2 p2 checkout master tag v0.3 gst-av-0.3.tar Release 0.3 Problem solved. But different commit/author and respective dates, and merges? Sounds like overkill. I felt it was important that the metadata format be able to specify git's entire metadata and DAG semantics. Otherwise, as sure as the sun rises, *somebody* would run into a corner case not covered, and (quite rightly) curse me for a shortsighted fool who had done a half-assed job. I'm willing to bet that won't happen. I don't do half-assed jobs. Not ever, no way, nohow. So you prefer code that is way more complicated that it needs to be, and with a higher likelihood of introducing bugs? There's a point of diminishing returns where the code that nobody uses causes bugs for real use-cases. That's not good. I prefer code that does one thing, and does it well. And when the need arises, evolve. Cheers. -- 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 0.5/4] t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
Ugh, line wrapping breaks my patch. I've attached a copy. Ram 0001-t4041-diff-submodule-option-don-t-hardcode-SHA-1-in-.patch Description: Binary data
Re: Python extension commands in git - request for policy change
On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar dav...@gmail.com wrote: *cough* git-cola *cough* it runs everywhere. Yes, windows too. It's written in python. It's been actively maintained since 2007. It's modern and has features that don't exist anywhere else. It even has tests. It even comes with a building full of willing guinea-pigs^Wtesters that let me know right away when anything goes wrong. It uses Qt but that's really the whole point of Qt - cross-platform. (not sure how that wiki page ended up saying Gnome/GTK?) The DAG aka git-dag (in its master branch, about to be released) is nicer looking then gitk IMO. gitk still has some features that are better too--there's no silver bullet, but the delta is pretty small. Gitk does a lot of things that people don't realise, since they're not really documented and you have to scrounge around on the UI. The thing is, it's just about the most awesome tool for code archeology I have seen. I realise (from looking at the doc page) that git-cola helps you do all sorts of things, but those are all things I am happier doing at the command line. Gitk does precisely those things which *require* a GUI, where the amount of information presented overwhelms a text interface. The display is concisely designed to give you the maximum information at a minimum space use. For example, a little black square when a commit has a note attached. Even hovering over the arrow-heads, on complex trees where the line gets broken, does something meaningful. if I had to pin it down, the feature I use most often is Show origin of this line. Other features I use often are - review a commit file by file (f and b keys, also spacebar and 'd') - search by SHA1 (4 digits appear to be enough, regardless of how big your repo is), - search for commits changing path/dir (while still showing all the commits; i.e., this is not 'git-dag -- README.txt' but within gitk you search up and down for commits touching README.txt - and navigating the commit tree looking for stuff http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to document some of the stuff I have found and use. One final point: the DAG on the right wastes enormous amounts of space. Purely subjectively, it is almost jarring on the senses. (If you reduce it, it becomes unreadable). With all due respect, git-cola/dag isn't anywhere near what gitk does, at least for people who are not afraid of the command line and only need the GUI to visualise a truly complex tree. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty sitar...@gmail.com wrote: On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar dav...@gmail.com wrote: *cough* git-cola *cough* it runs everywhere. Yes, windows too. It's written in python. It's been actively maintained since 2007. It's modern and has features that don't exist anywhere else. It even has tests. It even comes with a building full of willing guinea-pigs^Wtesters that let me know right away when anything goes wrong. It uses Qt but that's really the whole point of Qt - cross-platform. (not sure how that wiki page ended up saying Gnome/GTK?) The DAG aka git-dag (in its master branch, about to be released) is nicer looking then gitk IMO. gitk still has some features that are better too--there's no silver bullet, but the delta is pretty small. Gitk does a lot of things that people don't realise, since they're not really documented and you have to scrounge around on the UI. The thing is, it's just about the most awesome tool for code archeology I have seen. I realise (from looking at the doc page) that git-cola helps you do all sorts of things, but those are all things I am happier doing at the command line. Ditto. There's actually a few small things I use it for, mainly for teasing apart commits. These days you can use git-gui for that, but in the old days it was the only way to interactively select individual lines and stage/unstage/revert them, etc. I don't think we can line-by-line revert in git-gui yet, though. Some other small things that I use: ctrl-g, type something for grep, hit enter twice and I'm in my editor on that (or any other selected) line. 'spacebar' does xdg-open, and 'enter' launches the editor in the status widget; small things. I, too, do most stuff on the command line. The grep thing is a good example. You have tons of output, you see the one line that you care about, and you want to jump there. Clicking on that line and hitting enter is the minimal effort to do that. You don't have to click because we also have keyboard navigation. I have a feeling that there's probably something I'm missing, though.. another way of working (emacs?) that would render all of this custom GUI stuff pointless. What I learned about users: The commit editor is the #1 thing that got my coworkers finally writing better commit messages. It forces the subject/description separation and shows yellow, red when the subject gets too long. It also auto-wraps. IMO it makes sense for git-gui to do the same these days. Gitk does precisely those things which *require* a GUI, where the amount of information presented overwhelms a text interface. The display is concisely designed to give you the maximum information at a minimum space use. For example, a little black square when a commit has a note attached. Even hovering over the arrow-heads, on complex trees where the line gets broken, does something meaningful. if I had to pin it down, the feature I use most often is Show origin of this line. Other features I use often are - review a commit file by file (f and b keys, also spacebar and 'd') - search by SHA1 (4 digits appear to be enough, regardless of how big your repo is), - search for commits changing path/dir (while still showing all the commits; i.e., this is not 'git-dag -- README.txt' but within gitk you search up and down for commits touching README.txt - and navigating the commit tree looking for stuff http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to document some of the stuff I have found and use. Wow, this is awesome. One final point: the DAG on the right wastes enormous amounts of space. Purely subjectively, it is almost jarring on the senses. (If you reduce it, it becomes unreadable). With all due respect, git-cola/dag isn't anywhere near what gitk does, at least for people who are not afraid of the command line and only need the GUI to visualise a truly complex tree. This is really great feedback. cc:ing Guillaume since he had similar ideas. thx, -- David -- 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 5/5] git-send-email: allow edit invalid email address
On Mon, Nov 26, 2012 at 03:50:30PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
On Mon, Nov 26, 2012 at 02:58:58PM -0800, Junio C Hamano wrote:
Krzysztof Mazur krzys...@podlesie.net writes:
Not having this new code inside elsif (/^e/) { } feels somewhat
sloppy, even though it is not *too* bad. Also do we know this
ok, I will fix that.
function will never be used for addresses other than recipients' (I
gave a cursory look to see what is done to the $sender and it does
not seem to go through this function, tho)?
Yes, this function is called only from validate_address_just()
to filter @initial_to, @initial_cc, @bcc_list as early as possible,
and filter @to and @cc added in each email.
Thanks; when merged to 'pu', this series seems to break t9001. I'll
push the result out with breakages but could you take a look?
Sorry, I tested final version only on an ancient perl 5.8.8 and it really
worked there. The third patch is broken:
diff --git a/git-send-email.perl b/git-send-email.perl
index 9996735..f3bbc16 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1472,7 +1472,7 @@ sub unique_email_list {
my @emails;
foreach my $entry (@_) {
- my $clean = extract_valid_address_or_die($entry))
+ my $clean = extract_valid_address_or_die($entry);
Ah, ok, I wasn't looking closely enough. Thanks for a quick
turnaround. Will requeue and push out.
I rechecked that and I've just sent some older broken version. The
patch that I've sent had date Date: Thu, 22 Nov 2012 19:00:25 +0100,
but on my tree I have commit from Date: Thu Nov 22 19:01:55 2012 +0100,
which is exactly the same as the fixed version in your tree.
Thanks,
Krzysiek
--
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
Antw: Re: diff support for the Eiffel language?
Hi! I managed to have some success, although it's not perfect. Unfortunately the Eiffel grammar does not allow a 100% solution. Example: --- local x : BOOLEAN --- declares a local variable named `x', while --- x : BOOLEAN do ... end --- Declares a function named `x'. Formal generic parameters like `x : ARRAY[ARRAY[STRING]]' make things more complicate. Anyway, here's my solution (probably incomplete): --- % git config --local -e [diff Eiffel] xfuncname = !^[[:space:]]*(check|class|[Cc]reate|else|elseif|end|ensure|do|!|feature|from|indexing|inherit|is|local|loop|note|require|then|until)[[:space:]]*\n\ ^[[:space:]]*(class[[:space:]]*[[:alpha:]_][[:alnum:]_]*)\n\ ^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*\\([^(\)]+:[^(\)]+\\)[[:space:]]*:[[:space:]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*[^[:space:]\]?[^\=]*)[[:space:]]*$\n\ ^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*\\([^(\)]+:[^(\)]+\\))[[:space:]]*$\n\ ^[[:space:]]*([[:alpha:]_][[:alnum:]_]*[[:space:]]*:[[:space:]*[[:alpha:]_][[:alnum:]_]*[[:space:]]*[^[:space:]\]?[^\=]*)[[:space:]]*$\n\ ^[[:space:]]*([[:alpha:]_][[:alnum:]_]*)[[:space:]]*$ % cat .git/info/attributes *.e diff=Eiffel --- Regards, Ulrich Johannes Sixt j.s...@viscovery.net schrieb am 22.10.2012 um 15:35 in Nachricht 50854b90.50...@viscovery.net: Am 10/22/2012 15:06, schrieb Ævar Arnfjörð Bjarmason: On Mon, Oct 22, 2012 at 1:58 PM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de wrote: However there's one little thing I noticed with git diff: The conte4xt lines (staring with @@) show the current function (in Perl and C), but they show the current feature clause in Eiffel (as opposed to the expected current feature). I wonder how hard it is to fix it (Observed in git 1.7.7 of openSUSE 12.1). See git.git's e90d065 for an example of adding a new diff pattern. It's not necessary to wait until there is built-in support for a new language. For example, for Windows resource files, I have *.rcdiff=winres in .gitattributes or .git/info/attributes and [diff winres] xfuncname = !^(BEGIN|END|FONT|CAPTION|STYLE)\n^[a-zA-Z_][a-zA-Z_0-9]*.*\n^[[:space:]]*( [[:alnum:]_]+, *DIALOG.*) in .git/config (the xfuncname is all on a single line). The first part beginning at ! up to \n tells to ignore the specified matches. The other parts separated by \n tell the things to put in the hunk header. You can have ignore parts (with exlamation mark) and take this parts (without) in any order that is convenient, as long as the last one is take this. -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
#: builtin/pack-refs.c:6 msgid git pack-refs [options] -msgstr +msgstr git pack-refs [Optionen] #: builtin/pack-refs.c:14 msgid pack everything -msgstr +msgstr packt alles #: builtin/pack-refs.c:15 msgid prune loose refs (default) -msgstr +msgstr entfernt lose Referenzen (Standard) #: builtin/prune-packed.c:7 msgid git prune-packed [-n|--dry-run] [-q|--quiet] -msgstr +msgstr git prune-packed [-n|--dry-run] [-q|--quite] #: builtin/prune.c:12 msgid git prune [-n] [-v] [--expire time] [--] [head...] -msgstr +msgstr git prune [-n] [-v] [--expire Zeit] [--] [Zweigspitze...] #: builtin/prune.c:132 -#, fuzzy msgid do not remove, show only -msgstr Würde nicht entfernen %s\n +msgstr nicht entfernen, nur anzeigen #: builtin/prune.c:133 -#, fuzzy msgid report pruned objects -msgstr kann Objekt %s nicht lesen +msgstr meldet entfernte Objekte #: builtin/prune.c:136 msgid expire objects older than time -msgstr +msgstr lässt Objekte älter als Zeit verfallen #: builtin/push.c:14 -#, fuzzy msgid git push [options] [repository [refspec...]] -msgstr git apply [Optionen] [Patch...] +msgstr git push [Optionen] [Projektarchiv [Referenzspezifikation...]] #: builtin/push.c:45 msgid tag shorthand without tag @@ -7141,55 +7098,53 @@ msgid --all and --mirror are incompatible msgstr --all und --mirror sind inkompatibel #: builtin/push.c:382 -#, fuzzy msgid repository -msgstr ungültiges Projektarchiv '%s' +msgstr Projektarchiv #: builtin/push.c:383 msgid push all refs -msgstr +msgstr versendet alle Referenzen #: builtin/push.c:384 msgid mirror all refs -msgstr +msgstr spiegelt alle Referenzen #: builtin/push.c:386 -#, fuzzy msgid delete refs -msgstr gelöscht +msgstr löscht Referenzen #: builtin/push.c:387 msgid push tags (can't be used with --all or --mirror) msgstr +versendet Markierungen (kann nicht mit --all oder --mirror benutzt werden) #: builtin/push.c:390 -#, fuzzy msgid force updates -msgstr Aktualisierung erzwungen +msgstr erzwingt Aktualisierung #: builtin/push.c:391 msgid check -msgstr +msgstr Überprüfung #: builtin/push.c:392 msgid control recursive pushing of submodules -msgstr +msgstr steuert rekursives Versenden von Unterprojekten #: builtin/push.c:394 msgid use thin pack -msgstr +msgstr benutzt kleinere Pakete #: builtin/push.c:395 builtin/push.c:396 msgid receive pack program -msgstr +msgstr Programm zum Empfangen von Paketen #: builtin/push.c:397 msgid set upstream for git pull/status -msgstr +msgstr setzt externes Projektarchiv für \git pull/status\ #: builtin/push.c:400 msgid prune locally removed refs -msgstr +msgstr entfernt lokal gelöschte Referenzen #: builtin/push.c:410 msgid --delete is incompatible with --all, --mirror and --tags @@ -7205,155 +7160,160 @@ msgid [-u [--exclude-per-directory=gitignore] | -i]] [--no-sparse-checkout] [-- index-output=file] (--empty | tree-ish1 [tree-ish2 [tree-ish3]]) msgstr +git read-tree [[-m [--trivial] [--aggressive] | --reset | --prefix=Prefix] +[-u [--exclude-per-directory=gitignore] | -i]] [--no-sparse-checkout] [-- +index-output=Datei] (--empty | Versionsreferenz1 [Versionsreferenz2 +[Versionsreferenz3]]) #: builtin/read-tree.c:108 -#, fuzzy msgid write resulting index to file -msgstr beschädigte Bereitstellungsdatei +msgstr schreibt resultierende Bereitstellung nach Datei #: builtin/read-tree.c:111 -#, fuzzy msgid only empty the index -msgstr Konnte die Bereitstellung nicht lesen +msgstr leert nur die Bereitstellung #: builtin/read-tree.c:113 -#, fuzzy msgid Merging -msgstr Zusammenführung: +msgstr Zusammenführung #: builtin/read-tree.c:115 msgid perform a merge in addition to a read -msgstr +msgstr führt eine Zusammenführung zusätzlich zum Lesen aus #: builtin/read-tree.c:117 msgid 3-way merge if no file level merging required msgstr +3-Wege-Zusammenführung, wenn keine Zusammenführung auf Dateiebene +erforderlich ist #: builtin/read-tree.c:119 msgid 3-way merge in presence of adds and removes msgstr +3-Wege-Zusammenführung bei Vorhandensein von hinzugefügten/entfernten Zeilen #: builtin/read-tree.c:121 msgid same as -m, but discard unmerged entries -msgstr +msgstr genau wie -m, verwirft aber nicht zusammengeführte Einträge #: builtin/read-tree.c:122 -#, fuzzy msgid subdirectory/ -msgstr Verzeichnis/Datei +msgstr Unterverzeichnis/ #: builtin/read-tree.c:123 msgid read the tree into the index under subdirectory/ -msgstr +msgstr liest den Baum in die Bereitstellung unter Unterverzeichnis/ #: builtin/read-tree.c:126 msgid update working tree with merge result -msgstr +msgstr aktualisiert Arbeitsbaum mit Ergebnis der Zusammenführung #: builtin/read-tree.c:128 -#, fuzzy msgid gitignore -msgstr Ignorierte +msgstr gitignore
Re: [PATCH] Third try at documenting command integration requirements.
On 11/26/2012 10:41 PM, Eric S. Raymond wrote: The next things on my git to-do list are [...] 2. Submit a doc patch containing guidelines that (a) Python scripts should check for their floor version and error out gracefully if they won't run with the host's interpreter, and (b) Python scripts sbould be 2.6-compatible. OK, now let's discuss *which* minimum Python version that git should support in the hypothetical new world... Data point: Mercurial supports Python 2.4 - 2.7 with the following explanation [1]: We will continue to support Python 2.4 as long as it doesn't present a significant barrier to development. Given that Python 2.5 and later don't contain any features that we're dying to use, that may be a long time off. [...] We also will continue to support Python 2.x as long as there is a significant installed base in the form of Red Hat Enterprise Linux and Ubuntu LTS users. RHEL 5, which uses Python 2.4, will reach the end of the production 2 portion of its lifecycle in Q1 2014 and the end of its regular lifecycle in 2017. It would be a shame to leave RHEL 5 users behind if Python is used to implement important git functionality. Python 2.4 is missing some of Python's shiny new features, but still quite OK. What features would you miss the most if we were to target Python 2.4 instead of 2.6? Michael [1] http://mercurial.selenic.com/wiki/SupportedPythonVersions -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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: [RFC/PATCH] l10n: de.po: translate 825 new messages
Hi Ralf,
This is the middle third of my review. Sorry for the long wait! I hope
it can still be useful.
Also, sorry for the other mail that I just sent out seconds ago. That
was what I wanted to save as to be done in the last third, but
I accidentally hit the wrong key and sent it out.
- Thomas
@@ -4459,6 +4423,8 @@ msgstr
#: builtin/fmt-merge-msg.c:13
msgid git fmt-merge-msg [-m message] [--log[=n]|--no-log] [--file
file]
msgstr
+git fmt-merge-msg [-m Beschreibung] [--log[=Anzahl]|--no-log] [--file
+Datei]
#: builtin/fmt-merge-msg.c:653 builtin/fmt-merge-msg.c:656 builtin/grep.c:786
#: builtin/merge.c:188 builtin/show-branch.c:656 builtin/show-ref.c:192
@@ -4468,115 +4434,111 @@ msgstr Anzahl
#: builtin/fmt-merge-msg.c:654
msgid populate log with at most n entries from shortlog
-msgstr
+msgstr fügt Historie mit höchstens Nummer Einträgen von \shortlog\
hinzu
I don't really share your apparent aversion to just using n :-)
#: builtin/for-each-ref.c:994
msgid quote placeholders suitably for shells
-msgstr
+msgstr quotiert Platzhalter geeignet für Shells
[...]
#: builtin/for-each-ref.c:996
msgid quote placeholders suitably for perl
+msgstr quotiert Platzhalter geeignet für Perl
[etc]
quote is a hard one, and quotiert sounds very wrong to me. How
about weaseling out along the lines of
Formatiert Platzhalter als {Shell|Perl|Python|TCL} Zeichenfolge
or even Shell-String.
#: builtin/for-each-ref.c:1003
msgid show only n matched refs
-msgstr
+msgstr zeigt nur Nummer passende Referenzen
This should be Anzahl if you insist on translating the 'n'.
#: builtin/for-each-ref.c:1006
msgid field name to sort on
-msgstr
+msgstr Name des Felder zum Sortieren
Feld_s_?
Or just sortiere nach diesem Feld.
#: builtin/fsck.c:618
msgid make index objects head nodes
-msgstr
+msgstr erzeugt Kopfknoten der Bereitstellungsobjekte
The English version is equally obscure, but this refers to (also)
walking the objects listed in the index. Furthermore, --cache is
actually the default if you don't list any objects to walk.
#: builtin/fsck.c:620
msgid also consider packs and alternate objects
-msgstr
+msgstr betrachtet auch Pakete und wechselnde Objekte
The glossary tells me pack - Archiv.
An alternate object [store] is essentially a pointer to the object store
of another repository. It may best be left untranslated, as it's a
pretty advanced feature.
#: builtin/grep.c:741
msgid match patterns only at word boundaries
-msgstr
+msgstr findet Muster nur innerhalb von Wörtern
The translation gets the purpose wrong: the option forces a
word-boundary match on either side of the pattern, so that you will find
only one or more words matching the pattern. The manpage has a precise
definition:
Match the pattern only at word boundary (either begin at the
beginning of a line, or preceded by a non-word character; end at
the end of a line or followed by a non-word character).
Maybe suche nur ganze Wörter would suffice as a concise description.
#: builtin/grep.c:817
msgid indicate hit with exit status without output
-msgstr
+msgstr kennzeichnet Übereinstimmungen mit Beendigungsstatus, ohne Ausgabe
The indicate should be zeigen or some such, since it only tells
whether there were any matches at all.
I spent some time looking for a better translation of exit status, but
couldn't find anything helpful (such as a German translation of diff(1)
or a Wikipedia page on exit status).
#: builtin/hash-object.c:77
msgid process file as it were from this path
-msgstr
+msgstr verarbeitet Datei, wie es von diesem Pfad wäre
als ob sie von diesem Pfad wäre?
#: builtin/help.c:47
msgid show info page
-msgstr
+msgstr zeigt Informationsseite
info here refers to GNU info, presumably it should be left as
info-Seite or some such.
#: builtin/index-pack.c:1106
msgid confusion beyond insanity
@@ -5150,12 +5111,12 @@ msgstr Fehler beim Auflösen der Unterschiede
#: builtin/index-pack.c:1112
#, c-format
msgid completed with %d local objects
-msgstr
+msgstr fertiggestellt mit %d lokalen Objekten
*vervollständigt* mit %d lokalen Objekten
#: builtin/log.c:102
msgid decorate options
-msgstr
+msgstr Ausgabeoptionen
'decorate' is the option to mark commits by the refs pointing at them,
and should probably not be translated.
The English version is quite tautological though, since it just turns
into
--decorate[=...] decorate options
#: builtin/log.c:1091
msgid don't include a patch matching a commit upstream
msgstr
+schließt keine Patches ein, die einer Version im externen Projektarchiv
+entsprechen
Upstream refers to the notional upstream state, which does not even have
to be a branch here. I.e., if you say
git format-patch --ignore-if-in-upstream commit
then it will format the range 'commit..HEAD', ignoring patches that are
already in 'HEAD..commit'.
So it's not an upstream
Re: Python extension commands in git - request for policy change
On Sunday, November 25, 2012 at 06:40 EST, Felipe Contreras felipe.contre...@gmail.com wrote: On Sun, Nov 25, 2012 at 11:44 AM, Michael Haggerty mhag...@alum.mit.edu wrote: [...] On the contrary, there is *constant* traffic on the mailing list about incompatibilities between different shell implementations (sh, dash, bash, etc), not to mention those in other utilities (sed, grep, etc) that one is forced to work with in shell scripts. Compatibility is a *huge* pain when developing shell code for git. The fact that users typically don't encounter such problems is due to the hard work of POSIX lawyers on the mailing list correcting the compatibility errors of mortal programmers. *Theoretical* incompatibilities on probably obscure systems. *I* have never seen such compatibility issues *in practice*. While constant traffic probably overstates the issue, these are not theoretical problems. I recall at least three cases in the last year or so where Git has seen breakage with Solaris or Mac OS X because of sed or tr incompatibilities, and I don't even read this list that thoroughly. [...] -- Magnus Bäck ba...@google.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: [msysGit] Re: Python extension commands in git - request for policy change
Hi David, On Mon, 26 Nov 2012, David Aguilar wrote: *cough* git-cola *cough* If you had a couple of free cycles to help us get Python/Qt compiled in msysGit, I will be happy to make a Git for Windows package including git-cola. Ciao, Dscho -- 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] Extend runtime prefix computation
Support determining the binaries' installation path at runtime even if
called without any path components (i.e. via search path). Implement
fallback to compiled-in prefix if determination fails or is impossible.
Signed-off-by: Michael Weiser wei...@science-computing.de
---
- Has two very minor memory leaks - function is called only once per
program execution. Do we care? Alternative: Use static buffer instead.
exec_cmd.c | 68 ++-
1 files changed, 53 insertions(+), 15 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 125fa6f..d50d7f8 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -4,28 +4,22 @@
#define MAX_ARGS 32
static const char *argv_exec_path;
-static const char *argv0_path;
+static const char *argv0_path = NULL;
const char *system_path(const char *path)
{
-#ifdef RUNTIME_PREFIX
- static const char *prefix;
-#else
static const char *prefix = PREFIX;
-#endif
struct strbuf d = STRBUF_INIT;
if (is_absolute_path(path))
return path;
#ifdef RUNTIME_PREFIX
- assert(argv0_path);
- assert(is_absolute_path(argv0_path));
-
- if (!prefix
- !(prefix = strip_path_suffix(argv0_path, GIT_EXEC_PATH))
- !(prefix = strip_path_suffix(argv0_path, BINDIR))
- !(prefix = strip_path_suffix(argv0_path, git))) {
+ if (!argv0_path ||
+ !is_absolute_path(argv0_path) ||
+ (!(prefix = strip_path_suffix(argv0_path, GIT_EXEC_PATH))
+!(prefix = strip_path_suffix(argv0_path, BINDIR))
+!(prefix = strip_path_suffix(argv0_path, git {
prefix = PREFIX;
trace_printf(RUNTIME_PREFIX requested,
but prefix computation failed.
@@ -41,20 +35,64 @@ const char *system_path(const char *path)
const char *git_extract_argv0_path(const char *argv0)
{
const char *slash;
+ char *abs_argv0 = NULL;
if (!argv0 || !*argv0)
return NULL;
slash = argv0 + strlen(argv0);
+ /* walk to the first slash from the end */
while (argv0 = slash !is_dir_sep(*slash))
slash--;
+ /* if there was a slash ... */
if (slash = argv0) {
- argv0_path = xstrndup(argv0, slash - argv0);
- return slash + 1;
+ /* ... it's either an absolute path */
+ if (is_absolute_path(argv0)) {
+ /* FIXME: memory leak here */
+ argv0_path = xstrndup(argv0, slash - argv0);
+ return slash + 1;
+ }
+
+ /* ... or a relative path, in which case we have to make it
+* absolute first and do the whole thing again */
+ abs_argv0 = xstrdup(real_path(argv0));
+ } else {
+ /* argv0 is no path at all, just a name. Resolve it into a
+* path. Unfortunately, this gets system specific. */
+#if defined(__linux__)
+ struct stat st;
+ if (!stat(/proc/self/exe, st)) {
+ abs_argv0 = xstrdup(real_path(/proc/self/exe));
+ }
+#elif defined(__APPLE__)
+ /* Mac OS X has realpath, which incidentally allocates its own
+* memory, which in turn is why we do all the xstrdup's in the
+* other cases. */
+ abs_argv0 = realpath(argv0, NULL);
+#endif
+
+ /* if abs_argv0 is still NULL here, something failed above or
+* we are on an unsupported system. system_path() will warn
+* and fall back to the static prefix */
+ if (!abs_argv0) {
+ argv0_path = NULL;
+ return argv0;
+ }
}
- return argv0;
+ /* abs_argv0 is an absolute path now for which memory was allocated
+* with malloc */
+
+ slash = abs_argv0 + strlen(abs_argv0);
+ while (abs_argv0 = slash !is_dir_sep(*slash))
+ slash--;
+
+ /* FIXME: memory leaks here */
+ argv0_path = xstrndup(abs_argv0, slash - abs_argv0);
+ slash = xstrdup(slash + 1);
+ free(abs_argv0);
+ return slash;
}
void git_set_argv_exec_path(const char *exec_path)
--
1.7.3.4
--
Vorstandsvorsitzender/Chairman of the board of management:
Gerd-Lothar Leonhart
Vorstand/Board of Management:
Dr. Bernd Finkbeiner, Michael Heinrichs,
Dr. Arno Steitz, Dr. Ingrid Zech
Vorsitzender des Aufsichtsrats/
Chairman of the Supervisory Board:
Philippe Miltin
Sitz/Registered Office: Tuebingen
Registergericht/Registration Court: Stuttgart
Registernummer/Commercial Register No.: HRB 382196
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 p2 3/9] transport-helper: trivial code shuffle
Felipe Contreras felipe.contre...@gmail.com writes:
Just shuffle the die() part to make it more explicit, and cleanup the
code-style.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
transport-helper.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 32ad877..0c95101 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -775,6 +775,9 @@ static int push_refs_with_export(struct transport
*transport,
char *private;
unsigned char sha1[20];
+ if (ref-deletion)
+ die(remote-helpers do not support ref deletion);
+
if (!data-refspecs)
continue;
This is not just just shuffle the die to make it explicit but it
does change the semantics; earlier ref-deletion was perfectly fine
as long as data-refspecs is not given, but the new code always
dies.
If this semantic change is a good thing, please explain why it is so
in the log message. If the change is it does not matter because
when data-refspecs is not given and ref-deletion is set, we die
later elsewhere in the code anyway, then it needs to be described.
Thanks.
@@ -784,10 +787,6 @@ static int push_refs_with_export(struct transport
*transport,
}
free(private);
- if (ref-deletion) {
- die(remote-helpers do not support ref deletion);
- }
-
if (ref-peer_ref)
string_list_append(revlist_args, ref-peer_ref-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] Documentation: improve phrasing in git-push.txt
Sounds better; 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 7/7] push: clarify rejection of update to non-commit-ish
Chris Rorvick ch...@rorvick.com writes: With this code, the old must be a commit but new can be a tag that points at a commit? Why? The old must not be a tag because fast-forwarding from it is potentially destructive; a tag would likely be left dangling in this case. This is not true for the new, though. I'm not sure fast-forwarding from a commit to a tag is useful, but I didn't see a reason to prevent it either. The refs/tags/ hierarchy is excluded from fast-forwarding before this check, and refs/heads/ is already protected against anything but commits. So it seems very unlikely that someone would accidentally make use of this behavior. So, fast-forwarding to a tag seemed fairly benign and unlikely to cause confusion, so I leaned towards allowing it in case someone found a use case for it. Sounds sensible. Perhaps some of that thinking behind this change (i.e. earlier we checked the forwardee was any commit-ish, but the new code only allows a commit object if it were to be fast-forwarded) belongs to the log message? 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 5/7] push: require force for refs under refs/tags/
Chris Rorvick ch...@rorvick.com writes: On Mon, Nov 26, 2012 at 12:57 PM, Junio C Hamano gits...@pobox.com wrote: Chris Rorvick ch...@rorvick.com writes: diff --git a/remote.c b/remote.c index 4a6f822..012b52f 100644 --- a/remote.c +++ b/remote.c @@ -1315,14 +1315,18 @@ void set_ref_status_for_push(struct ref *remote_refs, int send_mirror, * * (1) if the old thing does not exist, it is OK. * - * (2) if you do not have the old thing, you are not allowed + * (2) if the destination is under refs/tags/ you are + * not allowed to overwrite it; tags are expected + * to be static once created + * + * (3) if you do not have the old thing, you are not allowed * to overwrite it; you would not know what you are losing * otherwise. * - * (3) if both new and old are commit-ish, and new is a + * (4) if both new and old are commit-ish, and new is a * descendant of old, it is OK. * - * (4) regardless of all of the above, removing :B is + * (5) regardless of all of the above, removing :B is * always allowed. */ We may want to reword (0) to make it clear that --force (and +A:B) can be used to defeat all the other rules. On that note, having (5) be regardless of all of the above ... seems a little awkward. That would seem to fit better towards the top. Sure. (0) you can always force; (1) you can always delete; and then other requirements. That may indeed read better. 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] Support for git aliasing for tcsh completion
The patch was linewrapped so I had to fix it up; please double check what will be queued on 'pu' to make sure that I did not miss necessary whitespaces or added unnecessary ones when I rejoined long lines. 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: Interesting git-format-patch bug
per...@pluto.rain.com (Perry Hutchison) writes: Junio C Hamano gits...@pobox.com wrote: Olsen, Alan R alan.r.ol...@intel.com writes: I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) As you literally have patches that do essentially the same or similar things on two branches that was merged, you cannot expect to export each individual commit into a patch and not have conflicts among them. So I do not think there is no answer than don't do that. To me, this seems to miss Alan's point: only one patch was merged to branch A,... Are you sure about this part? I thought Alan's description was that he originally had this x-A \ \ B-M (a) and then some other process made it like so: x-A |\ \ | B-M \ \ B'--M' (a) and then you ask to linealize the last n patches starting from the rewritten M'. If that some other process instead created a history like this: x-A---\ |\ \ \ | B-M \ \ \ B'--M' (a) then the redone-merge M' will not see the old B that was fixed later to B' in the history, but then format-patch would not show B so we wouldn't be having this discussion thread. It is possible that some other process may (ab)use the parent field to record the evolution of B, to create a topology like this: x-A---\ |\ \ \ | B-M \ \ \ \ \-B'M' (a) in which case M' has parent B' but B' has a (phoney) parent B. So again, it all depends on what some other process does to the history when it rewrites it, and if somebody wants to fiter cruft in the resulting history when flattening it, the knowledge of what some other process does need to help that process. Which is what I already said, I guess ;-) so git-format-patch applied to branch A should find only one patch. It can be argued either way whether that one-patch report should include the gerrit annotations, but surely the application of gerrit on branch B, _after the merge to branch A has already been performed_, should not cause an additional patch to magically appear on branch A. -- 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/4] t4041 (diff-submodule-option): parse digests sensibly
Ramkumar Ramachandra artag...@gmail.com writes:
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t4041-diff-submodule-option.sh | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh
b/t/t4041-diff-submodule-option.sh
index 5377639..cfb71e5 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -21,7 +21,7 @@ add_file () {
test_tick
git commit -m Add $name
done /dev/null
- git rev-parse --verify HEAD | cut -c1-7
+ git rev-parse --short --verify HEAD
cd $owd
}
commit_file () {
@@ -33,7 +33,7 @@ test_create_repo sm1
add_file . foo /dev/null
head1=$(add_file sm1 foo1 foo2)
-fullhead1=$(cd sm1; git rev-list --max-count=1 $head1)
+fullhead1=$(cd sm1; git rev-parse --verify $head1)
That still is a roundabout way to say git rev-parse --verify HEAD,
no? Why feed a shortened one to get the expanded result when you
know the full representation of HEAD is what you want?
test_expect_success 'added submodule'
git add sm1
@@ -116,8 +116,8 @@ EOF
test_cmp expected actual
-fullhead2=$(cd sm1; git rev-list --max-count=1 $head2)
test_expect_success 'modified submodule(forward) --submodule=short'
+fullhead2=$(cd sm1; git rev-parse --verify $head2)
git diff --submodule=short actual
cat expected -EOF
diff --git a/sm1 b/sm1
@@ -135,7 +135,7 @@ commit_file sm1
head3=$(
cd sm1
git reset --hard HEAD~2 /dev/null
- git rev-parse --verify HEAD | cut -c1-7
+ git rev-parse --short --verify HEAD
)
test_expect_success 'modified submodule(backward)'
@@ -220,8 +220,8 @@ EOF
rm -f sm1
test_create_repo sm1
head6=$(add_file sm1 foo6 foo7)
-fullhead6=$(cd sm1; git rev-list --max-count=1 $head6)
test_expect_success 'nonexistent commit'
+fullhead6=$(cd sm1; git rev-parse --verify $head6)
git diff-index -p --submodule=log HEAD actual
cat expected -EOF
Submodule sm1 $head4...$head6 (commits not present)
@@ -318,8 +318,8 @@ EOF
(cd sm1; git commit -mchange foo6 /dev/null)
-head8=$(cd sm1; git rev-parse --verify HEAD | cut -c1-7)
test_expect_success 'submodule is modified'
+head8=$(cd sm1; git rev-parse --short --verify HEAD)
git diff-index -p --submodule=log HEAD actual
cat expected -EOF
Submodule sm1 $head6..$head8:
@@ -461,7 +461,7 @@ EOF
test_cmp expected actual
-fullhead7=$(cd sm2; git rev-list --max-count=1 $head7)
+fullhead7=$(cd sm2; git rev-parse --verify $head7)
test_expect_success 'given commit --submodule=short'
git diff-index -p --submodule=short HEAD^ actual
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/6] Improve remote helper documentation
Various remote helper capabilities and commands were not documented, in particular 'export', or documented in a misleading way (e.g. 'for-push' was listed as a ref attribute understood by git, which is not the case). This patch series changes that, and also address some other things in the remote helper documentation that I found jarring when reading through it. Note that the description of export and (im|ex)port-marks probably can be improved, and I hope that somebody who knows more about them than me and/or is better at writing documentation will do just that. But I felt it was better to provide something than to do nothing and only complain, as I did previously on this subject ;-). Max Horn (6): Document invocation first, then input format Document missing remote helper capabilities Fix grammar Rearrange the description of remote helper capabilities Make clearer which commands must be supported for which capabilities Remove 'for-push' from ref list attributes list, link to subsections Documentation/git-remote-helpers.txt | 241 --- 1 file changed, 136 insertions(+), 105 deletions(-) -- 1.8.0.393.gcc9701d -- 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 6/6] Remove 'for-push' from ref list attributes list, link to subsections
The documentation was misleading in that it gave the impression that 'for-push' could be used as a ref attribute in the output of the 'list' command. That is wrong. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 023dcca..081cb06 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -227,6 +227,8 @@ Support for this command is mandatory. the name; unrecognized attributes are ignored. The list ends with a blank line. + +See REF LIST ATTRIBUTES for a list of currently defined options. ++ Supported if the helper has the fetch or import capability. 'list for-push':: @@ -248,6 +250,8 @@ Supported if the helper has the push or export capability. for it). Options should be set before other commands, and may influence the behavior of those commands. + +See OPTIONS for a list of currently defined options. ++ Supported if the helper has the option capability. 'fetch' sha1 name:: @@ -256,7 +260,7 @@ Supported if the helper has the option capability. per line, terminated with a blank line. Outputs a single blank line when all fetch commands in the same batch are complete. Only objects which were reported - in the ref list with a sha1 may be fetched this way. + in the output of 'list' with a sha1 may be fetched this way. + Optionally may output a 'lock file' line indicating a file under GIT_DIR/objects/pack which is keeping a pack until refs can be @@ -360,10 +364,9 @@ capabilities reported by the helper. REF LIST ATTRIBUTES --- -'for-push':: - The caller wants to use the ref list to prepare push - commands. A helper might chose to acquire the ref list by - opening a different type of connection to the destination. +The 'list' command produces a list of refs in which each ref +may be followed by a list of attributes. The following ref list +attributes are defined. 'unchanged':: This ref is unchanged since the last import or fetch, although -- 1.8.0.393.gcc9701d -- 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 4/6] Rearrange the description of remote helper capabilities
This also remove some duplication in the descriptions (e.g. refspec was explained twice with similar level of detail) Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 134 +++ 1 file changed, 56 insertions(+), 78 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 7eb43d7..7ac1461 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of commands. The operations a helper supports are declared to git in the response to the `capabilities` command (see COMMANDS, below). -'option':: - For specifying settings like `verbosity` (how much output to - write to stderr) and `depth` (how much history is wanted in the - case of a shallow clone) that affect how other commands are - carried out. - -'connect':: - For fetching and pushing using git's native packfile protocol - that requires a bidirectional, full-duplex connection. - -'push':: - For listing remote refs and pushing specified objects from the - local object store to remote refs. - -'fetch':: - For listing remote refs and fetching the associated history to - the local object store. - -'export':: - For listing remote refs and pushing specified objects from a - fast-import stream to remote refs. - -'import':: - For listing remote refs and fetching the associated history as - a fast-import stream. - -'refspec' refspec:: - This modifies the 'import' capability, allowing the produced - fast-import stream to modify refs in a private namespace - instead of writing to refs/heads or refs/remotes directly. - It is recommended that all importers providing the 'import' - capability use this. -+ -A helper advertising the capability -`refspec refs/heads/*:refs/svn/origin/branches/*` -is saying that, when it is asked to `import refs/heads/topic`, the -stream it outputs will update the `refs/svn/origin/branches/topic` -ref. -+ -This capability can be advertised multiple times. The first -applicable refspec takes precedence. The left-hand of refspecs -advertised with this capability must cover all refs reported by -the list command. If no 'refspec' capability is advertised, -there is an implied `refspec *:*`. - -'bidi-import':: - The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers - to retrieve information about blobs and trees that already exist in - fast-import's memory. This requires a channel from fast-import to the - remote-helper. - If it is advertised in addition to import, git establishes a pipe from - fast-import to the remote-helper's stdin. - It follows that git and fast-import are both connected to the - remote-helper's stdin. Because git can send multiple commands to - the remote-helper it is required that helpers that use 'bidi-import' - buffer all 'import' commands of a batch before sending data to fast-import. - This is to prevent mixing commands and fast-import responses on the - helper's stdin. - -'export-marks' file:: - This modifies the 'export' capability, instructing git to dump the - internal marks table to file when complete. For details, - read up on '--export-marks=file' in linkgit:git-fast-export[1]. - -'import-marks' file:: - This modifies the 'export' capability, instructing git to load the - marks specified in file before processing any input. For details, - read up on '--import-marks=file' in linkgit:git-fast-export[1]. +In the following, we list all defined capabilities and for +each we list which commands a helper with that capability +must provide. Capabilities for Pushing - + 'connect':: Can attempt to connect to 'git receive-pack' (for pushing), - 'git upload-pack', etc for communication using the - packfile protocol. + 'git upload-pack', etc for communication using + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. + Supported commands: 'connect'. @@ -186,11 +122,12 @@ Other frontends may have some other order of preference. Capabilities for Fetching -~ +^ 'connect':: Can try to connect to 'git upload-pack' (for fetching), 'git receive-pack', etc for communication using the - packfile protocol. + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. + Supported commands: 'connect'. @@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS). When choosing between 'fetch' and 'import', git prefers 'fetch'. Other frontends may have some other order of preference. +Miscellaneous
[PATCH 2/6] Document missing remote helper capabilities
The 'export' and '(im|ex)port-marks' capabilities were not documented at all Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 45 +--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 9a7e583..db63541 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below). For listing remote refs and fetching the associated history to the local object store. +'export':: + For listing remote refs and pushing specified objects from a + fast-import stream to remote refs. + 'import':: For listing remote refs and fetching the associated history as a fast-import stream. @@ -143,6 +147,16 @@ there is an implied `refspec *:*`. This is to prevent mixing commands and fast-import responses on the helper's stdin. +'export-marks' file:: + This modifies the 'export' capability, instructing git to dump the + internal marks table to file when complete. For details, + read up on '--export-marks=file' in linkgit:git-fast-export[1]. + +'import-marks' file:: + This modifies the 'export' capability, instructing git to load the + marks specified in file before processing any input. For details, + read up on '--import-marks=file' in linkgit:git-fast-export[1]. + Capabilities for Pushing 'connect':: @@ -158,9 +172,18 @@ Supported commands: 'connect'. + Supported commands: 'list for-push', 'push'. -If a helper advertises both 'connect' and 'push', git will use -'connect' if possible and fall back to 'push' if the helper requests -so when connecting (see the 'connect' command under COMMANDS). +'export':: + Can discover remote refs and push specified objects from a + fast-import stream to remote refs. ++ +Supported commands: 'list for-push', 'export'. + +If a helper advertises 'connect', git will use it if possible and +fall back to another capability if the helper requests so when +connecting (see the 'connect' command under COMMANDS). +When choosing between 'push' and 'export', git prefers 'push'. +Other frontends may have some other order of preference. + Capabilities for Fetching ~ @@ -307,6 +330,22 @@ stdin. + Supported if the helper has the 'import' capability. +'export':: + Instructs the remote helper that any subsequent input is + part of a fast-import stream (generated by 'git fast-export') + containing objects which should be pushed to the remote. ++ +Especially useful for interoperability with a foreign versioning +system. ++ +The 'export-marks' and 'import-marks' capabilities, if specified, +affect this command in so far as they are passed on to 'git +fast-export', which then will load/store a table of marks for +local objects. This can be used to implement for incremental +operations. ++ +Supported if the helper has the 'export' capability. + 'connect' service:: Connects to given service. Standard input and standard output of helper are connected to specified service (git prefix is -- 1.8.0.393.gcc9701d -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] Fix grammar
Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index db63541..7eb43d7 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line. 'capabilities':: Lists the capabilities of the helper, one per line, ending with a blank line. Each capability may be preceded with '*', - which marks them mandatory for git version using the remote - helper to understand (unknown mandatory capability is fatal - error). + which marks them mandatory for git versions using the remote + helper to understand. Any unknown mandatory capability is a + fatal error. 'list':: Lists the refs, one per line, in the format value name -- 1.8.0.393.gcc9701d -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] Document invocation first, then input format
In the distant past, the order was 'Invocation', 'Commands', 'Capabilities', ... Then it was decided that before giving a list of Commands, there should be an overall description of the 'Input format', which was a wise decision. However, this description was put as the very first thing, with the rationale that any implementor would want to know that first. However, it seems an implementor would actually first need to know how the remote helper will be invoked, so moving 'Invocation' to the front again seems logical. Moreover, we now don't switch from discussing the input format to the invocation style and then back to input related stuff. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 62 ++-- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 5ce4cda..9a7e583 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https', 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities 'fetch', 'option', and 'push'. +INVOCATION +-- + +Remote helper programs are invoked with one or (optionally) two +arguments. The first argument specifies a remote repository as in git; +it is either the name of a configured remote or a URL. The second +argument specifies a URL; it is usually of the form +'transport://address', but any arbitrary string is possible. +The 'GIT_DIR' environment variable is set up for the remote helper +and can be used to determine where to store additional data or from +which directory to invoke auxiliary git commands. + +When git encounters a URL of the form 'transport://address', where +'transport' is a protocol that it cannot handle natively, it +automatically invokes 'git remote-transport' with the full URL as +the second argument. If such a URL is encountered directly on the +command line, the first argument is the same as the second, and if it +is encountered in a configured remote, the first argument is the name +of that remote. + +A URL of the form 'transport::address' explicitly instructs git to +invoke 'git remote-transport' with 'address' as the second +argument. If such a URL is encountered directly on the command line, +the first argument is 'address', and if it is encountered in a +configured remote, the first argument is the name of that remote. + +Additionally, when a configured remote has 'remote.name.vcs' set to +'transport', git explicitly invokes 'git remote-transport' with +'name' as the first argument. If set, the second argument is +'remote.name.url'; otherwise, the second argument is omitted. + INPUT FORMAT @@ -173,37 +204,6 @@ advertised with this capability must cover all refs reported by the list command. If no 'refspec' capability is advertised, there is an implied `refspec *:*`. -INVOCATION --- - -Remote helper programs are invoked with one or (optionally) two -arguments. The first argument specifies a remote repository as in git; -it is either the name of a configured remote or a URL. The second -argument specifies a URL; it is usually of the form -'transport://address', but any arbitrary string is possible. -The 'GIT_DIR' environment variable is set up for the remote helper -and can be used to determine where to store additional data or from -which directory to invoke auxiliary git commands. - -When git encounters a URL of the form 'transport://address', where -'transport' is a protocol that it cannot handle natively, it -automatically invokes 'git remote-transport' with the full URL as -the second argument. If such a URL is encountered directly on the -command line, the first argument is the same as the second, and if it -is encountered in a configured remote, the first argument is the name -of that remote. - -A URL of the form 'transport::address' explicitly instructs git to -invoke 'git remote-transport' with 'address' as the second -argument. If such a URL is encountered directly on the command line, -the first argument is 'address', and if it is encountered in a -configured remote, the first argument is the name of that remote. - -Additionally, when a configured remote has 'remote.name.vcs' set to -'transport', git explicitly invokes 'git remote-transport' with -'name' as the first argument. If set, the second argument is -'remote.name.url'; otherwise, the second argument is omitted. - COMMANDS -- 1.8.0.393.gcc9701d -- 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 5/6] Make clearer which commands must be supported for which capabilities
In particular, document 'list for-push' separately from 'list', as the former needs only be supported for the 'push' capability, and the latter only for fetch/import/export. In particular, a hypothetically 'push-only' helper only needs to support the former, not the latter. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 7ac1461..023dcca 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard input, one per line. which marks them mandatory for git versions using the remote helper to understand. Any unknown mandatory capability is a fatal error. ++ +Support for this command is mandatory. 'list':: Lists the refs, one per line, in the format value name @@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard input, one per line. the name; unrecognized attributes are ignored. The list ends with a blank line. + -If 'push' is supported this may be called as 'list for-push' -to obtain the current refs prior to sending one or more 'push' -commands to the helper. +Supported if the helper has the fetch or import capability. + +'list for-push':: + Similar to 'list', except that it is used if and only if + the caller wants to the resulting ref list to prepare + push commands. + A helper supporting both push and fetch can use this + to distinguish for which operation the output of 'list' + is going to be used, possibly reducing the amount + of work that needs to be performed. ++ +Supported if the helper has the push or export capability. 'option' name value:: Sets the transport helper option name to value. Outputs a @@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to fast-import to prevent mixing of commands and fast-import responses on the helper's stdin. + -Supported if the helper has the 'import' capability. +Supported if the helper has the import capability. 'export':: Instructs the remote helper that any subsequent input is @@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks for local objects. This can be used to implement for incremental operations. + -Supported if the helper has the 'export' capability. +Supported if the helper has the export capability. 'connect' service:: Connects to given service. Standard input and standard output -- 1.8.0.393.gcc9701d -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] t4041 (diff-submodule-option): change tense of test names
Ramkumar Ramachandra artag...@gmail.com writes: Change the tense of test names from past to present, as this is the prevalent style. Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- I see most of them are not past but past particle used as if they are adjectives. For example, I think this test -test_expect_success 'added submodule' ' tries to say See what happens to an added submodule. The same for the others. -test_expect_success 'modified submodule(forward)' ' See what is shown for modified submodule. -test_expect_success 'typechanged submodule(submodule-blob), --cached' ' See what is shown for typechanged one, when --cached option is given. So I do not think this patch is needed; the current wording looks not so grammatically kosher, but still is understandable. Updated result isn't. -- 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] Third try at documenting command integration requirements.
Michael Haggerty mhag...@alum.mit.edu: OK, now let's discuss *which* minimum Python version that git should support in the hypothetical new world... By all means! It would be a shame to leave RHEL 5 users behind if Python is used to implement important git functionality. Python 2.4 is missing some of Python's shiny new features, but still quite OK. What features would you miss the most if we were to target Python 2.4 instead of 2.6? Off the top of my head...the 'with' statement, the conditional expression, and built-in JSON support. Other developers would be likely to kick about the string format() method; personally I'm cheerfully old-school about that. I agree that 2.4 is still quite OK. I'm a little concerned that dropping that far back might store up some transition problems for the day we decide to make the jump to Python 3. On the other hand, I think gating features on RHEL5 might be excessively cautious. According to [1], RHEL will red-zone within 30 days if it hasn't done so already ([1] says Q4). And RHEL6 (with Python 2.6) has been shipping for two years. Policy suggestion: we aim to stay friendly for every version of RHEL that is still in Support 1. I doubt anyone will code anything critical in Python before Dec 31st - I'm certainly not planning to! [1] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux RHEL5 is going -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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/4] t4041 (diff-submodule-option): rewrite add_file() routine
Ramkumar Ramachandra artag...@gmail.com writes:
Instead of cd there and then come back, use the cd there in a
subshell pattern. Also fix '' chaining in one place.
Suggested-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t4041-diff-submodule-option.sh | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/t/t4041-diff-submodule-option.sh
b/t/t4041-diff-submodule-option.sh
index cfb71e5..103c690 100755
--- a/t/t4041-diff-submodule-option.sh
+++ b/t/t4041-diff-submodule-option.sh
@@ -11,18 +11,15 @@ This test tries to verify the sanity of the --submodule
option of git diff.
. ./test-lib.sh
add_file () {
+ (cd $1
+ shift
+ for name; do
echo $name $name
git add $name
test_tick
git commit -m Add $name
+ done /dev/null
+ git rev-parse --short --verify HEAD)
While at it, why not do the indent with a single tab, and other
style fixes? e.g.
(
cd $1
shift
for name
do
echo $name $name
git add $name
test_tick
git commit -m Add $name || exit
done /dev/null
git rev-parse --short --verify HEAD
)
The || exit is needed to catch failures inside the loop (not that
git commit there is likely to fail, so it is just for
completeness).
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
Hi, On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote: From: W. Trevor King wk...@tremily.us On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote: We could add $ git submodule update --branch to checkout the gitlinked SHA1 as submodule.name.branch in each of the submodules, leaving the submodules on the .gitmodules-configured branch. Effectively (for each submodule): $ git branch -f $branch $sha1 $ git checkout $branch I haven't gotten any feedback on this as an idea, but perhaps someone will comment on it as a patch series ;). I am not sure I understand you correctly. You are suggesting that the branch option as an alias for the registered SHA1 in the superproject? I though the goal of your series was that you want to track submodules branch which come from the remote side? Doing the above does not assist you much in that does it? I would think more of some convention like: $ git checkout -t origin/$branch when first initialising the submodule with e.g. $ git submodule update --init --branch Then later calls of $ git submodule update --branch would have a branch configured to pull from. I imagine that results in a similar behavior gerrit is doing on the server side? Changes since v3: * --record=??? is now --local-branch=??? * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation) * Added local git-config overrides of .gitmodules' submodule.name.branch * Added `submodule update --branch` I would prefer if we could squash all these commits together into one since it seems to me one logical step, using the new variable for update belongs together with its configuration on initialization. How about reusing the -b|--branch option for add? Since we only change the behavior when submodule.$name.update is set to branch it seems reasonable to me. Opinions? Because you need to recurse through submodules for `update --branch` even if $subsha1 == $sha1, I had to amend the conditional controlling that block. This broke one of the existing tests, which I fixed in patch 4. I think a proper fix would involve rewriting (clear_local_git_env; cd $sm_path ( (rev=$(git rev-list -n 1 $sha1 --not --all 2/dev/null) test -z $rev) || git-fetch)) || die $(eval_gettext Unable to fetch in submodule path '\$sm_path') but I'm not familiar enough with rev-list to want to dig into that yet. If feedback for the earlier three patches is positive, I'll work up a clean fix and resubmit. You probably need to separate your handling here. The comparison of the currently checked out sha1 and the recorded sha1 is an optimization which skips unnecessary fetching in case the submodules commits are already correct. This code snippet checks whether the to be checked out sha1 is already local and also skips the fetch if it is. We should not break that. Maybe we need an else block here and possibly extract the current code inside the if statement into a function. E.g. that the final code looks something like this: if test $subsha1 != $sha1 then handle_on_demand_fetch_update ... else handle_tracked_branch_update ... fi Not sure about the function names though. If we decide to go that route: The extraction into a function should go in an extra preparation patch which does not change any functionality. I will reply to the patches for further comments. Cheers Heiko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
Magnus Bäck ba...@google.com: While constant traffic probably overstates the issue, these are not theoretical problems. I recall at least three cases in the last year or so where Git has seen breakage with Solaris or Mac OS X because of sed or tr incompatibilities, and I don't even read this list that thoroughly. This is exactly the sort of of pain experience would lead me to expect. OK, this is where I assume the full Old Fart position (30-year old-school Unix guy, author of The Art of Unix Programming, can remember the years before Perl and still has sh idioms in his fingertips) and say Get with the 21st century, people! Or at least 1990... As a general scripting language shell sucks *really badly* compared to anything new-school. Performance, portability, you name it, it's a mess. It's not so much the shell interpreters itself that are the portabilty problem, but (as Magnus implicitly points out) all those userland dependencies on sed and tr and awk and even variants of expr(!) that get dragged in the second you try to get any actual work done. Can we cease behaving like we're still pounding keys on 110-baud teletypes now? Some old-school Unix habits have persisted long past the point that they're even remotely sane. Shell programming at any volume above a few lines of throwaway code is one of them - it's *nuts* and we should *stop doing it*. (Yes, I too still make this mistake occasionally out of ancient reflex. But I know I shouldn't, and I always end up regretting it.) -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/4] git-submodule update: Add --branch option
On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote: From: W. Trevor King wk...@tremily.us This allows users to checkout the current superproject-recorded-submodule-sha as a branch, avoiding the detached head state that the standard submodule update creates. This may be useful for the existing --rebase/--merge workflows which already avoid detached heads. It is also useful if you want easy tracking of upstream branches. The particular upstream branch to be tracked is configured locally with .git/modules/name/config. With the new option Ævar's suggested $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitm odules submodule.$name.branch) git pull' reduces to a $ git submodule update --branch after each supermodule .gitmodules edit, and a $ git submodule foreach 'git pull' whenever you feel like updating the submodules. Your still on you're own to commit (or not) the updated submodule hashes in the superproject's .gitmodules. Signed-off-by: W. Trevor King wk...@tremily.us --- Documentation/git-submodule.txt | 20 +++-- git-submodule.sh| 48 +-- t/t7406-submodule-update.sh | 50 - 3 files changed, 98 insertions(+), 20 deletions(-) diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt index d0b4436..34392a1 100644 --- a/Documentation/git-submodule.txt +++ b/Documentation/git-submodule.txt @@ -13,7 +13,7 @@ SYNOPSIS [-f|--force] [--reference repository] [--] repository [path] 'git submodule' [--quiet] status [--cached] [--recursive] [--] [path...] 'git submodule' [--quiet] init [--] [path...] -'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase] +'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--branch] [--rebase] [--reference repository] [--merge] [--recursive] [--] [path...] 'git submodule' [--quiet] summary [--cached|--files] [(-n|--summary-limit) n] [commit] [--] [path...] @@ -136,11 +136,11 @@ init:: update:: Update the registered submodules, i.e. clone missing submodules and - checkout the commit specified in the index of the containing repository. - This will make the submodules HEAD be detached unless `--rebase` or - `--merge` is specified or the key `submodule.$name.update` is set to - `rebase`, `merge` or `none`. `none` can be overridden by specifying - `--checkout`. + checkout the commit specified in the index of the containing + repository. This will make the submodules HEAD be detached unless + `--branch`, `--rebase`, `--merge` is specified or the key + `submodule.$name.update` is set to `branch`, `rebase`, `merge` or + `none`. `none` can be overridden by specifying `--checkout`. + If the submodule is not yet initialized, and you just want to use the setting as stored in .gitmodules, you can automatically initialize the @@ -207,7 +207,13 @@ OPTIONS -b:: --branch:: - Branch of repository to add as submodule. + When used with the add command, gives the branch of repository to + add as submodule. ++ +When used with the update command, checks out a branch named +`submodule.name.branch` (as set by `--local-branch`) pointing at the +current HEAD SHA-1. This is useful for commands like `update +--rebase` that do not work on detached heads. Since you are reusing this option for update it further convinces me that reusing it for add makes sense and simplifies the logic for users. I think an optional argument for --branch would be nice in the update case: $ git submodule update --branch=master would then allow a user that has not configured anything (except the branch tracking info in the submodule of course) to pull all submodules master branches. diff --git a/git-submodule.sh b/git-submodule.sh index c51b6ae..28eb4b1 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?) die $(eval_gettext Unable to find current revision in submodule path '\$sm_path') fi - if test $subsha1 != $sha1 -o -n $force + if test $subsha1 != $sha1 -o -n $force -o $update_module = branch As said before I think separating your code from the current update logic will simplify the handling below. then subforce=$force # If we don't already have a -f flag and the submodule has never been checked out @@ -650,16 +654,21 @@ Maybe you want to use 'update --init'?) case ;$cloned_modules; in *;$name;*) # then there is no local change to integrate - update_module= ;; + case $update_module in +
Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote: I would prefer if we could squash all these commits together into one since it seems to me one logical step, using the new variable for update belongs together with its configuration on initialization. Works for me. I could also try to rework the patch boundaries if a monolithic patch is not acceptable. I agree that the current documentation assignments are fairly arbitrary. If I don't hear from anyone in favor of keeping them separate, v5 will be monolithic. -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH] diff: Fixes shortstat number of files
Antoine Pelisse apeli...@gmail.com writes:
Indeed stat seems to be broken on master by commit 74faaa16 from Linus
Torvalds
There are three separated issues here:
- unmerged files are marked as interesting in stat and probably
shouldn't, with some patch like this:
data-is_interesting = p-status != 0;
if (!one || !two) {
data-is_unmerged = 1;
+ data-is_interesting = 0;
return;
}
By the way, I don't get the point of this code then:
else if (data-files[i]-is_unmerged) {
fprintf(options-file, %s, line_prefix);
show_name(options-file, prefix, name, len);
fprintf(options-file, Unmerged\n);
continue;
}
and
if (file-is_unmerged) {
/* Unmerged is 8 characters */
bin_width = bin_width 8 ? 8 : bin_width;
continue;
}
Are we ever supposed to print that ? I feel like it could be removed.
Yes, we have been showing two entries in --stat output:
file | Unmerged
file | 4
and that is not going to change.
There are a few problems in diff.c around --stat area, partially
caused by Linus's patch (like s/is_rename/is_interesting/ change
started ignoring unmerged entries in the diff queue and made the
existing loop not go into the codepath we see above), and largely
caused by the earlier change that introduced when --stat-count was
added (the second loop that decrements total_files does so only for
the paths within the count horizon determined by the first loop;
total_files must be adjusted for _all_ uninteresting and unchanged
filepairs and exclude unmerged entries).
Also the initialization of data-is_interesting is wrong. These
days, p-status is never zero.
I'll send out a fix later today.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote: On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote: From: W. Trevor King wk...@tremily.us On Fri, Nov 23, 2012 at 12:54:02PM -0500, W. Trevor King wrote: We could add $ git submodule update --branch to checkout the gitlinked SHA1 as submodule.name.branch in each of the submodules, leaving the submodules on the .gitmodules-configured branch. Effectively (for each submodule): $ git branch -f $branch $sha1 $ git checkout $branch I haven't gotten any feedback on this as an idea, but perhaps someone will comment on it as a patch series ;). I am not sure I understand you correctly. You are suggesting that the branch option as an alias for the registered SHA1 in the superproject? I though the goal of your series was that you want to track submodules branch which come from the remote side? That's what I'd initially thought, but when I went to implement `update --pull`, I realized that $ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) …' is using submodule.name.branch as the local branch name. The remote branch name was actually setup in .git/modules/name/config during the initial clone -b branch …. The v4 series leaves the remote branch amigious, but it helps you point the local branch at the right hash so that future calls to $ git submodule foreach 'git pull' can use the branch's .git/modules/name/config settings. I would think more of some convention like: $ git checkout -t origin/$branch when first initialising the submodule with e.g. $ git submodule update --init --branch Then later calls of $ git submodule update --branch would have a branch configured to pull from. I imagine that results in a similar behavior gerrit is doing on the server side? That sounds like it's doing pretty much the same thing. Can you think of a test that would distinguish it from my current v4 implementation? Changes since v3: * --record=??? is now --local-branch=??? * Dropped patches 2 ($submodule_ export) and 3 (motivating documentation) * Added local git-config overrides of .gitmodules' submodule.name.branch * Added `submodule update --branch` I would prefer if we could squash all these commits together into one since it seems to me one logical step, using the new variable for update belongs together with its configuration on initialization. How about reusing the -b|--branch option for add? Since we only change the behavior when submodule.$name.update is set to branch it seems reasonable to me. Opinions? That was the approach I used in v1, but people were concerned that we would be stomping on previously unclaimed config space. Since noone has pointed out other uses besides Gerrit's very similar case, I'm not sure if that is still an issue. Because you need to recurse through submodules for `update --branch` even if $subsha1 == $sha1, I had to amend the conditional controlling that block. This broke one of the existing tests, which I fixed in patch 4. I think a proper fix would involve rewriting (clear_local_git_env; cd $sm_path ( (rev=$(git rev-list -n 1 $sha1 --not --all 2/dev/null) test -z $rev) || git-fetch)) || die $(eval_gettext Unable to fetch in submodule path '\$sm_path') but I'm not familiar enough with rev-list to want to dig into that yet. If feedback for the earlier three patches is positive, I'll work up a clean fix and resubmit. You probably need to separate your handling here. The comparison of the currently checked out sha1 and the recorded sha1 is an optimization which skips unnecessary fetching in case the submodules commits are already correct. This code snippet checks whether the to be checked out sha1 is already local and also skips the fetch if it is. We should not break that. Agreed. However, determining if the target $sha1 is local should have nothing to do with the current checked out $subsha1. Thanks for the feedback! Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
Re: [PATCH v4 3/4] git-submodule update: Add --branch option
On Tue, Nov 27, 2012 at 07:51:42PM +0100, Heiko Voigt wrote:
On Mon, Nov 26, 2012 at 04:00:18PM -0500, W. Trevor King wrote:
-b::
--branch::
- Branch of repository to add as submodule.
+ When used with the add command, gives the branch of repository to
+ add as submodule.
++
+When used with the update command, checks out a branch named
+`submodule.name.branch` (as set by `--local-branch`) pointing at the
+current HEAD SHA-1. This is useful for commands like `update
+--rebase` that do not work on detached heads.
Since you are reusing this option for update it further convinces me
that reusing it for add makes sense and simplifies the logic for users.
I think an optional argument for --branch would be nice in the update
case:
$ git submodule update --branch=master
would then allow a user that has not configured anything (except the
branch tracking info in the submodule of course) to pull all submodules
master branches.
Sounds good to me. Remember that this is checking the branch and
pointing it at $sha1 (preparing for the pull), not pulling remote
branches. The pull happens in a later
$ git submodules foreach 'git pull'
diff --git a/git-submodule.sh b/git-submodule.sh
index c51b6ae..28eb4b1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -627,7 +631,7 @@ Maybe you want to use 'update --init'?)
die $(eval_gettext Unable to find current revision in
submodule path '\$sm_path')
fi
- if test $subsha1 != $sha1 -o -n $force
+ if test $subsha1 != $sha1 -o -n $force -o
$update_module = branch
As said before I think separating your code from the current update
logic will simplify the handling below.
This felt less invasive (it avoids duplicating the recursion logic),
but I don't mind breaking it into a separate function/block.
must_die_on_failure=
case $update_module in
rebase)
command=git rebase
- die_msg=$(eval_gettext Unable to rebase
'\$sha1' in submodule path '\$sm_path')
+ die_msg=$(eval_gettext Unable to rebase
'\$sha1' in submodule path '\$sm_path')
say_msg=$(eval_gettext Submodule path
'\$sm_path': rebased into '\$sha1')
- must_die_on_failure=yes
+ must_die_on_failure=yes
Please always cleanup whitespace changes.
Oops, sloppy me. Will fix.
then
- die_with_status 2 $die_msg
- else
- err=${err};$die_msg
- continue
+ if (clear_local_git_env; cd $sm_path
+ git branch -f $branch $sha1
+ git checkout $branch)
You wrote in earlier emails that you wanted to protect the user from
non-fastforward changes. So I would expect a
$ git pull --ff-only
I'm not pulling here, I'm doing a regular `submodule update`, and
after that's done I checkout the branch pointing at the $sha1 to which
the branch was just updated. All the submodule-state-clobbering
caveats of a usual `submodule update` still apply to this new
`submodule update --branch`, and I'm fine with that.
BTW, I am more and more convinced that an automatically manufactured
commit on update with --branch should be the default.
Again, there's nothing to update. The pull happens in a separate
step.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
Re: Operations on unborn branch
Martin von Zweigbergk martinv...@gmail.com writes: simplify a lot of things (maybe I'm biased because of the things I have happened to work on?) Yes. Do not waste time on it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Interesting git-format-patch bug
[Sorry for the top posting. Outlook is crap.] You are correct. I should only get one copy of the patch on branch A. Branch B was modified after the merge and git-format-patch includes the original patch from the merge and a duplicate copy with the changed comments. Note that this patch only has different comments. The body of the patch is exactly the same. How gerrit mangles things is out of my control. I would prefer that they cherry-pick instead of merges. I have to live with the bad choices of both gerrit and developers in this case. I guess I will have to diagram out a better example of what is happening here. -Original Message- From: Perry Hutchison [mailto:per...@pluto.rain.com] Sent: Monday, November 26, 2012 8:15 PM To: gits...@pobox.com Cc: git@vger.kernel.org; Olsen, Alan R Subject: Re: Interesting git-format-patch bug Junio C Hamano gits...@pobox.com wrote: Olsen, Alan R alan.r.ol...@intel.com writes: I found an interesting bug in git-format-patch. Say you have a branch A. You create branch B and add a patch to it. You then merge that patch into branch A. After the merge, some other process (we will call it 'gerrit') uses annotate and changes the comment on the patch that exists on branch B. Now someone runs git-format-patch for the last n patches on branch A. You should just get the original patch that was merged over to branch A. What you get is the patch that was merged to branch A *and* the patch with the modified commit comment on branch B. (Double the patches, double the clean-up...) As you literally have patches that do essentially the same or similar things on two branches that was merged, you cannot expect to export each individual commit into a patch and not have conflicts among them. So I do not think there is no answer than don't do that. To me, this seems to miss Alan's point: only one patch was merged to branch A, so git-format-patch applied to branch A should find only one patch. It can be argued either way whether that one-patch report should include the gerrit annotations, but surely the application of gerrit on branch B, _after the merge to branch A has already been performed_, should not cause an additional patch to magically appear on branch A. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-gui: textconv not used on unstaged files
On 2012-11-26 21:54, Junio C Hamano wrote: Peter Oberndorfer kumbay...@arcor.de writes: Does anybody have a idea which git command would output the diff of a untracked file against /dev/null? The --no-index option is meant as a bolt-on to let you use various features of git diff that is missing from other people's diff in a context where git does not know anything about that file. It should be usable even outside a git repository. $ git diff --no-index /dev/null new-file.txt I do not know offhand (and didn't bother to check) if textconv applies, though. It does need access to a git repository as it reads from the $GIT_DIR/config to learn what to do. Hi, this seems to work when adding the --textconv option. I will try to see if I can modify git gui to use this command when clicking a unstaged file. Thanks, Greetings Peter -- 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: Operations on unborn branch
On Tue, Nov 27, 2012 at 12:25 PM, Junio C Hamano gits...@pobox.com wrote: Martin von Zweigbergk martinv...@gmail.com writes: simplify a lot of things (maybe I'm biased because of the things I have happened to work on?) Yes. Do not waste time on it. Yes, no way I would waste time on that; I was mostly just curious. What I might spend time on is to fix cherry-pick. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] Fix grammar
Max Horn m...@quendi.de writes: Subject: Re: [PATCH 3/6] Fix grammar Please run git shortlog -200 --no-merges from the tip of your topic branch before sending a series out, and see if you can immediately identify what area each of your patches affects. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index db63541..7eb43d7 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line. 'capabilities':: Lists the capabilities of the helper, one per line, ending with a blank line. Each capability may be preceded with '*', - which marks them mandatory for git version using the remote - helper to understand (unknown mandatory capability is fatal - error). + which marks them mandatory for git versions using the remote + helper to understand. Any unknown mandatory capability is a + fatal error. 'list':: Lists the refs, one per line, in the format value 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
Millisecond precision in timestamps?
Because I do a lot of work on repository conversion tools, I've had to learn a lot of detail about ontological mismatches between version-control systems - especially places where you lose metadata moving between them. In general, git metadata can carry forward almost all the metadata in a Subversion repository. Among the handful of minor exceptions (empty directories, flow structure, certain kinds of mergeinfos) there is one that stands out because it seems to be an implementation detail rather than a consequence of fundamentally different design decisions. I refer to the one-second precision of git timestamps. Subversion stores its commit and property-change timestamps to microsecond precision; conversion tools have to throw the subsecond part of this information away. Has going to timestamps with the full precision of the system clock been considered and rejected, or am I the first to bring this up? If I were to write refactoring patches that treated timestamp as an ADT, with a view towards hiding the difference between int and float timestamps and eventually experimenting with float ones, would they be accepted? -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a Every Communist must grasp the truth, 'Political power grows out of the barrel of a gun.' -- Mao Tse-tung, 1938, inadvertently endorsing the Second Amendment. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Wed, Nov 28, 2012 at 12:05 AM, Eric S. Raymond e...@thyrsus.com wrote: Magnus Bäck ba...@google.com: While constant traffic probably overstates the issue, these are not theoretical problems. I recall at least three cases in the last year or so where Git has seen breakage with Solaris or Mac OS X because of sed or tr incompatibilities, and I don't even read this list that thoroughly. This is exactly the sort of of pain experience would lead me to expect. OK, this is where I assume the full Old Fart position (30-year old-school Unix guy, author of The Art of Unix Programming, can remember the years before Perl and still has sh idioms in his fingertips) and say Get with the 21st century, people! Or at least 1990... As a general scripting language shell sucks *really badly* compared to anything new-school. Performance, portability, you name it, it's a mess. It's not so much the shell interpreters itself that are the portabilty problem, but (as Magnus implicitly points out) all those userland dependencies on sed and tr and awk and even variants of expr(!) that get dragged in the second you try to get any actual work done. Not always. There are several situations where a shell script that makes good use of grep, cut, etc., is definitely much cleaner and more elegant than anything you can do in a propah programming language. If the price of doing that is sticking to a base set of primitives, it's a small price to pay, not much different from sticking to python 2.7 or perl 5.8 or whatever. Shell *is* the universal scripting language, not perl (even though we all know it is what God himself used to create the world -- see xkcd 224 if you don't believe me!), not python, not Ruby. -- sitaram -- 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: difftool -d symlinks, under what conditions
On Tuesday, November 27, 2012, David Aguilar wrote: It seems that there is an edge case here that we are not accounting for: unmodified worktree paths, when checked out into the temporary directory, can be edited by the tool when comparing against older commits. These edits will be lost. Yes. That is exactly my desired use case. I want to make edits while I'm reviewing the diff. When we can do that then we avoid needing to have a temporary directory altogether for any dir-diffs that involve the worktree. I think the temporary directory is still a good thing. Without it, the directory diff tool would have no way to distinguish a file added in the diff from a file that was preexisting and unmodified. -- Matt McClure http://www.matthewlmcclure.com http://www.mapmyfitness.com/profile/matthewlmcclure -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 4/4] Hack fix for 'submodule update does not fetch already present commits'
On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote: On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote: On Mon, Nov 26, 2012 at 04:00:15PM -0500, W. Trevor King wrote: Because you need to recurse through submodules for `update --branch` even if $subsha1 == $sha1, I had to amend the conditional controlling that block. This broke one of the existing tests, which I fixed in patch 4. I think a proper fix would involve rewriting (clear_local_git_env; cd $sm_path ( (rev=$(git rev-list -n 1 $sha1 --not --all 2/dev/null) test -z $rev) || git-fetch)) || die $(eval_gettext Unable to fetch in submodule path '\$sm_path') but I'm not familiar enough with rev-list to want to dig into that yet. If feedback for the earlier three patches is positive, I'll work up a clean fix and resubmit. You probably need to separate your handling here. The comparison of the currently checked out sha1 and the recorded sha1 is an optimization which skips unnecessary fetching in case the submodules commits are already correct. This code snippet checks whether the to be checked out sha1 is already local and also skips the fetch if it is. We should not break that. Agreed. However, determining if the target $sha1 is local should have nothing to do with the current checked out $subsha1. Erm, I clearly wasn't getting enough sleep heading into yesterday, because when I drop the hack patch #4, reinstall, and retest, I no longer get the bad-fetch error. I'm not quite sure what was going on, but please pretend I never mentioned it ;). -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy signature.asc Description: OpenPGP digital signature
[PATCH 0/5] diff --stat counting fixes
It turns out that there are at least two bugs in the diffstat counting code. This series comes on top of the earlier 74faaa1 (Fix git diff --stat for interesting - but empty - file changes, 2012-10-17) to fix them. Junio C Hamano (5): test: add failing tests for diff --stat to t4049 diff --stat: status of unmodified pair in diff-q is not zero diff --stat: use file temporary variable to refer to data-files[i] diff --stat: move the total count logic to the last loop diff --stat: do not count unmerged entries diff.c | 49 +- t/t4049-diff-stat-count.sh | 46 ++- 2 files changed, 72 insertions(+), 23 deletions(-) -- 1.8.0.1.331.g808d2af -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] test: add failing tests for diff --stat to t4049
There are a few problems in diff.c around --stat area, partially caused by the recent 74faaa1 (Fix git diff --stat for interesting - but empty - file changes, 2012-10-17), and largely caused by the earlier change that introduced when --stat-count was added. Add a few test pieces to t4049 to expose the issues. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t4049-diff-stat-count.sh | 46 +- 1 file changed, 45 insertions(+), 1 deletion(-) diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh index 7b3ef00..e212b11 100755 --- a/t/t4049-diff-stat-count.sh +++ b/t/t4049-diff-stat-count.sh @@ -4,12 +4,17 @@ test_description='diff --stat-count' . ./test-lib.sh -test_expect_success setup ' +test_expect_success 'setup' ' a b c d git add a b c d + git commit -m initial +' + +test_expect_success 'limit output to 2 (simple)' ' + git reset --hard chmod +x c d echo a a echo b b @@ -23,4 +28,43 @@ test_expect_success setup ' test_i18ncmp expect actual ' +test_expect_failure 'binary changes do not count in lines' ' + git reset --hard + chmod +x c d + echo a a + echo b b + cat $TEST_DIRECTORY/test-binary-1.png d + cat expect -\EOF +a | 1 + +b | 1 + +... +4 files changed, 2 insertions(+) + EOF + git diff --stat --stat-count=2 actual + test_i18ncmp expect actual +' + +test_expect_failure 'exclude unmerged entries from total file count' ' + git reset --hard + echo a a + echo b b + git ls-files -s a x + git rm -f d + for stage in 1 2 3 + do + sed -e s/ 0a/ $stage d/ x + done | + git update-index --index-info + echo d d + chmod +x c d + cat expect -\EOF +a | 1 + +b | 1 + +... +4 files changed, 3 insertions(+) + EOF + git diff --stat --stat-count=2 actual + test_i18ncmp expect actual +' + test_done -- 1.8.0.1.331.g808d2af -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] diff --stat: use file temporary variable to refer to data-files[i]
The generated code shouldn't change but it is easier to read.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/diff.c b/diff.c
index ce6baa4..e4e70e5 100644
--- a/diff.c
+++ b/diff.c
@@ -1470,8 +1470,8 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
for (i = 0; (i count) (i data-nr); i++) {
struct diffstat_file *file = data-files[i];
uintmax_t change = file-added + file-deleted;
- if (!data-files[i]-is_interesting
-(change == 0)) {
+
+ if (!file-is_interesting (change == 0)) {
count++; /* not shown == room for one more */
continue;
}
@@ -1586,13 +1586,13 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
*/
for (i = 0; i count; i++) {
const char *prefix = ;
- char *name = data-files[i]-print_name;
- uintmax_t added = data-files[i]-added;
- uintmax_t deleted = data-files[i]-deleted;
+ struct diffstat_file *file = data-files[i];
+ char *name = file-print_name;
+ uintmax_t added = file-added;
+ uintmax_t deleted = file-deleted;
int name_len;
- if (!data-files[i]-is_interesting
-(added + deleted == 0)) {
+ if (!file-is_interesting (added + deleted == 0)) {
total_files--;
continue;
}
@@ -1611,7 +1611,7 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
name = slash;
}
- if (data-files[i]-is_binary) {
+ if (file-is_binary) {
fprintf(options-file, %s, line_prefix);
show_name(options-file, prefix, name, len);
fprintf(options-file, %*s, number_width, Bin);
@@ -1628,7 +1628,7 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
fprintf(options-file, \n);
continue;
}
- else if (data-files[i]-is_unmerged) {
+ else if (file-is_unmerged) {
fprintf(options-file, %s, line_prefix);
show_name(options-file, prefix, name, len);
fprintf(options-file, Unmerged\n);
@@ -1668,10 +1668,10 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
fprintf(options-file, \n);
}
for (i = count; i data-nr; i++) {
- uintmax_t added = data-files[i]-added;
- uintmax_t deleted = data-files[i]-deleted;
- if (!data-files[i]-is_interesting
-(added + deleted == 0)) {
+ struct diffstat_file *file = data-files[i];
+ uintmax_t added = file-added;
+ uintmax_t deleted = file-deleted;
+ if (!file-is_interesting (added + deleted == 0)) {
total_files--;
continue;
}
--
1.8.0.1.331.g808d2af
--
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 5/5] diff --stat: do not count unmerged entries
Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.
The separation done by the previous step makes this fix simple and
straightforward. Among the filepairs in diff_queue, paths that
weren't modified, and the extra unmerged entries do not count as
total number of files.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff.c | 6 --
t/t4049-diff-stat-count.sh | 2 +-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 4105260..26ede82 100644
--- a/diff.c
+++ b/diff.c
@@ -1669,12 +1669,14 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
struct diffstat_file *file = data-files[i];
uintmax_t added = file-added;
uintmax_t deleted = file-deleted;
- if (!file-is_interesting (added + deleted == 0)) {
+
+ if (file-is_unmerged ||
+ (!file-is_interesting (added + deleted == 0))) {
total_files--;
continue;
}
- if (!file-is_binary !file-is_unmerged) {
+ if (!file-is_binary) {
adds += added;
dels += deleted;
}
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index 70ee073..37f50cd 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -44,7 +44,7 @@ test_expect_success 'binary changes do not count in lines' '
test_i18ncmp expect actual
'
-test_expect_failure 'exclude unmerged entries from total file count' '
+test_expect_success 'exclude unmerged entries from total file count' '
git reset --hard
echo a a
echo b b
--
1.8.0.1.331.g808d2af
--
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 4/5] diff --stat: move the total count logic to the last loop
The diffstat generation logic, with --stat-count limit, is
implemented as three loops.
- The first counts the width necessary to show stats up to
specified number of entries, and notes up to how many entries in
the data we need to iterate to show the graph;
- The second iterates that many times to draw the graph, adjusts
the number of total modified files, and counts the total
added/deleted lines for the part that was shown in the graph;
- The third iterates over the remainder and only does the part to
count total added/deleted lines and to adjust total modified
files without drawing anything.
Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.
This incidentally fixes a bug. The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should. The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff.c | 21 -
t/t4049-diff-stat-count.sh | 2 +-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/diff.c b/diff.c
index e4e70e5..4105260 100644
--- a/diff.c
+++ b/diff.c
@@ -1498,7 +1498,7 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
if (max_change change)
max_change = change;
}
- count = i; /* min(count, data-nr) */
+ count = i; /* where we can stop scanning in data-files[] */
/*
* We have width = stat_width or term_columns() columns total.
@@ -1592,10 +1592,9 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
uintmax_t deleted = file-deleted;
int name_len;
- if (!file-is_interesting (added + deleted == 0)) {
- total_files--;
+ if (!file-is_interesting (added + deleted == 0))
continue;
- }
+
/*
* scale the filename
*/
@@ -1640,8 +1639,6 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
*/
add = added;
del = deleted;
- adds += add;
- dels += del;
if (graph_width = max_change) {
int total = add + del;
@@ -1667,7 +1664,8 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
show_graph(options-file, '-', del, del_c, reset);
fprintf(options-file, \n);
}
- for (i = count; i data-nr; i++) {
+
+ for (i = 0; i data-nr; i++) {
struct diffstat_file *file = data-files[i];
uintmax_t added = file-added;
uintmax_t deleted = file-deleted;
@@ -1675,8 +1673,13 @@ static void show_stats(struct diffstat_t *data, struct
diff_options *options)
total_files--;
continue;
}
- adds += added;
- dels += deleted;
+
+ if (!file-is_binary !file-is_unmerged) {
+ adds += added;
+ dels += deleted;
+ }
+ if (i count)
+ continue;
if (!extra_shown)
fprintf(options-file, %s ...\n, line_prefix);
extra_shown = 1;
diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
index e212b11..70ee073 100755
--- a/t/t4049-diff-stat-count.sh
+++ b/t/t4049-diff-stat-count.sh
@@ -28,7 +28,7 @@ test_expect_success 'limit output to 2 (simple)' '
test_i18ncmp expect actual
'
-test_expect_failure 'binary changes do not count in lines' '
+test_expect_success 'binary changes do not count in lines' '
git reset --hard
chmod +x c d
echo a a
--
1.8.0.1.331.g808d2af
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] Fix grammar
On 27.11.2012, at 21:39, Junio C Hamano wrote: Max Horn m...@quendi.de writes: Subject: Re: [PATCH 3/6] Fix grammar Please run git shortlog -200 --no-merges from the tip of your topic branch before sending a series out, and see if you can immediately identify what area each of your patches affects. First off: I apologize for the inconvenience my stumbling causes :-(, and I'll try to learn and do better next time I send this or another series. In this particular case, I am not 100% sure if I understood you correctly, i.e. what exactly you are trying to tell me. Is it (in a nutshell) that the subject lines of my commits suck, as they don't identify which area of code they touch? At least that's the thing I notice when looking at that shortlog... Bad, of course... If this is indeed it, would a commit message like git-remote-helper.txt: minor grammar fix be OK? If this is indeed it, I'll be happy to reroll and resubmit the series accordingly. If I am mistaken and something else / more is wrong, please be so kind and let me know, too. Sorry once more and thank you very much for your feedback, Max Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index db63541..7eb43d7 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line. 'capabilities':: Lists the capabilities of the helper, one per line, ending with a blank line. Each capability may be preceded with '*', -which marks them mandatory for git version using the remote -helper to understand (unknown mandatory capability is fatal -error). +which marks them mandatory for git versions using the remote +helper to understand. Any unknown mandatory capability is a +fatal error. 'list':: Lists the refs, one per line, in the format value 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 -- 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: Millisecond precision in timestamps?
On Tue, Nov 27, 2012 at 12:48 PM, Eric S. Raymond e...@thyrsus.com wrote: Because I do a lot of work on repository conversion tools, I've had to learn a lot of detail about ontological mismatches between version-control systems - especially places where you lose metadata moving between them. In general, git metadata can carry forward almost all the metadata in a Subversion repository. Among the handful of minor exceptions (empty directories, flow structure, certain kinds of mergeinfos) there is one that stands out because it seems to be an implementation detail rather than a consequence of fundamentally different design decisions. I refer to the one-second precision of git timestamps. Subversion stores its commit and property-change timestamps to microsecond precision; conversion tools have to throw the subsecond part of this information away. Has going to timestamps with the full precision of the system clock been considered and rejected, or am I the first to bring this up? If I were to write refactoring patches that treated timestamp as an ADT, with a view towards hiding the difference between int and float timestamps and eventually experimenting with float ones, would they be accepted? JGit would fortunately ignore a floating point timestamp specification if given in a commit, but I don't know about other Git implementations... like say git. :-) -- 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: Millisecond precision in timestamps?
-Original Message- From: Eric S. Raymond Sent: Tuesday, November 27, 2012 3:48 PM Because I do a lot of work on repository conversion tools, I've had to learn a lot of detail about ontological mismatches between version-control systems - especially places where you lose metadata moving between them. In general, git metadata can carry forward almost all the metadata in a Subversion repository. Among the handful of minor exceptions (empty directories, flow structure, certain kinds of mergeinfos) there is one that stands out because it seems to be an implementation detail rather than a consequence of fundamentally different design decisions. I refer to the one-second precision of git timestamps. Subversion stores its commit and property-change timestamps to microsecond precision; conversion tools have to throw the subsecond part of this information away. Has going to timestamps with the full precision of the system clock been considered and rejected, or am I the first to bring this up? If I were to write refactoring patches that treated timestamp as an ADT, with a view towards hiding the difference between int and float timestamps and eventually experimenting with float ones, Do you really mean floating point numbers with approximate imprecise values? smime.p7s Description: S/MIME cryptographic signature
Re: Python extension commands in git - request for policy change
Le mardi 27 novembre 2012 02:51:04 David Aguilar a écrit : On Tue, Nov 27, 2012 at 1:17 AM, Sitaram Chamarty sitar...@gmail.com wrote: On Tue, Nov 27, 2012 at 1:24 PM, David Aguilar dav...@gmail.com wrote: *cough* git-cola *cough* it runs everywhere. Yes, windows too. It's written in python. It's been actively maintained since 2007. It's modern and has features that don't exist anywhere else. It even has tests. It even comes with a building full of willing guinea-pigs^Wtesters that let me know right away when anything goes wrong. It uses Qt but that's really the whole point of Qt - cross-platform. (not sure how that wiki page ended up saying Gnome/GTK?) The DAG aka git-dag (in its master branch, about to be released) is nicer looking then gitk IMO. gitk still has some features that are better too--there's no silver bullet, but the delta is pretty small. Gitk does a lot of things that people don't realise, since they're not really documented and you have to scrounge around on the UI. The thing is, it's just about the most awesome tool for code archeology I have seen. I realise (from looking at the doc page) that git-cola helps you do all sorts of things, but those are all things I am happier doing at the command line. Ditto. There's actually a few small things I use it for, mainly for teasing apart commits. These days you can use git-gui for that, but in the old days it was the only way to interactively select individual lines and stage/unstage/revert them, etc. I don't think we can line-by-line revert in git-gui yet, though. Some other small things that I use: ctrl-g, type something for grep, hit enter twice and I'm in my editor on that (or any other selected) line. 'spacebar' does xdg-open, and 'enter' launches the editor in the status widget; small things. I, too, do most stuff on the command line. The grep thing is a good example. You have tons of output, you see the one line that you care about, and you want to jump there. Clicking on that line and hitting enter is the minimal effort to do that. You don't have to click because we also have keyboard navigation. I have a feeling that there's probably something I'm missing, though.. another way of working (emacs?) that would render all of this custom GUI stuff pointless. What I learned about users: The commit editor is the #1 thing that got my coworkers finally writing better commit messages. It forces the subject/description separation and shows yellow, red when the subject gets too long. It also auto-wraps. IMO it makes sense for git-gui to do the same these days. Gitk does precisely those things which *require* a GUI, where the amount of information presented overwhelms a text interface. The display is concisely designed to give you the maximum information at a minimum space use. For example, a little black square when a commit has a note attached. Even hovering over the arrow-heads, on complex trees where the line gets broken, does something meaningful. if I had to pin it down, the feature I use most often is Show origin of this line. Other features I use often are - review a commit file by file (f and b keys, also spacebar and 'd') - search by SHA1 (4 digits appear to be enough, regardless of how big your repo is), - search for commits changing path/dir (while still showing all the commits; i.e., this is not 'git-dag -- README.txt' but within gitk you search up and down for commits touching README.txt - and navigating the commit tree looking for stuff http://sitaramc.github.com/1-basic-usage/gitk.html is my attempt to document some of the stuff I have found and use. Wow, this is awesome. One final point: the DAG on the right wastes enormous amounts of space. Purely subjectively, it is almost jarring on the senses. (If you reduce it, it becomes unreadable). With all due respect, git-cola/dag isn't anywhere near what gitk does, at least for people who are not afraid of the command line and only need the GUI to visualise a truly complex tree. This is really great feedback. cc:ing Guillaume since he had similar ideas. thx, Thanks David for cc:ing me. I'm sorry I was quite below the radar lately, had too much work to get back on the dag. What I would really like for the dag is to become as useful as the treeview in git extensions (http://code.google.com/p/gitextensions/), where it is the central place for checkout, merge, cherry picks... My only complaint with git extensions is that it is poorly integrated on my linux desktop, due to framework choice (let's not start a flame war here, it's not the point). On the other hand, git-cola is quite easy to hack on thanks to its python roots, well integrated on all OS thanks to Qt, so I thought it would be great to make it at least on par. Had an opportunity to rework the visuals on the dag, but
Re: [PATCH 3/6] Fix grammar
Max Horn m...@quendi.de writes: If this is indeed it, would a commit message like git-remote-helper.txt: minor grammar fix Perfect. 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: Millisecond precision in timestamps?
Shawn Pearce spea...@spearce.org writes: JGit would fortunately ignore a floating point timestamp specification if given in a commit, but I don't know about other Git implementations... like say git. :-) fsck_ident() in fsck.c rejects anything but [1-9][0-9]* after the author and committer ident (i.e. the timestamp has to be integral number of seconds since the epoch, not before it, nor with fractional seconds). -- 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 6/5] diff --shortstat: do not count unmerged entries
Fix the same issue as the previous one for git diff --stat;
unmerged entries was doubly-counted.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
diff.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/diff.c b/diff.c
index 26ede82..374b235 100644
--- a/diff.c
+++ b/diff.c
@@ -1701,9 +1701,8 @@ static void show_shortstats(struct diffstat_t *data,
struct diff_options *option
int added = data-files[i]-added;
int deleted= data-files[i]-deleted;
- if (data-files[i]-is_unmerged)
- continue;
- if (!data-files[i]-is_interesting (added + deleted == 0)) {
+ if (data-files[i]-is_unmerged ||
+ (!data-files[i]-is_interesting (added + deleted ==
0))) {
total_files--;
} else if (!data-files[i]-is_binary) { /* don't count bytes */
adds += added;
--
1.8.0.1.337.gd2c5e06
--
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 2/6] git-remote-helpers.txt: document missing capabilities
Specifically, document the 'export' and '(im|ex)port-marks' capabilities as well as the export command, which were undocumented (but in active use). Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 45 +--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 9a7e583..db63541 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -106,6 +106,10 @@ to the `capabilities` command (see COMMANDS, below). For listing remote refs and fetching the associated history to the local object store. +'export':: + For listing remote refs and pushing specified objects from a + fast-import stream to remote refs. + 'import':: For listing remote refs and fetching the associated history as a fast-import stream. @@ -143,6 +147,16 @@ there is an implied `refspec *:*`. This is to prevent mixing commands and fast-import responses on the helper's stdin. +'export-marks' file:: + This modifies the 'export' capability, instructing git to dump the + internal marks table to file when complete. For details, + read up on '--export-marks=file' in linkgit:git-fast-export[1]. + +'import-marks' file:: + This modifies the 'export' capability, instructing git to load the + marks specified in file before processing any input. For details, + read up on '--import-marks=file' in linkgit:git-fast-export[1]. + Capabilities for Pushing 'connect':: @@ -158,9 +172,18 @@ Supported commands: 'connect'. + Supported commands: 'list for-push', 'push'. -If a helper advertises both 'connect' and 'push', git will use -'connect' if possible and fall back to 'push' if the helper requests -so when connecting (see the 'connect' command under COMMANDS). +'export':: + Can discover remote refs and push specified objects from a + fast-import stream to remote refs. ++ +Supported commands: 'list for-push', 'export'. + +If a helper advertises 'connect', git will use it if possible and +fall back to another capability if the helper requests so when +connecting (see the 'connect' command under COMMANDS). +When choosing between 'push' and 'export', git prefers 'push'. +Other frontends may have some other order of preference. + Capabilities for Fetching ~ @@ -307,6 +330,22 @@ stdin. + Supported if the helper has the 'import' capability. +'export':: + Instructs the remote helper that any subsequent input is + part of a fast-import stream (generated by 'git fast-export') + containing objects which should be pushed to the remote. ++ +Especially useful for interoperability with a foreign versioning +system. ++ +The 'export-marks' and 'import-marks' capabilities, if specified, +affect this command in so far as they are passed on to 'git +fast-export', which then will load/store a table of marks for +local objects. This can be used to implement for incremental +operations. ++ +Supported if the helper has the 'export' capability. + 'connect' service:: Connects to given service. Standard input and standard output of helper are connected to specified service (git prefix is -- 1.8.0.393.gcc9701d -- 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 1/6] git-remote-helpers.txt: document invocation before input format
In the distant past, the order things were documented was 'Invocation', 'Commands', 'Capabilities', ... Then it was decided that before giving a list of Commands, there should be an overall description of the 'Input format', which was a wise decision. However, this description was put as the very first thing, with the rationale that any implementor would want to know that first. However, it seems an implementor would actually first need to know how the remote helper will be invoked, so moving 'Invocation' to the front again seems logical. Moreover, we now don't switch from discussing the input format to the invocation style and then back to input related stuff. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 62 ++-- 1 file changed, 31 insertions(+), 31 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 5ce4cda..9a7e583 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -35,6 +35,37 @@ transport protocols, such as 'git-remote-http', 'git-remote-https', 'git-remote-ftp' and 'git-remote-ftps'. They implement the capabilities 'fetch', 'option', and 'push'. +INVOCATION +-- + +Remote helper programs are invoked with one or (optionally) two +arguments. The first argument specifies a remote repository as in git; +it is either the name of a configured remote or a URL. The second +argument specifies a URL; it is usually of the form +'transport://address', but any arbitrary string is possible. +The 'GIT_DIR' environment variable is set up for the remote helper +and can be used to determine where to store additional data or from +which directory to invoke auxiliary git commands. + +When git encounters a URL of the form 'transport://address', where +'transport' is a protocol that it cannot handle natively, it +automatically invokes 'git remote-transport' with the full URL as +the second argument. If such a URL is encountered directly on the +command line, the first argument is the same as the second, and if it +is encountered in a configured remote, the first argument is the name +of that remote. + +A URL of the form 'transport::address' explicitly instructs git to +invoke 'git remote-transport' with 'address' as the second +argument. If such a URL is encountered directly on the command line, +the first argument is 'address', and if it is encountered in a +configured remote, the first argument is the name of that remote. + +Additionally, when a configured remote has 'remote.name.vcs' set to +'transport', git explicitly invokes 'git remote-transport' with +'name' as the first argument. If set, the second argument is +'remote.name.url'; otherwise, the second argument is omitted. + INPUT FORMAT @@ -173,37 +204,6 @@ advertised with this capability must cover all refs reported by the list command. If no 'refspec' capability is advertised, there is an implied `refspec *:*`. -INVOCATION --- - -Remote helper programs are invoked with one or (optionally) two -arguments. The first argument specifies a remote repository as in git; -it is either the name of a configured remote or a URL. The second -argument specifies a URL; it is usually of the form -'transport://address', but any arbitrary string is possible. -The 'GIT_DIR' environment variable is set up for the remote helper -and can be used to determine where to store additional data or from -which directory to invoke auxiliary git commands. - -When git encounters a URL of the form 'transport://address', where -'transport' is a protocol that it cannot handle natively, it -automatically invokes 'git remote-transport' with the full URL as -the second argument. If such a URL is encountered directly on the -command line, the first argument is the same as the second, and if it -is encountered in a configured remote, the first argument is the name -of that remote. - -A URL of the form 'transport::address' explicitly instructs git to -invoke 'git remote-transport' with 'address' as the second -argument. If such a URL is encountered directly on the command line, -the first argument is 'address', and if it is encountered in a -configured remote, the first argument is the name of that remote. - -Additionally, when a configured remote has 'remote.name.vcs' set to -'transport', git explicitly invokes 'git remote-transport' with -'name' as the first argument. If set, the second argument is -'remote.name.url'; otherwise, the second argument is omitted. - COMMANDS -- 1.8.0.393.gcc9701d -- 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 6/6] git-remote-helpers.txt: clarify options ref list attributes
The documentation was misleading in that it gave the impression that 'for-push' could be used as a ref attribute in the output of the 'list' command. That is wrong. Also, explicitly point out the connection between the commands 'list' and 'options' on the one hand, and the sections 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 023dcca..e1df01d 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -227,6 +227,8 @@ Support for this command is mandatory. the name; unrecognized attributes are ignored. The list ends with a blank line. + +See REF LIST ATTRIBUTES for a list of currently defined options. ++ Supported if the helper has the fetch or import capability. 'list for-push':: @@ -248,6 +250,8 @@ Supported if the helper has the push or export capability. for it). Options should be set before other commands, and may influence the behavior of those commands. + +See OPTIONS for a list of currently defined options. ++ Supported if the helper has the option capability. 'fetch' sha1 name:: @@ -256,7 +260,7 @@ Supported if the helper has the option capability. per line, terminated with a blank line. Outputs a single blank line when all fetch commands in the same batch are complete. Only objects which were reported - in the ref list with a sha1 may be fetched this way. + in the output of 'list' with a sha1 may be fetched this way. + Optionally may output a 'lock file' line indicating a file under GIT_DIR/objects/pack which is keeping a pack until refs can be @@ -360,10 +364,9 @@ capabilities reported by the helper. REF LIST ATTRIBUTES --- -'for-push':: - The caller wants to use the ref list to prepare push - commands. A helper might chose to acquire the ref list by - opening a different type of connection to the destination. +The 'list' command produces a list of refs in which each ref +may be followed by a list of attributes. The following ref list +attributes are defined. 'unchanged':: This ref is unchanged since the last import or fetch, although @@ -371,6 +374,10 @@ REF LIST ATTRIBUTES OPTIONS --- + +The following options are defined and (under suitable circumstances) +set by git if the remote helper has the 'option' capability. + 'option verbosity' n:: Changes the verbosity of messages displayed by the helper. A value of 0 for n means that processes operate -- 1.8.0.393.gcc9701d -- 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 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections
The documentation was misleading in that it gave the impression that 'for-push' could be used as a ref attribute in the output of the 'list' command. That is wrong. Also, explicitly point out the connection between the commands 'list' and 'options' on the one hand, and the sections 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 023dcca..e1df01d 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -227,6 +227,8 @@ Support for this command is mandatory. the name; unrecognized attributes are ignored. The list ends with a blank line. + +See REF LIST ATTRIBUTES for a list of currently defined options. ++ Supported if the helper has the fetch or import capability. 'list for-push':: @@ -248,6 +250,8 @@ Supported if the helper has the push or export capability. for it). Options should be set before other commands, and may influence the behavior of those commands. + +See OPTIONS for a list of currently defined options. ++ Supported if the helper has the option capability. 'fetch' sha1 name:: @@ -256,7 +260,7 @@ Supported if the helper has the option capability. per line, terminated with a blank line. Outputs a single blank line when all fetch commands in the same batch are complete. Only objects which were reported - in the ref list with a sha1 may be fetched this way. + in the output of 'list' with a sha1 may be fetched this way. + Optionally may output a 'lock file' line indicating a file under GIT_DIR/objects/pack which is keeping a pack until refs can be @@ -360,10 +364,9 @@ capabilities reported by the helper. REF LIST ATTRIBUTES --- -'for-push':: - The caller wants to use the ref list to prepare push - commands. A helper might chose to acquire the ref list by - opening a different type of connection to the destination. +The 'list' command produces a list of refs in which each ref +may be followed by a list of attributes. The following ref list +attributes are defined. 'unchanged':: This ref is unchanged since the last import or fetch, although @@ -371,6 +374,10 @@ REF LIST ATTRIBUTES OPTIONS --- + +The following options are defined and (under suitable circumstances) +set by git if the remote helper has the 'option' capability. + 'option verbosity' n:: Changes the verbosity of messages displayed by the helper. A value of 0 for n means that processes operate -- 1.8.0.393.gcc9701d -- 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 4/6] git-remote-helpers.txt: rearrange description of capabilities
This also remove some duplication in the descriptions (e.g. refspec was explained twice with similar level of detail). Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 134 +++ 1 file changed, 56 insertions(+), 78 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 7eb43d7..7ac1461 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -88,81 +88,17 @@ Each remote helper is expected to support only a subset of commands. The operations a helper supports are declared to git in the response to the `capabilities` command (see COMMANDS, below). -'option':: - For specifying settings like `verbosity` (how much output to - write to stderr) and `depth` (how much history is wanted in the - case of a shallow clone) that affect how other commands are - carried out. - -'connect':: - For fetching and pushing using git's native packfile protocol - that requires a bidirectional, full-duplex connection. - -'push':: - For listing remote refs and pushing specified objects from the - local object store to remote refs. - -'fetch':: - For listing remote refs and fetching the associated history to - the local object store. - -'export':: - For listing remote refs and pushing specified objects from a - fast-import stream to remote refs. - -'import':: - For listing remote refs and fetching the associated history as - a fast-import stream. - -'refspec' refspec:: - This modifies the 'import' capability, allowing the produced - fast-import stream to modify refs in a private namespace - instead of writing to refs/heads or refs/remotes directly. - It is recommended that all importers providing the 'import' - capability use this. -+ -A helper advertising the capability -`refspec refs/heads/*:refs/svn/origin/branches/*` -is saying that, when it is asked to `import refs/heads/topic`, the -stream it outputs will update the `refs/svn/origin/branches/topic` -ref. -+ -This capability can be advertised multiple times. The first -applicable refspec takes precedence. The left-hand of refspecs -advertised with this capability must cover all refs reported by -the list command. If no 'refspec' capability is advertised, -there is an implied `refspec *:*`. - -'bidi-import':: - The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers - to retrieve information about blobs and trees that already exist in - fast-import's memory. This requires a channel from fast-import to the - remote-helper. - If it is advertised in addition to import, git establishes a pipe from - fast-import to the remote-helper's stdin. - It follows that git and fast-import are both connected to the - remote-helper's stdin. Because git can send multiple commands to - the remote-helper it is required that helpers that use 'bidi-import' - buffer all 'import' commands of a batch before sending data to fast-import. - This is to prevent mixing commands and fast-import responses on the - helper's stdin. - -'export-marks' file:: - This modifies the 'export' capability, instructing git to dump the - internal marks table to file when complete. For details, - read up on '--export-marks=file' in linkgit:git-fast-export[1]. - -'import-marks' file:: - This modifies the 'export' capability, instructing git to load the - marks specified in file before processing any input. For details, - read up on '--import-marks=file' in linkgit:git-fast-export[1]. +In the following, we list all defined capabilities and for +each we list which commands a helper with that capability +must provide. Capabilities for Pushing - + 'connect':: Can attempt to connect to 'git receive-pack' (for pushing), - 'git upload-pack', etc for communication using the - packfile protocol. + 'git upload-pack', etc for communication using + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. + Supported commands: 'connect'. @@ -186,11 +122,12 @@ Other frontends may have some other order of preference. Capabilities for Fetching -~ +^ 'connect':: Can try to connect to 'git upload-pack' (for fetching), 'git receive-pack', etc for communication using the - packfile protocol. + git's native packfile protocol. This + requires a bidirectional, full-duplex connection. + Supported commands: 'connect'. @@ -212,14 +149,27 @@ connecting (see the 'connect' command under COMMANDS). When choosing between 'fetch' and 'import', git prefers 'fetch'. Other frontends may have some other order of preference. +Miscellaneous
[PATCH v2 3/6] git-remote-helpers.txt: minor grammar fix
Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index db63541..7eb43d7 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -235,9 +235,9 @@ Commands are given by the caller on the helper's standard input, one per line. 'capabilities':: Lists the capabilities of the helper, one per line, ending with a blank line. Each capability may be preceded with '*', - which marks them mandatory for git version using the remote - helper to understand (unknown mandatory capability is fatal - error). + which marks them mandatory for git versions using the remote + helper to understand. Any unknown mandatory capability is a + fatal error. 'list':: Lists the refs, one per line, in the format value name -- 1.8.0.393.gcc9701d -- 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 5/6] git-remote-helpers.txt: clarify command - capability correspondences
In particular, document 'list for-push' separately from 'list', as the former needs only be supported for the push/export capabilities, and the latter only for fetch/import. Indeed, a hypothetically 'push-only' helper would only need to support the former, not the latter. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 21 - 1 file changed, 16 insertions(+), 5 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 7ac1461..023dcca 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -216,6 +216,8 @@ Commands are given by the caller on the helper's standard input, one per line. which marks them mandatory for git versions using the remote helper to understand. Any unknown mandatory capability is a fatal error. ++ +Support for this command is mandatory. 'list':: Lists the refs, one per line, in the format value name @@ -225,9 +227,18 @@ Commands are given by the caller on the helper's standard input, one per line. the name; unrecognized attributes are ignored. The list ends with a blank line. + -If 'push' is supported this may be called as 'list for-push' -to obtain the current refs prior to sending one or more 'push' -commands to the helper. +Supported if the helper has the fetch or import capability. + +'list for-push':: + Similar to 'list', except that it is used if and only if + the caller wants to the resulting ref list to prepare + push commands. + A helper supporting both push and fetch can use this + to distinguish for which operation the output of 'list' + is going to be used, possibly reducing the amount + of work that needs to be performed. ++ +Supported if the helper has the push or export capability. 'option' name value:: Sets the transport helper option name to value. Outputs a @@ -306,7 +317,7 @@ sequence has to be buffered before starting to send data to fast-import to prevent mixing of commands and fast-import responses on the helper's stdin. + -Supported if the helper has the 'import' capability. +Supported if the helper has the import capability. 'export':: Instructs the remote helper that any subsequent input is @@ -322,7 +333,7 @@ fast-export', which then will load/store a table of marks for local objects. This can be used to implement for incremental operations. + -Supported if the helper has the 'export' capability. +Supported if the helper has the export capability. 'connect' service:: Connects to given service. Standard input and standard output -- 1.8.0.393.gcc9701d -- 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 0/6] Improve remote helper documentation
Various remote helper capabilities and commands were not documented, in particular 'export', or documented in a misleading way (e.g. 'for-push' was listed as a ref attribute understood by git, which is not the case). This patch series changes that, and also address some other things in the remote helper documentation that I found jarring when reading through it. Note that the description of export and (im|ex)port-marks probably can be improved, and I hope that somebody who knows more about them than me and/or is better at writing documentation will do just that. But I felt it was better to provide something than to do nothing and only complain, as I did previously on this subject ;-). Max Horn (6): git-remote-helpers.txt: document invocation before input format git-remote-helpers.txt: document missing capabilities git-remote-helpers.txt: minor grammar fix git-remote-helpers.txt: rearrange description of capabilities git-remote-helpers.txt: clarify command - capability correspondences git-remote-helpers.txt: clarify options ref list attributes Documentation/git-remote-helpers.txt | 245 --- 1 file changed, 140 insertions(+), 105 deletions(-) -- 1.8.0.393.gcc9701d -- 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: Millisecond precision in timestamps?
Junio C Hamano gits...@pobox.com: fsck_ident() in fsck.c rejects anything but [1-9][0-9]* after the author and committer ident (i.e. the timestamp has to be integral number of seconds since the epoch, not before it, nor with fractional seconds). Is this architecturally significant? It sounds like another implementation detail. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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 6/6] git-remote-helpers.txt: clarify ref list attributes, link to subsections
Ouch. This one should *not* have been sent (the [PATCH v2 6/6] one is the correct one). Very sorry :(. I'll triple check next time. Max On 28.11.2012, at 00:03, Max Horn wrote: The documentation was misleading in that it gave the impression that 'for-push' could be used as a ref attribute in the output of the 'list' command. That is wrong. Also, explicitly point out the connection between the commands 'list' and 'options' on the one hand, and the sections 'REF LIST ATTRIBUTES' and 'OPTIONS' on the other hand. Signed-off-by: Max Horn m...@quendi.de --- Documentation/git-remote-helpers.txt | 17 - 1 file changed, 12 insertions(+), 5 deletions(-) diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt index 023dcca..e1df01d 100644 --- a/Documentation/git-remote-helpers.txt +++ b/Documentation/git-remote-helpers.txt @@ -227,6 +227,8 @@ Support for this command is mandatory. the name; unrecognized attributes are ignored. The list ends with a blank line. + +See REF LIST ATTRIBUTES for a list of currently defined options. ++ Supported if the helper has the fetch or import capability. 'list for-push':: @@ -248,6 +250,8 @@ Supported if the helper has the push or export capability. for it). Options should be set before other commands, and may influence the behavior of those commands. + +See OPTIONS for a list of currently defined options. ++ Supported if the helper has the option capability. 'fetch' sha1 name:: @@ -256,7 +260,7 @@ Supported if the helper has the option capability. per line, terminated with a blank line. Outputs a single blank line when all fetch commands in the same batch are complete. Only objects which were reported - in the ref list with a sha1 may be fetched this way. + in the output of 'list' with a sha1 may be fetched this way. + Optionally may output a 'lock file' line indicating a file under GIT_DIR/objects/pack which is keeping a pack until refs can be @@ -360,10 +364,9 @@ capabilities reported by the helper. REF LIST ATTRIBUTES --- -'for-push':: - The caller wants to use the ref list to prepare push - commands. A helper might chose to acquire the ref list by - opening a different type of connection to the destination. +The 'list' command produces a list of refs in which each ref +may be followed by a list of attributes. The following ref list +attributes are defined. 'unchanged':: This ref is unchanged since the last import or fetch, although @@ -371,6 +374,10 @@ REF LIST ATTRIBUTES OPTIONS --- + +The following options are defined and (under suitable circumstances) +set by git if the remote helper has the 'option' capability. + 'option verbosity' n:: Changes the verbosity of messages displayed by the helper. A value of 0 for n means that processes operate -- 1.8.0.393.gcc9701d -- 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
Re: Possible vulnerability to SHA-1 collisions
On Sat, Nov 24, 2012 at 10:09:31AM -0800, Shawn O. Pearce wrote: On Sat, Nov 24, 2012 at 3:12 AM, Michael Hirshleifer 111...@caltech.edu wrote: Evil Guy creates 2 files, 1 evil and 1 innocuous, with the same SHA-1 checksum (including Git header). Mr. Evil creates a local branch with an innocuous name like “test-bugfix”, and adds a commit containing a reference to the evil file. Separately, using a sockpuppet, Evil Guy creates an innocuous bugfix (very likely to be accepted) containing the innocuous file, and submits it to Good Guy. Before Good Guy can commit the bugfix, Evil Guy pushes the evil branch to Github, and then immediately deletes it; or equivalently --force pushes any innocuous commit on top of it. (This is unlikely to arouse suspicion, and he can always say he deleted it because it didn’t work.) Here you assume Evil Guy has write access to the same repository as Good Guy. Lets assume this is possible, e.g. Evil Guy is actually impersonating White Hat because he managed to steal White Hat's credentials through a compromised host. Typically Evil Guy doesn't have write access to Good Guy's repository, and thus can't introduce objects into it without Good Guy being the one that creates the objects. But lets just keep he assumption that Evil Guy can write to the same repository as Good Guy, and that he managed to create the bad branch and delete it, leaving the bad object in an unreachable state for 2 weeks. Actually, it is somewhat easier on GitHub, because we share objects between forks of a repository via the alternates mechanism. So if you can publicly fork the project and push a branch to your fork, you can write to the shared object database. This applies not just to GitHub, but to any hosting service which shares object databases between projects (I do not know offhand if other hosting providers like Google Code do this). But as you noted later in your email, the byte-for-byte comparison on object collision will let us detect this case when the good guy tries to push and abort. -Peff PS I also think the OP's sockpuppet creates innocuous bugfix above is easier said than done. We do not have SHA-1 collisions yet, but if the md5 attacks are any indication, the innocuous file will not be completely clean; it will need to have some embedded binary goo that is mutated randomly during the collision process (which is why the md5 attacks were demonstrated with postscript files which _rendered_ to look good, but contained a chunk of random bytes in a spot ignored by the postscript interpreter). -- 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 3/3] Add option to transpose parents of merge commit
When the changes are pushed upstream, and in the meantime someone else
updated upstream branch git advises to use git pull. This results in
history:
---A---B---C--
\ /
D---E
where B is the local commit. D, E are commits pushed by someone else
when the developer was working on B. However sometimes the following
history is preferable:
---A---D---C'--
\ /
'-B-'
The difference between C and C' is the order of parents. This change
allow for easier way to obtain this effect by introducing the option
--transpose-parents to git-merge and git-pull, which changes the order
of parents in resulting commit moving the original first parent to
the very end of list of parents.
The transposition is done just before the commit is finalized, so the
meaning of our and their for conflict resolution is not changed, so
ours denotes local version and theirs upstream.
Signed-off-by: Kacper Kornet drae...@pld-linux.org
---
Documentation/merge-options.txt | 7 +++
builtin/commit.c| 8 +++-
builtin/merge.c | 16
commit.c| 11 +++
commit.h| 2 ++
git-pull.sh | 4 +++-
6 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 0bcbe0a..b4fbfdc 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -88,6 +88,13 @@ option can be used to override --squash.
Synonyms to --stat and --no-stat; these are deprecated and will be
removed in the future.
+--transpose-parents::
+ Transpose the parents in the final commit. The change is made
+ just before the commit so the meaning of 'our' and 'their'
+ concepts remains the same (i.e. 'our' means current branch before
+ the merge).
+
+
ifndef::git-pull[]
-q::
--quiet::
diff --git a/builtin/commit.c b/builtin/commit.c
index ee0e884..ab2b844 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1477,6 +1477,7 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
} else if (whence == FROM_MERGE) {
struct strbuf m = STRBUF_INIT;
FILE *fp;
+ int reversed_order=0;
if (!reflog_msg)
reflog_msg = commit (merge);
@@ -1484,10 +1485,13 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
while (strbuf_getline(m, fp, '\n') != EOF) {
if (!strcmp(m.buf, no-ff))
allow_fast_forward = 0;
+ if (!strcmp(m.buf, reversed-order))
+ reversed_order = 1;
}
fclose(fp);
}
- pptr = commit_list_insert(current_head, pptr)-next;
+ if (!reversed_order)
+ pptr = commit_list_insert(current_head, pptr)-next;
fp = fopen(git_path(MERGE_HEAD), r);
if (fp == NULL)
die_errno(_(could not open '%s' for reading),
@@ -1502,6 +1506,8 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
}
fclose(fp);
strbuf_release(m);
+ if (reversed_order)
+ pptr = commit_list_insert(current_head, pptr)-next;
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
diff --git a/builtin/merge.c b/builtin/merge.c
index a96e8ea..41738a5 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -65,6 +65,7 @@ static int abort_current_merge;
static int show_progress = -1;
static int default_to_upstream;
static const char *sign_commit;
+static int reversed_order=0;
static struct strategy all_strategy[] = {
{ recursive, DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -213,6 +214,7 @@ static struct option builtin_merge_options[] = {
{ OPTION_STRING, 'S', gpg-sign, sign_commit, N_(key id),
N_(GPG sign commit), PARSE_OPT_OPTARG, NULL, (intptr_t) },
OPT_BOOLEAN(0, overwrite-ignore, overwrite_ignore, N_(update
ignored files (default))),
+ OPT_BOOLEAN(0, transpose-parents, reversed_order, N_(reverse order
of parents)),
OPT_END()
};
@@ -822,9 +824,9 @@ static int merge_trivial(struct commit *head, struct
commit_list *remoteheads)
write_tree_trivial(result_tree);
printf(_(Wonderful.\n));
- parent-item = head;
+ parent-item = reversed_order ? remoteheads-item : head;
parent-next = xmalloc(sizeof(*parent-next));
- parent-next-item = remoteheads-item;
+ parent-next-item = reversed_order ? head : remoteheads-item;
parent-next-next = NULL;
prepare_to_commit(remoteheads);
if (commit_tree(merge_msg, result_tree,
[PATCH v2 1/3] Process MERGE_MODE before MERGE_HEAD
It is in preparation to introduce --transpose-parents option to
git-merge, when the content of MERGE_MODE will dictate how the
MERGE_HEAD is interpreted.
Signed-off-by: Kacper Kornet drae...@pld-linux.org
---
builtin/commit.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 1dd2ec5..273332f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1481,6 +1481,12 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
if (!reflog_msg)
reflog_msg = commit (merge);
+ if (!stat(git_path(MERGE_MODE), statbuf)) {
+ if (strbuf_read_file(sb, git_path(MERGE_MODE), 0)
0)
+ die_errno(_(could not read MERGE_MODE));
+ if (!strcmp(sb.buf, no-ff))
+ allow_fast_forward = 0;
+ }
pptr = commit_list_insert(current_head, pptr)-next;
fp = fopen(git_path(MERGE_HEAD), r);
if (fp == NULL)
@@ -1496,12 +1502,6 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
}
fclose(fp);
strbuf_release(m);
- if (!stat(git_path(MERGE_MODE), statbuf)) {
- if (strbuf_read_file(sb, git_path(MERGE_MODE), 0)
0)
- die_errno(_(could not read MERGE_MODE));
- if (!strcmp(sb.buf, no-ff))
- allow_fast_forward = 0;
- }
if (allow_fast_forward)
parents = reduce_heads(parents);
} else {
--
1.8.0.1
--
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 2/3] Allow for MERGE_MODE to specify more then one mode
Presently only one merge mode exists: non-fast-forward. But in future
the second one (transpose-parents) will be added, so the need to read
all lines of MERGE_MODE.
Signed-off-by: Kacper Kornet drae...@pld-linux.org
---
builtin/commit.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 273332f..ee0e884 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -1427,7 +1427,6 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
unsigned char sha1[20];
struct ref_lock *ref_lock;
struct commit_list *parents = NULL, **pptr = parents;
- struct stat statbuf;
int allow_fast_forward = 1;
struct commit *current_head = NULL;
struct commit_extra_header *extra = NULL;
@@ -1481,11 +1480,12 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
if (!reflog_msg)
reflog_msg = commit (merge);
- if (!stat(git_path(MERGE_MODE), statbuf)) {
- if (strbuf_read_file(sb, git_path(MERGE_MODE), 0)
0)
- die_errno(_(could not read MERGE_MODE));
- if (!strcmp(sb.buf, no-ff))
- allow_fast_forward = 0;
+ if((fp = fopen(git_path(MERGE_MODE), r))) {
+ while (strbuf_getline(m, fp, '\n') != EOF) {
+ if (!strcmp(m.buf, no-ff))
+ allow_fast_forward = 0;
+ }
+ fclose(fp);
}
pptr = commit_list_insert(current_head, pptr)-next;
fp = fopen(git_path(MERGE_HEAD), r);
--
1.8.0.1
--
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 0/3] Add option to change order of parents in merge commit
The second version of patches introducing option to change order of parents in merge commits. The changes in respect to the previous version: - I have divided the changes to the preparatory ones, which only refactore the code without introducing new functionality, and the commit which introduces the new option - The documentation for the new options has been added This is not yet a final version, as the tests are missing. But maybe while I'm working on them there will be some comments. Kacper Kornet (3): Process MERGE_MODE before MERGE_HEAD Allow for MERGE_MODE to specify more then one mode Add option to transpose parents of merge commit Documentation/merge-options.txt | 7 +++ builtin/commit.c| 22 ++ builtin/merge.c | 16 commit.c| 11 +++ commit.h| 2 ++ git-pull.sh | 4 +++- 6 files changed, 49 insertions(+), 13 deletions(-) -- 1.8.0.1 -- 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: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
Hi,
On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
The v4 series leaves the remote branch amigious, but it helps you
point the local branch at the right hash so that future calls to
$ git submodule foreach 'git pull'
can use the branch's .git/modules/name/config settings.
But IMO thats the functionality which should be implemented in submodule
update and not left to the user.
I would think more of some convention like:
$ git checkout -t origin/$branch
when first initialising the submodule with e.g.
$ git submodule update --init --branch
Then later calls of
$ git submodule update --branch
would have a branch configured to pull from. I imagine that results in
a similar behavior gerrit is doing on the server side?
That sounds like it's doing pretty much the same thing. Can you think
of a test that would distinguish it from my current v4 implementation?
Well the main difference is that gerrit is automatically updating the
superproject AFAIK. I would like it if we could implement the same
workflow support in the submodule script. It seems to me that this is
already proven to be useful workflow.
I do not have a test but a small draft diff (completely untested, quick and
dirty) to illustrate the approach I am talking about.
You can find the whole change at
https://github.com/hvoigt/git/commits/hv/floating_submodules_draft
and the interesting patch for easy commenting below[1].
How about reusing the -b|--branch option for add? Since we only change
the behavior when submodule.$name.update is set to branch it seems
reasonable to me. Opinions?
That was the approach I used in v1, but people were concerned that we
would be stomping on previously unclaimed config space. Since noone
has pointed out other uses besides Gerrit's very similar case, I'm not
sure if that is still an issue.
Could you point me to that mail? I cannot seem to find it in my archive.
Because you need to recurse through submodules for `update --branch`
even if $subsha1 == $sha1, I had to amend the conditional
controlling that block. This broke one of the existing tests, which I
fixed in patch 4. I think a proper fix would involve rewriting
(clear_local_git_env; cd $sm_path
( (rev=$(git rev-list -n 1 $sha1 --not --all 2/dev/null)
test -z $rev) || git-fetch)) ||
die $(eval_gettext Unable to fetch in submodule path '\$sm_path')
but I'm not familiar enough with rev-list to want to dig into that
yet. If feedback for the earlier three patches is positive, I'll work
up a clean fix and resubmit.
You probably need to separate your handling here. The comparison of the
currently checked out sha1 and the recorded sha1 is an optimization
which skips unnecessary fetching in case the submodules commits are
already correct. This code snippet checks whether the to be checked out
sha1 is already local and also skips the fetch if it is. We should not
break that.
Agreed. However, determining if the target $sha1 is local should have
nothing to do with the current checked out $subsha1.
See my draft or the diff below for an illustration of the splitup.
Cheers Heiko
[1]
diff --git a/git-submodule.sh b/git-submodule.sh
index 9ad4370..3fa1465 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -183,6 +183,7 @@ module_clone()
sm_path=$1
url=$2
reference=$3
+ branch=$4
quiet=
if test -n $GIT_QUIET
then
@@ -209,6 +210,8 @@ module_clone()
clear_local_git_env
git clone $quiet -n ${reference:+$reference} \
--separate-git-dir $gitdir $url $sm_path
+ test -n $branch (cd $sm_path
+ git checkout -t origin/$branch)
) ||
die $(eval_gettext Clone of '\$url' into submodule path
'\$sm_path' failed)
fi
@@ -361,7 +364,7 @@ Use -f if you really want to add it. 2
else
- module_clone $sm_path $realrepo $reference || exit
+ module_clone $sm_path $realrepo $reference
$local_branch || exit
(
clear_local_git_env
cd $sm_path
@@ -577,6 +580,12 @@ handle_on_demand_update () {
fi
}
+handle_tracking_branch_update () {
+ (clear_local_git_env; cd $sm_path
+ git-checkout $branch git-pull --ff-only) ||
+ die $(eval_gettext Unable to pull branch '\$branch' in submodule path
'\$sm_path')
+}
+
#
# Update each submodule path to correct revision, using clone and checkout as
needed
#
@@ -648,6 +657,7 @@ cmd_update()
cloned_modules=
module_list $@ | {
err=
+ floating_submodules=
while read mode sha1 stage sm_path
do
die_if_unmatched $mode
Re: [PATCH v3 0/7] New remote-bzr remote helper
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. 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: Millisecond precision in timestamps?
On Tue, Nov 27, 2012 at 3:04 PM, Eric S. Raymond e...@thyrsus.com wrote: Junio C Hamano gits...@pobox.com: fsck_ident() in fsck.c rejects anything but [1-9][0-9]* after the author and committer ident (i.e. the timestamp has to be integral number of seconds since the epoch, not before it, nor with fractional seconds). Is this architecturally significant? It sounds like another implementation detail. Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. -- 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-push.txt: clarify the push from satellite workflow
The context of the example to push into refs/remotes/satellite/ hierarchy of the other repository needs to be spelled out explicitly for the value of this example to be fully appreciated. Make it so. Signed-off-by: Junio C Hamano gits...@pobox.com --- Brandon Casey bca...@nvidia.com writes: So refs are correct. The context is not sufficiently explained. Ah, I see. Yeah, I think that is complex enough to merit an extended explanation. Something like this? Documentation/git-push.txt | 16 ++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git c/Documentation/git-push.txt w/Documentation/git-push.txt index 6d19d59..8b637d3 100644 --- c/Documentation/git-push.txt +++ w/Documentation/git-push.txt @@ -385,11 +385,23 @@ the ones in the examples below) can be configured as the default for A handy way to push the current branch to the same name on the remote. -`git push origin master:satellite/master dev:satellite/dev`:: +`git push mothership master:satellite/master dev:satellite/dev`:: Use the source ref that matches `master` (e.g. `refs/heads/master`) to update the ref that matches `satellite/master` (most probably - `refs/remotes/satellite/master`) in the `origin` repository, then + `refs/remotes/satellite/master`) in the `mothership` repository; do the same for `dev` and `satellite/dev`. ++ +This is to emulate `git fetch` run on the `mothership` using `git +push` that is run in the opposite direction in order to integrate +the work done on `satellite`, and is often necessary when you can +only make connection in one way (i.e. satellite can ssh into +mothership but mothership cannot initiate connection to satellite +because the latter is behind a firewall or does not run sshd). ++ +After running this `git push` on the `satellite` machine, you would +ssh into the `mothership` and run `git merge` there to complete the +emulation of `git pull` that were run on `mothership` to pull changes +made on `satellite`. `git push origin HEAD:master`:: Push the current branch to the remote ref matching `master` in the -- 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: Millisecond precision in timestamps?
Shawn Pearce spea...@spearce.org: Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. So much for that idea, I guess. Unless..I don't know how git's database representations work. Are they version-stamped in any way? If so, some slightly painful hackery would get around that problem. I'm being exploratory, here. No proposal to code anything is in the offing. -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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: Why is this known by git but not by gitk
On Tue, Nov 27, 2012 at 6:50 PM, Kevin O'Gorman kogor...@gmail.com wrote: I just converted a SourceForge CVS repo to git using cvs2svn. One directory in the result is named CVSROOT and everything would be fine, but I wan to know why gitk does not see it. Git itself does not report it either, but it lets me git rm -r CVSROOT and stages the change. I just want to know what's up with this before I commit myself to using this converted repo. Is it present in the .gitignore file? -- 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 v3 0/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. I was waiting on both to be merged, let me see what I have pending and would be nice to have before the merge. -- 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: Millisecond precision in timestamps?
On Tue, 27 Nov 2012, Eric S. Raymond wrote: Shawn Pearce spea...@spearce.org: Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. So much for that idea, I guess. Unless..I don't know how git's database representations work. Are they version-stamped in any way? If so, some slightly painful hackery would get around that problem. I'm being exploratory, here. No proposal to code anything is in the offing. Apologies if this was covered earlier in the thread (I missed the beginning) remember that git is dealing with timestamps generated across different machines, and since the times are not assumed to be in sync, let alone to the millisecond level, there's not much value to git in that level of presision. git routinely deals with timestamps that are off by days. If the timestamps are within a minute or so, you are in pretty good shape. David Lang -- 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: Millisecond precision in timestamps?
On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond e...@thyrsus.com wrote: Shawn Pearce spea...@spearce.org: Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. So much for that idea, I guess. Unless..I don't know how git's database representations work. Are they version-stamped in any way? If so, some slightly painful hackery would get around that problem. % git cat-file -p HEAD You'll see exactly how git stores commits. Changing anything in there must be done carefully. -- 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 v3 0/7] New remote-bzr remote helper
On Wed, Nov 28, 2012 at 12:32 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Nov 26, 2012 at 5:09 AM, Junio C Hamano gits...@pobox.com wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Sun, Nov 11, 2012 at 3:19 PM, Felipe Contreras felipe.contre...@gmail.com wrote: This is a re-roll of the previous series to add support to fetch and push special modes, and refactor some related code. It seems this one got forgotten, I only see v2 in pu. Oops; I think that was fell through the cracks during the maintainer hand-off. As the previous one has already been cooking in 'next' for a week or so, I would appreciate if you send incremental updates to fix or enhance what is in there. Yes, that's what I have planned for the next patches, as I already did for remote-hg, but the changes in remote-bzr were a bit bigger. OK. Both fc/remote-hg and fc/remote-bzr are slated for 'master' soonish, but I take the above to mean that fc/remote-hg is ready while it is better to wait for updates to fc/remote-bzr before merging it. Please update remote-bzr to series version 3. The rest of the patches will be on top of that version. -- 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: Python extension commands in git - request for policy change
On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote: While constant traffic probably overstates the issue, these are not theoretical problems. I recall at least three cases in the last year or so where Git has seen breakage with Solaris or Mac OS X because of sed or tr incompatibilities, and I don't even read this list that thoroughly. Most of the *constant* traffic is about *theoretical* incompatibilities, how much of that are real incompatibilities, it's not known. _Some_ of the traffic is about real incompatibilities, sure, but you could count only three cases *in a year*. It's not a huge amount. And then, how man this year? Also, I would like references to those incompatibilities. Try: git log --grep='portab' -- '*.sh' Not all of the hits are shell portability fixes, but most of them are, and they are all in response to real, reported issues. The usual culprits are Solaris, BSD (including OS X), and the occasional GNUism. And that is only the ones that we fixed in response to bug reports for commits in the wild. Many more have been caught in review before needing a separate patch (grepping the list archive for 'portable' and '\.sh' yields 1800 messages). So dealing with shell portability is definitely something we do, and it is a minor pain. But like you, I think we have been getting along reasonably well with shell scripts (and where it is not powerful enough, writing C). No solution is going to be free of portability issues (whether because of differing versions, because the tool is uncommon on certain platforms, or whatever). And because git-core's official API is shell-executable commands, any other language you write ends up looking a lot like shell anyway. If people are really hankering to write sub-commands of git in python (or whatever), I would suggest checking out libgit2 which has a nice set of python bindings (and ruby bindings, and C# bindings, and so on). It doesn't have feature parity with git-core yet, but they have been making a lot of progress. -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 0/4] remote-helpers: general fixes
Hi, These are general fixes, some for old versions of bazaar, mercurial, and python. Some of these have already been sent, but here they go alone so they are not missed. The bazaar fixes are on top of the series v3 which is still not in 'pu'. Felipe Contreras (4): remote-hg: fix for files with spaces remote-hg: fix for older versions of python remote-bzr: add support for older versions of bzr remote-bzr: detect local repositories contrib/remote-helpers/git-remote-bzr | 54 +-- contrib/remote-helpers/git-remote-hg | 14 + 2 files changed, 42 insertions(+), 26 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] remote-bzr: add support for older versions of bzr
At least as old as 2.0.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index f8919f4..6cdfac6 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -17,7 +17,8 @@
import sys
import bzrlib
-bzrlib.initialize()
+if hasattr(bzrlib, initialize):
+bzrlib.initialize()
import bzrlib.plugin
bzrlib.plugin.load_plugins()
@@ -553,7 +554,7 @@ def parse_commit(parser):
repo.lock_write()
try:
-builder = repo.get_commit_builder(parents, None, date, tz, committer,
props, revid, False)
+builder = repo.get_commit_builder(parents, None, date, tz, committer,
props, revid)
try:
list(builder.record_iter_changes(mtree, mtree.last_revision(),
changes))
builder.finish_inventory()
@@ -612,7 +613,10 @@ def do_export(parser):
if ref == 'refs/heads/master':
repo.generate_revision_history(revid, marks.get_tip('master'))
revno, revid = repo.last_revision_info()
-peer.import_last_revision_info_and_tags(repo, revno, revid)
+if hasattr(peer, import_last_revision_info_and_tags):
+peer.import_last_revision_info_and_tags(repo, revno, revid)
+else:
+peer.import_last_revision_info(repo.repository, revno, revid)
wt = peer.bzrdir.open_workingtree()
wt.update()
print ok %s % ref
@@ -646,12 +650,12 @@ def get_repo(url, alias):
global dirname, peer
clone_path = os.path.join(dirname, 'clone')
-origin = bzrlib.controldir.ControlDir.open(url)
+origin = bzrlib.bzrdir.BzrDir.open(url)
remote_branch = origin.open_branch()
if os.path.exists(clone_path):
# pull
-d = bzrlib.controldir.ControlDir.open(clone_path)
+d = bzrlib.bzrdir.BzrDir.open(clone_path)
branch = d.open_branch()
result = branch.pull(remote_branch, [], None, False)
else:
--
1.8.0
--
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 4/4] remote-bzr: detect local repositories
So we don't create a clone unnecessarily.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 48 ---
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 6cdfac6..c5822e4 100755
--- a/contrib/remote-helpers/git-remote-bzr
+++ b/contrib/remote-helpers/git-remote-bzr
@@ -24,6 +24,7 @@ import bzrlib.plugin
bzrlib.plugin.load_plugins()
import bzrlib.generate_ids
+import bzrlib.transport
import sys
import os
@@ -613,11 +614,14 @@ def do_export(parser):
if ref == 'refs/heads/master':
repo.generate_revision_history(revid, marks.get_tip('master'))
revno, revid = repo.last_revision_info()
-if hasattr(peer, import_last_revision_info_and_tags):
-peer.import_last_revision_info_and_tags(repo, revno, revid)
+if peer:
+if hasattr(peer, import_last_revision_info_and_tags):
+peer.import_last_revision_info_and_tags(repo, revno, revid)
+else:
+peer.import_last_revision_info(repo.repository, revno,
revid)
+wt = peer.bzrdir.open_workingtree()
else:
-peer.import_last_revision_info(repo.repository, revno, revid)
-wt = peer.bzrdir.open_workingtree()
+wt = repo.bzrdir.open_workingtree()
wt.update()
print ok %s % ref
print
@@ -649,24 +653,28 @@ def do_list(parser):
def get_repo(url, alias):
global dirname, peer
-clone_path = os.path.join(dirname, 'clone')
origin = bzrlib.bzrdir.BzrDir.open(url)
-remote_branch = origin.open_branch()
-
-if os.path.exists(clone_path):
-# pull
-d = bzrlib.bzrdir.BzrDir.open(clone_path)
-branch = d.open_branch()
-result = branch.pull(remote_branch, [], None, False)
+branch = origin.open_branch()
+
+if not isinstance(origin.transport, bzrlib.transport.local.LocalTransport):
+clone_path = os.path.join(dirname, 'clone')
+remote_branch = branch
+if os.path.exists(clone_path):
+# pull
+d = bzrlib.bzrdir.BzrDir.open(clone_path)
+branch = d.open_branch()
+result = branch.pull(remote_branch, [], None, False)
+else:
+# clone
+d = origin.sprout(clone_path, None,
+hardlink=True, create_tree_if_local=False,
+source_branch=remote_branch)
+branch = d.open_branch()
+branch.bind(remote_branch)
+
+peer = remote_branch
else:
-# clone
-d = origin.sprout(clone_path, None,
-hardlink=True, create_tree_if_local=False,
-source_branch=remote_branch)
-branch = d.open_branch()
-branch.bind(remote_branch)
-
-peer = remote_branch
+peer = None
return branch
--
1.8.0
--
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: Millisecond precision in timestamps?
On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond e...@thyrsus.com wrote: Shawn Pearce spea...@spearce.org: Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. So much for that idea, I guess. Unless..I don't know how git's database representations work. Are they version-stamped in any way? If so, some slightly painful hackery would get around that problem. % git cat-file -p HEAD You'll see exactly how git stores commits. Changing anything in there must be done carefully. Apparently there is no room to change in these fields without breaking compatibility with all current versions of Git. So its not just done carefully... its deciding to make Git 2.0 that is not compatible with any Git 1.x release. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Millisecond precision in timestamps?
Felipe Contreras felipe.contre...@gmail.com: % git cat-file -p HEAD You'll see exactly how git stores commits. Changing anything in there must be done carefully. Oh, I've seen *that* before. Are you telling me the database representation is actually textual? -- a href=http://www.catb.org/~esr/;Eric S. Raymond/a -- 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: Millisecond precision in timestamps?
On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote: On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond e...@thyrsus.com wrote: Shawn Pearce spea...@spearce.org: Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. So much for that idea, I guess. Unless..I don't know how git's database representations work. Are they version-stamped in any way? If so, some slightly painful hackery would get around that problem. % git cat-file -p HEAD You'll see exactly how git stores commits. Changing anything in there must be done carefully. Apparently there is no room to change in these fields without breaking compatibility with all current versions of Git. So its not just done carefully... its deciding to make Git 2.0 that is not compatible with any Git 1.x release. There is room for new headers, and older versions of git will ignore them. You could add a new committer-timestamp field that elaborates on the timestamp included on the committer line. Newer versions of git would respect it, and older versions would fall back to using the committer timestamp. But I really wonder if anybody actually cares about adding sub-second timestamp support, or if it is merely because SVN has it. -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: Python extension commands in git - request for policy change
On Wed, Nov 28, 2012 at 1:51 AM, Jeff King p...@peff.net wrote:
On Wed, Nov 28, 2012 at 01:10:34AM +0100, Felipe Contreras wrote:
While constant traffic probably overstates the issue, these are not
theoretical problems. I recall at least three cases in the last year
or so where Git has seen breakage with Solaris or Mac OS X because
of sed or tr incompatibilities, and I don't even read this list that
thoroughly.
Most of the *constant* traffic is about *theoretical*
incompatibilities, how much of that are real incompatibilities, it's
not known. _Some_ of the traffic is about real incompatibilities,
sure, but you could count only three cases *in a year*. It's not a
huge amount. And then, how man this year?
Also, I would like references to those incompatibilities.
Try:
git log --grep='portab' -- '*.sh'
% git log --oneline --grep='portab' --since='2 years ago' --no-merges -- '*.sh'
6eafa6d submodules: don't stumble over symbolic links when cloning recursively
Somebody mentioned 'portable', but no problem was hit.
2718781 t9400: fix gnuism in grep
It's a test, and nobody was hit by any problem.
0dbe659 t5704: fix nonportable sed/grep usages
Apparently there was an issue, but this is a test.
93d5e0c t7810: avoid unportable use of echo
A problem, but in tests.
482ce70 tests: avoid nonportable {foo,bar} glob
Again, tests.
77e5726 t0050: fix printf format strings for portability
Tests.
So, this search didn't throw a single issue that affected users in two
years. Moving git sub-commands to python wouldn't change a thing.
Maybe shell wasn't the right language for the test system, but I don't
see anybody proposing it to be changed.
Not all of the hits are shell portability fixes, but most of them are,
and they are all in response to real, reported issues. The usual
culprits are Solaris, BSD (including OS X), and the occasional GNUism.
And that is only the ones that we fixed in response to bug reports for
commits in the wild. Many more have been caught in review before needing
a separate patch (grepping the list archive for 'portable' and '\.sh'
yields 1800 messages).
So dealing with shell portability is definitely something we do, and it
is a minor pain.
First you have to separate the issues with the test system, because
that's not going to be changed. And then you have to separate the
*potential* issues and the *real* ones. You can spend all your time
doing shell portability, but does that mean that you actually have a
problem? Maybe if you hadn't done anything, nobody would have noticed
there was a problem.
Sure, you will argue that we don't see the *real* issues, because they
were fixed preemptively, but the fact of the matter is that we will
never know. All we know is the reality we can observe, and the reality
is that we hit very few *real* issues outside the test system (feel
free to provide evidence to the contrary).
But like you, I think we have been getting along reasonably well with
shell scripts (and where it is not powerful enough, writing C). No
solution is going to be free of portability issues (whether because of
differing versions, because the tool is uncommon on certain platforms,
or whatever). And because git-core's official API is shell-executable
commands, any other language you write ends up looking a lot like shell
anyway.
Agreed.
Cheers.
--
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: Millisecond precision in timestamps?
-Original Message- From: Jeff King Sent: Tuesday, November 27, 2012 20:18 On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote: On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond e...@thyrsus.com wrote: Shawn Pearce spea...@spearce.org: Well... if we added a fractional seconds to a commit, older versions of Git will scream loudly and refuse to work with the new commit. That would create a fork of Git. So much for that idea, I guess. Unless..I don't know how git's database representations work. Are they version-stamped in any way? If so, some slightly painful hackery would get around that problem. % git cat-file -p HEAD You'll see exactly how git stores commits. Changing anything in there must be done carefully. Apparently there is no room to change in these fields without breaking compatibility with all current versions of Git. So its not just done carefully... its deciding to make Git 2.0 that is not compatible with any Git 1.x release. There is room for new headers, and older versions of git will ignore them. You could add a new committer-timestamp field that elaborates on the timestamp included on the committer line. Newer versions of git would respect it, and older versions would fall back to using the committer timestamp. Suggestion add a ms offset field. Ex: jpyeron@black /projects/git/git $ git cat-file -p HEAD tree 1e24acfbfcc05aa57e8cb2cfe3ffe01cb100961d parent e98fa647aa5673cc95b6e9be1fdc13c0afa2cb37 author Junio C Hamano gits...@pobox.com 1350495361 -0700 committer Junio C Hamano gits...@pobox.com 1350495402 -0700 mstimestamps author 0 committer 1234 Git 1.7.12.4 Signed-off-by: Junio C Hamano gits...@pobox.com But I really wonder if anybody actually cares about adding sub-second timestamp support, or if it is merely because SVN has it. Not because subversion has it but because date != git(precisedate) and some automation using git in a larger enterprise workflow may assume that date 1354065991.1234 going in should be the same when queried. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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] Support for git aliasing for tcsh completion
On Tue, Nov 27, 2012 at 12:16 PM, Junio C Hamano gits...@pobox.com wrote: The patch was linewrapped so I had to fix it up; Sorry about that. I don't know if it is gmail, or the fact that I use its web interface that causes these problems. please double check what will be queued on 'pu' to make sure that I did not miss necessary whitespaces or added unnecessary ones when I rejoined long lines. I just checked it and it looks great. I'm working on another improvement to the script but I don't have it working yet. But I should not bother you much after that. Thanks again! Marc -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Python extension commands in git - request for policy change
On Wed, Nov 28, 2012 at 02:22:09AM +0100, Felipe Contreras wrote: Sure, you will argue that we don't see the *real* issues, because they were fixed preemptively, but the fact of the matter is that we will never know. All we know is the reality we can observe, and the reality is that we hit very few *real* issues outside the test system (feel free to provide evidence to the contrary). I think reports of breakage in the test scripts are relevant, because they are indicative that people _do_ run platforms that care about these issues, and if we were to write a lot of shell scripts, we would run across them more frequently. But the fact of the matter is that we don't write a lot of non-test shell scripts these days, which is part of the reason limiting your search to the last 2 years did not turn up many fixes outside the tests. There was a big push in 2006 and 2007 to port some of the hairier scripts to C. Try: git log --no-renames --diff-filter=D \ --diff-filter=D --format='%ad %s' --date=short \ -- 'git-*.sh' A lot of it was motivated by portability and decent performance for common commands under Windows. Anyway, there is not much point in debating the exact level of pain that shell portability causes us. Even if you accept that there is some, it is clearly not a major problem for the project. -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 v6 p2 3/9] transport-helper: trivial code shuffle
Felipe Contreras felipe.contre...@gmail.com writes: This is not just just shuffle the die to make it explicit but it does change the semantics; earlier ref-deletion was perfectly fine as long as data-refspecs is not given, but the new code always dies. If this semantic change is a good thing, please explain why it is so in the log message. If the change is it does not matter because when data-refspecs is not given and ref-deletion is set, we die later elsewhere in the code anyway, then it needs to be described. refspecs are optional, but when they are not present the code doesn't work at all. This patch changes the behavior that was totally broken anyway. In case it was not clear, I did not request/expect responses in the discussion thread, but a rerolled series with updated description. 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
