Aw: Re: [PATCH] gittutorial.txt: remove reference to ancient Git version
I also re-read the whole document and think it's still up-to-date with Git 2.0. But I might have missed some subtler points. Thomas - Original Nachricht Von: Junio C Hamano gits...@pobox.com An: Thomas Ackermann th.ac...@arcor.de Datum: 11.11.2014 23:51 Betreff: Re: [PATCH] gittutorial.txt: remove reference to ancient Git version Yeah, sounds like going in the right direction. Perhaps we should start doing a serious re-reading of this document and update the contents to suggest better ways that were invented to solve common problems since this document was written. --- Thomas -- To unsubscribe from this list: send the line 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: [PATCHv5 9/9] t3301: Modernize
On Wed, Nov 12, 2014 at 2:57 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland jo...@herland.net wrote: + test_line_count = 1 actual Broken -chain. This problem is repeated each place use invoke test_line_count(). Thanks. Fixed in the next iteration. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gittutorial.txt: remove reference to ancient Git version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.11.2014 um 09:57 schrieb Thomas Ackermann:
I also re-read the whole document and think it's still up-to-date
with Git 2.0. But I might have missed some subtler points.
Hhmm..
At least this is not 100% up to date:
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 8262196..8715244 100644
- --- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -107,14 +107,15 @@ summary of the situation with 'git status':
$ git status
- -# On branch master
- -# Changes to be committed:
- -# (use git reset HEAD file... to unstage)
- -#
- -# modified: file1
- -# modified: file2
- -# modified: file3
- -#
+On branch master
+Changes to be committed:
+Your branch is up-to-date with 'origin/master'.
+ (use git reset HEAD file... to unstage)
+
+modified: file1
+modified: file2
+modified: file3
+
Stefan
- --
-
/dev/random says: The drunker I sit here, The longer I get.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlRjJGgACgkQgptJxZIhJ6+MfQCeI4iZ3HSkT0Lsk1sh1ckHLBzK
ROwAnAog8We8VLs6trwJsSQqZWDg7ndN
=YC26
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line 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] gittutorial.txt: remove reference to ancient Git version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.11.2014 um 10:12 schrieb Stefan Näwe:
Am 12.11.2014 um 09:57 schrieb Thomas Ackermann:
I also re-read the whole document and think it's still up-to-date
with Git 2.0. But I might have missed some subtler points.
Hhmm..
At least this is not 100% up to date:
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
[...]
And while at it:
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 3109ea8..1901af7 100644
- --- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -368,17 +368,18 @@ situation:
$ git status
- -# On branch master
- -# Changes to be committed:
- -# (use git reset HEAD file... to unstage)
- -#
- -# new file: closing.txt
- -#
- -# Changes not staged for commit:
- -# (use git add file... to update what will be committed)
- -#
- -# modified: file.txt
- -#
+On branch master
+Changes to be committed:
+ (use git reset HEAD file... to unstage)
+
+new file: closing.txt
+
+Changes not staged for commit:
+ (use git add file... to update what will be committed)
+ (use git checkout -- file... to discard changes in working directory)
+
+modified: file.txt
+
Stefan
- --
-
/dev/random says: Make it idiot proof and someone will make a better idiot.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlRjJmoACgkQgptJxZIhJ6+LBgCgmVgJCmJjC86NHopW1rQwk/eA
r04AoIgMfKhB00H8KCHBMAsC5LjCFXY5
=bNM+
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] Clean stale environment pointer in finish_command()
Hi, On Tue, 11 Nov 2014, Junio C Hamano wrote: Jeff King p...@peff.net writes: I don't think this is unfortunately; freeing the memory was the entire purpose in adding env_array. If you want to easily reuse the same environment in multiple commands, it is still perfectly fine to use env directly, like: struct argv_array env = ARGV_ARRAY_INIT; struct child_process one = CHILD_PROCESS_INIT; struct child_process two = CHILD_PROCESS_INIT; ... setup env with argv_array_push ... one.argv = foo; one.env = env.argv; run_command(one); two.argv = bar; two.env = env.argv; run_command(two); argv_array_clear(env); You do not get the benefit of the auto-cleanup (you have to call argv_array_clear yourself), but that is less bad than repeating the setup of env twice. Yeah, the above looks like the best option, better than using a single child_process and having to re-initialize fds and envs. Okay, I have to say that I was led to believe that reusing the child_process struct is okay because argv_array_clear() explicitly reinitializes the env_array field, something that is useless churn unless you plan to reuse the memory. However, my personal taste says that reusing the same memory is more elegant than to waste extra memory unnecessarily, so I will go with the child_process_init() solution. 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
Re: [PATCH v2 1/2] Clean stale environment pointer in finish_command()
On Wed, Nov 12, 2014 at 11:45:19AM +0100, Johannes Schindelin wrote: Okay, I have to say that I was led to believe that reusing the child_process struct is okay because argv_array_clear() explicitly reinitializes the env_array field, something that is useless churn unless you plan to reuse the memory. The argv_array code prepares its data structure for reuse after freeing. But child_process which uses it does not make any such promises. If there were an argv_array_free(), child_process could use it. But there is only argv_array_clear(). I don't have a problem with finish_command leaving its child_process in a known usable state (e.g., by calling child_process_init). But I also don't see much benefit. However, my personal taste says that reusing the same memory is more elegant than to waste extra memory unnecessarily, so I will go with the child_process_init() solution. I do not mind much either way. But I doubt that a single extra struct on the stack will break the bank, compared to the fact that we are forking and execing a new program. I'd also not be surprised if a smart compiler could notice that the variables are used exclusively in non-overlapping bits of the code, and just reuse the stack space. -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 v2 1/2] Clean stale environment pointer in finish_command()
On Wed, Nov 12, 2014 at 05:52:29AM -0500, Jeff King wrote: However, my personal taste says that reusing the same memory is more elegant than to waste extra memory unnecessarily, so I will go with the child_process_init() solution. I do not mind much either way. But I doubt that a single extra struct on the stack will break the bank, compared to the fact that we are forking and execing a new program. I'd also not be surprised if a smart compiler could notice that the variables are used exclusively in non-overlapping bits of the code, and just reuse the stack space. Actually, I take that back. We are passing a pointer to a struct, rather than by-value, so the compiler cannot know that the sub-function does not store that pointer in a static variable, and reference it in the next call. It must use two variables if it cannot see the definition of run_command. I still think it's pointless optimization to worry about, and you should write whichever is the most readable and maintainable. -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 2/2] Let deny.currentBranch=updateInstead ignore submodules
Hi Junio, On Mon, 10 Nov 2014, Junio C Hamano wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: By the way, if the expected use case of updateInstead is what I outlined in the previous message, would it make more sense not to fail with update-index --refresh failure (i.e. the working tree files have no changes since the index)? Thinking about it a bit more, checking with update-index --refresh feels doubly wrong. You not just want the working tree files to be pristine with respect to the index, but also you do not want to see any change between the index and the original HEAD, i.e. $ git reset --hard echo Makefile ; git add Makefile $ git update-index --refresh ; echo $? 0 this is not a good state from which you would want to update the working tree. Wouldn't the two-tree form read-tree -u -m that is the equivalent to branch switching do a sufficient check? That is indeed what the patched code calls. I know that ;-), but I think I wasn't clear enough. I am not saying you are not using two-tree read-tree. I am saying the check with update-index --refresh before read-tree seems dubious. There are three cleanliness we require in various occasions: (1) rebase asks you to have your index and the working tree match HEAD exactly, as if just after reset --hard HEAD. (2) merge asks you to have your index match HEAD exactly (i.e. no output from diff --cached HEAD), and have no changes in the working tree at paths that are involved in the operation. It is OK to have local changes in the working tree (but not in the index) at paths that are not involved in a mergy operation. (3) checkout asks you to have your index and the working tree match either HEAD or the commit you are switching to exactly at paths that are involved in the operation. It is OK to have local changes in the working tree and in the index at paths that are not different between the commits you are moving between, and it is also OK to have the contents from the new commit in the working tree and the index at paths that are different between the two. Dying when update-index --refresh signals a difference is an attempt to mimic #1, but it is in line with the spirit of the reason why a user would want to use updateInstead, I think. The situation is more like the person who pushed into your repository from sideline did a checkout -B $current_branch $new_commit to update the HEAD, the index and the working tree, to let you pretend as if you based your work on the commit he pushed to you. While you still need to error out when your local work does not satisfy the cleanliness criteria #3 above, I do not think you would want to stop the operation when checkout would not fail, e.g. you have a local change that does not interfere with the update between the two commits, with this one: + if (run_command(child)) + die (Could not refresh the index); When refreshed the index successfully, we signal that there were differences between the index and the working tree with a non-zero return value, so Could not refresh is not quite right, either. But this one that checks the exit status from two-tree read-tree + if (run_command(child)) + die (Could not merge working tree with new HEAD. Good luck.); is checking the right condition, i.e. cleanliness #3. The disposition should not be die, but an error return to tell the caller to abort the push as we discussed earlier. I have to say that I am quite puzzled now: I guess that you want me to drop the update-index --refresh call? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Let deny.currentBranch=updateInstead ignore submodules
Hi Junio, On Mon, 10 Nov 2014, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Dying when update-index --refresh signals a difference is an attempt to mimic #1, but it is in line with the spirit of the reason why a user would want to use updateInstead, I think. The situation is more like the person who pushed into your repository from sideline did a checkout -B $current_branch $new_commit to update the HEAD, the index and the working tree, to let you pretend as if you based your work on the commit he pushed to you. While you still need to error out when your local work does not satisfy the cleanliness criteria #3 above, I do not think you would want to stop the operation when checkout would not fail, e.g. you have a local change that does not interfere with the update between the two commits, with this one: + if (run_command(child)) + die (Could not refresh the index); When refreshed the index successfully, we signal that there were differences between the index and the working tree with a non-zero return value, so Could not refresh is not quite right, either. Just to make sure. I am *not* saying that you do not need to run update-index --refresh. It is necessary before running read-tree to avoid false dirtyness, so you do need to run it. I am only saying that it is too strict to fail the operation when the command reports that you have a local modification in the working tree. Okay, now I am even more puzzled. I guess you actually meant to say that I need to convert the die() into a return? If so, I agree fully. Ciao, Johannes -- To unsubscribe from this list: send the line 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/2] Add a few more values for receive.denyCurrentBranch
Hi Junio, On Mon, 10 Nov 2014, Junio C Hamano wrote: Johannes Schindelin johannes.schinde...@gmx.de writes: I do not think of a good justification of detachInstead offhand, but you must have thought things through a lot more than I did, so you can come up with a work flow description that is more usable by mere mortals to justify that mode. The main justification is that it is safer than updateInstead because it is guaranteed not to modify the working directory. I intended it for use by developers who are uncomfortable with updating the working directory through a push, and as uncomfortable with forgetting about temporary branches pushed, say, via git push other-computer HEAD:refs/heads/tmp. However, I have to admit that I never used this myself after the first few weeks of playing with this patch series. Without such a description to justify why detachInstead makes sense, for example, I cannot even answer this simple question: Would it make sense to have a third mode, check out if the working tree is clean, detach otherwise? I imagine that some developer might find that useful. If you insist, I will implement it, even if I personally deem this mode way too complicated a concept for myself to be used safely. You have been around long enough to know that adding a feature of an unknown value is the last thing I would ask, don't you? Given that you actually did ask me to add such a feature when I simply wanted to get a bug fix for fast-export into Git to support Sverre's remote-hg (that he abandoned because of my failure to get the bug fix in), I have to respectfully declare that I do not know that, no, sorry! I am essentially saying this: I do not see why and the patch and its documentation do not explain why it is useful, but Dscho wouldn't have added the feature without a reason better than just because we can do so, so let's assume the mode is useful for some unknown reason. Would people find updateInstead if able otherwise detachInstead even more useful for that same unknown reason? Okay, here is my explanation: at the time I wanted to disprove that updateInstead could make sense, I wanted to offer a milder version of updating the current branch that left the working directory alone: detachInstead. Now, I never used it myself, but I use updateInstead extensively. So now I offer you two choices: - help me come up with a good scenario where it makes sense to detachInstead, or - tell me to drop it. I have no preference. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-send-email.perl: Fix handling of suppresscc option.
Signed-off-by: Jens Stimpfle deb...@jstimpfle.de
---
Notes:
This patch makes sure that sob, cc and bodycc values for
sendemail.suppresscc option are handled, even when the email-addresses in
question are equal to the sender and self in not configured in
sendemail.suppresscc.
Sounds complicated, I know. But the current behaviour is really confusing:
For
example, when sending, git-send-email logs
(mbox) Adding cc: Jens Stimpfle deb...@jstimpfle.de from line 'From: Jens
Stimpfle deb...@jstimpfle.de'
(body) Adding cc: Jens Stimpfle deb...@jstimpfle.de from line
'Signed-off-by: Jens Stimpfle deb...@jstimpfle.de'
even though I have sob configured in sendemail.suppresscc.
With this patch, the suppression handling is also made consistent with the
handling of the author value.
git-send-email.perl | 16 +---
1 file changed, 5 insertions(+), 11 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 9949db0..452a783 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1377,11 +1377,8 @@ foreach my $t (@files) {
foreach my $addr (parse_address_line($1)) {
my $qaddr = unquote_rfc2047($addr);
my $saddr = sanitize_address($qaddr);
- if ($saddr eq $sender) {
- next if ($suppress_cc{'self'});
- } else {
- next if ($suppress_cc{'cc'});
- }
+ next if $suppress_cc{'cc'};
+ next if $suppress_cc{'self'} and $saddr
eq $sender;
printf((mbox) Adding cc: %s from line
'%s'\n,
$addr, $_) unless $quiet;
push @cc, $addr;
@@ -1425,12 +1422,9 @@ foreach my $t (@files) {
my ($what, $c) = ($1, $2);
chomp $c;
my $sc = sanitize_address($c);
- if ($sc eq $sender) {
- next if ($suppress_cc{'self'});
- } else {
- next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
- next if $suppress_cc{'bodycc'} and $what =~
/Cc/i;
- }
+ next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
+ next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
+ next if $suppress_cc{'self'} and $sc eq $sender;
push @cc, $c;
printf((body) Adding cc: %s from line '%s'\n,
$c, $_) unless $quiet;
--
2.1.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: tig: Improving startup time and interactivity
On Tue, Nov 11, 2014 at 3:50 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote: Hi Jonas, HI Dominik, Good to hear from you. working on a relatively old machine with a crypted disk, there are really two performance problems with tig on large repos like gcc or the Linux kernel. I wonder what would be necessary to improve these two problems: 1) Firing up tig for the first time in the kernel repo, the screen goes blank for about a minute. After that it comes up quickly. This is probably caused by decrypting lots of on-disk-objects. You are not alone at reporting this problem. The main reason is that when the revision graph is enabled, tig automatically passes --topo-order to git-log. This commit order seems to cause quite a slow down before the first commits are available in the output in the Linux kernel repo, I assume, due to its many merges. I recently added an option to disable the automatic forcing of topological commit order. So assuming you are using tig from current master, you can do this using `set main-view-commit-title-graph = no-topo`, but I will probably move this setting to another option before the next release (so if it breaks take a look at the NEWS file). Alternatively you can disable the revision graph completely using `set main-view-commit-title-graph = no`. Before the next commit I plan to also investigate whether tig can first load a screen full of commits without --topo-order and then restart git-log, so the main view has content faster. 2) When I cherry pick commits inside tig, it reloads the whole commit history of the active branch before tig accepts new commands. This should should be able to disable this behaviour using `set refresh-mode = manual` if you don't want tig to automatically reload the view. I guess both issues are caused by tig reading the whole commit history before user input is allowed. Is there a way to do that in the background, or interrupt loading when the user presses a key, or to load the history in small chunks? The loading should already happen while also accepting user input (modulo any bugs). After all, you're usually interested only in the last 100 commits or so, and there's no need to block the UI while loading the rest. True. Well, The only part of the loading that is blocking is the .git/index refreshing that takes place when display of work tree changes is enabled in the main view (when `set show-changes = yes`). I will review this again. Could you point me to the right source file? I'm not used to the sources split into multiple files yet. :-) Try: tig grep main_open Ciao Have a great day. -- Jonas Fonseca -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] Clean stale environment pointer in finish_command()
On Wed, Nov 12, 2014 at 2:59 AM, Jeff King p...@peff.net wrote: I do not mind much either way. But I doubt that a single extra struct on the stack will break the bank, compared to the fact that we are forking and execing a new program. I'd also not be surprised if a smart compiler could notice that the variables are used exclusively in non-overlapping bits of the code, and just reuse the stack space. Actually, I take that back. We are passing a pointer to a struct, rather than by-value, so the compiler cannot know that the sub-function does not store that pointer in a static variable, and reference it in the next call. It must use two variables if it cannot see the definition of run_command. I still think it's pointless optimization to worry about, and you should write whichever is the most readable and maintainable. Amen. I do not have strong preference either way as long as the result is readable, correct and maintainlable ;-). -- To unsubscribe from this list: send the line 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] l10n: de.po: translate 62 new messages
Translate 62 new messages came from git.pot update in 16742b0 (l10n: git.pot: proposed updates for v2.2.0 (+62)). Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- po/de.po | 180 +-- 1 file changed, 83 insertions(+), 97 deletions(-) diff --git a/po/de.po b/po/de.po index 96d381e..28ed847 100644 --- a/po/de.po +++ b/po/de.po @@ -23,14 +23,13 @@ msgid hint: %.*s\n msgstr Hinweis: %.*s\n #: advice.c:88 -#, fuzzy msgid Fix them up in the work tree, and then use 'git add/rm file'\n as appropriate to mark resolution and make a commit. msgstr Korrigieren Sie dies im Arbeitsverzeichnis, und benutzen Sie\n dann 'git add/rm Datei', um die Auflösung entsprechend zu markieren\n -und zu committen, oder benutzen Sie 'git commit -a'. +und zu committen. #: archive.c:11 msgid git archive [options] tree-ish [path...] @@ -328,9 +327,9 @@ msgid index-pack died msgstr Erstellung der Paketindexdatei abgebrochen #: color.c:157 -#, fuzzy, c-format +#, c-format msgid invalid color value: %.*s -msgstr Ungültiger Wert für %s: %s +msgstr Ungültiger Farbwert: %.*s #: commit.c:40 #, c-format @@ -349,56 +348,56 @@ msgstr Speicher verbraucht #: config.c:469 config.c:471 #, c-format msgid bad config file line %d in %s -msgstr +msgstr Zeile %d in Konfigurationsdatei %s ist ungültig. #: config.c:587 #, c-format msgid bad numeric config value '%s' for '%s' in %s: %s -msgstr +msgstr Ungültiger numerischer Wert '%s' für Konfiguration '%s' in %s: %s #: config.c:589 -#, fuzzy, c-format +#, c-format msgid bad numeric config value '%s' for '%s': %s -msgstr Konnte Sektion '%s' in Konfiguration nicht nach '%s' umbenennen +msgstr Ungültiger numerischer Wert '%s' für Konfiguration '%s': %s #: config.c:674 -#, fuzzy, c-format +#, c-format msgid failed to expand user dir in: '%s' -msgstr Fehler beim Lesen der Reihenfolgedatei '%s'. +msgstr Fehler beim Erweitern des Nutzerverzeichnisses in: '%s' #: config.c:752 config.c:763 -#, fuzzy, c-format +#, c-format msgid bad zlib compression level %d -msgstr Komprimierungsgrad für Paketierung +msgstr ungültiger zlib Komprimierungsgrad %d #: config.c:885 -#, fuzzy, c-format +#, c-format msgid invalid mode for object creation: %s -msgstr Ungültiges Datumsformat: %s +msgstr Ungültiger Modus für Objekterstellung: %s #: config.c:1201 -#, fuzzy msgid unable to parse command-line config -msgstr Konnte Staging-Area-Datei nicht lesen +msgstr Konnte die über die Kommandozeile angegebene Konfiguration nicht parsen. #: config.c:1262 msgid unknown error occured while reading the configuration files -msgstr +msgstr Es trat ein unbekannter Fehler beim Lesen der Konfigurationsdateien auf. #: config.c:1586 -#, fuzzy, c-format +#, c-format msgid unable to parse '%s' from command-line config -msgstr konnte Wert '%s' für Option %s nicht parsen +msgstr Konnte Wert '%s' aus der über die Kommandozeile angegebenen\n +Konfiguration nicht parsen. #: config.c:1588 #, c-format msgid bad config variable '%s' in file '%s' at line %d -msgstr +msgstr ungültige Konfigurationsvariable '%s' in Datei '%s' bei Zeile %d #: config.c:1647 #, c-format msgid %s has multiple values -msgstr +msgstr %s hat mehrere Werte #: connected.c:69 msgid Could not run 'git rev-list' @@ -642,11 +641,11 @@ msgstr %s: %s - %s #: lockfile.c:275 msgid BUG: reopen a lockfile that is still open -msgstr +msgstr FEHLER: Wiedereröffnen einer bereits geöffneten Lock-Datei #: lockfile.c:277 msgid BUG: reopen a lockfile that has been committed -msgstr +msgstr FEHLER: Wiedereröffnen einer bereits committeten Lock-Datei #: merge.c:41 msgid failed to read the cache @@ -1034,9 +1033,8 @@ msgstr Vielleicht haben Sie vergessen entweder ':/' oder '.' hinzuzufügen? #: pretty.c:968 -#, fuzzy msgid unable to parse --pretty format -msgstr Konnte Objekt '%s' nicht parsen. +msgstr Konnte --pretty Format nicht parsen. #: progress.c:225 msgid done @@ -1150,13 +1148,12 @@ msgid dup2(%d,%d) failed msgstr dup2(%d,%d) fehlgeschlagen #: send-pack.c:265 -#, fuzzy msgid failed to sign the push certificate -msgstr gpg beim Signieren der Daten fehlgeschlagen +msgstr Fehler beim Signieren des \push\-Zertifikates #: send-pack.c:322 msgid the receiving end does not support --signed push -msgstr +msgstr die Gegenseite unterstützt keinen signierten Versand (\--signed push\) #: sequencer.c:172 builtin/merge.c:781 builtin/merge.c:892 #: builtin/merge.c:1002 builtin/merge.c:1012 @@ -1488,9 +1485,9 @@ msgstr Konnte core.worktree in '%s' nicht setzen. #: trailer.c:500 trailer.c:504 trailer.c:508 trailer.c:562 trailer.c:566 #: trailer.c:570 -#, fuzzy, c-format +#, c-format msgid unknown value '%s' for key '%s' -msgstr konnte Wert '%s' für Option %s nicht parsen +msgstr unbekannter Wert '%s' für Schlüssel %s #: trailer.c:552 trailer.c:557 builtin/remote.c:288 #, c-format @@ -1500,17 +1497,16 @@ msgstr mehr als ein %s
smudge filters during checkout crash consistency
I have a case where I would like to smudge files according to the
reflog information of the switching-to branch.
This is difficult to achieve because updating HEAD to the new
switched-to refname or commit hash is the last step performed in a
checkout prior to calling the post-checkout hook, and smudge filters
process content during the rewriting of the index and work-tree before
HEAD is updated.
I believe this weakness of checkout filters also exposes a crash
consistency concern. Suppose power is lost during a long-running
checkout while the index/worktree is being updated but before the new
HEAD file is written.
Upon coming back up, your git status will show edits against your
switching-from branch, and possibilities of recovery would rely on
your memory of what you were doing (instead of git-status reporting
Incomplete checkout to {branch,commit}, 'git checkout --continue' to
continue).
Maybe git could record a CHECKOUT_HEAD at the start of a checkout,
then at the end of the commit update_refs_for_switch() would move
CHECKOUT_HEAD over top HEAD instead of rewriting HEAD (but,
presumably, a lot of logic in update_refs_for_switch() would have to
be relocated to when CHECKOUT_HEAD is written, other implications
notwithstanding).
Crash consistency aside, my workaround for filtering will probably be
to use a fake smudge filter that records the file paths of all
to-be-smudged files to a file under .git/, and then use a post-commit
hook that will process those files from within the newly checked-out
branch (where I'll be using git-archive to overwrite files).
Seems git could fix these two concerns in one fell swoop.
Thanks,
Derek
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Let deny.currentBranch=updateInstead ignore submodules
Johannes Schindelin johannes.schinde...@gmx.de writes: Hi Junio, On Mon, 10 Nov 2014, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Dying when update-index --refresh signals a difference is an attempt to mimic #1, but it is in line with the spirit of the reason why a user would want to use updateInstead, I think. The situation is more like the person who pushed into your repository from sideline did a checkout -B $current_branch $new_commit to update the HEAD, the index and the working tree, to let you pretend as if you based your work on the commit he pushed to you. While you still need to error out when your local work does not satisfy the cleanliness criteria #3 above, I do not think you would want to stop the operation when checkout would not fail, e.g. you have a local change that does not interfere with the update between the two commits, with this one: + if (run_command(child)) + die (Could not refresh the index); When refreshed the index successfully, we signal that there were differences between the index and the working tree with a non-zero return value, so Could not refresh is not quite right, either. Just to make sure. I am *not* saying that you do not need to run update-index --refresh. It is necessary before running read-tree to avoid false dirtyness, so you do need to run it. I am only saying that it is too strict to fail the operation when the command reports that you have a local modification in the working tree. Okay, now I am even more puzzled. I guess you actually meant to say that I need to convert the die() into a return? If so, I agree fully. No. update-index --refresh does two things. (a) For performance reasons, plumbing commands such as diff-files and read-tree do not refresh the stat bits in the index. They expect to be run from scripted Porcelain commands, and expect that the caller would refresh the stat bits before they are called to prevent them from mistakingly seeing that an unmodified existing file, after touch existing-file, as modified. And update-index --refresh is the way for the caller to do so. (b) update-index --refresh indicates with its exit status if the working tree files match what is recorded in the index. This can be used to see if diff-files would report difference. As you are going to run read-tree -m -u, you need to refresh the stat bits for purpose (a) above, i.e. to avoid read-tree from failing due to a difference that does not exist. Because I am assuming that your cleanliness requirement to update the working tree is criterion #3 in the previous message, I do not think you would want to abort the update only because there are some difference between the index and the working tree. That means that checking the exit status of update-index --refresh and dying (or signaling the failure to the caller by returning a non-NULL string, in the context of this call path) is not what you want. You may have a local change to Makefile in the working tree of the repository that you are pushing into, and there may not be any change to the Makefile between the original HEAD the working tree is based on and the updated HEAD you are pushing into the repository. update-index --refresh will say You have a local change. and exit with non-zero status, but just like git checkout another to switch to another branch while you have some local change that does not overlap with the difference between branches does not fail, you would want to allow the update. You may be trying to use a cleanliness requirement that is different from criterion #3 in the previous message, but checking the exit status from update-index --refresh does not make much sense in that case either. I do not think you want to have: * pushing into a repository that did edit Makefile; git add Makefile succeeds. * pushing into a repository that did edit Makefile without git add Makefile fails. but that is what you will get, because update-index --refresh would say Your working tree matches the index by exiting with 0 in the former case, and you will end up running read-tree -m -u. Having said all that. Instead of running update-index --refresh; read-tree -m -u, using reset --keep may be a better implementation of what you are trying to do here. I think a checkout -B current-branch new-commit is what you want to run when a push attempts to update the current branch from sideways with updateInstead, and reset --keep new-commit lets you run an equivalent of the checkout -B current-branch but you do not have to know the name of the current-branch. Also by using reset --keep, you do not have to worry about refreshing the index. 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 1/2] Add a few more values for receive.denyCurrentBranch
Johannes Schindelin johannes.schinde...@gmx.de writes: Okay, here is my explanation: at the time I wanted to disprove that updateInstead could make sense, I wanted to offer a milder version of updating the current branch that left the working directory alone: detachInstead. Now, I never used it myself, but I use updateInstead extensively. Sounds like updateInstead turned out to be useful enough to make a possibly more cautious detachInstead unnecessary? It probably makes sense not to add it in that case, I would think. -- To unsubscribe from this list: send the line 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: diff-highlight highlight words?
On 11/11/2014 11:56 PM, Jeff King wrote: [+cc git@vger, since this may be of interest to others] On Tue, Nov 11, 2014 at 02:40:59PM -0800, Scott Baker wrote: I'd like to recreate the github style diffs on the command line. It appears that your diff-highlight is very close. The current version only allows you to invert the colors which isn't ideal. Yes, I never built any configurability into the script. However, you can tweak the definitions at the top to get different effects. Traditionally, ANSI colors on the terminal only came in two flavors: normal and bright (which is attached to the bold attribute). Instead of reversing video, you can switch on brightness like this: It's 2014, most terminals are at least 256 colors. I'm fine if the defaults are 16 colors (that's safest), but it would be really cool if we could have an option for: line add color line remove color word add color word remove color I would then configure appropriate colors from the 256 color palette. I think the Github style diffs which include the lines/words that are changed are very readable and make dealing with diffs easier. -- Scott Baker - Canby Telcom Senior System Administrator - RHCE -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-send-email.perl: Fix handling of suppresscc option.
Jens Stimpfle deb...@jstimpfle.de writes:
Signed-off-by: Jens Stimpfle deb...@jstimpfle.de
---
Thanks.
Please do better than saying Fix to explain your changes in your
log message.
Also, on the Subject:, s/Fix/fix/; s/option./option/ to match other
entries in git shortlog message.
What you think is broken is clear (i.e. supresscc option is
broken) with the subject line alone, but How it is broken, How it
should behave instead, and What are the differences between the
broken and the correct behaviour should be explained in the log
message.
In other words, most of what you wrote below should come before your
S-o-b: line.
Notes:
...
diff --git a/git-send-email.perl b/git-send-email.perl
index 9949db0..452a783 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -1377,11 +1377,8 @@ foreach my $t (@files) {
foreach my $addr (parse_address_line($1)) {
my $qaddr = unquote_rfc2047($addr);
my $saddr = sanitize_address($qaddr);
- if ($saddr eq $sender) {
- next if ($suppress_cc{'self'});
- } else {
- next if ($suppress_cc{'cc'});
- }
+ next if $suppress_cc{'cc'};
+ next if $suppress_cc{'self'} and $saddr
eq $sender;
This smells more like a change in behaviour than bugfix from a
cursory look, though. It used to be that I could receive a copy by
adding me to cc as long as I did not suppress 'self', even I
squelched everybody else by suppressing 'cc'. I do not use such a
configuration myself but I wonder if people rely on this behaviour
as a feature.
@@ -1425,12 +1422,9 @@ foreach my $t (@files) {
my ($what, $c) = ($1, $2);
chomp $c;
my $sc = sanitize_address($c);
- if ($sc eq $sender) {
- next if ($suppress_cc{'self'});
- } else {
- next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
- next if $suppress_cc{'bodycc'} and $what =~
/Cc/i;
- }
+ next if $suppress_cc{'sob'} and $what =~
/Signed-off-by/i;
+ next if $suppress_cc{'bodycc'} and $what =~ /Cc/i;
+ next if $suppress_cc{'self'} and $sc eq $sender;
Likewise.
I do like the updated logic flow in both hunks, though.
When I say addresses on Cc: does not matter, it doesn't. No matter
what the address in question is (likewise for S-o-b:) is what the
updated logic says. It is easier to explain than the traditional
The way to squelch my address is by 'suppress self'; for all other
addresses on Cc:/S-o-b:, there are separate suppression methods.
But I have a slight suspicion that this special casing of 'self' was
done on purpose, and people may be relying 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: smudge filters during checkout crash consistency
Derek Moore derek.p.mo...@gmail.com writes: I have a case where I would like to smudge files according to the reflog information of the switching-to branch. Don't do that. When you have branches A, B and C, and a path F is the same between branches A and B but different in branch C, if you start from branch C and switch to branch A, F will be updated and obtain your smudge tailored for branch A's instance of F. But if you then switch to B from that state, F will not even be modified (i.e. it will keep the contents you prepared for branch A's instance of F). In short, do not make clean/smudge depend on anything but blob contents. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git docs typo - patch
Hello, i have a patch here for the git docs. There is a typo. See: https://github.com/git/git/pull/103/files cheers, - Joe DF-- To unsubscribe from this list: send the line 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: smudge filters during checkout crash consistency
Here's a solution that depends only/mostly on blob contents: 1) construct the ident of the blob via an `(echo -e -n blob size\0 ; cat file) | sha1sum` equivalent if an $Id$ string is not found in its contents, 2) look up the earliest commit with that blob hash at that path, and 3) use the reflog metadata from that earliest commit. Then when switching from C-to-A or C-to-B, F will have the same contents as a noop switch when switching A-to-B from C-to-A (although, conceivably, you may get a commit that is in neither A nor B, but you will have the earliest introduction of that file at that state). In other words, always use the earliest occurrence of a specific content at a given path, earliest commit wins irrespective of branches. Not the most elegant solution. I may have to go back and let these people know that outside of build scripts they can't get what they think they want. Thanks! :D On Wed, Nov 12, 2014 at 12:30 PM, Junio C Hamano gits...@pobox.com wrote: Derek Moore derek.p.mo...@gmail.com writes: I have a case where I would like to smudge files according to the reflog information of the switching-to branch. Don't do that. When you have branches A, B and C, and a path F is the same between branches A and B but different in branch C, if you start from branch C and switch to branch A, F will be updated and obtain your smudge tailored for branch A's instance of F. But if you then switch to B from that state, F will not even be modified (i.e. it will keep the contents you prepared for branch A's instance of F). In short, do not make clean/smudge depend on anything but blob contents. -- To unsubscribe from this list: send the line 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 docs typo - patch
On Wed, Nov 12, 2014 at 2:17 PM, Joe DF jo...@live.ca wrote: Hello, i have a patch here for the git docs. There is a typo. See: https://github.com/git/git/pull/103/files cheers, Thanks. This is fixed already [1] in the git master branch. [1]: http://thread.gmane.org/gmane.comp.version-control.git/259070 -- To unsubscribe from this list: send the line 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 docs typo - patch
On Wed, Nov 12, 2014 at 2:17 PM, Joe DF jo...@live.ca wrote: Hello, i have a patch here for the git docs. There is a typo. See: https://github.com/git/git/pull/103/files cheers, - Joe DF-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This was fixed just over a week ago in commit 03af7cd1580b7a4d9b77c81081d6eabc0338883e. Also, note that patches are submitted using 'git send-email' to this mailing list instead of pull requests via GitHub. Jason -- To unsubscribe from this list: send the line 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] t1410: fix breakage on case-insensitive filesystems
Am 09.11.2014 um 02:59 schrieb Jeff King:
test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '
- test_when_finished git branch -d a || git branch -d a/b
+ test_when_finished git branch -d one || git branch -d one/two
- git branch a/b master
- echo a/b@{0} branch: Created from master expect
- git log -g --format=%gd %gs a/b actual
+ git branch one/two master
+ echo one/two@{0} branch: Created from master expect
+ git log -g --format=%gd %gs one/two actual
test_cmp expect actual
- git branch -d a/b
+ git branch -d one/two
- # same as before, but we only create a reflog for a if
+ # same as before, but we only create a reflog for one if
# it already exists, which it does not
- git -c core.logallrefupdates=false branch a master
+ git -c core.logallrefupdates=false branch one master
: expect
- git log -g --format=%gd %gs a actual
+ git log -g --format=%gd %gs one actual
test_cmp expect actual
'
On Linux I observe
Deleted branch one/two (was b60a214).
warning: unable to unlink .git/logs/refs/heads/one: Is a directory
Deleted branch one (was b60a214).
ok 15 - stale dirs do not cause d/f conflicts (reflogs off)
(notice the warning) but on Windows the test fails with
Deleted branch one/two (was b60a214).
error: Unable to append to .git/logs/refs/heads/one: Permission denied
fatal: Cannot update the ref 'refs/heads/one'.
not ok 15 - stale dirs do not cause d/f conflicts (reflogs off)
On both systems, .git/logs/refs/heads/one exists as an empty directory
after the test.
I haven't dug further (will have to wait a day or two, so if you have
time or a hint where to look...)
-- 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: smudge filters during checkout crash consistency
But if you then switch to B from that state, F will not even be
modified (i.e. it will keep the contents you prepared for branch
A's instance of F).
Or: the post-commit hook used in the workaround looks up the prior
branch via @{-1}, finds all files common between @ @{-1} that don't
share a latest commit, deletes those files and replaces them singly
with the results of git-archive using the latest commits of those
files relative to @. (All files common between @ @{-1} would need
to be either all non-locally-modified files or making use of git-stash
{save,pop} to preserve local modifications.) All this assumes having
reversible $Format$ strings, so the clean filter can restore the
proper $Format$ string.
Might be worth doing just so there's at least 1 accurate and
maybe-fast git rcs keywords substitution using smudge/clean filters
project on github. ;) Otherwise, users of git-keyword-substitution
and git-rcs-keywords are being led astray.
--
To unsubscribe from this list: send the line 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] doc: add some crossrefs between manual pages
On 11.11.2014, at 23:51, Junio C Hamano gits...@pobox.com wrote: Max Horn m...@quendi.de writes: I did this because I was browsing the remote helper docs online quite a bit, and was wishing for some more direct links between the pages. While I can manyally edit the URL, it seems logical to offer these links directly. diff --git a/Documentation/git-fast-export.txt b/Documentation/git-fast-export.txt ... +linkgit:git-fast-import[1] diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt ... +linkgit:git-fast-export[1] Makes sense to have these pair refer to each other. diff --git a/Documentation/git-remote-ext.txt b/Documentation/git-remote-ext.txt ... +linkgit:gitremote-helpers[1] diff --git a/Documentation/git-remote-fd.txt b/Documentation/git-remote-fd.txt +linkgit:gitremote-helpers[1] Likewise. git-remote-* are instances of gitremote-helpers. diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt index 64f7ad2..8edf72c 100644 --- a/Documentation/gitremote-helpers.txt +++ b/Documentation/gitremote-helpers.txt @@ -452,8 +452,14 @@ SEE ALSO linkgit:git-remote[1] +linkgit:git-remote-ext[1] + +linkgit:git-remote-fd[1] + linkgit:git-remote-testgit[1] Makes sense. +linkgit:git-fast-import[1] This looks somewhat out of place; fast-import is not the only or even the primary way to do a remote-helper, is it? It depends on how you look at it, I'd say. If you write a remote-helper that uses the import/export feature, it is absolutely vital. All remote helpers I ever worked on are of that kind, so to me it is the primary way ;-), although of course I realize there are others. So, how would you determine which of the various methods is the primary one? In fact, this single link is the one that motivated me to write the whole patch; all the others were afterthoughts ;-). To elaborate on that: In the past, I did some work on various import/export remote-helpers; and I recall wishing for this precise link several times. More recently, I worked on some tweaks and fixes for Felipe's git-remote-hg. Whenever doing that, the place in the docs I start to refresh my memory on how remote helpers work is gitremote-helpers. But then at some point I realize ah wait, *that* particular bit is actually part of the fastimport protocol. So I need to look that up. And again and again thought dang, why isn't there a hyperlink for that here. Fact is, I need both man pages to understand what's going on. Now, clearly, I can live without that link. But I feel that there is a clear connection. And if you say it doesn't belong here because it is only relevant for one of multiple ways to do a remote-helper, then shouldn't one drop the links to git-remote-ext etc., too? After all, they are only examples for one of multiple ways, too... In other words, I find it arbitrary to exclude one link that is useful for some, but not all remote-helper authors, while adding some other links that are also useful for some, but not all remote-helper authors... That said, I certainly don't plan to hold that patch hostage to this one line. :-) Cheers, Max-- To unsubscribe from this list: send the line 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: smudge filters during checkout crash consistency
Derek Moore derek.p.mo...@gmail.com writes:
But if you then switch to B from that state, F will not even be
modified (i.e. it will keep the contents you prepared for branch
A's instance of F).
Or: the post-commit hook used in the workaround looks up the prior
branch via @{-1}, finds all files common between @ @{-1} that don't
share a latest commit, deletes those files and replaces them singly
with the results of git-archive using the latest commits of those
files relative to @. (All files common between @ @{-1} would need
to be either all non-locally-modified files or making use of git-stash
{save,pop} to preserve local modifications.) All this assumes having
reversible $Format$ strings, so the clean filter can restore the
proper $Format$ string.
Might be worth doing...
I still do not see what you are trying to record in the checked out
source files with your smudge filter, so I won't comment if it might
be worth doing.
Your use of reflog suggests me that whatever you are recording
depends on how you acquired your history in your specific repository
you work in, and your result is not reproducible by other people who
work with you by fetching from a repository that is different from
the repository you work in. E.g. perhaps you have a repository at
GitHub and push into there, and others fetch from there into their
repository. What is in their reflog has no relation to what you
have in your reflog.
That's the nature of distrubuted life. More generally, in a
distributred world with merges, even between two people who agree
that the tip of the 'master' branch of the project is at a certain
commit, there is no single sensible answer to the question which
commit changed this path last? We wouldn't mind anything you may
do to emulate RCS $Id$, but it would be futile.
--
To unsubscribe from this list: send the line 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] doc: add some crossrefs between manual pages
Max Horn m...@quendi.de writes: On 11.11.2014, at 23:51, Junio C Hamano gits...@pobox.com wrote: ... +linkgit:git-fast-import[1] This looks somewhat out of place; fast-import is not the only or even the primary way to do a remote-helper, is it? It depends on how you look at it, I'd say. If you write a remote-helper that uses the import/export feature, it is absolutely vital. All remote helpers I ever worked on are of that kind, so to me it is the primary way ;-), although of course I realize there are others. So, how would you determine which of the various methods is the primary one? You don't. If there exists no clear primary one, you do not have to designate a random one as the primary. I just thought that these references are to related/relevant pages in the same family of commands, and not a place to list possible implementation technologies. We do not say see also libcurl only because we have the curl-based remote helper that almost everybody uses to interact with other repositories over https:// URLs here, and do not list send-pack or receive-pack, even though the pair would be a natural way to implement 'fetch' and 'push' methods to a helper to interact with a native Git repository, either. -- To unsubscribe from this list: send the line 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] doc: add some crossrefs between manual pages
Junio C Hamano gits...@pobox.com writes: Max Horn m...@quendi.de writes: On 11.11.2014, at 23:51, Junio C Hamano gits...@pobox.com wrote: ... +linkgit:git-fast-import[1] This looks somewhat out of place; fast-import is not the only or even the primary way to do a remote-helper, is it? It depends on how you look at it, I'd say. If you write a remote-helper that uses the import/export feature, it is absolutely vital. All remote helpers I ever worked on are of that kind, so to me it is the primary way ;-), although of course I realize there are others. So, how would you determine which of the various methods is the primary one? You don't. If there exists no clear primary one, you do not have to designate a random one as the primary. I just thought that these references are to related/relevant pages in the same family of commands, and not a place to list possible implementation technologies. We do not say see also libcurl only because we have the curl-based remote helper that almost everybody uses to interact with other repositories over https:// URLs here, and do not list send-pack or receive-pack, even though the pair would be a natural way to implement 'fetch' and 'push' methods to a helper to interact with a native Git repository, either. Sorry, the final paragraph did not make it for some reason, which read like this: Having said that, we do seem to refer to fast-import quite extensively in the text of this manual page, so I think it is good to have a reference to its documentation at the bottom. So I am OK to special case fast-import and single it out as a notable implementation technology, which is what your patch does. 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: [PATCHv5 9/9] t3301: Modernize
Johan Herland jo...@herland.net writes:
On Wed, Nov 12, 2014 at 2:57 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland jo...@herland.net wrote:
+ test_line_count = 1 actual
Broken -chain. This problem is repeated each place use invoke
test_line_count().
Thanks. Fixed in the next iteration.
...Johan
Just FYI, here is what I came up with on top of 9/9 as 10/9, and it
can be squashed in. If these will be the only differences between
v5 and upcoming v6, you can just tell me to squash them together.
One unrelated changes is that '\'' is a bit shorter than ''' (and
the four-letter sequence is idiomatic and easier to spot, once your
eyes are used to reading strings in single-quote pairs).
Thanks.
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index 861c159..245406a 100755
--- a/t/t3301-notes.sh
+++ b/t/t3301-notes.sh
@@ -53,7 +53,7 @@ test_expect_success 'create notes' '
MSG=b4 git notes add
test_path_is_missing .git/NOTES_EDITMSG
git ls-tree -r refs/notes/commits actual
- test_line_count = 1 actual
+ test_line_count = 1 actual
test b4 = $(git notes show)
git show HEAD^
test_must_fail git notes show HEAD^
@@ -67,7 +67,7 @@ test_expect_success 'show notes entry with %N' '
test_expect_success 'create reflog entry' '
cat -EOF expect
- a1d8fa6 refs/notes/commits@{0}: notes: Notes added by '''git
notes add'''
+ a1d8fa6 refs/notes/commits@{0}: notes: Notes added by '\''git
notes add'\''
EOF
git reflog show refs/notes/commits actual
test_cmp expect actual
@@ -77,7 +77,7 @@ test_expect_success 'edit existing notes' '
MSG=b3 git notes edit
test_path_is_missing .git/NOTES_EDITMSG
git ls-tree -r refs/notes/commits actual
- test_line_count = 1 actual
+ test_line_count = 1 actual
test b3 = $(git notes show)
git show HEAD^
test_must_fail git notes show HEAD^
@@ -87,7 +87,7 @@ test_expect_success 'cannot git notes add -m where notes
already exists' '
test_must_fail git notes add -m b2
test_path_is_missing .git/NOTES_EDITMSG
git ls-tree -r refs/notes/commits actual
- test_line_count = 1 actual
+ test_line_count = 1 actual
test b3 = $(git notes show)
git show HEAD^
test_must_fail git notes show HEAD^
@@ -97,7 +97,7 @@ test_expect_success 'can overwrite existing note with git
notes add -f -m' '
git notes add -f -m b1
test_path_is_missing .git/NOTES_EDITMSG
git ls-tree -r refs/notes/commits actual
- test_line_count = 1 actual
+ test_line_count = 1 actual
test b1 = $(git notes show)
git show HEAD^
test_must_fail git notes show HEAD^
@@ -107,7 +107,7 @@ test_expect_success 'add w/no options on existing note
morphs into edit' '
MSG=b2 git notes add
test_path_is_missing .git/NOTES_EDITMSG
git ls-tree -r refs/notes/commits actual
- test_line_count = 1 actual
+ test_line_count = 1 actual
test b2 = $(git notes show)
git show HEAD^
test_must_fail git notes show HEAD^
@@ -117,7 +117,7 @@ test_expect_success 'can overwrite existing note with git
notes add -f' '
MSG=b1 git notes add -f
test_path_is_missing .git/NOTES_EDITMSG
git ls-tree -r refs/notes/commits actual
- test_line_count = 1 actual
+ test_line_count = 1 actual
test b1 = $(git notes show)
git show HEAD^
test_must_fail git notes show HEAD^
--
2.2.0-rc1-84-gcd6439f
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
mac test failure -- 2gb clone
This is in pu, haven't checked if it's also in master, this is the
first time I've run this test
$ GIT_TEST_CLONE_2GB=t ./t5705-clone-2gb.sh -v
Initialized empty Git repository in
/Users/michael.blume/workspace/git/t/trash
directory.t5705-clone-2gb/.git/
expecting success:
git config pack.compression 0
git config pack.depth 0
blobsize=$((100*1024*1024))
blobcount=$((2*1024*1024*1024/$blobsize+1))
i=1
(while test $i -le $blobcount
do
printf Generating blob $i/$blobcount\r 2
printf blob\nmark :$i\ndata $blobsize\n
#test-genrandom $i $blobsize
printf %-${blobsize}s $i
echo M 100644 :$i $i commit
i=$(($i+1)) ||
echo $? exit-status
done
echo commit refs/heads/master
echo author A U Thor aut...@email.com 123456789 +
echo committer C O Mitter commit...@email.com 123456789 +
echo data 5
echo 2gb
cat commit) |
git fast-import --big-file-threshold=2
test ! -f exit-status
git-fast-import statistics:
-
Alloc'd objects: 5000
Total objects: 23 ( 0 duplicates )
blobs : 21 ( 0 duplicates 0 deltas
of 0 attempts)
trees :1 ( 0 duplicates 0 deltas
of 0 attempts)
commits:1 ( 0 duplicates 0 deltas
of 0 attempts)
tags :0 ( 0 duplicates 0 deltas
of 0 attempts)
Total branches: 1 ( 1 loads )
marks: 1024 (21 unique)
atoms: 21
Memory total: 2344 KiB
pools: 2110 KiB
objects: 234 KiB
-
pack_report: getpagesize()= 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 8589934592
pack_report: pack_used_ctr= 2
pack_report: pack_mmap_calls = 1
pack_report: pack_open_windows= 1 / 1
pack_report: pack_mapped = 54863024 / 54863024
-
ok 1 - setup
expecting success:
git clone --bare --no-hardlinks . clone-bare
Cloning into bare repository 'clone-bare'...
done.
ok 2 - clone - bare
expecting success:
git clone file://. clone-wt
Cloning into 'clone-wt'...
fatal: No path specified. See 'man git-pull' for valid url syntax
not ok 3 - clone - with worktree, file:// protocol
#
#
# git clone file://. clone-wt
#
#
# failed 1 among 3 test(s)
1..3
--
To unsubscribe from this list: send the line 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] t1410: fix breakage on case-insensitive filesystems
On Wed, Nov 12, 2014 at 09:20:22PM +0100, Johannes Sixt wrote:
Am 09.11.2014 um 02:59 schrieb Jeff King:
test_expect_success 'stale dirs do not cause d/f conflicts (reflogs off)' '
- test_when_finished git branch -d a || git branch -d a/b
+ test_when_finished git branch -d one || git branch -d one/two
- git branch a/b master
- echo a/b@{0} branch: Created from master expect
- git log -g --format=%gd %gs a/b actual
+ git branch one/two master
+ echo one/two@{0} branch: Created from master expect
+ git log -g --format=%gd %gs one/two actual
test_cmp expect actual
- git branch -d a/b
+ git branch -d one/two
- # same as before, but we only create a reflog for a if
+ # same as before, but we only create a reflog for one if
# it already exists, which it does not
- git -c core.logallrefupdates=false branch a master
+ git -c core.logallrefupdates=false branch one master
: expect
- git log -g --format=%gd %gs a actual
+ git log -g --format=%gd %gs one actual
test_cmp expect actual
'
On Linux I observe
Deleted branch one/two (was b60a214).
warning: unable to unlink .git/logs/refs/heads/one: Is a directory
Deleted branch one (was b60a214).
ok 15 - stale dirs do not cause d/f conflicts (reflogs off)
(notice the warning)
Yes, this is expected. The warning actually comes from the git branch
-d run during cleanup. Branch one exists but has no reflog. Instead
there is a crufty dir call logs/refs/heads/one. The deletion process
blindly calls unlink on it and complains when it fails for reasons
other than ENOENT.
We could suppress that warning, but I didn't think it was really worth
the bother. This is such a funny setup (reflogs on, then off, then on,
_and_ a d/f conflict in the branches) that I doubt it will come up much.
I seem to recall that ancient versions of SunOS used to do bad things
when you called unlink on a directory, but I do not know if that is
still the case (I also would doubt this is the only place in git where
we blindly do an unlink if you can without actually checking the file.
but on Windows the test fails with
Deleted branch one/two (was b60a214).
error: Unable to append to .git/logs/refs/heads/one: Permission denied
fatal: Cannot update the ref 'refs/heads/one'.
not ok 15 - stale dirs do not cause d/f conflicts (reflogs off)
That looks more like it is failing the actual test (i.e., the creation
of branch one when there is cruft in the reflog). My guess is that
calling open() on a directory is giving us EACCES instead of EISDIR. Can
you verify that?
If that is the case, then this isn't a new breakage, I think, but just
code we weren't previously exercising. It would be interesting to know
whether:
git config core.logallrefupdates true
git branch one/two
git branch -d one/two
git branch one
works (even without my patch). If so, then there's probably something
else going on.
The relevant bits are in log_ref_setup. We try to open() once, and
accept EISDIR as a hint that we may need to remove an empty directory
and try again. If Windows gives us EACCES, then we may need to have that
trigger the same code.
-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: mac test failure -- 2gb clone
Confirmed exists on master
On Wed, Nov 12, 2014 at 1:57 PM, Michael Blume blume.m...@gmail.com wrote:
This is in pu, haven't checked if it's also in master, this is the
first time I've run this test
$ GIT_TEST_CLONE_2GB=t ./t5705-clone-2gb.sh -v
Initialized empty Git repository in
/Users/michael.blume/workspace/git/t/trash
directory.t5705-clone-2gb/.git/
expecting success:
git config pack.compression 0
git config pack.depth 0
blobsize=$((100*1024*1024))
blobcount=$((2*1024*1024*1024/$blobsize+1))
i=1
(while test $i -le $blobcount
do
printf Generating blob $i/$blobcount\r 2
printf blob\nmark :$i\ndata $blobsize\n
#test-genrandom $i $blobsize
printf %-${blobsize}s $i
echo M 100644 :$i $i commit
i=$(($i+1)) ||
echo $? exit-status
done
echo commit refs/heads/master
echo author A U Thor aut...@email.com 123456789 +
echo committer C O Mitter commit...@email.com 123456789 +
echo data 5
echo 2gb
cat commit) |
git fast-import --big-file-threshold=2
test ! -f exit-status
git-fast-import statistics:
-
Alloc'd objects: 5000
Total objects: 23 ( 0 duplicates )
blobs : 21 ( 0 duplicates 0 deltas
of 0 attempts)
trees :1 ( 0 duplicates 0 deltas
of 0 attempts)
commits:1 ( 0 duplicates 0 deltas
of 0 attempts)
tags :0 ( 0 duplicates 0 deltas
of 0 attempts)
Total branches: 1 ( 1 loads )
marks: 1024 (21 unique)
atoms: 21
Memory total: 2344 KiB
pools: 2110 KiB
objects: 234 KiB
-
pack_report: getpagesize()= 4096
pack_report: core.packedGitWindowSize = 1073741824
pack_report: core.packedGitLimit = 8589934592
pack_report: pack_used_ctr= 2
pack_report: pack_mmap_calls = 1
pack_report: pack_open_windows= 1 / 1
pack_report: pack_mapped = 54863024 / 54863024
-
ok 1 - setup
expecting success:
git clone --bare --no-hardlinks . clone-bare
Cloning into bare repository 'clone-bare'...
done.
ok 2 - clone - bare
expecting success:
git clone file://. clone-wt
Cloning into 'clone-wt'...
fatal: No path specified. See 'man git-pull' for valid url syntax
not ok 3 - clone - with worktree, file:// protocol
#
#
# git clone file://. clone-wt
#
#
# failed 1 among 3 test(s)
1..3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] builtin: move builtin retrieval to get_builtin()
Hi,
found a small code redundancy in a builtin command retrieval ('git.c').
For the master branch.
Thanks in advance for any suggestions.
Signed-off-by: slavomir vlcek s...@inventati.org
---
From 78228e3f7c3029d07827f973fa7992777d6e0cb9 Mon Sep 17 00:00:00 2001
From: slavomir vlcek s...@inventati.org
Date: Wed, 12 Nov 2014 14:10:22 +0100
Subject: [PATCH] builtin: move builtin retrieval to get_builtin()
There was a redundant code for a builtin command retrieval
in 'handle_builtin()' and 'is_builtin()'.
This was solved by adding a new function 'get_builtin()'
and by making a boolean wrapper out of the 'is_builtin()'.
---
git.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/git.c b/git.c
index 18fbf79..e32c5b8 100644
--- a/git.c
+++ b/git.c
@@ -487,15 +487,20 @@ static struct cmd_struct commands[] = {
{ write-tree, cmd_write_tree, RUN_SETUP },
};
-int is_builtin(const char *s)
+struct cmd_struct *get_builtin(const char *s)
{
int i;
for (i = 0; i ARRAY_SIZE(commands); i++) {
- struct cmd_struct *p = commands+i;
+ struct cmd_struct *p = commands + i;
if (!strcmp(s, p-cmd))
- return 1;
+ return p;
}
- return 0;
+ return NULL;
+}
+
+int is_builtin(const char *s)
+{
+ return !!get_builtin(s);
}
static void handle_builtin(int argc, const char **argv)
@@ -503,6 +508,7 @@ static void handle_builtin(int argc, const char **argv)
const char *cmd = argv[0];
int i;
static const char ext[] = STRIP_EXTENSION;
+ struct cmd_struct *builtin;
if (sizeof(ext) 1) {
i = strlen(argv[0]) - strlen(ext);
@@ -519,15 +525,12 @@ static void handle_builtin(int argc, const char **argv)
argv[0] = cmd = help;
}
- for (i = 0; i ARRAY_SIZE(commands); i++) {
- struct cmd_struct *p = commands+i;
- if (strcmp(p-cmd, cmd))
- continue;
- if (saved_environment (p-option NO_SETUP)) {
+ builtin = get_builtin(cmd);
+ if (builtin) {
+ if (saved_environment (builtin-option NO_SETUP))
restore_env();
- break;
- }
- exit(run_builtin(p, argc, argv));
+ else
+ exit(run_builtin(builtin, argc, argv));
}
}
--
2.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
TTY tests are unnecessarily suppressed under Mac OS
From lib_terminal.sh: # Reading from the pty master seems to get stuck _sometimes_ # on Mac OS X 10.5.0, using Perl 5.10.0 or 5.8.9. # # Reproduction recipe: run # # i=0 # while ./test-terminal.perl echo hi $i # do # : $((i = $i + 1)) # done # # After 2000 iterations or so it hangs. # https://rt.cpan.org/Ticket/Display.html?id=65692 # test $(uname -s) != Darwin I tried the reproduction recipe on my mac and couldn't reproduce, so it may make sense to take this switch out? In any case, I've set my automated mac build to include TTY tests -- To unsubscribe from this list: send the line 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] wincred: fix get credential if username has @
Signed-off-by: Aleksey Vasenev margtu-f...@ya.ru
---
.../credential/wincred/git-credential-wincred.c| 25 +++---
1 file changed, 22 insertions(+), 3 deletions(-)
diff --git a/contrib/credential/wincred/git-credential-wincred.c
b/contrib/credential/wincred/git-credential-wincred.c
index a1d38f0..0229443 100644
--- a/contrib/credential/wincred/git-credential-wincred.c
+++ b/contrib/credential/wincred/git-credential-wincred.c
@@ -111,14 +111,23 @@ static void write_item(const char *what, LPCWSTR wbuf,
int wlen)
* Match an (optional) expected string and a delimiter in the target string,
* consuming the matched text by updating the target pointer.
*/
-static int match_part(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim)
+
+LPCWSTR wcsstr_last(LPCWSTR str, LPCWSTR find)
+{
+ LPCWSTR res = NULL, pos;
+ for (pos = wcsstr(str, find); pos; pos = wcsstr(pos + 1, find))
+ res = pos;
+ return res;
+}
+
+static int match_part_with_last(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim,
int last)
{
LPCWSTR delim_pos, start = *ptarget;
int len;
/* find start of delimiter (or end-of-string if delim is empty) */
if (*delim)
- delim_pos = wcsstr(start, delim);
+ delim_pos = last ? wcsstr_last(start, delim) : wcsstr(start,
delim);
else
delim_pos = start + wcslen(start);
@@ -138,6 +147,16 @@ static int match_part(LPCWSTR *ptarget, LPCWSTR want,
LPCWSTR delim)
return !want || (!wcsncmp(want, start, len) !want[len]);
}
+static int match_part(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim)
+{
+ return match_part_with_last(ptarget, want, delim, 0);
+}
+
+static int match_part_last(LPCWSTR *ptarget, LPCWSTR want, LPCWSTR delim)
+{
+ return match_part_with_last(ptarget, want, delim, 1);
+}
+
static int match_cred(const CREDENTIALW *cred)
{
LPCWSTR target = cred-TargetName;
@@ -146,7 +165,7 @@ static int match_cred(const CREDENTIALW *cred)
return match_part(target, Lgit, L:)
match_part(target, protocol, L://)
- match_part(target, wusername, L@)
+ match_part_last(target, wusername, L@)
match_part(target, host, L/)
match_part(target, path, L);
}
--
1.9.4.msysgit.2
--
To unsubscribe from this list: send the line 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: [PATCHv5 9/9] t3301: Modernize
On Wed, Nov 12, 2014 at 10:18 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: On Wed, Nov 12, 2014 at 2:57 AM, Eric Sunshine sunsh...@sunshineco.com wrote: On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland jo...@herland.net wrote: + test_line_count = 1 actual Broken -chain. This problem is repeated each place use invoke test_line_count(). Thanks. Fixed in the next iteration. Just FYI, here is what I came up with on top of 9/9 as 10/9, and it can be squashed in. If these will be the only differences between v5 and upcoming v6, you can just tell me to squash them together. So far this is the only diff on top of v5. I've squashed it into my tree, so if a re-roll is needed, this diff will also be part of it. But if no other issues show up to trigger a re-roll, then please squash them on your end as well. One unrelated changes is that '\'' is a bit shorter than ''' (and the four-letter sequence is idiomatic and easier to spot, once your eyes are used to reading strings in single-quote pairs). Agreed, thanks. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SubmittingPatches: fix an inconsistency
The 'SubmittingPatches' document contains a small inconsistency in a patch-email sending procedure. Not a big thing, but a newcomer could get confused. Please, also consider adding the definition/explanation for all the branches available at the beginning of this document (and maybe even what their names stand for). Thanks. Signed-off-by: slavomir vlcek s...@inventati.org --- From 74859712cf805663e3863686bdc09511c74b207b Mon Sep 17 00:00:00 2001 From: slavomir vlcek s...@inventati.org Date: Thu, 13 Nov 2014 00:18:39 +0100 Subject: [PATCH] SubmittingPatches: fix an inconsistency At line 213 there was an instruction: re-send it with To: set to the maintainer [*1*] and cc: the list [*2*] and this instruction got repeated once more in the document (line 340): Send it to the list and cc the maintainer. This inconsistency was solved by editing the second occurance. --- Documentation/SubmittingPatches | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index e6d46ed..fa71b5f 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -337,7 +337,7 @@ suggests to the contributors: spend their time to improve your patch. Go back to step (2). (4) The list forms consensus that the last round of your patch is - good. Send it to the list and cc the maintainer. + good. Send it to the maintainer and cc the list. (5) A topic branch is created with the patch and is merged to 'next', and cooked further and eventually graduates to 'master'. -- 2.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
Bug: git log showing nothing when using --since and --until flags with specific dates
Hi all, Apologies if this has already been raised or PEBCAK, but I've noticed a bug where git log with certain date ranges breaks things. It appears to be any --since date with a --until date in the future between 2014-12-01 and 2014-12-09. Dates from 2014-12-10 appear to work, and so does the date 2015-12-01. Tested with the following versions: git version 2.2.0.rc1.18.gf6f61cb on Ubuntu git version 2.0.1 on whatever the latest version of OS X is. To reproduce, on a git repo with a recent enough change to view a checkin after October 1 2014, run 'git log --since=2014-10-01 --until=2014-12-02' - no errors or anything to indicate the command failed are shown, now run 'git log --since=2014-10-01 --until=2014-12-10'. Btw, the mail daemon appears to reject emails with '550 5.7.1 Content-Policy reject msg: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus. TEXT/PLAIN is accepted.! BF:U 0.499737; S1752168AbaKMAGd' - makes reporting bugs a bit of a hassle... Cheers, Colin Smith -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Set file modification time on checkout
The request is to allow git to set the file modification time on checkout to the commit-author-date of the commit which last modified the file. Yes I know this is in the FAQ, but the FAQ entry is missing an increasingly common use case: docker. When docker builds an image, it generates layers of images based on each build step. Adding a file would be a build step, and for this action it generates a hash based on the file modification time content. Next time the image is built, if these haven't changed, the previously built layer is reused. And like git commit history, if a layer changes, the hash of all subsequent layers change and have to be rebuilt. So reusing layers can save a ton of time. Now I'm not proposing that this be made the default action. The `make` use case is legitimate. But it would be nice to have an option for `checkout` and `reset` which toggles the behavior. -Patrick -- To unsubscribe from this list: send the line 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: Set file modification time on checkout
On 2014-11-13 05.45, Patrick Hemmer wrote: The request is to allow git to set the file modification time on checkout to the commit-author-date of the commit which last modified the file. Yes I know this is in the FAQ, but the FAQ entry is missing an increasingly common use case: docker. When docker builds an image, it generates layers of images based on each build step. Adding a file would be a build step, and for this action it generates a hash based on the file modification time content. Why do they do this? The file content is the only thing that matters. The other thing is to use a hook, utilizing test-chmtime from test-chmtime.c -- To unsubscribe from this list: send the line 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: mac test failure -- 2gb clone
On 2014-11-12 22.57, Michael Blume wrote: [t5705-clone-2gb.sh broken on Mac OS] It is most probably even broken on every platform, since we renovated the URL parser in 2013. (More info can be found here:) git log t/t5601-clone.sh I missed t5705-clone-2gb.sh, because it has its own enabler variable GIT_TEST_CLONE_2GB instead of using EXPENSIVE as other tests do. We can say that it as a regression that the URL file://. is no longer supported, and change it like this: diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh index e9783c3..a713118 100755 --- a/t/t5705-clone-2gb.sh +++ b/t/t5705-clone-2gb.sh @@ -46,7 +46,7 @@ test_expect_success CLONE_2GB 'clone - bare' ' test_expect_success CLONE_2GB 'clone - with worktree, file:// protocol' ' - git clone file://. clone-wt + git clone file://$(pwd) clone-wt ' Thanks for reporting. Does someone wants to send a patch for t5705-clone-2gb.sh ? -- To unsubscribe from this list: send the line 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] On watchman support
On 2014-11-11 13.49, Duy Nguyen wrote: I've come to the last piece to speed up git status, watchman support. And I realized it's not as good as I thought. Watchman could be used for two things: to avoid refreshing the index, and to avoid searching for ignored files. The first one can be done (with the patch below as demonstration). And it should keep refresh cost to near zero in the best case, the cost is proportional to the number of modified files. For avoiding searching for ignored files. My intention was to build on top of untracked cache. If watchman can tell me what files are added or deleted since last observed time, then I can invalidate just directories that contain them, or even better, calculate ignore status for those files only. This is important because in reality compilers and editors tend to update files by creating a new version then rename them, updating directory mtime and invalidating untracked cache as a consequence. As you edit more files (or your rebuild touches more dirs), untracked cache performance drops (until the next git status). The numbers I posted so far are the best case. The problem with watchman is it cannot tell me new files since the last observed time (let's say 'T'). If a file exists at 'T', gets deleted then recreated, then watchman tells me it's a new file. I want to separate those from ones that do not exist before 'T'. David's watchman approach does not have this problem because he keeps track of all entries under $GIT_WORK_TREE and knows which files are truely new. But I don't really want to keep the whole file list around, especially when watchman already manages the same list. So we got a few options: 1) Convince watchman devs to add something to make it work 2) Fork watchman 3) Make another daemon to keep file list around, or put it in a shared memory. 4) Move David's watchman series forward (and maybe make use of shared mem for fs_cache). 5) Go with something similar to the patch below and accept untracked cache performance degrades from time to time 6) ?? I'm working on 1). 2) is just bad taste, listed for completeness only. If we go with 3) and watchman starts to support Windows (seems to be in their plan), we'll need to rework some how. And I really don't like 3) If 1-3 does not work out, we're left without 4) and 5). We could support both, but proobably not worth the code complexity and should just go with one. And if we go with 4) we should probably think of dropping untracked cache if watchman will support Windows in the end. 4) also has another advantage over untracked cache, that it could speed up listing ignored files as well as untracked files. Comments? [remove the patch] From a Git user perspective it could be good to have something like this: a) git status -u b) git status -uno c) git status -umtime d) git status -uwatchman We know that a) and b) already exist. c) Can be convenient to have, in order to do benchmarking and testing. When the UNTR extension is not found, Git can give an error, saying something like this: No mtime information found, use git update-index --untracked-cache d) does not yet exist Of course we may want to configure the default for git status in a default variable, like status.findUntrackedFiles, which can be empty , mtime or watchman, and we may add other backends later. A short test showed that watchman compiles under Mac OS. The patch did not compile out of the box (both Git and watchman declare there own version of usage(), some C99 complaints from the compiler in watchman, nothing that can not be fixed easily) I will test the mtime patch under networked file systems the next weeks. The short version: Go with c), d) then 5) until we have something better :-) -- To unsubscribe from this list: send the line 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] t5705: Use the correct file:// URL
A URL like file;//. is (no longer) supported by Git: Typically there is no host, and RFC1738 says that file:///path should be used. Update t5705 to use a working URL. Reported-by: Michael Blume blume.m...@gmail.com Signed-off-by: Torsten Bögershausen tbo...@web.de --- t/t5705-clone-2gb.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5705-clone-2gb.sh b/t/t5705-clone-2gb.sh index e9783c3..191d6d3 100755 --- a/t/t5705-clone-2gb.sh +++ b/t/t5705-clone-2gb.sh @@ -46,7 +46,7 @@ test_expect_success CLONE_2GB 'clone - bare' ' test_expect_success CLONE_2GB 'clone - with worktree, file:// protocol' ' - git clone file://. clone-wt + git clone file://$(pwd) clone-wt ' -- 1.9.1.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
