Re: [PATCH] cleanup argument passing in submodule status command
Heiko Voigt hvo...@hvoigt.net writes: Note: This is a code cleanup and does not fix any bugs. As a side effect the variables containing the parsed flags to git submodule status are passed down recursively. So everything was already behaving as expected. If that is the case, shouldn't we stop passing anything down, if we want it to be a clean-up only, no behaviour changes patch? While at it, we may want to kill that code to accumulate the original options in orig_flags because we haven't been using the variable. We _know_ $orig_args has been empty, i.e. the code has been working fine with only cmd_status there. Nobody has tried what happens when we pass the original arguments to cmd_status on that line. The patch changes the behaviour of the code; it makes the command line parsing while loop to run again, and if the code that accumulates original options in orig_flags have been buggy, now that bug will be exposed. Signed-off-by: Heiko Voigt hvo...@hvoigt.net --- git-submodule.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-submodule.sh b/git-submodule.sh index dba4d39..3a3f0a4 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -961,7 +961,7 @@ cmd_status() prefix=$displaypath/ clear_local_git_env cd $sm_path - eval cmd_status $orig_args + eval cmd_status $orig_flags ) || die $(eval_gettext Failed to recurse into submodule path '\$sm_path') fi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] log: remove redundant check for merge commit
Martin von Zweigbergk martin.von.zweigbe...@gmail.com writes: I incorrectly assumed that ignore_merges was about revision traversal, but now I think it's only diff output from 'git log' (and possibly others). Yeah, I realized the same after I wrote the response last night and went to bed. I am glad you figured all out yourself. -- 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] buitin_config: return postitive status in get_value
Nguyen Thai Ngoc Duy pclo...@gmail.com writes:
On Sat, Jul 28, 2012 at 04:18:49PM +0300, Nikolay Vladimirov wrote:
But the behavior now seems kind of strange, or maybe I'm missing something:
# git config foobar; echo $?
error: key does not contain a section: foobar
255
# git config foobar.info; echo $?
1
git version 1.7.11.2
I would generally expect the both to behave the same way.
Then the following patch may be better because it leaves other cases
untouched (I'm not saying that we should or should not do it though)
I personally think that the documentation unnecessarily exposes the
useless value assignment of the exit codes (the use of different
exit codes was done merely to aid debugging the git-config command
itself) by describing the then-current set of conditions, and should
be reduced to say 0 for success, non-zero for any error.
But if we really want to follow that documented subset of possible
conditions, I agree that your version to return 1 in this case,
together with a change to initialize ret to 7 and document it as
all other errors (ret=7), would make more sense. Other conditions
that have been added since that partial enumeration of the exit code
was done are regexp errors, which I think will get -1 from the same
function.
-- 8 --
diff --git a/builtin/config.c b/builtin/config.c
index 8cd08da..d048ebf 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -199,8 +199,10 @@ static int get_value(const char *key_, const char
*regex_)
goto free_strings;
}
} else {
- if (git_config_parse_key(key_, key, NULL))
+ if (git_config_parse_key(key_, key, NULL)) {
+ ret = 1;
goto free_strings;
+ }
}
if (regex_) {
-- 8 --
--
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: Enhancements to git-protocoll
Fredrik Gustafsson iv...@iveqy.com writes:
Sometimes the server wants to communicate directly to the git user.
...
For example:
gitolite has something called wild repos[1]. The management is
cumbersome and if you misspell when you clone a repo you might instead
create a new repo.
This could have been avoided with a simply:
Do you want to create a new repo[Yn]
I do not think the automatic repository creation done by gitolite is
a good use case or example for whatever you seem to be advocating.
IIUC, the auto-creation in gitolite-shell::main() is done way before
gitolite-shell (which is used as a login shell for incoming ssh
sessions) creates a new git repository, goes into it and spawns the
git-receive-pack command. It all happens outside Git.
# auto-create?
if ( repo_missing($repo) and access( $repo, $user, '^C', 'any' ) !~
/DENIED/ ) {
require Gitolite::Conf::Store;
Gitolite::Conf::Store-import;
new_wild_repo( $repo, $user, $aa );
gl_log( 'create', $repo, $user, $aa );
}
The access() we see here is not the Perl builtin access(), but is
a function defined in src/lib/Gitolite/Conf/Load.pm; that would be
the place to allow the incoming ssh session to talk back to the end
user, but at that point there is no Git processing on the server
end.
While I am not fundamentally opposed to adding yet another sideband
channel to the git protocol, I do not think adding user interaction
at random places in the protocol exchange is a viable or useful
approach to implement an enhanced server that works with both
enhanced and vanilla clients (and the same is true for enhanced
client that works with both enhanced and vanilla server).
--
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 0/2] test results for v1.7.12-rc0 on cygwin
Am 28.07.2012 20:46, schrieb Ramsay Jones: Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh. I tried, among other things, to provoke a failure thus: $ for i in $(seq 100); do if ! ./t7810-grep.sh -i -v; then break; fi done $ but, apart from chewing on the cpu for about 50 minutes, it didn't result in a failure. :( However, after looking at test 59, it seems to me to be a stale (redundant) test. So, patch #2 removes that test! :-D [I wish I could reproduce the failure because I don't like not knowing why it failed, but ...] Removing the test makes sense, since it was needed for --ext-grep only, is relatively expensive and a bit fragile (by depending on MAXARGS). I'm slightly worried about the non-reproducible failure, though. Perhaps a timing issue is involved and chances are higher if you leave out the option -v? Thanks, René -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson iv...@iveqy.com wrote: Hi, sometimes git communicates with something that's not git on the other side (gitolite and github for example). Sometimes the server wants to communicate directly to the git user. git isn't really designed for this. gitolite solves this by do user interaction on STDERR instead. The bad thing about this is that it can only be one-direction communication, for example error messages. If git would allow for the user to interact direct with the server, a lot of cool and and userfriendly features could be developed. For example: gitolite has something called wild repos[1]. The management is cumbersome and if you misspell when you clone a repo you might instead create a new repo. For the record, although it cannot do the yes/no part, if you want to disable auto-creation on a fetch/clone (read operation) it's trivial to add a PRE_CREATE trigger to do that. -- 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-tag documentation enhancement
Dear Sir, I would like to enhance git-tag documentation --Unless -f is given, the tag to be created must not yet exist in the .git/refs/tags/ directory. ++Unless -f is given, the tag to be created must not yet exist in the .git/refs/tags/ directory or inside .git/packed-refs file. Regards, ch3cooli -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 04:07:13PM +0530, Sitaram Chamarty wrote: On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson iv...@iveqy.com wrote: Hi, sometimes git communicates with something that's not git on the other side (gitolite and github for example). Sometimes the server wants to communicate directly to the git user. git isn't really designed for this. gitolite solves this by do user interaction on STDERR instead. The bad thing about this is that it can only be one-direction communication, for example error messages. If git would allow for the user to interact direct with the server, a lot of cool and and userfriendly features could be developed. For example: gitolite has something called wild repos[1]. The management is cumbersome and if you misspell when you clone a repo you might instead create a new repo. For the record, although it cannot do the yes/no part, if you want to disable auto-creation on a fetch/clone (read operation) it's trivial to add a PRE_CREATE trigger to do that. Thanks, however I think auto-creation is a great feature for some cases and I think there can be even more useable functions if we could get user interaction. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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: Enhancements to git-protocoll
On Sat, Jul 28, 2012 at 11:58:09PM -0700, Junio C Hamano wrote:
Fredrik Gustafsson iv...@iveqy.com writes:
Sometimes the server wants to communicate directly to the git user.
...
For example:
gitolite has something called wild repos[1]. The management is
cumbersome and if you misspell when you clone a repo you might instead
create a new repo.
This could have been avoided with a simply:
Do you want to create a new repo[Yn]
I do not think the automatic repository creation done by gitolite is
a good use case or example for whatever you seem to be advocating.
IIUC, the auto-creation in gitolite-shell::main() is done way before
gitolite-shell (which is used as a login shell for incoming ssh
sessions) creates a new git repository, goes into it and spawns the
git-receive-pack command. It all happens outside Git.
# auto-create?
if ( repo_missing($repo) and access( $repo, $user, '^C', 'any' ) !~
/DENIED/ ) {
require Gitolite::Conf::Store;
Gitolite::Conf::Store-import;
new_wild_repo( $repo, $user, $aa );
gl_log( 'create', $repo, $user, $aa );
}
The access() we see here is not the Perl builtin access(), but is
a function defined in src/lib/Gitolite/Conf/Load.pm; that would be
the place to allow the incoming ssh session to talk back to the end
user, but at that point there is no Git processing on the server
end.
That's a feature. It means that the impact on git would be rather small,
we don't have to involve server-side git at all. The problem so solve is
how to get client-side git to pass through STDIN and STDOUT (just as is
done with STDERR right now). I see this as a gitolite - client-git
interaction case. No server-git should be involved.
All the use casese I can imagine will be done before (or after)
serverside git is executed.
While I am not fundamentally opposed to adding yet another sideband
channel to the git protocol, I do not think adding user interaction
at random places in the protocol exchange is a viable or useful
approach to implement an enhanced server that works with both
enhanced and vanilla clients (and the same is true for enhanced
client that works with both enhanced and vanilla server).
Do we mean the same thing with git protocol? I specify the protocol as
everything that happens between the server and the client. Are the
connection divided into multiple protocoll after eachother? (would it be
possible to execute git-user-interaction-protocoll first and the
git-protocoll and then git-user-interaction-protocoll again?).
The vanilla case would be easy to solve if the protocol has git version
in its handshake. The STDERR approach is already used and working. A
vanilla client would have the same functionality as today and en
enhanced client will have enhanced functionality.
--
Med vänliga hälsningar
Fredrik Gustafsson
tel: 0733-608274
e-post: iv...@iveqy.com
--
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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 7:43 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Sun, Jul 29, 2012 at 04:07:13PM +0530, Sitaram Chamarty wrote: On Sun, Jul 29, 2012 at 3:11 AM, Fredrik Gustafsson iv...@iveqy.com wrote: Hi, sometimes git communicates with something that's not git on the other side (gitolite and github for example). Sometimes the server wants to communicate directly to the git user. git isn't really designed for this. gitolite solves this by do user interaction on STDERR instead. The bad thing about this is that it can only be one-direction communication, for example error messages. If git would allow for the user to interact direct with the server, a lot of cool and and userfriendly features could be developed. For example: gitolite has something called wild repos[1]. The management is cumbersome and if you misspell when you clone a repo you might instead create a new repo. For the record, although it cannot do the yes/no part, if you want to disable auto-creation on a fetch/clone (read operation) it's trivial to add a PRE_CREATE trigger to do that. Thanks, however I think auto-creation is a great feature for some cases and I think there can be even more useable functions if we could get user interaction. For the record, I don't think I agree. There's a place to create a human-conversation, and there's a place not to. If you want a dialog with the server, there should be *other* commands that do that, instead of overloading git's own protocol. Since you mentioned gitolite, consider copying the fork command (src/commands/fork) and munging the code into an explicit wild repo create. -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote: Thanks, however I think auto-creation is a great feature for some cases and I think there can be even more useable functions if we could get user interaction. For the record, I don't think I agree. There's a place to create a human-conversation, and there's a place not to. If you want a dialog with the server, there should be *other* commands that do that, instead of overloading git's own protocol. Since you mentioned gitolite, consider copying the fork command (src/commands/fork) and munging the code into an explicit wild repo create. I appriciate that you clearified you oppinion. Please excuse me if it sounded as I in any way speaked for gitolite. I use gitolite as an example becuase the target application in this case is unknown to most people (think gitolite with db-backend for user permissions). It's a valid design oppinion to not mix git protocoll with anything else. But gitolite already does that. Gitolite already have user interaction mixed with git interaction. Do you say to me that gitolite is broken and should not do user interaction over git-commands? Then why does wild repos exists and why does gitolite error messages exists? We're already down that road, why not do it better? -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 8:35 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Sun, Jul 29, 2012 at 07:55:36PM +0530, Sitaram Chamarty wrote: Thanks, however I think auto-creation is a great feature for some cases and I think there can be even more useable functions if we could get user interaction. For the record, I don't think I agree. There's a place to create a human-conversation, and there's a place not to. If you want a dialog with the server, there should be *other* commands that do that, instead of overloading git's own protocol. Since you mentioned gitolite, consider copying the fork command (src/commands/fork) and munging the code into an explicit wild repo create. I appriciate that you clearified you oppinion. Please excuse me if it sounded as I in any way speaked for gitolite. I use gitolite as an example becuase the target application in this case is unknown to most people (think gitolite with db-backend for user permissions). It's a valid design oppinion to not mix git protocoll with anything else. But gitolite already does that. Gitolite already have user interaction mixed with git interaction. Do you say to me that gitolite is broken and should not do user interaction over git-commands? Then why does wild repos exists and why does gitolite error messages exists? We're already down that road, why not do it better? I think you misunderstood how gitolite works. Gitolite does not have *any* user interaction other than sending some extra messages back via STDERR if you're using a normal git client to do normal git operations (clone/fetch/ls-remote). Such messages are *no different* from something that an update or pre-receive hook might send back even on a normal (no gitolite) git server. The only time that gitolite might have any user *interaction* is when using gitolite commands. These do not run git at all (neither on the client nor on the server), and in fact merely provide a convenient way to allow users to run a controlled set of specific *shell* commands. -- 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] cleanup argument passing in submodule status command
Am 29.07.2012 08:22, schrieb Junio C Hamano: Heiko Voigt hvo...@hvoigt.net writes: Note: This is a code cleanup and does not fix any bugs. As a side effect the variables containing the parsed flags to git submodule status are passed down recursively. So everything was already behaving as expected. If that is the case, shouldn't we stop passing anything down, if we want it to be a clean-up only, no behaviour changes patch? While at it, we may want to kill that code to accumulate the original options in orig_flags because we haven't been using the variable. We _know_ $orig_args has been empty, i.e. the code has been working fine with only cmd_status there. Nobody has tried what happens when we pass the original arguments to cmd_status on that line. I tried today. Before this change no arguments got passed down and afterwards they are (but just the arguments, no submodule paths were passed on in either case; which is what Kevin fixed in the commit Heiko referenced). Three arguments are allowed for git submodule status: --recursive: It doesn't matter if we pass that on or not because $recursive is reused when eval cmd_status is executed. --quiet: Same as recursive, GIT_QUIET is set the first time and then reused in the recursion. --cached: This was dropped when recursing into submodules but isn't anymore with Heiko's change, so we do have a change in behavior here. The patch changes the behaviour of the code; it makes the command line parsing while loop to run again, and if the code that accumulates original options in orig_flags have been buggy, now that bug will be exposed. Hmm, when --cached is used together with --recursive, I would expect it to show the commit stored in the index for the deeper submodules too (and not magically switch to show their HEAD again after the first level of submodules). To me this looks like a bug which Kevin accidentally introduced and nobody noticed and/or reported until now. So I'd vote for making this a bugfix patch for git submodule status --cached --recursive (and would love to see a test for it ;-). Signed-off-by: Heiko Voigt hvo...@hvoigt.net --- git-submodule.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-submodule.sh b/git-submodule.sh index dba4d39..3a3f0a4 100755 --- a/git-submodule.sh +++ b/git-submodule.sh @@ -961,7 +961,7 @@ cmd_status() prefix=$displaypath/ clear_local_git_env cd $sm_path -eval cmd_status $orig_args +eval cmd_status $orig_flags ) || die $(eval_gettext Failed to recurse into submodule path '\$sm_path') fi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable parallelism in git submodule update.
Am 27.07.2012 20:37, schrieb Stefan Zager: The --jobs parameter may be used to set the degree of per-submodule parallel execution. I think this is a sound idea, but it would be good to see some actual measurements. What are the performance numbers with and without this change? Which cases do benefit and are there some which run slower when run in parallel? -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote: I think you misunderstood how gitolite works. Gitolite does not have *any* user interaction other than sending some extra messages back via STDERR if you're using a normal git client to do normal git operations (clone/fetch/ls-remote). As you say, gitolite has userinteraction, and its not even standard to git error messages. Try cloning a repo that doesn't exists via gitolite and a regular ssh connection: [iveqy@paksenarrion git]$ git clone ssh://gitolite@localhost/testing2 Cloning into testing2... FATAL: R any testing2 id_rsa DENIED by fallthru (or you mis-spelled the reponame) fatal: The remote end hung up unexpectedly [iveqy@paksenarrion git]$ git clone ssh://iveqy@localhost/testing2 Cloning into testing... fatal: '/testing2' does not appear to be a git repository fatal: The remote end hung up unexpectedly Such messages are *no different* from something that an update or pre-receive hook might send back even on a normal (no gitolite) git server. As I showed above the non-existing repo is a case when it's different. But you have a good point in hooks, of course a hook also should be able to have two way user interaction. The only time that gitolite might have any user *interaction* is when using gitolite commands. These do not run git at all (neither on the client nor on the server), and in fact merely provide a convenient way to allow users to run a controlled set of specific *shell* commands. I do understand how gitolite works. However this is off-topic to my original question. I also do not have an oppinion on how gitolite should work, I simply don't care. Gitolite is an widely acceptet git tool, I see improvement opportunities in git to allow an other program to utilize two-way user interaction all the time, this will not effect gitolite at all. So in my point of view, it's up to Junio if I shall continue explore this path and maybe find a way of doing this in git, the right way. Or if this is something unwanted and gitolite and alike programs should continue with STDERR hacks. -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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: The GitTogether
Am 27.07.2012 13:45, schrieb Thomas Rast: Scott Chacon scha...@gmail.com writes: GitHub would like to volunteer to organize and pay for these events this year. I would like to hold the developer-centric one in Berlin in early October Yay, Berlin! I would be glad to join there; I would probably not have the time and resources to travel to SF this year. Same here. For those of you who *have* been to a GitTogether, what did you find useful and/or useless about it? What did you get out of it and would like to see again? For those of you who have never been, what do you think would be useful? I was thinking for both of them to have a combination of short prepared talks, lightning/unconference style talks and general discussion / breakout sessions. I was at the 2010 GitTogether in Mountain View. I really liked the unconference format, and the way Shawn and Junio used it: just using the topic stickers as a sort of todo-list, not actually fixing any schedule in advance. Oddly enough we also managed to avoid the usual consequence of open-ended discussions: getting stuck endlessly on an absolutely insignificant point. Yup, the unconference format with both common and breakout sessions worked really well. I think the discussions were very productive. I would love to do more hacking than we managed in 2010, but I realize that this is not possible if we just meet for 2-3 days. Perhaps one option would be to plan for 1-2 days of hacking after the discussion rounds, so that the interested people can stay a bit longer? I really like that idea and would vote for 3-4 days (maybe including a weekend for those of us who have to take a leave from work ;-). -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 9:11 PM, Fredrik Gustafsson iv...@iveqy.com wrote: On Sun, Jul 29, 2012 at 08:45:39PM +0530, Sitaram Chamarty wrote: I think you misunderstood how gitolite works. Gitolite does not have *any* user interaction other than sending some extra messages back via STDERR if you're using a normal git client to do normal git operations (clone/fetch/ls-remote). As you say, gitolite has userinteraction, and its not even standard to I think we differ on the meaning of the word interaction. -- 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: Recursive submodules fail when the repo path contains spaces
On Tue, Jul 24, 2012 at 4:33 PM, Justin Spahr-Summers justin.spahrsumm...@gmail.com wrote: On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de (http://web.de) writes: Am 24.07.2012 21:01, schrieb Justin Spahr-Summers: This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3. Steps: 1. Create or clone a repository to an absolute path that contains spaces. 2. Add a submodule to the repository, if it does not already have one. 3. Within that submodule, attempt to add another submodule. The result is an error fatal: Not a git repository, followed by the relative path to the submodule directory within .git/modules of the top-level repository. Similarly, using git submodule update --init --recursive in a freshly-cloned repository that matches the above configuration will fail with the same error. git clone --recursive does not seem to suffer from the same problem at clone time, but will still fail to add recursive submodules. Hmm, I don't understand how that is different from what t7407 does, it uses git submodule update --init --recursive in to populate recursive submodules in a freshly cloned repository whose path contains a space (in the trash directory name) in test number 8. I can see one codepath that would behave incorrectly, especially if the submodule path relative to the superproject has whitespaces in it. In module_clone(), you have: # We already are at the root of the work tree but cd_to_toplevel will # resolve any symlinks that might be present in $PWD a=$(cd_to_toplevel cd $gitdir pwd)/ b=$(cd_to_toplevel cd $sm_path pwd)/ ... # Turn each leading */ component into ../ rel=$(echo $b | sed -e 's|[^/][^/]*|..|g') echo gitdir: $rel/$a $sm_path/.git I _think_ $sm_path is computed correctly by the codeflow leading to this place, and $b is also computed correctly, but notice the lack of quoting around $b when you echo it? It will be split at $IFS, so if b='/Program Files/My Stupidity/', the sed script will see a single SP between My and Stupidity, which is different from what you wanted to feed, I presume. Having said that, I do not think git-submodule is prepared to take paths with path-unsafe characters in it, given that many part of it has loops like while read mode sha1 stage sm_path that reads from ls-files/ls-tree output without -z (which means it cannot handle pathnames with LF in them). My recommendation at this point (i.e. not a long term) for people with problems Justin saw is Don't do it then. I appreciate the debugging work. Unfortunately, none of the relative submodule paths have had whitespace in them, so I'm not sure that's the issue. Here's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule): $ cd External/twui $ git submodule add git://github.com/petejkim/expecta.git TwUITests/expecta Cloning into 'TwUITests/expecta'... remote: Counting objects: 988, done. remote: Compressing objects: 100% (404/404), done. remote: Total 988 (delta 680), reused 842 (delta 535) Receiving objects: 100% (988/988), 156.30 KiB, done. Resolving deltas: 100% (680/680), done. fatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta I saw something similar before but I was unable to reproduce the conditions. In my case, my superproject was cloned with an earlier version of git and some new submodule behaviors seemed to cause me problems. Is project name with spaces a freshly cloned project also using, say, 1.7.11.3? I am not able to reproduce the problem here on Linux using your same example command. Phil -- 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 with large files...
On Mon, Jul 23, 2012 at 12:23 AM, Sitaram Chamarty sitar...@gmail.com wrote: On Mon, Jul 23, 2012 at 2:24 AM, Junio C Hamano gits...@pobox.com wrote: mer...@stonehenge.com (Randal L. Schwartz) writes: Darek == Darek Bridges darek.brid...@me.com writes: Darek I use git for many things, but I am trying to work out the Darek workflow to use git for deployment. Don't. Yeah, don't think 'git checkout' is a way to 'deploy'. Using Git as a transport measure is probably fine. You can also try http://sitaramc.github.com/the-list-and-irc/deploy.html. Whether it's saying you *can* use git for deploying something, or you *can* but *should not*, or you *cannot*, will depend on your own thoughts on the matter ;-) After a couple of false starts, I think that Sitaram came closest to what Darek was asking about. Now, as somebody who is using Git currently to stage things to deployment (I may change to SVN due to office politics--which will double my workload on rollout of updates, but I'm not saying any more than that in public) on production web servers, I have a few comments. We have several WordPress instances @$work where we are using Git to stage template changes out to our development server (where I've contemplated putting the lessons in Sitaram's article to use) before merging those changes back into the Production branch (after suitable testing) and pulling them from a central gitolite into the live server. It works and it respects the posix extended ACLs on the destination host (which is what you actually want on a live web server). Even better, it provides a safe way of tracking and merging back in any opportunistic changes that were made directly in the development or production servers so that they are not lost. Thought must be applied to do this safely, but that's the way it usually is on web servers. To those who say admins should be using RPM, DEB, or any other generic package management software to deploy non-system updates to in-house web servers may I kindly indicate that it often doesn't make sense to do so unless each and every website has its own server and IP address--and you are deploying tens of thousands of them. Most of us can't afford that. (Yes, there is an overhead to building packages. I've done it enough times to know about that quite intimately.) Packages and package management are great for system software but they are not a good solution for installing client code into a webspace on a shared server (yes, heresy, I know). For this common use case Git is not a half-bad ADDITION to the toolkit of a website development and maintenance team. -- -Drew Northup -- As opposed to vegetable or mineral error? -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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
PROPFIND 405 with git-http-backend and Smart HTTP
I'm setting up a git server with git-http-backend and Smart HTTP but I'm
getting PROPFIND Error 405 with git push.
Here's my config:
VirtualHost *:8000
ServerName localhost
DocumentRoot /opt/local/apache2/htdocs/repo
SetEnv GIT_PROJECT_ROOT /opt/local/apache2/htdocs/repo
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /repo/ /usr/libexec/git-core/git-http-backend/
AliasMatch ^/repo/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$
/opt/local/apache2/htdocs/repo/$1
AliasMatch ^/repo/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$
/opt/local/apache2/htdocs/repo/$1
ScriptAliasMatch \
(?x)^/repo/(.*/(HEAD | \
info/refs | \
objects/(info/[^/]+ | \
[0-9a-f]{2}/[0-9a-f]{38} | \
pack/pack-[0-9a-f]{40}\.(pack|idx)) | \
git-(upload|receive)-pack))$ \
/usr/libexec/git-core/git-http-backend/$1
LocationMatch ^/repo/.*/git-receive-pack$
AuthType Basic
AuthName Git
Require valid-user
AuthUserFile /etc/apache2/other/htpasswd
/LocationMatch
/VirtualHost
And here's a snip from my access_log:
::1 - - [29/Jul/2012:18:34:34 +0100] GET
/repo/myproject.git/info/refs?service=git-receive-pack HTTP/1.1 200 117
::1 - - [29/Jul/2012:18:34:34 +0100] GET /repo/myproject.git/HEAD
HTTP/1.1 200 23
::1 - - [29/Jul/2012:18:34:34 +0100] PROPFIND /repo/myproject.git/
HTTP/1.1 405 247
Any ideas?
--
View this message in context:
http://git.661346.n2.nabble.com/PROPFIND-405-with-git-http-backend-and-Smart-HTTP-tp7564017.html
Sent from the git mailing list archive at Nabble.com.
--
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: Recursive submodules fail when the repo path contains spaces
On Sunday, 29. July 2012 at 11:31, Phil Hord wrote: On Tue, Jul 24, 2012 at 4:33 PM, Justin Spahr-Summers justin.spahrsumm...@gmail.com (mailto:justin.spahrsumm...@gmail.com) wrote: On Tuesday, 24. July 2012 at 13:26, Junio C Hamano wrote: Jens Lehmann jens.lehm...@web.de (http://web.de) writes: Am 24.07.2012 21:01, schrieb Justin Spahr-Summers: This occurs on Mac OS X 10.7.4, on git versions 1.7.10.2 (Apple Git-33) and 1.7.11.3. Steps: 1. Create or clone a repository to an absolute path that contains spaces. 2. Add a submodule to the repository, if it does not already have one. 3. Within that submodule, attempt to add another submodule. The result is an error fatal: Not a git repository, followed by the relative path to the submodule directory within .git/modules of the top-level repository. Similarly, using git submodule update --init --recursive in a freshly-cloned repository that matches the above configuration will fail with the same error. git clone --recursive does not seem to suffer from the same problem at clone time, but will still fail to add recursive submodules. Hmm, I don't understand how that is different from what t7407 does, it uses git submodule update --init --recursive in to populate recursive submodules in a freshly cloned repository whose path contains a space (in the trash directory name) in test number 8. I can see one codepath that would behave incorrectly, especially if the submodule path relative to the superproject has whitespaces in it. In module_clone(), you have: # We already are at the root of the work tree but cd_to_toplevel will # resolve any symlinks that might be present in $PWD a=$(cd_to_toplevel cd $gitdir pwd)/ b=$(cd_to_toplevel cd $sm_path pwd)/ ... # Turn each leading */ component into ../ rel=$(echo $b | sed -e 's|[^/][^/]*|..|g') echo gitdir: $rel/$a $sm_path/.git I _think_ $sm_path is computed correctly by the codeflow leading to this place, and $b is also computed correctly, but notice the lack of quoting around $b when you echo it? It will be split at $IFS, so if b='/Program Files/My Stupidity/', the sed script will see a single SP between My and Stupidity, which is different from what you wanted to feed, I presume. Having said that, I do not think git-submodule is prepared to take paths with path-unsafe characters in it, given that many part of it has loops like while read mode sha1 stage sm_path that reads from ls-files/ls-tree output without -z (which means it cannot handle pathnames with LF in them). My recommendation at this point (i.e. not a long term) for people with problems Justin saw is Don't do it then. I appreciate the debugging work. Unfortunately, none of the relative submodule paths have had whitespace in them, so I'm not sure that's the issue. Here's some real output, with a couple specific names removed, starting from the root of the top-level repository (where External/twui is a submodule): $ cd External/twui $ git submodule add git://github.com/petejkim/expecta.git (http://github.com/petejkim/expecta.git) TwUITests/expecta Cloning into 'TwUITests/expecta'... remote: Counting objects: 988, done. remote: Compressing objects: 100% (404/404), done. remote: Total 988 (delta 680), reused 842 (delta 535) Receiving objects: 100% (988/988), 156.30 KiB, done. Resolving deltas: 100% (680/680), done. fatal: Not a git repository: ../../../../../../../../Volumes/drive name with spaces/Users/justin/Documents/Programming/project name with spaces/.git/modules/External/twui/modules/TwUITests/expecta I saw something similar before but I was unable to reproduce the conditions. In my case, my superproject was cloned with an earlier version of git and some new submodule behaviors seemed to cause me problems. Is project name with spaces a freshly cloned project also using, say, 1.7.11.3? I am not able to reproduce the problem here on Linux using your same example command. Hmm, you're right. After further investigation, this actually looks like a weird issue with soft links. Here's some exact output (with spacing only for clarity), using a public test repository at https://github.com/jspahrsummers/recursive-submodules-test: justin:~/ $ ls -l HDD lrwxr-xr-x 1 justin staff 34 5 Jan 2012 HDD - /Volumes/fadelah data/Users/justin justin:~/ $ cd HDD justin:HDD/ $ pwd /Users/justin/HDD justin:HDD/ $ git clone g...@github.com:jspahrsummers/recursive-submodules-test.git Cloning into 'recursive-submodules-test'... remote: Counting objects: 6, done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 1), reused 5 (delta 0) Receiving objects: 100% (6/6), done. Resolving deltas: 100% (1/1), done. justin:HDD/ $ cd
Re: [PATCH 0/2] test results for v1.7.12-rc0 on cygwin
René Scharfe rene.scha...@lsrfire.ath.cx writes: Am 28.07.2012 20:46, schrieb Ramsay Jones: Unfortunately, I was unable to reproduce the final failure in t7810-grep.sh. I tried, among other things, to provoke a failure thus: $ for i in $(seq 100); do if ! ./t7810-grep.sh -i -v; then break; fi done $ but, apart from chewing on the cpu for about 50 minutes, it didn't result in a failure. :( However, after looking at test 59, it seems to me to be a stale (redundant) test. So, patch #2 removes that test! :-D [I wish I could reproduce the failure because I don't like not knowing why it failed, but ...] Removing the test makes sense, since it was needed for --ext-grep only, is relatively expensive and a bit fragile (by depending on MAXARGS). I'm slightly worried about the non-reproducible failure, though. Perhaps a timing issue is involved and chances are higher if you leave out the option -v? Thanks for a comment. I agree that removing the test makes sense, and I also agree that the non reproducibleness is worrying (the latter is more important). -- 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] buitin_config: return postitive status in get_value
Junio C Hamano gits...@pobox.com writes:
I personally think that the documentation unnecessarily exposes the
useless value assignment of the exit codes (the use of different
exit codes was done merely to aid debugging the git-config command
itself) by describing the then-current set of conditions, and should
be reduced to say 0 for success, non-zero for any error.
But if we really want to follow that documented subset of possible
conditions, I agree that your version to return 1 in this case,
together with a change to initialize ret to 7 and document it as
all other errors (ret=7), would make more sense. Other conditions
that have been added since that partial enumeration of the exit code
was done are regexp errors, which I think will get -1 from the same
function.
IOW, something like this.
Documentation/git-config.txt | 18 ++
builtin/config.c | 8 ++--
2 files changed, 16 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 2d6ef32..b071d65 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -54,19 +54,21 @@ configuration file by default, and options '--system',
'--global',
'--file filename' can be used to tell the command to write to
that location (you can say '--local' but that is the default).
-This command will fail (with exit code ret) if:
+This command will fail with non-zero status if:
+. The section name or key name is invalid (ret=1),
+. No section name or key name was provided (ret=2),
. The config file is invalid (ret=3),
-. can not write to the config file (ret=4),
-. no section or name was provided (ret=2),
-. the section or key is invalid (ret=1),
-. you try to unset an option which does not exist (ret=5),
-. you try to unset/set an option for which multiple lines match (ret=5),
-. you try to use an invalid regexp (ret=6), or
-. you use '--global' option without $HOME being properly set (ret=128).
+. The config file cannot be written (ret=4),
+. You try to unset an option which does not exist (ret=5),
+. You try to unset/set an option for which multiple lines match (ret=5),
+. You try to use an invalid regexp (ret=6),
+. You use '--global' option without $HOME being properly set (ret=128),
+. Any other errors (ret=7).
On success, the command returns the exit code 0.
+
OPTIONS
---
diff --git a/builtin/config.c b/builtin/config.c
index 8cd08da..2318308 100644
--- a/builtin/config.c
+++ b/builtin/config.c
@@ -160,7 +160,7 @@ static int show_config(const char *key_, const char
*value_, void *cb)
static int get_value(const char *key_, const char *regex_)
{
- int ret = -1;
+ int ret = 7;
char *global = NULL, *xdg = NULL, *repo_config = NULL;
const char *system_wide = NULL, *local;
struct config_include_data inc = CONFIG_INCLUDE_INIT;
@@ -196,11 +196,14 @@ static int get_value(const char *key_, const char *regex_)
if (regcomp(key_regexp, key, REG_EXTENDED)) {
fprintf(stderr, Invalid key pattern: %s\n, key_);
free(key);
+ ret = 6;
goto free_strings;
}
} else {
- if (git_config_parse_key(key_, key, NULL))
+ if (git_config_parse_key(key_, key, NULL)) {
+ ret = 1;
goto free_strings;
+ }
}
if (regex_) {
@@ -212,6 +215,7 @@ static int get_value(const char *key_, const char *regex_)
regexp = (regex_t*)xmalloc(sizeof(regex_t));
if (regcomp(regexp, regex_, REG_EXTENDED)) {
fprintf(stderr, Invalid pattern: %s\n, regex_);
+ ret = 6;
goto free_strings;
}
}
--
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: Enhancements to git-protocoll
Sitaram Chamarty sitar...@gmail.com writes: Uggh, no. Client-git should only talk to server-git. It shouldn't be talking first to some *other* program (in this case gitolite), and then to to server-git. That doesn't sound sane to me. You should wrap this whole thing around something else that does it in 3 steps. Check, create if needed, then the actual git command you intend to run. All this should be local to your environment, not rolled into git; it's far too specific to be rolled into git itself, if you ask me. Thanks for saving me from having to state an obvious sanity ;-) -- 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: Recursive submodules fail when the repo path contains spaces
On Sun, Jul 29, 2012 at 3:30 PM, Justin Spahr-Summers justin.spahrsumm...@gmail.com wrote: Hmm, you're right. After further investigation, this actually looks like a weird issue with soft links. Here's some exact output (with spacing only for clarity), using a public test repository at https://github.com/jspahrsummers/recursive-submodules-test: I can reproduce the problem now on 1.7.10.3. However the problem goes away in 1.7.12 since it was fixed in 6eafa6d096ce6b0ae20e4c0fbb248958559daf64 Author: Jens Lehmann jens.lehm...@web.de Date: Thu Jul 12 19:45:32 2012 +0200 Subject: submodules: don't stumble over symbolic links when cloning recursively Regards, Phil -- 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: Recursive submodules fail when the repo path contains spaces
On Sunday, 29. July 2012 at 14:10, Phil Hord wrote: On Sun, Jul 29, 2012 at 3:30 PM, Justin Spahr-Summers justin.spahrsumm...@gmail.com (mailto:justin.spahrsumm...@gmail.com) wrote: Hmm, you're right. After further investigation, this actually looks like a weird issue with soft links. Here's some exact output (with spacing only for clarity), using a public test repository at https://github.com/jspahrsummers/recursive-submodules-test: I can reproduce the problem now on 1.7.10.3. However the problem goes away in 1.7.12 since it was fixed in 6eafa6d096ce6b0ae20e4c0fbb248958559daf64 Author: Jens Lehmann jens.lehm...@web.de (http://web.de) Date: Thu Jul 12 19:45:32 2012 +0200 Subject: submodules: don't stumble over symbolic links when cloning recursively Regards, Phil Ah, good to know. Thanks, everyone, for the help. -- 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: Enhancements to git-protocoll
Sorry I missed this thread earlier. I'll drop this if it's not something that's wanted. On Sun, Jul 29, 2012 at 01:51:34PM -0700, Junio C Hamano wrote: Sitaram Chamarty sitar...@gmail.com writes: Uggh, no. Client-git should only talk to server-git. It shouldn't be talking first to some *other* program (in this case gitolite), and then to to server-git. That doesn't sound sane to me. This is exactly the way gitolite works. It's placed between git-server and git-client. Does some checks and approves a connection if some criterias isn't met. See the example when trying to clone an non-existing repo from gitolite. You won't get an git error but a gitolite error. I can understand why my idea is beeing rejected but I can't see why the gitolite way should be considered sane. It seems more like an hack to me (according to git design principles). So from a git point of view, why is it sane for passing through STDERR but not STDIN and STDOUT? (I realize that this is a closed matter but would appriciate an explanation solely for my own educational purpose). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iv...@iveqy.com -- 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: Enhancements to git-protocoll
Junio C Hamano gits...@pobox.com writes: Sitaram Chamarty sitar...@gmail.com writes: Uggh, no. Client-git should only talk to server-git. It shouldn't be talking first to some *other* program (in this case gitolite), and then to to server-git. That doesn't sound sane to me. You should wrap this whole thing around something else that does it in 3 steps. Check, create if needed, then the actual git command you intend to run. All this should be local to your environment, not rolled into git; it's far too specific to be rolled into git itself, if you ask me. Thanks for saving me from having to state an obvious sanity ;-) Having said all that, I am not fundamentally opposed to new features added to the git protocol. The responses so far from me in this thread were primarily me reacting to (1) auto creation by gitolite is a bad example and (2) the proposal sounded, at least to me, that it wants to add random and uncontrolled interactions between the sides outside the defined protocol exchange (e.g. pusher connects, pushee says what it has and what capabilities it supports, pusher says what it wants to update how and chooses what capabilities it wants to use in the exchange, sends the pack data, ...), which is an unworkable idea. For people who do not understand how the git protocol works (the proposal that started this thread included), a bit of clarification on (2) may help. Long time ago, we did not have report-status capability (think of a capability as a protocol extension). The git push protocol exchange ended with the pusher sending the pack data and that was the end of conversation. But we realized that it would be beneficial for the pushee to be able to tell the pusher that the push failed at the protocol level, so that the git push program can exit with an error code. The version of the git push program that was current at the time exited with success unconditionally, as long as all protocol exchange went well and all the pack data was sent successfully. The program's flow was not expecting any response once the pack data started flowing from it to the pushee, so that is the only reasonable behaviour. So what did we do? We added report-status capability to the capability suite, and made new versions of receive-pack program advertise it. Existing versions of git push did not know about this capability, so they did not ask for it and pusher and pushee worked exactly as before. But that way, the new versions of git push can learn to ask for report-status capability to updated receive-pack, and the new versions of receive-pack, after receiving and processing the pack data stream, can send new messages the original protocol did not allow it to send to git push. An important point to understand is that there is one more thing that is needed. The updated git push that asks for report-status needed to learn how to interpret the new message and act on it. Another example in the same protocol was the addition of sideband capability. Before that happened, there was no way to send the error stream from the pushee to the pusher. Unlike report-status that happens at the very end, this actually changes the way how the remainder of the protocol exchange proceeds once it is activated. You could add a new capability that says when in effect, both ends can write to and read from new sidebands 4 and 5 to communicate out of line, but that is not all that useful. You need to make the updated programs to agree on what should happen to the main interaction when a new kind of communication is made out of band. For example, you may ask do you really mean it [Y/n]? to the client, pause the entire transaction until you hear Yes or No from the client, and you may even choose to do something different from the usual when the client says No, but you also need to update the client to behave differently after that, perhaps by defining a new conversation path in the protocol. At that point, you would need to handle real and concrete definition of the extended protocol and the code on the both sides to support it _anyway_. For example, imagine that you want to let a new user interaction to verify the repository it is pushing to. How would we do that with your adding random interaction between the server and client? The server end notices that the user is trying to push into one repository. throws Do you really mean to push into repository foo? Updated client that understands your random interaction extention is capable of show this message, pauses until the user says Yes or No, and sends it back to the server end. If the answer is No, the client may want to say No, the repository I really wanted to push into was not foo, but bar. How did the client _know_ the Do you really mean message from the server requires a Yes or No response in the above scenario? How did the client know, when saying No, to ask the real URL of the repository to the end user, disconnect the current session with the
Re: [PATCH] buitin_config: return postitive status in get_value
On Sat, Jul 28, 2012 at 11:38:10PM -0700, Junio C Hamano wrote: Then the following patch may be better because it leaves other cases untouched (I'm not saying that we should or should not do it though) I personally think that the documentation unnecessarily exposes the useless value assignment of the exit codes (the use of different exit codes was done merely to aid debugging the git-config command itself) by describing the then-current set of conditions, and should be reduced to say 0 for success, non-zero for any error. We use ret=5 in the test suite to say unset this variable, but it's OK if it wasn't set in the first place but still fail on error. The only other one I can imagine that would be useful is you tried to get a variable but it did not exist, and there was no other error. Which is probably what ret=1 is attempting to do, though it also encompasses syntactically bogus keys. -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] buitin_config: return postitive status in get_value
On Sun, Jul 29, 2012 at 01:43:21PM -0700, Junio C Hamano wrote: But if we really want to follow that documented subset of possible conditions, I agree that your version to return 1 in this case, together with a change to initialize ret to 7 and document it as all other errors (ret=7), would make more sense. Other conditions that have been added since that partial enumeration of the exit code was done are regexp errors, which I think will get -1 from the same function. IOW, something like this. Documentation/git-config.txt | 18 ++ builtin/config.c | 8 ++-- 2 files changed, 16 insertions(+), 10 deletions(-) This looks right to me. Even if we are missing an error case, it is certainly going in the right direction. -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] cleanup argument passing in submodule status command
Jens Lehmann jens.lehm...@web.de writes: I tried today. Before this change no arguments got passed down and afterwards they are (but just the arguments, no submodule paths were passed on in either case; which is what Kevin fixed in the commit Heiko referenced). Three arguments are allowed for git submodule status: --recursive: It doesn't matter if we pass that on or not because $recursive is reused when eval cmd_status is executed. --quiet: Same as recursive, GIT_QUIET is set the first time and then reused in the recursion. --cached: This was dropped when recursing into submodules but isn't anymore with Heiko's change, so we do have a change in behavior here. ... Hmm, when --cached is used together with --recursive, I would expect it to show the commit stored in the index for the deeper submodules too (and not magically switch to show their HEAD again after the first level of submodules). To me this looks like a bug which Kevin accidentally introduced and nobody noticed and/or reported until now. So I'd vote for making this a bugfix patch for git submodule status --cached --recursive (and would love to see a test for it ;-). Yeah, I am not opposed to a fix. I just wanted it to be labelled as such, and analysed correctly. And with test ;-) Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Enable parallelism in git submodule update.
Heiko Voigt hvo...@hvoigt.net writes: On Fri, Jul 27, 2012 at 04:25:58PM -0700, Junio C Hamano wrote: ... Of course, any set of rules have exceptions ;-) There are a few things to which we say Even though it is not in POSIX, everybody who matters supports it, and without taking advantage of it, what we want to achieve will become too cumbersome to express. I was about to write that since this is limited to a given --jobs options the majority platforms should be enough as a start and others could add a parallelism mechanism later. Its only a matter of efficiency and not features. As long as git submodule --jobs 9 on a platform without GNU enhanced xargs does not error out and gracefully degrade to non parallel execution, I do not have any problem with it. As posted, the patch has not yet achieved that doneness yet. -- 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 0/3] null sha1 in trees
All looked reasonable, even though I'd want to read the surrounding codepath over for 2/3 a few more times. Will queue; thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] cherry: don't set ignored rev_info options
Ever since cherry was built-in in e827633 (Built-in cherry, 2006-10-24), it has set a bunch of options on the the rev_info that are only used while outputting a patch. But since the built-in cherry command never needs to output any patch (it uses add_commit_patch_id and has_commit_patch_id instead), these options are just distractions, so remove them. Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com --- builtin/log.c | 4 1 file changed, 4 deletions(-) diff --git a/builtin/log.c b/builtin/log.c index 7a92e3f..8cea1e5 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -1508,10 +1508,6 @@ int cmd_cherry(int argc, const char **argv, const char *prefix) } init_revisions(revs, prefix); - revs.diff = 1; - revs.combine_merges = 0; - revs.ignore_merges = 1; - DIFF_OPT_SET(revs.diffopt, RECURSIVE); if (add_pending_commit(head, revs, 0)) die(_(Unknown commit %s), head); -- 1.7.11.1.104.ge7b44f1 -- 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/3] remove unnecessary parameter from get_patch_ids()
get_patch_ids() takes an already initialized rev_info and a
prefix. The prefix is used when initalizing a second rev_info. Since
the initialized rev_info already has a prefix and the prefix never
changes, we can used the prefix from the initialized rev_info to
initialize the second rev_info.
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
builtin/log.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index ecc2793..7a92e3f 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -696,7 +696,7 @@ static int reopen_stdout(struct commit *commit, const char
*subject,
return 0;
}
-static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids, const
char *prefix)
+static void get_patch_ids(struct rev_info *rev, struct patch_ids *ids)
{
struct rev_info check_rev;
struct commit *commit;
@@ -717,7 +717,7 @@ static void get_patch_ids(struct rev_info *rev, struct
patch_ids *ids, const cha
init_patch_ids(ids);
/* given a range a..b get all patch ids for b..a */
- init_revisions(check_rev, prefix);
+ init_revisions(check_rev, rev-prefix);
o1-flags ^= UNINTERESTING;
o2-flags ^= UNINTERESTING;
add_pending_object(check_rev, o1, o1);
@@ -1306,7 +1306,7 @@ int cmd_format_patch(int argc, const char **argv, const
char *prefix)
if (hashcmp(o[0].item-sha1, o[1].item-sha1) == 0)
return 0;
}
- get_patch_ids(rev, ids, prefix);
+ get_patch_ids(rev, ids);
}
if (!use_stdout)
@@ -1525,7 +1525,7 @@ int cmd_cherry(int argc, const char **argv, const char
*prefix)
return 0;
}
- get_patch_ids(revs, ids, prefix);
+ get_patch_ids(revs, ids);
if (limit add_pending_commit(limit, revs, UNINTERESTING))
die(_(Unknown commit %s), limit);
--
1.7.11.1.104.ge7b44f1
--
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 0/3] Small log simplifications
Separated out the removal of the unused diff options into patch 2/3 and added the necessary max_parents=1 in patch 3/3. Martin von Zweigbergk (3): remove unnecessary parameter from get_patch_ids() cherry: don't set ignored rev_info options log: remove redundant check for merge commit builtin/log.c | 22 ++ 1 file changed, 6 insertions(+), 16 deletions(-) -- 1.7.11.1.104.ge7b44f1 -- 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 3/3] log: remove redundant check for merge commit
While walking the revision list in get_patch_ids and cmd_cherry, we
check for each commit if there is more than one parent and ignore the
commit if that is the case. Instead, set rev_info.max_parents to 1 and
let the revision traversal code handle it for us.
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
builtin/log.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 8cea1e5..3423d11 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -718,6 +718,7 @@ static void get_patch_ids(struct rev_info *rev, struct
patch_ids *ids)
/* given a range a..b get all patch ids for b..a */
init_revisions(check_rev, rev-prefix);
+ check_rev.max_parents = 1;
o1-flags ^= UNINTERESTING;
o2-flags ^= UNINTERESTING;
add_pending_object(check_rev, o1, o1);
@@ -726,10 +727,6 @@ static void get_patch_ids(struct rev_info *rev, struct
patch_ids *ids)
die(_(revision walk setup failed));
while ((commit = get_revision(check_rev)) != NULL) {
- /* ignore merges */
- if (commit-parents commit-parents-next)
- continue;
-
add_commit_patch_id(commit, ids);
}
@@ -1508,6 +1505,7 @@ int cmd_cherry(int argc, const char **argv, const char
*prefix)
}
init_revisions(revs, prefix);
+ revs.max_parents = 1;
if (add_pending_commit(head, revs, 0))
die(_(Unknown commit %s), head);
@@ -1530,10 +1528,6 @@ int cmd_cherry(int argc, const char **argv, const char
*prefix)
if (prepare_revision_walk(revs))
die(_(revision walk setup failed));
while ((commit = get_revision(revs)) != NULL) {
- /* ignore merges */
- if (commit-parents commit-parents-next)
- continue;
-
commit_list_insert(commit, list);
}
--
1.7.11.1.104.ge7b44f1
--
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: Enhancements to git-protocoll
On Mon, Jul 30, 2012 at 2:56 AM, Fredrik Gustafsson iv...@iveqy.com wrote: Sorry I missed this thread earlier. I'll drop this if it's not something that's wanted. On Sun, Jul 29, 2012 at 01:51:34PM -0700, Junio C Hamano wrote: Sitaram Chamarty sitar...@gmail.com writes: Uggh, no. Client-git should only talk to server-git. It shouldn't be talking first to some *other* program (in this case gitolite), and then to to server-git. That doesn't sound sane to me. This is exactly the way gitolite works. It's placed between git-server and git-client. Does some checks and approves a connection if some criterias isn't met. See the example when trying to clone an non-existing repo from gitolite. You won't get an git error but a gitolite error. I can understand why my idea is beeing rejected but I can't see why the gitolite way should be considered sane. It seems more like an hack to me (according to git design principles). So from a git point of view, why is it sane for passing through STDERR but not STDIN and STDOUT? That is precisely the point. The pack protocol (see Documentation/pack-protocol.txt in the git sources) works with STDIN/STDOUT. Run with GIT_TRACE_PACKET=1 to see some of that info fly past on various git commands. It explicitly leaves STDERR for the purpose of providing user's extra information, including errors. Gitolite is merely using that same mechanism. And I repeat, if you insist on calling what gitolite does an interaction (which to me means two-way communication, not a one-way error/warning/diagnostic stream), we do not have enough in common to discuss this any more. -- 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] link_alt_odb_entry: fix read over array bounds reported by valgrind
Heiko Voigt hvo...@hvoigt.net writes:
pfxlen can be longer than the path in objdir when relative_base contains
the path to gits object directory.
s/gits// perhaps Git's, but I am not sure.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
sha1_file.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4ccaf7a..631d0dd 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -251,7 +251,7 @@ static int link_alt_odb_entry(const char * entry, int
len, const char * relative
const char *objdir = get_object_directory();
struct alternate_object_database *ent;
struct alternate_object_database *alt;
- int pfxlen, entlen;
+ int pfxlen, entlen, objdirlen;
struct strbuf pathbuf = STRBUF_INIT;
if (!is_absolute_path(entry) relative_base) {
@@ -298,7 +298,8 @@ static int link_alt_odb_entry(const char * entry, int
len, const char * relative
return -1;
}
}
- if (!memcmp(ent-base, objdir, pfxlen)) {
+ objdirlen = strlen(objdir);
+ if (!memcmp(ent-base, objdir, pfxlen objdirlen ? objdirlen :
pfxlen)) {
The new code tells us to compare up to the shorter length between
objdir (i.e. path/to/.git/objects) and the given alternate object
directory (i.e. alt/path/to/.git/objects), but is that really what
we want? What happens if the given alternate object directory were
path/to/.git/objects-not-quite, with objdir path/to/.git/objects?
They are not the same directory, and this check is about avoiding
the common mistake of listing ... object directory itself, no?
free(ent);
return -1;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: PROPFIND 405 with git-http-backend and Smart HTTP
On Sun, Jul 29, 2012 at 11:52 AM, Bo98 boellisander...@aol.com wrote: I'm setting up a git server with git-http-backend and Smart HTTP but I'm getting PROPFIND Error 405 with git push. This suggests the client didn't see the server as one supporting smart HTTP. ... And here's a snip from my access_log: ::1 - - [29/Jul/2012:18:34:34 +0100] GET /repo/myproject.git/info/refs?service=git-receive-pack HTTP/1.1 200 117 Was this request actually served using the smart http-backend? Try the request yourself on the command line with curl, making sure to pass the ?service=git-receive-pack query parameter. A smart HTTP response will include a service=git-receive-pack line as the first line of the response body. I don't think Apache called the http-backend CGI, and so the client thought the server was not smart HTTP capable. -- 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] link_alt_odb_entry: fix read over array bounds reported by valgrind
Junio C Hamano gits...@pobox.com writes:
Heiko Voigt hvo...@hvoigt.net writes:
pfxlen can be longer than the path in objdir when relative_base contains
the path to gits object directory.
s/gits// perhaps Git's, but I am not sure.
Signed-off-by: Heiko Voigt hvo...@hvoigt.net
---
sha1_file.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4ccaf7a..631d0dd 100644
--- a/sha1_file.c
+++ b/sha1_file.c
return -1;
}
}
-if (!memcmp(ent-base, objdir, pfxlen)) {
+objdirlen = strlen(objdir);
+if (!memcmp(ent-base, objdir, pfxlen objdirlen ? objdirlen :
pfxlen)) {
The new code tells us to compare up to the shorter length between
objdir (i.e. path/to/.git/objects) and the given alternate object
directory (i.e. alt/path/to/.git/objects), but is that really what
we want? What happens if the given alternate object directory were
path/to/.git/objects-not-quite, with objdir path/to/.git/objects?
They are not the same directory, and this check is about avoiding
the common mistake of listing ... object directory itself, no?
free(ent);
return -1;
}
In other words, wouldn't this be sufficient? We NUL terminate
ent-base[pfxlen] when we prepare that buffer with
LEADING PATH\0XX/XX\0
in preparation for these duplicate check step, and then we turn
the NUL at ent-base[pfxlen] to '/' before leaving the function to
make it
LEADING PATH/XX/XX\0
so that we can fill XX when probing for loose objects.
sha1_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index 4f06a0e..a1f3bee 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -298,7 +298,7 @@ static int link_alt_odb_entry(const char * entry, int len,
const char * relative
return -1;
}
}
- if (!memcmp(ent-base, objdir, pfxlen)) {
+ if (!strcmp(ent-base, objdir)) {
free(ent);
return -1;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enhancements to git-protocoll
On Mon, Jul 30, 2012 at 3:08 AM, Junio C Hamano gits...@pobox.com wrote: Junio C Hamano gits...@pobox.com writes: Sitaram Chamarty sitar...@gmail.com writes: Uggh, no. Client-git should only talk to server-git. It shouldn't be talking first to some *other* program (in this case gitolite), and then to to server-git. That doesn't sound sane to me. You should wrap this whole thing around something else that does it in 3 steps. Check, create if needed, then the actual git command you intend to run. All this should be local to your environment, not rolled into git; it's far too specific to be rolled into git itself, if you ask me. Thanks for saving me from having to state an obvious sanity ;-) Having said all that, I am not fundamentally opposed to new features added to the git protocol. The responses so far from me in this thread were primarily me reacting to (1) auto creation by gitolite is a bad example and (2) the proposal sounded, at least to me, that it wants to add random and uncontrolled interactions between the sides outside the defined protocol exchange (e.g. pusher connects, pushee says what it has and what capabilities it supports, pusher says what it wants to update how and chooses what capabilities it wants to use in the exchange, sends the pack data, ...), which is an unworkable idea. For people who do not understand how the git protocol works (the proposal that started this thread included), a bit of clarification on (2) may help. Long time ago, we did not have report-status capability (think of a capability as a protocol extension). The git push protocol exchange ended with the pusher sending the pack data and that was the end of conversation. But we realized that it would be beneficial for the pushee to be able to tell the pusher that the push failed at the protocol level, so that the git push program can exit with an error code. The version of the git push program that was current at the time exited with success unconditionally, as long as all protocol exchange went well and all the pack data was sent successfully. The program's flow was not expecting any response once the pack data started flowing from it to the pushee, so that is the only reasonable behaviour. So what did we do? We added report-status capability to the capability suite, and made new versions of receive-pack program advertise it. Existing versions of git push did not know about this capability, so they did not ask for it and pusher and pushee worked exactly as before. But that way, the new versions of git push can learn to ask for report-status capability to updated receive-pack, and the new versions of receive-pack, after receiving and processing the pack data stream, can send new messages the original protocol did not allow it to send to git push. An important point to understand is that there is one more thing that is needed. The updated git push that asks for report-status needed to learn how to interpret the new message and act on it. Another example in the same protocol was the addition of sideband capability. Before that happened, there was no way to send the error stream from the pushee to the pusher. Unlike report-status that happens at the very end, this actually changes the way how the remainder of the protocol exchange proceeds once it is activated. You could add a new capability that says when in effect, both ends can write to and read from new sidebands 4 and 5 to communicate out of line, but that is not all that useful. You need to make the updated programs to agree on what should happen to the main interaction when a new kind of communication is made out of band. For example, you may ask do you really mean it [Y/n]? to the client, pause the entire transaction until you hear Yes or No from the client, and you may even choose to do something different from the usual when the client says No, but you also need to update the client to behave differently after that, perhaps by defining a new conversation path in the protocol. At that point, you would need to handle real and concrete definition of the extended protocol and the code on the both sides to support it _anyway_. For example, imagine that you want to let a new user interaction to verify the repository it is pushing to. How would we do that with your adding random interaction between the server and client? The server end notices that the user is trying to push into one repository. throws Do you really mean to push into repository foo? Updated client that understands your random interaction extention is capable of show this message, pauses until the user says Yes or No, and sends it back to the server end. If the answer is No, the client may want to say No, the repository I really wanted to push into was not foo, but bar. How did the client _know_ the Do you really mean message from the server requires a Yes or No response in the above
Re: git-tag documentation enhancement
乙酸鋰 ch3co...@gmail.com writes: I would like to enhance git-tag documentation --Unless -f is given, the tag to be created must not yet exist in the .git/refs/tags/ directory. ++Unless -f is given, the tag to be created must not yet exist in the .git/refs/tags/ directory or inside .git/packed-refs file. I think the updated text is technically correct, but I do not think it is a good direction to go. The root cause of the problem was that the original text assumed .git/refs/tags/ directory will forever be the only way to have a local tag, and the description was left behind when packed refs mechanism was introduced to improve the file system usage. It shouldn't have relied its description on such an implementation detail in the first place. The updated text still shares the same problem. I think the right fix is to say something like this: Unless -f is given, the tag to be created must not yet exist as a local tag. -- 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: Enhancements to git-protocoll
Sitaram Chamarty sitar...@gmail.com writes: As I may have said earlier, this interaction is far too site-specific to be rolled into git itself. How about a new hook instead? A pre-pack-protocol hook that acts as if it was called by the remote user as a command, and if it exit's with 0, then the real pack protocol starts else it gets aborted. Let him do whatever he wants in there. Arguments to the hook will be repo name and command (git-upload-pack mainly). Not very interested. If it is _known_ to happen before Git protocol proper happens, why not give the user something like the gitolite command D, that is interpreted by gitolite-shell without bothering Git at all? After all, at least you and I share the understanding that once the conversation in Git protocol proper starts, there is no place for such a random hook to affect further behaviour of the protocol, so the approach hook can only solve narrow before gitolite-shell (or git-shell or whatever-shell) decides it is time to call Git cases, and the only way it can affect the outcome of the main conversation is to abort it without graceful degradation, or let the main conversation continue as if nothing happened. I think we agree between us that a new hook, while it may be _a_ way to do something new, is _not_ a good way to do so. Why add such a wart? And even then, all we are doing is rolling into git something that he can very easily do outside right now on his own environment ... Yes, that is a repeat of what you told him already, to which I said thanks for sanity, I think ;-). I am not opposed to protocol enhancements, but a new feature that has to change what either end does should be added properly at the protocol level as a protocol capability, not added out of band with band-aid, leaving the main conversation oblivious to what is going on ouside. -- 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: Enhancements to git-protocoll
On Mon, Jul 30, 2012 at 6:51 AM, Shawn Pearce spea...@spearce.org wrote:
On Sun, Jul 29, 2012 at 6:04 PM, Sitaram Chamarty sitar...@gmail.com wrote:
Of course this will only work with ssh. None of what Fredrik has so
far suggested would possibly work on smart http without even more
hacks, I think.
Now that we have smart HTTP, and its somewhat popular for sites to
deploy with, we need to carefully consider all future protocol changes
to make sure they are compatible with the HTTP one. Since the HTTP is
single request/response model, its hard to implement a conversation
with the end-user.
One thing I would like to do with the protocol is add custom site
specific extensions to the protocol, where hooks are able to advertise
in the initial capability list something like a namespace prefix that
`git push` can use to offer site specific command line flags from:
... HEAD^{} report-status delete-refs side-band-64k
ofs-delta hook=gitolite
and the client seeing this would recognize a push command like:
git push -Lgitolite,create-repository URL master
passing the string gitolite,create-repository as data in the header
of the push request. gitolite would need to scan more than just the
git receive-pack command line from SSH to see this data, but you can
I would avoid anything that requires gitolite to even *know* the pack
protocol. They should be orthogonal.
But if you mean this extra info will be added to the command line
itself in some way (or in http terms to the REQUEST_URI, PATH_INFO,
QUERY_STRING, etc) then that's fine.
People who use gitolite already should try git ls-remote
git@host:testing.git1 instead of the usual ...testing or
...testing.git to see how a trace capability is currently hacked
into gitolite. Also change the 1 to a 2 then a 3 if you wish.
I'd certainly love a cleaner way of doing this, and what you suggest
seems it will satisfy.
use it to implement an are you sure you want to create this
repository exchange by failing a push with sideband information
telling the user to reinvoke push with the create-repository flag if
they really mean to create it.
We sort of want this in Gerrit Code Review to pass reviewer names on
the command line of git push, making it easier for users to upload a
code review. The idea is similar to what happens with gcc accepting
linker flags that are just passed onto the linker. From what I
understand, Mercurial already has something like this in their push
system for hooks to accept additional data one-way from the client.
--
Sitaram
--
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: Enhancements to git-protocoll
On Mon, Jul 30, 2012 at 6:58 AM, Junio C Hamano gits...@pobox.com wrote: Sitaram Chamarty sitar...@gmail.com writes: As I may have said earlier, this interaction is far too site-specific to be rolled into git itself. How about a new hook instead? A pre-pack-protocol hook that acts as if it was called by the remote user as a command, and if it exit's with 0, then the real pack protocol starts else it gets aborted. Let him do whatever he wants in there. Arguments to the hook will be repo name and command (git-upload-pack mainly). Not very interested. If it is _known_ to happen before Git protocol proper happens, why not give the user something like the gitolite command D, that is interpreted by gitolite-shell without bothering Git at all? Indeed. In one of the earlier messages I already told him he should copy and munge the fork command in gitolite to do precisely this. -- 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: Enhancements to git-protocoll
Shawn Pearce spea...@spearce.org writes: We sort of want this in Gerrit Code Review to pass reviewer names on the command line of git push, making it easier for users to upload a code review. The idea is similar to what happens with gcc accepting linker flags that are just passed onto the linker. For reviewer names, authentication cookies and things of that nature where the extra pieces of information affect the outcome in a way that does not have to change how the underlying protocol exchange works, such an additional one-way channel from the pusher to pushee to carry auxiliary information would be sufficient. The server may decide to accept otherwise forbidden, or reject otherwise permitted, push based on the extra information given, for example, and that is an example of an enhancement that does not have to change how the underlying protocol exchange works. The way to expose the extra information parsed by Git to the server side could be made into calling out to hooks, and at that point, gitolite would not even have to know about the pack protocol. Perhaps the interface to such a hook may be hook can tell Git to abort the communication by exiting non-zero, after giving a message to its standard output. It is a separate matter if it makes sense to add another channel that goes the other way on demand (i.e. taking the end-user response from the pusher and giving it to the pushee, and then allowing the pushee change its behaviour in a way more than just simply aborting the connection but performing a useful alternative operation)---I doubt it is. -- 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 (Jul 2012, #09; Sun, 29)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. We are getting closer to 1.7.12-rc1; I do not see any topic in 'next' (let alnoe 'pu') right now that is so urgent that cannot wait until the next release. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * mz/cherry-code-cleanup (2012-07-29) 3 commits - cherry: remove redundant check for merge commit - cherry: don't set ignored rev_info options - remove unnecessary parameter from get_patch_ids() Minor code clean-up on the cherry-pick codepath. Not urgent. * nd/maint-i18n-diffstat (2012-07-26) 1 commit - i18n: leave \n out of translated diffstat Will merge to 'next' and then down to 'master' by 1.7.2-rc1. * hv/link-alt-odb-entry (2012-07-29) 1 commit - link_alt_odb_entry: fix read over array bounds reported by valgrind The code to avoid mistaken attempt to add the object directory itself as its own alternate could read beyond end of a string while comparison. The patch is different from what was posted by Heiko. Waiting for comments. * jc/maint-config-exit-status (2012-07-29) 1 commit - config: git config baa should exit with status 1 The exit status code from git config was way overspecified while being incorrect. Update the implementation to give the documented status for a case that was documented, and introduce a new code for all other errors. * jk/maint-null-in-trees (2012-07-29) 3 commits - fsck: detect null sha1 in tree entries - do not write null sha1s to on-disk index - diff: do not use null sha1 as a sentinel value git diff used incorrectly an all-NUL object name as sentinel. * rj/maint-grep-remove-redundant-test (2012-07-29) 1 commit - t7810-*.sh: Remove redundant test git grep stopped spawning an external grep long time ago, but a duplicated test to check internal and external grep was left behind. -- [Graduated to master] * dg/submodule-in-dismembered-working-tree (2012-07-25) 1 commit (merged to 'next' on 2012-07-26 at cfa16c4) + git-submodule: work with GIT_DIR/GIT_WORK_TREE In a superproject that has repository outside of its working tree, git submodule add failed to clone a new submodule, as GIT_DIR and GIT_WORK_TREE environment variables necessary to work in such a superproject interfered with access to the submodule repository. * jk/autoident-test (2012-07-26) 6 commits (merged to 'next' on 2012-07-26 at f358a28) + t7502: test early quit from commit with bad ident + t7502: handle systems where auto-identity is broken + t7502: drop confusing test_might_fail call + t7502: narrow checks for author/committer name in template + t7502: properly quote GIT_EDITOR + t7502: clean up fake_editor tests Fix test breakages by a builder who does not have a valid user name in his /etc/password entry. * jk/help-plug-memleak (2012-07-25) 2 commits (merged to 'next' on 2012-07-26 at bd57cb8) + help.c::exclude_cmds(): plug a leak + help.c::uniq: plug a leak Plug a few trivial memory leaks. * jk/maint-checkout-orphan-check-fix (2012-07-25) 1 commit (merged to 'next' on 2012-07-26 at a513c5a) + checkout: don't confuse ref and object flags git checkout branchname to come back from a detached HEAD state incorrectly computed reachability of the detached HEAD, resulting in unnecessary warnings. -- [Stalled] * mz/rebase-range (2012-07-18) 7 commits - rebase (without -p): correctly calculate patches to rebase - rebase -p: don't request --left-right only to ignore left side - rebase -p: use --cherry-mark for todo file - git-rebase--interactive.sh: look up subject in add_pick_line - git-rebase--interactive: group all $preserve_merges code - git-rebase--interactive.sh: extract function for adding pick line - git-rebase--am.sh: avoid special-casing --keep-empty Expecting a reroll. Performance concerns from Windows folks. Also the series lacks proper sign-offs. * jl/submodule-rm (2012-07-05) 2 commits - rm: remove submodules from the index and the .gitmodules file - rm: don't fail when removing populated submodules Expecting a reroll. * ph/stash-rerere (2012-07-08) 2 commits - stash: invoke rerere in case of conflict - test: git-stash conflict sets up rerere Will be rerolled but is going in the right direction. * lt/commit-tree-guess-utf-8 (2012-06-28) 1 commit - commit/commit-tree: correct latin1 to utf-8 Teaches git commit and git commit-tree the we are told to use utf-8 in log message, but this does not look like utf-8---attempt to pass it through convert-from-latin1-to-utf8 and see if it makes sense heuristics git mailinfo already uses. A draft from Linus received privately without a log message. Expecting a reroll.
New git.pot is generated for the upcoming git v1.7.12
L10n teams: New git.pot is generated from git v1.7.12-rc0. L10n teams can get it from the usual place and start translation. * https://github.com/git-l10n/git-po/commits/master This update is quite small: l10n: Update git.pot (4 new, 3 removed messages) Generate po/git.pot from v1.7.12-rc0-54-g9e211, and there are 4 new, 3 removed l10n messages. * 4 new messages are added at lines: 1254, 1264, 1459, 1523 * 3 old messages are deleted from the previous version at lines: 1254, 1273, 2854 I am not sure whether Junio would like to merge new new i18n commits to the upcoming 1.7.12, but I bet there would be more i18n/l10n works in the future. (I would contribute more i18n update since I begin to update my book on Git in Chinese, any untranslated output would be fixed.) I also generate a git.pot from branch jx/i18n-1.7.11 in Junio's repo just for reference. The update is huge: l10n: Update git.pot (79 new, 6 removed messages) Generate po/git.pot from v1.7.11.2-256-g55653, and there are 79 new, 6 removed l10n messages. * 79 new messages are added at lines: 337, 342, 346, 350, 354, 359, 364, 370, 375, 380, 385, 395, 400, 404, 409, 413, 420, 427, 431, 435, 440, 447, 451, 456, 461, 466, ... * 6 old messages are deleted from the previous version at lines: 1254, 1273, 2854, 4726, 4761, 5292 You can find it from https://github.com/git-l10n/git-po/commits/jx/i18n-1.7.11 . -- Jiang Xin -- 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: Enhancements to git-protocoll
On Sun, Jul 29, 2012 at 7:38 PM, Junio C Hamano gits...@pobox.com wrote: Shawn Pearce spea...@spearce.org writes: We sort of want this in Gerrit Code Review to pass reviewer names on the command line of git push, making it easier for users to upload a code review. The idea is similar to what happens with gcc accepting linker flags that are just passed onto the linker. For reviewer names, authentication cookies and things of that nature where the extra pieces of information affect the outcome in a way that does not have to change how the underlying protocol exchange works, such an additional one-way channel from the pusher to pushee to carry auxiliary information would be sufficient. Yes, that is what I was trying to argue. :-) I agree that authentication information is outside of the Git protocol itself. We rely on SSH authentication for SSH and HTTP native authentication methods for HTTP transport. But at least in the HTTP case, the Git client has learned how to set up the authentication data for the user to make it easier to use HTTP authentication. We don't yet support native OAuth 2.0 (ick!) or HTTP cookies as well as we do client side SSL certificates or basic username/password pair. If we want to support additional information from pusher to pushee, this is a native feature of Git and should be supported on all native push type transports, with roughly the same semantics everywhere. I don't want to add additional data into X-Git-Foo HTTP headers in HTTP, and as environment variables in SSH, for example. Additional HTTP headers will *probably* transit an HTTP proxy correctly (but there are a lot of broken proxy servers so I don't put it past someone to strip an X-* header they don't think is safe). SSH environment variables are icky to set from the client, and server side Git would need to know how it was invoked to decode the correct data and make it available uniformly to repository owner authored hooks. The server may decide to accept otherwise forbidden, or reject otherwise permitted, push based on the extra information given, for example, and that is an example of an enhancement that does not have to change how the underlying protocol exchange works. Yes. The way to expose the extra information parsed by Git to the server side could be made into calling out to hooks, and at that point, gitolite would not even have to know about the pack protocol. Good point. The case that spawned this thread however still has a problem with this approach. gitolite would need to create a repository to invoke the receive-pack process within, and install that new hook script into... when the hook was trying to prevent the creation of that repository in the first place. Maybe I am jaded by the way JGit handles the protocol, it is easy for application code to glue into and see things going on in the protocol in ways that are hard to do from git-core. Perhaps the interface to such a hook may be hook can tell Git to abort the communication by exiting non-zero, after giving a message to its standard output. Perhaps this new channel data is simply passed as arguments to receive-pack on the remote side? An ancient Git would abort hard if passed this flag. An updated Git could set environment variables before calling hooks, making the arguments visible that way. And gitolite can still scrape what it needs from the command line without having to muck about inside of the protocol, but only if it needs to observe this new data from pusher to pushee? `git push -Rfoo=baz host:dest.git master` on the client would turn into `git-receive-pack -Rfoo=baz dest.git` in the SSH and git:// command line, and cause GIT_PUSH_ARG_FOO=baz to appear in the environment of hooks. Over smart HTTP requests would get an additional query parameter of foo=baz. The other hacky idea I had was to use a fake reference and have the client push a structured blob to that ref. The server would decode the blob, and deny the creation of the fake reference, but be able to get additional data from that blob. Its hacky, and I don't like making a new blob on the server just to transport a few small bits of data from the client. -- 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
