[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:/// should be used. Update t5705 to use a working URL. Reported-by: Michael Blume Signed-off-by: Torsten Bögershausen --- 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
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
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: 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
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
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:; 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
[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 --- >From 74859712cf805663e3863686bdc09511c74b207b Mon Sep 17 00:00:00 2001 From: slavomir vlcek 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
Re: [PATCHv5 9/9] t3301: Modernize
On Wed, Nov 12, 2014 at 10:18 PM, Junio C Hamano wrote: > Johan Herland writes: >> On Wed, Nov 12, 2014 at 2:57 AM, Eric Sunshine >> wrote: >>> On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland 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, 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] wincred: fix get credential if username has @
Signed-off-by: Aleksey Vasenev
---
.../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, L"git", 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
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/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
---
>From 78228e3f7c3029d07827f973fa7992777d6e0cb9 Mon Sep 17 00:00:00 2001
From: slavomir vlcek
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
Re: mac test failure -- 2gb clone
Confirmed exists on master
On Wed, Nov 12, 2014 at 1:57 PM, Michael Blume 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 123456789 +" &&
> echo "committer C O Mitter 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
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 123456789 +" &&
echo "committer C O Mitter 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: [PATCHv5 9/9] t3301: Modernize
Johan Herland writes:
> On Wed, Nov 12, 2014 at 2:57 AM, Eric Sunshine
> wrote:
>> On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland 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
Re: [PATCH] doc: add some crossrefs between manual pages
Junio C Hamano writes: > Max Horn writes: > >> On 11.11.2014, at 23:51, Junio C Hamano 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: [PATCH] doc: add some crossrefs between manual pages
Max Horn writes: > On 11.11.2014, at 23:51, Junio C Hamano 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: smudge filters during checkout & crash consistency
Derek Moore 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
On 11.11.2014, at 23:51, Junio C Hamano wrote: > Max Horn 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
> 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] 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: git docs typo - patch
On Wed, Nov 12, 2014 at 2:17 PM, Joe DF 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: git docs typo - patch
On Wed, Nov 12, 2014 at 2:17 PM, Joe DF 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: 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 \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 wrote: > Derek Moore 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
Derek Moore 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: [PATCH] git-send-email.perl: Fix handling of suppresscc option.
Jens Stimpfle writes:
> Signed-off-by: Jens Stimpfle
> ---
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: 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 1/2] Add a few more values for receive.denyCurrentBranch
Johannes Schindelin 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: [PATCH 2/2] Let deny.currentBranch=updateInstead ignore submodules
Johannes Schindelin writes:
> Hi Junio,
>
> On Mon, 10 Nov 2014, Junio C Hamano wrote:
>
>> Junio C Hamano 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 " is what you
want to run when a push attempts to update the current branch from
sideways with updateInstead, and "reset --keep " lets
you run an equivalent of the "checkout -B " but you
do not have to know the name of the . 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-
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
[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 --- 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 '\n" "as appropriate to mark resolution and make a commit." msgstr "" "Korrigieren Sie dies im Arbeitsverzeichnis, und benutzen Sie\n" "dann 'git add/rm ', 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] [...]" @@ -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"
Re: [PATCH v2 1/2] Clean stale environment pointer in finish_command()
On Wed, Nov 12, 2014 at 2:59 AM, Jeff King 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
Re: tig: Improving startup time and interactivity
On Tue, Nov 11, 2014 at 3:50 AM, Dominik Vogt 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
[PATCH] git-send-email.perl: Fix handling of suppresscc option.
Signed-off-by: Jens Stimpfle
---
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 from line 'From: Jens
Stimpfle '
(body) Adding cc: Jens Stimpfle from line
'Signed-off-by: Jens Stimpfle '
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: [PATCH 1/2] Add a few more values for receive.denyCurrentBranch
Hi Junio, On Mon, 10 Nov 2014, Junio C Hamano wrote: > Johannes Schindelin 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
Re: [PATCH 2/2] Let deny.currentBranch=updateInstead ignore submodules
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
> Junio C Hamano 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 2/2] Let deny.currentBranch=updateInstead ignore submodules
Hi Junio,
On Mon, 10 Nov 2014, Junio C Hamano wrote:
> Johannes Schindelin 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 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 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()
Hi, On Tue, 11 Nov 2014, Junio C Hamano wrote: > Jeff King 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] 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 ..." to unstage)
- -#
- -# new file: closing.txt
- -#
- -# Changes not staged for commit:
- -# (use "git add ..." to update what will be committed)
- -#
- -# modified: file.txt
- -#
+On branch master
+Changes to be committed:
+ (use "git reset HEAD ..." to unstage)
+
+new file: closing.txt
+
+Changes not staged for commit:
+ (use "git add ..." to update what will be committed)
+ (use "git checkout -- ..." 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] 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 ..." 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 ..." 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: [PATCHv5 9/9] t3301: Modernize
On Wed, Nov 12, 2014 at 2:57 AM, Eric Sunshine wrote: > On Tue, Nov 11, 2014 at 7:40 PM, Johan Herland 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, 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
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 An: Thomas Ackermann 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
