Re: [PATCH v3] git-remote-mediawiki: bugfix for pages w/ 500 revisions
Benoit Person benoit.per...@gmail.com writes: contrib/mw-to-git/git-remote-mediawiki.perl | 14 -- contrib/mw-to-git/t/t9365-continuing-queries.sh | 23 +++ This version sounds all right. Thanks a lot, -- 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
Searching explanation of different diff algorithms
Is there any explanation available of the different merrits and drawbacks of the diff algorithms that Git supports? I'm not satisfied with the default diff but have enough processing power for a slower algorithm that might produce diffs that better show the intention of the edit. Thank you, Thomas Koch -- To unsubscribe from this list: send the line 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 clone -c core.sharedRepository=group not working as expected (git v1.8.4 linux/osx)
On Tue, Sep 24, 2013 at 12:06:43PM -0700, Jonathan Nieder wrote:
Part of the underlying problem is that unlike 'git init', 'git clone'
does not accept a --shared=(true|false|group|...) option. Worse, it
does accept a --shared option, with a completely different meaning.
No better option names are coming immediately to mind, but perhaps
someone on the list will have ideas that could let 'git clone' and
'git init' use the same --share-repository=group option?
Perhaps calling it something like --permissions would be good (IMHO,
that is more descriptive than --shared for git init). Then both can
respect it, and init maintains --shared for backwards compatibility.
Calling it --shared-repository does match the config name, but I do not
find that name especially descriptive. But perhaps it is good enough,
and consistency with the existing name is certainly a plus.
Another problem is that once the configuration is written, it is past
the point that some of the sharedrepository setting's effect would
have occured. The repository, including worktree, object dirs, and so
on has already been created without g+w and setgid bits set.
Yes. This is as-documented for clone -c, which claims to act after the
repository is initialized. That being said, I think it is less confusing
for the user for them to take effect as early as possible, so the user
doesn't have to worry.
I cannot think off-hand of any case where the user would actually want
the delayed effect.
Worse, when we write the new configuration and then re-read it, we
skip reading some repository-specific configuration
(core.{repositoryformatversion,sharedrepository,bare,worktree})
on the assumption that we should already know what their values would
be. That assumption is now wrong.
Yes, I think this is simply a bug in 84054f7 (clone: accept config
options on the command line), which assumed that any effects it had
would be picked up by the git_config() call.
I wonder if something like the following (just a sketch, completely
untested) would make sense.
diff --git i/builtin/clone.c w/builtin/clone.c
index 7ac677d..145a974 100644
--- i/builtin/clone.c
+++ w/builtin/clone.c
@@ -856,7 +856,11 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
init_db(option_template, INIT_DB_QUIET);
write_config(option_config);
+ if (option_bare)
+ git_config_set(core.bare, true);
+
git_config(git_default_config, NULL);
+ check_repository_format();
If we call check_repository_format() again, we will pick up the new
config. But I think we would still have to go back and fix the paths
created by init_db.
It may be cleaner to teach init_db to add the initial config (and
optionally add init -c for testing, though I do not think anyone
particularly cares in the real world).
-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: Local tag killer
On Tue, Sep 24, 2013 at 09:22:32AM -0400, Marc Branchaud wrote: If we instead moved to a default fetch refspec more like: [remote origin] fetch = +refs/*:refs/remotes/origin/refs/* I'm all for such a change. You no doubt recall the lengthy discussion about remote ref namespaces back in 2011 [1]. That arose while planning for 1.8, but my feeble recollection is that the change was considered too disruptive. It seems 2.0 would be a better home for such work. I do recall the discussion, though I did not review all of the complications before writing this most recent mail. I assume there are backwards compatibility issues lurking, and we may even need a config switch to flip between old-style and new-style modes (and leave it set to old-style at first, wait a while for people to have a git that understands both, and then flip the default to new-style). However, none of that is for Git 2.0. I do not think we have an exact date set for Git 2.0, but we already have several switches ready to be flipped. I think Junio's plan was to do it sooner rather than later, and not try to cram a bunch of last-minute compatibility breakages in. -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 checkout foo is getting confused by folder named foo
On 25 September 2013 04:51, David Aguilar dav...@gmail.com wrote: On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt j...@sahnwaldt.de wrote: Hi, maybe this has already been reported, but I didn't find it in the mail archive. If I understand correctly, after I clone a repo, I should be able to switch to branch foo just by running git checkout foo This doesn't seem to work if a folder called foo exists in the root of the repo. git checkout foo -- Thanks for the suggestion, but it doesn't work for me. With both 1.7.9.5 and 1.8.3.2, I get this: $ git checkout wiktionary -- fatal: invalid reference: wiktionary When I try the full branch name: $ git checkout origin/wiktionary -- Note: checking out 'origin/wiktionary'. You are in 'detached HEAD' state. You can [...] :-( Christopher The double-dash at the end disambiguates between refs and paths. You can use that trick on any command that accepts refspec (branches, tags, etc) and pathspec (path patterns). -- David -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Searching explanation of different diff algorithms
On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:
Is there any explanation available of the different merrits and drawbacks of
the diff algorithms that Git supports?
I'm not satisfied with the default diff but have enough processing power for
a
slower algorithm that might produce diffs that better show the intention of
the
edit.
It is not just question of algorithm, even definition how should most
readable diff look like is problematic, for example when large block is
rewritten and one line is unchanged then you get diff like
if (x){
- foo
+ bar
} else {
- foo
+ bar
}
but it is better to create following diff as it does not break flow of code.
if (x) {
- foo
-} else {
- foo
+ bar
+} else {
+ bar
}
--
To unsubscribe from this list: send the line 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: breakage in revision traversal with pathspec
On Fri, Sep 20, 2013 at 10:51:55AM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: My original question was going to be: why bother peeling at all if we are just going to push the outer objects, anyway? And after staring at it, I somehow convinced myself that the answer was that you were pushing both. But that is not the case. Sorry for the noise. But that is still a valid point, and the patch to avoid peeling for non symmetric diff does not look too bad, either. revision.c | 59 ++-- t/t6000-rev-list-misc.sh | 8 +++ 2 files changed, 45 insertions(+), 22 deletions(-) FWIW, the flow of this version makes more sense to me. It also allows things like: git rev-list --objects $blob..$tree which I cannot see anybody actually wanting, but it somehow seems simpler to me to say A..B is syntactic sugar for ^B A, without qualifying except that A and B must be commit-ishes. -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] sample pre-commit hook: Use --bool when retrieving config var
On Tue, Sep 24, 2013 at 9:22 PM, Jonathan Nieder jrnie...@gmail.com wrote: Johan Herland wrote: Signed-off-by: Johan Herland jo...@herland.net Thanks. What symptoms does this alleviate? Is this to allow configurations like [hooks] allowNonAscii = 1 and [hooks] allowNonAscii to do the expected thing, or is it something more subtle than that? Nothing subtle. Just what you list. And for consistency with the other sample hooks' use of git config. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
fast-forwarding tags
Hi! Linus favors one-time use signed tags, e.g. for_linus. Unfortunately if I push to such a tag without -f, I get an error (already exists). Would it make sense for there to be an option that makes it behave like a head, and allow fast-forward? -- MST -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
DO YOU NEED A LOAN EMAIL WITH NAME, COUNTRY, DURATION, AMOUNT, PHONE NUMBER. 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
[RFC/PATCH] checkout: allow dwim for branch creation for git checkout $branch --
The -- notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
A possible scenario is then:
git checkout $branch
= fails if $branch is both a ref and a file, and suggests --
git checkout $branch --
= refuses to create the $branch
This patch allows the second form to create $branch, and since the -- is
provided, it does not look for file named $branch.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
builtin/checkout.c | 32
t/t2024-checkout-dwim.sh | 22 ++
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 0f57397..f1f5915 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -863,6 +863,14 @@ static const char *unique_tracking_name(const char *name,
unsigned char *sha1)
return NULL;
}
+static int error_invalid_ref(const char *arg, int has_dash_dash, int argcount)
+{
+ if (has_dash_dash)
+ die(_(invalid reference: %s), arg);
+ else
+ return argcount;
+}
+
static int parse_branchname_arg(int argc, const char **argv,
int dwim_new_local_branch_ok,
struct branch_info *new,
@@ -916,20 +924,28 @@ static int parse_branchname_arg(int argc, const char
**argv,
if (!strcmp(arg, -))
arg = @{-1};
- if (get_sha1_mb(arg, rev)) {
- if (has_dash_dash) /* case (1) */
- die(_(invalid reference: %s), arg);
- if (dwim_new_local_branch_ok
- !check_filename(NULL, arg)
- argc == 1) {
+ if (get_sha1_mb(arg, rev)) { /* case (1)? */
+ int try_dwim = dwim_new_local_branch_ok;
+
+ if (check_filename(NULL, arg) !has_dash_dash)
+ try_dwim = 0;
+ /*
+* Accept git checkout foo and git checkout foo --
+* as candidates for dwim.
+*/
+ if (!(argc == 1 !has_dash_dash)
+ !(argc == 2 has_dash_dash))
+ try_dwim = 0;
+
+ if (try_dwim) {
const char *remote = unique_tracking_name(arg, rev);
if (!remote)
- return argcount;
+ return error_invalid_ref(arg, has_dash_dash,
argcount);
*new_branch = arg;
arg = remote;
/* DWIMmed to create local branch */
} else {
- return argcount;
+ return error_invalid_ref(arg, has_dash_dash, argcount);
}
}
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 094b92e..d9afdb2 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -164,4 +164,26 @@ test_expect_success 'checkout of branch from a single
remote succeeds #4' '
test_branch_upstream eggs repo_d eggs
'
+test_expect_success 'checkout of branch with a file having the same name
fails' '
+ git checkout -B master
+ test_might_fail git branch -D spam
+
+ spam
+ test_must_fail git checkout spam
+ test_must_fail git checkout spam
+ test_must_fail git rev-parse --verify refs/heads/spam
+ test_branch master
+'
+
+test_expect_success 'checkout branch -- succeeds, even if a file with the
same name exists' '
+ git checkout -B master
+ test_might_fail git branch -D spam
+
+ spam
+ git checkout spam --
+ test_branch spam
+ test_cmp_rev refs/remotes/extra_dir/repo_c/extra_dir/spam HEAD
+ test_branch_upstream spam repo_c spam
+'
+
test_done
--
1.8.4.475.g703937e.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout foo is getting confused by folder named foo
Jona Christopher Sahnwaldt j...@sahnwaldt.de writes: On 25 September 2013 04:51, David Aguilar dav...@gmail.com wrote: On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt j...@sahnwaldt.de wrote: Hi, maybe this has already been reported, but I didn't find it in the mail archive. If I understand correctly, after I clone a repo, I should be able to switch to branch foo just by running git checkout foo This doesn't seem to work if a folder called foo exists in the root of the repo. git checkout foo -- Thanks for the suggestion, but it doesn't work for me. With both 1.7.9.5 and 1.8.3.2, I get this: $ git checkout wiktionary -- fatal: invalid reference: wiktionary OK, what happens is that git checkout wiktionary is actually a shorthand for git checkout -b wiktionary --track origin/wiktionary. In other words, it does not only checkout the branch, but it creates a local branch with the right name, and checks it out. The -- disables this shorthand. I'd consider this as a bug. I've just sent a patch to try to fix this. When I try the full branch name: $ git checkout origin/wiktionary -- Note: checking out 'origin/wiktionary'. You are in 'detached HEAD' state. You can [...] This actually checks out the right commit, but does not create a local branch. That's not a very desirable solution. In short, this should do the trick: git checkout -b wiktionary --track origin/wiktionary -- 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: [RFC/PATCH] checkout: allow dwim for branch creation for git checkout $branch --
On Wed, Sep 25, 2013 at 7:49 PM, Matthieu Moy matthieu@imag.fr wrote:
static int parse_branchname_arg(int argc, const char **argv,
int dwim_new_local_branch_ok,
struct branch_info *new,
You may want to update the big comment block about all cases at the
beginning of this function.
@@ -916,20 +924,28 @@ static int parse_branchname_arg(int argc, const char
**argv,
if (!strcmp(arg, -))
arg = @{-1};
- if (get_sha1_mb(arg, rev)) {
- if (has_dash_dash) /* case (1) */
- die(_(invalid reference: %s), arg);
- if (dwim_new_local_branch_ok
- !check_filename(NULL, arg)
- argc == 1) {
+ if (get_sha1_mb(arg, rev)) { /* case (1)? */
+ int try_dwim = dwim_new_local_branch_ok;
+
+ if (check_filename(NULL, arg) !has_dash_dash)
+ try_dwim = 0;
+ /*
+* Accept git checkout foo and git checkout foo --
+* as candidates for dwim.
+*/
+ if (!(argc == 1 !has_dash_dash)
has_dash_dash is calculated as (argc 1) !strcmp(argv[1], --),
so when argc == 1, the has_dash_dash must be zero, the
!has_dash_dash is redundant. But it makes me wonder what we do with
git checkout abc def -- xyz. I think both old and new code do not
see -- as a separator like it should (and should also error about
multiple refs given). Maybe something worth fixing too while you're
updating this code.
+ !(argc == 2 has_dash_dash))
+ try_dwim = 0;
+
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister j...@szakmeister.net wrote: [snip] There's nothing objective about Nobody every (sic) agrees changes are good. If it were true, no changes would get in. It is true, where by changes I mean changes from common user's point of view, actually, a tiny amount of then do sneak in, so let me be precise: Virtually nobody ever agrees important changes from the common user's point of view are good. So now that I'm being clear, do tell, name one important change in Git from the user's point of view that happened in the last two years. Credential helpers. Also, you don't know that any of those changes would benefit 99% of all users. It's a guess or an estimate but it's not based on anything concrete. It might be a good guess--and in this case, I think it is--but it's not a concrete fact. Don't make it sound like it is. Sure, it's not a concrete fact, but the actual probability most likely follows a beta distribution with alpha=15 and beta=1. Is that more precise for you? It's not about precision, it's that you don't have any actual facts to stand on but you speak like you do. Then when someone questions it, you accuse them of being against fixes for the user. I wish you'd stop it and do something more constructive to help move things along. If you don't agree my comment is accurate, that's one thing, but labeling it as an attack is another. Don't turn it around. A number of your patches and emails poke at the community of the Git project and you know it. It's simply not helping the situation. Show me a patch that pokes at the community. All my patches have technical descriptions, and help improve Git. You're filtering what I said again. Take a look at the first message is this thread. I'll agree the patches themselves have been free of this, but the cover letters--which I consider to be part of the patch--and ensuing conversation has not. If you need another example, look at the cover letter for your transport helper patches. None of this is news to you. [snip] I would admit I was wrong if an /etc/gitconfig is indeed shipped by default, and agree that the Git project is indeed welcome to change, but that's not going to happen. And there it is again. Predicting the future now? Objectively and accurately? Please stop. Yes I am. Feel free to go back to this mail and tell me I was wrong when they do what I said they won't. I have no need for that, and I'm done talking to you about any of this. -John -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-grep.txt: add git ack alias to Examples section
The alias was from René Scharfe's Google+ post [1]. For reference when the Internet (or Google) is down: While grep is an indispensable tool if you're working with text files, some aspects of it could be improved. ack (or ack-grep, as it's called on Debian) has a few nice ideas in this regard. I especially like its presentation of search results from multiple files, which leaves more space for the actual file contents. And with the upcoming release 1.7.7 of git, its built-in grep command can dress up like ack and show search results in that nicer way, too. Run this (single line) command to add an alias that you can call as git ack ... [1] https://plus.google.com/104164106444631459594/posts Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- One of the few things I like about Clearcase is the examples section in their man pages, which contain very practical and often used commands. So I'd like to do the same way to git: start adding examples that are useful, not just ones that demonstrate difficult concepts or use cases. Those often used commands are likely popular aliases on the Internet. The next one that comes to mind after git ack is git lol. We probably won't add them all. Certain concensus is needed to keep examples from becoming a encyclopedia. Good or bad move? Documentation/git-grep.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt index 8497aa4..a4881e5 100644 --- a/Documentation/git-grep.txt +++ b/Documentation/git-grep.txt @@ -269,6 +269,12 @@ Examples Looks for a line that has `NODE` or `Unexpected` in files that have lines that match both. +`git -c color.grep.filename='bold green' -c color.grep.match='black yellow' grep --break --heading -n pattern`:: + Searches for `pattern` and produces output similar to ack(1). + Alternatively you could add an alias for frequent use: ++ +`git config --global --add alias.ack -c color.grep.filename='bold green' -c color.grep.match='black yellow' grep --break --heading -n` + GIT --- Part of the linkgit:git[1] suite -- 1.8.2.83.gc99314b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] build: add default aliases
n On Wed, Sep 25, 2013 at 8:33 AM, John Szakmeister j...@szakmeister.net wrote: On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras felipe.contre...@gmail.com wrote: On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister j...@szakmeister.net wrote: [snip] There's nothing objective about Nobody every (sic) agrees changes are good. If it were true, no changes would get in. It is true, where by changes I mean changes from common user's point of view, actually, a tiny amount of then do sneak in, so let me be precise: Virtually nobody ever agrees important changes from the common user's point of view are good. So now that I'm being clear, do tell, name one important change in Git from the user's point of view that happened in the last two years. Credential helpers. That's not a change, that's a new feature, and it could hardly be called important. By change I mean something that was one way before, and it's a different way now. But let me help you; you can't mention one, because there isn't any. Also, you don't know that any of those changes would benefit 99% of all users. It's a guess or an estimate but it's not based on anything concrete. It might be a good guess--and in this case, I think it is--but it's not a concrete fact. Don't make it sound like it is. Sure, it's not a concrete fact, but the actual probability most likely follows a beta distribution with alpha=15 and beta=1. Is that more precise for you? It's not about precision, it's that you don't have any actual facts to stand on but you speak like you do. Then when someone questions it, you accuse them of being against fixes for the user. I wish you'd stop it and do something more constructive to help move things along. I have as many facts as you or anybody does. If I cannot use the claim that 99% (or any overwhelming number) of users would benefit, then nobody can make the claim that X amount of users would be affected negatively, because the actual number can be close to or equal to 0. But one claim is more likely than the other. As for doing something more constructive to help move things along, what you don't get is that there is nothing to do to move things along. I send the patches, the patches are good, the patches should be applied. That's what any decently run project would do, concentrate on the technical side. Do you think if I hold hands with the people involved and we all sing Kumbaya things would move along? Well it shouldn't, if the patches are good the patches are good. What should move things along is the technical merits of the patch. If you don't agree my comment is accurate, that's one thing, but labeling it as an attack is another. Don't turn it around. A number of your patches and emails poke at the community of the Git project and you know it. It's simply not helping the situation. Show me a patch that pokes at the community. All my patches have technical descriptions, and help improve Git. You're filtering what I said again. Take a look at the first message is this thread. I'll agree the patches themselves have been free of this, but the cover letters--which I consider to be part of the patch--and ensuing conversation has not. If you need another example, look at the cover letter for your transport helper patches. I don't consider the cover letter part of the patch. And the conversation is irrelevant, all the users care about is the code. Not introducing a good feature for users because a developer said a nasty word (which I haven't) in the cover letter of the patch series is ridiculous. I would admit I was wrong if an /etc/gitconfig is indeed shipped by default, and agree that the Git project is indeed welcome to change, but that's not going to happen. And there it is again. Predicting the future now? Objectively and accurately? Please stop. Yes I am. Feel free to go back to this mail and tell me I was wrong when they do what I said they won't. I have no need for that, and I'm done talking to you about any of this. Doesn't matter, because it's not going to happen. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug] git show crashes with deepened shallow clone
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
When I execute the below script 'git show' crashes. 'git log --oneline -2' gives
for example:
3808bade5b76c4663ac4a3f751dc9f1ed0b08f2e three
error: Could not read 1e8777edeb2b7e757f74c789e679fc6c71073897
fatal: Failed to traverse parents of commit
0aa4ef86004f5bb29f67e971d7963f5cf430c668
gdb backtrace of one run is attached.
It happens on 32-bit Debian (5.0.10), 64-bit openSUSE (12.2), and Windows XP
with git 1.8.4
on all systems.
The help of 'git fetch' says:
--depth=depth
Deepen or shorten the history of a shallow repository created by git
clone with
--depth=depth option (see git-clone(1)) to the specified number of
commits from
the tip of each remote branch history. Tags for the deepened commits are
not fetched.
---^
But that's not true. The tag 'two' (from the script below) gets fetched when
deepening the repository.
---8---8---8---8---8---8---8---8---8---8---8---8---8---8---8
git init shallow-test
(cd shallow-test
echo foo file
git add file
git commit -mone
git tag -mone one
echo bar file
git commit -mtwo file
git tag -mtwo two
echo baz file
git commit -mthree file
git tag -mthree three )
git clone --depth=1 -b three file://`pwd`/shallow-test shallow-test-clone
(cd shallow-test-clone
git fetch --depth=2
git log --oneline -2 ;
git show two)
---8---8---8---8---8---8---8---8---8---8---8---8---8---8---8
Stefan
--
/dev/random says: The cost of feathers has risen... Now even DOWN is up!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
Core was generated by `/home/naewe/src/git/git show two'.
Program terminated with signal 11, Segmentation fault.
[New process 13783]
#0 read_object_with_reference (sha1=0x4 Address 0x4 out of bounds,
required_type_name=0x817ca97 tree, size=0xbfdfe3d8, actual_sha1_return=0x0)
at cache.h:697
697 memcpy(sha_dst, sha_src, 20);
#0 read_object_with_reference (sha1=0x4 Address 0x4 out of bounds,
required_type_name=0x817ca97 tree, size=0xbfdfe3d8, actual_sha1_return=0x0)
at cache.h:697
type = -1075846344
required_type = OBJ_TREE
buffer = (void *) 0x0
isize = value optimized out
actual_sha1 = \fãß¿\000\000\000\000¸âß¿±n\022\b¼`S\t
#1 0x081392bf in diff_tree_sha1 (old=0x4 Address 0x4 out of bounds,
new=0x95429cc A1þM3Í\205Ú\200Zɦi|\QÉ\023\210\034, base=0x8155ab9 ,
opt=0xbfdfe7e4) at tree-diff.c:277
tree1 = (void *) 0x954a9d0
tree2 = value optimized out
t1 = {
buffer = 0x1,
entry = {
sha1 = 0x0,
path = 0x0,
mode = 3219121144
},
size = 135386226
}
t2 = {
buffer = 0xbfdfe3e8,
entry = {
sha1 = 0x80c44cc é1ÿÿÿë\r, '\220' repeats 13 times,
U\211åW\211×V\211ÎS\203ì\034ÇEð,
path = 0x816d329 Could not read %s,
mode = 135991090
},
size = 3219121108
}
size1 = value optimized out
size2 = value optimized out
retval = value optimized out
#2 0x080f12d9 in log_tree_commit (opt=0xbfdfe530, commit=0x9536088) at
log-tree.c:778
log = {
commit = 0x9536088,
parent = 0x0
}
shown = 0
#3 0x08082dea in cmd_log_walk (rev=0xbfdfe530) at builtin/log.c:342
commit = (struct commit *) 0x9536088
saved_nrl = 0
saved_dcctc = 0
#4 0x080835cd in cmd_show (argc=2, argv=0xbfdfec28, prefix=0x0) at
builtin/log.c:566
o = (struct object *) 0x9536088
name = 0x952c390 two
rev = {
commits = 0x0,
pending = {
nr = 0,
alloc = 0,
objects = 0x0
},
boundary_commits = {
nr = 0,
alloc = 0,
objects = 0x0
},
cmdline = {
nr = 1,
alloc = 24,
rev = 0x952c9f8
},
prefix = 0x0,
def = 0x815364c HEAD,
prune_data = {
raw = 0x0,
nr = 0,
has_wildcard = 0,
recursive = 0,
max_depth = 0,
items = 0x0
},
sort_order = REV_SORT_IN_GRAPH_ORDER,
early_output = 0,
ignore_missing = 0,
dense = 1,
prune = 0,
no_walk = 1,
show_all = 0,
remove_empty_trees = 0,
simplify_history = 1,
topo_order = 0,
simplify_merges = 0,
simplify_by_decoration = 0,
tag_objects = 0,
tree_objects = 0,
blob_objects = 0,
verify_objects = 0,
edge_hint = 0,
limited = 0,
unpacked = 0,
boundary = 0,
count = 0,
left_right = 0,
left_only = 0,
right_only = 0,
rewrite_parents = 0,
print_parents = 0,
show_source = 0,
show_decorations = 0,
reverse = 0,
reverse_output_stage = 0,
cherry_pick = 0,
cherry_mark = 0,
bisect = 0,
ancestry_path = 0,
first_parent_only = 0,
line_level_traverse = 0,
diff = 1,
full_diff = 0,
show_root_diff = 1,
no_commit_id = 0,
verbose_header = 1,
Re: [PATCH v3] build: add default aliases
On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com writes: But let me help you; you can't mention one, because there isn't any. Or because you didn't really look. Read the release notes of every Git release these days, there's a big section about ongoing backward incompatible changes. I said *important* changes from the common user's point of view. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] build: add default aliases
Felipe Contreras felipe.contre...@gmail.com writes: On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com writes: But let me help you; you can't mention one, because there isn't any. Or because you didn't really look. Read the release notes of every Git release these days, there's a big section about ongoing backward incompatible changes. I said *important* changes from the common user's point of view. Call me fool, but I do consider the default behavior of git push as something important, indeed. -- 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 v3] build: add default aliases
On Wed, Sep 25, 2013 at 10:13 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com writes: On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com writes: But let me help you; you can't mention one, because there isn't any. Or because you didn't really look. Read the release notes of every Git release these days, there's a big section about ongoing backward incompatible changes. I said *important* changes from the common user's point of view. Call me fool, but I do consider the default behavior of git push as something important, indeed. Last time I checked nothing has changed, the default remains push.default=matching. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] git show crashes with deepened shallow clone
Am 25.09.2013 16:47, schrieb Stefan Näwe:
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
Seems to be somewhere between v1.8.3.1 (OK) and v1.8.3.2 (not OK) !!
When I execute the below script 'git show' crashes. 'git log --oneline -2'
gives
for example:
3808bade5b76c4663ac4a3f751dc9f1ed0b08f2e three
error: Could not read 1e8777edeb2b7e757f74c789e679fc6c71073897
fatal: Failed to traverse parents of commit
0aa4ef86004f5bb29f67e971d7963f5cf430c668
gdb backtrace of one run is attached.
It happens on 32-bit Debian (5.0.10), 64-bit openSUSE (12.2), and Windows XP
with git 1.8.4
on all systems.
The help of 'git fetch' says:
--depth=depth
Deepen or shorten the history of a shallow repository created by git
clone with
--depth=depth option (see git-clone(1)) to the specified number of
commits from
the tip of each remote branch history. Tags for the deepened commits
are not fetched.
---^
But that's not true. The tag 'two' (from the script below) gets fetched when
deepening the repository.
v1.8.3.1 fetches the tag also.
Stefan
--
/dev/random says: Pobody's Nerfect!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line 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: [Bug] git show crashes with deepened shallow clone
Am 25.09.2013 16:47, schrieb Stefan Näwe:
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
I'd marry 'git bisect' if I wasn't already... ;-)
This is what it gives me if I use my script (slightly modified to also run make)
with 'git bisect run':
6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f
Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Date: Sun May 26 08:16:15 2013 +0700
fetch-pack: prepare updated shallow file before fetching the pack
index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be led to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
git learns new global option --shallow-file to pass on the alternate
shallow file path. Undocumented (and not even support --shallow-file=
syntax) because it's unlikely to be used again elsewhere.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
:100644 100644 67bd5091be0b34bfea075cd60281d22cf5b34768
6e9c7cd9d5da7d24d4810b36039681f184325932 M commit.h
:100644 100644 f156dd4fac30cda4e09c508b7091cdb8d96917e2
6b5467c6dec9645f53d83cdad2467a158db622c0 M fetch-pack.c
:100644 100644 1ada169d5cff3051effee33c6f9ba5b9be15b2e6
88eef5a7cc6d36f6e17f4855945116dd6f1b0681 M git.c
:100644 100644 6be915f38f1fe8dbe0a22c4cd8ae2569331f483f
cbe2526d8c2b2643957eea2729a16269a7a74fab M shallow.c
:04 04 5333beeb4db3fc37c37e5a4d03816c4750ce6b28
3b0fb999b8655155cba24e2d09ebff29058d29d7 M t
bisect run success
Stefan
--
/dev/random says: Answers: $1 * Correct answers: $5 * Dumb looks: Free! *
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line 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: Searching explanation of different diff algorithms
On 2013-09-25 10:55, Ondřej Bílka wrote:
On Wed, Sep 25, 2013 at 09:24:15AM +0200, Thomas Koch wrote:
Is there any explanation available of the different merrits and drawbacks of
the diff algorithms that Git supports?
I'm not satisfied with the default diff but have enough processing power for
a
slower algorithm that might produce diffs that better show the intention of
the
edit.
It is not just question of algorithm, even definition how should most
readable diff look like is problematic, for example when large block is
rewritten and one line is unchanged then you get diff like
if (x){
- foo
+ bar
} else {
- foo
+ bar
}
but it is better to create following diff as it does not break flow of code.
if (x) {
- foo
-} else {
- foo
+ bar
+} else {
+ bar
}
I already asked the list for such a feature in the past[1].
I might be able to provide a rough/unfinished hack
that does exactly this in a few days after cleaning it up a bit.
It works like this:
If 2 hunks are separated by less than a certain count of lines and
those lines are identified as containing no interesting information
like {, }, /*, */, whitespace then the 2 hunks are fused together.
The hack is mainly lacking the following things:
* A way to identify boring lines.
(a like a list of boring keywords?, per filetype?)
* Configuration/commandline options to turn it on/off
* Tests
* Cleanup the code
Greetings Peter
[1] http://article.gmane.org/gmane.comp.version-control.git/207239/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.
Git for Windows crashes when clone Japanese multibyte repository. - Japanese Base Encoding is Shift-JIS. - It happens Japanese multibyte directory name and too-long directory path - Linux(ex. Ubuntu 13.04 amd64) can clone normally. - example repository is here: git clone https://github.com/wnoguchi/mingw-checkout-crash.git - The reproduce crash repository contains following file only. - following directory and file name is encoded for this commit log. - actually file name is decoded.] %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt - only one commit. This commit reduce gcc optimization level from O2 to O1 when MinGW Windows environment. Signed-off-by: Wataru Noguchi wnoguchi.0...@gmail.com --- git-compat-util.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index a31127f..394c23b 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -90,6 +90,8 @@ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include winsock2.h #include windows.h +/* reduce gcc optimization level to 1 */ +#pragma GCC optimize (O1) #define GIT_WINDOWS_NATIVE #endif -- 1.8.1.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] build: add default aliases
Felipe Contreras felipe.contre...@gmail.com writes: Last time I checked nothing has changed, the default remains push.default=matching. LOL. -- 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 v3] build: add default aliases
On Wed, Sep 25, 2013 at 11:05 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Felipe Contreras felipe.contre...@gmail.com writes: Last time I checked nothing has changed, the default remains push.default=matching. LOL. I'd take that as an admission that you don't have any examples of important changes in the past two years, at least. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] git show crashes with deepened shallow clone
Stefan Näwe stefan.naewe at atlas-elektronik.com writes: Am 25.09.2013 16:47, schrieb Stefan Näwe: This is what it gives me if I use my script (slightly modified to also run make) with 'git bisect run': 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit And to answer myself once more: That's fixed in 6da8bdc fetch-pack: do not remove .git/shallow file when --depth is not specified Sorry for all the noise. Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git gc leaving gc.pid files around
Hi, Since 64a99eb47, git gc creates a lock file gc.pid while running. I just noticed that the file is never deleted. The locking mechanism works, but leaving these files around creates a minor annoyance. For example, I run git gc in all my repos from time to time (in a cron job). It normally does nothing in repos that have not changed, but now, it updates the gc.pid file. As a result, all the gc.pid files show up in unison (synchronization tool between machines) for example. Is there any reason not to do something like this: --- a/builtin/gc.c +++ b/builtin/gc.c @@ -316,5 +316,6 @@ int cmd_gc(int argc, const char **argv, const char *prefix) warning(_(There are too many unreachable loose objects; run 'git prune' to remove them.)); + unlink(git_path(gc.pid)); return 0; } ? -- 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: [Bug] git show crashes with deepened shallow clone
Stefan Näwe wrote: Stefan Näwe stefan.naewe at atlas-elektronik.com writes: 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit And to answer myself once more: That's fixed in 6da8bdc fetch-pack: do not remove .git/shallow file when --depth is not specified Sorry for all the noise. No problem. It's probably worth releasing 1.8.4.1 soon. Thanks for a reminder. -- To unsubscribe from this list: send the line 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 gc leaving gc.pid files around
On Thu, Sep 26, 2013 at 1:29 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Hi, Since 64a99eb47, git gc creates a lock file gc.pid while running. I just noticed that the file is never deleted. The locking mechanism works, but leaving these files around creates a minor annoyance. For example, I run git gc in all my repos from time to time (in a cron job). It normally does nothing in repos that have not changed, but now, it updates the gc.pid file. As a result, all the gc.pid files show up in unison (synchronization tool between machines) for example. Is there any reason not to do something like this: --- a/builtin/gc.c +++ b/builtin/gc.c @@ -316,5 +316,6 @@ int cmd_gc(int argc, const char **argv, const char *prefix) warning(_(There are too many unreachable loose objects; run 'git prune' to remove them.)); + unlink(git_path(gc.pid)); return 0; } ? I considered this and decided it was not a big problem for another file lying around in .git. Moreover it could provide the last gc time to gc itself, so we could avoid running gc too often, for example no more than one gc a day. But if it causes actual annoyance, I think unlink() is ok. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] checkout: allow dwim for branch creation for git checkout $branch --
On Wed, Sep 25, 2013 at 8:52 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
@@ -925,7 +926,15 @@ static int parse_branchname_arg(int argc, const char
**argv,
return 1;
arg = argv[0];
- has_dash_dash = (argc 1) !strcmp(argv[1], --);
+ has_dash_dash = 0;
+ for (i = 0; i argc; i++) {
+ if (!strcmp(argv[i], --)) {
+ has_dash_dash = i;
+ break;
+ }
+ }
+ if (has_dash_dash = 2)
+ die(only one reference expected, %d given., has_dash_dash);
The translator in me says this string should be marked for translation
like others in git-checkout...
if (!strcmp(arg, -))
arg = @{-1};
diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
index 7cc0a35..2836a3e 100755
--- a/t/t2010-checkout-ambiguous.sh
+++ b/t/t2010-checkout-ambiguous.sh
@@ -47,4 +47,10 @@ test_expect_success 'disambiguate checking out from a
tree-ish' '
git diff --exit-code --quiet
'
+test_expect_success 'accurate error message with more than one ref' '
+ test_must_fail git checkout HEAD master -- 2actual
+ echo fatal: only one reference expected, 2 given. expect
+ test_cmp expect actual
+'
+
test_done
which makes C_LOCALE_OUTPUT a prerequisite for this test because it
needs the untranslated version of the string.
I'll resend, together with tweaks to the first patch.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
Duy
--
To unsubscribe from this list: send the line 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 checkout foo is getting confused by folder named foo
Jona Christopher Sahnwaldt j...@sahnwaldt.de writes: Hi everyone, tl;dr: The short form git checkout foo is a mess. There's simply too much DWIM magic going on. There are no comprehensible rules how it decides if foo is a pathspec or a refspec. There is a very simple rule: What's on the left hand side of -- are refs, what's on the right hand side are paths. When you don't use --, then Git tries to guess, and fails whenever there's an ambiguity. OK, what happens is that git checkout wiktionary is actually a shorthand for git checkout -b wiktionary --track origin/wiktionary. No, it isn't. What I meant was that the short form advised by people were _meant_ to be a shorthand. Let's consider several scenarios: I don't get your point. Is the overly long list a way of complaining? Are you suggesting a change? What do you think about the change I'm proposing? -- 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] git-compat-util.h: reduce optimization level to 1 on MinGW env.
(cc-ing the Git for Windows maintainers) Hi, Wataru Noguchi wrote: Git for Windows crashes when clone Japanese multibyte repository. - Japanese Base Encoding is Shift-JIS. - It happens Japanese multibyte directory name and too-long directory path - Linux(ex. Ubuntu 13.04 amd64) can clone normally. - example repository is here: git clone https://github.com/wnoguchi/mingw-checkout-crash.git - The reproduce crash repository contains following file only. - following directory and file name is encoded for this commit log. - actually file name is decoded.] %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt - only one commit. This commit reduce gcc optimization level from O2 to O1 when MinGW Windows environment. Signed-off-by: Wataru Noguchi wnoguchi.0...@gmail.com Thanks. --- git-compat-util.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index a31127f..394c23b 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -90,6 +90,8 @@ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include winsock2.h #include windows.h +/* reduce gcc optimization level to 1 */ +#pragma GCC optimize (O1) #define GIT_WINDOWS_NATIVE #endif Do you know why reducing the optimization level avoids a crash? Perhaps this is just masking the symptoms and the problem is still lurking. If changing the optimization level turns out to be the right fix, I would prefer to see this change made in the Makefile instead of git-compat-util.h. That way, the user building can still easily override the optimization settings to -O0 if they want to during a debugging session. What do you think? Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] checkout: allow dwim for branch creation for git checkout $branch --
The -- notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
A possible scenario is then:
git checkout $branch
= fails if $branch is both a ref and a file, and suggests --
git checkout $branch --
= refuses to create the $branch
This patch allows the second form to create $branch, and since the -- is
provided, it does not look for file named $branch.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
Since v1: added a paragraph in the block comment.
builtin/checkout.c | 38 ++
t/t2024-checkout-dwim.sh | 22 ++
2 files changed, 52 insertions(+), 8 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 0f57397..a5a12f6 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -863,6 +863,14 @@ static const char *unique_tracking_name(const char *name,
unsigned char *sha1)
return NULL;
}
+static int error_invalid_ref(const char *arg, int has_dash_dash, int argcount)
+{
+ if (has_dash_dash)
+ die(_(invalid reference: %s), arg);
+ else
+ return argcount;
+}
+
static int parse_branchname_arg(int argc, const char **argv,
int dwim_new_local_branch_ok,
struct branch_info *new,
@@ -881,6 +889,12 @@ static int parse_branchname_arg(int argc, const char
**argv,
* ref must be a valid tree, everything after the '--' must be
* a path.
*
+* A sub-case of (1) is git checkout ref --. In this
+* case, checkout behaves like case (3), except that it does
+* not attempt to understand ref as a file (hence, the
+* short-hand to create branch ref works even if ref
+* exists as a filename).
+*
* case 2: git checkout -- [paths]
*
* everything after the '--' must be paths.
@@ -916,20 +930,28 @@ static int parse_branchname_arg(int argc, const char
**argv,
if (!strcmp(arg, -))
arg = @{-1};
- if (get_sha1_mb(arg, rev)) {
- if (has_dash_dash) /* case (1) */
- die(_(invalid reference: %s), arg);
- if (dwim_new_local_branch_ok
- !check_filename(NULL, arg)
- argc == 1) {
+ if (get_sha1_mb(arg, rev)) { /* case (1)? */
+ int try_dwim = dwim_new_local_branch_ok;
+
+ if (check_filename(NULL, arg) !has_dash_dash)
+ try_dwim = 0;
+ /*
+* Accept git checkout foo and git checkout foo --
+* as candidates for dwim.
+*/
+ if (!(argc == 1 !has_dash_dash)
+ !(argc == 2 has_dash_dash))
+ try_dwim = 0;
+
+ if (try_dwim) {
const char *remote = unique_tracking_name(arg, rev);
if (!remote)
- return argcount;
+ return error_invalid_ref(arg, has_dash_dash,
argcount);
*new_branch = arg;
arg = remote;
/* DWIMmed to create local branch */
} else {
- return argcount;
+ return error_invalid_ref(arg, has_dash_dash, argcount);
}
}
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 094b92e..d9afdb2 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -164,4 +164,26 @@ test_expect_success 'checkout of branch from a single
remote succeeds #4' '
test_branch_upstream eggs repo_d eggs
'
+test_expect_success 'checkout of branch with a file having the same name
fails' '
+ git checkout -B master
+ test_might_fail git branch -D spam
+
+ spam
+ test_must_fail git checkout spam
+ test_must_fail git checkout spam
+ test_must_fail git rev-parse --verify refs/heads/spam
+ test_branch master
+'
+
+test_expect_success 'checkout branch -- succeeds, even if a file with the
same name exists' '
+ git checkout -B master
+ test_might_fail git branch -D spam
+
+ spam
+ git checkout spam --
+ test_branch spam
+ test_cmp_rev refs/remotes/extra_dir/repo_c/extra_dir/spam HEAD
+ test_branch_upstream spam repo_c spam
+'
+
test_done
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] checkout: proper error message on 'git checkout foo bar --'
The previous code was detecting the presence of -- by looking only at
argument 1. As a result, git checkout foo bar -- was interpreted as an
ambiguous file/revision list, and errored out with:
error: pathspec 'foo' did not match any file(s) known to git.
error: pathspec 'bar' did not match any file(s) known to git.
error: pathspec '--' did not match any file(s) known to git.
This patch fixes it by walking through the argument list to find the
--, and now complains about the number of references given.
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
+ die(only one reference expected, %d given.,
has_dash_dash);
The translator in me says this string should be marked for translation
like others in git-checkout...
Indeed. Sorry, it's not like I didn't knoW about _(...) /o\.
builtin/checkout.c| 11 ++-
t/t2010-checkout-ambiguous.sh | 6 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index a5a12f6..3dd45cc 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -882,6 +882,7 @@ static int parse_branchname_arg(int argc, const char **argv,
unsigned char branch_rev[20];
const char *arg;
int has_dash_dash;
+ int i;
/*
* case 1: git checkout ref -- [paths]
@@ -925,7 +926,15 @@ static int parse_branchname_arg(int argc, const char
**argv,
return 1;
arg = argv[0];
- has_dash_dash = (argc 1) !strcmp(argv[1], --);
+ has_dash_dash = 0;
+ for (i = 0; i argc; i++) {
+ if (!strcmp(argv[i], --)) {
+ has_dash_dash = i;
+ break;
+ }
+ }
+ if (has_dash_dash = 2)
+ die(_(only one reference expected, %d given.), has_dash_dash);
if (!strcmp(arg, -))
arg = @{-1};
diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
index 7cc0a35..ce6b6e2 100755
--- a/t/t2010-checkout-ambiguous.sh
+++ b/t/t2010-checkout-ambiguous.sh
@@ -47,4 +47,10 @@ test_expect_success 'disambiguate checking out from a
tree-ish' '
git diff --exit-code --quiet
'
+test_expect_success C_LOCALE_OUTPUT 'accurate error message with more than one
ref' '
+ test_must_fail git checkout HEAD master -- 2actual
+ echo fatal: only one reference expected, 2 given. expect
+ test_cmp expect actual
+'
+
test_done
--
1.8.4.474.g128a96c
--
To unsubscribe from this list: send the line 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 checkout foo is getting confused by folder named foo
On 25 September 2013 21:12, Matthieu Moy matthieu@grenoble-inp.fr wrote: Jona Christopher Sahnwaldt j...@sahnwaldt.de writes: Hi everyone, tl;dr: The short form git checkout foo is a mess. There's simply too much DWIM magic going on. There are no comprehensible rules how it decides if foo is a pathspec or a refspec. There is a very simple rule: What's on the left hand side of -- are refs, what's on the right hand side are paths. When you don't use --, then Git tries to guess, and fails whenever there's an ambiguity. That's the case I'm concerned with. And I think the guessing confuses users in many cases. It certainly has confused me. OK, what happens is that git checkout wiktionary is actually a shorthand for git checkout -b wiktionary --track origin/wiktionary. No, it isn't. What I meant was that the short form advised by people were _meant_ to be a shorthand. Let's consider several scenarios: I don't get your point. Is the overly long list a way of complaining? It's a way of showing that human beings can't understand git's guesswork. :-) It was also a (failed) attempt to understand the rules of this heuristic. And an attempt to show the developers that the rules have gotten out of hand. Are you suggesting a change? Yes, I think the rules for the short form (the guessing when there's no --) should be made simpler, or maybe the guessing should be dropped altogether. I don't know. I don't know git well enough to be able to be more specific. I just find the current behavior very confusing. What do you think about the change I'm proposing? I don't know. It looks like it's not really addressing my specific problem, because as far as I understand it only applies when there is a --. But again, I don't know git well enough. Anyway, thanks for your work. I'm sorry I can't provide more useful input. This short form of checkout is just a small feature. I guess I'm bikeshedding here. Cheers, JC -- 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] git-svn.txt: mention how to rebuild rev_map files
Hi, Keshav Kini wrote: The man page for `git svn` describes a situation in which 'git svn' will not be able to rebuild your .git/svn/**/.rev_map files, but no mention is made of in what circumstances `git svn` *will* be able to do so, or how to get `git svn` to do so. This patch adds some language to the description of the 'fetch' command to rectify this oversight, and also fixes an AsciiDoc escaping typo. Signed-off-by: Keshav Kini keshav.k...@gmail.com Good idea. [...] --- a/Documentation/git-svn.txt +++ b/Documentation/git-svn.txt @@ -103,9 +103,12 @@ COMMANDS 'fetch':: Fetch unfetched revisions from the Subversion remote we are - tracking. The name of the [svn-remote ...] section in the - .git/config file may be specified as an optional command-line - argument. + tracking. If necessary, rebuild the .git/svn/\*\*/.rev_map.* + files, given the requisite information exists in commit + messages (see the svn.noMetadata config option for more + information). The name of the [svn-remote ...] section in + the .git/config file may be specified as an optional + command-line argument. Taking a step back, the reader might wonder *why* he would want to run git svn fetch to rebuilt these .rev_map.* files, and what they are for. Perhaps there should be a separate REVISION MAP section describing this in more detail. Something as simple as FILES - .git/svn/\*\*/.rev_map.\*:: Mapping between Subversion revision numbers and Git commit names. Can be rebuilt using the git-svn-id: lines at the end of every commit as long as the noMetadata option is not set (see the 'svn.noMetadata' section above for details). + 'git svn fetch' and 'git svn rebase' automatically update the rev_map if it is missing or not up to date. 'git svn reset' automatically rewinds it. Then this reference in 'fetch' could just say something like ... argument. + This automatically updates the rev_map if needed (see '.git/svn/\*\*/.rev_map.\*' in the FILES section below for details). @@ -684,7 +687,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not I don't mind seeing this fix snuck into the same commit, but a separate commit that could be applied more quickly would be even better. ;-) Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line 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.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com wrote: Keshav Kini wrote: + tracking. If necessary, rebuild the .git/svn/\*\*/.rev_map.* + files, given the requisite information exists in commit + messages (see the svn.noMetadata config option for more + information). The name of the [svn-remote ...] section in + the .git/config file may be specified as an optional + command-line argument. Taking a step back, the reader might wonder *why* he would want to run git svn fetch to rebuilt these .rev_map.* files, and what they are for. Perhaps there should be a separate REVISION MAP section describing this in more detail. Something as simple as I agree with Jonathan's suggestions. Keshav: can you please resend with Jonathan's suggestions? Thanks both. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.
Hi, On Wed, 25 Sep 2013, Jonathan Nieder wrote: Wataru Noguchi wrote: - actually file name is decoded.] %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt This commit reduce gcc optimization level from O2 to O1 when MinGW Windows environment. Do you know why reducing the optimization level avoids a crash? I suspect that the optimization level causes smaller (or no) buffer bytes between data structures and the crash is the symptom of a buffer overflow. In that light, I think that reducing the optimization level is most likely just working around this particular issue, and other scenarios might still crash until we fix the underlying bug. Most likely the problem is with our Windows-specific UTF-8 handling, I would not be surprised if it is my favorite bug: an off-by-one. To find out what the real cause is, I suggest using a tool similar to valgrind. Valgrind does not run on Windows, but I DuckDuckWent e.g. http://code.google.com/p/drmemory/ as an alternative that could be tried to identify the problem. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git checkout foo is getting confused by folder named foo
Jona Christopher Sahnwaldt j...@sahnwaldt.de writes: Yes, I think the rules for the short form (the guessing when there's no --) should be made simpler, or maybe the guessing should be dropped altogether. I don't know. I don't know git well enough to be able to be more specific. I just find the current behavior very confusing. It can hardly be simpler (in the sense behavior that can be described with fewer words), but it could be tightened to be safer. When a remote branch $foo exists, a local branch $foo does not, and a file $foo does, then git checkout $foo rather likely means I want to use git checkout's DWIM and create local branch $foo, but it currently means to Git checkout file foo from the index. It would make sense to die here, and require the use of --. No time to write a patch for this. Any volunteer? -- 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 v2 1/2] checkout: allow dwim for branch creation for git checkout $branch --
Hi,
Matthieu Moy wrote:
The -- notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
Hm. I am not sure that was just an implementation side-effect.
Normally 'git checkout branch --' means Check out that branch,
and I mean it!. 'git checkout -- pattern' means Check out
these paths from the index, and I mean it! 'git checkout blah'
means Do what I mean.
On the other hand, if I want to do 'git checkout branch --'
while disabling the set up master to track origin/master magic,
I can use 'git checkout --no-track branch --'. So I think this
is a good change.
[...]
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -863,6 +863,14 @@ static const char *unique_tracking_name(const char
*name, unsigned char *sha1)
return NULL;
}
+static int error_invalid_ref(const char *arg, int has_dash_dash, int
argcount)
+{
+ if (has_dash_dash)
+ die(_(invalid reference: %s), arg);
+ else
+ return argcount;
+}
Style: I'd leave out the 'else'
if (has_dash_dash)
...
return argcount;
More importantly, what's the contract behind this function? Is there
a simpler explanation than If argument #2 is true, print a certain
message depending on argument #1; otherwise, return argument #3?.
If not, it might be clearer to inline it.
[...]
@@ -881,6 +889,12 @@ static int parse_branchname_arg(int argc, const char
**argv,
* ref must be a valid tree, everything after the '--' must be
* a path.
*
+ * A sub-case of (1) is git checkout ref --. In this
+ * case, checkout behaves like case (3), except that it does
+ * not attempt to understand ref as a file (hence, the
+ * short-hand to create branch ref works even if ref
+ * exists as a filename).
Maybe simpler to explain as a separate case?
case 1: git checkout ref -- paths
case 2: git checkout -- [paths]
case 3: git checkout something [--]
If something is a commit, [...]
If something is _not_ a commit, either -- is present or
something is not a path, no -t nor -b was given, and [...]
Otherwise, if -- is present, treat it like case (1).
Otherwise behave like case (4).
case 4: git checkout something paths
The first argument must not be ambiguous.
- If it's *only* a reference, [...]
[...]
@@ -916,20 +930,28 @@ static int parse_branchname_arg(int argc, const char
**argv,
if (!strcmp(arg, -))
arg = @{-1};
- if (get_sha1_mb(arg, rev)) {
+ if (get_sha1_mb(arg, rev)) { /* case (1)? */
The check means that we are most likely not in case (1), since arg isn't
a commit name, right?
- if (has_dash_dash) /* case (1) */
- die(_(invalid reference: %s), arg);
- if (dwim_new_local_branch_ok
- !check_filename(NULL, arg)
- argc == 1) {
- const char *remote = unique_tracking_name(arg, rev);
- if (!remote)
- return argcount;
+ int try_dwim = dwim_new_local_branch_ok;
+
+ if (check_filename(NULL, arg) !has_dash_dash)
+ try_dwim = 0;
+ /*
+ * Accept git checkout foo and git checkout foo --
+ * as candidates for dwim.
+ */
+ if (!(argc == 1 !has_dash_dash)
+ !(argc == 2 has_dash_dash))
+ try_dwim = 0;
+
+ if (try_dwim) {
+ const char *remote = unique_tracking_name(arg, rev);
+ if (!remote)
+ return error_invalid_ref(arg, has_dash_dash,
argcount);
This could be simplified by eliminating try_dwim local.
We are trying case (3) first:
if (dwim_new_local_branch_ok
(argc == 1 || (argc == 2 has_dash_dash))
(has_dash_dash || !check_filename(NULL, arg))) {
...
Then can come the invalid reference check for case (1):
} else if (has_dash_dash) /* case (1) */
die(...);
Then case (4).
else/* case (4) */
return argcount;
[...]
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -164,4 +164,26 @@ test_expect_success 'checkout of branch from a single
remote succeeds #4' '
test_branch_upstream eggs repo_d eggs
'
+test_expect_success 'checkout of branch with a file having the same name
fails' '
+ git checkout -B master
+ test_might_fail git branch -D spam
+
+ spam
+ test_must_fail git checkout spam
+ test_must_fail git checkout spam
Why twice?
+ test_must_fail
Re: [PATCH v2 2/2] checkout: proper error message on 'git checkout foo bar --'
Hi,
Matthieu Moy wrote:
error: pathspec 'foo' did not match any file(s) known to git.
error: pathspec 'bar' did not match any file(s) known to git.
error: pathspec '--' did not match any file(s) known to git.
This patch fixes it by walking through the argument list to find the
--, and now complains about the number of references given.
Good catch. Just some nits below.
[...]
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -882,6 +882,7 @@ static int parse_branchname_arg(int argc, const char
**argv,
unsigned char branch_rev[20];
const char *arg;
int has_dash_dash;
+ int i;
/*
* case 1: git checkout ref -- [paths]
@@ -925,7 +926,15 @@ static int parse_branchname_arg(int argc, const char
**argv,
return 1;
arg = argv[0];
- has_dash_dash = (argc 1) !strcmp(argv[1], --);
+ has_dash_dash = 0;
+ for (i = 0; i argc; i++) {
+ if (!strcmp(argv[i], --)) {
+ has_dash_dash = i;
+ break;
+ }
+ }
+ if (has_dash_dash = 2)
+ die(_(only one reference expected, %d given.), has_dash_dash);
(The argv[0] == -- case is handled a few lines above.)
At first I skipped the loop and read this as if (there are two or more
'--' arguments). How about doing one of the following to make it
easier to read quickly?
(a) rename has_dash_dash here to dash_dash_pos, or
(b) put the check in the loop, like so:
has_dash_dash = 0;
for (i = 0; i ...) {
if (strcmp(argv[i], --))
continue;
if (i == 0) /* case (2) */
return 1;
if (i 1)
die(_(only one reference expected ...);
has_dash_dash = 1;
break;
}
[...]
--- a/t/t2010-checkout-ambiguous.sh
+++ b/t/t2010-checkout-ambiguous.sh
@@ -47,4 +47,10 @@ test_expect_success 'disambiguate checking out from a
tree-ish' '
git diff --exit-code --quiet
'
+test_expect_success C_LOCALE_OUTPUT 'accurate error message with more than
one ref' '
+ test_must_fail git checkout HEAD master -- 2actual
+ echo fatal: only one reference expected, 2 given. expect
+ test_cmp expect actual
Nits:
- if we change this from 'fatal' to 'error' or reword the message as
part of a libification some day, it would be a nuisance to have to
update this test. Maybe a 'grep' could make it more flexible.
- most of the test (though not the interesting part) can run in the
!C_LOCALE_OUTPUT case if you use test_i18ncmp or test_i18ngrep
- even the check for 2 can run in the !C_LOCALE_OUTPUT case. :)
e.g. something like
test_must_fail ... 2actual
grep 2 actual
test_i18ngrep one reference expected, 2 given actual
Thanks,
Jonathan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
: -- Jacky Alciné - PGP: 201999FC http://jalcine.me signature.asc Description: This is a digitally signed message part.
Re: Local tag killer
On Tue, 24 Sep 2013, Jeff King wrote: On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote: I think it would be preferable if --prune would *not* affect tags, and if there were an extra option like --prune-tags that would have to be used explicitly to cause tags to be pruned. Would somebody object to such a change? I think most of this problem is the way that we fetch tags straight into the refs/tags hierarchy. You would not do: [remote origin] fetch = +refs/heads/*:refs/heads/* prune = true unless you wanted to be a pure-mirror, because you would hose your local changes any time you fetched. But that is _exactly_ what we do with a refs/tags/*:refs/tags/* fetch. If we instead moved to a default fetch refspec more like: [remote origin] fetch = +refs/*:refs/remotes/origin/refs/* Then everything would Just Work. If you prune what the other side has locally, that's fine. All you're doing is pruning your view of what he has, not anything you've done locally. The tricky part is tweaking the lookup rules so that origin/master still works, and that looking for v1.0 checks both refs/tags and refs/remotes/*/refs/tags. And of course managing backwards compatibility. :) Cheers !!! I remember participating to a discussion about this like 2.5 years ago: http://news.gmane.org/group/gmane.comp.version-control.git/thread=165799 The flat tag namespace remains my major annoyance with git IMHO. Nicolas -- To unsubscribe from this list: send the line 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.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com writes: Taking a step back, the reader might wonder *why* he would want to run git svn fetch to rebuilt these .rev_map.* files, and what they are for. Perhaps there should be a separate REVISION MAP section describing this in more detail. Something as simple as FILES - .git/svn/\*\*/.rev_map.\*:: Mapping between Subversion revision numbers and Git commit names. Can be rebuilt using the git-svn-id: lines at the end of every commit as long as the noMetadata option is not set (see the 'svn.noMetadata' section above for details). + 'git svn fetch' and 'git svn rebase' automatically update the rev_map if it is missing or not up to date. 'git svn reset' automatically rewinds it. Then this reference in 'fetch' could just say something like ... argument. + This automatically updates the rev_map if needed (see '.git/svn/\*\*/.rev_map.\*' in the FILES section below for details). Note that only the first two asterisks are escaped in my patch. For some reason, escaping all three causes a literal '\' to appear in asciidoc's output... I changed the wording of your first paragraph a bit according to what I thought it meant. Does it still convey what you wanted to convey, and is it still correct? Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details). Also, I'm having a bit of trouble trying to get a definition to start with a '.' character in AsciiDoc. Escaping the '.' produces a definition block, but with a literal '\' before the '.'. If I don't escape the '.', asciidoc thinks it's a section heading or something. Is asciidoc just incapable of doing this, or am I missing something? -Keshav -- To unsubscribe from this list: send the line 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 (Sep 2013, #08; Wed, 25)
What's cooking in git.git (Sep 2013, #08; Wed, 25) -- Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The fifth batch of topics are in 'master'. You can find the changes described here in the integration branches at git://repo.or.cz/git/jrn.git http://repo.or.cz/r/git/jrn.git Or view the web interface: http://repo.or.cz/w/git/jrn.git I'll probably be releasing 1.8.4.1 tomorrow. If you have time to experiment with maint or master to find any remaining problems until then, that will be very welcome. -- [Graduated to master] * bc/submodule-status-ignored (2013-09-11) 3 commits (merged to 'next' on 2013-09-11 at 9f66712) + Improve documentation concerning the status.submodulesummary setting (merged to 'next' on 2013-09-10 at a417960) + submodule: don't print status output with ignore=all + submodule: fix confusing variable name * bp/mediawiki-infinite-loop-fix (2013-09-23) 1 commit - git-remote-mediawiki: bugfix for pages w/ 500 revisions The mediawiki:: remote helper would hang while handling results from queries with more than 500 results against version 1.21 or newer of the Mediawiki server. * cc/replace-with-the-same-type (2013-09-09) 8 commits (merged to 'next' on 2013-09-17 at 34b5bb7) + Doc: 'replace' merge and non-merge commits + t6050-replace: use some long option names + replace: allow long option names + Documentation/replace: add Creating Replacement Objects section + t6050-replace: add test to clean up all the replace refs + t6050-replace: test that objects are of the same type + Documentation/replace: state that objects must be of the same type + replace: forbid replacing an object with one of a different type Using the replace mechanism to swap an object with another object of a different type can introduce inconsistency (e.g. a tree expects an object name to refer to a blob, but the blob object can be mistakenly or maliciously replaced with an object with a different type). Attempt to forbid such. * es/contacts-in-subdir (2013-09-17) 1 commit (merged to 'next' on 2013-09-20 at d67164f) + contacts: fix to work in subdirectories Allows the contacts (in contrib/) script to run from inside a subdirectory. * jc/push-cas (2013-09-20) 1 commit (merged to 'next' on 2013-09-20 at 5e1e7cc) + t5541: mark passing c-a-s test as success A touch-up to finish off a recently added feature. * jc/strcasecmp-pure-inline (2013-09-12) 1 commit (merged to 'next' on 2013-09-20 at 7142d08) + mailmap: work around implementations with pure inline strcasecmp Work around MinGW string.h header that does not declare strcasecmp whose address cannot be taken. * jk/shortlog-tolerate-broken-commit (2013-09-18) 1 commit (merged to 'next' on 2013-09-20 at 9c85c02) + shortlog: ignore commits with missing authors * kb/msvc-compile (2013-09-11) 5 commits (merged to 'next' on 2013-09-17 at a9bcbb5) + Windows: do not redefine _WIN32_WINNT + MinGW: Fix stat definitions to work with MinGW runtime version 4.0 + MSVC: fix stat definition hell + MSVC: fix compile errors due to macro redefinitions + MSVC: fix compile errors due to missing libintl.h Build updates for Windows port. * nd/fetch-pack-error-reporting-fix (2013-09-18) 1 commit (merged to 'next' on 2013-09-20 at fefa04f) + fetch-pack.c: show correct command name that fails When fetch-pack detected an error from spawned index-pack or unpack-objects, it did not report the failed program name correctly when a shallow repository is involved. * nd/unpack-entry-optim-in-pack-objects (2013-09-13) 1 commit (merged to 'next' on 2013-09-17 at 00f7335) + pack-objects: no crc check when the cached version is used The codepath to use data from packfiles that is only exercised in pack-objects unnecessarily checked crc checksum of the pack data, even when it ends up using in-core copy that it got by reading from the pack (at which point the checksum was validated). * sg/complete-untracked-filter (2013-09-19) 1 commit (merged to 'next' on 2013-09-20 at 798d0b9) + completion: improve untracked directory filtering for filename completion -- [New Topics] * bc/gnome-keyring (2013-09-23) 15 commits - contrib/git-credential-gnome-keyring.c: support really ancient gnome-keyring - contrib/git-credential-gnome-keyring.c: support ancient gnome-keyring - contrib/git-credential-gnome-keyring.c: report failure to store password - contrib/git-credential-gnome-keyring.c: use glib messaging functions - contrib/git-credential-gnome-keyring.c: use glib memory allocation functions - contrib/git-credential-gnome-keyring.c: use secure memory for reading passwords - contrib/git-credential-gnome-keyring.c: use secure memory functions for passwds -
Re: [PATCH] git-svn.txt: mention how to rebuild rev_map files
Keshav Kini wrote: I changed the wording of your first paragraph a bit according to what I thought it meant. Does it still convey what you wanted to convey, and is it still correct? Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details). Sounds good. Also, I'm having a bit of trouble trying to get a definition to start with a '.' character in AsciiDoc. Escaping the '.' produces a definition block, but with a literal '\' before the '.'. If I don't escape the '.', asciidoc thinks it's a section heading or something. Is asciidoc just incapable of doing this, or am I missing something? Oh. Yeah, this can be a pain. Quoting the filename with `backticks` might work. Writing $GIT_DIR instead of .git might be simpler (see v1.5.3.2~18 Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot, 2007-09-14). Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: [PATCH] git-compat-util.h: reduce optimization level to 1 on MinGW env.
Hi, I'm sorry resend email many times... My GMail setting default to HTML format. So mail sent to Git ML is rejected... Thanks for your reply. If changing the optimization level turns out to be the right fix, I would prefer to see this change made in the Makefile instead of git-compat-util.h. Yes, I see. I think so. I shuld write optimization level change code to Makefile instead of git-compat-util.h. 2013/9/26 Jonathan Nieder jrnie...@gmail.com: (cc-ing the Git for Windows maintainers) Hi, Wataru Noguchi wrote: Git for Windows crashes when clone Japanese multibyte repository. - Japanese Base Encoding is Shift-JIS. - It happens Japanese multibyte directory name and too-long directory path - Linux(ex. Ubuntu 13.04 amd64) can clone normally. - example repository is here: git clone https://github.com/wnoguchi/mingw-checkout-crash.git - The reproduce crash repository contains following file only. - following directory and file name is encoded for this commit log. - actually file name is decoded.] %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt - only one commit. This commit reduce gcc optimization level from O2 to O1 when MinGW Windows environment. Signed-off-by: Wataru Noguchi wnoguchi.0...@gmail.com Thanks. --- git-compat-util.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index a31127f..394c23b 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -90,6 +90,8 @@ #define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */ #include winsock2.h #include windows.h +/* reduce gcc optimization level to 1 */ +#pragma GCC optimize (O1) #define GIT_WINDOWS_NATIVE #endif Do you know why reducing the optimization level avoids a crash? Perhaps this is just masking the symptoms and the problem is still lurking. If changing the optimization level turns out to be the right fix, I would prefer to see this change made in the Makefile instead of git-compat-util.h. That way, the user building can still easily override the optimization settings to -O0 if they want to during a debugging session. What do you think? Hope that helps, Jonathan Hi, Thanks for your advise. To find out what the real cause is, I suggest using a tool similar to valgrind. Valgrind does not run on Windows, but I DuckDuckWent e.g. http://code.google.com/p/drmemory/ as an alternative that could be tried to identify the problem. I will try debugging by using any tools more real cause. * Valgrind and drmemory, etc. 2013/9/26 Johannes Schindelin johannes.schinde...@gmx.de: Hi, On Wed, 25 Sep 2013, Jonathan Nieder wrote: Wataru Noguchi wrote: - actually file name is decoded.] %E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%201-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%202-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%203-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%204-long-long-long-dirname/%E6%97%A5%E6%9C%AC%E8%AA%9E%E3%83%87%E3%82%A3%E3%83%AC%E3%82%AF%E3%83%88%E3%83%AA%205-long-long-long-dirname/%E3%81%AF%E3%81%98%E3%82%81%E3%81%AB%E3%81%8A%E8%AA%AD%E3%81%BF%E3%81%8F%E3%81%A0%E3%81%95%E3%81%84.txt This commit reduce gcc optimization level from O2 to O1 when MinGW Windows environment. Do you know why reducing the optimization level avoids a crash? I suspect that the optimization level causes smaller (or no) buffer bytes between data structures and the crash is the symptom of a buffer overflow. In that light, I think that reducing the optimization level is most likely just working around this particular issue, and other scenarios might still crash until we fix the underlying bug. Most likely the problem is with our Windows-specific UTF-8 handling, I would not be surprised if it is my favorite bug: an off-by-one. To find out what the real cause is, I suggest using a tool similar to valgrind. Valgrind does not run on Windows, but I DuckDuckWent e.g. http://code.google.com/p/drmemory/ as an alternative that could be tried to identify the problem. Ciao, Johannes Thanks! -- === Wataru Noguchi
Re: [PATCH] git-svn.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com writes: Keshav Kini wrote: I changed the wording of your first paragraph a bit according to what I thought it meant. Does it still convey what you wanted to convey, and is it still correct? Mapping between Subversion revision numbers and Git commit names. In a repository where the noMetadata option is not set, this can be rebuilt from the git-svn-id: lines that are at the end of every commit (see the 'svn.noMetadata' section above for details). Sounds good. Also, I'm having a bit of trouble trying to get a definition to start with a '.' character in AsciiDoc. Escaping the '.' produces a definition block, but with a literal '\' before the '.'. If I don't escape the '.', asciidoc thinks it's a section heading or something. Is asciidoc just incapable of doing this, or am I missing something? Oh. Yeah, this can be a pain. Quoting the filename with `backticks` might work. Writing $GIT_DIR instead of .git might be simpler (see v1.5.3.2~18 Documentation/git-config.txt: AsciiDoc tweak to avoid leading dot, 2007-09-14). Good point. Actually it seems to me that writing $GIT_DIR is in fact more correct, since $GIT_DIR need not be .git at all. So I'll just use that. Reroll coming up in a bit. -Keshav -- To unsubscribe from this list: send the line 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] test-dump: new test program to examine binary data
This will come handy for verifying binary files like .pack, .idx or
$GIT_DIR/index. For now the only supported command is ntohl. This
command looks into the given file at the given offset, do ntohl() and
return the value in decimal.
More commands may be added later to decode varint, or decompress a
zlib stream and so on...
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
.gitignore| 1 +
Makefile | 1 +
test-dump.c (new) | 27 +++
3 files changed, 29 insertions(+)
create mode 100644 test-dump.c
diff --git a/.gitignore b/.gitignore
index 2e2ae2b..6d835e2 100644
--- a/.gitignore
+++ b/.gitignore
@@ -182,6 +182,7 @@
/test-ctype
/test-date
/test-delta
+/test-dump
/test-dump-cache-tree
/test-scrap-cache-tree
/test-genrandom
diff --git a/Makefile b/Makefile
index af2e3e3..a07a194 100644
--- a/Makefile
+++ b/Makefile
@@ -560,6 +560,7 @@ TEST_PROGRAMS_NEED_X += test-chmtime
TEST_PROGRAMS_NEED_X += test-ctype
TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
+TEST_PROGRAMS_NEED_X += test-dump
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
TEST_PROGRAMS_NEED_X += test-genrandom
TEST_PROGRAMS_NEED_X += test-index-version
diff --git a/test-dump.c b/test-dump.c
new file mode 100644
index 000..71c6f8f
--- /dev/null
+++ b/test-dump.c
@@ -0,0 +1,27 @@
+#include cache.h
+
+static inline uint32_t ntoh_l_force_align(void *p)
+{
+ uint32_t x;
+ memcpy(x, p, sizeof(x));
+ return ntohl(x);
+}
+
+int main(int ac, char **av)
+{
+ unsigned char *p;
+ int fd = open(av[2], O_RDONLY);
+ struct stat st;
+ if (lstat(av[2], st))
+ return 1;
+ p = mmap(0, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (p == (unsigned char*)MAP_FAILED)
+ return 2;
+ if (!strcmp(av[1], ntohl))
+ printf(%u\n, ntoh_l_force_align(p + atoi(av[3])));
+ else {
+ fprintf(stderr, unknown command %s\n, av[1]);
+ return 3;
+ }
+ return 0;
+}
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line 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] pack v4 UI support
This adds - clone, fetch and repack learn --pack-version (backends also learn new options, check out the patches for details) - core.preferredPackVersion to specify the default pack version for fetch, clone, repack and the receiver of push. This config is supposed to be used by porcelain commands only (with the exception of receive-pack). All other plumbing will default to pack v2 forever. - git and remote helper protocols learn about packv4 capabilities I think the UI changes for pack v4 are done with this series. Well, git-bundle needs --pack-version too but it's not part of core user interaction. The remaining work for v4 would be optimization (that includes multi-base tree support) and more v4 tests. Let me know if I missed anything here. I'm aware that repack is being rewritten in C, so it'll cause conflicts when np/pack-v4 is re-pulled to 'pu' again. I suggest that the new tests in t7700 are marked failed at the merge. We can add --pack-version to the C-based repack and enable the tests later. About the packv4 capability in git protocol. I considered a more generic cap packver=ver[,ver[,ver...]] that represents all supported versions, with the order of preference from the first ver (most preferred) to the last (least preferred). But it adds more parsing code and frankly I don't think we'll have pack v5 in the next five years. So I dropped it. Multi-base tree support is not part of packv4 capability. Let's see if such support comes before the series is merged to master. If so we can drop that line from protocol-capabilities.txt. Otherwise a new capability can be added for multi-base trees. Another capability could be added for sending the actual number of objects in a thin pack for more accurate display in index-pack. Low priority in my opinion. There's also the pack conversion issue. Suppose the client requests v4 but, for performance purposes, the server sends v2. Should index-pack convert the received pack to v4? My answer is no because there's no way we can do it without saving v2 first. And if we have to save v2 anyway, pack-objects (or repack) will do the conversion better. We can adjust git-gc to maybe repack more often when the number of v2 packs is over a limit, or just repack v2 packs into one v4 pack. Nguyễn Thái Ngọc Duy (10): test-dump: new test program to examine binary data config: add core.preferredPackVersion upload-pack: new capability to send pack v4 fetch: new option to set preferred pack version for transfer clone: new option to set preferred pack version for transfer fetch: pack v4 support on smart http receive-pack: request for packv4 if it's the preferred version send-pack: support pack v4 repack: add --pack-version and fall back to core.preferredPackVersion count-objects: report pack v4 usage .gitignore| 1 + Documentation/config.txt | 5 Documentation/fetch-options.txt | 5 Documentation/git-clone.txt | 4 +++ Documentation/git-count-objects.txt | 4 +++ Documentation/git-fetch-pack.txt | 4 +++ Documentation/git-repack.txt | 6 +++- Documentation/gitremote-helpers.txt | 3 ++ Documentation/technical/protocol-capabilities.txt | 14 + Makefile | 1 + builtin/clone.c | 19 builtin/count-objects.c | 23 +-- builtin/fetch-pack.c | 7 + builtin/fetch.c | 10 +++ builtin/receive-pack.c| 3 +- cache.h | 1 + config.c | 5 environment.c | 1 + fetch-pack.c | 3 ++ fetch-pack.h | 1 + git-repack.sh | 8 +- remote-curl.c | 14 - send-pack.c | 5 send-pack.h | 1 + t/t5510-fetch.sh | 13 + t/t5516-fetch-push.sh | 12 t/t5551-http-fetch.sh | 9 ++ t/t5601-clone.sh | 12 t/t7700-repack.sh | 35 +++ test-dump.c (new) | 27 + transport-helper.c| 3 ++ transport.c | 4 +++ transport.h | 5 upload-pack.c | 16 +-- 34 files changed, 274 insertions(+), 10
[PATCH 02/10] config: add core.preferredPackVersion
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 5 +
cache.h | 1 +
config.c | 5 +
environment.c| 1 +
4 files changed, 12 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..6e7037b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -644,6 +644,11 @@ core.abbrev::
for abbreviated object names to stay unique for sufficiently long
time.
+core.preferredPackVersion::
+ This is the preferred pack format version for various operations
+ that may produce pack files such as clone, fetch, push or repack.
+ Valid values are 2 and 4. The default value is 2.
+
add.ignore-errors::
add.ignoreErrors::
Tells 'git add' to continue adding files when some files cannot be
diff --git a/cache.h b/cache.h
index b68ad5a..20c2d6d 100644
--- a/cache.h
+++ b/cache.h
@@ -597,6 +597,7 @@ extern int fsync_object_files;
extern int core_preload_index;
extern int core_apply_sparse_checkout;
extern int precomposed_unicode;
+extern int core_default_pack_version;
/*
* The character that begins a commented line in user-editable file
diff --git a/config.c b/config.c
index e13a7b6..02af0d1 100644
--- a/config.c
+++ b/config.c
@@ -831,6 +831,11 @@ static int git_default_core_config(const char *var, const
char *value)
return 0;
}
+ if (!strcmp(var, core.preferredpackversion)) {
+ core_default_pack_version = git_config_int(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5398c36..24c43ba 100644
--- a/environment.c
+++ b/environment.c
@@ -62,6 +62,7 @@ int merge_log_config = -1;
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
struct startup_info *startup_info;
unsigned long pack_size_limit_cfg;
+int core_default_pack_version = 2;
/*
* The character that begins a commented line in user-editable file
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line 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] upload-pack: new capability to send pack v4
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/technical/protocol-capabilities.txt | 10 ++
upload-pack.c | 16 +---
2 files changed, 23 insertions(+), 3 deletions(-)
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
index fd8ffa5..be09792 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -217,3 +217,13 @@ allow-tip-sha1-in-want
If the upload-pack server advertises this capability, fetch-pack may
send want lines with SHA-1s that exist at the server but are not
advertised by upload-pack.
+
+packv4
+--
+
+The upload-server can generate .pack version 4. If the client accepts
+this capability, the server may send a pack version 4. The server can
+choose to send pack version 2 even if the client accepts this
+capability.
+
+This capability does not include multi-base tree support.
diff --git a/upload-pack.c b/upload-pack.c
index ccf76d9..291d366 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -32,7 +32,7 @@ static unsigned long oldest_have;
static int multi_ack;
static int no_done;
-static int use_thin_pack, use_ofs_delta, use_include_tag;
+static int use_thin_pack, use_ofs_delta, use_include_tag, packv4_ok;
static int no_progress, daemon_mode;
static int allow_tip_sha1_in_want;
static int shallow_nr;
@@ -140,7 +140,7 @@ static void create_pack_file(void)
corruption on the remote side.;
int buffered = -1;
ssize_t sz;
- const char *argv[10];
+ const char *argv[11];
int arg = 0;
argv[arg++] = pack-objects;
@@ -157,6 +157,14 @@ static void create_pack_file(void)
argv[arg++] = --delta-base-offset;
if (use_include_tag)
argv[arg++] = --include-tag;
+ /*
+* The client may have requested pack v4. But if this is a v2
+* repo on a busy machine, we may want to send v2 and let the
+* client do the v2-v4 conversion to reduce the cost on the
+* server side.
+*/
+ if (packv4_ok)
+ argv[arg++] = --version=4;
argv[arg++] = NULL;
memset(pack_objects, 0, sizeof(pack_objects));
@@ -633,6 +641,8 @@ static void receive_needs(void)
no_progress = 1;
if (parse_feature_request(features, include-tag))
use_include_tag = 1;
+ if (parse_feature_request(features, packv4))
+ packv4_ok = 1;
o = parse_object(sha1_buf);
if (!o)
@@ -738,7 +748,7 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
{
static const char *capabilities = multi_ack thin-pack side-band
side-band-64k ofs-delta shallow no-progress
-include-tag multi_ack_detailed;
+include-tag multi_ack_detailed packv4;
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line 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] fetch: new option to set preferred pack version for transfer
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/fetch-options.txt | 5 +
builtin/fetch.c | 10 ++
fetch-pack.c| 3 +++
fetch-pack.h| 1 +
t/t5510-fetch.sh| 13 +
transport.c | 4
transport.h | 5 +
7 files changed, 41 insertions(+)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index ba1fe49..47d55e5 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -17,6 +17,11 @@
Convert a shallow repository to a complete one, removing all
the limitations imposed by shallow repositories.
+--pack-version=n::
+ Define the preferred pack format version for data transfer.
+ Valid values are 2 and 4. Default value is specified by
+ core.preferredPackVersion setting. See linkgit:git-config[1].
+
ifndef::git-pull[]
--dry-run::
Show what would be done, without making any changes.
diff --git a/builtin/fetch.c b/builtin/fetch.c
index d784b2e..695fbf1 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -31,6 +31,7 @@ enum {
};
static int all, append, dry_run, force, keep, multiple, prune, update_head_ok,
verbosity;
+static int pack_version;
static int progress = -1, recurse_submodules = RECURSE_SUBMODULES_DEFAULT;
static int tags = TAGS_DEFAULT, unshallow;
static const char *depth;
@@ -90,6 +91,8 @@ static struct option builtin_fetch_options[] = {
{ OPTION_STRING, 0, recurse-submodules-default,
recurse_submodules_default, NULL,
N_(default mode for recursion), PARSE_OPT_HIDDEN },
+ OPT_INTEGER(0, pack-version, pack_version,
+ N_(preferred pack version for transfer)),
OPT_END()
};
@@ -957,6 +960,8 @@ static int fetch_one(struct remote *remote, int argc, const
char **argv)
set_option(TRANS_OPT_KEEP, yes);
if (depth)
set_option(TRANS_OPT_DEPTH, depth);
+ if (pack_version == 4)
+ set_option(TRANS_OPT_PACKV4, yes);
if (argc 0) {
int j = 0;
@@ -1010,6 +1015,11 @@ int cmd_fetch(int argc, const char **argv, const char
*prefix)
argc = parse_options(argc, argv, prefix,
builtin_fetch_options, builtin_fetch_usage, 0);
+ if (!pack_version)
+ pack_version = core_default_pack_version;
+ if (pack_version != 2 pack_version != 4)
+ die(_(invalid pack version %d), pack_version);
+
if (unshallow) {
if (depth)
die(_(--depth and --unshallow cannot be used
together));
diff --git a/fetch-pack.c b/fetch-pack.c
index 6684348..16aa3d0 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -324,6 +324,7 @@ static int find_common(struct fetch_pack_args *args,
if (args-no_progress) strbuf_addstr(c,
no-progress);
if (args-include_tag) strbuf_addstr(c,
include-tag);
if (prefer_ofs_delta) strbuf_addstr(c, ofs-delta);
+ if (args-packv4) strbuf_addstr(c, packv4);
if (agent_supported)strbuf_addf(c, agent=%s,
git_user_agent_sanitized());
packet_buf_write(req_buf, want %s%s\n, remote_hex,
c.buf);
@@ -869,6 +870,8 @@ static struct ref *do_fetch_pack(struct fetch_pack_args
*args,
args-no_progress = 0;
if (!server_supports(include-tag))
args-include_tag = 0;
+ if (!server_supports(packv4))
+ args-packv4 = 0;
if (server_supports(ofs-delta)) {
if (args-verbose)
fprintf(stderr, Server supports ofs-delta\n);
diff --git a/fetch-pack.h b/fetch-pack.h
index 40f08ba..5f03739 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -17,6 +17,7 @@ struct fetch_pack_args {
no_progress:1,
include_tag:1,
stateless_rpc:1,
+ packv4:1,
check_self_contained_and_connected:1,
self_contained_and_connected:1;
};
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index fde6891..d3da088 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -512,4 +512,17 @@ test_expect_success 'all boundary commits are excluded' '
test_bundle_object_count .git/objects/pack/pack-${pack##pack}.pack 3
'
+test_expect_success 'fetch --pack-version=4' '
+ git init pv4
+ (
+ cd pv4
+ git fetch --pack-version=4 --keep file://$D/.git
+ P=`ls .git/objects/pack/pack-*.pack`
+ # Offset 4 is pack version
+ test-dump ntohl $P 4 ver.actual
+ echo 4 ver.expected
+ test_cmp ver.expected ver.actual
+
[PATCH 09/10] repack: add --pack-version and fall back to core.preferredPackVersion
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-repack.txt | 6 +-
git-repack.sh| 8 +++-
t/t7700-repack.sh| 35 +++
3 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 4c1aff6..c43eb4a 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -9,7 +9,7 @@ git-repack - Pack unpacked objects in a repository
SYNOPSIS
[verse]
-'git repack' [-a] [-A] [-d] [-f] [-F] [-l] [-n] [-q] [--window=n]
[--depth=n]
+'git repack' [options]
DESCRIPTION
---
@@ -110,6 +110,10 @@ other objects in that pack they already have locally.
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
+--pack-version=version::
+ Force the version for the generated pack.
+ Valid values are 2 and 4. Default value is specified by
+ core.preferredPackVersion setting. See linkgit:git-config[1].
Configuration
-
diff --git a/git-repack.sh b/git-repack.sh
index 7579331..0d898eb 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -21,12 +21,13 @@ window= size of the window used for delta
compression
window-memory= same as the above, but limit memory size instead of entries
count
depth= limits the maximum delta depth
max-pack-size= maximum size of each packfile
+pack-version= format version of the output pack
SUBDIRECTORY_OK='Yes'
. git-sh-setup
no_update_info= all_into_one= remove_redundant= unpack_unreachable=
-local= no_reuse= extra=
+local= no_reuse= extra= packver=
while test $# != 0
do
case $1 in
@@ -43,6 +44,8 @@ do
-l) local=--local ;;
--max-pack-size|--window|--window-memory|--depth)
extra=$extra $1=$2; shift ;;
+ --pack-version)
+ packver=$2; shift ;;
--) shift; break;;
*) usage ;;
esac
@@ -92,6 +95,9 @@ esac
mkdir -p $PACKDIR || exit
+[ -n $packver ] || packver=`git config --int core.preferredPackVersion`
+[ -n $packver ] args=$args --version=$packver
+
args=$args $local ${GIT_QUIET:+-q} $no_reuse$extra
names=$(git pack-objects --keep-true-parents --honor-pack-keep --non-empty
--all --reflog $args /dev/null $PACKTMP) ||
exit 1
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index d954b84..8383e1b 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -164,5 +164,40 @@ test_expect_success 'objects made unreachable by grafts
only are kept' '
git cat-file -t $H1
'
+test_expect_success 'repack respects core.preferredPackVersion' '
+ git init pv4
+ (
+ unset GIT_TEST_PACKV4
+ cd pv4
+ test_commit one
+ test_commit two
+ test_commit three
+ git config core.preferredPackVersion 4
+ git repack -ad
+ P=`ls .git/objects/pack/pack-*.pack`
+ # Offset 4 is pack version
+ test-dump ntohl $P 4 ver.actual
+ echo 4 ver.expected
+ test_cmp ver.expected ver.actual
+ )
+'
+
+test_expect_success 'repack --pack-version=4' '
+ git init pv4.2
+ (
+ unset GIT_TEST_PACKV4
+ cd pv4.2
+ test_commit one
+ test_commit two
+ test_commit three
+ git repack -ad --pack-version=4
+ P=`ls .git/objects/pack/pack-*.pack`
+ # Offset 4 is pack version
+ test-dump ntohl $P 4 ver.actual
+ echo 4 ver.expected
+ test_cmp ver.expected ver.actual
+ )
+'
+
test_done
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line 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 08/10] send-pack: support pack v4
Contrary to the fetch direction, whether send-pack sends packv4 is
totally controlled by the server. This is in favor of lowering load at
the server side. More logic may be added later to allow the client to
stick to v2 even if the server requests v4.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
send-pack.c | 5 +
send-pack.h | 1 +
t/t5516-fetch-push.sh | 12
3 files changed, 18 insertions(+)
diff --git a/send-pack.c b/send-pack.c
index 7d172ef..977c14b 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -44,6 +44,7 @@ static int pack_objects(int fd, struct ref *refs, struct
extra_have_objects *ext
NULL,
NULL,
NULL,
+ NULL,
};
struct child_process po;
int i;
@@ -57,6 +58,8 @@ static int pack_objects(int fd, struct ref *refs, struct
extra_have_objects *ext
argv[i++] = -q;
if (args-progress)
argv[i++] = --progress;
+ if (args-packv4)
+ argv[i++] = --version=4;
memset(po, 0, sizeof(po));
po.argv = argv;
po.in = -1;
@@ -205,6 +208,8 @@ int send_pack(struct send_pack_args *args,
quiet_supported = 1;
if (server_supports(agent))
agent_supported = 1;
+ if (server_supports(packv4))
+ args-packv4 = 1;
if (!remote_refs) {
fprintf(stderr, No refs in common and none specified; doing
nothing.\n
diff --git a/send-pack.h b/send-pack.h
index 05d7ab1..cda770c 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -11,6 +11,7 @@ struct send_pack_args {
use_thin_pack:1,
use_ofs_delta:1,
dry_run:1,
+ packv4:1,
stateless_rpc:1;
};
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 4691d51..d0c116f 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -1172,4 +1172,16 @@ test_expect_success 'push --follow-tag only pushes
relevant tags' '
test_cmp expect actual
'
+test_expect_success 'push pack v4' '
+ git init pv4
+ git --git-dir pv4/.git config core.preferredPackVersion 4
+ git --git-dir pv4/.git config transfer.unpackLimit 1
+ git push pv4 HEAD:refs/heads/head
+ P=`ls pv4/.git/objects/pack/pack-*.pack`
+ # Offset 4 is pack version
+ test-dump ntohl $P 4 ver.actual
+ echo 4 ver.expected
+ test_cmp ver.expected ver.actual
+'
+
test_done
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line 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] fetch: pack v4 support on smart http
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-fetch-pack.txt| 4
Documentation/gitremote-helpers.txt | 3 +++
builtin/fetch-pack.c| 7 +++
remote-curl.c | 14 +-
t/t5551-http-fetch.sh | 9 +
transport-helper.c | 3 +++
6 files changed, 39 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index 1e71754..b68cd45 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -87,6 +87,10 @@ be in a separate packet, and the list must end with a flush
packet.
'git-upload-pack' treats the special depth 2147483647 as
infinite even if there is an ancestor-chain that long.
+--pack-version=n::
+ Define the preferred pack format version for data transfer.
+ Valid values are 2 and 4. Default is 2.
+
--no-progress::
Do not show the progress.
diff --git a/Documentation/gitremote-helpers.txt
b/Documentation/gitremote-helpers.txt
index 0827f69..90dfc2e 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -416,6 +416,9 @@ set by Git if the remote helper has the 'option' capability.
must not rely on this option being set before
connect request occurs.
+'option packv4 \{'true'|'false'\}::
+ Prefer pack version 4 (true) or 2 (false) for data transfer.
+
SEE ALSO
linkgit:git-remote[1]
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index aba4465..bfe940a 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -100,6 +100,13 @@ int cmd_fetch_pack(int argc, const char **argv, const char
*prefix)
pack_lockfile_ptr = pack_lockfile;
continue;
}
+ if (!prefixcmp(arg, --pack-version=)) {
+ int ver = strtol(arg + 15, NULL, 0);
+ if (ver != 2 ver != 4)
+ die(_(invalid pack version %d), ver);
+ args.packv4 = ver == 4;
+ continue;
+ }
usage(fetch_pack_usage);
}
diff --git a/remote-curl.c b/remote-curl.c
index 5b3ce9e..1a3d215 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -18,6 +18,7 @@ struct options {
unsigned progress : 1,
followtags : 1,
dry_run : 1,
+ packv4 : 1,
thin : 1;
};
static struct options options;
@@ -67,6 +68,15 @@ static int set_option(const char *name, const char *value)
return -1;
return 0;
}
+ else if (!strcmp(name, packv4)) {
+ if (!strcmp(value, true))
+ options.packv4 = 1;
+ else if (!strcmp(value, false))
+ options.packv4 = 0;
+ else
+ return -1;
+ return 0;
+ }
else {
return 1 /* unsupported */;
}
@@ -654,7 +664,7 @@ static int fetch_git(struct discovery *heads,
struct strbuf preamble = STRBUF_INIT;
char *depth_arg = NULL;
int argc = 0, i, err;
- const char *argv[15];
+ const char *argv[16];
argv[argc++] = fetch-pack;
argv[argc++] = --stateless-rpc;
@@ -676,6 +686,8 @@ static int fetch_git(struct discovery *heads,
depth_arg = strbuf_detach(buf, NULL);
argv[argc++] = depth_arg;
}
+ if (options.packv4)
+ argv[argc++] = --pack-version=4;
argv[argc++] = url;
argv[argc++] = NULL;
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 55a866a..5b4e6aa 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -222,5 +222,14 @@ test_expect_success EXPENSIVE 'clone the 50,000 tag repo
to check OS command lin
)
'
+test_expect_success 'clone http repository with pack v4' '
+ git -c transfer.unpackLimit=1 clone --pack-version=4
$HTTPD_URL/smart/repo.git pv4
+ P=`ls pv4/.git/objects/pack/pack-*.pack`
+ # Offset 4 is pack version
+ test-dump ntohl $P 4 ver.actual
+ echo 4 ver.expected
+ test_cmp ver.expected ver.actual
+'
+
stop_httpd
test_done
diff --git a/transport-helper.c b/transport-helper.c
index 63cabc3..07fbf6e 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -350,6 +350,9 @@ static int fetch_with_fetch(struct transport *transport,
standard_options(transport);
+ set_helper_option(transport, packv4,
+ data-transport_options.packv4 ? true : false);
+
for (i = 0; i nr_heads; i++) {
const struct ref *posn = to_fetch[i];
if (posn-status REF_STATUS_UPTODATE)
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line unsubscribe git in
the body of
[PATCH 05/10] clone: new option to set preferred pack version for transfer
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-clone.txt | 4
builtin/clone.c | 19 +++
t/t5601-clone.sh| 12
3 files changed, 35 insertions(+)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 450f158..6299a70 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -217,6 +217,10 @@ objects from the source repository into a pack in the
cloned repository.
The result is Git repository can be separated from working
tree.
+--pack-version=n::
+ Define the preferred pack format version for data transfer.
+ Valid values are 2 and 4. Default value is specified by
+ core.preferredPackVersion setting. See linkgit:git-config[1].
repository::
The (possibly remote) repository to clone from. See the
diff --git a/builtin/clone.c b/builtin/clone.c
index 430307b..9c0e296 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -46,6 +46,7 @@ static const char *real_git_dir;
static char *option_upload_pack = git-upload-pack;
static int option_verbosity;
static int option_progress = -1;
+static int pack_version;
static struct string_list option_config;
static struct string_list option_reference;
@@ -98,6 +99,8 @@ static struct option builtin_clone_options[] = {
N_(separate git dir from working tree)),
OPT_STRING_LIST('c', config, option_config, N_(key=value),
N_(set config inside the new repository)),
+ OPT_INTEGER(0, pack-version, pack_version,
+ N_(preferred pack version for transfer)),
OPT_END()
};
@@ -764,6 +767,11 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
usage_msg_opt(_(You must specify a repository to clone.),
builtin_clone_usage, builtin_clone_options);
+ if (!pack_version)
+ pack_version = core_default_pack_version;
+ if (pack_version != 2 pack_version != 4)
+ die(_(invalid pack version %d), pack_version);
+
if (option_single_branch == -1)
option_single_branch = option_depth ? 1 : 0;
@@ -794,6 +802,8 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
is_local = option_local != 0 path !is_bundle;
if (is_local option_depth)
warning(_(--depth is ignored in local clones; use file://
instead.));
+ if (is_local pack_version == 4)
+ warning(_(--pack-version is ignored in local clones; use
file:// instead.));
if (option_local 0 !is_local)
warning(_(--local is ignored));
@@ -868,6 +878,12 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
} else {
strbuf_addf(branch_top, refs/remotes/%s/, option_origin);
}
+ if (pack_version != core_default_pack_version) {
+ struct strbuf sb = STRBUF_INIT;
+ strbuf_addf(sb, %d, pack_version);
+ git_config_set(core.preferredPackVersion, sb.buf);
+ strbuf_release(sb);
+ }
strbuf_addf(value, +%s*:%s*, src_ref_prefix, branch_top.buf);
strbuf_addf(key, remote.%s.url, option_origin);
@@ -903,6 +919,9 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
transport_set_option(transport, TRANS_OPT_UPLOADPACK,
option_upload_pack);
+ if (pack_version == 4)
+ transport_set_option(transport, TRANS_OPT_PACKV4,
yes);
+
if (transport-smart_options !option_depth)
transport-smart_options-check_self_contained_and_connected = 1;
}
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 0629149..8118524 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -285,4 +285,16 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path
foo:bar' '
git clone ./foo:bar foobar
'
+test_expect_success 'clone --pack-version=4' '
+ git clone --pack-version=4 --no-local src pv4
+ P=`ls pv4/.git/objects/pack/pack-*.pack`
+ # Offset 4 is pack version
+ test-dump ntohl $P 4 ver.actual
+ echo 4 ver.expected
+ test_cmp ver.expected ver.actual
+ git --git-dir=pv4/.git config --int core.preferredPackVersion
cfgver.actual
+ echo 4 cfgver.expected
+ test_cmp cfgver.expected cfgver.actual
+'
+
test_done
--
1.8.2.82.gc24b958
--
To unsubscribe from this list: send the line 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] receive-pack: request for packv4 if it's the preferred version
This is the only plumbing command that is controlled by core.preferredPackVersion so far. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Documentation/technical/protocol-capabilities.txt | 4 builtin/receive-pack.c| 3 ++- 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt index be09792..32153cd 100644 --- a/Documentation/technical/protocol-capabilities.txt +++ b/Documentation/technical/protocol-capabilities.txt @@ -226,4 +226,8 @@ this capability, the server may send a pack version 4. The server can choose to send pack version 2 even if the client accepts this capability. +The receive-pack server advertises this capability if it wants to +receive the pack in format version 4 and the client should send in +this format. + This capability does not include multi-base tree support. diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c index e3eb5fc..288b0bc 100644 --- a/builtin/receive-pack.c +++ b/builtin/receive-pack.c @@ -130,10 +130,11 @@ static void show_ref(const char *path, const unsigned char *sha1) if (sent_capabilities) packet_write(1, %s %s\n, sha1_to_hex(sha1), path); else - packet_write(1, %s %s%c%s%s agent=%s\n, + packet_write(1, %s %s%c%s%s%s agent=%s\n, sha1_to_hex(sha1), path, 0, report-status delete-refs side-band-64k quiet, prefer_ofs_delta ? ofs-delta : , +core_default_pack_version == 4 ? packv4 : , git_user_agent_sanitized()); sent_capabilities = 1; } -- 1.8.2.82.gc24b958 -- To unsubscribe from this list: send the line 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] count-objects: report pack v4 usage
An ideal repository is v4 only, no v2 packs. Show pack v4 statistics
so people know if the repository is mixed with v2 and repack it. Note
that in-pack and size-pack include all pack versions, not just v2.
Only display v4 info when there are v4 packs. It's still experimental
so don't polute the output with v4 that's never used by 99.99% of
users. We can make it unconditional later when v4 is officially
supported and recommended.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-count-objects.txt | 4
builtin/count-objects.c | 23 ---
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-count-objects.txt
b/Documentation/git-count-objects.txt
index b300e84..d15b4dc 100644
--- a/Documentation/git-count-objects.txt
+++ b/Documentation/git-count-objects.txt
@@ -28,8 +28,12 @@ size: disk space consumed by loose objects, in KiB (unless
-H is specified)
+
in-pack: the number of in-pack objects
+
+in-packv4: the number of objects in packs version 4
++
size-pack: disk space consumed by the packs, in KiB (unless -H is specified)
+
+size-packv4: disk space consumed by the packs version 4
++
prune-packable: the number of loose objects that are also present in
the packs. These objects could be pruned using `git prune-packed`.
+
diff --git a/builtin/count-objects.c b/builtin/count-objects.c
index a7f70cb..db73ce7 100644
--- a/builtin/count-objects.c
+++ b/builtin/count-objects.c
@@ -89,7 +89,7 @@ int cmd_count_objects(int argc, const char **argv, const char
*prefix)
const char *objdir = get_object_directory();
int len = strlen(objdir);
char *path = xmalloc(len + 50);
- unsigned long loose = 0, packed = 0, packed_loose = 0;
+ unsigned long loose = 0, packed_loose = 0;
off_t loose_size = 0;
struct option opts[] = {
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -119,10 +119,12 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
}
if (verbose) {
struct packed_git *p;
- unsigned long num_pack = 0;
- off_t size_pack = 0;
+ unsigned long num_pack = 0, num_pack_v4 = 0;
+ unsigned long packed = 0, packed_v4 = 0;
+ off_t size_pack = 0, size_pack_v4 = 0;
struct strbuf loose_buf = STRBUF_INIT;
struct strbuf pack_buf = STRBUF_INIT;
+ struct strbuf pack_buf_v4 = STRBUF_INIT;
struct strbuf garbage_buf = STRBUF_INIT;
if (!packed_git)
prepare_packed_git();
@@ -134,17 +136,25 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
packed += p-num_objects;
size_pack += p-pack_size + p-index_size;
num_pack++;
+ if (p-version == 4) {
+ packed_v4 += p-num_objects;
+ size_pack_v4 += p-pack_size + p-index_size;
+ num_pack_v4++;
+ }
}
if (human_readable) {
strbuf_humanise_bytes(loose_buf, loose_size);
strbuf_humanise_bytes(pack_buf, size_pack);
+ strbuf_humanise_bytes(pack_buf_v4, size_pack_v4);
strbuf_humanise_bytes(garbage_buf, size_garbage);
} else {
strbuf_addf(loose_buf, %lu,
(unsigned long)(loose_size / 1024));
strbuf_addf(pack_buf, %lu,
(unsigned long)(size_pack / 1024));
+ strbuf_addf(pack_buf_v4, %lu,
+ (unsigned long)(size_pack_v4 / 1024));
strbuf_addf(garbage_buf, %lu,
(unsigned long)(size_garbage / 1024));
}
@@ -152,13 +162,20 @@ int cmd_count_objects(int argc, const char **argv, const
char *prefix)
printf(count: %lu\n, loose);
printf(size: %s\n, loose_buf.buf);
printf(in-pack: %lu\n, packed);
+ if (num_pack_v4)
+ printf(in-packv4: %lu\n, packed_v4);
printf(packs: %lu\n, num_pack);
+ if (num_pack_v4)
+ printf(v4-packs: %lu\n, num_pack_v4);
printf(size-pack: %s\n, pack_buf.buf);
+ if (num_pack_v4)
+ printf(size-packv4: %s\n, pack_buf_v4.buf);
printf(prune-packable: %lu\n, packed_loose);
printf(garbage: %lu\n, garbage);
printf(size-garbage: %s\n, garbage_buf.buf);
strbuf_release(loose_buf);
strbuf_release(pack_buf);
+ strbuf_release(pack_buf_v4);
Re: [PATCH] git-svn.txt: mention how to rebuild rev_map files
Jonathan Nieder jrnie...@gmail.com writes: @@ -684,7 +687,7 @@ svn-remote.name.noMetadata:: + This option can only be used for one-shot imports as 'git svn' will not be able to fetch again without metadata. Additionally, -if you lose your .git/svn/**/.rev_map.* files, 'git svn' will not +if you lose your .git/svn/\*\*/.rev_map.* files, 'git svn' will not I don't mind seeing this fix snuck into the same commit, but a separate commit that could be applied more quickly would be even better. ;-) May I also roll into said commit a couple of replacements of .git with $GIT_DIR in the same file, or other such minor touchups? -Keshav -- To unsubscribe from this list: send the line 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] pack v4 UI support
On Thu, Sep 26, 2013 at 11:51 AM, Nicolas Pitre n...@fluxnic.net wrote: Multi-base tree support is not part of packv4 capability. Let's see if such support comes before the series is merged to master. If so we can drop that line from protocol-capabilities.txt. Otherwise a new capability can be added for multi-base trees. What is that for? Multi-base trees are not created yet, but the code to parse them is already there. So I don't see the point of having a capability in the protocol for this. pv4_get_tree() can. index-pack cannot. Another capability could be added for sending the actual number of objects in a thin pack for more accurate display in index-pack. Low priority in my opinion. That just cannot be communicated during capability exchange. This number is known only after object enumeration. Hence my suggestion of a ['T', 'H', 'I', 'N', htonl(number_of_sent_objects)] special header prepended to the actual pack on the wire. And that has to be decided before formalizing the pack v4 capability. That makes it a somewhat higher priority. The capability is to let the server know the client understands ['T', 'H', 'I', 'N' ..]. The server can choose not to send it later, but that's ok. Hence the new capability. I'm somewhat reluctant to do it because of peeking code in fetch-pack and receive-pack and some refactoring may be needed first. But I could certainly put it on higher priority. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
