* Unneeded branch history
From: Luca Siciliano Viglieri @ 2008-12-10 11:13 UTC (permalink / raw)
To: git
Hi,
i have tried to find a solution to my problem, but i couldn't find
anything on the documentation.
I have created from master branch a development branch. I keep the master
branch regularly uptodate from the server and in the development branch i
commit my code. When i merge the two branches i obtain a commit with two
parents and when i push my master branch to the server, all my development
history it is also saved in the server.
Can i avoid saving my develoment history, at least on the server, so that
the master branch has only one parent commits?
Thanks
Luca Siciliano
^ permalink raw reply
* Re: Unneeded branch history
From: Santi Béjar @ 2008-12-10 12:43 UTC (permalink / raw)
To: Luca Siciliano Viglieri; +Cc: git
In-Reply-To: <50628.127.0.0.1.1228907607.squirrel@localhost>
2008/12/10 Luca Siciliano Viglieri <Luca.Siciliano@bittwister.com>:
> Hi,
> i have tried to find a solution to my problem, but i couldn't find
> anything on the documentation.
> I have created from master branch a development branch. I keep the master
> branch regularly uptodate from the server and in the development branch i
> commit my code. When i merge the two branches i obtain a commit with two
> parents and when i push my master branch to the server, all my development
> history it is also saved in the server.
> Can i avoid saving my develoment history, at least on the server, so that
> the master branch has only one parent commits?
$ git merge --squash
or
$ git rebase -i master
and squash/edit/... some of the revisions (this way you can have the
interesting development history)
HTH,
Santi
^ permalink raw reply
* Re: [PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()
From: Jakub Narebski @ 2008-12-10 13:39 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Luben Tuikov
In-Reply-To: <20081210124901.6117@nanako3.lavabit.com>
On Wed, 10 Dec 2008, Nanako Shiraishi wrote:
> Quoting Jakub Narebski <jnareb@gmail.com>:
>
> > Unfortunately the implementation in 244a70e used one call for
> > git-rev-parse to find parent revision per line in file, instead of
> > using long lived "git cat-file --batch-check" (which might not existed
> > then), or changing validate_refname to validate_revision and made it
> > accept <rev>^, <rev>^^, <rev>^^^ etc. syntax.
>
> Could you substantiate why this is "Unfortunate"?
Because it calls git-rev-parse once for _each line_, even if for lines
in the group of neighbour lines blamed by same commit $parent_commit
is the same, and even if you need to calculate $parent_commit only once
per unique individual commit present in blame output.
> Is the new implementation faster? By how much?
File | L[1] | C[2] || Time0[3] | Before[4] | After[4]
====================================================================
blob.h | 18 | 4 || 0m1.727s | 0m2.545s | 0m2.474s
GIT-VERSION-GEN | 42 | 13 || 0m2.165s | 0m2.448s | 0m2.071s
README | 46 | 6 || 0m1.593s | 0m2.727s | 0m2.242s
revision.c | 1923 | 121 || 0m2.357s | 0m30.365s | 0m7.028s
gitweb/gitweb.perl | 6291 | 428 || 0m8.080s | 1m37.244s | 0m20.627s
File | L/C | Before/After
=========================================
blob.h | 4.5 | 1.03
GIT-VERSION-GEN | 3.2 | 1.18
README | 7.7 | 1.22
revision.c | 15.9 | 4.32
gitweb/gitweb.perl | 14.7 | 4.71
As you can see the greater ratio of lines in file to unique commits
in blame output, the greater gain from the new implementation.
Footnotes:
~~~~~~~~~~
[1] Lines:
$ wc -l <file>
[2] Individual commits in blame output:
$ git blame -p <file> | grep author-time | wc -l
[3] Time for running "git blame -p" (user time, single run):
$ time git blame -p <file> >/dev/null
[4] Time to run gitweb as Perl script from command line:
$ gitweb-run.sh "p=git.git;a=blame;f=<file>" > /dev/null 2>&1
Appendix A:
~~~~~~~~~~~
#!/bin/bash
export GATEWAY_INTERFACE="CGI/1.1"
export HTTP_ACCEPT="*/*"
export REQUEST_METHOD="GET"
export QUERY_STRING=""$1""
export PATH_INFO=""$2""
export GITWEB_CONFIG="/home/jnareb/git/gitweb/gitweb_config.perl"
perl -- /home/jnareb/git/gitweb/gitweb.perl
# end of gitweb-run.sh
> When "previous" commit information is available in the output from
> "git blame", can you make use of it?
Yes, I could; but I don't think it got implemented.
--
Jakub Narebski
Poland
^ permalink raw reply
* builtin-add.c patch
From: daly @ 2008-12-10 12:38 UTC (permalink / raw)
To: git; +Cc: daly
A trivial patch to fix a typo -- Tim Daly
diff --git a/builtin-add.c b/builtin-add.c
index ea4e771..5f2e68b 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -23,7 +23,7 @@ static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
int num_unmatched = 0, i;
/*
- * Since we are walking the index as if we are warlking the directory,
+ * Since we are walking the index as if we are walking the directory,
* we have to mark the matched pathspec as seen; otherwise we will
* mistakenly think that the user gave a pathspec that did not match
* anything.
^ permalink raw reply related
* Annotating patches inside diff
From: Jakub Narebski @ 2008-12-10 13:45 UTC (permalink / raw)
To: git
I remember that long time ago on git mailing list there was discussed
extending git-apply and friends (including git-am), to be able to
ignore lines in patches with selected special prefix, different from
'@' for chunks headers, ' ' for context, '+'/'-' for added/deleted
lines. IIRC it was chose '|' for this purpose.
This way you could annotate patch
@@ -4667,7 +4667,6 @@ HTML
hash_base => $parent_commit);
print "<td class=\"linenr\">";
print $cgi->a({ -href => "$blamed#l$orig_lineno",
| moved to <tr>
- -id => "l$lineno",
-class => "linenr" },
esc_html($lineno));
print "</td>";
Was it accepted or dropped, or is this feature present but not
documented?
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] Update Hungarian translation for 0.12
From: Miklos Vajna @ 2008-12-10 14:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081208163628.GG31551@spearce.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
po/hu.po | 186 ++++++++++++++++++++++++++++++++------------------------------
1 files changed, 96 insertions(+), 90 deletions(-)
diff --git a/po/hu.po b/po/hu.po
index 8ec4339..f761b64 100644
--- a/po/hu.po
+++ b/po/hu.po
@@ -7,8 +7,8 @@ msgid ""
msgstr ""
"Project-Id-Version: git-gui-i 18n\n"
"Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2008-11-16 13:56-0800\n"
-"PO-Revision-Date: 2008-11-17 23:03+0100\n"
+"POT-Creation-Date: 2008-12-08 08:31-0800\n"
+"PO-Revision-Date: 2008-12-10 15:00+0100\n"
"Last-Translator: Miklos Vajna <vmiklos@frugalware.org>\n"
"Language-Team: Hungarian\n"
"MIME-Version: 1.0\n"
@@ -241,25 +241,25 @@ msgstr "VisszavonĂĄs"
msgid "Redo"
msgstr "MĂŠgis"
-#: git-gui.sh:2378 git-gui.sh:2923
+#: git-gui.sh:2378 git-gui.sh:2937
msgid "Cut"
msgstr "KivĂĄgĂĄs"
-#: git-gui.sh:2381 git-gui.sh:2926 git-gui.sh:3000 git-gui.sh:3082
+#: git-gui.sh:2381 git-gui.sh:2940 git-gui.sh:3014 git-gui.sh:3096
#: lib/console.tcl:69
msgid "Copy"
msgstr "MĂĄsolĂĄs"
-#: git-gui.sh:2384 git-gui.sh:2929
+#: git-gui.sh:2384 git-gui.sh:2943
msgid "Paste"
msgstr "BeillesztĂŠs"
-#: git-gui.sh:2387 git-gui.sh:2932 lib/branch_delete.tcl:26
+#: git-gui.sh:2387 git-gui.sh:2946 lib/branch_delete.tcl:26
#: lib/remote_branch_delete.tcl:38
msgid "Delete"
msgstr "TĂśrlĂŠs"
-#: git-gui.sh:2391 git-gui.sh:2936 git-gui.sh:3086 lib/console.tcl:71
+#: git-gui.sh:2391 git-gui.sh:2950 git-gui.sh:3100 lib/console.tcl:71
msgid "Select All"
msgstr "Mindent kivĂĄlaszt"
@@ -291,15 +291,15 @@ msgstr "KĂŠsz"
msgid "Commit@@verb"
msgstr "Commit@@ige"
-#: git-gui.sh:2443 git-gui.sh:2864
+#: git-gui.sh:2443 git-gui.sh:2878
msgid "New Commit"
msgstr "Ăšj commit"
-#: git-gui.sh:2451 git-gui.sh:2871
+#: git-gui.sh:2451 git-gui.sh:2885
msgid "Amend Last Commit"
msgstr "UtolsĂł commit javĂtĂĄsa"
-#: git-gui.sh:2461 git-gui.sh:2825 lib/remote_branch_delete.tcl:99
+#: git-gui.sh:2461 git-gui.sh:2839 lib/remote_branch_delete.tcl:99
msgid "Rescan"
msgstr "KeresĂŠs Ăşjra"
@@ -319,15 +319,15 @@ msgstr "Commitba valĂł kivĂĄlasztĂĄs visszavonĂĄsa"
msgid "Revert Changes"
msgstr "VĂĄltoztatĂĄsok visszaĂĄllĂtĂĄsa"
-#: git-gui.sh:2491 git-gui.sh:3069
+#: git-gui.sh:2491 git-gui.sh:3083
msgid "Show Less Context"
msgstr "Kevesebb kĂśrnyezet mutatĂĄsa"
-#: git-gui.sh:2495 git-gui.sh:3073
+#: git-gui.sh:2495 git-gui.sh:3087
msgid "Show More Context"
msgstr "TĂśbb kĂśrnyezet mutatĂĄsa"
-#: git-gui.sh:2502 git-gui.sh:2838 git-gui.sh:2947
+#: git-gui.sh:2502 git-gui.sh:2852 git-gui.sh:2961
msgid "Sign Off"
msgstr "AlĂĄĂr"
@@ -361,7 +361,7 @@ msgstr "NĂŠvjegy: %s"
msgid "Preferences..."
msgstr "BeĂĄllĂtĂĄsok..."
-#: git-gui.sh:2565 git-gui.sh:3115
+#: git-gui.sh:2565 git-gui.sh:3129
msgid "Options..."
msgstr "OpciĂłk..."
@@ -381,125 +381,125 @@ msgstr "Online dokumentĂĄciĂł"
msgid "Show SSH Key"
msgstr "SSH kulcs mutatĂĄsa"
-#: git-gui.sh:2707
+#: git-gui.sh:2721
#, tcl-format
msgid "fatal: cannot stat path %s: No such file or directory"
msgstr ""
"vÊgzetes hiba: nem Êrhető el a(z) %s útvonal: Nincs ilyen fåjl vagy kÜnyvtår"
-#: git-gui.sh:2740
+#: git-gui.sh:2754
msgid "Current Branch:"
msgstr "Jelenlegi branch:"
-#: git-gui.sh:2761
+#: git-gui.sh:2775
msgid "Staged Changes (Will Commit)"
msgstr "KivĂĄlasztott vĂĄltoztatĂĄsok (commitolva lesz)"
-#: git-gui.sh:2781
+#: git-gui.sh:2795
msgid "Unstaged Changes"
msgstr "KivĂĄlasztatlan vĂĄltoztatĂĄsok"
-#: git-gui.sh:2831
+#: git-gui.sh:2845
msgid "Stage Changed"
msgstr "VĂĄltoztatĂĄsok kivĂĄlasztĂĄsa"
-#: git-gui.sh:2850 lib/transport.tcl:93 lib/transport.tcl:182
+#: git-gui.sh:2864 lib/transport.tcl:104 lib/transport.tcl:193
msgid "Push"
msgstr "Push"
-#: git-gui.sh:2885
+#: git-gui.sh:2899
msgid "Initial Commit Message:"
msgstr "Kezdeti commit Ăźzenet:"
-#: git-gui.sh:2886
+#: git-gui.sh:2900
msgid "Amended Commit Message:"
msgstr "JavĂtĂł commit Ăźzenet:"
-#: git-gui.sh:2887
+#: git-gui.sh:2901
msgid "Amended Initial Commit Message:"
msgstr "Kezdeti javĂtĂł commit Ăźzenet:"
-#: git-gui.sh:2888
+#: git-gui.sh:2902
msgid "Amended Merge Commit Message:"
msgstr "JavĂtĂł merge commit Ăźzenet:"
-#: git-gui.sh:2889
+#: git-gui.sh:2903
msgid "Merge Commit Message:"
msgstr "Merge commit Ăźzenet:"
-#: git-gui.sh:2890
+#: git-gui.sh:2904
msgid "Commit Message:"
msgstr "Commit Ăźzenet:"
-#: git-gui.sh:2939 git-gui.sh:3090 lib/console.tcl:73
+#: git-gui.sh:2953 git-gui.sh:3104 lib/console.tcl:73
msgid "Copy All"
msgstr "Ă–sszes mĂĄsolĂĄsa"
-#: git-gui.sh:2963 lib/blame.tcl:104
+#: git-gui.sh:2977 lib/blame.tcl:104
msgid "File:"
msgstr "FĂĄjl:"
-#: git-gui.sh:3078
+#: git-gui.sh:3092
msgid "Refresh"
msgstr "FrissĂtĂŠs"
-#: git-gui.sh:3099
+#: git-gui.sh:3113
msgid "Decrease Font Size"
msgstr "Font mĂŠret csĂśkkentĂŠse"
-#: git-gui.sh:3103
+#: git-gui.sh:3117
msgid "Increase Font Size"
msgstr "FĂśnt mĂŠret nĂśvelĂŠse"
-#: git-gui.sh:3111 lib/blame.tcl:281
+#: git-gui.sh:3125 lib/blame.tcl:281
msgid "Encoding"
msgstr "KĂłdolĂĄs"
-#: git-gui.sh:3122
+#: git-gui.sh:3136
msgid "Apply/Reverse Hunk"
msgstr "Hunk alkalmazĂĄsa/visszaĂĄllĂtĂĄsa"
-#: git-gui.sh:3127
+#: git-gui.sh:3141
msgid "Apply/Reverse Line"
msgstr "Sor alkalmazĂĄsa/visszaĂĄllĂtĂĄsa"
-#: git-gui.sh:3137
+#: git-gui.sh:3151
msgid "Run Merge Tool"
msgstr "Merge eszkĂśz futtatĂĄsa"
-#: git-gui.sh:3142
+#: git-gui.sh:3156
msgid "Use Remote Version"
msgstr "TĂĄvoli verziĂł hasznĂĄlata"
-#: git-gui.sh:3146
+#: git-gui.sh:3160
msgid "Use Local Version"
msgstr "Helyi verziĂł hasznĂĄlata"
-#: git-gui.sh:3150
+#: git-gui.sh:3164
msgid "Revert To Base"
msgstr "VisszaĂĄllĂtĂĄs az alaphoz"
-#: git-gui.sh:3169
+#: git-gui.sh:3183
msgid "Unstage Hunk From Commit"
msgstr "Hunk tĂśrlĂŠse commitbĂłl"
-#: git-gui.sh:3170
+#: git-gui.sh:3184
msgid "Unstage Line From Commit"
msgstr "A sor kivĂĄlasztĂĄsĂĄnak tĂśrlĂŠse"
-#: git-gui.sh:3172
+#: git-gui.sh:3186
msgid "Stage Hunk For Commit"
msgstr "Hunk kivĂĄlasztĂĄsa commitba"
-#: git-gui.sh:3173
+#: git-gui.sh:3187
msgid "Stage Line For Commit"
msgstr "Sor kivĂĄlasztĂĄsa commitba"
-#: git-gui.sh:3196
+#: git-gui.sh:3210
msgid "Initializing..."
msgstr "InicializĂĄlĂĄs..."
-#: git-gui.sh:3301
+#: git-gui.sh:3315
#, tcl-format
msgid ""
"Possible environment issues exist.\n"
@@ -516,7 +516,7 @@ msgstr ""
"indĂtott folyamatok ĂĄltal:\n"
"\n"
-#: git-gui.sh:3331
+#: git-gui.sh:3345
msgid ""
"\n"
"This is due to a known issue with the\n"
@@ -526,7 +526,7 @@ msgstr ""
"Ez a Cygwin ĂĄltal terjesztett Tcl binĂĄrisban\n"
"lÊvő ismert hiba miatt van."
-#: git-gui.sh:3336
+#: git-gui.sh:3350
#, tcl-format
msgid ""
"\n"
@@ -612,43 +612,43 @@ msgstr "FuttatĂĄs mĂĄsolĂĄs-ĂŠrzĂŠkelĂŠsen keresztĂźl..."
msgid "Loading annotation..."
msgstr "Az annotĂĄciĂł betĂśltĂŠse..."
-#: lib/blame.tcl:964
+#: lib/blame.tcl:963
msgid "Author:"
msgstr "Szerző:"
-#: lib/blame.tcl:968
+#: lib/blame.tcl:967
msgid "Committer:"
msgstr "Commiter:"
-#: lib/blame.tcl:973
+#: lib/blame.tcl:972
msgid "Original File:"
msgstr "Eredeti fĂĄjl:"
-#: lib/blame.tcl:1021
+#: lib/blame.tcl:1020
msgid "Cannot find HEAD commit:"
msgstr "Nem talĂĄlhatĂł a HEAD commit:"
-#: lib/blame.tcl:1076
+#: lib/blame.tcl:1075
msgid "Cannot find parent commit:"
msgstr "Nem talålható a szßlő commit:"
-#: lib/blame.tcl:1091
+#: lib/blame.tcl:1090
msgid "Unable to display parent"
msgstr "Nem lehet megjelenĂteni a szĂźlĹ‘t"
-#: lib/blame.tcl:1092 lib/diff.tcl:297
+#: lib/blame.tcl:1091 lib/diff.tcl:297
msgid "Error loading diff:"
msgstr "Hiba a diff betĂśltĂŠse kĂśzben:"
-#: lib/blame.tcl:1232
+#: lib/blame.tcl:1231
msgid "Originally By:"
msgstr "Eredeti szerző:"
-#: lib/blame.tcl:1238
+#: lib/blame.tcl:1237
msgid "In File:"
msgstr "Ebben a fĂĄjlban:"
-#: lib/blame.tcl:1243
+#: lib/blame.tcl:1242
msgid "Copied Or Moved Here By:"
msgstr "Ide mĂĄsolta vagy helyezte:"
@@ -665,7 +665,7 @@ msgstr "Checkout"
#: lib/checkout_op.tcl:544 lib/choose_font.tcl:43 lib/merge.tcl:172
#: lib/option.tcl:125 lib/remote_add.tcl:32 lib/remote_branch_delete.tcl:42
#: lib/tools_dlg.tcl:40 lib/tools_dlg.tcl:204 lib/tools_dlg.tcl:352
-#: lib/transport.tcl:97
+#: lib/transport.tcl:108
msgid "Cancel"
msgstr "MĂŠgsem"
@@ -1317,19 +1317,19 @@ msgstr ""
"A jelenlegi merge mĂŠg nem teljesen fejezĹ‘dĂśtt be. Csak akkor javĂthat egy "
"elĹ‘bbi commitot, hogyha megszakĂtja a jelenlegi merge folyamatot.\n"
-#: lib/commit.tcl:49
+#: lib/commit.tcl:48
msgid "Error loading commit data for amend:"
msgstr "Hiba a javĂtandĂł commit adat betĂśltĂŠse kĂśzben:"
-#: lib/commit.tcl:76
+#: lib/commit.tcl:75
msgid "Unable to obtain your identity:"
msgstr "Nem sikerĂźlt megĂĄllapĂtani az azonosĂtĂłt:"
-#: lib/commit.tcl:81
+#: lib/commit.tcl:80
msgid "Invalid GIT_COMMITTER_IDENT:"
msgstr "ÉrvÊnytelen GIT_COMMITTER_IDENT:"
-#: lib/commit.tcl:133
+#: lib/commit.tcl:132
msgid ""
"Last scanned state does not match repository state.\n"
"\n"
@@ -1346,7 +1346,7 @@ msgstr ""
"\n"
"Az ĂşjrakeresĂŠs most automatikusan el fog indulni.\n"
-#: lib/commit.tcl:156
+#: lib/commit.tcl:155
#, tcl-format
msgid ""
"Unmerged files cannot be committed.\n"
@@ -1359,7 +1359,7 @@ msgstr ""
"A(z) %s fĂĄjlban ĂźtkĂśzĂŠsek vannak. Egyszer azokat ki kell javĂtani, majd "
"hozzå ki kell vålasztani a fåjlt mielőtt commitolni lehetne.\n"
-#: lib/commit.tcl:164
+#: lib/commit.tcl:163
#, tcl-format
msgid ""
"Unknown file state %s detected.\n"
@@ -1370,7 +1370,7 @@ msgstr ""
"\n"
"A(z) %s fĂĄjlt nem tudja ez a program commitolni.\n"
-#: lib/commit.tcl:172
+#: lib/commit.tcl:171
msgid ""
"No changes to commit.\n"
"\n"
@@ -1380,7 +1380,7 @@ msgstr ""
"\n"
"LegalĂĄbb egy fĂĄjl ki kell vĂĄlasztani, hogy commitolni lehessen.\n"
-#: lib/commit.tcl:187
+#: lib/commit.tcl:186
msgid ""
"Please supply a commit message.\n"
"\n"
@@ -1398,45 +1398,45 @@ msgstr ""
"- MĂĄsodik sor: Ăœres\n"
"- A tĂśbbi sor: LeĂrja, hogy miĂŠrt jĂł ez a vĂĄltoztatĂĄs.\n"
-#: lib/commit.tcl:211
+#: lib/commit.tcl:210
#, tcl-format
msgid "warning: Tcl does not support encoding '%s'."
msgstr "figyelmeztetĂŠs: a Tcl nem tĂĄmogatja a(z) '%s' kĂłdolĂĄst."
-#: lib/commit.tcl:227
+#: lib/commit.tcl:226
msgid "Calling pre-commit hook..."
msgstr "A pre-commit hurok meghĂvĂĄsa..."
-#: lib/commit.tcl:242
+#: lib/commit.tcl:241
msgid "Commit declined by pre-commit hook."
msgstr "A commitot megakadĂĄlyozta a pre-commit hurok. "
-#: lib/commit.tcl:265
+#: lib/commit.tcl:264
msgid "Calling commit-msg hook..."
msgstr "A commit-msg hurok meghĂvĂĄsa..."
-#: lib/commit.tcl:280
+#: lib/commit.tcl:279
msgid "Commit declined by commit-msg hook."
msgstr "A commiot megakadĂĄlyozta a commit-msg hurok."
-#: lib/commit.tcl:293
+#: lib/commit.tcl:292
msgid "Committing changes..."
msgstr "A vĂĄltoztatĂĄsok commitolĂĄsa..."
-#: lib/commit.tcl:309
+#: lib/commit.tcl:308
msgid "write-tree failed:"
msgstr "a write-tree sikertelen:"
-#: lib/commit.tcl:310 lib/commit.tcl:354 lib/commit.tcl:374
+#: lib/commit.tcl:309 lib/commit.tcl:353 lib/commit.tcl:373
msgid "Commit failed."
msgstr "A commit nem sikerĂźlt."
-#: lib/commit.tcl:327
+#: lib/commit.tcl:326
#, tcl-format
msgid "Commit %s appears to be corrupt"
msgstr "A(z) %s commit sĂŠrĂźltnek tĹąnik"
-#: lib/commit.tcl:332
+#: lib/commit.tcl:331
msgid ""
"No changes to commit.\n"
"\n"
@@ -1450,19 +1450,19 @@ msgstr ""
"\n"
"Az ĂşjrakeresĂŠs most automatikusan el fog indulni.\n"
-#: lib/commit.tcl:339
+#: lib/commit.tcl:338
msgid "No changes to commit."
msgstr "Nincs commitolandĂł vĂĄltoztatĂĄs."
-#: lib/commit.tcl:353
+#: lib/commit.tcl:352
msgid "commit-tree failed:"
msgstr "a commit-tree sikertelen:"
-#: lib/commit.tcl:373
+#: lib/commit.tcl:372
msgid "update-ref failed:"
msgstr "az update-ref sikertelen:"
-#: lib/commit.tcl:461
+#: lib/commit.tcl:460
#, tcl-format
msgid "Created commit %s: %s"
msgstr "LĂŠtrejĂśtt a %s commit: %s"
@@ -2168,7 +2168,8 @@ msgstr "A(z) %s letĂśltĂŠse"
msgid "Do not know how to initialize repository at location '%s'."
msgstr "Nem tudni, hogy hogy kell a(z) '%s' helyen repĂłt inicializĂĄlni."
-#: lib/remote_add.tcl:163 lib/transport.tcl:25 lib/transport.tcl:71
+#: lib/remote_add.tcl:163 lib/transport.tcl:25 lib/transport.tcl:63
+#: lib/transport.tcl:81
#, tcl-format
msgid "push %s"
msgstr "%s push-olĂĄsa"
@@ -2186,11 +2187,11 @@ msgstr "TĂĄvoli Branch tĂśrlĂŠse"
msgid "From Repository"
msgstr "ForrĂĄs repĂł"
-#: lib/remote_branch_delete.tcl:50 lib/transport.tcl:123
+#: lib/remote_branch_delete.tcl:50 lib/transport.tcl:134
msgid "Remote:"
msgstr "TĂĄvoli:"
-#: lib/remote_branch_delete.tcl:66 lib/transport.tcl:138
+#: lib/remote_branch_delete.tcl:66 lib/transport.tcl:149
msgid "Arbitrary Location:"
msgstr "Ă–nkĂŠnyes hely:"
@@ -2519,38 +2520,43 @@ msgstr "A %s repóból tÜrÜlt kÜvető branchek tÜrlÊse"
msgid "Pushing changes to %s"
msgstr "VĂĄltozĂĄsok pusholĂĄsa ide: %s"
-#: lib/transport.tcl:72
+#: lib/transport.tcl:64
+#, tcl-format
+msgid "Mirroring to %s"
+msgstr "TßkrÜzÊs a kÜvetkező helyre: %s"
+
+#: lib/transport.tcl:82
#, tcl-format
msgid "Pushing %s %s to %s"
msgstr "PusholĂĄs: %s %s, ide: %s"
-#: lib/transport.tcl:89
+#: lib/transport.tcl:100
msgid "Push Branches"
msgstr "Branchek pusholĂĄsa"
-#: lib/transport.tcl:103
+#: lib/transport.tcl:114
msgid "Source Branches"
msgstr "ForrĂĄs branchek"
-#: lib/transport.tcl:120
+#: lib/transport.tcl:131
msgid "Destination Repository"
msgstr "CĂŠl repĂł"
-#: lib/transport.tcl:158
+#: lib/transport.tcl:169
msgid "Transfer Options"
msgstr "Ătviteli opciĂłk"
-#: lib/transport.tcl:160
+#: lib/transport.tcl:171
msgid "Force overwrite existing branch (may discard changes)"
msgstr ""
"LĂŠtezĹ‘ branch felĂźlĂrĂĄsĂĄnak erĹ‘ltetĂŠse (lehet, hogy el fog dobni "
"vĂĄltoztatĂĄsokat)"
-#: lib/transport.tcl:164
+#: lib/transport.tcl:175
msgid "Use thin pack (for slow network connections)"
msgstr "VĂŠkony csomagok hasznĂĄlata (lassĂş hĂĄlĂłzati kapcsolatok szĂĄmĂĄra)"
-#: lib/transport.tcl:168
+#: lib/transport.tcl:179
msgid "Include tags"
msgstr "Tageket is"
--
1.6.0.3
^ permalink raw reply related
* [PATCH] remove unnecessary 'if'
From: Alexander Potashev @ 2008-12-10 14:09 UTC (permalink / raw)
To: git; +Cc: gitster, Alexander Potashev
'patch->is_new' is always <= 0 at this point (look at 'assert' at the
beginning of the function). In both cases ('is_new < 0' and 'is_new == 0')
the result of those two lines is zeroing of 'is_new'.
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
---
builtin-apply.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 4c4d1e1..904a748 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2440,8 +2440,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
if (!cached)
st_mode = ce_mode_from_stat(*ce, st->st_mode);
- if (patch->is_new < 0)
- patch->is_new = 0;
+ patch->is_new = 0;
if (!patch->old_mode)
patch->old_mode = st_mode;
if ((st_mode ^ patch->old_mode) & S_IFMT)
--
1.6.0.4
^ permalink raw reply related
* Re: builtin-add.c patch
From: Alexander Potashev @ 2008-12-10 14:26 UTC (permalink / raw)
To: daly; +Cc: git
In-Reply-To: <200812101238.mBACcWQk023480@axiom-developer.org>
Hello, Tim!
On 06:38 Wed 10 Dec , daly@axiom-developer.org wrote:
> A trivial patch to fix a typo -- Tim Daly
>
>
> diff --git a/builtin-add.c b/builtin-add.c
> index ea4e771..5f2e68b 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -23,7 +23,7 @@ static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
> int num_unmatched = 0, i;
>
> /*
> - * Since we are walking the index as if we are warlking the directory,
> + * Since we are walking the index as if we are walking the directory,
We probably should use subjunctive here:
"Since we are walking the index as if we _were_ walking the directory,".
Are there any native English speakers? :)
> * we have to mark the matched pathspec as seen; otherwise we will
> * mistakenly think that the user gave a pathspec that did not match
> * anything.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
It's also better to change the commit message, one should be able to
realize from it that the change is a typo fix in comments.
^ permalink raw reply
* [PATCH v2] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Marcel M. Cary @ 2008-12-10 15:04 UTC (permalink / raw)
To: gitster, git; +Cc: jnareb, ae, j.sixt, Marcel M. Cary
In-Reply-To: <7viqq1hghw.fsf@gitster.siamese.dyndns.org>
* When interpretting a relative upward (../) path in cd_to_toplevel,
prepend the cwd without symlinks, given by /bin/pwd
* Add tests for cd_to_toplevel and "git pull" in a symlinked
directory that failed before this fix, plus constrasting
scenarios that already worked
Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org>
---
Now /bin/pwd is only used when $cdup both is relative
and contains a ".." component, which I think is most of
the time that git didn't start out in the top-level
directory.
I can't seem to exercise the case that show-cdup prints
something other than "../" or "", even when setting
GIT_WORK_TREE in or out of the work tree. Is it premature
to anticipate that show-cdup might print an arbitrary path
sometime in the future, given the
"if (!is_inside_work_tree())" branch of show-cdup? Or maybe
it does now and I just don't see the use case.
Also, the additional invocation of "cd" is now removed.
git-sh-setup.sh | 23 ++++++++++++++-
t/t2300-cd-to-toplevel.sh | 37 +++++++++++++++++++++++++
t/t5521-pull-symlink.sh | 67 +++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 125 insertions(+), 2 deletions(-)
create mode 100755 t/t2300-cd-to-toplevel.sh
create mode 100755 t/t5521-pull-symlink.sh
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index dbdf209..f07d96b 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -85,8 +85,27 @@ cd_to_toplevel () {
cdup=$(git rev-parse --show-cdup)
if test ! -z "$cdup"
then
- cd "$cdup" || {
- echo >&2 "Cannot chdir to $cdup, the toplevel of the working tree"
+ case "$cdup" in
+ /*)
+ # Not quite the same as if we did "cd -P '$cdup'" when
+ # $cdup contains ".." after symlink path components.
+ # Don't fix that case at least until Git switches to
+ # "cd -P" across the board.
+ phys="$cdup"
+ ;;
+ ..|../*|*/..|*/../*)
+ # Interpret $cdup relative to the physical, not logical, cwd.
+ # Probably /bin/pwd is more portable than passing -P to cd or pwd.
+ phys="$(/bin/pwd)/$cdup"
+ ;;
+ *)
+ # There's no "..", so no need to make things absolute.
+ phys="$cdup"
+ ;;
+ esac
+
+ cd "$phys" || {
+ echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
exit 1
}
fi
diff --git a/t/t2300-cd-to-toplevel.sh b/t/t2300-cd-to-toplevel.sh
new file mode 100755
index 0000000..293dc35
--- /dev/null
+++ b/t/t2300-cd-to-toplevel.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='cd_to_toplevel'
+
+. ./test-lib.sh
+
+test_cd_to_toplevel () {
+ test_expect_success "$2" '
+ (
+ cd '"'$1'"' &&
+ . git-sh-setup &&
+ cd_to_toplevel &&
+ [ "$(pwd -P)" = "$TOPLEVEL" ]
+ )
+ '
+}
+
+TOPLEVEL="$(pwd -P)/repo"
+mkdir -p repo/sub/dir
+mv .git repo/
+SUBDIRECTORY_OK=1
+
+test_cd_to_toplevel repo 'at physical root'
+
+test_cd_to_toplevel repo/sub/dir 'at physical subdir'
+
+ln -s repo symrepo
+test_cd_to_toplevel symrepo 'at symbolic root'
+
+ln -s repo/sub/dir subdir-link
+test_cd_to_toplevel subdir-link 'at symbolic subdir'
+
+cd repo
+ln -s sub/dir internal-link
+test_cd_to_toplevel internal-link 'at internal symbolic subdir'
+
+test_done
diff --git a/t/t5521-pull-symlink.sh b/t/t5521-pull-symlink.sh
new file mode 100755
index 0000000..f18fec7
--- /dev/null
+++ b/t/t5521-pull-symlink.sh
@@ -0,0 +1,67 @@
+#!/bin/sh
+
+test_description='pulling from symlinked subdir'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+# The scenario we are building:
+#
+# trash\ directory/
+# clone-repo/
+# subdir/
+# bar
+# subdir-link -> clone-repo/subdir/
+#
+# The working directory is subdir-link.
+#
+test_expect_success setup '
+
+ mkdir subdir &&
+ touch subdir/bar &&
+ git add subdir/bar &&
+ git commit -m empty &&
+ git clone . clone-repo &&
+ # demonstrate that things work without the symlink
+ test_debug "cd clone-repo/subdir/ && git pull; cd ../.." &&
+ ln -s clone-repo/subdir/ subdir-link &&
+ cd subdir-link/ &&
+ test_debug "set +x"
+'
+
+# From subdir-link, pulling should work as it does from
+# clone-repo/subdir/.
+#
+# Instead, the error pull gave was:
+#
+# fatal: 'origin': unable to chdir or not a git archive
+# fatal: The remote end hung up unexpectedly
+#
+# because git would find the .git/config for the "trash directory"
+# repo, not for the clone-repo repo. The "trash directory" repo
+# had no entry for origin. Git found the wrong .git because
+# git rev-parse --show-cdup printed a path relative to
+# clone-repo/subdir/, not subdir-link/. Git rev-parse --show-cdup
+# used the correct .git, but when the git pull shell script did
+# "cd `git rev-parse --show-cdup`", it ended up in the wrong
+# directory. Shell "cd" works a little different from chdir() in C.
+# Bash's "cd -P" works like chdir() in C.
+#
+test_expect_success 'pulling from symlinked subdir' '
+
+ git pull
+'
+
+# Prove that the remote end really is a repo, and other commands
+# work fine in this context.
+#
+test_debug "
+ test_expect_success 'pushing from symlinked subdir' '
+
+ git push
+ '
+"
+cd "$D"
+
+test_done
--
1.6.0.3
^ permalink raw reply related
* Re: [PATCH 2/3] gitweb: Cache $parent_commit info in git_blame()
From: Jakub Narebski @ 2008-12-10 15:15 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <182871.96175.qm@web31804.mail.mud.yahoo.com>
On Wed, 10 Dec 2008, Luben Tuikov wrote:
> --- On Tue, 12/9/08, Jakub Narebski <jnareb@gmail.com> wrote:
> > This patch attempts to migitate issue [of performance] a bit by
> > caching $parent_commit info in %metainfo, which makes gitweb to
> > call git-rev-parse only once per unique commit in blame output.
>
> Have you tested this patch that it gives the same commit chain
> as before it?
The only difference between precious version and this patch is that
now, if you calculate sha-1 of $long_rev^, it is stored in
$metainfo{$long_rev}{'parent'} and not calculated second time.
But I have checked that (at least for single example file) the blame
output is identical for before and after this patch.
> > That is what I have noticed during browsing git_blame()
> > code.
>
> What?
What I have noticed? I have noticed this inefficiency.
Why I was browsing git_blame? To write git_blame_incremental...
See also my reply to Nanako Shiraishi with simple benchmark.
> > We can change it to even more effective implementation
> > (like the ones proposed above in the commit message) later.
>
> Where?
jn> Unfortunately the implementation in 244a70e used one call for
jn> git-rev-parse to find parent revision per line in file, instead of
jn> using long lived "git cat-file --batch-check" (which might not existed
jn> then), or changing validate_refname to validate_revision and made it
jn> accept <rev>^, <rev>^^, <rev>^^^ etc. syntax.
One solution mentioned there is to open bidi pipe (like in Git::Repo
in gitweb caching by Lea Wiemann) to "git cat-file --batch-check"
(the '--batch-check' option was added to git-cat-file by Adam Roben
on Apr 23, 2008 in v1.5.6-rc0~8^2~9), feed it $long_rev^, and parse
its output of the form:
926b07e694599d86cec668475071b32147c95034 commit 637
see manpage for git-cat-file(1). Unfortunately it seems like
command_bidi_pipe doesn't work as _I_ expected...
Another solution mentioned there is to change validate_refname to
validate_revision when checking script parameters (CGI query or
path_info), with validate_revision being something like:
sub validate_revision {
my $rev = shift;
return validate_refname(strip_rev_suffixes($rev));
}
or something like that, so we don't need to calculate $long_rev^,
but can pass "$long_rev^" as 'hb' parameter ($long_rev can in turn
also end in '^').
--
Jakub Narebski
Poland
^ permalink raw reply
* malloc fails when dealing with huge files
From: Jonathan Blanton @ 2008-12-10 15:42 UTC (permalink / raw)
To: git
I'm using Git for a project that contains huge (multi-gigabyte) files.
I need to track these files, but with some of the really big ones,
git-add aborts with the message "fatal: Out of memory, malloc failed".
Also, git-gc sometimes fails because it can't allocate enough memory.
I've been using the "--window-memory" option to git- repack to work
around the git-gc problem, but I don't know of a similar trick for
git-add. Is there any way (aside from adding more memory, of course)
that I can deal with these huge files? I'm using git 1.5.6.2 on
Debian 4.0.
Thanks in advance.
Jonathan Blanton
^ permalink raw reply
* Re: builtin-add.c patch
From: Boyd Stephen Smith Jr. @ 2008-12-10 16:01 UTC (permalink / raw)
To: Alexander Potashev; +Cc: daly, git
In-Reply-To: <20081210142632.GA4137@myhost>
[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]
On Wednesday 2008 December 10 08:26:32 Alexander Potashev wrote:
>> diff --git a/builtin-add.c b/builtin-add.c
>> index ea4e771..5f2e68b 100644
>> --- a/builtin-add.c
>> +++ b/builtin-add.c
>> @@ -23,7 +23,7 @@ static void fill_pathspec_matches(const char **pathspec,
>> char *seen, int specs) int num_unmatched = 0, i;
>>
>> /*
>> - * Since we are walking the index as if we are warlking the directory,
>> + * Since we are walking the index as if we are walking the directory,
>
>We probably should use subjunctive here:
>"Since we are walking the index as if we _were_ walking the directory,".
>
>Are there any native English speakers? :)
Southern bah the grace o' gawd. :)
Yes, the subjunctive is the appropriate tense for use in hypotheticals ("as
if").
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* fatal output from git-show really wants a terminal
From: Tim Olsen @ 2008-12-10 16:01 UTC (permalink / raw)
To: git
It appears that when outputting a fatal error, git-show will choose
stdout over stderr if stdout is a terminal and stderr is not. How do I
redirect the error but still allow stdout to be displayed?
~/git$ mkdir test
~/git$ cd test
~/git/test$ git init
~/git/test$ git show 12345
fatal: ambiguous argument '12345': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
~/git/test$ git show 12345 2> /dev/null
fatal: ambiguous argument '12345': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
~/git/test$ git show 12345 > /dev/null
fatal: ambiguous argument '12345': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
~/git/test$ git show 12345 > /dev/null 2> /dev/null
~/git/test$ git show 12345 > /tmp/out 2> /tmp/err
~/git/test$ cat /tmp/out
~/git/test$ cat /tmp/err
fatal: ambiguous argument '12345': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions
^ permalink raw reply
* Re: fatal output from git-show really wants a terminal
From: Boyd Stephen Smith Jr. @ 2008-12-10 16:10 UTC (permalink / raw)
To: git; +Cc: Tim Olsen
In-Reply-To: <ghop5d$qud$1@ger.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 701 bytes --]
On Wednesday 2008 December 10 10:01:49 you wrote:
>It appears that when outputting a fatal error, git-show will choose
>stdout over stderr if stdout is a terminal and stderr is not. How do I
>redirect the error but still allow stdout to be displayed?
Gah, I think that's really bad behavior. Anyway, something like:
git show 12345 2>/dev/null | cat
should work. Neither stdout nor stderr will be a terminal, but stdout will be
displayed to your terminal.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@volumehost.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Annotating patches inside diff
From: Johannes Schindelin @ 2008-12-10 16:58 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200812101445.48034.jnareb@gmail.com>
Hi,
On Wed, 10 Dec 2008, Jakub Narebski wrote:
> I remember that long time ago on git mailing list there was discussed
> extending git-apply and friends (including git-am), to be able to
> ignore lines in patches with selected special prefix, different from
> '@' for chunks headers, ' ' for context, '+'/'-' for added/deleted
> lines. IIRC it was chose '|' for this purpose.
>
> This way you could annotate patch
>
> @@ -4667,7 +4667,6 @@ HTML
> hash_base => $parent_commit);
> print "<td class=\"linenr\">";
> print $cgi->a({ -href => "$blamed#l$orig_lineno",
> | moved to <tr>
> - -id => "l$lineno",
> -class => "linenr" },
> esc_html($lineno));
> print "</td>";
>
>
> Was it accepted or dropped, or is this feature present but not
> documented?
As I said on IRC, I think that if you are too good in the hiding-comments
business, you can just spare the time to write them, 'cause nobody will
find them.
IOW such a comment needs to go either into the commit message (if it is an
important API change), so that people who do not remember discussions on
the mailing list still have a chance to find the comment, or between the
message and the diffstat (if it is less important).
Ciao,
Dscho
^ permalink raw reply
* Re: help needed: Splitting a git repository after subversion migration
From: Thomas Jarosch @ 2008-12-10 16:33 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Michael J Gruber, git
In-Reply-To: <200812081834.26688.thomas.jarosch@intra2net.com>
On Monday, 8. December 2008 18:34:20 Thomas Jarosch wrote:
> 1. When I run "git rev-list --all --objects", I can see file names that
> look like "SVN-branchname/directory/filename". Is it normal that "git svn"
> creates a directory with the name of the branch and puts files below it?
Ok, this seems to be a PEBKAC: In the history of the subversion repository,
f.e. I once copied the "branches" root folder to tags/xyz. One revision later
I noticed this and retagged the correct branch. git-svn imports all branches
from the first tag, which is the correct thing to do :o)
Now I'll manually check the history of the tags/ and branches/ folder
for more funny tags and write down the revision. If I understood
the git-svn man page correctly, I should be able to specifiy
revision ranges it's going to import. I'll try to skip the broken tags.
Cheers,
Thomas
^ permalink raw reply
* after first git clone of linux kernel repository there are changed files in working dir
From: rdkrsr @ 2008-12-10 18:22 UTC (permalink / raw)
To: git
In-Reply-To: <d304880b0812101019ufe85095h46ff0fe00d32bbd0@mail.gmail.com>
I just fetched the sources without changing anything, but git diff
shows, that there are changes that are not yet updated (changed but not
updated: use git add to ...). Why is it like that?
I use msysgit on windows, maybe that is one reason?
^ permalink raw reply
* Re: Annotating patches inside diff
From: Junio C Hamano @ 2008-12-10 18:40 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200812101445.48034.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> I remember that long time ago on git mailing list there was discussed
> extending git-apply and friends (including git-am), to be able to
> ignore lines in patches with selected special prefix, different from
> '@' for chunks headers, ' ' for context, '+'/'-' for added/deleted
> lines. IIRC it was chose '|' for this purpose.
That's a blast from the past.
> This way you could annotate patch
>
> @@ -4667,7 +4667,6 @@ HTML
> ...
>
> Was it accepted or dropped, or is this feature present but not
> documented?
The code is simple, but I do not think it is a good idea to do so:
* If it is about describing the state (what it does, how it does it and
why), you should be writing that as in-code comments;
* If it is about describing the change (what it used to do and how, and
what it does after your change and how, and why you changed it that
way), i.e. "we used to do X but now we do Y for such and such reasons"
(your example is a good one, except in real life you would want to
state "why" as well), you should be writing that in the commit log
message; and
* If describing the change in the commit log message feels insufficient,
it probably is a sign that the patch is too big and covers too many
topics.
In other words, I think the problem the old patch attempted to solve was
this:
When you do too many things in a patch touching many places of the
code, and want to explain and justify all of them, your commit log
message becomes a list of "we used to do X but 7th hunk changes it to Y
because of Z" entries for different X, Y and Z. When this list gets
too big, it is easier to read through the patch if such explanation are
done close to where the changes described are.
For your reference, this was the dropped patch.
From: Junio C Hamano <junkio@cox.net>
Date: Fri, 8 Dec 2006 21:03:52 -0800
Subject: [PATCH] mailinfo: hack to accept in-line annotations in patches.
Long before git-apply, when I wanted to talk about rationale of
individual changes, I used to add annotation between hunks
(delimited @@ -n,m, +l,k @@) as unindented plain text and rely
on GNU patch to discard them as garbage. Because git-apply is
much less forgiving than GNU patch, this is not possible.
This patch teaches mailinfo that lines that begin with a '|' would
never appear in the patch text and can be discarded safely.
Which means that we can generate a patch as usual using format-patch,
and add annotations inline, prefixed with '|'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-mailinfo.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index c95e477..2608260 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -720,8 +720,10 @@ static int handle_commit_msg(char *line)
static int handle_patch(char *line)
{
- fputs(line, patchfile);
- patch_lines++;
+ if (line[0] != '|') {
+ fputs(line, patchfile);
+ patch_lines++;
+ }
return 0;
}
^ permalink raw reply related
* Re: Forcing --no-ff on pull
From: Stephen Haberman @ 2008-12-10 19:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: R. Tyler Ballance, Nanako Shiraishi, git
In-Reply-To: <alpine.LNX.1.00.0812091651360.19665@iabervon.org>
On Tue, 9 Dec 2008 17:32:36 -0500 (EST)
Daniel Barkalow <barkalow@iabervon.org> wrote:
> > At this point, QA is involved and what can happen is that QA realizes
> > that this code is *not* stable and *never* should have been brought into
> > the stable branch.
>
> How do you prevent the (IMHO more likely) case of:
>
> % git checkout -b project
> % git checkout stable
> <fix some bug in stable>
> % git commit -a
> <forget to switch branches back>
> <work>
> % git commit -am "A"
> <work>
> % git commit -am "B"
> ...
> % git push origin stable
>
> That is, the developer makes a whole bunch of inappropriate commits on
> their stable branch instead of their project branch and then pushes it out
> (perhaps as part of a push rule, or thinking only the bug fix went there).
> I suspect that "pull" step there isn't the point where things are going
> wrong.
Well, two things:
1) The hook script at [1] really would prevent this from getting published.
Although it only looks for "stable"--if you have per-team stable branches,
you might need to match on "*-stable" or something like that. But it does
(copy/paste from [1]):
# * stable must move by only 1 commit-per-push
# * the stable commit must have 2 and only 2 parents
# * The first parent must be the previous stable commit
# * The second parent is the tip of the candidate branch being released
# * the stable commit must have the same contents as the candidate tip
# * Any merge conflicts should have been resolved in the candidate tip
# by pulling stable into the candidate and having qa/tests done--pulling
# candidate into stable should then apply cleanly
So, no fast forwards, no direct commits, only "good"/empty merges of
topic branches can move stable. Anything else is rejected and LazyDev
has to try again.
2) As far as "pull" isn't where things are going wrong, that is not
entirely true, as even with the server-side enforcement like [1],
I think you'd still like to help LazyDev out and have `git pull`
"just work" for your given setup. Especially if you don't have full
management buy-in to git, pacifying LazyDev's can be necessary.
- Stephen
1: http://github.com/stephenh/gc/tree/master/server/update-stable
^ permalink raw reply
* Re: builtin-add.c patch
From: root @ 2008-12-10 19:10 UTC (permalink / raw)
To: aspotashev; +Cc: daly, git
In-Reply-To: <20081210142632.GA4137@myhost>
Alexander,
Feel free to change the patch.
Its hardly worth the bits of email used
but it does need to be fixed.
Tim
^ permalink raw reply
* Re: builtin-add.c patch
From: root @ 2008-12-10 19:14 UTC (permalink / raw)
To: aspotashev; +Cc: daly, git
In-Reply-To: <20081210142632.GA4137@myhost>
Alexander,
I saw a suggestion that git could be used as a filesystem rather
than as a code repository. I'm looking to convert it for this
purpose to sit underneath Axiom, a computer algebra system written
in common lisp. Basically the idea is that a "close" operation does
a 'git add foo ; git commit'.
Are you aware of anyone who has used git as a filesystem?
Tim Daly
^ permalink raw reply
* Re: malloc fails when dealing with huge files
From: Linus Torvalds @ 2008-12-10 19:32 UTC (permalink / raw)
To: Jonathan Blanton; +Cc: git
In-Reply-To: <43c10b980812100742t3a65466yb9b7310bfedb2b18@mail.gmail.com>
On Wed, 10 Dec 2008, Jonathan Blanton wrote:
>
> I'm using Git for a project that contains huge (multi-gigabyte) files.
> I need to track these files, but with some of the really big ones,
> git-add aborts with the message "fatal: Out of memory, malloc failed".
git is _really_ not designed for huge files.
By design - good or bad - git does pretty much all single file operations
with the whole file in memory as one single allocation.
Now, some of that is hard to fix - or at least would generate much more
complex code. The _particular_ case of "git add" could be fixed without
undue pain, but it's not entirely trivial either.
The main offender is probably "index_fd()" that just mmap's the whole file
in one go and then calls write_sha1_file() which really expects it to be
one single memory area both for the initial SHA1 create and for the
compression and writing out of the result.
Changing that to do big files in pieces would not be _too_ painful, but
it's not just a couple of lines either.
However, git performance with big files would never be wonderful, and
things like "git diff" would still end up reading not just the whole file,
but _both_versions_ at the same time. Marking the big files as being
no-diff might help, though.
Linus
^ permalink raw reply
* [PATCH 1/2] bash completion: Add '--intent-to-add' long option for 'git add'
From: Lee Marlow @ 2008-12-10 19:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c79c98f..5356e5b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -563,7 +563,7 @@ _git_add ()
--*)
__gitcomp "
--interactive --refresh --patch --update --dry-run
- --ignore-errors
+ --ignore-errors --intent-to-add
"
return
esac
--
1.6.1.rc2.14.g5363d
^ permalink raw reply related
* [PATCH 2/2] bash completion: Use 'git add' completions for 'git stage'
From: Lee Marlow @ 2008-12-10 19:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Lee Marlow
In-Reply-To: <1228937958-5091-1-git-send-email-lee.marlow@gmail.com>
Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
---
contrib/completion/git-completion.bash | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5356e5b..7e2b482 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1660,6 +1660,7 @@ _git ()
show) _git_show ;;
show-branch) _git_show_branch ;;
stash) _git_stash ;;
+ stage) _git_add ;;
submodule) _git_submodule ;;
svn) _git_svn ;;
tag) _git_tag ;;
--
1.6.1.rc2.14.g5363d
^ permalink raw reply related
* Re: [PATCH 1/2] bash completion: Add '--intent-to-add' long option for 'git add'
From: Shawn O. Pearce @ 2008-12-10 19:41 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1228937958-5091-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Trivially-Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index c79c98f..5356e5b 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -563,7 +563,7 @@ _git_add ()
> --*)
> __gitcomp "
> --interactive --refresh --patch --update --dry-run
> - --ignore-errors
> + --ignore-errors --intent-to-add
> "
> return
> esac
> --
> 1.6.1.rc2.14.g5363d
>
--
Shawn.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox