Re: [PATCH v2] git-prompt: preserve value of $? inside shell prompt
SZEDER Gábor wrote: > > Makes sense, but the patch doesn't cover all cases, because > __git_ps1() can exit early Thanks for looking at the patch. I feel quite silly for missing the other return points :-( Follow-up patch on the way... Tony. -- f.anthony.n.finchhttp://dotat.at/ Faeroes, Southeast Iceland: Cyclonic for a time in Faeroes, otherwise northeasterly 6 to gale 8, increasing gale 8 to storm 10. Very rough or high. Rain, snow or wintry showers. Moderate or poor, occasionally very poor.
[PATCH] git-prompt: preserve value of $? in all cases
Signed-off-by: Tony Finch
---
contrib/completion/git-prompt.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-prompt.sh
index 3c3fc6d..3e70e74 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -288,6 +288,7 @@ __git_eread ()
# In this mode you can request colored hints using GIT_PS1_SHOWCOLORHINTS=true
__git_ps1 ()
{
+ # preserve exit status
local exit=$?
local pcmode=no
local detached=no
@@ -303,7 +304,7 @@ __git_ps1 ()
;;
0|1)printf_format="${1:-$printf_format}"
;;
- *) return
+ *) return $exit
;;
esac
@@ -355,7 +356,7 @@ __git_ps1 ()
#In PC mode PS1 always needs to be set
PS1="$ps1pc_start$ps1pc_end"
fi
- return
+ return $exit
fi
local short_sha
@@ -416,7 +417,7 @@ __git_ps1 ()
if [ $pcmode = yes ]; then
PS1="$ps1pc_start$ps1pc_end"
fi
- return
+ return $exit
fi
# is it a symbolic ref?
b="${head#ref: }"
@@ -513,6 +514,5 @@ __git_ps1 ()
printf -- "$printf_format" "$gitstring"
fi
- # preserve exit status
return $exit
}
--
2.2.1.68.g56d9796
--
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: How to prevent empty git commit --amend
Ivo Anjo writes: > Is there a way to prevent a *git commit --amend** with nothing to > commit from working? > If not, I would like to suggest that this feature would be very helpful :) I don't know any way to let Git do the check for you, but git diff --staged --quiet || git commit --amend should do it. You can alias it like [alias] amend = !git diff --staged --quiet || git commit --amend and then use "git amend". -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] t1050-large: replace dd by test-genrandom
On Tue, Jan 13, 2015 at 03:40:10PM -0800, Junio C Hamano wrote: > >> - test-genrandom seed2 250 >huge && > >> + printf "\0%250s" Y >huge && > [...] > Are we depending on the binary-ness of these test files by the way? > The leading NUL \0 looked a bit strange to me. I don't think so. We do not want to do a text diff, because that would overflow our GIT_ALLOC_LIMIT. But the core.bigfilethreshold check is what will make them binary, not the actual content. So a gigantic text file is arguably a better test of the feature in question. -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 v5 1/2] git-prompt.sh: if pc mode, immediately set PS1
Hi,
Quoting Richard Hansen :
At the beginning of __git_ps1, right after determining that the
function is running in pc mode, set PS1 to a plain (undecorated)
prompt. This makes it possible to simply return early without having
to set PS1 if the prompt should not be decorated.
Signed-off-by: Richard Hansen
---
contrib/completion/git-prompt.sh | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 729f769..b0de082 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -299,6 +299,10 @@ __git_ps1 ()
ps1pc_start="$1"
ps1pc_end="$2"
printf_format="${3:-$printf_format}"
+ # set PS1 to a plain prompt so that we can
+ # simply return early if the prompt should not
+ # be decorated
+ PS1="$ps1pc_start$ps1pc_end"
;;
0|1)printf_format="${1:-$printf_format}"
;;
@@ -350,10 +354,6 @@ __git_ps1 ()
rev_parse_exit_code="$?"
if [ -z "$repo_info" ]; then
- if [ $pcmode = yes ]; then
- #In PC mode PS1 always needs to be set
- PS1="$ps1pc_start$ps1pc_end"
- fi
return
fi
@@ -412,9 +412,6 @@ __git_ps1 ()
else
local head=""
if ! __git_eread "$g/HEAD" head; then
- if [ $pcmode = yes ]; then
- PS1="$ps1pc_start$ps1pc_end"
- fi
return
fi
# is it a symbolic ref?
--
2.2.1
As the one responsible for the last hunk I really like this change.
Thanks,
Gábor
--
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: commit --amend --author error
On Tue, Jan 13, 2015 at 12:24:18PM +0100, Michael J Gruber wrote: > Gunnar Wagner schrieb am 13.01.2015 um 09:15: > > I got APGL licensed code from someone else and want to post it on my > > github (without taking credit for the work) > > > > tried git commit --amend --author="Author name, www.website.com" but > > got an error message which said something like "original author not found" > > Can it be that the --amen --author only work if the author is on github > > himself? > > > > This has nothing to do with github. > > The author has be in the form "authorname ". The important > parts for the format are the <>. Yes, but the error message is a hint that there is something else going on. When there are no angle brackets, some DWIM magic kicks in: git tries to find a matching author by walking the project history from HEAD. So you can do (in git.git): $ git commit --allow-empty -m foo --author=gruber [detached HEAD 73ef08b] foo Author: Michael J Gruber Of course that does not work if you do not already have commits from the person in your repository: $ git commit --allow-empty -m foo --author=foobar fatal: No existing author found with 'foobar' -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] git-prompt: preserve value of $? in all cases
Hi,
Quoting Tony Finch :
Signed-off-by: Tony Finch
---
contrib/completion/git-prompt.sh | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
b/contrib/completion/git-prompt.sh
index 3c3fc6d..3e70e74 100644
--- a/contrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -288,6 +288,7 @@ __git_eread ()
# In this mode you can request colored hints using
GIT_PS1_SHOWCOLORHINTS=true
__git_ps1 ()
{
+ # preserve exit status
local exit=$?
local pcmode=no
local detached=no
@@ -303,7 +304,7 @@ __git_ps1 ()
;;
0|1)printf_format="${1:-$printf_format}"
;;
- *) return
+ *) return $exit
;;
esac
@@ -355,7 +356,7 @@ __git_ps1 ()
#In PC mode PS1 always needs to be set
PS1="$ps1pc_start$ps1pc_end"
fi
- return
+ return $exit
fi
local short_sha
@@ -416,7 +417,7 @@ __git_ps1 ()
if [ $pcmode = yes ]; then
PS1="$ps1pc_start$ps1pc_end"
fi
- return
+ return $exit
fi
# is it a symbolic ref?
b="${head#ref: }"
@@ -513,6 +514,5 @@ __git_ps1 ()
printf -- "$printf_format" "$gitstring"
fi
- # preserve exit status
return $exit
}
--
2.2.1.68.g56d9796
Thanks for the quick turnaround, looks good to me. I didn't remember
the early return in the second hunk.
I wonder whether we could test this behavior... but how could we set
$? and pass it to __git_ps1()?
Junio,
as far as I can judge from the last What's cooking and the relevant
patch emails on Gmane, this patch will have a textual conflict with
the first patch in 'rh/hide-prompt-in-ignored-directory'. While the
conflict is trivial (maybe git would even be able to resolve it by
itself?), the second patch in that series adds yet another early
return to __git_ps1(). Please be sure to add 'return $exit' when
merging.
Best,
Gábor
--
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
Big repo not shrinking on repack or gc?
Hi everybody, I have a repo here that is 130G, but when I clone --mirror it, the result is only 25G big. Because of the --mirror I don't think that I missed any refs that keep objects only in the source repo. I already tried 'git repack -fad' and 'git gc' to shrink the original repo, but it only shaved off 3G, and there are a lot of loose objects and old pack files that I simply don't expect to be there after a repack. Shouldn't 'git gc' (even without --aggressive) or a 'repack -fad' remove those redundant objects and packs? How to clean this up? (Additional problem: I don't have enough space to run a repack anymore.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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: How to prevent empty git commit --amend
Hello, On Wed, Jan 14, 2015 at 10:00 AM, Matthieu Moy wrote: > I don't know any way to let Git do the check for you, but > > git diff --staged --quiet || git commit --amend > > should do it. You can alias it like > > [alias] > amend = !git diff --staged --quiet || git commit --amend > > and then use "git amend". Genius! This is exactly what I wanted, thanks! Ivo Anjo -- 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: sporadic git failures on interactive rebase
On Tue, Jan 13, 2015 at 11:54:32AM +0100, Henning Moll wrote: > . error: short SHA1 c4095c1 is ambiguous. > . fatal: Needed a single revision > . Invalid commit name: c4095c1 > > Now that the command failed, i checked for ambigous c4095c1. But there is > only one: > $ git log -1 c4095c1 > . commit c4095c1f5e7c126accf93ba68e2fa72bb055f567 > . ... > > Just as a test: > $ git log -1 c409 > . error: short SHA1 c409 is ambiguous. > . error: short SHA1 c409 is ambiguous. Hmm. There are some instances in git where we know we are looking for an object of a particular type, and we can disambiguate a short-sha1 based on the type. And "git log" is just such a place, whereas a generic "git rev-parse" used by the git-rebase script would not be. Try: git rev-list --objects --all | grep ^c4095c1 | cut -d' ' -f1 | git cat-file --batch-check If my hunch is right, then you may find multiple objects, only one of which is a commit. And if so, the solution is likely one of: 1. Teach rev-parse a "prefer committish" option and use it in the appropriate spot in git-rebase. 2. Teach whatever is generating the shortended sha1s to report a truly unambiguous result, not one that depends on the type. I don't think we _have_ a codepath to do type-dependent shortening, though, which is maybe an indication that this is a red herring. It's also possible that part of the rebase sequence generates a new object that creates the ambiguity. That would be consistent with your statement that rolling back and running the commands again makes it work. I'm not sure how to defend against that, aside from adding a character or two to the shortened ids, which reduces the likelihood of a collision. -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: sporadic git failures on interactive rebase
On Wed, Jan 14, 2015 at 07:19:15AM -0500, Jeff King wrote: > Hmm. There are some instances in git where we know we are looking for an > object of a particular type, and we can disambiguate a short-sha1 based > on the type. And "git log" is just such a place, whereas a generic "git > rev-parse" used by the git-rebase script would not be. > [...] > I don't think > we _have_ a codepath to do type-dependent shortening, though, which > is maybe an indication that this is a red herring. Yeah, I think this cannot be it. There is a 7-character commit/blob ambiguity in git. You can find it yourself with: git rev-list --objects --all | cut -d' ' -f1 | sort | uniq -w 7 -D | git cat-file --batch-check | head -2 which produces: 01319837c53050109c60e6740dfa9462327161f0 commit 649 0131983dfbc143ce5dae77e067663bb2e7d5f126 blob 20638 And it behaves as expected. Running "git rev-parse 0131983" complains of the ambiguity, but "git log 0131983" shows the commit. What happens if we rebase with it? $ git checkout 01319837 $ git rebase -i HEAD^ will yield a todo file with the 8-character unambiguous abbreviation. So I guess all is working as intended there. Perhaps you really were just very unlucky and an earlier step of the rebase created a conflicting sha1. -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] standardize usage info string format
Alex Henrie writes: > This patch puts the usage info strings that were not already in docopt- > like format into docopt-like format, which will be a litle easier for > end users and a lot easier for translators. Changes include: > > - Placing angle brackets around fill-in-the-blank parameters > - Putting dashes in multiword parameter names > - Adding spaces to [-f|--foobar] to make [-f | --foobar] > - Replacing * with [...] I had a closer look and found it all good. Reviewed-by: Matthieu Moy Thanks! -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to prevent empty git commit --amend
Ivo Anjo writes: > Hello, > > On Wed, Jan 14, 2015 at 10:00 AM, Matthieu Moy > wrote: >> [alias] >> amend = !git diff --staged --quiet || git commit --amend >> >> and then use "git amend". > > Genius! This is exactly what I wanted, thanks! You probably want to tweak the alias by adding a && echo "Nothing to commit, sorry" (or an if/then/fi) after git diff to get the appropriate error message though. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Big repo not shrinking on repack or gc?
On Wed, Jan 14, 2015 at 12:51:30PM +0100, Andreas Krey wrote:
> I have a repo here that is 130G, but when I clone --mirror it, the result
> is only 25G big. Because of the --mirror I don't think that I missed
> any refs that keep objects only in the source repo.
Perhaps some objects are mentioned by reflogs, but not by the refs? They
would not be transferred as part of a clone. Try:
git rev-list --objects --all | cut -d' ' -f1 | sort >reachable
git rev-list --objects --reflog | cut -d' ' -f1 | sort >reflogs
comm -13 reachable reflogs |
git cat-file --batch-check='%(objectsize:disk)' |
perl -lne '$total += $_; END { print $total }'
That should print the size, in bytes, that reflog-only objects are using
on disk. You can use "git reflog expire --expire-unreachable=now --all"
to get rid of them (and then repack).
> I already tried 'git repack -fad' and 'git gc' to shrink the original repo,
You don't need the "-f" here. Just "git repack -ad" should be enough
(and the "-f" probably makes it _way_ slower).
-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: Big repo not shrinking on repack or gc?
On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote: > On Wed, Jan 14, 2015 at 12:51:30PM +0100, Andreas Krey wrote: > > > I have a repo here that is 130G, but when I clone --mirror it, the result > > is only 25G big. Because of the --mirror I don't think that I missed > > any refs that keep objects only in the source repo. > > Perhaps some objects are mentioned by reflogs, but not by the refs? They > would not be transferred as part of a clone. Try: > > git rev-list --objects --all | cut -d' ' -f1 | sort >reachable > git rev-list --objects --reflog | cut -d' ' -f1 | sort >reflogs Actually, the output of 'git rev-list --objects --reflog' is empty, and there isn't even a reflog (or similar) directory. (This is a bare repo inside atlass. stash.) ... > > I already tried 'git repack -fad' and 'git gc' to shrink the original repo, > > You don't need the "-f" here. Just "git repack -ad" should be enough > (and the "-f" probably makes it _way_ slower). Right, the -f is an old workaround for old jgits in another repo. Apparently, part of the trick is --prune=all or similar on 'git gc', to get rid of the loose objects faster. That got a copy of the repo down to around 70G - still way to go. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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: [ANNOUNCE] Git v2.3.0-rc0
Junio C Hamano writes: > * "git push" into a repository with a working tree normally refuses >to modify the branch that is checked out. The command learned to >optionally do an equivalent of "git reset --hard" only when there >is no change to the working tree and the index instead, which would >be useful to "deploy" by pushing into a repository. Perhaps this can mention "receive.denyCurrentBranch=updateInstead" so interested users won't have to grep the tree for 10min to find it. :) Thanks, -- Christian Neukirchenhttp://chneukirchen.org -- 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] blame.c: fix garbled error message
On Tue, 13 Jan 2015 at 02:54:27, Jeff King wrote: > On Mon, Jan 12, 2015 at 04:11:06PM -0800, Junio C Hamano wrote: > > > Jeff King writes: > > > > > As an aside, I have often been tempted to have xstrdup silently > > > propagate a NULL. It would have been the right thing to do here, but > > > maybe there are cases where the segfault is preferable for catching a > > > mistake early (otherwise you might store the NULL and then segfault much > > > later). > > > > Great minds think alike. The sentence after "but maybe ..." was > > what I had in mind as a response in anticipation that somebody might > > suggest that; a separate xstrdup_or_null() might be fine, but I'd > > rather not to have xstrdup() that is _too_ magical. > > Yeah. Of course, it is not _that_ many more characters to do a ternary > conditional. I guess the main benefit is that you do not have to repeat > the name of the variable (which lets you reuse a function result > directly, avoiding an explicit temporary). > > Here's my attempt. Some cases are a little nicer, but overall, it does > not feel significantly more readable to me. I dunno. I could go either > way. I stuck Lukas's patch on top (modified to use xstrdup_or_null), if > we do want to go that route. Otherwise it needs the ?: treatment. > > [1/5]: git-compat-util: add xstrdup_or_null helper > [2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup > [3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup > [4/5]: use xstrdup_or_null to replace ternary conditionals > [5/5]: blame.c: fix garbled error message > Looks good to me! I am not sure whether those patches should be built on top of (a fixed version of) my patch, though, which would make backporting the fix to the maintenance branch straightforward. Junio? -- 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: Big repo not shrinking on repack or gc?
On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote: ... > You don't need the "-f" here. Just "git repack -ad" should be enough > (and the "-f" probably makes it _way_ slower). Indeed, factor four. However, my expectation is that a repack -ad will remove all the old pack files, as what is in there is either referenced and put into the new pack, or dropped => there should be a single pack file afterwards. This is not the case. :-( (Done only with 1.8.2 due to lack of compilers for this box.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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
t5539 broken under Mac OS X
t5539 doesn't seem to work as expected under Mac OX X 10.6 (10.9 is OK) I am not root. Are there any ideas how we can improve the situation, or how to debug ? t> t> ./t5539-fetch-http-shallow.sh ; echo $? 1..0 # SKIP Cannot run httpd tests as root 0 t> t> GIT_TEST_HTTPD=t ./t5539-fetch-http-shallow.sh ; echo $? error: Cannot run httpd tests as root 1 t> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Big repo not shrinking on repack or gc?
On Wed, 14 Jan 2015 15:39:46 +, Andreas Krey wrote: ... > This is not the case. :-( (Done only with 1.8.2 due to > lack of compilers for this box.) Neither for current git (copied repo to other machine) There is one new pack file of a plausible size (25G), and 65G worth of old packfiles. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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: sporadic git failures on interactive rebase
Jeff King writes: > What happens if we rebase with it? > > $ git checkout 01319837 > $ git rebase -i HEAD^ > > will yield a todo file with the 8-character unambiguous abbreviation. > > So I guess all is working as intended there. Perhaps you really were > just very unlucky and an earlier step of the rebase created a > conflicting sha1. That would mean 75c69766 (rebase -i: fix short SHA-1 collision, 2013-08-23) did not fix what it intended to fix, no? Is the symptom coming from pre-1.8.4.2 version of Git? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] blame.c: fix garbled error message
Lukas Fleischer writes: >> [1/5]: git-compat-util: add xstrdup_or_null helper >> [2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup >> [3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup >> [4/5]: use xstrdup_or_null to replace ternary conditionals >> [5/5]: blame.c: fix garbled error message >> > > Looks good to me! I am not sure whether those patches should be built on > top of (a fixed version of) my patch, though, which would make > backporting the fix to the maintenance branch straightforward. Junio? We can queue these five on top of 1da1e07c (clean up name allocation in prepare_revision_walk, 2014-10-15), which changed the rule of the game to break this code, that only is in v2.2 and later. And the result should merge just fine to 'maint'. -- 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: Big repo not shrinking on repack or gc?
Andreas Krey writes: > On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote: > ... >> You don't need the "-f" here. Just "git repack -ad" should be enough >> (and the "-f" probably makes it _way_ slower). > > Indeed, factor four. > > However, my expectation is that a repack -ad will remove all the > old pack files, as what is in there is either referenced and put > into the new pack, or dropped => there should be a single pack file > afterwards. > > This is not the case. :-( (Done only with 1.8.2 due to > lack of compilers for this box.) Guess in the dark: "ls -l .git/objects/pack" Do you see any .keep files? -- 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: How to prevent empty git commit --amend
Matthieu Moy writes: > Ivo Anjo writes: > >> Is there a way to prevent a *git commit --amend** with nothing to >> commit from working? >> If not, I would like to suggest that this feature would be very helpful :) > > I don't know any way to let Git do the check for you, but > > git diff --staged --quiet || git commit --amend > > should do it. You can alias it like > > [alias] > amend = !git diff --staged --quiet || git commit --amend > > and then use "git amend". That would not let you say "git amend Makefile", no? !sh -c 'git diff --cached --quiet "$@" || git commit --amend "$@"' - or something, perhaps? -- 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] standardize usage info string format
Matthieu Moy writes: > Alex Henrie writes: > >> This patch puts the usage info strings that were not already in docopt- >> like format into docopt-like format, which will be a litle easier for >> end users and a lot easier for translators. Changes include: >> >> - Placing angle brackets around fill-in-the-blank parameters >> - Putting dashes in multiword parameter names >> - Adding spaces to [-f|--foobar] to make [-f | --foobar] >> - Replacing * with [...] > > I had a closer look and found it all good. > > Reviewed-by: Matthieu Moy > > Thanks! Thanks again. -- 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] t1050-large: replace dd by test-genrandom
Jeff King writes: > On Tue, Jan 13, 2015 at 03:40:10PM -0800, Junio C Hamano wrote: > >> >> - test-genrandom seed2 250 >huge && >> >> + printf "\0%250s" Y >huge && >> [...] >> Are we depending on the binary-ness of these test files by the way? >> The leading NUL \0 looked a bit strange to me. > > I don't think so. We do not want to do a text diff, because that would > overflow our GIT_ALLOC_LIMIT. But the core.bigfilethreshold check is > what will make them binary, not the actual content. So a gigantic text > file is arguably a better test of the feature in question. Perhaps. The original used "dd seek" primarily so that we can logically have large file without wasting diskspace, in addition to make sure that the result would compress well. The large printf will still waste the diskspace, but disks are cheap enough to tolerate a hanful of files of a few megabytes and you already made sure that the compressibility is what matters more to the test latency, so I think all is good. 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
[PATCH] init-db: use OPT__QUIET macro instead OPT_BIT
There is OPT__QUIET macro for easily -q/--quiet option defenition,
let's use it instead OPT_BIT
Signed-off-by: Alexander Kuleshov
---
builtin/init-db.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 280454a..a89343b 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -368,7 +368,7 @@ static void separate_git_dir(const char *git_dir)
write_file(git_link, 1, "gitdir: %s\n", git_dir);
}
-int init_db(const char *template_dir, unsigned int flags)
+int init_db(const char *template_dir, unsigned int quiet)
{
int reinit;
const char *git_dir = get_git_dir();
@@ -411,8 +411,7 @@ int init_db(const char *template_dir, unsigned int flags)
git_config_set("core.sharedrepository", buf);
git_config_set("receive.denyNonFastforwards", "true");
}
- if (!(flags & INIT_DB_QUIET)) {
+ if (!(quiet & INIT_DB_QUIET)) {
int len = strlen(git_dir);
/* TRANSLATORS: The first '%s' is either "Reinitialized
@@ -483,7 +482,7 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
const char *real_git_dir = NULL;
const char *work_tree;
const char *template_dir = NULL;
- unsigned int flags = 0;
+ unsigned int quiet = 0;
const struct option init_db_options[] = {
OPT_STRING(0, "template", &template_dir,
N_("template-directory"),
N_("directory from which templates will be
used")),
@@ -493,7 +492,7 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
N_("permissions"),
N_("specify that the git repository is to be shared
amongst several users"),
PARSE_OPT_OPTARG | PARSE_OPT_NONEG, shared_callback, 0},
- OPT_BIT('q', "quiet", &flags, N_("be quiet"), INIT_DB_QUIET),
+ OPT__QUIET(&quiet, N_("suppress progress reporting")),
OPT_STRING(0, "separate-git-dir", &real_git_dir, N_("gitdir"),
N_("separate git dir from working tree")),
OPT_END()
@@ -593,5 +592,5 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
set_git_dir_init(git_dir, real_git_dir, 1);
- return init_db(template_dir, flags);
+ return init_db(template_dir, quiet);
}
--
2.3.0.rc0.256.g17f147e
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation/init-db.txt: minor style and synopsys fixes
This patch constists of two minor changes: * line-wrap 'git init-db' synopsis * last possible argument '[directory]' was missed Signed-off-by: Alexander Kuleshov --- Documentation/git-init-db.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt index 648a6cd..1d94fe8 100644 --- a/Documentation/git-init-db.txt +++ b/Documentation/git-init-db.txt @@ -9,8 +9,9 @@ git-init-db - Creates an empty Git repository SYNOPSIS [verse] -'git init-db' [-q | --quiet] [--bare] [--template=] [--separate-git-dir ] [--shared[=]] - +'git init-db' [-q | --quiet] [--bare] [--template=] + [--separate-git-dir ] + [--shared[=]] [directory] DESCRIPTION --- -- 2.3.0.rc0.256.g0057d96 -- 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] diff: added '-q' option, short option for '--quiet'
Signed-off-by: Alexander Kuleshov --- Documentation/diff-options.txt | 1 + diff.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt index 2b15050..9160c90 100644 --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -491,6 +491,7 @@ ifndef::git-log[] That is, it exits with 1 if there were differences and 0 means no differences. +-q --quiet:: Disable all output of the program. Implies `--exit-code`. endif::git-log[] diff --git a/diff.c b/diff.c index 6ad8970..d778df7 100644 --- a/diff.c +++ b/diff.c @@ -3798,7 +3798,7 @@ int diff_opt_parse(struct diff_options *options, const char **av, int ac) } else if (!strcmp(arg, "--exit-code")) DIFF_OPT_SET(options, EXIT_WITH_STATUS); - else if (!strcmp(arg, "--quiet")) + else if (!strcmp(arg, "--quiet") || !strcmp(arg, "-q")) DIFF_OPT_SET(options, QUICK); else if (!strcmp(arg, "--ext-diff")) DIFF_OPT_SET(options, ALLOW_EXTERNAL); -- 2.3.0.rc0.256.gb0e92c0 -- 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: How to prevent empty git commit --amend
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Ivo Anjo writes:
>>
>>> Is there a way to prevent a *git commit --amend** with nothing to
>>> commit from working?
>>> If not, I would like to suggest that this feature would be very helpful :)
>>
>> I don't know any way to let Git do the check for you, but
>>
>> git diff --staged --quiet || git commit --amend
>>
>> should do it. You can alias it like
>>
>> [alias]
>> amend = !git diff --staged --quiet || git commit --amend
>>
>> and then use "git amend".
>
> That would not let you say "git amend Makefile", no?
>
> !sh -c 'git diff --cached --quiet "$@" || git commit --amend "$@"' -
>
> or something, perhaps?
Heh, not that but something like that ;-).
* If we have pathspec, we would want to see if the HEAD and the
working tree differ at the given paths;
* Otherwise we would want to see if the HEAD and the index differ.
So it would be more like this, I guess.
case "$#" in
0) git diff --quiet --cached ;;
*) git diff --quiet HEAD -- "$@" ;;
esac || git commit --amend ${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] stash: git stash create and git stash store added to git stash usage synopsys
Scott Schmit writes: [administrivia: please refrain from using Mail-follow-up-to] > On Tue, Jan 13, 2015 at 11:54:06PM +0600, Alexander Kuleshov wrote: >> Signed-off-by: Alexander Kuleshov >> --- >> git-stash.sh | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/git-stash.sh b/git-stash.sh >> index 6846b18..6e30380 100755 >> --- a/git-stash.sh >> +++ b/git-stash.sh >> @@ -9,7 +9,9 @@ USAGE="list [] >> or: $dashless branch [] >> or: $dashless [save [--patch] [-k|--[no-]keep-index] [-q|--quiet] >> [-u|--include-untracked] [-a|--all] []] >> - or: $dashless clear" >> + or: $dashless clear >> + or: $dashless create [] >> + or: $dashless store [-m|--message ] [-q|--quiet] " >> >> SUBDIRECTORY_OK=Yes >> OPTIONS_SPEC= > > Considering the man page says create & store are intended for scripts > and "probably not the command you want to use", why would we want it in > the synopsis? With the understanding that these are only for scripters, I think we can agree that we do want to describe them in the manual pages, and we do not want them in the completion. I feel "git stash -h" output is on the borderline, and can be argued both ways: - When you script and are not clear how a command you wanted to use in your script is to be used, it wouldn't be a crime to ask the short "git stash -h" form (instead of the full manual page "git stash --help") to remind how the command line ought to be spelled. - When you are not interested in script at all, from the command line you may want to be reminded how to spell the subcommand with "git stash -h" form. Having "store" listed, which will never be what you want in this scenario, will be confusing. You want to see "save". So, I dunno. -- 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] init-db: remove unused #includes
* "cache.h" - is unnecessary because it already included at "builtin.h" * "exec_cmd.h" - was added at a47d1813 (Allow a relative builtin template directory., 15 Nov 2007). init-db used 'git_exec_path' routine from "exec_cmd.h", but later it was removed at 2de9de5e (Move code interpreting path relative to exec-dir to new function system_path()., 14 Jul 2008). So we no need in it anymore. Signed-off-by: Alexander Kuleshov --- builtin/init-db.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/builtin/init-db.c b/builtin/init-db.c index 280454a..2978b36 100644 --- a/builtin/init-db.c +++ b/builtin/init-db.c @@ -3,9 +3,7 @@ * * Copyright (C) Linus Torvalds, 2005 */ -#include "cache.h" #include "builtin.h" -#include "exec_cmd.h" #include "parse-options.h" #ifndef DEFAULT_GIT_TEMPLATE_DIR -- 2.3.0.rc0.255.g53b80d0 -- 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] receive-pack.c: don't miss exporting unsolicited push certificates
Stefan Beller writes: > On Mon, Jan 12, 2015 at 11:07 AM, Junio C Hamano wrote: >>> >>> yes that's what I was trying to hint at. The hook would just see >>> it is unsolicited instead of not having the state available. >> >> OK. That makes sort of sense. So if we: >> >> 1) did not apply either patch (i.e. we accept unsolicited >> certificate, and the fact that we did not exchange "give me this >> nonce" "here is your nonce" is conveyed to the hooks by the lack >> of GIT_PUSH_CERT_NONCE environment and possible presense of >> unsolicited nonce in the GIT_PUSH_CERT blob); and then >> >> 2) applied this patch first (i.e. we still allow unsolicited >> certificate, and the same fact is now conveyed to the hooks also >> by GIT_PUSH_CERT_NONCE_STATUS=UNSOLICITED if they sent a nonce, >> or GIT_PUSH_CERT_NONCE_STATUS=MISSING); and then finally >> >> 3) applied the other patch to reject unsolicited certificate. >> >> then we can stop at any of these three steps and the behaviour of >> three resulting systems make sense and the pre-receive hook can >> reject unsolicited certificates if it wants to, even at step #1. > > I do not quite understand the intention of your mail. Are you saying I should > make a patch series to solve the problems as outlined above? Not really. All I was saying was that a hypothetical patch series that progressed in the order above would "make sort-of sense". I was hoping that readers would ask themselves this question: if we know that our endgame will be #3, then does it still make much sense to have the state that only patch #2 is applied? I think #3 makes #2 unnecessary, as we always ask for nonce when advertising push-cert capability in the released versions of Git, so we might get an unsolicited push-cert (which #3 will reject), but we will never see an unsolicited nonce in a push-cert, as long as we told the pusher that it is OK to send a push-cert to us. -- 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
Segmentation fault in git apply
This is a mac with a fresh build of git from pu branch, commit 53b80d0. With my gitconfig looking like [user] email = blume.m...@gmail.com name = Michael Blume [apply] whitespace = fix [core] whitespace = fix,trailing-space,space-before-tab, tab-in-indent, tabwidth=4 If I run git clone g...@github.com:MichaelBlume/clojure.git cd clojure git checkout origin/rebase-start git rebase origin/rebase-base I get src/jvm/clojure/lang/Compiler.java | 26 +- test/clojure/test_clojure/compilation.clj | 33 - test/clojure/test_clojure/compilation/examples_clj_1561.clj | 121 + 3 files changed, 170 insertions(+), 10 deletions(-) create mode 100644 test/clojure/test_clojure/compilation/examples_clj_1561.clj First, rewinding head to replay your work on top of it... Applying: CLJ-1603 - add reducible cycle, iterate, repeat Applying: CLJ-1515 Reify range Applying: CLJ-1499 Direct iterators for PersistentHashMap, APersistentSet, PersistentQueue, and PersistentStructMap, and records. Added new IMapIterable interface for key and val iterators. Applying: CLJ-1602 Make keys and vals return Iterable result Applying: fix AOT bug preventing overriding of clojure.core functions Applying: catch multiple rest forms Applying: zipmap using iterators and transient maps Applying: Define merge/merge-with after reduce has loaded Applying: very simple test of the merge function Applying: Support get on arbitrary java.util.List instances Applying: CLJ-1451 add take-until Applying: CLJ-1606 - complete eduction's xform without completing outer rfn Applying: add unrolled vector implementation Applying: add transient? predicate Applying: fix emitted line numbers Using index info to reconstruct a base tree... M src/jvm/clojure/lang/Compiler.java Falling back to patching base and 3-way merge... Auto-merging src/jvm/clojure/lang/Compiler.java Applying: just use a not Applying: trailing whitespace Applying: don't mix tabs/spaces in clojure.xml/emit-element Applying: avoid mixing tabs with spaces in clojure core code Applying: don't optimize for defrecord lookup if keyword is namespaced Applying: CLJ-1572 - Extend CollReduce to IReduceInit for supported arity Applying: unrolled impls for maps Applying: CLJ-703: Remove flush and sync calls when writing class files. Applying: CLJ-1078: Add queue and queue? to clojure.core Applying: make RT.boundedLength lazier Applying: first try for adding compare Applying: Fix for #CLJ-1565 Applying: CLJ-1074: Read +/- Infinity and NaN Applying: Fix CLJ-1074 for EdnReader too, see eaeda2e7bf2697e565decdf14a8a99fbf8588c57 Applying: add get-and-set! to expose AtomicReference.getAndSet() for atoms Applying: CLJ-1472 Locking macro without explicit monitor-enter, monitor-exit Applying: CLJ-1449: Add starts-with? ends-with? contains? to clojure.string Applying: if test expr of an if statement is a literal, don't emit the runtime test Applying: evaluate def symbol metadata only once Applying: CLJ-1295: Speed up dissoc on array-maps Applying: some throwing Applying: don't pass offset to ArrayChunk Applying: make EMPTY accessible Applying: add handy create methods Applying: regenerate Applying: regenerate /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 Segmentation fault: 11 git apply --index "$dotest/patch" > /dev/null 2>&1 /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:13: tab in indent. IPersistentVector v = (IPersistentVector) asTransient().conj(val) /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:14: tab in indent. .persistent(); /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:15: tab in indent. return (IPersistentVector) ((IObj) v).withMeta(meta); /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:25: tab in indent. ITransientCollection coll = PersistentVector.EMPTY /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:27: tab in indent. return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) warning: squelched 1 whitespace error warning: 6 lines add whitespace errors. Using index info to reconstruct a base tree... M src/jvm/clojure/lang/PersistentUnrolledVector.java :13: tab in indent. IPersistentVector v = (IPersistentVector) asTransient().conj(val) :14: tab in indent. .persistent(); :15: tab in indent. return (IPersistentVector) ((IObj) v).withMeta(meta); :25: tab in indent. ITransientCollection coll = PersistentVector.EMPTY :27: tab in indent. return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) warning: squelched 1 whitespace error warning: 6 lines applied after fixing whitespace errors. Falling back to patching base and 3-way merge... fatal: Unable to create '/Users/michael.blume/workspace/clojure/.git/index.lock': File exists. If no other git process is currently runnin
git ignores /~/.config/git/
git exludes /~/.config/git/ from the matching list. ~ is the name of a dir on the root of git working tree and not my user home dir. pgphhw3k02WET.pgp Description: PGP signature
Re: t5539 broken under Mac OS X
Torsten Bögershausen writes: > t5539 doesn't seem to work as expected under Mac OX X 10.6 > (10.9 is OK) > > I am not root. > Are there any ideas how we can improve the situation, or how to debug ? As to "how to debug", the first step is to grep for that message and notice that it comes from here: t/lib-httpd.sh: if ! test_have_prereq SANITY; then test_skip_or_die $GIT_TEST_HTTPD \ "Cannot run httpd tests as root" fi and then grep for SANITY to find: t/test-lib.sh: # When the tests are run as root, permission tests will report that # things are writable when they shouldn't be. test -w / || test_set_prereq SANITY It appears that the check in lib-httpd.sh thinks you lack SANITY; is the root directory of your system somehow writable by you? > > > t> > t> ./t5539-fetch-http-shallow.sh ; echo $? > > 1..0 # SKIP Cannot run httpd tests as root > 0 > t> > t> GIT_TEST_HTTPD=t ./t5539-fetch-http-shallow.sh ; echo $? > error: Cannot run httpd tests as root > 1 > t> -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Segmentation fault in git apply
On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume wrote: > This is a mac with a fresh build of git from pu branch, commit 53b80d0. > > With my gitconfig looking like > > [user] > email = blume.m...@gmail.com > name = Michael Blume > [apply] > whitespace = fix > [core] > whitespace = fix,trailing-space,space-before-tab, tab-in-indent, > tabwidth=4 > > If I run > git clone g...@github.com:MichaelBlume/clojure.git > cd clojure > git checkout origin/rebase-start > git rebase origin/rebase-base > > I get > > src/jvm/clojure/lang/Compiler.java | 26 > +- > test/clojure/test_clojure/compilation.clj | 33 > - > test/clojure/test_clojure/compilation/examples_clj_1561.clj | 121 > + > 3 files changed, 170 insertions(+), 10 deletions(-) > create mode 100644 > test/clojure/test_clojure/compilation/examples_clj_1561.clj > First, rewinding head to replay your work on top of it... > Applying: CLJ-1603 - add reducible cycle, iterate, repeat > Applying: CLJ-1515 Reify range > Applying: CLJ-1499 Direct iterators for PersistentHashMap, > APersistentSet, PersistentQueue, and PersistentStructMap, and records. > Added new IMapIterable interface for key and val iterators. > Applying: CLJ-1602 Make keys and vals return Iterable result > Applying: fix AOT bug preventing overriding of clojure.core functions > Applying: catch multiple rest forms > Applying: zipmap using iterators and transient maps > Applying: Define merge/merge-with after reduce has loaded > Applying: very simple test of the merge function > Applying: Support get on arbitrary java.util.List instances > Applying: CLJ-1451 add take-until > Applying: CLJ-1606 - complete eduction's xform without completing outer rfn > Applying: add unrolled vector implementation > Applying: add transient? predicate > Applying: fix emitted line numbers > Using index info to reconstruct a base tree... > M src/jvm/clojure/lang/Compiler.java > Falling back to patching base and 3-way merge... > Auto-merging src/jvm/clojure/lang/Compiler.java > Applying: just use a not > Applying: trailing whitespace > Applying: don't mix tabs/spaces in clojure.xml/emit-element > Applying: avoid mixing tabs with spaces in clojure core code > Applying: don't optimize for defrecord lookup if keyword is namespaced > Applying: CLJ-1572 - Extend CollReduce to IReduceInit for supported arity > Applying: unrolled impls for maps > Applying: CLJ-703: Remove flush and sync calls when writing class files. > Applying: CLJ-1078: Add queue and queue? to clojure.core > Applying: make RT.boundedLength lazier > Applying: first try for adding compare > Applying: Fix for #CLJ-1565 > Applying: CLJ-1074: Read +/- Infinity and NaN > Applying: Fix CLJ-1074 for EdnReader too, see > eaeda2e7bf2697e565decdf14a8a99fbf8588c57 > Applying: add get-and-set! to expose AtomicReference.getAndSet() for atoms > Applying: CLJ-1472 Locking macro without explicit monitor-enter, monitor-exit > Applying: CLJ-1449: Add starts-with? ends-with? contains? to clojure.string > Applying: if test expr of an if statement is a literal, don't emit the > runtime test > Applying: evaluate def symbol metadata only once > Applying: CLJ-1295: Speed up dissoc on array-maps > Applying: some throwing > Applying: don't pass offset to ArrayChunk > Applying: make EMPTY accessible > Applying: add handy create methods > Applying: regenerate > Applying: regenerate > /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 > Segmentation fault: 11 git apply --index "$dotest/patch" > /dev/null > 2>&1 > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:13: tab > in indent. >IPersistentVector v = (IPersistentVector) asTransient().conj(val) > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:14: tab > in indent. >.persistent(); > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:15: tab > in indent. >return (IPersistentVector) ((IObj) v).withMeta(meta); > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:25: tab > in indent. > ITransientCollection coll = PersistentVector.EMPTY > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:27: tab > in indent. > return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) > warning: squelched 1 whitespace error > warning: 6 lines add whitespace errors. > Using index info to reconstruct a base tree... > M src/jvm/clojure/lang/PersistentUnrolledVector.java > :13: tab in indent. >IPersistentVector v = (IPersistentVector) asTransient().conj(val) > :14: tab in indent. >.persistent(); > :15: tab in indent. >return (IPersistentVector) ((IObj) v).withMeta(meta); > :25: tab in indent. > ITransientCollection coll = PersistentVector.EMPTY > :27: tab in indent. > return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) > warn
Re: Segmentation fault in git apply
On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume wrote: > On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume wrote: >> This is a mac with a fresh build of git from pu branch, commit 53b80d0. >> >> With my gitconfig looking like >> >> [user] >> email = blume.m...@gmail.com >> name = Michael Blume >> [apply] >> whitespace = fix >> [core] >> whitespace = fix,trailing-space,space-before-tab, tab-in-indent, >> tabwidth=4 >> >> If I run >> git clone g...@github.com:MichaelBlume/clojure.git >> cd clojure >> git checkout origin/rebase-start >> git rebase origin/rebase-base >> >> I get >> >> src/jvm/clojure/lang/Compiler.java | 26 >> +- >> test/clojure/test_clojure/compilation.clj | 33 >> - >> test/clojure/test_clojure/compilation/examples_clj_1561.clj | 121 >> + >> 3 files changed, 170 insertions(+), 10 deletions(-) >> create mode 100644 >> test/clojure/test_clojure/compilation/examples_clj_1561.clj >> First, rewinding head to replay your work on top of it... >> Applying: CLJ-1603 - add reducible cycle, iterate, repeat >> Applying: CLJ-1515 Reify range >> Applying: CLJ-1499 Direct iterators for PersistentHashMap, >> APersistentSet, PersistentQueue, and PersistentStructMap, and records. >> Added new IMapIterable interface for key and val iterators. >> Applying: CLJ-1602 Make keys and vals return Iterable result >> Applying: fix AOT bug preventing overriding of clojure.core functions >> Applying: catch multiple rest forms >> Applying: zipmap using iterators and transient maps >> Applying: Define merge/merge-with after reduce has loaded >> Applying: very simple test of the merge function >> Applying: Support get on arbitrary java.util.List instances >> Applying: CLJ-1451 add take-until >> Applying: CLJ-1606 - complete eduction's xform without completing outer rfn >> Applying: add unrolled vector implementation >> Applying: add transient? predicate >> Applying: fix emitted line numbers >> Using index info to reconstruct a base tree... >> M src/jvm/clojure/lang/Compiler.java >> Falling back to patching base and 3-way merge... >> Auto-merging src/jvm/clojure/lang/Compiler.java >> Applying: just use a not >> Applying: trailing whitespace >> Applying: don't mix tabs/spaces in clojure.xml/emit-element >> Applying: avoid mixing tabs with spaces in clojure core code >> Applying: don't optimize for defrecord lookup if keyword is namespaced >> Applying: CLJ-1572 - Extend CollReduce to IReduceInit for supported arity >> Applying: unrolled impls for maps >> Applying: CLJ-703: Remove flush and sync calls when writing class files. >> Applying: CLJ-1078: Add queue and queue? to clojure.core >> Applying: make RT.boundedLength lazier >> Applying: first try for adding compare >> Applying: Fix for #CLJ-1565 >> Applying: CLJ-1074: Read +/- Infinity and NaN >> Applying: Fix CLJ-1074 for EdnReader too, see >> eaeda2e7bf2697e565decdf14a8a99fbf8588c57 >> Applying: add get-and-set! to expose AtomicReference.getAndSet() for atoms >> Applying: CLJ-1472 Locking macro without explicit monitor-enter, monitor-exit >> Applying: CLJ-1449: Add starts-with? ends-with? contains? to clojure.string >> Applying: if test expr of an if statement is a literal, don't emit the >> runtime test >> Applying: evaluate def symbol metadata only once >> Applying: CLJ-1295: Speed up dissoc on array-maps >> Applying: some throwing >> Applying: don't pass offset to ArrayChunk >> Applying: make EMPTY accessible >> Applying: add handy create methods >> Applying: regenerate >> Applying: regenerate >> /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 >> Segmentation fault: 11 git apply --index "$dotest/patch" > /dev/null >> 2>&1 >> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:13: tab >> in indent. >>IPersistentVector v = (IPersistentVector) asTransient().conj(val) >> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:14: tab >> in indent. >>.persistent(); >> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:15: tab >> in indent. >>return (IPersistentVector) ((IObj) v).withMeta(meta); >> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:25: tab >> in indent. >> ITransientCollection coll = PersistentVector.EMPTY >> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:27: tab >> in indent. >> return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) >> warning: squelched 1 whitespace error >> warning: 6 lines add whitespace errors. >> Using index info to reconstruct a base tree... >> M src/jvm/clojure/lang/PersistentUnrolledVector.java >> :13: tab in indent. >>IPersistentVector v = (IPersistentVector) asTransient().conj(val) >> :14: tab in indent. >>.persistent(); >> :15: tab in indent. >>return (IPersistentVector) ((IObj) v).withMeta(meta
Re: Segmentation fault in git apply
On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume wrote: > On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume wrote: >> On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume wrote: >>> This is a mac with a fresh build of git from pu branch, commit 53b80d0. >>> >>> With my gitconfig looking like >>> >>> [user] >>> email = blume.m...@gmail.com >>> name = Michael Blume >>> [apply] >>> whitespace = fix >>> [core] >>> whitespace = fix,trailing-space,space-before-tab, tab-in-indent, >>> tabwidth=4 >>> >>> If I run >>> git clone g...@github.com:MichaelBlume/clojure.git >>> cd clojure >>> git checkout origin/rebase-start >>> git rebase origin/rebase-base >>> >>> I get >>> >>> src/jvm/clojure/lang/Compiler.java | 26 >>> +- >>> test/clojure/test_clojure/compilation.clj | 33 >>> - >>> test/clojure/test_clojure/compilation/examples_clj_1561.clj | 121 >>> + >>> 3 files changed, 170 insertions(+), 10 deletions(-) >>> create mode 100644 >>> test/clojure/test_clojure/compilation/examples_clj_1561.clj >>> First, rewinding head to replay your work on top of it... >>> Applying: CLJ-1603 - add reducible cycle, iterate, repeat >>> Applying: CLJ-1515 Reify range >>> Applying: CLJ-1499 Direct iterators for PersistentHashMap, >>> APersistentSet, PersistentQueue, and PersistentStructMap, and records. >>> Added new IMapIterable interface for key and val iterators. >>> Applying: CLJ-1602 Make keys and vals return Iterable result >>> Applying: fix AOT bug preventing overriding of clojure.core functions >>> Applying: catch multiple rest forms >>> Applying: zipmap using iterators and transient maps >>> Applying: Define merge/merge-with after reduce has loaded >>> Applying: very simple test of the merge function >>> Applying: Support get on arbitrary java.util.List instances >>> Applying: CLJ-1451 add take-until >>> Applying: CLJ-1606 - complete eduction's xform without completing outer rfn >>> Applying: add unrolled vector implementation >>> Applying: add transient? predicate >>> Applying: fix emitted line numbers >>> Using index info to reconstruct a base tree... >>> M src/jvm/clojure/lang/Compiler.java >>> Falling back to patching base and 3-way merge... >>> Auto-merging src/jvm/clojure/lang/Compiler.java >>> Applying: just use a not >>> Applying: trailing whitespace >>> Applying: don't mix tabs/spaces in clojure.xml/emit-element >>> Applying: avoid mixing tabs with spaces in clojure core code >>> Applying: don't optimize for defrecord lookup if keyword is namespaced >>> Applying: CLJ-1572 - Extend CollReduce to IReduceInit for supported arity >>> Applying: unrolled impls for maps >>> Applying: CLJ-703: Remove flush and sync calls when writing class files. >>> Applying: CLJ-1078: Add queue and queue? to clojure.core >>> Applying: make RT.boundedLength lazier >>> Applying: first try for adding compare >>> Applying: Fix for #CLJ-1565 >>> Applying: CLJ-1074: Read +/- Infinity and NaN >>> Applying: Fix CLJ-1074 for EdnReader too, see >>> eaeda2e7bf2697e565decdf14a8a99fbf8588c57 >>> Applying: add get-and-set! to expose AtomicReference.getAndSet() for atoms >>> Applying: CLJ-1472 Locking macro without explicit monitor-enter, >>> monitor-exit >>> Applying: CLJ-1449: Add starts-with? ends-with? contains? to clojure.string >>> Applying: if test expr of an if statement is a literal, don't emit the >>> runtime test >>> Applying: evaluate def symbol metadata only once >>> Applying: CLJ-1295: Speed up dissoc on array-maps >>> Applying: some throwing >>> Applying: don't pass offset to ArrayChunk >>> Applying: make EMPTY accessible >>> Applying: add handy create methods >>> Applying: regenerate >>> Applying: regenerate >>> /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 >>> Segmentation fault: 11 git apply --index "$dotest/patch" > /dev/null >>> 2>&1 >>> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:13: tab >>> in indent. >>>IPersistentVector v = (IPersistentVector) asTransient().conj(val) >>> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:14: tab >>> in indent. >>>.persistent(); >>> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:15: tab >>> in indent. >>>return (IPersistentVector) ((IObj) v).withMeta(meta); >>> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:25: tab >>> in indent. >>> ITransientCollection coll = PersistentVector.EMPTY >>> /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:27: tab >>> in indent. >>> return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) >>> warning: squelched 1 whitespace error >>> warning: 6 lines add whitespace errors. >>> Using index info to reconstruct a base tree... >>> M src/jvm/clojure/lang/PersistentUnrolledVector.java >>> :13: tab in indent. >>>IPersistentVector v =
Re: Segmentation fault in git apply
Michael Blume writes: > This is a mac with a fresh build of git from pu branch, commit 53b80d0. Hmm, I do not see anything suspicious between master and pu. Is it possible to bisect? -- 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] diff: added '-q' option, short option for '--quiet'
Alexander Kuleshov writes: > Signed-off-by: Alexander Kuleshov > --- > Documentation/diff-options.txt | 1 + > diff.c | 2 +- > 2 files changed, 2 insertions(+), 1 deletion(-) I think we have deliberately refrained from doing this, as it will make "git diff" inconsistent with the underlying "git diff-fiels". > > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt > index 2b15050..9160c90 100644 > --- a/Documentation/diff-options.txt > +++ b/Documentation/diff-options.txt > @@ -491,6 +491,7 @@ ifndef::git-log[] > That is, it exits with 1 if there were differences and > 0 means no differences. > > +-q > --quiet:: > Disable all output of the program. Implies `--exit-code`. > endif::git-log[] > diff --git a/diff.c b/diff.c > index 6ad8970..d778df7 100644 > --- a/diff.c > +++ b/diff.c > @@ -3798,7 +3798,7 @@ int diff_opt_parse(struct diff_options *options, const > char **av, int ac) > } > else if (!strcmp(arg, "--exit-code")) > DIFF_OPT_SET(options, EXIT_WITH_STATUS); > - else if (!strcmp(arg, "--quiet")) > + else if (!strcmp(arg, "--quiet") || !strcmp(arg, "-q")) > DIFF_OPT_SET(options, QUICK); > else if (!strcmp(arg, "--ext-diff")) > DIFF_OPT_SET(options, ALLOW_EXTERNAL); -- 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: Segmentation fault in git apply
On Wed, Jan 14, 2015 at 10:48 AM, Michael Blume wrote: > On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume wrote: >> On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume wrote: >>> On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume >>> wrote: This is a mac with a fresh build of git from pu branch, commit 53b80d0. With my gitconfig looking like [user] email = blume.m...@gmail.com name = Michael Blume [apply] whitespace = fix [core] whitespace = fix,trailing-space,space-before-tab, tab-in-indent, tabwidth=4 If I run git clone g...@github.com:MichaelBlume/clojure.git cd clojure git checkout origin/rebase-start git rebase origin/rebase-base I get src/jvm/clojure/lang/Compiler.java | 26 +- test/clojure/test_clojure/compilation.clj | 33 - test/clojure/test_clojure/compilation/examples_clj_1561.clj | 121 + 3 files changed, 170 insertions(+), 10 deletions(-) create mode 100644 test/clojure/test_clojure/compilation/examples_clj_1561.clj First, rewinding head to replay your work on top of it... Applying: CLJ-1603 - add reducible cycle, iterate, repeat Applying: CLJ-1515 Reify range Applying: CLJ-1499 Direct iterators for PersistentHashMap, APersistentSet, PersistentQueue, and PersistentStructMap, and records. Added new IMapIterable interface for key and val iterators. Applying: CLJ-1602 Make keys and vals return Iterable result Applying: fix AOT bug preventing overriding of clojure.core functions Applying: catch multiple rest forms Applying: zipmap using iterators and transient maps Applying: Define merge/merge-with after reduce has loaded Applying: very simple test of the merge function Applying: Support get on arbitrary java.util.List instances Applying: CLJ-1451 add take-until Applying: CLJ-1606 - complete eduction's xform without completing outer rfn Applying: add unrolled vector implementation Applying: add transient? predicate Applying: fix emitted line numbers Using index info to reconstruct a base tree... M src/jvm/clojure/lang/Compiler.java Falling back to patching base and 3-way merge... Auto-merging src/jvm/clojure/lang/Compiler.java Applying: just use a not Applying: trailing whitespace Applying: don't mix tabs/spaces in clojure.xml/emit-element Applying: avoid mixing tabs with spaces in clojure core code Applying: don't optimize for defrecord lookup if keyword is namespaced Applying: CLJ-1572 - Extend CollReduce to IReduceInit for supported arity Applying: unrolled impls for maps Applying: CLJ-703: Remove flush and sync calls when writing class files. Applying: CLJ-1078: Add queue and queue? to clojure.core Applying: make RT.boundedLength lazier Applying: first try for adding compare Applying: Fix for #CLJ-1565 Applying: CLJ-1074: Read +/- Infinity and NaN Applying: Fix CLJ-1074 for EdnReader too, see eaeda2e7bf2697e565decdf14a8a99fbf8588c57 Applying: add get-and-set! to expose AtomicReference.getAndSet() for atoms Applying: CLJ-1472 Locking macro without explicit monitor-enter, monitor-exit Applying: CLJ-1449: Add starts-with? ends-with? contains? to clojure.string Applying: if test expr of an if statement is a literal, don't emit the runtime test Applying: evaluate def symbol metadata only once Applying: CLJ-1295: Speed up dissoc on array-maps Applying: some throwing Applying: don't pass offset to ArrayChunk Applying: make EMPTY accessible Applying: add handy create methods Applying: regenerate Applying: regenerate /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 Segmentation fault: 11 git apply --index "$dotest/patch" > /dev/null 2>&1 /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:13: tab in indent. IPersistentVector v = (IPersistentVector) asTransient().conj(val) /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:14: tab in indent. .persistent(); /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:15: tab in indent. return (IPersistentVector) ((IObj) v).withMeta(meta); /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:25: tab in indent. ITransientCollection coll = PersistentVector.EMPTY /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:27: tab in indent. return (ITransientVector) coll.conj(e0).conj(e1).conj(e2) warning: squelched 1 whitespace error warning: 6 lines add whitespace err
Re: [PATCH] bash completion: allow git stash store options completion
On Tue, Jan 13, 2015 at 10:40:40AM -0800, Junio C Hamano wrote: Alexander Kuleshov writes: This patch adds bash completion for git stash 'store' subcommand which apperead at bd514cad (stash: introduce 'git stash store', 18 Jun 2013) Signed-off-by: Alexander Kuleshov --- Hmph. The "create" and "store" subcommands are not end-user facing; they are meant to be used in scripts. I am not sure if we want to complete them in the first place. I know "create" already is in the list of completion candidates, but I wonder if adding "store" is making things worse. For what it's worth, I'll often sketch out a script at the command line before putting it in a file (either because I realize I'll need to do the same thing again or I want to share it with others), so I think this might be a useful addition. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] init-db: use OPT__QUIET macro instead OPT_BIT
Alexander Kuleshov writes:
> There is OPT__QUIET macro for easily -q/--quiet option defenition,
> let's use it instead OPT_BIT
>
> Signed-off-by: Alexander Kuleshov
> ---
> builtin/init-db.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
This is questionable for three reasons.
- OPT__QUIET() takes an integer and counts up; a single -q and
double -q -q will give different values to the given variable so
that the user can express varying levels of quietness. You can
no longer check the value with "& INIT_DB_QUIET".
- We did "flags" very deliberately because we wanted to make sure
we do not have to add different parameters to init_db() every
time we wanted a new small knob to tweak its operation like
"quiet", "verbose", etc.
- We have been trying to move away from OPT__VERBOSE() and
OPT__QUIET() to OPT__VERBOSITY(), so that we can handle
combinations of --quiet and --verbose on the command line in a
more sensible manner.
I am OK if you switched to OPT__VERBOSITY(), in anticipation of more
verbose output from the command in the future, though.
> diff --git a/builtin/init-db.c b/builtin/init-db.c
> index 280454a..a89343b 100644
> --- a/builtin/init-db.c
> +++ b/builtin/init-db.c
> @@ -368,7 +368,7 @@ static void separate_git_dir(const char *git_dir)
> write_file(git_link, 1, "gitdir: %s\n", git_dir);
> }
>
> -int init_db(const char *template_dir, unsigned int flags)
> +int init_db(const char *template_dir, unsigned int quiet)
> {
> int reinit;
> const char *git_dir = get_git_dir();
> @@ -411,8 +411,7 @@ int init_db(const char *template_dir, unsigned int flags)
> git_config_set("core.sharedrepository", buf);
> git_config_set("receive.denyNonFastforwards", "true");
> }
> - if (!(flags & INIT_DB_QUIET)) {
> + if (!(quiet & INIT_DB_QUIET)) {
--
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: Segmentation fault in git apply
On Wed, Jan 14, 2015 at 10:58 AM, Michael Blume wrote: > On Wed, Jan 14, 2015 at 10:48 AM, Michael Blume wrote: >> On Wed, Jan 14, 2015 at 10:44 AM, Michael Blume wrote: >>> On Wed, Jan 14, 2015 at 10:40 AM, Michael Blume >>> wrote: On Wed, Jan 14, 2015 at 10:20 AM, Michael Blume wrote: > This is a mac with a fresh build of git from pu branch, commit 53b80d0. > > With my gitconfig looking like > > [user] > email = blume.m...@gmail.com > name = Michael Blume > [apply] > whitespace = fix > [core] > whitespace = fix,trailing-space,space-before-tab, tab-in-indent, > tabwidth=4 > > If I run > git clone g...@github.com:MichaelBlume/clojure.git > cd clojure > git checkout origin/rebase-start > git rebase origin/rebase-base > > I get > > src/jvm/clojure/lang/Compiler.java | 26 > +- > test/clojure/test_clojure/compilation.clj | 33 > - > test/clojure/test_clojure/compilation/examples_clj_1561.clj | 121 > + > 3 files changed, 170 insertions(+), 10 deletions(-) > create mode 100644 > test/clojure/test_clojure/compilation/examples_clj_1561.clj > First, rewinding head to replay your work on top of it... > Applying: CLJ-1603 - add reducible cycle, iterate, repeat > Applying: CLJ-1515 Reify range > Applying: CLJ-1499 Direct iterators for PersistentHashMap, > APersistentSet, PersistentQueue, and PersistentStructMap, and records. > Added new IMapIterable interface for key and val iterators. > Applying: CLJ-1602 Make keys and vals return Iterable result > Applying: fix AOT bug preventing overriding of clojure.core functions > Applying: catch multiple rest forms > Applying: zipmap using iterators and transient maps > Applying: Define merge/merge-with after reduce has loaded > Applying: very simple test of the merge function > Applying: Support get on arbitrary java.util.List instances > Applying: CLJ-1451 add take-until > Applying: CLJ-1606 - complete eduction's xform without completing outer > rfn > Applying: add unrolled vector implementation > Applying: add transient? predicate > Applying: fix emitted line numbers > Using index info to reconstruct a base tree... > M src/jvm/clojure/lang/Compiler.java > Falling back to patching base and 3-way merge... > Auto-merging src/jvm/clojure/lang/Compiler.java > Applying: just use a not > Applying: trailing whitespace > Applying: don't mix tabs/spaces in clojure.xml/emit-element > Applying: avoid mixing tabs with spaces in clojure core code > Applying: don't optimize for defrecord lookup if keyword is namespaced > Applying: CLJ-1572 - Extend CollReduce to IReduceInit for supported arity > Applying: unrolled impls for maps > Applying: CLJ-703: Remove flush and sync calls when writing class files. > Applying: CLJ-1078: Add queue and queue? to clojure.core > Applying: make RT.boundedLength lazier > Applying: first try for adding compare > Applying: Fix for #CLJ-1565 > Applying: CLJ-1074: Read +/- Infinity and NaN > Applying: Fix CLJ-1074 for EdnReader too, see > eaeda2e7bf2697e565decdf14a8a99fbf8588c57 > Applying: add get-and-set! to expose AtomicReference.getAndSet() for atoms > Applying: CLJ-1472 Locking macro without explicit monitor-enter, > monitor-exit > Applying: CLJ-1449: Add starts-with? ends-with? contains? to > clojure.string > Applying: if test expr of an if statement is a literal, don't emit the > runtime test > Applying: evaluate def symbol metadata only once > Applying: CLJ-1295: Speed up dissoc on array-maps > Applying: some throwing > Applying: don't pass offset to ArrayChunk > Applying: make EMPTY accessible > Applying: add handy create methods > Applying: regenerate > Applying: regenerate > /Users/michael.blume/libexec/git-core/git-am: line 854: 92059 > Segmentation fault: 11 git apply --index "$dotest/patch" > /dev/null > 2>&1 > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:13: tab > in indent. >IPersistentVector v = (IPersistentVector) asTransient().conj(val) > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:14: tab > in indent. >.persistent(); > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:15: tab > in indent. >return (IPersistentVector) ((IObj) v).withMeta(meta); > /Users/michael.blume/workspace/clojure/.git/rebase-apply/patch:25: tab > in indent. > ITransientCollection coll = PersistentVector.EMPTY > /Users/michael.blume/workspace/clojure/.git/rebase-appl
Re: [PATCH] init-db: remove unused #includes
Alexander Kuleshov writes: > * "cache.h" - is unnecessary because it already included at "builtin.h" > > * "exec_cmd.h" - was added at a47d1813 (Allow a relative builtin template > directory., 15 Nov 2007). init-db used 'git_exec_path' routine from > "exec_cmd.h", but later it was removed at 2de9de5e (Move code interpreting > path relative to exec-dir to new function system_path()., 14 Jul 2008). So > we no need in it anymore. > > Signed-off-by: Alexander Kuleshov > --- Makes sense. Thanks. > builtin/init-db.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/builtin/init-db.c b/builtin/init-db.c > index 280454a..2978b36 100644 > --- a/builtin/init-db.c > +++ b/builtin/init-db.c > @@ -3,9 +3,7 @@ > * > * Copyright (C) Linus Torvalds, 2005 > */ > -#include "cache.h" > #include "builtin.h" > -#include "exec_cmd.h" > #include "parse-options.h" > > #ifndef DEFAULT_GIT_TEMPLATE_DIR -- 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: t5539 broken under Mac OS X
On 2015-01-14 19.37, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> t5539 doesn't seem to work as expected under Mac OX X 10.6 >> (10.9 is OK) >> >> I am not root. >> Are there any ideas how we can improve the situation, or how to debug ? > > As to "how to debug", the first step is to grep for that message and > notice that it comes from here: > > t/lib-httpd.sh: > > if ! test_have_prereq SANITY; then > test_skip_or_die $GIT_TEST_HTTPD \ > "Cannot run httpd tests as root" > fi > > and then grep for SANITY to find: > > t/test-lib.sh: > > # When the tests are run as root, permission tests will report that > # things are writable when they shouldn't be. > test -w / || test_set_prereq SANITY > > It appears that the check in lib-httpd.sh thinks you lack SANITY; is > the root directory of your system somehow writable by you? > Yes, that was a good hint, thanks. The "problem" is that I am Admin on one machine, but not on the other, and / was writable for the admin group for some reasons, and only on this machine. But, why does e.g. t0004 behave more gracefully (and skips) and t5539 just dies ? ./t0004-unwritable.sh ok 1 - setup ok 2 # skip write-tree should notice unwritable repository (missing SANITY of POSIXPERM,SANITY) (And after changing the group of / t5539 passes, and so does t0004) -- 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] bash completion: allow git stash store options completion
"brian m. carlson" writes: [administrivia: please refrain from using Mail-follow-up-to] > For what it's worth, I'll often sketch out a script at the command > line before putting it in a file (either because I realize I'll need > to do the same thing again or I want to share it with others), so I > think this might be a useful addition. Yes, but that applies to manual pages and possibly "-h" short hint; keeping completion that is unnecessary for end-users has cost, e.g. making unique prefix longer. -- 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] init-db: remove unused #includes
Junio C Hamano writes: > Alexander Kuleshov writes: > >> * "cache.h" - is unnecessary because it already included at "builtin.h" >> >> * "exec_cmd.h" - was added at a47d1813 (Allow a relative builtin template >> directory., 15 Nov 2007). init-db used 'git_exec_path' routine from >> "exec_cmd.h", but later it was removed at 2de9de5e (Move code interpreting >> path relative to exec-dir to new function system_path()., 14 Jul 2008). So >> we no need in it anymore. >> >> Signed-off-by: Alexander Kuleshov >> --- > > Makes sense. Thanks. Actually, not. 2de9de5e does make it unnecessary to refer to git_exec_path(), but in order to reference the newly introduced system_path(), which is declared in exec_cmd.h, the file still would have needed to include the header, so the justification for the latter does not make sense. And indeed, we still need exec_cmd.h in today's code. -- 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] t1050-large: generate large files without dd
For some unknown reason, the dd on my Windows box segfaults randomly, but since recently, it does so much more often than it used to, which makes running the test suite burdensome. Use printf to write large files instead of dd. To emphasize that three of the large blobs are exact copies, use cp to allocate them. The new code makes the files a bit smaller, and they are not sparse anymore, but the tests do not depend on these properties. We do not want to use test-genrandom here (which is used to generate large files elsewhere in t1050), so that the files can be compressed well (which keeps the run-time short). The files are now large text files, not binary files. But since they are larger than core.bigfilethreshold they are diagnosed as binary by Git. For this reason, the 'git diff' tests that check the output for "Binary files differ" still pass. Signed-off-by: Johannes Sixt --- V2: - use printf instead of test-genrandom - use test_cmp, not test_cmp_bin because the files are text now Am 14.01.2015 um 12:27 schrieb Jeff King: > On Tue, Jan 13, 2015 at 03:40:10PM -0800, Junio C Hamano wrote: >> Are we depending on the binary-ness of these test files by the way? >> The leading NUL \0 looked a bit strange to me. > > I don't think so. We do not want to do a text diff, because that would > overflow our GIT_ALLOC_LIMIT. But the core.bigfilethreshold check is > what will make them binary, not the actual content. So a gigantic text > file is arguably a better test of the feature in question. Agreed. The files are text now. t/t1050-large.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t1050-large.sh b/t/t1050-large.sh index f5a9119..f9f3d13 100755 --- a/t/t1050-large.sh +++ b/t/t1050-large.sh @@ -9,10 +9,10 @@ test_expect_success setup ' # clone does not allow us to pass core.bigfilethreshold to # new repos, so set core.bigfilethreshold globally git config --global core.bigfilethreshold 200k && - echo X | dd of=large1 bs=1k seek=2000 && - echo X | dd of=large2 bs=1k seek=2000 && - echo X | dd of=large3 bs=1k seek=2000 && - echo Y | dd of=huge bs=1k seek=2500 && + printf "%200s" X >large1 && + cp large1 large2 && + cp large1 large3 && + printf "%250s" Y >huge && GIT_ALLOC_LIMIT=1500k && export GIT_ALLOC_LIMIT ' @@ -61,7 +61,7 @@ test_expect_success 'checkout a large file' ' large1=$(git rev-parse :large1) && git update-index --add --cacheinfo 100644 $large1 another && git checkout another && - cmp large1 another ;# this must not be test_cmp + test_cmp large1 another ' test_expect_success 'packsize limit' ' @@ -162,7 +162,7 @@ test_expect_success 'pack-objects with large loose object' ' test_create_repo packed && mv pack-* packed/.git/objects/pack && GIT_DIR=packed/.git git cat-file blob $SHA1 >actual && - cmp huge actual + test_cmp huge actual ' test_expect_success 'tar achiving' ' -- 2.0.0.12.gbcf935e -- 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-svn metadata commands performance issue
Niluge kiwi wrote:
> Hi all,
>
> In magit (http://magit.github.io/), a popular git frontend within
> emacs, there is a git-svn frontend. With a recent refactoring, it was
> discovered that git-svn metadata commands (like "git-svn info") are
> much slower than git ones:
> git svn info: 130-150ms (after warmup): get the svn revision and url.
> git svn rebase --dry-run: 150-170ms (after warmup): get the remote
> branch.
>
> Whereas in pure git:
> git rev-parse --abbrev-ref HEAD@{upstream}: 2-3ms (after warmup): get
> the remote branch
> Other git commands alike take all less than 10ms after warmup.
Thanks for the bug report. I actually see worse performance from
my old machines, but I'm not a very heavy git-svn user anymore.
100ms is an eternity :<
> This is an issue for the magit developers and users: just getting a
> git-svn status with some metadata easily take ~500ms, which is really
> slow for a UI. The equivalent UI with a pure git repository in magit
> takes much less than 100ms to generate although more than 30 git
> process are forked for it.
How big is the parent process which forks the git commands? On Linux at
least, fork() performance is negatively impacted by parent process
memory size. To avoid spawn performance problems with large parent
processes, vfork() should be used, but there does not seem to be an
easy/portable way to use vfork() from Perl.
> A previous version of magit-svn was much faster because it
> re-implemented the logic of git-svn from perl to elisp (the
> programming language in emacs), and to get the 3 previously mentioned
> values it took less than 10ms.
I've never worked with elisp, but we can probably figure out why it's
faster. Can you give us a pointer to the old elisp code?
> What could be done about this?
> Could git-svn performance be dramatically improved?
> Even git svn --version takes ~100ms, is perl the bottleneck?
The Linux 'perf' tool reports much time is spent is from the Perl
parser. So we may implement lazy loading, so simple commands such as
"git svn info" do not need to load and parse all the Perl code.
> Or should each git-svn frontend developer re-implement the git-svn
> metadata commands themselves for better performance?
I prefer git-svn be fast enough; but you're free to reimplement
and optimize your own code as you see fit.
> Also, wouldn't it be better for those frontend developers if there
> were some git-svn porcelain commands like git has? Fast, easy to parse
> and stable input & output format?
Sure, but we don't know what you'd need beyond the current command set.
Of course we need to be careful about adding even more code to git-svn
as that impacts startup time, too.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/init-db.txt: minor style and synopsys fixes
On Wed, Jan 14, 2015 at 12:33 PM, Alexander Kuleshov wrote: > This patch constists of two minor changes: > > * line-wrap 'git init-db' synopsis > > * last possible argument '[directory]' was missed > > Signed-off-by: Alexander Kuleshov > --- > diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt > index 648a6cd..1d94fe8 100644 > --- a/Documentation/git-init-db.txt > +++ b/Documentation/git-init-db.txt > @@ -9,8 +9,9 @@ git-init-db - Creates an empty Git repository > SYNOPSIS > > [verse] > -'git init-db' [-q | --quiet] [--bare] [--template=] > [--separate-git-dir ] [--shared[=]] > - > +'git init-db' [-q | --quiet] [--bare] [--template=] > + [--separate-git-dir ] > + [--shared[=]] [directory] I realize that you copied/pasted the text from git-init.txt, but this should really be []. While you're at it, you could fix it in git-init.txt, as well, and adjust the formatting of... If you provide a 'directory', ... to say: If you provide , ... -- 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] blame.c: fix garbled error message
On Wed, Jan 14, 2015 at 09:22:52AM -0800, Junio C Hamano wrote: > Lukas Fleischer writes: > > >> [1/5]: git-compat-util: add xstrdup_or_null helper > >> [2/5]: builtin/apply.c: use xstrdup_or_null instead of null_strdup > >> [3/5]: builtin/commit.c: use xstrdup_or_null instead of envdup > >> [4/5]: use xstrdup_or_null to replace ternary conditionals > >> [5/5]: blame.c: fix garbled error message > >> > > > > Looks good to me! I am not sure whether those patches should be built on > > top of (a fixed version of) my patch, though, which would make > > backporting the fix to the maintenance branch straightforward. Junio? > > We can queue these five on top of 1da1e07c (clean up name allocation > in prepare_revision_walk, 2014-10-15), which changed the rule of the > game to break this code, that only is in v2.2 and later. > > And the result should merge just fine to 'maint'. Are we in agreement then that the resulting code with the helper is actually easier to read? I think replacing the straight ?: lines is, but I am on the fence on whether: const char *x = some_fun(...); return xstrdup_or_null(x); is better or worse than: return xstrdup_or_null(some_fun()); -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: sporadic git failures on interactive rebase
On Wed, Jan 14, 2015 at 09:12:46AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > What happens if we rebase with it? > > > > $ git checkout 01319837 > > $ git rebase -i HEAD^ > > > > will yield a todo file with the 8-character unambiguous abbreviation. > > > > So I guess all is working as intended there. Perhaps you really were > > just very unlucky and an earlier step of the rebase created a > > conflicting sha1. > > That would mean 75c69766 (rebase -i: fix short SHA-1 collision, > 2013-08-23) did not fix what it intended to fix, no? Is the symptom > coming from pre-1.8.4.2 version of Git? Yeah, you're right. I didn't even remember that commit at all. On the off chance that the abbreviation code was different in that earlier version, I also checked rebasing 01319837 with an older version, but it does work fine. So yeah, the most plausible theory to me so far is unluckiness combined with pre-1.8.4.2. That should be easy to disprove if Henning tells us his git version. -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] t1050-large: generate large files without dd
On Wed, Jan 14, 2015 at 09:28:56PM +0100, Johannes Sixt wrote: > For some unknown reason, the dd on my Windows box segfaults randomly, > but since recently, it does so much more often than it used to, which > makes running the test suite burdensome. > > Use printf to write large files instead of dd. To emphasize that three > of the large blobs are exact copies, use cp to allocate them. > > The new code makes the files a bit smaller, and they are not sparse > anymore, but the tests do not depend on these properties. We do not want > to use test-genrandom here (which is used to generate large files > elsewhere in t1050), so that the files can be compressed well (which > keeps the run-time short). Thanks, this version looks good to me. > The files are now large text files, not binary files. But since they > are larger than core.bigfilethreshold they are diagnosed as binary > by Git. For this reason, the 'git diff' tests that check the output > for "Binary files differ" still pass. I was less concerned with tests not passing, as much as tests ending up testing nothing (which is very hard to test automatically, as you would have to recreate the original bug!). But I think it is fine, as text is more likely to get malloc'd than a binary (and these tests are really about making sure we avoid huge mallocs). > @@ -162,7 +162,7 @@ test_expect_success 'pack-objects with large loose > object' ' Funny wrapping here. I imagine Junio can manage to apply it anyway, but you may want to check your MUA settings. -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: sporadic git failures on interactive rebase
On Wed, Jan 14, 2015 at 3:54 PM, Jeff King wrote: > On Wed, Jan 14, 2015 at 09:12:46AM -0800, Junio C Hamano wrote: > >> Jeff King writes: >> >> > What happens if we rebase with it? >> > >> > $ git checkout 01319837 >> > $ git rebase -i HEAD^ >> > >> > will yield a todo file with the 8-character unambiguous abbreviation. >> > >> > So I guess all is working as intended there. Perhaps you really were >> > just very unlucky and an earlier step of the rebase created a >> > conflicting sha1. >> >> That would mean 75c69766 (rebase -i: fix short SHA-1 collision, >> 2013-08-23) did not fix what it intended to fix, no? Is the symptom >> coming from pre-1.8.4.2 version of Git? > > Yeah, you're right. I didn't even remember that commit at all. On the > off chance that the abbreviation code was different in that earlier > version, I also checked rebasing 01319837 with an older version, but it > does work fine. > > So yeah, the most plausible theory to me so far is unluckiness combined > with pre-1.8.4.2. That should be easy to disprove if Henning tells us > his git version. Henning mentioned it at the very top of his original problem report: "(git version 2.2.0)" -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/init-db.txt: minor style and synopsys fixes
2015-01-14 13:47 GMT-07:00 Eric Sunshine : > On Wed, Jan 14, 2015 at 12:33 PM, Alexander Kuleshov > wrote: >> -'git init-db' [-q | --quiet] [--bare] [--template=] >> [--separate-git-dir ] [--shared[=]] >> - >> +'git init-db' [-q | --quiet] [--bare] [--template=] >> + [--separate-git-dir ] >> + [--shared[=]] [directory] > > I realize that you copied/pasted the text from git-init.txt, but this > should really be []. We're also transitioning to using hyphens to separate words in template placeholders, so here you would have and . -Alex -- 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: sporadic git failures on interactive rebase
On Wed, Jan 14, 2015 at 4:00 PM, Eric Sunshine wrote: > On Wed, Jan 14, 2015 at 3:54 PM, Jeff King wrote: >> On Wed, Jan 14, 2015 at 09:12:46AM -0800, Junio C Hamano wrote: >> >>> Jeff King writes: >>> >>> > What happens if we rebase with it? >>> > >>> > $ git checkout 01319837 >>> > $ git rebase -i HEAD^ >>> > >>> > will yield a todo file with the 8-character unambiguous abbreviation. >>> > >>> > So I guess all is working as intended there. Perhaps you really were >>> > just very unlucky and an earlier step of the rebase created a >>> > conflicting sha1. >>> >>> That would mean 75c69766 (rebase -i: fix short SHA-1 collision, >>> 2013-08-23) did not fix what it intended to fix, no? Is the symptom >>> coming from pre-1.8.4.2 version of Git? >> >> Yeah, you're right. I didn't even remember that commit at all. On the >> off chance that the abbreviation code was different in that earlier >> version, I also checked rebasing 01319837 with an older version, but it >> does work fine. >> >> So yeah, the most plausible theory to me so far is unluckiness combined >> with pre-1.8.4.2. That should be easy to disprove if Henning tells us >> his git version. > > Henning mentioned it at the very top of his original problem report: > > "(git version 2.2.0)" For completeness: http://article.gmane.org/gmane.comp.version-control.git/262334 -- 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: sporadic git failures on interactive rebase
On Wed, Jan 14, 2015 at 04:00:37PM -0500, Eric Sunshine wrote: > > So yeah, the most plausible theory to me so far is unluckiness combined > > with pre-1.8.4.2. That should be easy to disprove if Henning tells us > > his git version. > > Henning mentioned it at the very top of his original problem report: > > "(git version 2.2.0)" Ah, reading comprehension. It pays off. I'm stumped, then. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git ignores /~/.config/git/
On Wed, Jan 14, 2015 at 07:33:07PM +, Moez Bouhlel wrote: > git exludes /~/.config/git/ from the matching list. > > ~ is the name of a dir on the root of git working tree and not my user home > dir. I'm not quite sure what you mean by "matching list". Do you mean that the path is not listed as untracked in "git status"? Are there any files inside the directory? Git will not mention empty directories, as tracks only file content, not directories. Beyond that, I cannot reproduce: $ git init $ mkdir -p '~/.config/git' $ git status -s Lack of output is expected, since there are no files. Now: $ echo content >'~/.config/git/foo' $ git status -s ?? ~/ $ git status -s -uall ?? ~/.config/git/foo This is on Linux. Are you by any chance using Git for Windows? I wonder if the recent chances to short-names like "foo~1" could have affected this. -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: sporadic git failures on interactive rebase
On Wed, Jan 14, 2015 at 4:02 PM, Jeff King wrote: > On Wed, Jan 14, 2015 at 04:00:37PM -0500, Eric Sunshine wrote: > >> > So yeah, the most plausible theory to me so far is unluckiness combined >> > with pre-1.8.4.2. That should be easy to disprove if Henning tells us >> > his git version. >> >> Henning mentioned it at the very top of his original problem report: >> >> "(git version 2.2.0)" > > Ah, reading comprehension. It pays off. > > I'm stumped, then. Perhaps some new code been added to git-rebase--interactive.sh since 75c69766 which neglects to invoke expand_todo_ids()? Or, possibly some older version of git is being invoked somehow during rebase despite his "front end" use of 2.2.0? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: t5539 broken under Mac OS X
On Wed, Jan 14, 2015 at 08:50:47PM +0100, Torsten Bögershausen wrote: > But, why does e.g. t0004 behave more gracefully (and skips) and t5539 just > dies ? > > ./t0004-unwritable.sh > ok 1 - setup > ok 2 # skip write-tree should notice unwritable repository (missing SANITY of > POSIXPERM,SANITY) The http code uses test_skip_or_die when it runs into setup errors. The intent there is that the user has either: 1. Told us explicitly that they want http tests by setting GIT_TEST_HTTPD=true. 2. Wants to run http tests if they can by setting GIT_TEST_HTTPD=auto (or leaving it unset, as that is the default). In case (1), we treat this as a test failure. They asked for httpd tests, and we could not run them. In case (2), we would just skip all of the tests. You may want to loosen your GIT_TEST_HTTPD setting (pre-83d842dc, you had to set it to true to run the tests at all, but nowadays we have auto). -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] t1050-large: generate large files without dd
Am 14.01.2015 um 22:00 schrieb Jeff King: >> @@ -162,7 +162,7 @@ test_expect_success 'pack-objects with large loose >> object' ' > > Funny wrapping here. I imagine Junio can manage to apply it anyway, but > you may want to check your MUA settings. Argh! Forgot to switch off line wrapping. Here is a hopefully correct version. --- 8< --- [PATCH v2] t1050-large: generate large files without dd For some unknown reason, the dd on my Windows box segfaults randomly, but since recently, it does so much more often than it used to, which makes running the test suite burdensome. Use printf to write large files instead of dd. To emphasize that three of the large blobs are exact copies, use cp to allocate them. The new code makes the files a bit smaller, and they are not sparse anymore, but the tests do not depend on these properties. We do not want to use test-genrandom here (which is used to generate large files elsewhere in t1050), so that the files can be compressed well (which keeps the run-time short). The files are now large text files, not binary files. But since they are larger than core.bigfilethreshold they are diagnosed as binary by Git. For this reason, the 'git diff' tests that check the output for "Binary files differ" still pass. Signed-off-by: Johannes Sixt --- t/t1050-large.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t1050-large.sh b/t/t1050-large.sh index f5a9119..f9f3d13 100755 --- a/t/t1050-large.sh +++ b/t/t1050-large.sh @@ -9,10 +9,10 @@ test_expect_success setup ' # clone does not allow us to pass core.bigfilethreshold to # new repos, so set core.bigfilethreshold globally git config --global core.bigfilethreshold 200k && - echo X | dd of=large1 bs=1k seek=2000 && - echo X | dd of=large2 bs=1k seek=2000 && - echo X | dd of=large3 bs=1k seek=2000 && - echo Y | dd of=huge bs=1k seek=2500 && + printf "%200s" X >large1 && + cp large1 large2 && + cp large1 large3 && + printf "%250s" Y >huge && GIT_ALLOC_LIMIT=1500k && export GIT_ALLOC_LIMIT ' @@ -61,7 +61,7 @@ test_expect_success 'checkout a large file' ' large1=$(git rev-parse :large1) && git update-index --add --cacheinfo 100644 $large1 another && git checkout another && - cmp large1 another ;# this must not be test_cmp + test_cmp large1 another ' test_expect_success 'packsize limit' ' @@ -162,7 +162,7 @@ test_expect_success 'pack-objects with large loose object' ' test_create_repo packed && mv pack-* packed/.git/objects/pack && GIT_DIR=packed/.git git cat-file blob $SHA1 >actual && - cmp huge actual + test_cmp huge actual ' test_expect_success 'tar achiving' ' -- 2.0.0.12.gbcf935e -- 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] blame.c: fix garbled error message
Jeff King writes: > On Wed, Jan 14, 2015 at 09:22:52AM -0800, Junio C Hamano wrote: > ... >> And the result should merge just fine to 'maint'. > > Are we in agreement then that the resulting code with the helper is > actually easier to read? I think replacing the straight ?: lines is, but > I am on the fence on whether: > > const char *x = some_fun(...); > return xstrdup_or_null(x); > > is better or worse than: > > return xstrdup_or_null(some_fun()); I think the latter is fine as long as some_fun(...) invocation does not get overly long, and even the longest I saw in refs.c, i.e. return xstrdup_or_null(resolve_ref_unsafe(ref, resolve_flags, sha1, flags)); did not bother me too much. -- 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: sporadic git failures on interactive rebase
Eric Sunshine writes: > On Wed, Jan 14, 2015 at 4:02 PM, Jeff King wrote: >> On Wed, Jan 14, 2015 at 04:00:37PM -0500, Eric Sunshine wrote: >> >>> > So yeah, the most plausible theory to me so far is unluckiness combined >>> > with pre-1.8.4.2. That should be easy to disprove if Henning tells us >>> > his git version. >>> >>> Henning mentioned it at the very top of his original problem report: >>> >>> "(git version 2.2.0)" >> >> Ah, reading comprehension. It pays off. >> >> I'm stumped, then. > > Perhaps some new code been added to git-rebase--interactive.sh since > 75c69766 which neglects to invoke expand_todo_ids()? > > Or, possibly some older version of git is being invoked somehow during > rebase despite his "front end" use of 2.2.0? Or git_sequence_editor creates conflicting objects? -- 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] t1050-large: generate large files without dd
Jeff King writes: >> @@ -162,7 +162,7 @@ test_expect_success 'pack-objects with large loose >> object' ' > > Funny wrapping here. I imagine Junio can manage to apply it anyway, but > you may want to check your MUA settings. Thanks for a warning; luckily this was the only breakage and the result looks good. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: remote helper example with push/fetch capabilities
I'm interested in doing something very similar (not to S3, but to a customer CMS repository), but have found it very difficult to find any documentation or good example code on git-remote-helpers. If you can share any learnings or references I would really appreciate it! thanks, Andrew -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-svn: show progress in working_head_info()
Eric, I'm sorry, but this change isn't important enough for me to follow up. Please merge the other two patches, if you think they're good. 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
[PATCH 01/10] http.c: make finish_active_slot() and handle_curl_result() static
No external callers exist.
Signed-off-by: Junio C Hamano
---
http.c | 64
http.h | 2 --
2 files changed, 32 insertions(+), 34 deletions(-)
diff --git a/http.c b/http.c
index 040f362..16a6a2d 100644
--- a/http.c
+++ b/http.c
@@ -114,6 +114,37 @@ size_t fwrite_null(char *ptr, size_t eltsize, size_t
nmemb, void *strbuf)
return eltsize * nmemb;
}
+static void closedown_active_slot(struct active_request_slot *slot)
+{
+ active_requests--;
+ slot->in_use = 0;
+}
+
+static void finish_active_slot(struct active_request_slot *slot)
+{
+ closedown_active_slot(slot);
+ curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);
+
+ if (slot->finished != NULL)
+ (*slot->finished) = 1;
+
+ /* Store slot results so they can be read after the slot is reused */
+ if (slot->results != NULL) {
+ slot->results->curl_result = slot->curl_result;
+ slot->results->http_code = slot->http_code;
+#if LIBCURL_VERSION_NUM >= 0x070a08
+ curl_easy_getinfo(slot->curl, CURLINFO_HTTPAUTH_AVAIL,
+ &slot->results->auth_avail);
+#else
+ slot->results->auth_avail = 0;
+#endif
+ }
+
+ /* Run callback if appropriate */
+ if (slot->callback_func != NULL)
+ slot->callback_func(slot->callback_data);
+}
+
#ifdef USE_CURL_MULTI
static void process_curl_messages(void)
{
@@ -730,12 +761,6 @@ void run_active_slot(struct active_request_slot *slot)
#endif
}
-static void closedown_active_slot(struct active_request_slot *slot)
-{
- active_requests--;
- slot->in_use = 0;
-}
-
static void release_active_slot(struct active_request_slot *slot)
{
closedown_active_slot(slot);
@@ -752,31 +777,6 @@ static void release_active_slot(struct active_request_slot
*slot)
#endif
}
-void finish_active_slot(struct active_request_slot *slot)
-{
- closedown_active_slot(slot);
- curl_easy_getinfo(slot->curl, CURLINFO_HTTP_CODE, &slot->http_code);
-
- if (slot->finished != NULL)
- (*slot->finished) = 1;
-
- /* Store slot results so they can be read after the slot is reused */
- if (slot->results != NULL) {
- slot->results->curl_result = slot->curl_result;
- slot->results->http_code = slot->http_code;
-#if LIBCURL_VERSION_NUM >= 0x070a08
- curl_easy_getinfo(slot->curl, CURLINFO_HTTPAUTH_AVAIL,
- &slot->results->auth_avail);
-#else
- slot->results->auth_avail = 0;
-#endif
- }
-
- /* Run callback if appropriate */
- if (slot->callback_func != NULL)
- slot->callback_func(slot->callback_data);
-}
-
void finish_all_active_slots(void)
{
struct active_request_slot *slot = active_queue_head;
@@ -839,7 +839,7 @@ char *get_remote_object_url(const char *url, const char
*hex,
return strbuf_detach(&buf, NULL);
}
-int handle_curl_result(struct slot_results *results)
+static int handle_curl_result(struct slot_results *results)
{
/*
* If we see a failing http code with CURLE_OK, we have turned off
diff --git a/http.h b/http.h
index 473179b..49afe39 100644
--- a/http.h
+++ b/http.h
@@ -85,9 +85,7 @@ extern curlioerr ioctl_buffer(CURL *handle, int cmd, void
*clientp);
extern struct active_request_slot *get_active_slot(void);
extern int start_active_slot(struct active_request_slot *slot);
extern void run_active_slot(struct active_request_slot *slot);
-extern void finish_active_slot(struct active_request_slot *slot);
extern void finish_all_active_slots(void);
-extern int handle_curl_result(struct slot_results *results);
/*
* This will run one slot to completion in a blocking manner, similar to how
--
2.3.0-rc0-134-g109a908
--
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 10/10] commit: show "Author:" hint when the ident is not given explicitly
This is a knee-jerk response to two facts:
- the author_ident_sufficiently_given() function is public but
nobody uses it;
- a corresponding function committer_ident_sufficiently_given() is
used to determine when to add "Committer: " reminder in the log
message editor.
The existing logic decides to show "Author:" reminder when the
author is different from the committer, so there won't be practical
difference other than we would end up showing both reminders when a
committer with iffy name derived from the heuristic is committing
her own patch.
Which means this patch probably should be dropped.
Signed-off-by: Junio C Hamano
---
builtin/commit.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 7d90c35..b512504 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -847,7 +847,8 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
assert_split_ident(&ai, author_ident);
assert_split_ident(&ci, &committer_ident);
- if (ident_cmp(&ai, &ci))
+ if (ident_cmp(&ai, &ci) ||
+ !author_ident_sufficiently_given())
status_printf_ln(s, GIT_COLOR_NORMAL,
_("%s"
"Author:%.*s <%.*s>"),
@@ -1440,7 +1441,8 @@ static void print_summary(const char *prefix, const
unsigned char *sha1,
format_commit_message(commit, "%an <%ae>", &author_ident, &pctx);
format_commit_message(commit, "%cn <%ce>", &committer_ident, &pctx);
- if (strbuf_cmp(&author_ident, &committer_ident)) {
+ if (strbuf_cmp(&author_ident, &committer_ident) ||
+ !author_ident_sufficiently_given()) {
strbuf_addstr(&format, "\n Author: ");
strbuf_addbuf_percentquote(&format, &author_ident);
}
--
2.3.0-rc0-134-g109a908
--
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 00/10] mark private symbols static
Here are a handful of patches to make symbols that are only used within a .c file as static. This is not the kind of changes we would want to do in the pre-release freeze period, and it is just for reference. I may later come back to them after 2.3 final is tagged. Note that I did not blindly make everything that _could_ be made static; the ones I deliberately left untouched are: * config.c: this has a lot of git_configset_*() API functions that were developed but not yet used (as part of 3/4-way done GSoc project that did not fully convert users of the config subsystem to these new style functions); making them static merely because they are not yet used goes backwards. * ewah/* and xdiff/*: I consider these borrowed code, which we would want to avoid touching in the same series as our own code. * graph.c: graph_next_line() and graph_set_column_colors() are not called externally, but I suspect that they are API functions waiting for a new caller to appear. * line-log.c: range_set_append() is not called externally, but this is only because a caller calls range_set_append_unsafe(), its sibling, which may want to be cleaned up. * refs.c: rollback_packed_refs() is not called externally, but the codebase around refs API is in flux and I did not want to add to the code churn. * strbuf.c: xstrvfmt() is not called externally, but this is a reasonable API function to keep; its friend xstrfmt() is used by many places. * string-list.c: print_string_list() may want to go, but it may be useful for debugging, so I kept it in. * wrapper.c: rmdir_or_warn() is not used externally, but this is a reasonable API function as its friends like unlink_or_warn() that are used. The last patch in the series is very questionable. Instead of hiding unused author_ident_sufficiently_given() function (and possibly removing it), it adds external callers to justify its existence ;-) Junio C Hamano (10): http.c: make finish_active_slot() and handle_curl_result() static line-log.c: make line_log_data_init() static prompt.c: remove git_getpass() nobody uses revision.c: make save_parents() and free_saved_parents() static urlmatch.c: make match_urls() static remote.c: make clear_cas_option() static shallow.c: make check_shallow_file_for_update() static pack-bitmap.c: make pack_bitmap_filename() static read-cache.c: make fill/match_stat_data() static commit: show "Author:" hint when the ident is not given explicitly builtin/commit.c | 6 ++-- cache.h | 14 commit.h | 1 - http.c | 64 - http.h | 2 -- line-log.c | 2 +- line-log.h | 2 -- pack-bitmap.c| 28 +++ pack-bitmap.h| 1 - prompt.c | 5 --- prompt.h | 1 - read-cache.c | 14 ++-- remote.c | 2 +- remote.h | 1 - revision.c | 106 +-- revision.h | 12 +++ shallow.c| 2 +- urlmatch.c | 6 ++-- urlmatch.h | 1 - 19 files changed, 127 insertions(+), 143 deletions(-) -- 2.3.0-rc0-134-g109a908 -- 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 03/10] prompt.c: remove git_getpass() nobody uses
Signed-off-by: Junio C Hamano
---
prompt.c | 5 -
prompt.h | 1 -
2 files changed, 6 deletions(-)
diff --git a/prompt.c b/prompt.c
index 8181eeb..7540639 100644
--- a/prompt.c
+++ b/prompt.c
@@ -73,8 +73,3 @@ char *git_prompt(const char *prompt, int flags)
}
return r;
}
-
-char *git_getpass(const char *prompt)
-{
- return git_prompt(prompt, PROMPT_ASKPASS);
-}
diff --git a/prompt.h b/prompt.h
index 04f321a..e04cced 100644
--- a/prompt.h
+++ b/prompt.h
@@ -5,6 +5,5 @@
#define PROMPT_ECHO(1<<1)
char *git_prompt(const char *prompt, int flags);
-char *git_getpass(const char *prompt);
#endif /* PROMPT_H */
--
2.3.0-rc0-134-g109a908
--
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 06/10] remote.c: make clear_cas_option() static
No external callers exist.
Signed-off-by: Junio C Hamano
---
remote.c | 2 +-
remote.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index 5b9c693..0b3939c 100644
--- a/remote.c
+++ b/remote.c
@@ -2156,7 +2156,7 @@ struct ref *get_stale_heads(struct refspec *refs, int
ref_count, struct ref *fet
/*
* Compare-and-swap
*/
-void clear_cas_option(struct push_cas_option *cas)
+static void clear_cas_option(struct push_cas_option *cas)
{
int i;
diff --git a/remote.h b/remote.h
index 8b62efd..31ccdcd 100644
--- a/remote.h
+++ b/remote.h
@@ -260,7 +260,6 @@ struct push_cas_option {
extern int parseopt_push_cas_option(const struct option *, const char *arg,
int unset);
extern int parse_push_cas_option(struct push_cas_option *, const char *arg,
int unset);
-extern void clear_cas_option(struct push_cas_option *);
extern int is_empty_cas(const struct push_cas_option *);
void apply_push_cas(struct push_cas_option *, struct remote *, struct ref *);
--
2.3.0-rc0-134-g109a908
--
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 09/10] read-cache.c: make fill/match_stat_data() static
Signed-off-by: Junio C Hamano
---
cache.h | 14 --
read-cache.c | 14 --
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/cache.h b/cache.h
index f704af5..98911c8 100644
--- a/cache.h
+++ b/cache.h
@@ -539,20 +539,6 @@ extern int ie_modified(const struct index_state *, const
struct cache_entry *, s
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, enum
object_type type, const char *path, unsigned flags);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st,
unsigned flags);
-/*
- * Record to sd the data from st that we use to check whether a file
- * might have changed.
- */
-extern void fill_stat_data(struct stat_data *sd, struct stat *st);
-
-/*
- * Return 0 if st is consistent with a file not having been changed
- * since sd was filled. If there are differences, return a
- * combination of MTIME_CHANGED, CTIME_CHANGED, OWNER_CHANGED,
- * INODE_CHANGED, and DATA_CHANGED.
- */
-extern int match_stat_data(const struct stat_data *sd, struct stat *st);
-
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_REALLY 0x0001 /* ignore_valid */
diff --git a/read-cache.c b/read-cache.c
index 9cff715..5a71de1 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -83,7 +83,11 @@ void rename_index_entry_at(struct index_state *istate, int
nr, const char *new_n
add_index_entry(istate, new,
ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE);
}
-void fill_stat_data(struct stat_data *sd, struct stat *st)
+/*
+ * Record to sd the data from st that we use to check whether a file
+ * might have changed.
+ */
+static void fill_stat_data(struct stat_data *sd, struct stat *st)
{
sd->sd_ctime.sec = (unsigned int)st->st_ctime;
sd->sd_mtime.sec = (unsigned int)st->st_mtime;
@@ -96,7 +100,13 @@ void fill_stat_data(struct stat_data *sd, struct stat *st)
sd->sd_size = st->st_size;
}
-int match_stat_data(const struct stat_data *sd, struct stat *st)
+/*
+ * Return 0 if st is consistent with a file not having been changed
+ * since sd was filled. If there are differences, return a
+ * combination of MTIME_CHANGED, CTIME_CHANGED, OWNER_CHANGED,
+ * INODE_CHANGED, and DATA_CHANGED.
+ */
+static int match_stat_data(const struct stat_data *sd, struct stat *st)
{
int changed = 0;
--
2.3.0-rc0-134-g109a908
--
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 04/10] revision.c: make save_parents() and free_saved_parents() static
No external callers exist.
Signed-off-by: Junio C Hamano
---
revision.c | 106 -
revision.h | 12 +++
2 files changed, 59 insertions(+), 59 deletions(-)
diff --git a/revision.c b/revision.c
index 86406a2..0f4619c 100644
--- a/revision.c
+++ b/revision.c
@@ -2968,6 +2968,61 @@ enum commit_action get_commit_action(struct rev_info
*revs, struct commit *commi
return commit_show;
}
+define_commit_slab(saved_parents, struct commit_list *);
+
+#define EMPTY_PARENT_LIST ((struct commit_list *)-1)
+
+/*
+ * You may only call save_parents() once per commit (this is checked
+ * for non-root commits).
+ */
+static void save_parents(struct rev_info *revs, struct commit *commit)
+{
+ struct commit_list **pp;
+
+ if (!revs->saved_parents_slab) {
+ revs->saved_parents_slab = xmalloc(sizeof(struct
saved_parents));
+ init_saved_parents(revs->saved_parents_slab);
+ }
+
+ pp = saved_parents_at(revs->saved_parents_slab, commit);
+
+ /*
+* When walking with reflogs, we may visit the same commit
+* several times: once for each appearance in the reflog.
+*
+* In this case, save_parents() will be called multiple times.
+* We want to keep only the first set of parents. We need to
+* store a sentinel value for an empty (i.e., NULL) parent
+* list to distinguish it from a not-yet-saved list, however.
+*/
+ if (*pp)
+ return;
+ if (commit->parents)
+ *pp = copy_commit_list(commit->parents);
+ else
+ *pp = EMPTY_PARENT_LIST;
+}
+
+static void free_saved_parents(struct rev_info *revs)
+{
+ if (revs->saved_parents_slab)
+ clear_saved_parents(revs->saved_parents_slab);
+}
+
+struct commit_list *get_saved_parents(struct rev_info *revs, const struct
commit *commit)
+{
+ struct commit_list *parents;
+
+ if (!revs->saved_parents_slab)
+ return commit->parents;
+
+ parents = *saved_parents_at(revs->saved_parents_slab, commit);
+ if (parents == EMPTY_PARENT_LIST)
+ return NULL;
+ return parents;
+}
+
enum commit_action simplify_commit(struct rev_info *revs, struct commit
*commit)
{
enum commit_action action = get_commit_action(revs, commit);
@@ -3267,54 +3322,3 @@ void put_revision_mark(const struct rev_info *revs,
const struct commit *commit)
fputs(mark, stdout);
putchar(' ');
}
-
-define_commit_slab(saved_parents, struct commit_list *);
-
-#define EMPTY_PARENT_LIST ((struct commit_list *)-1)
-
-void save_parents(struct rev_info *revs, struct commit *commit)
-{
- struct commit_list **pp;
-
- if (!revs->saved_parents_slab) {
- revs->saved_parents_slab = xmalloc(sizeof(struct
saved_parents));
- init_saved_parents(revs->saved_parents_slab);
- }
-
- pp = saved_parents_at(revs->saved_parents_slab, commit);
-
- /*
-* When walking with reflogs, we may visit the same commit
-* several times: once for each appearance in the reflog.
-*
-* In this case, save_parents() will be called multiple times.
-* We want to keep only the first set of parents. We need to
-* store a sentinel value for an empty (i.e., NULL) parent
-* list to distinguish it from a not-yet-saved list, however.
-*/
- if (*pp)
- return;
- if (commit->parents)
- *pp = copy_commit_list(commit->parents);
- else
- *pp = EMPTY_PARENT_LIST;
-}
-
-struct commit_list *get_saved_parents(struct rev_info *revs, const struct
commit *commit)
-{
- struct commit_list *parents;
-
- if (!revs->saved_parents_slab)
- return commit->parents;
-
- parents = *saved_parents_at(revs->saved_parents_slab, commit);
- if (parents == EMPTY_PARENT_LIST)
- return NULL;
- return parents;
-}
-
-void free_saved_parents(struct rev_info *revs)
-{
- if (revs->saved_parents_slab)
- clear_saved_parents(revs->saved_parents_slab);
-}
diff --git a/revision.h b/revision.h
index 033a244..07807e5 100644
--- a/revision.h
+++ b/revision.h
@@ -298,18 +298,14 @@ extern int rewrite_parents(struct rev_info *revs, struct
commit *commit,
rewrite_parent_fn_t rewrite_parent);
/*
- * Save a copy of the parent list, and return the saved copy. This is
- * used by the log machinery to retrieve the original parents when
- * commit->parents has been modified by history simpification.
- *
- * You may only call save_parents() once per commit (this is checked
- * for non-root commits).
+ * The log machinery saves the original parent list so that
+ * get_saved_parents() can later tell what the real parents of the
+ * commits are, when commit->parents has been modified by history
+ * simpification.
*
* get_saved_pa
[PATCH 08/10] pack-bitmap.c: make pack_bitmap_filename() static
Signed-off-by: Junio C Hamano
---
pack-bitmap.c | 28 ++--
pack-bitmap.h | 1 -
2 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/pack-bitmap.c b/pack-bitmap.c
index 6a81841..0cd85f6 100644
--- a/pack-bitmap.c
+++ b/pack-bitmap.c
@@ -252,6 +252,20 @@ static int load_bitmap_entries_v1(struct bitmap_index
*index)
return 0;
}
+static char *pack_bitmap_filename(struct packed_git *p)
+{
+ char *idx_name;
+ int len;
+
+ len = strlen(p->pack_name) - strlen(".pack");
+ idx_name = xmalloc(len + strlen(".bitmap") + 1);
+
+ memcpy(idx_name, p->pack_name, len);
+ memcpy(idx_name + len, ".bitmap", strlen(".bitmap") + 1);
+
+ return idx_name;
+}
+
static int open_pack_bitmap_1(struct packed_git *packfile)
{
int fd;
@@ -322,20 +336,6 @@ failed:
return -1;
}
-char *pack_bitmap_filename(struct packed_git *p)
-{
- char *idx_name;
- int len;
-
- len = strlen(p->pack_name) - strlen(".pack");
- idx_name = xmalloc(len + strlen(".bitmap") + 1);
-
- memcpy(idx_name, p->pack_name, len);
- memcpy(idx_name + len, ".bitmap", strlen(".bitmap") + 1);
-
- return idx_name;
-}
-
static int open_pack_bitmap(void)
{
struct packed_git *p;
diff --git a/pack-bitmap.h b/pack-bitmap.h
index 487600b..0adcef7 100644
--- a/pack-bitmap.h
+++ b/pack-bitmap.h
@@ -38,7 +38,6 @@ int prepare_bitmap_git(void);
void count_bitmap_commit_list(uint32_t *commits, uint32_t *trees, uint32_t
*blobs, uint32_t *tags);
void traverse_bitmap_commit_list(show_reachable_fn show_reachable);
void test_bitmap_walk(struct rev_info *revs);
-char *pack_bitmap_filename(struct packed_git *p);
int prepare_bitmap_walk(struct rev_info *revs);
int reuse_partial_packfile_from_bitmap(struct packed_git **packfile, uint32_t
*entries, off_t *up_to);
int rebuild_existing_bitmaps(struct packing_data *mapping, khash_sha1
*reused_bitmaps, int show_progress);
--
2.3.0-rc0-134-g109a908
--
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 02/10] line-log.c: make line_log_data_init() static
No external callers exist.
Signed-off-by: Junio C Hamano
---
line-log.c | 2 +-
line-log.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/line-log.c b/line-log.c
index b7864ad..a490efe 100644
--- a/line-log.c
+++ b/line-log.c
@@ -237,7 +237,7 @@ static void diff_ranges_release(struct diff_ranges *diff)
range_set_release(&diff->target);
}
-void line_log_data_init(struct line_log_data *r)
+static void line_log_data_init(struct line_log_data *r)
{
memset(r, 0, sizeof(struct line_log_data));
range_set_init(&r->ranges, 0);
diff --git a/line-log.h b/line-log.h
index a9212d8..7a5c24e 100644
--- a/line-log.h
+++ b/line-log.h
@@ -54,8 +54,6 @@ struct line_log_data {
struct diff_ranges diff;
};
-extern void line_log_data_init(struct line_log_data *r);
-
extern void line_log_init(struct rev_info *rev, const char *prefix, struct
string_list *args);
extern int line_log_filter(struct rev_info *rev);
--
2.3.0-rc0-134-g109a908
--
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 05/10] urlmatch.c: make match_urls() static
No external callers exist.
Signed-off-by: Junio C Hamano
---
urlmatch.c | 6 +++---
urlmatch.h | 1 -
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/urlmatch.c b/urlmatch.c
index 618d216..132d342 100644
--- a/urlmatch.c
+++ b/urlmatch.c
@@ -412,9 +412,9 @@ static size_t url_match_prefix(const char *url,
return 0;
}
-int match_urls(const struct url_info *url,
- const struct url_info *url_prefix,
- int *exactusermatch)
+static int match_urls(const struct url_info *url,
+ const struct url_info *url_prefix,
+ int *exactusermatch)
{
/*
* url_prefix matches url if the scheme, host and port of url_prefix
diff --git a/urlmatch.h b/urlmatch.h
index b461dfd..528862a 100644
--- a/urlmatch.h
+++ b/urlmatch.h
@@ -31,7 +31,6 @@ struct url_info {
};
extern char *url_normalize(const char *, struct url_info *);
-extern int match_urls(const struct url_info *url, const struct url_info
*url_prefix, int *exactusermatch);
struct urlmatch_item {
size_t matched_len;
--
2.3.0-rc0-134-g109a908
--
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 07/10] shallow.c: make check_shallow_file_for_update() static
No external callers exist.
Signed-off-by: Junio C Hamano
---
commit.h | 1 -
shallow.c | 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/commit.h b/commit.h
index 5cc1e7e..9f189cb 100644
--- a/commit.h
+++ b/commit.h
@@ -254,7 +254,6 @@ extern int for_each_commit_graft(each_commit_graft_fn, void
*);
extern int is_repository_shallow(void);
extern struct commit_list *get_shallow_commits(struct object_array *heads,
int depth, int shallow_flag, int not_shallow_flag);
-extern void check_shallow_file_for_update(void);
extern void set_alternate_shallow_file(const char *path, int override);
extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol,
const struct sha1_array *extra);
diff --git a/shallow.c b/shallow.c
index cdd0775..04ea816 100644
--- a/shallow.c
+++ b/shallow.c
@@ -137,7 +137,7 @@ struct commit_list *get_shallow_commits(struct object_array
*heads, int depth,
return result;
}
-void check_shallow_file_for_update(void)
+static void check_shallow_file_for_update(void)
{
if (is_shallow == -1)
die("BUG: shallow must be initialized by now");
--
2.3.0-rc0-134-g109a908
--
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
What's cooking in git.git (Jan 2015, #03; Wed, 14)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. Many small low-impact topics have been merged to 'master' in preparation for 2.3-rc1 later in the week. I see nothing pressing that remain in 'next' other than a few bugfixes I am hoping that we can merge and ship in the 2.3 final. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * ak/doc-add-v-n-options (2015-01-09) 1 commit (merged to 'next' on 2015-01-12 at 0888edf) + Documentation: list long options for -v and -n * ak/fewer-includes (2015-01-09) 2 commits (merged to 'next' on 2015-01-12 at d425e96) + cat-file: remove unused includes + git.c: remove unnecessary #includes * ak/show-branch-usage-string (2015-01-08) 1 commit (merged to 'next' on 2015-01-12 at 3a0de03) + show-branch: line-wrap show-branch usage * aw/doc-smtp-ssl-cert-path (2015-01-07) 1 commit (merged to 'next' on 2015-01-12 at 61d0b22) + correct smtp-ssl-cert-path description A long overdue documentation update to match an age-old code update. * jk/prune-packed-server-info (2015-01-06) 2 commits (merged to 'next' on 2015-01-12 at 5e789e2) + update-server-info: create info/* with mode 0666 + t1301: set umask in reflog sharedrepository=group test Fix recent breakage in Git 2.2 that started creating info/refs and objects/info/packs files with permission bits tighter than user's umask. * js/remote-add-with-insteadof (2014-12-23) 2 commits (merged to 'next' on 2015-01-12 at ccff14f) + Add a regression test for 'git remote add ' + git remote: allow adding remotes agreeing with url.<...>.insteadOf "git remote add $name $URL" is now allowed when "url.$URL.insteadOf" is already defined. * km/imap-send-libcurl-options (2015-01-06) 2 commits (merged to 'next' on 2015-01-12 at 5bb8802) + imap-send.c: set CURLOPT_USE_SSL to CURLUSESSL_TRY + imap-send.c: support GIT_CURL_VERBOSE Now imap-send learned to talk to the server using cURL library, allow the same GIT_CURL_VERBOSE environment variable to control the verbosity of the chattering. * km/log-usage-string-i18n (2015-01-06) 1 commit (merged to 'next' on 2015-01-12 at 437bf8a) + log.c: fix translation markings * mm/complete-rebase-autostash (2015-01-07) 1 commit (merged to 'next' on 2015-01-12 at edcdead) + git-completion: add --autostash for 'git rebase' * po/doc-core-ignorestat (2015-01-12) 2 commits (merged to 'next' on 2015-01-12 at c660a71) + doc: core.ignoreStat update, and clarify the --assume-unchanged effect (merged to 'next' on 2014-12-23 at d2b3e84) + doc: core.ignoreStat clarify the --assume-unchanged effect * rc/for-each-ref-tracking (2015-01-12) 1 commit (merged to 'next' on 2015-01-12 at 94eef27) + for-each-ref: always check stat_tracking_info()'s return value * rh/autoconf-rhel3 (2015-01-09) 3 commits (merged to 'next' on 2015-01-12 at 57f125c) + configure.ac: check for HMAC_CTX_cleanup + configure.ac: check for clock_gettime and CLOCK_MONOTONIC + configure.ac: check 'tv_nsec' field in 'struct stat' Build update for older RHEL. * rh/hide-prompt-in-ignored-directory (2015-01-07) 2 commits (merged to 'next' on 2015-01-12 at 9aed017) + git-prompt.sh: allow to hide prompt for ignored pwd + git-prompt.sh: if pc mode, immediately set PS1 to a plain prompt * rh/test-color-avoid-terminfo-in-original-home (2015-01-07) 2 commits (merged to 'next' on 2015-01-12 at eac0b93) + test-lib.sh: do tests for color support after changing HOME + test-lib: use 'test ...' instead of '[ ... ]' We try to see if "tput" gives a useful result before switching TERM to dumb and moving HOME to point to our fake location for stability of the tests, and then use the command when coloring the output from the tests, but there is no guarantee "tput" works after switching HOME. * sp/subtree-doc (2015-01-06) 1 commit (merged to 'next' on 2015-01-12 at 7c488d6) + subtree: fix AsciiDoc list item continuation -- [New Topics] * ah/usage-strings (2015-01-14) 1 commit - standardize usage info string format Will merge to and cook in 'next'. * ak/cat-file-clean-up (2015-01-13) 1 commit - cat-file: use "type" and "size" from outer scope Will merge to 'next'. * ak/stash-store-create-help (2015-01-13) 1 commit - stash: show "create" and "store" subcommands in usage-help Undecided. * jk/blame-commit-label (2015-01-13) 5 commits - blame.c: fix garbled error message - use xstrdup_or_null to replace ternary conditionals - builtin/commit.c: use xstrdup_or_null instead of envdup - builtin/apply.c: use xstrdup_or_null instead of null_strdup - git-compat-util: add xstrdup_or_null helper Will merge to 'next'. * jk/http-push
Re: [PATCH 00/10] mark private symbols static
Regarding patch 1 - 9: Reviewed-by: Stefan Beller for what it's worth. -- 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: Big repo not shrinking on repack or gc?
On Thu, Jan 15, 2015 at 4:24 AM, Junio C Hamano wrote: > Andreas Krey writes: > >> On Wed, 14 Jan 2015 07:49:36 +, Jeff King wrote: >> ... >>> You don't need the "-f" here. Just "git repack -ad" should be enough >>> (and the "-f" probably makes it _way_ slower). >> >> Indeed, factor four. >> >> However, my expectation is that a repack -ad will remove all the >> old pack files, as what is in there is either referenced and put >> into the new pack, or dropped => there should be a single pack file >> afterwards. >> >> This is not the case. :-( (Done only with 1.8.2 due to >> lack of compilers for this box.) > > Guess in the dark: "ls -l .git/objects/pack" > Do you see any .keep files? I'm one of the Stash developers and just noticed this thread. If the repository in question has been forked via Stash there likely _will_ be .keep files. Stash uses alternates for forks, so it's possible, by deleting those kept packs and pruning objects (which you've already done I see) that you will corrupt, or have already corrupted, some number of the forks. (At the moment Stash packs "garbage" into a "dead pack" which it flags with a .keep, to ensure forks don't lose access to objects that once existed upstream that they still reference.) > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Bulk dump of git metadata / getting git metadata into a database
I'm wondering if anyone happens to know of software to dump all a git
repo's metadata, both stored and derived, to a format - sql, xml, csv,
whatever - that is easily importable into a database / manipulated
programmatically.
Background, for the interested:
There is git repo HAPPY and and a separate git repo with branch SAD.
Repo HAPPY is canonical; branch SAD is in a separate fork repo. Files
from HAPPY have been copied over on an irregular basis to SAD. So SAD
has a mixture of files that are exactly the same as (the one in some
commit to) HAPPY, and files that have diverged since the initial copy
over from HAPPY as per the needs of the SAD fork.
The end goal is to get a diff that shows only fork-specific changes.
Identify the common file ancestor, and then diff the most recent
fork'ed file against that. Or put another way:
(a) Remove any files from SAD's most recent commit that are exactly
the same as any commit to HAPPY.
(b) For each file still in SAD's most recent commit, walk backwards in
SAD until a version is found that exists in HAPPY.
For (a) the below two git commands plus a little scripting look like enough:
# HAPPY: Get all file hases for a repo
git verify-pack -v .git/objects/pack/*.idx > HAPPY.hashes
grep ' blob ' git.hashes | awk '{print $1}' > HAPPY.blobs
# SAD: Get hases and paths from current checkout
git ls-files --full-name -s | awk '{print $2" "$4}' > SAD.blobs
I haven't looked into (b) as much yet, but at the moment I'm thinking
of using git log to get a chronological list of commit hashes, then
walk backwards, at each checkout using git ls-files to dump the tree's
hashes to a separate file.
--
Daniel J Clark - off-list: djc @ first initial last name . us
--
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
Unused #include statements
Hello there, Since reading a post [1] about removing some unnecessary #include statements from a git C source file I've been intrigued to see how many more might be lurking in the code base. After a bit of digging around, my brute force approach of 'remove as many #includes as possible while making sure the code still successfully compiles' has returned the following results: $ git diff --stat alloc.c| 2 -- archive-zip.c | 1 - archive.c | 1 - argv-array.c | 1 - bisect.c | 9 - block-sha1/sha1.c | 2 -- branch.c | 1 - builtin/add.c | 7 --- builtin/annotate.c | 1 - builtin/apply.c| 8 builtin/archive.c | 3 --- builtin/bisect--helper.c | 2 -- builtin/blame.c| 13 - builtin/branch.c | 8 builtin/bundle.c | 1 - builtin/cat-file.c | 3 --- builtin/check-attr.c | 2 -- builtin/check-ignore.c | 2 -- builtin/check-mailmap.c| 2 -- builtin/check-ref-format.c | 2 -- builtin/checkout-index.c | 2 -- builtin/checkout.c | 11 --- builtin/clean.c| 3 --- builtin/clone.c| 10 -- builtin/column.c | 3 --- builtin/commit-tree.c | 4 builtin/commit.c | 13 - builtin/config.c | 1 - builtin/count-objects.c| 2 -- builtin/credential.c | 1 - builtin/describe.c | 5 - builtin/diff-files.c | 4 builtin/diff-index.c | 4 builtin/diff-tree.c| 4 builtin/diff.c | 6 -- builtin/fast-export.c | 8 builtin/fetch.c| 8 builtin/fmt-merge-msg.c| 6 -- builtin/for-each-ref.c | 6 -- builtin/fsck.c | 7 --- builtin/gc.c | 3 --- builtin/get-tar-commit-id.c| 3 --- builtin/grep.c | 6 -- builtin/hash-object.c | 2 -- builtin/help.c | 2 -- builtin/index-pack.c | 5 - builtin/init-db.c | 1 - builtin/interpret-trailers.c | 3 --- builtin/log.c | 14 -- builtin/ls-files.c | 3 --- builtin/ls-remote.c| 3 --- builtin/ls-tree.c | 3 --- builtin/mailinfo.c | 2 -- builtin/mailsplit.c| 3 --- builtin/merge-base.c | 5 - builtin/merge-file.c | 2 -- builtin/merge-index.c | 1 - builtin/merge-ours.c | 1 - builtin/merge-recursive.c | 3 --- builtin/merge-tree.c | 2 -- builtin/merge.c| 10 -- builtin/mktree.c | 2 -- builtin/mv.c | 4 builtin/name-rev.c | 3 --- builtin/notes.c| 4 builtin/pack-objects.c
Re: Unused #include statements
Hi Zoltan, I can't make a statement for the git project but I consider this kind of brute-force removal a very problematic approach for languages like C and C++. The reason for that is simple: Often header files include other header files since their content depends on those other header files. Let's assume a header file a.h includes b.h. Now consider a file c.c includes both a.h and b.h since they are actually using stuff from both of them. Your brute-force approach would now remove b.h since it is indirectly pulled in through a.h. While the removal would no lead to technially incorrect code it would no longer reflect the semantical situation (since c.c still uses stuff from b.h). Even worse is that if you later modify c.c to no longer use stuff from a.h you could no longer remove a.h since that way you would break the chain to b.h. Thus doing those kind of brute-force removals generally makes the include structure in a project very fragile. The analysis itself you did is still useful to identify header files that can potentially be removed but removing them without further analysis I would consider problematic. Robert -- 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: t5539 broken under Mac OS X
On Jan 14, 2015, at 13:17, Jeff King wrote: On Wed, Jan 14, 2015 at 08:50:47PM +0100, Torsten Bögershausen wrote: But, why does e.g. t0004 behave more gracefully (and skips) and t5539 just dies ? ./t0004-unwritable.sh ok 1 - setup ok 2 # skip write-tree should notice unwritable repository (missing SANITY of POSIXPERM,SANITY) The http code uses test_skip_or_die when it runs into setup errors. The intent there is that the user has either: 1. Told us explicitly that they want http tests by setting GIT_TEST_HTTPD=true. 2. Wants to run http tests if they can by setting GIT_TEST_HTTPD=auto (or leaving it unset, as that is the default). In case (1), we treat this as a test failure. They asked for httpd tests, and we could not run them. In case (2), we would just skip all of the tests. You may want to loosen your GIT_TEST_HTTPD setting (pre-83d842dc, you had to set it to true to run the tests at all, but nowadays we have auto). I ran into this problem. It seems like (at least on older Mac OS X) that the root directory is created like so: drwxrwxr-t 39 root admin / And since the first (and likely only user) on Mac OS X is a member of the admin group, the SANITY test fails and complains even though you're not running as root (the failure message is misleading). I ended up removing group write permission from / (which happened to find a bug in another script of mine) and then it was happy. -Kyle-- 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: Unused #include statements
On Thu, Jan 15, 2015 at 05:14:39AM +0100, Robert Schiele wrote: > Thus doing those kind of brute-force removals generally makes the > include structure in a project very fragile. The analysis itself you > did is still useful to identify header files that can potentially be > removed but removing them without further analysis I would consider > problematic. I would second that. Besides leading to a potentially fragile result, this analysis was done only for a particular platform with a particular set of config knobs. One of our rules is that git-compat-util.h (or one of the well-known headers which includes, cache.h or builtin.h) is included first in any translation unit. This gives git-compat-util the cleanest environment possible for making decisions, and lets macros it defines effect the rest of the code consistently. I suspect on modern platforms like Linux/glibc that it is not a huge deal to include git-compat-util a little late, simply because it does not have all that much to do. But on Solaris 8? Who knows. -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: Big repo not shrinking on repack or gc?
On Thu, 15 Jan 2015 12:23:00 +, Bryan Turner wrote: ... > > Guess in the dark: "ls -l .git/objects/pack" > > Do you see any .keep files? Lots of. :-( > I'm one of the Stash developers and just noticed this thread. If the > repository in question has been forked via Stash there likely _will_ > be .keep files. Stash uses alternates for forks, so it's possible, by > deleting those kept packs and pruning objects (which you've already > done I see) that you will corrupt, or have already corrupted, some > number of the forks. There are a few forks in this stash instance, but the repository in question is neither the source nor the destination of any. So, git seems to be mostly out of the equation now (gc and repack apparently doing what they are supposed to do), and the question moves to 'how can stash let such a repo grow to that size'. > (At the moment Stash packs "garbage" into a "dead > pack" which it flags with a .keep, to ensure forks don't lose access > to objects that once existed upstream that they still reference.) Does it do so in any case even if there is no actual fork? That would explain a lot - we are daily (force-)pushing new commit in there (and potentially big ones) that become garbage the next day, and should be cleaned up rather fast. (We're pulling them into another non-stash repo for longer-term keeping - these are backups of dev repos in the form of git stash commits including untracked files.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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 01/10] http.c: make finish_active_slot() and handle_curl_result() static
On Wed, Jan 14, 2015 at 03:40:46PM -0800, Junio C Hamano wrote: > No external callers exist. I think this is sensible. They used to be used directly by remote-curl.c for the smart-http protocol. But they got wrapped by run_one_slot in beed336 (http: never use curl_easy_perform, 2014-02-18). And I'd expect any future users to follow that route. -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 03/10] prompt.c: remove git_getpass() nobody uses
On Wed, Jan 14, 2015 at 03:40:48PM -0800, Junio C Hamano wrote:
> -char *git_getpass(const char *prompt)
> -{
> - return git_prompt(prompt, PROMPT_ASKPASS);
> -}
Yay. This was whittled down to a compatibility wrapper around the more
flexible git_prompt, waiting for the final callers to go away. That
happened in 791643a8, when imap-send learned to use the credential
interface.
-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 05/10] urlmatch.c: make match_urls() static
On Wed, Jan 14, 2015 at 03:40:50PM -0800, Junio C Hamano wrote: > No external callers exist. I think there was some notion that we might use this elsewhere (e.g., to harmonize the credential.* and http.* config matching rules). But I do not have any plans to work on that soon, and I am not even sure what interface would be needed, so it's reasonable to make this static in the interim. -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 08/10] pack-bitmap.c: make pack_bitmap_filename() static
On Wed, Jan 14, 2015 at 03:40:53PM -0800, Junio C Hamano wrote: > pack-bitmap.c | 28 ++-- > pack-bitmap.h | 1 - > 2 files changed, 14 insertions(+), 15 deletions(-) Looks good. I have some other not-yet-public bitmap stuff to send pending cleanup and testing, but I checked and none of it cares about this function. -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: Big repo not shrinking on repack or gc?
On Thu, Jan 15, 2015 at 5:38 PM, Andreas Krey wrote:
> On Thu, 15 Jan 2015 12:23:00 +, Bryan Turner wrote:
> ...
>> > Guess in the dark: "ls -l .git/objects/pack"
>> > Do you see any .keep files?
>
> Lots of. :-(
>
>> I'm one of the Stash developers and just noticed this thread. If the
>> repository in question has been forked via Stash there likely _will_
>> be .keep files. Stash uses alternates for forks, so it's possible, by
>> deleting those kept packs and pruning objects (which you've already
>> done I see) that you will corrupt, or have already corrupted, some
>> number of the forks.
>
> There are a few forks in this stash instance, but the repository in
> question is neither the source nor the destination of any.
>
> So, git seems to be mostly out of the equation now (gc and repack
> apparently doing what they are supposed to do), and the question
> moves to 'how can stash let such a repo grow to that size'.
>
>
>> (At the moment Stash packs "garbage" into a "dead
>> pack" which it flags with a .keep, to ensure forks don't lose access
>> to objects that once existed upstream that they still reference.)
>
> Does it do so in any case even if there is no actual fork? That would
> explain a lot - we are daily (force-)pushing new commit in there (and
> potentially big ones) that become garbage the next day, and should
> be cleaned up rather fast.
No, Stash will only do that in a repository which has been forked. In
any non-forked repository, Stash does not interact with garbage
collection in any way. Auto GC is left enabled, and all pruning
settings are left at their defaults. The default pruning interval is
two weeks, so if your development approach is rebase-heavy you may
need to adjust them.
What are the contents of some of those .keep files? If they're written
by Stash they contain a message saying so. ("GENERATED BY ATLASSIAN
STASH - DO NOT REMOVE")
>
> (We're pulling them into another non-stash repo for longer-term keeping -
> these are backups of dev repos in the form of git stash commits including
> untracked files.)
>
> Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds
> Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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 10/10] commit: show "Author:" hint when the ident is not given explicitly
On Wed, Jan 14, 2015 at 03:40:55PM -0800, Junio C Hamano wrote: > This is a knee-jerk response to two facts: > > - the author_ident_sufficiently_given() function is public but >nobody uses it; > > - a corresponding function committer_ident_sufficiently_given() is >used to determine when to add "Committer: " reminder in the log >message editor. > > The existing logic decides to show "Author:" reminder when the > author is different from the committer, so there won't be practical > difference other than we would end up showing both reminders when a > committer with iffy name derived from the heuristic is committing > her own patch. > > Which means this patch probably should be dropped. Yeah, I seem to recall going through this logic myself recently and coming to the same conclusion (probably while working on fac9083). I don't think it is really adding anything to the one case where it triggers (and in fact looks a bit worse, as the author information is redundant). -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 00/10] mark private symbols static
On Wed, Jan 14, 2015 at 03:40:45PM -0800, Junio C Hamano wrote: > Here are a handful of patches to make symbols that are only used > within a .c file as static. This is not the kind of changes we > would want to do in the pre-release freeze period, and it is just > for reference. I may later come back to them after 2.3 final is > tagged. I commented specifically on the ones that are in areas I touch a lot, but all of them look fine to me. -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: Big repo not shrinking on repack or gc?
On Thu, 15 Jan 2015 18:05:46 +, Bryan Turner wrote:
...
> No, Stash will only do that in a repository which has been forked. In
> any non-forked repository, Stash does not interact with garbage
> collection in any way. Auto GC is left enabled, and all pruning
> settings are left at their defaults. The default pruning interval is
> two weeks, so if your development approach is rebase-heavy you may
> need to adjust them.
>
> What are the contents of some of those .keep files? If they're written
> by Stash they contain a message saying so. ("GENERATED BY ATLASSIAN
> STASH - DO NOT REMOVE")
They do. So it seems it was forked once upon a time, but...
/opt/apps/atlassian/stash-data/shared/data/repositories $ grep ''
*/objects/info/alternates
158/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/20/objects
45/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/33/objects
93/objects/info/alternates:/data/opt_apps/atlassian/stash-data/shared/data/repositories/91/objects
...there is no trace of a fork still existing (the repo in question is 143).
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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
