Re: [PATCH] http-backend: provide Allow header for 405
On Sun, Sep 08, 2013 at 06:15:06PM +, brian m. carlson wrote:
The HTTP 1.1 standard requires an Allow header for 405 Method Not Allowed:
The response MUST include an Allow header containing a list of valid methods
for the requested resource.
So provide such a header when we return a 405 to the user agent.
Makes sense.
if (strcmp(method, c-method)) {
const char *proto = getenv(SERVER_PROTOCOL);
- if (proto !strcmp(proto, HTTP/1.1))
+ if (proto !strcmp(proto, HTTP/1.1)) {
http_status(405, Method Not Allowed);
+ hdr_str(Allow, !strcmp(GET,
c-method) ?
+ GET, HEAD : c-method);
+ }
It took me a minute to figure out what is going on here. But we seem to
convert HEAD requests into GETs elsewhere, so any GET service should
be able to do either.
Looks OK to me.
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] pull: rename pull.rename to pull.mode
On Mon, Sep 9, 2013 at 9:21 PM, Jeff King p...@peff.net wrote: On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote: These deprecation warning messages should be written to stderr, and should probably be prefixed with WARNING: . Is there any deprecation warning that works this way? The ones in C code typically use warning(), which will prefix with warning: and write to stderr. They do not use all-caps, though. Try git log --grep=deprecate -Swarning for some examples. I'm asking about the ones in shell, because this is a shell script. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] pull: rename pull.rename to pull.mode
On Tue, Sep 10, 2013 at 01:46:27AM -0500, Felipe Contreras wrote: On Mon, Sep 9, 2013 at 9:21 PM, Jeff King p...@peff.net wrote: On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote: These deprecation warning messages should be written to stderr, and should probably be prefixed with WARNING: . Is there any deprecation warning that works this way? The ones in C code typically use warning(), which will prefix with warning: and write to stderr. They do not use all-caps, though. Try git log --grep=deprecate -Swarning for some examples. I'm asking about the ones in shell, because this is a shell script. Why would we want a deprecation warning to behave any differently if it is written in shell versus in C? It cannot use the warning() function, but you can easily emulate it with echo. Do you have some reason for not wanting the warning to go to stderr? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano gits...@pobox.com wrote: Which raises another question on my side: Isn't it tedious for you to both update DEF_VER *and* tag a version? Wouldn't it probably be less error prove (in the sense of keeping DEF_VER and tagged version in sync) to remove DEF_VER completely and just die if all ways to derive a Git version fail? I do not see how it will fly well. Some people want to build out of tarballs without having any describe, and DEF_VER and version were added for that specific purpose. Right, but do we really need DEF_VER *and* version? Couldn't we just package official source tarballs in a way that they already contain an auto-generated version file? a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag No. I always carry patches on top. That answer sidesteps the real issue; which one would you prefer if there are two or more tags? describe updated with your patch would consider both and I think it favours the annotated one over lightweight. If it matches the preferred order then G-V-N with you patch would help your workflow; otherwise you would still need a different way, e.g. making sure what you want it to use is always used by doing the version thing. My answer sidesteps the issue because you were explicitly offering the sidestep in you original question ;-) Anyway, in such a scenario I would probably prefer my own tag instead of upstream's tag, to be honest. So you're right that in this case my patch won't help. But like I said, the case is not valid for me as I will always carry patches on top, and other people might feel differently about which tag (annotated vs. lightweight) they prefer if both point to the same commit. -- Sebastian Schuberth -- To unsubscribe from this list: send the line 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] Reject non-ff pulls by default
On Mon, Sep 09, 2013 at 06:02:35PM -0500, Felipe Contreras wrote: On Mon, Sep 9, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk wrote: On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote: On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote: You are in favor of an _option_ to allow people to forbid a pull in a non-ff situation, and I think other people are also in agreement. So perhaps: - drop jc/pull-training-wheel and revert its merge from 'next'; - update Felipe's series with a bit of tweak to make it less impactful by demoting error into warning and advice. would be a good way forward? I think that would address the concern I raised, because it does not create a roadblock to new users accomplishing their task. They can ignore the warning, or choose merge as the default to shut up the warning (and it is easy to choose that if you are confused, because it is what git is doing by default alongside the warning). I think we need to make sure that we give instructions for how to go back if the default hasn't done what you wanted. Something like this: Your pull did not fast-forward, so Git has merged '$upstream' into your branch, which may not be correct for your project. If you would rather rebase your changes, run git rebase See pull.mode in git-config(1) to suppress this message in the future. And you propose to show that every single time the user does a 'git pull'' that results in a non-fast-forward merge? Isn't that what 'git pull --help' is for? Only if the user has not given an explicit mode (either on the command line or in their config) and possibly if an advice.pullNonFF variable is not set to false. I think that matches what Git does elsewhere. git-pull(1) provides quite a lot more information that I think a new Git user would be comfortable with. There certainly is not a quick way to find out how to fix this error and I don't think it makes sense to add one because we'll still be presenting the user with all of the other content and they won't have any way to know what they can safely ignore and what they have to read and understand. -- To unsubscribe from this list: send the line 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: What's cooking in git.git (Sep 2013, #02; Mon, 9)
Junio C Hamano gits...@pobox.com writes: * mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit - rebase: fix run_specific_rebase's use of return on FreeBSD Work around a bug in FreeBSD shell that caused a regression to git rebase in v1.8.4. It would be lovely to hear from FreeBSD folks a success report to make sure we didn't miss any other use of a bare return from dot-sourced script. Will merge to 'next'. BTW, this is a candidate for maint too I guess. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] pull: rename pull.rename to pull.mode
Felipe Contreras felipe.contre...@gmail.com writes: On Mon, Sep 9, 2013 at 9:21 PM, Jeff King p...@peff.net wrote: On Mon, Sep 09, 2013 at 05:49:36PM -0500, Felipe Contreras wrote: These deprecation warning messages should be written to stderr, and should probably be prefixed with WARNING: . Is there any deprecation warning that works this way? The ones in C code typically use warning(), which will prefix with warning: and write to stderr. They do not use all-caps, though. Try git log --grep=deprecate -Swarning for some examples. I'm asking about the ones in shell, because this is a shell script. No user cares whether git pull is written in shell. shell Vs C is an implementation detail, stdout Vs stderr is user-visible. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Reject non-ff pulls by default
Felipe Contreras felipe.contre...@gmail.com writes: The problem is the newcomers, and the newcomers will most definitely not activate a configuration option to tell them that they are doing something potentially undesirable. I teach Git to 200 newcommers each year. All of them run git pull the first day, but believe me, very few of them want to know what a rebase is at that time. (I also work with experienced computer scientists, and actually, very few of them want to know what a rebase is either :-( ) By the time they learn about pull.mode, they probably already know what a rebase is. So what is the point of the configuration in the first place? [...] That doesn't mean anything, you are assuming the user will do 'git pull --rebase', and there's no rationale as to why they would end up doing that. So, you insist in asking the user to chose between rebase and merge, but you also insist that they will not chose rebase? So, why ask? 'git commit' by default prevents users from creating commits without first adding changes to the staging area, and since it's a concept unique to Git, it's fair to say that none of the newcomers understand why 'git commit' is failing, the error messages is not particularly useful either. I don't particularly agree that not defaulting to --all was a good idea, but that's another topic. But the error message is rather clear: no changes added to commit (use git add and/or git commit -a) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Proposal] Clonable scripts
Hi, On Tue, Sep 10, 2013 at 12:18 AM, Ramkumar Ramachandra artag...@gmail.com wrote: Niels Basjes wrote: As we all know the hooks ( in .git/hooks ) are not cloned along with the code of a project. Now this is a correct approach for the scripts that do stuff like emailing the people responsible for releases or submitting the commit to a CI system. More often than not, maintainers come with these hooks and they keep them private. Yes. Initially I wanted to propose introducing fully clonable (pre-commit) hook scripts. However I can imagine that a malicious opensource coder can create a github repo and try to hack the computer of a contributer via those scripts. So having such scripts is a 'bad idea'. I think it's a good idea, since the contributer can look through the scripts. What I meant to say is that having fully functional unrestricted scripts that are cloned is a bad idea. Having restricted cloned scripts to me is a goog idea (or atleast, that is what I propose here). 3) For the regular hooks this language is also support and when located in the (not cloned!) .git/hooks directory they are just as powerful as a normal script (i.e. can control CI, send emails, etc.). I'm confused now; how can .git/hooks be as powerful as .githooks? The former users should consider uploading their code on GitHub. The way I envisioned is is that the scripting language in .git/hooks is pick any language you like with the builtin language as a new addition. In the .githooks (which is under version control in the code base and cloned) is a the same builtin language, yet constrained in a sandbox. Which reminds me that we need to have GitTogethers. Thanks for this! You're welcome. -- Best regards / Met vriendelijke groeten, Niels Basjes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Disabling status hints in COMMIT_EDITMSG
Hi, I just noticed that the template COMMIT_EDITMSG was containing status hints, and that they were not particularty helpfull _during_ a commit. I think it would be sensible to ignore advice.statusHints and disable hints unconditionally when writting to COMMIT_EDITMSG. Any objection? -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Proposal] Clonable scripts
On 09/10/2013 02:18 AM, Niels Basjes wrote: As we all know the hooks ( in .git/hooks ) are not cloned along with the code of a project. Now this is a correct approach for the scripts that do stuff like emailing the people responsible for releases or submitting the commit to a CI system. For several other things it makes a lot of sense to give the developer immediate feedback. Things like the format of the commit message (i.e. it must start with an issue tracker id) or compliance with a coding standard. Initially I wanted to propose introducing fully clonable (pre-commit) hook scripts. However I can imagine that a malicious opensource coder can create a github repo and try to hack the computer of a contributer via those scripts. So having such scripts is a 'bad idea'. If those scripts were how ever written in a language that is build into the git program and the script are run in such a way that they can only interact with the files in the local git (and _nothing_ outside of that) this would be solved. Also have a builtin scripting language also means that this would run on all operating systems (yes, even Windows). So I propose the following new feature: 1) A scripting language is put inside git. Perhaps a version of python or ruby or go or ... (no need for a 'new' language) 2) If a project contains a folder called .githooks in the root of the code base then the rules/scripts that are present there are executed ONLY on the system doing the actual commit. These scripts are run in such a limited way that they can only read the files in the repository, they cannot do any networking/write to disk/etc and they can only do a limited set op actions against the current operation at hand (i.e. do checks, parse messages, etc). 3) For the regular hooks this language is also support and when located in the (not cloned!) .git/hooks directory they are just as powerful as a normal script (i.e. can control CI, send emails, etc.). Like I said, this is just a proposal and I would like to know what you guys think. I am not in favour of any idea like this. It will end in some sort of compromise (in both sense of the word!) It has to be voluntary, but we can make it easier. I suggest something like this: - some special directory can have normal hook files, but it's just a place holder. - each hook code file comes with some meta data at the top, say githook name, hook name, version, remote-name. I'll use these examples: pre-commit crlf-check 1.1 origin - on a clone/pull, if there is a change to any of these code files when compared to the previous HEAD, and if the program is running interactively, then you can ask and setup these hooks. The purpose of the remote name in the stored metadata is that we don't want to bother updating when we pull from some other repo, like when merging a feature branch. The purpose of the version number is so you can do some intelligent things, even silently upgrade under certain conditions. All we're doing is making things easier compared to what you can already do even now (which is completely manual and instructions based). I don't think anything more intrusive or forced is wise. And people who say it is OK, I'm going to seriously wonder if you work for the NSA (directly or indirectly). Sadly, that is not meant to be a joke question; such is life now. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disabling status hints in COMMIT_EDITMSG
On 10/09/13 21:19, Matthieu Moy wrote: Hi, I just noticed that the template COMMIT_EDITMSG was containing status hints, and that they were not particularty helpfull _during_ a commit. I think it would be sensible to ignore advice.statusHints and disable hints unconditionally when writting to COMMIT_EDITMSG. Any objection? I did recently find them useful/reassuring when I was committing a merge. But I wouldn't consider that a strong objection. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Tue, Sep 10, 2013 at 3:06 AM, Sebastian Schuberth sschube...@gmail.com wrote: On Sun, Sep 8, 2013 at 7:41 PM, Junio C Hamano gits...@pobox.com wrote: a case where you have your own tag that points at the exact version as I tagged? In such a case, do you have a preference on which tag No. I always carry patches on top. That answer sidesteps the real issue; which one would you prefer if there are two or more tags? describe updated with your patch would consider both and I think it favours the annotated one over lightweight. If it matches the preferred order then G-V-N with you patch would help your workflow; otherwise you would still need a different way, e.g. making sure what you want it to use is always used by doing the version thing. My answer sidesteps the issue because you were explicitly offering the sidestep in you original question ;-) Anyway, in such a scenario I would probably prefer my own tag instead of upstream's tag, to be honest. So you're right that in this case my patch won't help. But like I said, the case is not valid for me as I will always carry patches on top, and other people might feel differently about which tag (annotated vs. lightweight) they prefer if both point to the same commit. Indeed. I prefer it the other way; annotated takes precedence. -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disabling status hints in COMMIT_EDITMSG
Chris Packham judge.pack...@gmail.com writes: On 10/09/13 21:19, Matthieu Moy wrote: Hi, I just noticed that the template COMMIT_EDITMSG was containing status hints, and that they were not particularty helpfull _during_ a commit. I think it would be sensible to ignore advice.statusHints and disable hints unconditionally when writting to COMMIT_EDITMSG. Any objection? I did recently find them useful/reassuring when I was committing a merge. But I wouldn't consider that a strong objection. Just to make sure we're talking about the same thing: when commiting a merge, the template currently looks like: Merge branch 'master' of /tmp/git Conflicts: foo.txt # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # Your branch and 'origin/master' have diverged, # and have 3 and 1 different commit each, respectively. # (use git pull to merge the remote branch into yours) # # All conflicts fixed but you are still merging. # (use git commit to conclude merge) # # Changes to be committed: # # modified: foo.txt # What I'd like to remove are the parts between parenthesis : (use git commit to conclude merge) (use git pull to merge the remote branch into yours) The first part (It looks like [...]) would remain, of course. Actually, even the All conflicts fixed but you are still merging. part is not really accurate when the commit is already started. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Proposal] Clonable scripts
On Mon, 09 Sep 2013 22:48:42 +, Niels Basjes wrote: ... However I can imagine that a malicious opensource coder can create a github repo and try to hack the computer of a contributer via those scripts. So having such scripts is a 'bad idea'. Given that half the repos out there are cloned to 'make install' in them...it's still a bad idea. If those scripts were how ever written in a language that is build into the git program and the script are run in such a way that they can only interact with the files in the local git (and _nothing_ outside of that) this would be solved. I still think this is a nightmare of maintenance. You'd need a restricted version of a language that doesn't allow access outside the repo (and no TCP either), and someone will always miss some module... Not that it wouldn't be cool, yet. ... Like I said, this is just a proposal and I would like to know what you guys think. I think there are generally two use cases: - Many people working on repos in an organization. Give them a wrapper script that does the clone (and also knows the clone URL already), that will set up hooks and configuration as needed. - github-style cooperation. Add a make hooks to your Makefile that sets up the hooks your project seems to want. After all, this is for the developers to pre-check what they will submit, so it is in their own interest to have (and cross-read) the hooks. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
(Please CC me as I am not subscribed.) $ git config -l | grep '^branch.master\|^push.' push.default=upstream branch.master.remote=upstream branch.master.merge=refs/heads/master branch.master.pushremote=origin $ git branch * master $ git push fatal: You are pushing to remote 'origin', which is not the upstream of your current branch 'master', without telling me what to push to update which remote branch. push.default=upstream means push back where it came from (*). However, if I specifically define remote.pushdefault or branch.*.pushremote, this clearly means I don't want to do (*) in this case. The question here then is, what remote branch should git push to - since pushremote only specifies a repo? I can suggest two options: - A: push to branch.*.merge if it's defined; otherwise push to current branch (like push.default=current) - B: push to current branch regardless B is probably simpler and means you can amend the push.default manual entry more easily: upstream: [..] This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow). INSIf you are not pushing to the same repository, acts as current./INS (Note again; that this is a special case when push.default=upstream because of the this mode only makes sense semantics. The other values for push.default are simpler and do not result in a conflict.) Alternatively, an even more simple behaviour is to adjust the error message to communicate the root cause: $ git push fatal: branch.*.pushremote is not compatible with push.default = upstream X -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git signature.asc Description: OpenPGP digital signature
Regression in e02ca72: git svn rebase is broken on Windows
Hi, After bisecting this problem I ended up with the mentioned commit that completely breaks git-svn for me on Windows (mingw/msys version). == # git svn rebase warning: unable to access '': Invalid argument warning: unable to access '': Invalid argument fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': Invalid argument fatal: index file open failed: Invalid argument Cannot rebase: You have unstaged changes. Please commit or stash them. rebase refs/remotes/trunk: command returned error: 1 == Please note that I use the official git repository as-is, this one (no additional patches): git://git.kernel.org/pub/scm/git/git.git e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit commit e02ca72f70ed8f0268a81f72cb3230c72e538e77 Author: Jiang Xin Date: Tue Jun 25 23:53:43 2013 +0800 path.c: refactor relative_path(), not only strip prefix Thanks, --Tvangeste -- To unsubscribe from this list: send the line 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-Transmission of blobs?
Hello, as we all know, files are identified by their SHA. Thus I had the impression that when transfering files, git would know by the SHA whether a given file is already available in the destination repository and the transfer would be of no use. But this don't seem to be tha case. Lets see this example: $ cat t.sh #! /bin/sh -ex LANG= rm -rf 1 2 git init 1 git clone 1 2 cd 1 git commit --allow-empty -m initial structure git co -b somebranch dd if=/dev/urandom count=10 bs=1024k t git add t git commit -m blah cd ../2 git pull git cherry-pick origin/somebranch git push -v $ ./t.sh + LANG= + rm -rf 1 2 + git init 1 Initialized empty Git repository in /home/jw/test/1/.git/ + git clone 1 2 Cloning into '2'... warning: You appear to have cloned an empty repository. done. + cd 1 + git commit --allow-empty -m 'initial structure' [master (root-commit) 97e52e2] initial structure + git co -b somebranch Switched to a new branch 'somebranch' + dd if=/dev/urandom count=10 bs=1024k 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 1.3202 s, 7.9 MB/s + git add t + git commit -m blah [somebranch b11cf51] blah 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 t + cd ../2 + git pull remote: Counting objects: 5, done. remote: Compressing objects: 100% (3/3), done. remote: Total 5 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (5/5), done. From /home/jw/test/1 * [new branch] master - origin/master * [new branch] somebranch - origin/somebranch + git cherry-pick origin/somebranch [master 9e8f1c6] blah 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 t + git push -v warning: push.default is unset; its implicit value is changing in Git 2.0 from 'matching' to 'simple'. To squelch this message and maintain the current behavior after the default changes, use: git config --global push.default matching To squelch this message and adopt the new behavior now, use: git config --global push.default simple See 'git help config' and search for 'push.default' for further information. (the 'simple' mode was introduced in Git 1.7.11. Use the similar mode 'current' instead of 'simple' if you sometimes use older versions of Git) Pushing to /home/jw/test/1 Counting objects: 4, done. Delta compression using up to 2 threads. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 10.00 MiB, done. Total 3 (delta 0), reused 0 (delta 0) To /home/jw/test/1 97e52e2..9e8f1c6 master - master updating local tracking ref 'refs/remotes/origin/master' $ As we can see in this example, the big file is tranferred back to the first repository, although it is already available there. This is very annoying if you have a very slow connection. Am I missing some important point here? -- Josef Wolf j...@raven.inka.de -- To unsubscribe from this list: send the line 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-cvsserver strips exec bit
Hello, On git 1.8.1.x (Fedora 18) I was able to use the git-cvsserver to checkout code to package into a tarball. Script files that were in git with 755 masks were checked-out with the same mask. After upgrading the git repository machine to Fedora 19 (1.8.3.1) the behaviour has changed. When I checkout the same script files their mask is now 644. The mask has not changed in git. I understand I can use git-archive to perform the same functionality, but I'd like to report this issue here. Thanks, Michael -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
Hi Tvangeste, On Tue, 10 Sep 2013, Tvangeste wrote: After bisecting this problem I ended up with the mentioned commit that completely breaks git-svn for me on Windows (mingw/msys version). Have you tried with Git for Windows yet? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
Ximin Luo infini...@gmx.com writes:
(Please CC me as I am not subscribed.)
$ git config -l | grep '^branch.master\|^push.'
push.default=upstream
branch.master.remote=upstream
branch.master.merge=refs/heads/master
branch.master.pushremote=origin
$ git branch
* master
$ git push
fatal: You are pushing to remote 'origin', which is not the upstream of
your current branch 'master', without telling me what to push
to update which remote branch.
push.default=upstream means push back where it came from (*). However, if I
specifically define remote.pushdefault or branch.*.pushremote, this clearly
means I don't want to do (*) in this case.
I think this was discussed on the list during the last development
cycle. Please check the list archive.
git config --help has this to say about it:
* `upstream` - push the current branch back to the branch whose
changes are usually integrated into the current branch (which is
called `@{upstream}`). This mode only makes sense if you are
pushing to the same repository you would normally pull from
(i.e. central workflow).
* `simple` - in centralized workflow, work like `upstream` with an
added safety to refuse to push if the upstream branch's name is
different from the local one.
When pushing to a remote that is different from the remote you normally
pull from, work as `current`.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
Sebastian Schuberth sschube...@gmail.com writes: Right, but do we really need DEF_VER *and* version? Couldn't we just package official source tarballs in a way that they already contain an auto-generated version file? If you read our Makefile, you will see that we do include the version file in our official tarball with make dist. That however does not help those who use a tarball obtained from git-archive, perhaps via gitweb running at the distribution site. Theoretically speaking, you can rip out everything but version and tell those who have been relying on the way other parts of G-V-G worked to change their workflow to stuff their favorite version string to that file before building, so in that sense, we do not *need* DEF_VER and version. But they have been there for a long time, and I do not think it gives us a good trade-off between risking regression and reducing the linecount to change it to remove one. -- To unsubscribe from this list: send the line 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: What's cooking in git.git (Sep 2013, #02; Mon, 9)
Am 10.09.2013 00:53, schrieb Junio C Hamano: * bc/submodule-status-ignored (2013-09-04) 2 commits - submodule: don't print status output with ignore=all - submodule: fix confusing variable name Originally merged to 'next' on 2013-08-22 Will merge to 'next'. I propose to cook this some time in next to give submodule users who have configured ignore=all the opportunity to test and comment on that. And as Matthieu noticed the documentation is not terribly clear here, I'll prepare one or two patches to fix that which should go in together with these changes. -- To unsubscribe from this list: send the line 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 v6 0/8] Multiple simultaneously locked ref updates
Brad King brad.k...@kitware.com writes: Updates since the previous revision of the series: * The entire series was rebased on master at bb80ee09; it was previously based on v1.8.4. * A conflict in refs.c with 47a59185 was resolved by preserving the elimination of find_ref_by_name while adding our new content. * A conflict in builtin/update-ref.c with d5d09d47 (Replace deprecated OPT_BOOLEAN by OPT_BOOL, 2013-08-03) was resolved by integrating both changes. The new options added in patch 7 now use OPT_BOOL. I just test-applied these on top of bb80ee09 (Update draft release notes to 1.8.5 for the second batch of topics, 2013-09-09), and compared the result with the result of merging the tip of the previous round 511910e1 (update-ref: add test cases covering --stdin signature, 2013-09-09) with bb80ee09, and they more-or-less match (the order of options[] array elements may differ in update-index.c), which validates that existing merge conflict resolution matches your expectation. Thanks. I am not sure if I should rewind and rebuild the series with these patches, though. This is a new feature and does not have to be merged to 'maint', so rebasing is perfectly fine, but it is not strictly necessary, either. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/14] reduce confusion over smart server response behaviour
The MUST and the following 'If' scenario may seem contradictory at first glance; swap their order to alleviate this. Also mention that the response should specifically be for the requested service, for clarity's sake. Based on: From: Junio C Hamano gits...@pobox.com Message-ID: 7vskdss3ei@alter.siamese.dyndns.org +Smart Server Response +^ + +Smart servers MUST respond with the smart server reply format. +If the server does not recognize the requested service name, or the +requested service name has been disabled by the server administrator, +the server MUST respond with the '403 Forbidden' HTTP status code. This is a bit confusing. If you as a server administrator want to disable the smart upload-pack for one repository (but not for other repositories), you would not be able to force smart clients to fall back to the dumb protocol by giving 403 for that repository. Maybe in 2 years somebody smarter than us will have invented a more efficient git-upload-pack-2 service, which is the only fetch protocol his server supports other than dumb. If your v1 smart client asks for the original git-upload-pack service and gets a 403, you won't be able to fall back to dumb. The solution for such cases likely is to pretend as if you are a dumb server for the smart request. That unfortunately means that the first sentence is misleading, and the second sentence is also an inappropriate advice. Signed-off-by: Tay Ray Chuan rcta...@gmail.com --- Documentation/technical/http-protocol.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index 4bb1614..63a089a 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -234,12 +234,13 @@ description of the dumb server response. Smart Server Response ^ -Smart servers MUST respond with the smart server reply format. - If the server does not recognize the requested service name, or the requested service name has been disabled by the server administrator, the server MUST respond with the '403 Forbidden' HTTP status code. +Otherwise, smart servers MUST respond with the smart server reply +format for the requested service name. + Cache-Control headers SHOULD be used to disable caching of the returned entity. -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disabling status hints in COMMIT_EDITMSG
Matthieu Moy matthieu@grenoble-inp.fr writes: Hi, I just noticed that the template COMMIT_EDITMSG was containing status hints, and that they were not particularty helpfull _during_ a commit. I think it would be sensible to ignore advice.statusHints and disable hints unconditionally when writting to COMMIT_EDITMSG. Any objection? I agree that the extra this is how you may rectify the situation lines like these look useless at the first glance. # Changes to be committed: # (use git reset HEAD file... to unstage) # # new file: foo # # Untracked files: # (use git add file... to include in what will be committed) # # bar # The whole point of showing the list is to give the user a chance to notice mistakes, and after noticing a mistake, what the user does is to abort the commit, not git reset HEAD file nor git add file. But at the same time, I feel that these redundant lines, especially the latter one, would give the users a stronger cue than just saying that bar is Untracked; do X to include reminds that bar will not be included if nothing is done. So I am on the fence on this one. No strong objection, but I suspect those who do not have any voice in this discussion (i.e. those who are about to start using Git) may be helped by keeping these lines. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/14] normalize indentation with protcol-common.txt
Indent client/server query examples with 3 spaces.
Indent ABNF rules with 2 spaces.
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
--
This is in its own patch to minimize noise in diffs.
---
Documentation/technical/http-protocol.txt | 226 +++---
1 file changed, 113 insertions(+), 113 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 0a2a53d..70a1648 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -161,14 +161,14 @@ Dumb HTTP clients MUST NOT include search/query
parameters when
fetching the info/refs file. (That is, '?' must not appear in the
requested URL.)
- C: GET $GIT_URL/info/refs HTTP/1.0
+ C: GET $GIT_URL/info/refs HTTP/1.0
- S: 200 OK
- S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 200 OK
+ S:
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
The Content-Type of the returned info/refs entity SHOULD be
text/plain; charset=utf-8, but MAY be any content type.
@@ -187,17 +187,17 @@ each ref and its known value. The file SHOULD be sorted
by name
according to the C locale ordering. The file SHOULD NOT include
the default ref named 'HEAD'.
- info_refs = *( ref_record )
- ref_record= any_ref | peeled_ref
+ info_refs= *( ref_record )
+ ref_record = any_ref | peeled_ref
- any_ref = id HT name LF
- peeled_ref= id HT name LF
- id HT name ^{} LF
- id= 40*HEX
+ any_ref = id HT name LF
+ peeled_ref = id HT name LF
+ id HT name ^{} LF
+ id = 40*HEX
- HEX = 0..9 | a..f
- LF= US-ASCII LF, linefeed (10)
- HT= US-ASCII HT, horizontal-tab (9)
+ HEX = 0..9 | a..f
+ LF = US-ASCII LF, linefeed (10)
+ HT = US-ASCII HT, horizontal-tab (9)
Smart Clients
~
@@ -211,26 +211,26 @@ The request MUST contain exactly one query parameter,
name the client wishes to contact to complete the operation.
The request MUST NOT contain additional query parameters.
- C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
-
- dumb server reply:
- S: 200 OK
- S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
-
- smart server reply:
- S: 200 OK
- S: Content-Type: application/x-git-upload-pack-advertisement
- S: Cache-Control: no-cache
- S:
- S: # service=git-upload-pack
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0
multi_ack
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
+
+ dumb server reply:
+ S: 200 OK
+ S:
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+
+ smart server reply:
+ S: 200 OK
+ S: Content-Type: application/x-git-upload-pack-advertisement
+ S: Cache-Control: no-cache
+ S:
+ S: # service=git-upload-pack
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0 multi_ack
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
Dumb Server Response
@@ -281,28 +281,28 @@ the C locale ordering. The stream SHOULD include the
default ref
named 'HEAD' as the first ref. The stream MUST include capability
declarations behind a NUL on the first ref.
- smart_reply= PKT-LINE(# service=$servicename LF)
-ref_list
-
- ref_list = empty_list | non_empty_list
+ smart_reply = PKT-LINE(# service=$servicename LF)
+ ref_list
+
[PATCH 05/14] drop rules, etc. common to the pack protocol
Use obj-id in lieu of id (defined as 40*HEX).
Use zero-id in lieu of 40*0.
Use refname in lieu of name (not defined).
Drop section on capabilities, since they are already available in
protocol-capabilities.txt.
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
--
pkt-line format section was dropped in response to Junio's comments:
From: Junio C Hamano gits...@pobox.com
Message-ID: 7vskdss3ei@alter.siamese.dyndns.org
+pkt-line Format
+---
...
+Examples (as C-style strings):
+
+ pkt-line actual value
+ -
+ 0006a\n a\n
+ 0005a a
+ 000bfoobar\nfoobar\n
+ 0004
+
+A pkt-line with a length of 0 () is a special case and MUST
+be treated as a message break or terminator in the payload.
Isn't this MUST be wrong?
It is not an advice to the implementors, but the protocol specification
itself defines what the flush packet means. IOW, The author of this
specification, Shawn, MUST treat a flush packet as a message break or
terminator in the payload, when designing this protocol.
Capabilities and 'command' ABNF rules under git-upload-pack were
dropped by Nguyễn:
Message-ID: 1377092713-25434-1-git-send-email-pclo...@gmail.com
---
Documentation/technical/http-protocol.txt | 85 ---
1 file changed, 10 insertions(+), 75 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index ff91bb0..a8d28ba 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -84,34 +84,6 @@ as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore
any
cookies sent by a client.
-pkt-line Format
-
-Much (but not all) of the payload is described around pkt-lines.
-
-A pkt-line is a variable length binary string. The first four bytes
-of the line indicates the total length of the line, in hexadecimal.
-The total length includes the 4 bytes used to denote the length.
-A line SHOULD BE terminated by an LF, which if present MUST be
-included in the total length.
-
-A pkt-line MAY contain binary data, so implementors MUST ensure all
-pkt-line parsing/formatting routines are 8-bit clean. The maximum
-length of a pkt-line's data is 65532 bytes (65536 - 4).
-
-Examples (as C-style strings):
-
- pkt-line actual value
- -
- 0006a\n a\n
- 0005a a
- 000bfoobar\nfoobar\n
- 0004
-
-A pkt-line with a length of 0 () is a special case and MUST
-be treated as a message break or terminator in the payload.
-
-
General Request Processing
--
@@ -194,11 +166,9 @@ the default ref named 'HEAD'.
info_refs= *( ref_record )
ref_record = any_ref / peeled_ref
- any_ref = id HTAB name LF
- peeled_ref = id HTAB name LF
- id HTAB name ^{} LF
- id = 40*HEX
-
+ any_ref = obj-id HTAB refname LF
+ peeled_ref = obj-id HTAB refname LF
+ obj-id HTAB refname ^{} LF
Smart Clients
~
@@ -283,23 +253,7 @@ named 'HEAD' as the first ref. The stream MUST include
capability
declarations behind a NUL on the first ref.
smart_reply = PKT-LINE(# service=$servicename LF)
- ref_list
-
- ref_list = empty_list / non_empty_list
-
- empty_list = PKT-LINE(id SP capabilities^{} NUL cap_list LF)
-
- non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
- *ref_record
-
- cap_list = *(SP capability) SP
- ref_record = any_ref / peeled_ref
-
- any_ref = PKT-LINE(id SP name LF)
- peeled_ref = PKT-LINE(id SP name LF)
- PKT-LINE(id SP name ^{} LF
- id = 40*HEX
-
+ advertised-refs
Smart Service git-upload-pack
--
@@ -345,31 +299,9 @@ appear in the response obtained through ref discovery.
have_list= *PKT-LINE(have SP id LF)
- command = create / delete / update
- create = 40*0 SP new_id SP name
- delete = old_id SP 40*0 SP name
- update = old_id SP new_id SP name
-
TODO: Document this further.
TODO: Don't use uppercase for variable names below.
-Capability include-tag
-~~
-
-When packing an object that an annotated tag points at, include the
-tag object too. Clients can request this if they want to fetch
-tags, but don't know which tags they will need until after they
-receive the branch data. By enabling include-tag an entire call
-to upload-pack can be avoided.
-
-Capability thin-pack
-
-
-When packing a deltified object the base is not included if the base
-is reachable from an object listed in the COMMON set by the
[PATCH 08/14] mention different variations around $GIT_URL
Based on
From: Alex Blewitt alex.blew...@gmail.com
Message-ID: loom.20091009t104530-...@post.gmane.org
Shawn O. Pearce spearce at spearce.org writes:
+URL Format
+--
+
+URLs for Git repositories accessed by HTTP use the standard HTTP
+URL syntax documented by RFC 1738, so they are of the form:
+
+ http://host:port/path
+
+Within this documentation the placeholder $GIT_URL will stand for
+the http:// repository URL entered by the end-user.
It's worth making clear here that $GIT_URL will be the path to the repository,
rather than necessarily just the host upon which the server sits. Perhaps
including an example, like http://example:8080/repos/example.git
would make it clearer that there can be a path (and so leading to
a request like http://example:8080/repos/example.git/info/refs?service=...
It's also worth clarifying, therefore, that multiple repositories can be
served
by the same process (as with the git server today) by using different path(s).
And for those that are interested in submodules, it's worth confirming that
http://example/repos/master.git/child.git/info/refs?service= will ensure
that the repository is the 'child' git rather than anything else.
The submodule example (/master.git/child.git) seems potentially
confusing - it suggests a setup where the server has a route to a git
repo (child.git) with a parent path containing another git repo
(master.git). It is excluded lest we be seen as encouraging such
mind-boggling setups.
While providing an example $GIT_URL containing a '?' (the catch-all
gateway one), also mention a possible contradiction between the
exactly-one-param requirement and the http client implementation in Git.
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
---
Documentation/technical/http-protocol.txt | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 2382384..d0955c2 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -22,15 +22,28 @@ URL Format
URLs for Git repositories accessed by HTTP use the standard HTTP
URL syntax documented by RFC 1738, so they are of the form:
- http://host:port/path
+ http://host:port/path?searchpart
Within this documentation the placeholder $GIT_URL will stand for
the http:// repository URL entered by the end-user.
-Both the smart and dumb HTTP protocols used by Git operate
+Servers SHOULD handle all requests to locations matching $GIT_URL, as
+both the smart and dumb HTTP protocols used by Git operate
by appending additional path components onto the end of the user
supplied $GIT_URL string.
+An example of a dumb client requesting for a loose object:
+
+ $GIT_URL: http://example.com:8080/git/repo.git
+ URL request:
http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355
+
+An example of a smart request to a catch-all gateway (notice how the
+'service' parameter is passed with '', since a '?' was detected in
+$GIT_URL):
+
+ $GIT_URL: http://example.com/daemon.cgi?svc=gitq=
+ URL request:
http://example.com/daemon.cgi?svc=gitq=/info/refsservice=git-receive-pack
+
Clients MUST strip a trailing '/', if present, from the user supplied
$GIT_URL string to prevent empty path tokens ('//') from appearing
in any URL sent to a server. Compatible clients MUST expand
@@ -186,6 +199,11 @@ The request MUST contain exactly one query parameter,
name the client wishes to contact to complete the operation.
The request MUST NOT contain additional query parameters.
+TODO: exactly one query parameter may be too strict; see the catch-all
+gateway $GIT_URL for an example where more than one parameter is passed.
+In fact, the http client implementation in Git can handle similar
+$GIT_URLs, and thus may pass more than parameter to the server.
+
C: GET $GIT_URL/info/refs?service=git-upload-pack HTTP/1.0
dumb server reply:
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
breakage in revision traversal with pathspec
I am grumpy X-. It appears that we introduced a large breakage during 1.8.4 cycle to the revision traversal machinery and made pathspec-limited git log pretty much useless. This command $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl reports that a merge 766f0f8ef7 (which did not touch the specified path at all) touches it. Bisecting points at d0af663e (revision.c: Make --full-history consider more merges, 2013-05-16). -- To unsubscribe from this list: send the line 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 11/14] be clearer in place of 'remote repository' phrase
Based on: From: Junio C Hamano gits...@pobox.com Message-ID: 7vskdss3ei@alter.siamese.dyndns.org +Smart Service git-upload-pack +-- +This service reads from the remote repository. The wording remote repository felt confusing. I know it is from the repository served by the server, but if it were named without upload-pack, I might have mistaken that you are allowing to proxy a request to access a third-party repository by this server. The same comment applies to the git-receive-pack service. Signed-off-by: Tay Ray Chuan rcta...@gmail.com --- Documentation/technical/http-protocol.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index dbfff36..4bb1614 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -279,7 +279,7 @@ declarations behind a NUL on the first ref. Smart Service git-upload-pack -- -This service reads from the remote repository. +This service reads from the repository pointed to by $GIT_URL. Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-upload-pack'. @@ -440,7 +440,7 @@ TODO: Document parsing response Smart Service git-receive-pack -- -This service modifies the remote repository. +This service modifies the repository pointed to by $GIT_URL. Clients MUST first perform ref discovery with '$GIT_URL/info/refs?service=git-receive-pack'. -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/14] fix example request/responses
Add LF for responses.
For smart interactions, add pkt-line lengths and the flush-pkt () line.
Drop the SP that followed NUL before capability list.
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
---
Documentation/technical/http-protocol.txt | 35 ---
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 5141c6a..dbfff36 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -157,10 +157,10 @@ without any search/query parameters. E.g.
S: 200 OK
S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\n
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
The Content-Type of the returned info/refs entity SHOULD be
text/plain; charset=utf-8, but MAY be any content type.
@@ -208,21 +208,22 @@ $GIT_URLs, and thus may pass more than parameter to the
server.
dumb server reply:
S: 200 OK
S:
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\n
+ S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
smart server reply:
S: 200 OK
S: Content-Type: application/x-git-upload-pack-advertisement
S: Cache-Control: no-cache
S:
- S: # service=git-upload-pack
- S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint\0 multi_ack
- S: d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master
- S: 2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0
- S: a3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}
+ S: 001e# service=git-upload-pack\n
+ S: 004895dcfa3633004da0049d3d0fa03f80589cbcaf31
refs/heads/maint\0multi_ack\n
+ S: 0042d049f6c27a2244e12041955e262a404c7faba355 refs/heads/master\n
+ S: 003c2cb58b79488a98d2721cea644875a8dd0026b115 refs/tags/v1.0\n
+ S: 003fa3c2e2402b99163d1d59756e5f207ae21cccba4c refs/tags/v1.0^{}\n
+ S:
Dumb Server Response
@@ -286,8 +287,8 @@ Clients MUST first perform ref discovery with
C: POST $GIT_URL/git-upload-pack HTTP/1.0
C: Content-Type: application/x-git-upload-pack-request
C:
- C: want 0a53e9ddeaddad63ad106860237bbf53411d11a7
- C: have 441b40d833fdfa93eb2908e52742248faf0ee993
+ C: 0032want 0a53e9ddeaddad63ad106860237bbf53411d11a7\n
+ C: 0032have 441b40d833fdfa93eb2908e52742248faf0ee993\n
C:
S: 200 OK
@@ -383,7 +384,7 @@ The computation to select the minimal pack proceeds as
follows
emptied C_PENDING it SHOULD include a done command to let
the server know it won't proceed:
- C: 0009done
+ C: 0009done\n
(s) Parse the git-upload-pack request:
@@ -447,7 +448,7 @@ Clients MUST first perform ref discovery with
C: POST $GIT_URL/git-receive-pack HTTP/1.0
C: Content-Type: application/x-git-receive-pack-request
C:
- C: 0a53e9ddeaddad63ad106860237bbf53411d11a7
441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0 report-status
+ C: 0a53e9ddeaddad63ad106860237bbf53411d11a7
441b40d833fdfa93eb2908e52742248faf0ee993 refs/heads/maint\0report-status
C:
C: PACK
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line 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 14/14] mention effect of allow-tip-sha1-in-want capability on git-upload-pack
From: Nguyễn Thái Ngọc Duy pclo...@gmail.com Signed-off-by: Tay Ray Chuan rcta...@gmail.com Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com -- Subject crafted by Ray Chuan, Nguyễn's s-o-b lifted from 1377092713-25434-1-git-send-email-pclo...@gmail.com. --- Documentation/technical/http-protocol.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index 3098aa4..acc68ac 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -304,7 +304,8 @@ Servers SHOULD support all capabilities defined here. Clients MUST send at least one 'want' command in the request body. Clients MUST NOT reference an id in a 'want' command which did not -appear in the response obtained through ref discovery. +appear in the response obtained through ref discovery unless the +server advertises capability allow-tip-sha1-in-want. compute_request = want_list have_list -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/14] capitalize key words according to RFC 2119
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
---
Documentation/technical/http-protocol.txt | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 70a1648..55753bb 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -11,6 +11,10 @@ protocol URLs to smart URLs. This permits all users to have
the
same published URL, and the peers automatically select the most
efficient transport available to them.
+The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL
+NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and
+OPTIONAL in this document are to be interpreted as described in
+RFC 2119.
URL Format
--
@@ -29,7 +33,7 @@ supplied $GIT_URL string.
Clients MUST strip a trailing '/', if present, from the user supplied
$GIT_URL string to prevent empty path tokens ('//') from appearing
-in any URL sent to a server. Compatible clients must expand
+in any URL sent to a server. Compatible clients MUST expand
'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.
@@ -66,7 +70,7 @@ Session State
-
The Git over HTTP protocol (much like HTTP itself) is stateless
-from the perspective of the HTTP server side. All state must be
+from the perspective of the HTTP server side. All state MUST be
retained and managed by the client process. This permits simple
round-robin load-balancing on the server side, without needing to
worry about state management.
@@ -158,7 +162,7 @@ references by making a request for the special info/refs
file of
the repository.
Dumb HTTP clients MUST NOT include search/query parameters when
-fetching the info/refs file. (That is, '?' must not appear in the
+fetching the info/refs file. (That is, '?' MUST NOT appear in the
requested URL.)
C: GET $GIT_URL/info/refs HTTP/1.0
@@ -390,7 +394,7 @@ The computation to select the minimal pack proceeds as
follows
(c) Start a queue, C_PENDING, ordered by commit time (popping newest
first). Add all client refs. When a commit is popped from
- the queue its parents should be automatically inserted back.
+ the queue its parents SHOULD be automatically inserted back.
Commits MUST only enter the queue once.
one compute step:
@@ -431,7 +435,7 @@ The computation to select the minimal pack proceeds as
follows
If the client has sent 256 HAVE commits and has not yet
received one of those back from S_COMMON, or the client has
- emptied C_PENDING it should include a done command to let
+ emptied C_PENDING it SHOULD include a done command to let
the server know it won't proceed:
C: 0009done
@@ -470,7 +474,7 @@ TODO: Document the pack based response
The returned stream is the side-band-64k protocol supported
by the git-upload-pack service, and the pack is embedded into
- stream 1. Progress messages from the server side may appear
+ stream 1. Progress messages from the server side MAY appear
in stream 2.
Here a closed set of objects is defined to have at least
@@ -538,5 +542,6 @@ References
--
link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators
(URL)]
+link:http://www.ietf.org/rfc/rfc2119.txt[RFC 2119: Key words for use in RFCs
to Indicate Requirement Levels]
link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol
-- HTTP/1.1]
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
Am 10.09.2013 15:14, schrieb Tvangeste: After bisecting this problem I ended up with the mentioned commit that completely breaks git-svn for me on Windows (mingw/msys version). == # git svn rebase warning: unable to access '': Invalid argument warning: unable to access '': Invalid argument fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': Invalid argument fatal: index file open failed: Invalid argument Cannot rebase: You have unstaged changes. Please commit or stash them. rebase refs/remotes/trunk: command returned error: 1 == Can you please run the command with GIT_TRACE=2? -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Michael Cronenworth m...@cchtml.com writes:
On git 1.8.1.x (Fedora 18) I was able to use the git-cvsserver to checkout
code
to package into a tarball. Script files that were in git with 755 masks were
checked-out with the same mask. After upgrading the git repository machine to
Fedora 19 (1.8.3.1) the behaviour has changed. When I checkout the same script
files their mask is now 644. The mask has not changed in git.
Matthew, I do not know if you are still using the git-cvsserver, but
it seems that the only substantial change to that subsystem between
the 1.8.1.x and 1.8.3.x is your update.
Especially 2c3af7e7 (cvsserver: factor out git-log parsing logic,
2012-10-13) looks interesting. It has a hunk like this:
-my $git_perms = ;
-$git_perms .= r if ( $mode 4 );
-$git_perms .= w if ( $mode 2 );
-$git_perms .= x if ( $mode 1 );
-$git_perms = rw if ( $git_perms eq );
+my $dbMode = convertToDbMode($mode);
with the definition of convertToDbMode being:
+sub convertToDbMode
+{
+my $mode = shift;
+...
+$mode=~/^\d\d(\d)\d{3}$/;
+my $userBits=$1;
+
+my $dbMode = ;
+$dbMode .= r if ( $userBits 4 );
+$dbMode .= w if ( $userBits 2 );
+$dbMode .= x if ( $userBits 1 );
+$dbMode = rw if ( $dbMode eq );
+
+return $dbMode;
The $mode in the caller comes from diff-tree output (the post-change
side of the mode string, like 100755).
Picking the third digit from the left (i.e. 10'0'755), instead of
the tail digit (i.e. 10075'5'), looks strange.
Side note: now I look at it, the original does not make much sense
for that matter. 100755 4 is different from oct(100755) 4.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/14] document edits to original http protocol documentation
This patch series are the changes based on the discussion on Shawn's
original text [1]. Some of them are minor, while some may potentially
change behaviour; see below for a classification of the changes.
Hopefully they can be examined by the git contributors here.
An earlier iteration of this patch series [2], including additional
changes by Nguyen [3], had been merged in 36d8020 (Merge branch
'sp/doc-smart-http', Aug 30). Since that iteration, the changes have
been corrected and consolidated. Effort has also been made to provide
the context for the changes; hopefully it helps with the review.
[1] http://mid.gmane.org/1255065768-10428-2-git-send-email-spea...@spearce.org
[2]
https://github.com/rctay/git/blob/rc/http-doc/v1/p/Documentation/technical/http-protocol.txt
[3] http://mid.gmane.org/1377092713-25434-1-git-send-email-pclo...@gmail.com
(For convenience, a diff against 36d8020 is included at the end of this
message; it is in word-diff form, hopefully for better clarity of the
changes.)
Given that an earlier iteration had already been merged, perhaps that
could be replaced with merge -Xtheirs (just throwing ideas, my git-fu is
not that strong). This would make the changes on the original RFC
available eg. via git-blame, which may be helpful for implementations
made based on the original RFC, especially since these early
implementations may now be in violation of the recently-included copy of
the spec.
The patches have been grouped based on their safeness (with regard to
potentially changing the protocol spec), with a bias towards caution, as
follows:
Trivial changes (eg formatting, style):
[PATCH 01/14] Document the HTTP transport protocol
[PATCH 02/14] normalize indentation with protcol-common.txt
[PATCH 03/14] capitalize key words according to RFC 2119
[PATCH 04/14] normalize rules with RFC 5234
[PATCH 05/14] drop rules, etc. common to the pack protocol
[PATCH 10/14] fix example request/responses
[PATCH 13/14] shift dumb server response details
Rewords based on discussions that have been settled, or seem safe:
[PATCH 07/14] weaken specification over cookies for authentication
[PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients
[PATCH 11/14] be clearer in place of 'remote repository' phrase
Potentially behaviour-changes, may need of discussion:
[PATCH 06/14] reword behaviour on missing repository or objects
[PATCH 08/14] mention different variations around $GIT_URL
[PATCH 12/14] reduce confusion over smart server response behaviour
[PATCH 14/14] mention effect of allow-tip-sha1-in-want capability
Full, ordered listing:
[PATCH 01/14] Document the HTTP transport protocol
[PATCH 02/14] normalize indentation with protcol-common.txt
[PATCH 03/14] capitalize key words according to RFC 2119
[PATCH 04/14] normalize rules with RFC 5234
[PATCH 05/14] drop rules, etc. common to the pack protocol
[PATCH 06/14] reword behaviour on missing repository or objects
[PATCH 07/14] weaken specification over cookies for authentication
[PATCH 08/14] mention different variations around $GIT_URL
[PATCH 09/14] reduce ambiguity over '?' in $GIT_URL for dumb clients
[PATCH 10/14] fix example request/responses
[PATCH 11/14] be clearer in place of 'remote repository' phrase
[PATCH 12/14] reduce confusion over smart server response behaviour
[PATCH 13/14] shift dumb server response details
[PATCH 14/14] mention effect of allow-tip-sha1-in-want capability
This patch series is queued at:
https://github.com/rctay/git/commits/rc/http-doc/v2/q
--
1.8.4.rc4.527.g303b16c
output of
$ git diff -b --word-diff 36d8020 -- Documentation/technical/http-protocol.txt
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index a1173ee..acc68ac 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -11,6 +11,10 @@ protocol URLs to smart URLs. This permits all users to have
the
same published URL, and the peers automatically select the most
efficient transport available to them.
{+The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL+}
{+NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and+}
{+OPTIONAL in this document are to be interpreted as described in+}
{+RFC 2119.+}
URL Format
--
@@ -33,16 +37,13 @@ An example of a dumb client requesting for a loose object:
$GIT_URL: http://example.com:8080/git/repo.git
URL request:
http://example.com:8080/git/repo.git/objects/d0/49f6c27a2244e12041955e262a404c7faba355
An example of a smart request to a catch-all [-gateway:-]{+gateway (notice how
the+}
{+'service' parameter is passed with '', since a '?' was detected in+}
{+$GIT_URL):+}
$GIT_URL: http://example.com/daemon.cgi?svc=gitq=
URL request:
http://example.com/daemon.cgi?svc=gitq=/info/refsservice=git-receive-pack
[-An example of a request to a submodule:-]
[- $GIT_URL: http://example.com/git/repo.git/path/submodule.git-]
[-
[PATCH 06/14] reword behaviour on missing repository or objects
From: Shawn O. Pearce spea...@spearce.org Signed-off-by: Tay Ray Chuan rcta...@gmail.com -- To Shawn: sign-off-by needed. Based on: From: Shawn O. Pearce spea...@spearce.org Message-ID: 20091016142135.gr10...@spearce.org Mike Hommey m...@glandium.org wrote: On Thu, Oct 15, 2009 at 10:59:25PM -0700, H. Peter Anvin wrote: On 10/10/2009 03:12 AM, Antti-Juhani Kaijanaho wrote: On 2009-10-09, Junio C Hamano gits...@pobox.com wrote: +If there is no repository at $GIT_URL, the server MUST respond with +the '404 Not Found' HTTP status code. We may also want to add If there is no object at $GIT_URL/some/path, the server MUST respond with the '404 Not Found' HTTP status code. to help dumb clients. In both cases - is it really necessary to forbid the use of 410 (Gone)? My original text got taken a bit out of context here. I guess MUST was too strong of a word. I more ment something like: If there is no repository at $GIT_URL, the server MUST NOT respond with '200 OK' and a valid info/refs response. A server SHOULD respond with '404 Not Found', '410 Gone', or any other suitable HTTP status code which does not imply the resource exists as requested. In addition, address behaviour on missing objects, as suggested by Junio. His text (see quote in above excerpt) was not used, in favour of a more general treatment (locations matching $GIT_URL, not just objects). --- Documentation/technical/http-protocol.txt | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt index a8d28ba..412b898 100644 --- a/Documentation/technical/http-protocol.txt +++ b/Documentation/technical/http-protocol.txt @@ -91,8 +91,12 @@ Except where noted, all standard HTTP behavior SHOULD be assumed by both client and server. This includes (but is not necessarily limited to): -If there is no repository at $GIT_URL, the server MUST respond with -the '404 Not Found' HTTP status code. +If there is no repository at $GIT_URL, the server MUST NOT respond with +'200 OK' and a valid info/refs response. Also, if the resource pointed +to by a location matching $GIT_URL does not exist, the server MUST NOT +respond with '200 OK'. A server SHOULD respond with +'404 Not Found', '410 Gone', or any other suitable HTTP status code +which does not imply the resource exists as requested. If there is a repository at $GIT_URL, but access is not currently permitted, the server MUST respond with the '403 Forbidden' HTTP -- 1.8.4.rc4.527.g303b16c -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
Tvangeste i.4m.l...@yandex.ru writes: Hi, After bisecting this problem I ended up with the mentioned commit that completely breaks git-svn for me on Windows (mingw/msys version). == # git svn rebase warning: unable to access '': Invalid argument warning: unable to access '': Invalid argument fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': Invalid argument fatal: index file open failed: Invalid argument Cannot rebase: You have unstaged changes. Please commit or stash them. rebase refs/remotes/trunk: command returned error: 1 == Please note that I use the official git repository as-is, this one (no additional patches): git://git.kernel.org/pub/scm/git/git.git e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit commit e02ca72f70ed8f0268a81f72cb3230c72e538e77 Author: Jiang Xin Date: Tue Jun 25 23:53:43 2013 +0800 path.c: refactor relative_path(), not only strip prefix Thanks, --Tvangeste The suspect commit and symptom look consistent. You started from a directory whose absolute path is w:/work/... and the updated code mistakenly thoguht that something that begins with w (not '/') is not an absolute, so added a series of ../ to make it relative, or something silly like that. Jiang? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/14] normalize rules with RFC 5234
Drop LF, SP which are defined in RFC 5234.
Replace HT with HTAB (also defined in the RFC).
Use '/' instead of '|', as the RFC does.
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
---
Documentation/technical/http-protocol.txt | 26 +-
1 file changed, 9 insertions(+), 17 deletions(-)
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
index 55753bb..ff91bb0 100644
--- a/Documentation/technical/http-protocol.txt
+++ b/Documentation/technical/http-protocol.txt
@@ -192,16 +192,13 @@ according to the C locale ordering. The file SHOULD NOT
include
the default ref named 'HEAD'.
info_refs= *( ref_record )
- ref_record = any_ref | peeled_ref
+ ref_record = any_ref / peeled_ref
- any_ref = id HT name LF
- peeled_ref = id HT name LF
- id HT name ^{} LF
+ any_ref = id HTAB name LF
+ peeled_ref = id HTAB name LF
+ id HTAB name ^{} LF
id = 40*HEX
- HEX = 0..9 | a..f
- LF = US-ASCII LF, linefeed (10)
- HT = US-ASCII HT, horizontal-tab (9)
Smart Clients
~
@@ -288,7 +285,7 @@ declarations behind a NUL on the first ref.
smart_reply = PKT-LINE(# service=$servicename LF)
ref_list
- ref_list = empty_list | non_empty_list
+ ref_list = empty_list / non_empty_list
empty_list = PKT-LINE(id SP capabilities^{} NUL cap_list LF)
@@ -296,18 +293,13 @@ declarations behind a NUL on the first ref.
*ref_record
cap_list = *(SP capability) SP
- ref_record = any_ref | peeled_ref
+ ref_record = any_ref / peeled_ref
any_ref = PKT-LINE(id SP name LF)
peeled_ref = PKT-LINE(id SP name LF)
PKT-LINE(id SP name ^{} LF
id = 40*HEX
- HEX = 0..9 | a..f
- NL = US-ASCII NUL, null (0)
- LF = US-ASCII LF, linefeed (10)
- SP = US-ASCII SP, horizontal-tab (9)
-
Smart Service git-upload-pack
--
@@ -343,7 +335,7 @@ appear in the response obtained through ref discovery.
compute_request = want_list
have_list
request_end
- request_end = | done
+ request_end = / done
want_list= PKT-LINE(want NUL cap_list LF)
*(want_pkt)
@@ -353,7 +345,7 @@ appear in the response obtained through ref discovery.
have_list= *PKT-LINE(have SP id LF)
- command = create | delete | update
+ command = create / delete / update
create = 40*0 SP new_id SP name
delete = old_id SP 40*0 SP name
update = old_id SP new_id SP name
@@ -530,7 +522,7 @@ the id obtained through ref discovery as old_id.
command_pkt = PKT-LINE(command LF)
cap_list = *(SP capability) SP
- command = create | delete | update
+ command = create / delete / update
create = 40*0 SP new_id SP name
delete = old_id SP 40*0 SP name
update = old_id SP new_id SP name
--
1.8.4.rc4.527.g303b16c
--
To unsubscribe from this list: send the line 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 v6 0/8] Multiple simultaneously locked ref updates
On 09/10/2013 12:30 PM, Junio C Hamano wrote: Thanks. I am not sure if I should rewind and rebuild the series with these patches, though. This is a new feature and does not have to be merged to 'maint', so rebasing is perfectly fine, but it is not strictly necessary, either. I just thought I'd help out with the conflict resolution. If you're happy with resolving the conflicts in v5 then there is no reason to use v6. Thanks, -Brad -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/14] Document the HTTP transport protocol
From: Shawn O. Pearce spea...@spearce.org
Signed-off-by: Shawn O. Pearce spea...@spearce.org
Signed-off-by: Tay Ray Chuan rcta...@gmail.com
--
This is the original
1255065768-10428-2-git-send-email-spea...@spearce.org
with some minor changes, as follows:
- fix mis-spelling 'paramterized'
- fix mis-spelling 'mangement' (spotted by Junio)
- fix missing ABNF reference for smart replies (spotted by Sverre, Junio)
---
Documentation/technical/http-protocol.txt | 542 ++
1 file changed, 542 insertions(+)
create mode 100644 Documentation/technical/http-protocol.txt
diff --git a/Documentation/technical/http-protocol.txt
b/Documentation/technical/http-protocol.txt
new file mode 100644
index 000..0a2a53d
--- /dev/null
+++ b/Documentation/technical/http-protocol.txt
@@ -0,0 +1,542 @@
+HTTP transfer protocols
+===
+
+Git supports two HTTP based transfer protocols. A dumb protocol
+which requires only a standard HTTP server on the server end of the
+connection, and a smart protocol which requires a Git aware CGI
+(or server module). This document describes both protocols.
+
+As a design feature smart clients can automatically upgrade dumb
+protocol URLs to smart URLs. This permits all users to have the
+same published URL, and the peers automatically select the most
+efficient transport available to them.
+
+
+URL Format
+--
+
+URLs for Git repositories accessed by HTTP use the standard HTTP
+URL syntax documented by RFC 1738, so they are of the form:
+
+ http://host:port/path
+
+Within this documentation the placeholder $GIT_URL will stand for
+the http:// repository URL entered by the end-user.
+
+Both the smart and dumb HTTP protocols used by Git operate
+by appending additional path components onto the end of the user
+supplied $GIT_URL string.
+
+Clients MUST strip a trailing '/', if present, from the user supplied
+$GIT_URL string to prevent empty path tokens ('//') from appearing
+in any URL sent to a server. Compatible clients must expand
+'$GIT_URL/info/refs' as 'foo/info/refs' and not 'foo//info/refs'.
+
+
+Authentication
+--
+
+Standard HTTP authentication is used if authentication is required
+to access a repository, and MAY be configured and enforced by the
+HTTP server software.
+
+Because Git repositories are accessed by standard path components
+server administrators MAY use directory based permissions within
+their HTTP server to control repository access.
+
+Clients SHOULD support Basic authentication as described by RFC 2616.
+Servers SHOULD support Basic authentication by relying upon the
+HTTP server placed in front of the Git server software.
+
+Servers MUST NOT require HTTP cookies for the purposes of
+authentication or access control.
+
+Clients and servers MAY support other common forms of HTTP based
+authentication, such as Digest authentication.
+
+
+SSL
+---
+
+Clients and servers SHOULD support SSL, particularly to protect
+passwords when relying on Basic HTTP authentication.
+
+
+Session State
+-
+
+The Git over HTTP protocol (much like HTTP itself) is stateless
+from the perspective of the HTTP server side. All state must be
+retained and managed by the client process. This permits simple
+round-robin load-balancing on the server side, without needing to
+worry about state management.
+
+Clients MUST NOT require state management on the server side in
+order to function correctly.
+
+Servers MUST NOT require HTTP cookies in order to function correctly.
+Clients MAY store and forward HTTP cookies during request processing
+as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any
+cookies sent by a client.
+
+
+pkt-line Format
+---
+
+Much (but not all) of the payload is described around pkt-lines.
+
+A pkt-line is a variable length binary string. The first four bytes
+of the line indicates the total length of the line, in hexadecimal.
+The total length includes the 4 bytes used to denote the length.
+A line SHOULD BE terminated by an LF, which if present MUST be
+included in the total length.
+
+A pkt-line MAY contain binary data, so implementors MUST ensure all
+pkt-line parsing/formatting routines are 8-bit clean. The maximum
+length of a pkt-line's data is 65532 bytes (65536 - 4).
+
+Examples (as C-style strings):
+
+ pkt-line actual value
+ -
+ 0006a\n a\n
+ 0005a a
+ 000bfoobar\nfoobar\n
+ 0004
+
+A pkt-line with a length of 0 () is a special case and MUST
+be treated as a message break or terminator in the payload.
+
+
+General Request Processing
+--
+
+Except where noted, all standard HTTP behavior SHOULD be assumed
+by both client and server. This includes (but is not necessarily
+limited to):
+
+If there is no repository at $GIT_URL, the server MUST respond with
+the '404 Not Found' HTTP status code.
+
+If there is a repository at $GIT_URL, but access
Re: Re-Transmission of blobs?
Josef Wolf j...@raven.inka.de writes: as we all know, files are identified by their SHA. Thus I had the impression that when transfering files, git would know by the SHA whether a given file is already available in the destination repository and the transfer would be of no use. That is unfortunately not how things work. It is not like the receiving end sends the names of all objects it has, and the sending end excludes these objects from what it is going to send. Consider this simple history with only a handful of commits (as usual, time flows from left to right): E / A---B---C---D where D is at the tip of the sending side, E is at the tip of the receiving side. The exchange goes roughly like this: (receiving side): what do you have? (sending side): my tip is at D. (receiving side): D? I've never heard of it --- please give it to me. I have E. (sending side): E? I don't know about it; must be something you created since you forked from me. Tell me about its ancestors. (receiving side): OK, I have C. (sending side): Oh, C I know about. You do not have to tell me anything more. A packfile to bring you up to date will follow. At this point, the sender knows that the receiver needs the commit D, and trees and blobs in D. It does also know it has the commit C and trees and blobs in C. It does the best thing it can do using these (and only these) information, namely, to send the commit D, and send trees and blobs in D that are not in the commit C. You may happen to have something in E that match what is in D but not in C. Because the sender does not know anything about E at all in the first place, that information cannot be used to reduce the transfer. The sender theoretically _could_ also exploit the fact that any receiver that has C must have B and A and all trees and blobs associated with these ancestor commits [*1*], but that information is not currently discovered nor used during the object transfer. There may happen to be a tree or a blob in A that matches a tree or a blob in D. But because the common ancestor discovery exchange above stops at C, the sender does not bother enumerating all the objects that are in the ancestor commits of C when figuring out what objects to send to ensure that the receiving end has all the objects necessary to complete D. If you modified a blob at B (or C) and then resurrected the old version of the blob at D, it is likely that the blob is going to be sent again when the receiving end asks for D. There are some work being done to optimize this further using various techniques, but they are not ready yet. [Footnote] *1* only down to the shallow boundary, if the receiving end is a shallow clone. -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
10.09.2013, 18:13, Johannes Schindelin johannes.schinde...@gmx.de: Have you tried with Git for Windows yet? What's Git for Windows? If you mean msysgit, then I say no, because the latest msysgit version is from June 02, and the change under discussion was made later on, on June 25th. So, this regression is not in msysgit release (yet). Thanks, --Tvangeste -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
10.09.2013, 18:53, Johannes Sixt j...@kdbg.org: Can you please run the command with GIT_TRACE=2? Sure: # git --version trace: built-in: git 'version' git version 1.8.4.242.gbb80ee0 # git svn rebase -l trace: exec: 'git-svn' 'rebase' '-l' trace: run_command: 'git-svn' 'rebase' '-l' trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--show-cdup' trace: built-in: git 'config' '--bool' '--get' 'svn.fetchall' trace: built-in: git 'config' '--bool' '--get' 'svn.noauthcache' trace: built-in: git 'config' '--bool' '--get' 'svn.nocheckout' trace: built-in: git 'config' '--get' 'svn.authorsprog' trace: built-in: git 'config' '--bool' '--get' 'svn.dryrun' trace: built-in: git 'config' '--bool' '--get' 'svn.preservemerges' trace: built-in: git 'config' '--bool' '--get' 'svn.followparent' trace: built-in: git 'config' '--bool' '--get' 'svn.useSvmProps' trace: built-in: git 'config' '--get' 'svn.authorsfile' trace: built-in: git 'config' '--get' 'svn.username' trace: built-in: git 'config' '--get' 'svn.repackflags' trace: built-in: git 'config' '--bool' '--get' 'svn.localtime' trace: built-in: git 'config' '--int' '--get' 'svn.repack' trace: built-in: git 'config' '--get' 'svn.ignorepaths' trace: built-in: git 'config' '--bool' '--get' 'svn.verbose' trace: built-in: git 'config' '--bool' '--get' 'svn.quiet' trace: built-in: git 'config' '--int' '--get' 'svn.logwindowsize' trace: built-in: git 'config' '--get' 'svn.ignorerefs' trace: built-in: git 'config' '--get' 'svn.configdir' trace: built-in: git 'config' '--bool' '--get' 'svn.merge' trace: built-in: git 'config' '--bool' '--get' 'svn.addauthorfrom' trace: built-in: git 'config' '--bool' '--get' 'svn.useSvnsyncProps' trace: built-in: git 'config' '--bool' '--get' 'svn.noMetadata' trace: built-in: git 'config' '--bool' '--get' 'svn.local' trace: built-in: git 'config' '--get' 'svn.strategy' trace: built-in: git 'config' '--get' 'svn.includepaths' trace: built-in: git 'config' '--bool' '--get' 'svn.uselogauthor' trace: built-in: git 'rev-parse' '--symbolic' '--all' trace: built-in: git 'config' '-l' trace: built-in: git 'config' '-l' trace: built-in: git 'update-index' '--refresh' trace: built-in: git 'rev-list' '--first-parent' '--pretty=medium' 'HEAD' '--' trace: built-in: git 'config' '--bool' 'svn.useSvmProps' trace: built-in: git 'config' '-l' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'for-each-ref' '--format=%(refname)' 'refs/' trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot' trace: built-in: git 'config' '--get' 'svn-remote.svn.url' trace: built-in: git 'config' '--get' 'svn-remote.svn.pushurl' trace: built-in: git 'config' '--get' 'svn-remote.svn.uuid' trace: built-in: git 'rev-list' '--pretty=raw' '--reverse' 'cdc459d7cedcec6bb26812e24661c7318f031be4..refs/remotes/trunk' '--' trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteRoot' trace: built-in: git 'config' '--get' 'svn-remote.svn.rewriteUUID' trace: built-in: git 'diff-index' 'HEAD' '--' trace: exec: 'git-rebase' 'refs/remotes/trunk' trace: run_command: 'git-rebase' 'refs/remotes/trunk' trace: built-in: git 'rev-parse' '--parseopt' '--' 'refs/remotes/trunk' trace: built-in: git 'rev-parse' '--git-dir' trace: built-in: git 'rev-parse' '--is-bare-repository' trace: built-in: git 'rev-parse' '--show-toplevel' trace: built-in: git 'config' '--bool' 'rebase.stat' trace: built-in: git 'config' '--bool' 'rebase.autostash' trace: built-in: git 'config' '--bool' 'rebase.autosquash' trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0' trace: built-in: git 'rev-parse' '--verify' 'refs/remotes/trunk^0' trace: built-in: git 'symbolic-ref' '-q' 'HEAD' trace: built-in: git 'rev-parse' '--verify' 'HEAD' trace: built-in: git 'rev-parse' '--verify' 'HEAD' trace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh' fatal: unable to access '../../../../w:/work/xxx/xxx-xxx-OSS.git.new/.git/config': Invalid argument trace: built-in: git 'diff-files' '--quiet' '--ignore-submodules' fatal: index file open failed: Invalid argument Cannot rebase: You have unstaged changes. trace: built-in: git 'diff-index' '--cached' '--quiet' '--ignore-submodules' 'HEAD' '--' Please commit or stash them. rebase refs/remotes/trunk: command returned error: 1 Thanks, --Tvangeste -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
Hi Tvangeste, On Tue, 10 Sep 2013, Tvangeste wrote: 10.09.2013, 18:13, Johannes Schindelin johannes.schinde...@gmx.de: Have you tried with Git for Windows yet? What's Git for Windows? If you mean msysgit, Actually, they are two different things: Git for Windows is what the name says, and it comes with an installer. msysGit is the development environment to *build* Git for Windows. then I say no, because the latest msysgit version is from June 02, and the change under discussion was made later on, on June 25th. So, this regression is not in msysgit release (yet). Given the explanation what msysGit is, you might suspect that I'd like you to try to fix this in the msysGit context: After installing https://code.google.com/p/msysgit/downloads/list?q=net+installer you will have a full build environment, including the build of our latest master. You can then cd /git/ and git checkout pt/tentative-1.8.4 make install to make sure that the version we are very close to releasing as the new Git for Windows version does not break your workflow. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Disabling status hints in COMMIT_EDITMSG
Matthieu Moy wrote: I just noticed that the template COMMIT_EDITMSG was containing status hints, and that they were not particularty helpfull _during_ a commit. I think it would be sensible to ignore advice.statusHints and disable hints unconditionally when writting to COMMIT_EDITMSG. Any objection? No objection from me. It sounds like a good change. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Sep 2013, #02; Mon, 9)
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: * mm/rebase-continue-freebsd-WB (2013-09-09) 1 commit - rebase: fix run_specific_rebase's use of return on FreeBSD Work around a bug in FreeBSD shell that caused a regression to git rebase in v1.8.4. It would be lovely to hear from FreeBSD folks a success report to make sure we didn't miss any other use of a bare return from dot-sourced script. Will merge to 'next'. BTW, this is a candidate for maint too I guess. Yes, thanks for reminding me. I was planning to change that label to Will merge to 'master' and later to 'maint' when it hits 'next'. -- To unsubscribe from this list: send the line 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 1/2] reset: handle submodule with trailing slash
When using tab-completion, a directory path will often end with a trailing slash which currently confuses git rm when dealing with submodules. Now that we have parse_pathspec we can easily handle this by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag. Signed-off-by: John Keeping j...@keeping.me.uk --- builtin/reset.c| 5 + t/t7400-submodule-basic.sh | 6 -- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/builtin/reset.c b/builtin/reset.c index 5e4c551..9efac0f 100644 --- a/builtin/reset.c +++ b/builtin/reset.c @@ -220,8 +220,13 @@ static void parse_args(struct pathspec *pathspec, } } *rev_ret = rev; + + if (read_cache() 0) + die(_(index file corrupt)); + parse_pathspec(pathspec, 0, PATHSPEC_PREFER_FULL | + PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP | (patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0), prefix, argv); } diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh index 4192fe0..c268d3c 100755 --- a/t/t7400-submodule-basic.sh +++ b/t/t7400-submodule-basic.sh @@ -481,7 +481,7 @@ test_expect_success 'do not add files from a submodule' ' ' -test_expect_success 'gracefully add submodule with a trailing slash' ' +test_expect_success 'gracefully add/reset submodule with a trailing slash' ' git reset --hard git commit -m commit subproject init @@ -495,7 +495,9 @@ test_expect_success 'gracefully add submodule with a trailing slash' ' git add init/ test_must_fail git diff --exit-code --cached init test $commit = $(git ls-files --stage | - sed -n s/^16 \([^ ]*\).*/\1/p) + sed -n s/^16 \([^ ]*\).*/\1/p) + git reset init/ + git diff --exit-code --cached init ' -- 1.8.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] rm: re-use parse_pathspec's trailing-slash removal
Instead of re-implementing the remove trailing slashes loop in
builtin/rm.c just pass PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to
parse_pathspec.
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/rm.c | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/builtin/rm.c b/builtin/rm.c
index 9b59ab3..3a0e0ea 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -298,22 +298,10 @@ int cmd_rm(int argc, const char **argv, const char
*prefix)
if (read_cache() 0)
die(_(index file corrupt));
- /*
-* Drop trailing directory separators from directories so we'll find
-* submodules in the index.
-*/
- for (i = 0; i argc; i++) {
- size_t pathlen = strlen(argv[i]);
- if (pathlen is_dir_sep(argv[i][pathlen - 1])
- is_directory(argv[i])) {
- do {
- pathlen--;
- } while (pathlen is_dir_sep(argv[i][pathlen - 1]));
- argv[i] = xmemdupz(argv[i], pathlen);
- }
- }
-
- parse_pathspec(pathspec, 0, PATHSPEC_PREFER_CWD, prefix, argv);
+ parse_pathspec(pathspec, 0,
+ PATHSPEC_PREFER_CWD |
+ PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,
+ prefix, argv);
refresh_index(the_index, REFRESH_QUIET, pathspec, NULL, NULL);
seen = xcalloc(pathspec.nr, 1);
--
1.8.2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] reset: handle submodule with trailing slash
The first patch is the important one here, the second one I noticed while checking if any other commands fail to handle submodule paths with a trailing slash and is just a simplification. John Keeping (2): reset: handle submodule with trailing slash rm: re-use parse_pathspec's trailing-slash removal builtin/reset.c| 5 + builtin/rm.c | 20 t/t7400-submodule-basic.sh | 6 -- 3 files changed, 13 insertions(+), 18 deletions(-) -- 1.8.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Junio C Hamano gits...@pobox.com writes:
Michael Cronenworth m...@cchtml.com writes:
On git 1.8.1.x (Fedora 18) I was able to use the git-cvsserver to checkout
code
to package into a tarball. Script files that were in git with 755 masks were
checked-out with the same mask. After upgrading the git repository machine to
Fedora 19 (1.8.3.1) the behaviour has changed. When I checkout the same
script
files their mask is now 644. The mask has not changed in git.
Matthew, I do not know if you are still using the git-cvsserver, but
it seems that the only substantial change to that subsystem between
the 1.8.1.x and 1.8.3.x is your update.
Especially 2c3af7e7 (cvsserver: factor out git-log parsing logic,
2012-10-13) looks interesting. It has a hunk like this:
-my $git_perms = ;
-$git_perms .= r if ( $mode 4 );
-$git_perms .= w if ( $mode 2 );
-$git_perms .= x if ( $mode 1 );
-$git_perms = rw if ( $git_perms eq );
+my $dbMode = convertToDbMode($mode);
with the definition of convertToDbMode being:
+sub convertToDbMode
+{
+my $mode = shift;
+...
+$mode=~/^\d\d(\d)\d{3}$/;
+my $userBits=$1;
+
+my $dbMode = ;
+$dbMode .= r if ( $userBits 4 );
+$dbMode .= w if ( $userBits 2 );
+$dbMode .= x if ( $userBits 1 );
+$dbMode = rw if ( $dbMode eq );
+
+return $dbMode;
The $mode in the caller comes from diff-tree output (the post-change
side of the mode string, like 100755).
Picking the third digit from the left (i.e. 10'0'755), instead of
the tail digit (i.e. 10075'5'), looks strange.
Side note: now I look at it, the original does not make much sense
for that matter. 100755 4 is different from oct(100755) 4.
I stopped interacting with CVS quite a long time ago, so I do not
have any way of verifying, but the fix may be just the matter of
something like this.
I am not sure if we want to use the owner bit (i.e. 4th place)
instead of the other bit (i.e. the last place) like this patch does,
though. The old code in 1.8.1.x would have produced either r (for
100644) or wx (for 100755); I think that the result of applying
this patch would give us r (for 100644) or rx (for 100755).
-- 8 --
Subject: cvsserver: pick up the right mode bits
When determining the file mode from either ls-tree or diff-tree
output, we used to grab these octal mode string (typically 100644 or
100755) and then did
$git_perms .= r if ( $mode 4 );
$git_perms .= w if ( $mode 2 );
$git_perms .= x if ( $mode 1 );
which was already wrong, as (100644 4) is very different from
oct(100644) 4. An earlier refactoring 2c3af7e7 (cvsserver:
factor out git-log parsing logic, 2012-10-13) further changed it to
pick the third octal digit (10*0*644 or 10*0*755) from the left and
then do the above conversion, which does not make sense, either.
Let's use the last digit of the octal mode string to make sure we
get the executable and read bits right.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-cvsserver.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a0d796e..b1d7a4c 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -4167,7 +4167,7 @@ sub convertToDbMode
# this half-converted form, but it isn't currently worth the
# backwards compatibility headaches.
-$mode=~/^\d\d(\d)\d{3}$/;
+$mode=~/^\d{5}(\d)$/;
my $userBits=$1;
my $dbMode = ;
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] reset: handle submodule with trailing slash
On Tue, Sep 10, 2013 at 09:37:45PM +0200, Jens Lehmann wrote: Am 10.09.2013 21:13, schrieb John Keeping: When using tab-completion, a directory path will often end with a trailing slash which currently confuses git rm when dealing with I think you meant to say git reset in the line above. Apart from that I'm all for it. Yeah, you're right - I obviously got confused between the two patches :-(. I'll wait for more feedback before submitting a re-roll. submodules. Now that we have parse_pathspec we can easily handle this by simply adding the PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP flag. Signed-off-by: John Keeping j...@keeping.me.uk --- builtin/reset.c| 5 + t/t7400-submodule-basic.sh | 6 -- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/builtin/reset.c b/builtin/reset.c index 5e4c551..9efac0f 100644 --- a/builtin/reset.c +++ b/builtin/reset.c @@ -220,8 +220,13 @@ static void parse_args(struct pathspec *pathspec, } } *rev_ret = rev; + + if (read_cache() 0) + die(_(index file corrupt)); + parse_pathspec(pathspec, 0, PATHSPEC_PREFER_FULL | + PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP | (patch_mode ? PATHSPEC_PREFIX_ORIGIN : 0), prefix, argv); } diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh index 4192fe0..c268d3c 100755 --- a/t/t7400-submodule-basic.sh +++ b/t/t7400-submodule-basic.sh @@ -481,7 +481,7 @@ test_expect_success 'do not add files from a submodule' ' ' -test_expect_success 'gracefully add submodule with a trailing slash' ' +test_expect_success 'gracefully add/reset submodule with a trailing slash' ' git reset --hard git commit -m commit subproject init @@ -495,7 +495,9 @@ test_expect_success 'gracefully add submodule with a trailing slash' ' git add init/ test_must_fail git diff --exit-code --cached init test $commit = $(git ls-files --stage | - sed -n s/^16 \([^ ]*\).*/\1/p) + sed -n s/^16 \([^ ]*\).*/\1/p) + git reset init/ + git diff --exit-code --cached init ' -- To unsubscribe from this list: send the line 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: pack v4 trees with a canonical base
On Tue, 10 Sep 2013, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre n...@fluxnic.net wrote: An eventual optimization to index-pack when completing a pack would be to attempt the encoding of appended tree objects into the packv4 format using the existing dictionary table in the pack, and fall back to the canonical format if that table doesn't have all the necessary elements. Yeah, it's on the improvement todo list. The way pack-objects creates dictionaries right now, the tree dict should contain all elements the base trees need so fall back is only necessary when trees are have extra zeros in mode field. Careful. There may be trees in the wild that record 100775 or 100777 in the mode field for executable blobs, which also need to be special cased. All the file mode bits are always preserved. So this is not really a special case as far as the pack v4 encoding is concerned. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Tue, Sep 10, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote: string to that file before building, so in that sense, we do not *need* DEF_VER and version. But they have been there for a long time, and I do not think it gives us a good trade-off between risking regression and reducing the linecount to change it to remove one. Fair enough! -- Sebastian Schuberth -- To unsubscribe from this list: send the line 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 v6 0/8] Multiple simultaneously locked ref updates
Brad King brad.k...@kitware.com writes: On 09/10/2013 12:30 PM, Junio C Hamano wrote: Thanks. I am not sure if I should rewind and rebuild the series with these patches, though. This is a new feature and does not have to be merged to 'maint', so rebasing is perfectly fine, but it is not strictly necessary, either. I just thought I'd help out with the conflict resolution. Yeah, such an independent confirmation of the conflict resolution is very much appreciated. -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
10.09.2013, 20:02, Johannes Schindelin johannes.schinde...@gmx.de: Given the explanation what msysGit is, you might suspect that I'd like you to try to fix this in the msysGit context: After installing https://code.google.com/p/msysgit/downloads/list?q=net+installer No problem. Here's what I have so far: 1. Installed the latest msysgit from the URL you've provided. Tried the git that comes out of the box that comes with the installer (1.8.3.msysgit): 1a. On CMD: everything is fine. 1b. On msys shell: everything is fine. 2. Checked out the branch you've suggested to try (pt/tentative-1.8.4) and installed it. Tried the new version: 2a. On CMD: got the problem that is being discussed in this thread. 2b. On msys shell: everything is fine. So, in summary. That commit e02ca72, somewhere between 1.8.3 and 1.8.4 introduced the regression in git/git-svn on Windows, when executed in CMD. Thanks, --Tvangeste -- To unsubscribe from this list: send the line 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: pack v4 trees with a canonical base
Nicolas Pitre n...@fluxnic.net writes: very much appreciated to On Tue, 10 Sep 2013, Junio C Hamano wrote: Duy Nguyen pclo...@gmail.com writes: On Tue, Sep 10, 2013 at 2:25 AM, Nicolas Pitre n...@fluxnic.net wrote: An eventual optimization to index-pack when completing a pack would be to attempt the encoding of appended tree objects into the packv4 format using the existing dictionary table in the pack, and fall back to the canonical format if that table doesn't have all the necessary elements. Yeah, it's on the improvement todo list. The way pack-objects creates dictionaries right now, the tree dict should contain all elements the base trees need so fall back is only necessary when trees are have extra zeros in mode field. Careful. There may be trees in the wild that record 100775 or 100777 in the mode field for executable blobs, which also need to be special cased. All the file mode bits are always preserved. So this is not really a special case as far as the pack v4 encoding is concerned. Ahh. OK. It can theoretically be argued that you could further squeeze 13 bits out per tree entry because you would need only 5 possible values (100644, 100755 12, 4, and 16, all octal) for the modes, but we will never know what other modes we would want to use in the future, so not being over-tight and using 16-bit for this purpose is probably a good trade-off (squeezing 8 bits out per tree entry would make the shape of ident table entry and tree path entry different and may hurt reusing the code to parse these tables). -- To unsubscribe from this list: send the line 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: pack v4 trees with a canonical base
On Tue, 10 Sep 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: On Tue, 10 Sep 2013, Junio C Hamano wrote: There may be trees in the wild that record 100775 or 100777 in the mode field for executable blobs, which also need to be special cased. All the file mode bits are always preserved. So this is not really a special case as far as the pack v4 encoding is concerned. Ahh. OK. It can theoretically be argued that you could further squeeze 13 bits out per tree entry because you would need only 5 possible values (100644, 100755 12, 4, and 16, all octal) for the modes, but we will never know what other modes we would want to use in the future, so not being over-tight and using 16-bit for this purpose is probably a good trade-off Absolutely. I tried not to lose any of the currently available extension possibilities in the canonical object format. (squeezing 8 bits out per tree entry would make the shape of ident table entry and tree path entry different and may hurt reusing the code to parse these tables). One could argue that 16 bits is much more than sufficient to encode a time zone offset too. but again this didn't seem worth painting ourselves in a corner if ever some creative time zones are used. Those table are also compressed. So any repetition of the same mode bit pattern or sparseness in the tz bits is likely to be compressed well. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL REQUEST] initial pack v4 support
Nicolas Pitre n...@fluxnic.net writes:
Junio, would you please pull the following into pu:
git://git.linaro.org/people/nico/git
This is the pack v4 work to date which is somewhat getting usable. It
is time it gets more exposure, and possibly some more people's attention
who would like to work on the missing parts as I need to scale down my
own involvement.
Thanks. Parked on 'pu'.
packv4-parse.c: allow tree entry copying from a canonical tree object
This one needed a small fix-up to make it compile.
I do not particularly like reusing that size variable, but it
seemed to be dead at that point, so...
packv4-parse.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index f96acc1..3f95ed4 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -365,13 +365,14 @@ static int copy_canonical_tree_entries(struct packed_git
*p, off_t offset,
update_tree_entry(desc);
end = desc.buffer;
- if (end - from *sizep) {
+ size = (const char *)end - (const char *)from;
+ if (size *sizep) {
free(data);
return -1;
}
- memcpy(*dstp, from, end - from);
- *dstp += end - from;
- *sizep -= end - from;
+ memcpy(*dstp, from, size);
+ *dstp += size;
+ *sizep -= size;
free(data);
return 0;
}
--
1.8.4-468-g1185e84
--
To unsubscribe from this list: send the line 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: [PULL REQUEST] initial pack v4 support
On Tue, 10 Sep 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: Junio, would you please pull the following into pu: git://git.linaro.org/people/nico/git This is the pack v4 work to date which is somewhat getting usable. It is time it gets more exposure, and possibly some more people's attention who would like to work on the missing parts as I need to scale down my own involvement. Thanks. Parked on 'pu'. Good. packv4-parse.c: allow tree entry copying from a canonical tree object This one needed a small fix-up to make it compile. I do not particularly like reusing that size variable, but it seemed to be dead at that point, so... Feel free to fold this in the original commit. I'm curious... what compiler are you using? My gcc version is just happy to do arithmetic on void pointers. Nicolas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/5] pull: rename pull.rename to pull.mode
Felipe Contreras felipe.contre...@gmail.com writes: Also 'branch.name.rebase' to 'branch.name.pullmode'. This way 'pull.mode' can be set to 'merge', and the default can be something else. The old configurations still work, but get deprecated. Sounds good, but we should still mention these old names in the documentation (and mark them as deprecated). +test $mode == 'rebase' rebase=true POSIX test does not take == as string equality; it is a bash-ism. test $mode = rebase -- To unsubscribe from this list: send the line 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-cvsserver strips exec bit
Junio C Hamano wrote: I stopped interacting with CVS quite a long time ago, so I do not have any way of verifying, but the fix may be just the matter of something like this. This fix is close. Now all files are checked out with a mask of 555. -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
Junio C Hamano gitster at pobox.com writes: Tvangeste i.4m.l33t at yandex.ru writes: Hi, After bisecting this problem I ended up with the mentioned commit that completely breaks git-svn for me on Windows (mingw/msys version). == # git svn rebase warning: unable to access '': Invalid argument warning: unable to access '': Invalid argument fatal: unable to access '../../../../w:/work/my/repo.git/.git/config': Invalid argument fatal: index file open failed: Invalid argument Cannot rebase: You have unstaged changes. Please commit or stash them. rebase refs/remotes/trunk: command returned error: 1 == Please note that I use the official git repository as-is, this one (no additional patches): git://git.kernel.org/pub/scm/git/git.git e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit commit e02ca72f70ed8f0268a81f72cb3230c72e538e77 Author: Jiang Xin Date: Tue Jun 25 23:53:43 2013 +0800 path.c: refactor relative_path(), not only strip prefix Thanks, --Tvangeste The suspect commit and symptom look consistent. You started from a directory whose absolute path is w:/work/... and the updated code mistakenly thoguht that something that begins with w (not '/') is not an absolute, so added a series of ../ to make it relative, or something silly like that. Jiang? Indeed, this patch seems to change relative_path in a way that breaks git initialization, not just on Windows. Previously, relative_path was always called with two absolute paths, and it only returned a relative path if the first was a subdir of the second (so a better name would probably have been 'relative_path_if_subdir'). The purpose was to improve performance by making GIT_DIR shorter if it was a subdir of GIT_WORK_TREE. After this patch, relative_path always tries to return a relative path, even if both absolute paths are completely disjunct. This not only defeats the purpose (by making GIT_DIR longer, thus hurting performance), it is also not possible in general. POSIX explicitly allows for '//hostname' notation referring to network resources that are not explicitly mounted under '/'. I.e. given two absolute paths '//hostname1/a' and '//hostname2/b', there is no relative path from a to b or vice versa. Additionally, GIT_DIR now may or may not have a trailing slash, which gives me a slightly uneasy feeling... -- To unsubscribe from this list: send the line 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: [PULL REQUEST] initial pack v4 support
Nicolas Pitre n...@fluxnic.net writes: On Tue, 10 Sep 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: Junio, would you please pull the following into pu: git://git.linaro.org/people/nico/git This is the pack v4 work to date which is somewhat getting usable. It is time it gets more exposure, and possibly some more people's attention who would like to work on the missing parts as I need to scale down my own involvement. Thanks. Parked on 'pu'. Good. packv4-parse.c: allow tree entry copying from a canonical tree object This one needed a small fix-up to make it compile. I do not particularly like reusing that size variable, but it seemed to be dead at that point, so... Feel free to fold this in the original commit. I'm curious... what compiler are you using? My gcc version is just happy to do arithmetic on void pointers. I have -Werror -Wpointer-arith -Woverflow -Wno-pointer-to-int-cast defined in my private build script (the todo branch is checked out as Meta/ subdirectory of git.git, and Meta/Make --pedantic is how I build things). -- To unsubscribe from this list: send the line 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-cvsserver strips exec bit
Michael Cronenworth wrote: This fix is close. Now all files are checked out with a mask of 555. Let me clarify. Git mask 755 = CVS mask 555 Git mask 644 = CVS mask 444 Thanks, Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] remote-bzr: reuse bzrlib transports when possible
Junio C Hamano gits...@pobox.com writes:
Richard Hansen rhan...@bbn.com writes:
def do_export(parser):
-global parsed_refs, dirname
+global parsed_refs, dirname, transports
As this has been acked by Felipe who knows the script the best, I'll
apply this directly to 'master'.
These additions of global transports however have trivial
interactions with fc/contrib-bzr-hg-fixes topic Felipe posted
earlier, which I was planning to start merging down to 'next' and
then to 'master'. Most funcions merely use the variable without
assigning, so global transports can be removed, in line with the
spirit of 641a2b5b (remote-helpers: cleanup more global variables,
2013-08-28), except for the obvious initialisation in main(), I
think. Please double check the conflict resolution result in a
commit on 'pu' with
git show 'origin/pu^{/Merge fc/contrib-bzr}'
when I push the result out.
Thanks.
Ping? I'd like to merge fc/contrib-bzr.hg-fixes topic to 'next'
(and fast track it to 'master' after that), and it would be helpful
to get an Ack on the conflict resolution I have.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: breakage in revision traversal with pathspec
Kevin Bracey ke...@bracey.fi writes: On 10/09/2013 20:19, Junio C Hamano wrote: I am grumpy X-. It appears that we introduced a large breakage during 1.8.4 cycle to the revision traversal machinery and made pathspec-limited git log pretty much useless. This command $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl reports that a merge 766f0f8ef7 (which did not touch the specified path at all) touches it. Bisecting points at d0af663e (revision.c: Make --full-history consider more merges, 2013-05-16). That merge appearing *with* --full-history would seem like correct behaviour to me. Or at least it's what I intended. Oh, of course. --full-history is about showing any pointless change, the mainline was a lot more up-to-date and there were changes relative to a fork based on an older baseline, so your updated log should show that in the mainline git-cvsserver.perl has been more fresh when that merge happened. But it shouldn't appear if the user does not ask for --full-history. However, your particular example occurs *without*--full-history, which suggests a problem. Yes. I note that gitk v1.8.3^0..v1.8.4 and git log --parents v1.8.3..v1.8.4 show that merge in Git 1.8.3, but not in Git 1.8.4. So we're going partially forwards, at least. With the testcases demonstrating the cases your series fixed that all look sensible, I think it is not really an option for us to revert them; you do not have to defend it with we are going partially forwards ;-). -- To unsubscribe from this list: send the line 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] Reject non-ff pulls by default
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: You are in favor of an _option_ to allow people to forbid a pull in a non-ff situation, and I think other people are also in agreement. Yes. Having an option can't harm anybody, and there's a clear demand for that. So perhaps: - drop jc/pull-training-wheel and revert its merge from 'next'; - update Felipe's series with a bit of tweak to make it less impactful by demoting error into warning and advice. would be a good way forward? I didn't follow very closely the discussions and patch series, but that would sound right to me. The last version of Felipes' patch series already gives a warning only, but the wording and commit message implies that this will become an error in the future (this is the part with which I disagree). OK, the first step to drop jc/pull-training-wheel from 'next' has been done. I _think_ the one that starts at $gmane/234295 is the newer incarnation of the patches in this thread, but that seems to do a lot more than what the patches in this thread did, and it also badly interacts with another topic in flight that updates git-pull, so I have a topic branch for it but haven't merged to 'pu' 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 v5 2/2] Add new @ shortcut for HEAD
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Hmph, is the above sufficient? I added a case that mimics Stefano's
original regression report (which is handled) and another that uses
doubled @ for the same purpose of introducing a funny hierarchy,
and it appears that checkout -b chokes on it.
This fixes it:
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -1014,6 +1014,8 @@ static int interpret_empty_at(const char *name,
int namelen, int len, struct str
/* make sure it's a single @, or @@{.*}, not @foo */
next = strchr(name + len + 1, '@');
+ if (next next[1] != '{')
+ return -1;
if (!next)
next = name + namelen;
if (next != name + 1)
I think this should be sufficient for all cases, as the sequence
@{ cannot be a part of valid reference names.
Thanks.
I see v6 was posted yesterday after this message, but it does not
seem to have this fix, nor the additional test case I gave you in
the message upthread. Sent a wrong version of patch by mistake?
Ping?
I could squash the fixup at the tip of on fc/at-head in if you want
me to, but v6 seems to be a mistake to me.
--
To unsubscribe from this list: send the line 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] lookup_object: remove hashtable_index() and optimize hash_obj()
hashtable_index() appears to be a close duplicate of hash_obj().
Keep only the later and make it usable for all cases.
Also remove the modulus as this is an expansive operation.
The size argument is always a power of 2 anyway, so a simple
mask operation provides the same result.
On a 'git rev-list --all --objects' run this decreased the time spent
in lookup_object from 27.5% to 24.1%.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
I discovered this patch in my git work tree dating from 2 years ago.
diff --git a/object.c b/object.c
index d8a4b1f..e2dae22 100644
--- a/object.c
+++ b/object.c
@@ -43,16 +43,16 @@ int type_from_string(const char *str)
die(invalid object type \%s\, str);
}
-static unsigned int hash_obj(struct object *obj, unsigned int n)
+static unsigned int hash_obj(const unsigned char *sha1, unsigned int n)
{
unsigned int hash;
- memcpy(hash, obj-sha1, sizeof(unsigned int));
- return hash % n;
+ memcpy(hash, sha1, sizeof(unsigned int));
+ return hash (n - 1);
}
static void insert_obj_hash(struct object *obj, struct object **hash, unsigned
int size)
{
- unsigned int j = hash_obj(obj, size);
+ unsigned int j = hash_obj(obj-sha1, size);
while (hash[j]) {
j++;
@@ -62,13 +62,6 @@ static void insert_obj_hash(struct object *obj, struct
object **hash, unsigned i
hash[j] = obj;
}
-static unsigned int hashtable_index(const unsigned char *sha1)
-{
- unsigned int i;
- memcpy(i, sha1, sizeof(unsigned int));
- return i % obj_hash_size;
-}
-
struct object *lookup_object(const unsigned char *sha1)
{
unsigned int i, first;
@@ -77,7 +70,7 @@ struct object *lookup_object(const unsigned char *sha1)
if (!obj_hash)
return NULL;
- first = i = hashtable_index(sha1);
+ first = i = hash_obj(sha1, obj_hash_size);
while ((obj = obj_hash[i]) != NULL) {
if (!hashcmp(sha1, obj-sha1))
break;
--
To unsubscribe from this list: send the line 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: [PULL REQUEST] initial pack v4 support
On Tue, 10 Sep 2013, Junio C Hamano wrote:
packv4-parse.c: allow tree entry copying from a canonical tree object
This one needed a small fix-up to make it compile.
I do not particularly like reusing that size variable, but it
seemed to be dead at that point, so...
packv4-parse.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/packv4-parse.c b/packv4-parse.c
index f96acc1..3f95ed4 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -365,13 +365,14 @@ static int copy_canonical_tree_entries(struct
packed_git *p, off_t offset,
update_tree_entry(desc);
end = desc.buffer;
- if (end - from *sizep) {
+ size = (const char *)end - (const char *)from;
+ if (size *sizep) {
BTW, a simpler fix might simply involve declaring those 2 variables as
const char * up front which would remove the need for any cast.
Nicolas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-cvsserver strips exec bit
Michael Cronenworth m...@cchtml.com writes:
Michael Cronenworth wrote:
This fix is close. Now all files are checked out with a mask of 555.
Let me clarify.
Git mask 755 = CVS mask 555
Git mask 644 = CVS mask 444
Thanks,
Michael
Then what I wrote was actually relevant ;-)
I am not sure if we want to use the owner bit (i.e. 4th place)
instead of the other bit (i.e. the last place) like this patch does,
though. The old code in 1.8.1.x would have produced either r (for
100644) or wx (for 100755); I think that the result of applying
this patch would give us r (for 100644) or rx (for 100755).
This should then work, I would think.
-- 8 --
Subject: [PATCH v2] cvsserver: pick up the right mode bits
When determining the file mode from either ls-tree or diff-tree
output, we used to grab these octal mode string (typically 100644 or
100755) and then did
$git_perms .= r if ( $mode 4 );
$git_perms .= w if ( $mode 2 );
$git_perms .= x if ( $mode 1 );
which was already wrong, as (100644 4) is very different from
oct(100644) 4. An earlier refactoring 2c3af7e7 (cvsserver:
factor out git-log parsing logic, 2012-10-13) further changed it to
pick the third octal digit (10*0*644 or 10*0*755) from the left and
then do the above conversion, which does not make sense, either.
Let's use the third digit from the last of the octal mode string to
make sure we get the executable and read bits right.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-cvsserver.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index a0d796e..67b1e7b 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -4167,7 +4167,7 @@ sub convertToDbMode
# this half-converted form, but it isn't currently worth the
# backwards compatibility headaches.
-$mode=~/^\d\d(\d)\d{3}$/;
+$mode=~/^\d{3}(\d)\d\d$/;
my $userBits=$1;
my $dbMode = ;
--
To unsubscribe from this list: send the line 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 v6 8/8] update-ref: add test cases covering --stdin signature
Eric Sunshine sunsh...@sunshineco.com writes: Thus printf provides all the functionality you require, and print_nul() function can be dropped. So: printf '%s\0' foo bar baz is equivalent to: print_null foo bar baz Good eyes. Thanks, I missed them when I looked at the patches. -- To unsubscribe from this list: send the line 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 v6 7/8] update-ref: support multiple simultaneous updates
On Mon, Sep 9, 2013 at 8:57 PM, Brad King brad.k...@kitware.com wrote: diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt index 0df13ff..0a0a551 100644 --- a/Documentation/git-update-ref.txt +++ b/Documentation/git-update-ref.txt @@ -58,6 +58,58 @@ archive by creating a symlink tree). +option:: + Modify behavior of the next command naming a ref. + The only valid option is `no-deref` to avoid dereferencing + a symbolic ref. + +Use 40 0 or the empty string to specify a zero value, except that Did you want an 's' after the 0? 0's 0s 0's zeros zeroes +with `-z` an empty oldvalue is considered missing. + +If all refs can be locked with matching oldvalues +simultaneously, all modifications are performed. Otherwise, no +modifications are performed. Note that while each individual +ref is updated or deleted atomically, a concurrent reader may +still see a subset of the modifications. -- To unsubscribe from this list: send the line 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-v3] Allow git-filter-branch to process large repositories with lots of branches.
As noted in several forums, a recommended way to move trees between repositories is to use git-filter-branch to revise the history for a single tree: http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth er-preserving-history/ http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-r epo-to-another-not-a-clone-preserving-history However, this can lead to argument list too long errors when the original repository has many retained branches (6k) /usr/local/git/libexec/git-core/git-filter-branch: line 270: /usr/local/git/libexec/git-core/git: Argument list too long Could not get the commits Piping the saved output from git rev-parse into git rev-list avoids this problem, since the rev-parse output is not processed as a command line argument. --- git-filter-branch.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index ac2a005..2091885 100755 --- a/git-filter-branch.shgit +++ b/git-filter-branch.sh @@ -255,7 +255,7 @@ else remap_to_ancestor=t fi -rev_args=$(git rev-parse --revs-only $@) +git rev-parse --revs-only $@ ../parse case $filter_subdir in ) @@ -268,7 +268,7 @@ case $filter_subdir in esac git rev-list --reverse --topo-order --default HEAD \ - --parents --simplify-merges $rev_args $@ ../revs || + --parents --simplify-merges --stdin $@ ../parse ../revs || die Could not get the commits commits=$(wc -l ../revs | tr -d ) -- 1.8.3.2 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v3] Allow git-filter-branch to process large repositories with lots of branches.
Lee Carver lee.car...@servicenow.com writes: As noted in several forums, a recommended way to move trees between repositories is to use git-filter-branch to revise the history for a single tree: http://gbayer.com/development/moving-files-from-one-git-repository-to-anoth er-preserving-history/ http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-r epo-to-another-not-a-clone-preserving-history However, this can lead to argument list too long errors when the original repository has many retained branches (6k) /usr/local/git/libexec/git-core/git-filter-branch: line 270: /usr/local/git/libexec/git-core/git: Argument list too long Could not get the commits Piping the saved output from git rev-parse into git rev-list avoids this problem, since the rev-parse output is not processed as a command line argument. --- git-filter-branch.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-filter-branch.sh b/git-filter-branch.sh index ac2a005..2091885 100755 --- a/git-filter-branch.shgit +++ b/git-filter-branch.sh @@ -255,7 +255,7 @@ else remap_to_ancestor=t fi -rev_args=$(git rev-parse --revs-only $@) +git rev-parse --revs-only $@ ../parse Where is this rev-parse command running? Is it always safe to clobber the file ../parse like this? case $filter_subdir in ) @@ -268,7 +268,7 @@ case $filter_subdir in esac git rev-list --reverse --topo-order --default HEAD \ - --parents --simplify-merges $rev_args $@ ../revs || + --parents --simplify-merges --stdin $@ ../parse ../revs || die Could not get the commits commits=$(wc -l ../revs | tr -d ) -- To unsubscribe from this list: send the line 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 0/3] Fix MSVC compile errors and cleanup stat definitions
A few minor fixes for the MSVC build. Also here: https://github.com/kblees/git/tree/kb/fix-msvc-stat-definitions Karsten Blees (3): MSVC: fix compile errors due to missing libintl.h MSVC: fix compile errors due to macro redefinitions MSVC: fix stat definition hell compat/mingw.h | 21 + compat/msvc.h| 15 --- config.mak.uname | 1 + 3 files changed, 18 insertions(+), 19 deletions(-) -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line 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 1/3] MSVC: fix compile errors due to missing libintl.h
Set NO_GETTEXT in config.mak.uname to get rid of libintl.h dependency. Signed-off-by: Karsten Blees bl...@dcon.de --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index b27f51d..64b7f49 100644 --- a/config.mak.uname +++ b/config.mak.uname @@ -340,6 +340,7 @@ ifeq ($(uname_S),Windows) OBJECT_CREATION_USES_RENAMES = UnfortunatelyNeedsTo NO_REGEX = YesPlease NO_CURL = YesPlease + NO_GETTEXT = YesPlease NO_PYTHON = YesPlease BLK_SHA1 = YesPlease ETAGS_TARGET = ETAGS -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line 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 2/3] MSVC: fix compile errors due to macro redefinitions
Skip errno.h definitions if they are already defined.
Signed-off-by: Karsten Blees bl...@dcon.de
---
compat/mingw.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/compat/mingw.h b/compat/mingw.h
index bd0a88b..6b531e4 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -32,7 +32,9 @@ typedef int socklen_t;
#define WEXITSTATUS(x) ((x) 0xff)
#define WTERMSIG(x) SIGTERM
+#ifndef EWOULDBLOCK
#define EWOULDBLOCK EAGAIN
+#endif
#define SHUT_WR SD_SEND
#define SIGHUP 1
@@ -46,8 +48,12 @@ typedef int socklen_t;
#define F_SETFD 2
#define FD_CLOEXEC 0x1
+#ifndef EAFNOSUPPORT
#define EAFNOSUPPORT WSAEAFNOSUPPORT
+#endif
+#ifndef ECONNABORTED
#define ECONNABORTED WSAECONNABORTED
+#endif
struct passwd {
char *pw_name;
--
1.8.4.8243.gbcbdefd
--
To unsubscribe from this list: send the line 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 3/3] MSVC: fix stat definition hell
In msvc.h, there's a couple of stat related functions defined diffently from mingw.h. When we remove these definitions, the only problem we get is warning C4005: '_stati64' : macro redefinition for this line in mingw.h: #define _stati64(x,y) mingw_stat(x,y) The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the original _stati64 family of functions was renamed to _stat32i64, and the former function names became macros (pointing to the appropriate function based on the definition of _USE_32BIT_TIME_T). Defining _stati64 works on MinGW because MinGW by default compiles against the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather than a macro). Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC apparently can also compile for the Windows MSVCRT.DLL via the DDK (see http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ). Remove the stat definitions from msvc.h, as they are not compiler related. In mingw.h, determine the runtime version in use from the definitions of _stati64 and _USE_32BIT_TIME_T, and define stat() accordingly. This also fixes that stat() in MSVC builds still resolves to mingw_lstat() instead of mingw_stat(). Signed-off-by: Karsten Blees bl...@dcon.de --- compat/mingw.h | 15 +++ compat/msvc.h | 15 --- 2 files changed, 11 insertions(+), 19 deletions(-) diff --git a/compat/mingw.h b/compat/mingw.h index 6b531e4..3c3a9d9 100644 --- a/compat/mingw.h +++ b/compat/mingw.h @@ -264,19 +264,26 @@ static inline int getrlimit(int resource, struct rlimit *rlp) return 0; } -/* Use mingw_lstat() instead of lstat()/stat() and - * mingw_fstat() instead of fstat() on Windows. +/* + * Use mingw specific stat()/lstat()/fstat() implementations on Windows. */ #define off_t off64_t #define lseek _lseeki64 -#ifndef ALREADY_DECLARED_STAT_FUNCS + +/* use struct stat with 64 bit st_size */ #define stat _stati64 int mingw_lstat(const char *file_name, struct stat *buf); int mingw_stat(const char *file_name, struct stat *buf); int mingw_fstat(int fd, struct stat *buf); #define fstat mingw_fstat #define lstat mingw_lstat -#define _stati64(x,y) mingw_stat(x,y) + +#ifndef _stati64 +# define _stati64(x,y) mingw_stat(x,y) +#elif defined (_USE_32BIT_TIME_T) +# define _stat32i64(x,y) mingw_stat(x,y) +#else +# define _stat64(x,y) mingw_stat(x,y) #endif int mingw_utime(const char *file_name, const struct utimbuf *times); diff --git a/compat/msvc.h b/compat/msvc.h index 96b6d60..580bb55 100644 --- a/compat/msvc.h +++ b/compat/msvc.h @@ -24,21 +24,6 @@ static __inline int strcasecmp (const char *s1, const char *s2) #undef ERROR -/* Use mingw_lstat() instead of lstat()/stat() and mingw_fstat() instead - * of fstat(). We add the declaration of these functions here, suppressing - * the corresponding declarations in mingw.h, so that we can use the - * appropriate structure type (and function) names from the msvc headers. - */ -#define stat _stat64 -int mingw_lstat(const char *file_name, struct stat *buf); -int mingw_fstat(int fd, struct stat *buf); -#define fstat mingw_fstat -#define lstat mingw_lstat -#define _stat64(x,y) mingw_lstat(x,y) -#define ALREADY_DECLARED_STAT_FUNCS - #include compat/mingw.h -#undef ALREADY_DECLARED_STAT_FUNCS - #endif -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 0/5] New hash table implementation
Also here: https://github.com/kblees/git/tree/kb/hashmap Hi, this is a spin-off of my (very slowly progressing) msysgit fscache project. I needed to remove things from the hash table, which cannot be implemented efficiently in hash.[ch]. So I wrote hasmap.[ch], with these features: - O(1) remove - builtin entry chaining - ready-to-use FNV-1 hash functions - unit test - additions are ~twice as fast - uses less memory Patches 2 and 5 convert existing uses of hash.[ch] to hashmap.[ch]. Patches 3 and 4 are useful optimizations of their own. I haven't found the time to tackle name-hash.c yet, this is where remove() could come into play (to replace the CE_UNHASHED flag). Karsten Karsten Blees (5): add a hashtable implementation that supports O(1) removal buitin/describe.c: use new hash map implementation diffcore-rename.c: move code around to prepare for the next patch diffcore-rename.c: simplify finding exact renames diffcore-rename.c: use new hash map implementation Makefile | 3 + builtin/describe.c | 53 +-- diffcore-rename.c | 185 +- hashmap.c | 210 +++ hashmap.h | 200 + t/t0011-hashmap.sh | 236 test-hashmap.c | 258 + 7 files changed, 995 insertions(+), 150 deletions(-) create mode 100644 hashmap.c create mode 100644 hashmap.h create mode 100755 t/t0011-hashmap.sh create mode 100644 test-hashmap.c -- 1.8.4.8243.gbcbdefd -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 1/5] add a hashtable implementation that supports O(1) removal
The existing hashtable implementation (in hash.[ch]) uses open addressing
(i.e. resolve hash collisions by distributing entries across the table).
Thus, removal is difficult to implement with less than O(n) complexity.
Resolving collisions of entries with identical hashes (e.g. via chaining)
is left to the client code.
Add a hashtable implementation that supports O(1) removal and is slightly
easier to use due to builtin entry chaining.
Supports all basic operations init, free, get, add, remove and iteration.
Also includes ready-to-use hash functions based on the public domain FNV-1
algorithm (http://www.isthe.com/chongo/tech/comp/fnv).
The per-entry data structure (hashmap_entry) is meant to be piggybacked
in front of the client's data structure to save memory. See test-hashmap.c
for usage examples.
The hashtable is resized by a factor of four when 80% full. With these
settings, average memory consumption is about 2/3 of hash.[ch], and
insertion is about twice as fast due to less frequent resizing.
Signed-off-by: Karsten Blees bl...@dcon.de
---
Makefile | 3 +
hashmap.c | 210 +++
hashmap.h | 200 +
t/t0011-hashmap.sh | 236
test-hashmap.c | 258 +
5 files changed, 907 insertions(+)
create mode 100644 hashmap.c
create mode 100644 hashmap.h
create mode 100755 t/t0011-hashmap.sh
create mode 100644 test-hashmap.c
diff --git a/Makefile b/Makefile
index 3588ca1..e6ad011 100644
--- a/Makefile
+++ b/Makefile
@@ -562,6 +562,7 @@ TEST_PROGRAMS_NEED_X += test-date
TEST_PROGRAMS_NEED_X += test-delta
TEST_PROGRAMS_NEED_X += test-dump-cache-tree
TEST_PROGRAMS_NEED_X += test-genrandom
+TEST_PROGRAMS_NEED_X += test-hashmap
TEST_PROGRAMS_NEED_X += test-index-version
TEST_PROGRAMS_NEED_X += test-line-buffer
TEST_PROGRAMS_NEED_X += test-match-trees
@@ -681,6 +682,7 @@ LIB_H += gpg-interface.h
LIB_H += graph.h
LIB_H += grep.h
LIB_H += hash.h
+LIB_H += hashmap.h
LIB_H += help.h
LIB_H += http.h
LIB_H += kwset.h
@@ -811,6 +813,7 @@ LIB_OBJS += gpg-interface.o
LIB_OBJS += graph.o
LIB_OBJS += grep.o
LIB_OBJS += hash.o
+LIB_OBJS += hashmap.o
LIB_OBJS += help.o
LIB_OBJS += hex.o
LIB_OBJS += ident.o
diff --git a/hashmap.c b/hashmap.c
new file mode 100644
index 000..686ee6f
--- /dev/null
+++ b/hashmap.c
@@ -0,0 +1,210 @@
+/*
+ * Generic implementation of hash-based key value mappings.
+ */
+#include cache.h
+#include hashmap.h
+
+#define FNV32_BASE ((unsigned int) 0x811c9dc5)
+#define FNV32_PRIME ((unsigned int) 0x01000193)
+
+unsigned int strhash(const char *str)
+{
+ unsigned int c, hash = FNV32_BASE;
+ while ((c = (unsigned char) *str++))
+ hash = (hash * FNV32_PRIME) ^ c;
+ return hash;
+}
+
+unsigned int strihash(const char *str)
+{
+ unsigned int c, hash = FNV32_BASE;
+ while ((c = (unsigned char) *str++)) {
+ if (c = 'a' c = 'z')
+ c -= 'a' - 'A';
+ hash = (hash * FNV32_PRIME) ^ c;
+ }
+ return hash;
+}
+
+unsigned int memhash(const void *buf, size_t len)
+{
+ unsigned int hash = FNV32_BASE;
+ unsigned char *ucbuf = (unsigned char*) buf;
+ while (len--) {
+ unsigned int c = *ucbuf++;
+ hash = (hash * FNV32_PRIME) ^ c;
+ }
+ return hash;
+}
+
+unsigned int memihash(const void *buf, size_t len)
+{
+ unsigned int hash = FNV32_BASE;
+ unsigned char *ucbuf = (unsigned char*) buf;
+ while (len--) {
+ unsigned int c = *ucbuf++;
+ if (c = 'a' c = 'z')
+ c -= 'a' - 'A';
+ hash = (hash * FNV32_PRIME) ^ c;
+ }
+ return hash;
+}
+
+#define HASHMAP_INITIAL_SIZE 64
+/* grow / shrink by 2^2 */
+#define HASHMAP_GROW 2
+/* grow if 80% full (to 20%) */
+#define HASHMAP_GROW_AT 1.25
+/* shrink if 16.6% full (to 66.6%) */
+#define HASHMAP_SHRINK_AT 6
+
+static inline int entry_equals(const hashmap *map, const hashmap_entry *e1,
+ const hashmap_entry *e2)
+{
+ return (e1 == e2) || (e1-hash == e2-hash !(*map-cmpfn)(e1, e2));
+}
+
+static inline unsigned int bucket(const hashmap *map, const hashmap_entry *key)
+{
+ return key-hash (map-tablesize - 1);
+}
+
+static void rehash(hashmap *map, unsigned int newsize)
+{
+ unsigned int i, oldsize = map-tablesize;
+ hashmap_entry **oldtable = map-table;
+
+ map-tablesize = newsize;
+ map-table = xcalloc(sizeof(hashmap_entry*), map-tablesize);
+ for (i = 0; i oldsize; i++) {
+ hashmap_entry *e = oldtable[i];
+ while (e) {
+ hashmap_entry *next = e-next;
+ unsigned int b = bucket(map, e);
+ e-next = map-table[b];
+ map-table[b] = e;
+
[PATCH/RFC 2/5] buitin/describe.c: use new hash map implementation
Signed-off-by: Karsten Blees bl...@dcon.de
---
builtin/describe.c | 53 -
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 7d73722..bbc7159 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -6,7 +6,7 @@
#include exec_cmd.h
#include parse-options.h
#include diff.h
-#include hash.h
+#include hashmap.h
#include argv-array.h
#define SEEN (1u0)
@@ -25,7 +25,7 @@ static int longformat;
static int first_parent;
static int abbrev = -1; /* unspecified */
static int max_candidates = 10;
-static struct hash_table names;
+static hashmap names;
static int have_util;
static const char *pattern;
static int always;
@@ -38,7 +38,7 @@ static const char *diff_index_args[] = {
struct commit_name {
- struct commit_name *next;
+ hashmap_entry entry;
unsigned char peeled[20];
struct tag *tag;
unsigned prio:2; /* annotated tag = 2, tag = 1, head = 0 */
@@ -50,6 +50,11 @@ static const char *prio_names[] = {
head, lightweight, annotated,
};
+static int commit_name_cmp(struct commit_name *cn1, struct commit_name *cn2)
+{
+ return hashcmp(cn1-peeled, cn2-peeled);
+}
+
static inline unsigned int hash_sha1(const unsigned char *sha1)
{
unsigned int hash;
@@ -59,21 +64,10 @@ static inline unsigned int hash_sha1(const unsigned char
*sha1)
static inline struct commit_name *find_commit_name(const unsigned char *peeled)
{
- struct commit_name *n = lookup_hash(hash_sha1(peeled), names);
- while (n !!hashcmp(peeled, n-peeled))
- n = n-next;
- return n;
-}
-
-static int set_util(void *chain, void *data)
-{
- struct commit_name *n;
- for (n = chain; n; n = n-next) {
- struct commit *c = lookup_commit_reference_gently(n-peeled, 1);
- if (c)
- c-util = n;
- }
- return 0;
+ struct commit_name key;
+ hashmap_entry_init(key, hash_sha1(peeled), 0);
+ hashcpy(key.peeled, peeled);
+ return hashmap_get(names, key);
}
static int replace_name(struct commit_name *e,
@@ -118,16 +112,10 @@ static void add_to_known_names(const char *path,
struct tag *tag = NULL;
if (replace_name(e, prio, sha1, tag)) {
if (!e) {
- void **pos;
e = xmalloc(sizeof(struct commit_name));
hashcpy(e-peeled, peeled);
- pos = insert_hash(hash_sha1(peeled), e, names);
- if (pos) {
- e-next = *pos;
- *pos = e;
- } else {
- e-next = NULL;
- }
+ hashmap_entry_init(e, hash_sha1(peeled), 0);
+ hashmap_add(names, e);
e-path = NULL;
}
e-tag = tag;
@@ -292,7 +280,14 @@ static void describe(const char *arg, int last_one)
fprintf(stderr, _(searching to describe %s\n), arg);
if (!have_util) {
- for_each_hash(names, set_util, NULL);
+ hashmap_iter iter;
+ struct commit *c;
+ struct commit_name *n = hashmap_iter_first(names, iter);
+ for (; n; n = hashmap_iter_next(iter)) {
+ c = lookup_commit_reference_gently(n-peeled, 1);
+ if (c)
+ c-util = n;
+ }
have_util = 1;
}
@@ -463,9 +458,9 @@ int cmd_describe(int argc, const char **argv, const char
*prefix)
return cmd_name_rev(args.argc, args.argv, prefix);
}
- init_hash(names);
+ hashmap_init(names, (hashmap_cmp_fn) commit_name_cmp, 0);
for_each_rawref(get_name, NULL);
- if (!names.nr !always)
+ if (!names.size !always)
die(_(No names found, cannot describe anything.));
if (argc == 0) {
--
1.8.4.8243.gbcbdefd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 3/5] diffcore-rename.c: move code around to prepare for the next patch
No actual code changes, just move hash_filespec up and outdent part of
find_identical_files.
Signed-off-by: Karsten Blees bl...@dcon.de
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6c7a72f..008a60c 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -248,6 +248,18 @@ struct file_similarity {
struct file_similarity *next;
};
+static unsigned int hash_filespec(struct diff_filespec *filespec)
+{
+ unsigned int hash;
+ if (!filespec-sha1_valid) {
+ if (diff_populate_filespec(filespec, 0))
+ return 0;
+ hash_sha1_file(filespec-data, filespec-size, blob,
filespec-sha1);
+ }
+ memcpy(hash, filespec-sha1, sizeof(hash));
+ return hash;
+}
+
static int find_identical_files(struct file_similarity *src,
struct file_similarity *dst,
struct diff_options *options)
@@ -258,46 +270,46 @@ static int find_identical_files(struct file_similarity
*src,
* Walk over all the destinations ...
*/
do {
- struct diff_filespec *target = dst-filespec;
- struct file_similarity *p, *best;
- int i = 100, best_score = -1;
-
- /*
-* .. to find the best source match
-*/
- best = NULL;
- for (p = src; p; p = p-next) {
- int score;
- struct diff_filespec *source = p-filespec;
-
- /* False hash collision? */
- if (hashcmp(source-sha1, target-sha1))
- continue;
- /* Non-regular files? If so, the modes must match! */
- if (!S_ISREG(source-mode) || !S_ISREG(target-mode)) {
- if (source-mode != target-mode)
- continue;
- }
- /* Give higher scores to sources that haven't been used
already */
- score = !source-rename_used;
- if (source-rename_used options-detect_rename !=
DIFF_DETECT_COPY)
- continue;
- score += basename_same(source, target);
- if (score best_score) {
- best = p;
- best_score = score;
- if (score == 2)
- break;
- }
+ struct diff_filespec *target = dst-filespec;
+ struct file_similarity *p, *best;
+ int i = 100, best_score = -1;
- /* Too many identical alternatives? Pick one */
- if (!--i)
- break;
+ /*
+* .. to find the best source match
+*/
+ best = NULL;
+ for (p = src; p; p = p-next) {
+ int score;
+ struct diff_filespec *source = p-filespec;
+
+ /* False hash collision? */
+ if (hashcmp(source-sha1, target-sha1))
+ continue;
+ /* Non-regular files? If so, the modes must match! */
+ if (!S_ISREG(source-mode) || !S_ISREG(target-mode)) {
+ if (source-mode != target-mode)
+ continue;
}
- if (best) {
- record_rename_pair(dst-index, best-index, MAX_SCORE);
- renames++;
+ /* Give higher scores to sources that haven't been used already
*/
+ score = !source-rename_used;
+ if (source-rename_used options-detect_rename !=
DIFF_DETECT_COPY)
+ continue;
+ score += basename_same(source, target);
+ if (score best_score) {
+ best = p;
+ best_score = score;
+ if (score == 2)
+ break;
}
+
+ /* Too many identical alternatives? Pick one */
+ if (!--i)
+ break;
+ }
+ if (best) {
+ record_rename_pair(dst-index, best-index, MAX_SCORE);
+ renames++;
+ }
} while ((dst = dst-next) != NULL);
return renames;
}
@@ -343,18 +355,6 @@ static int find_same_files(void *ptr, void *data)
return ret;
}
-static unsigned int hash_filespec(struct diff_filespec *filespec)
-{
- unsigned int hash;
- if (!filespec-sha1_valid) {
- if (diff_populate_filespec(filespec, 0))
- return 0;
- hash_sha1_file(filespec-data, filespec-size, blob,
filespec-sha1);
-
[PATCH/RFC 5/5] diffcore-rename.c: use new hash map implementation
Signed-off-by: Karsten Blees bl...@dcon.de
---
diffcore-rename.c | 48 +---
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 82b7975..6271af9 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -4,7 +4,7 @@
#include cache.h
#include diff.h
#include diffcore.h
-#include hash.h
+#include hashmap.h
#include progress.h
/* Table of rename/copy destinations */
@@ -243,9 +243,9 @@ static int score_compare(const void *a_, const void *b_)
}
struct file_similarity {
+ hashmap_entry entry;
int index;
struct diff_filespec *filespec;
- struct file_similarity *next;
};
static unsigned int hash_filespec(struct diff_filespec *filespec)
@@ -260,21 +260,22 @@ static unsigned int hash_filespec(struct diff_filespec
*filespec)
return hash;
}
-static int find_identical_files(struct hash_table *srcs,
+static int find_identical_files(hashmap *srcs,
int dst_index,
struct diff_options *options)
{
int renames = 0;
struct diff_filespec *target = rename_dst[dst_index].two;
- struct file_similarity *p, *best;
+ struct file_similarity *p, *best, dst;
int i = 100, best_score = -1;
/*
* Find the best source match for specified destination.
*/
best = NULL;
- for (p = lookup_hash(hash_filespec(target), srcs); p; p = p-next) {
+ hashmap_entry_init(dst, hash_filespec(target), 0);
+ for (p = hashmap_get(srcs, dst); p; p = hashmap_get_next(srcs, p)) {
int score;
struct diff_filespec *source = p-filespec;
@@ -309,34 +310,15 @@ static int find_identical_files(struct hash_table *srcs,
return renames;
}
-static int free_similarity_list(void *p, void *unused)
+static void insert_file_table(hashmap *table, int index, struct diff_filespec
*filespec)
{
- while (p) {
- struct file_similarity *entry = p;
- p = entry-next;
- free(entry);
- }
- return 0;
-}
-
-static void insert_file_table(struct hash_table *table, int index, struct
diff_filespec *filespec)
-{
- void **pos;
- unsigned int hash;
struct file_similarity *entry = xmalloc(sizeof(*entry));
entry-index = index;
entry-filespec = filespec;
- entry-next = NULL;
-
- hash = hash_filespec(filespec);
- pos = insert_hash(hash, entry, table);
- /* We already had an entry there? */
- if (pos) {
- entry-next = *pos;
- *pos = entry;
- }
+ hashmap_entry_init(entry, hash_filespec(filespec), 0);
+ hashmap_add(table, entry);
}
/*
@@ -349,11 +331,10 @@ static void insert_file_table(struct hash_table *table,
int index, struct diff_f
static int find_exact_renames(struct diff_options *options)
{
int i, renames;
- struct hash_table file_table;
+ hashmap file_table;
/* Add all sources to the hash table */
- init_hash(file_table);
- preallocate_hash(file_table, rename_src_nr);
+ hashmap_init(file_table, NULL, rename_src_nr);
for (i = 0; i rename_src_nr; i++)
insert_file_table(file_table, i, rename_src[i].p-one);
@@ -361,11 +342,8 @@ static int find_exact_renames(struct diff_options *options)
for (i = 0; i rename_dst_nr; i++)
renames += find_identical_files(file_table, i, options);
- /* Free source file_similarity chains */
- for_each_hash(file_table, free_similarity_list, options);
-
- /* .. and free the hash data structure */
- free_hash(file_table);
+ /* Free the hash data structure and entries */
+ hashmap_free(file_table, free);
return renames;
}
--
1.8.4.8243.gbcbdefd
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello
Hello, You have won 1,000.000 great british pounds in the ongoing promo draw. For claims, contact Mr Jeremy via email on: jeremy-off...@qq.com Thanks, T. Stratford. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v3] Allow git-filter-branch to process large repositories with lots of branches.
On 9/10/13 4:20 PM, Junio C Hamano gits...@pobox.com wrote:
Lee Carver lee.car...@servicenow.com writes:
As noted in several forums, a recommended way to move trees between
repositories
is to use git-filter-branch to revise the history for a single tree:
http://gbayer.com/development/moving-files-from-one-git-repository-to-ano
th
er-preserving-history/
http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git
-r
epo-to-another-not-a-clone-preserving-history
However, this can lead to argument list too long errors when the
original
repository has many retained branches (6k)
/usr/local/git/libexec/git-core/git-filter-branch: line 270:
/usr/local/git/libexec/git-core/git: Argument list too long
Could not get the commits
Piping the saved output from git rev-parse into git rev-list avoids this
problem, since the rev-parse output is not processed as a command line
argument.
---
git-filter-branch.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ac2a005..2091885 100755
--- a/git-filter-branch.shgit
+++ b/git-filter-branch.sh
@@ -255,7 +255,7 @@ else
remap_to_ancestor=t
fi
-rev_args=$(git rev-parse --revs-only $@)
+git rev-parse --revs-only $@ ../parse
Where is this rev-parse command running? Is it always safe to
clobber the file ../parse like this?
It is using the same ${tempdir} working directory that git rev-list uses
below for the ../revs file
It's normally .git-rewrite/t, following the normal working directory setup
near line 205.
case $filter_subdir in
)
@@ -268,7 +268,7 @@ case $filter_subdir in
esac
git rev-list --reverse --topo-order --default HEAD \
---parents --simplify-merges $rev_args $@ ../revs ||
+--parents --simplify-merges --stdin $@ ../parse ../revs ||
die Could not get the commits
commits=$(wc -l ../revs | tr -d )
--
To unsubscribe from this list: send the line 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 3/3] MSVC: fix stat definition hell
On Tue, Sep 10, 2013 at 7:23 PM, Karsten Blees karsten.bl...@gmail.com wrote: In msvc.h, there's a couple of stat related functions defined diffently s/diffently/differently/ from mingw.h. When we remove these definitions, the only problem we get is warning C4005: '_stati64' : macro redefinition for this line in mingw.h: #define _stati64(x,y) mingw_stat(x,y) The reason is that as of MSVCR80.dll (distributed with MSVC 2005), the original _stati64 family of functions was renamed to _stat32i64, and the former function names became macros (pointing to the appropriate function based on the definition of _USE_32BIT_TIME_T). Defining _stati64 works on MinGW because MinGW by default compiles against the MSVCRT.DLL that is part of Windows (i.e. _stati64 is a function rather than a macro). Note: MinGW *can* compile for newer MSVC runtime versions, and MSVC apparently can also compile for the Windows MSVCRT.DLL via the DDK (see http://www.syndicateofideas.com/posts/fighting-the-msvcrt-dll-hell ). Remove the stat definitions from msvc.h, as they are not compiler related. In mingw.h, determine the runtime version in use from the definitions of _stati64 and _USE_32BIT_TIME_T, and define stat() accordingly. This also fixes that stat() in MSVC builds still resolves to mingw_lstat() instead of mingw_stat(). Signed-off-by: Karsten Blees bl...@dcon.de -- To unsubscribe from this list: send the line 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: push.default=upstream doesn't play nicely with remote.pushdefault/branch.*.pushremote
On Tue, Sep 10, 2013 at 8:10 AM, Ximin Luo infini...@gmx.com wrote: (Please CC me as I am not subscribed.) No need to say that, Git mailing list is sane and doesn't do reply-to munging. The question here then is, what remote branch should git push to - since pushremote only specifies a repo? I can suggest two options: - A: push to branch.*.merge if it's defined; otherwise push to current branch (like push.default=current) - B: push to current branch regardless Or C: introduce the concept of a publish branch to complement pushremote: http://article.gmane.org/gmane.comp.version-control.git/233572 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] http-backend: provide Allow header for 405
On Sun, Sep 08, 2013 at 09:18:12PM -0700, Jonathan Nieder wrote:
--- a/http-backend.c
+++ b/http-backend.c
@@ -594,8 +594,11 @@ int main(int argc, char **argv)
if (strcmp(method, c-method)) {
const char *proto = getenv(SERVER_PROTOCOL);
- if (proto !strcmp(proto, HTTP/1.1))
+ if (proto !strcmp(proto, HTTP/1.1)) {
http_status(405, Method Not Allowed);
+ hdr_str(Allow, !strcmp(GET,
c-method) ?
+ GET, HEAD : c-method);
+ }
else
Small style nit: the closing brace should go on the same line as the
else, like so:
if (proto ...) {
...
} else
http_status(400, Bad Request);
Another micronit: the comparison should be !strcmp(c-method, GET)
--- variable first, then constant it is being compared to.
The functional change looks good.
I plan on doing a reroll tomorrow.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
signature.asc
Description: Digital signature
[PATCH] Documentation/git-checkout: Move `--detach` flag in synopsis to correct command
From a33659535cb0eac92bed42d5e494dbb8f5d9ab20 Mon Sep 17 00:00:00 2001 From: Benjamin Bergman b...@benbergman.ca Date: Tue, 10 Sep 2013 16:00:29 -0500 Subject: [PATCH] Documentation/git-checkout: Move `--detach` flag in synopsis to correct command Detailed description of `--detach` states that it is default for `commit` but needs to be specified for `branch`. The old man page synopsis showed the reverse. --- Documentation/git-checkout.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index ca118ac..dee95e8 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -8,8 +8,8 @@ git-checkout - Checkout a branch or paths to the working tree SYNOPSIS [verse] -'git checkout' [-q] [-f] [-m] [branch] -'git checkout' [-q] [-f] [-m] [--detach] [commit] +'git checkout' [-q] [-f] [-m] [--detach] [branch] +'git checkout' [-q] [-f] [-m] [commit] 'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] new_branch] [start_point] 'git checkout' [-f|--ours|--theirs|-m|--conflict=style] [tree-ish] [--] paths... 'git checkout' [-p|--patch] [tree-ish] [--] [paths...] -- 1.8.3.4 -- To unsubscribe from this list: send the line 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: Regression in e02ca72: git svn rebase is broken on Windows
2013/9/11 Junio C Hamano gits...@pobox.com:
Tvangeste i.4m.l...@yandex.ru writes:
Hi,
After bisecting this problem I ended up with the mentioned commit that
completely breaks git-svn for me on Windows (mingw/msys version).
==
# git svn rebase
warning: unable to access '': Invalid argument
warning: unable to access '': Invalid argument
fatal: unable to access '../../../../w:/work/my/repo.git/.git/config':
Invalid argument
fatal: index file open failed: Invalid argument
Cannot rebase: You have unstaged changes.
Please commit or stash them.
rebase refs/remotes/trunk: command returned error: 1
==
Please note that I use the official git repository as-is, this one (no
additional patches):
git://git.kernel.org/pub/scm/git/git.git
e02ca72f70ed8f0268a81f72cb3230c72e538e77 is the first bad commit
commit e02ca72f70ed8f0268a81f72cb3230c72e538e77
Author: Jiang Xin
Date: Tue Jun 25 23:53:43 2013 +0800
path.c: refactor relative_path(), not only strip prefix
Thanks,
--Tvangeste
The suspect commit and symptom look consistent. You started from a
directory whose absolute path is w:/work/... and the updated code
mistakenly thoguht that something that begins with w (not '/') is
not an absolute, so added a series of ../ to make it relative, or
something silly like that.
Jiang?
I tested 'relative_path' function using 'test-path-utils', and got the
following result:
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
../../../C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
../..//a/b
$ ./test-path-utils relative_path 'a/b' '/x/y'
../../../a/b
For the first case, in and prefix are on different ROOT, and for the other
two cases, one path is a relative path, and another is an absolute path.
I write a patch to test whether two paths (in and prefix) have the same
root. The result after applied the patch:
$ ./test-path-utils relative_path 'C:/a/b' 'C:/x/y'
../../a/b
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
/a/b
$ ./test-path-utils relative_path 'a/b' '/x/y'
a/b
diff --git a/path.c b/path.c
index 7f3324a..51f5d28 100644
--- a/path.c
+++ b/path.c
@@ -441,6 +441,25 @@ int adjust_shared_perm(const char *path)
return 0;
}
+static int have_same_root(const char *path1, const char *path2)
+{
+ /* for POSIX:
+
+ return ((path1 is_dir_sep(*path1)) ^
+ (path2 is_dir_sep(*path2))) == 0;
+ */
+ return path1 path2 *path1 *path2 (
+ (is_dir_sep(*path1)
+is_dir_sep(*path2)) ||
+ (*(path1+1) == ':'
+*(path2+1) == ':'
+!strncasecmp(path1, path2, 1)) ||
+ (!is_dir_sep(*path1)
+!is_dir_sep(*path2)
+*(path1+1) != ':'
+*(path2+1) != ':'));
+}
+
/*
* Give path as relative to prefix.
*
@@ -461,6 +480,9 @@ const char *relative_path(const char *in, const
char *prefix,
else if (!prefix_len)
return in;
+ if (!have_same_root(in, prefix))
+ return in;
+
Should I write the function have_same_root as inline function or macro
like 'is_dir_sep'?
--
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: Regression in e02ca72: git svn rebase is broken on Windows
2013/9/11 Karsten Blees karsten.bl...@gmail.com: Junio C Hamano gitster at pobox.com writes: The suspect commit and symptom look consistent. You started from a directory whose absolute path is w:/work/... and the updated code mistakenly thoguht that something that begins with w (not '/') is not an absolute, so added a series of ../ to make it relative, or something silly like that. Jiang? Indeed, this patch seems to change relative_path in a way that breaks git initialization, not just on Windows. Previously, relative_path was always called with two absolute paths, and it only returned a relative path if the first was a subdir of the second (so a better name would probably have been 'relative_path_if_subdir'). The purpose was to improve performance by making GIT_DIR shorter if it was a subdir of GIT_WORK_TREE. Yes, it's what commit v1.5.6-1-g044bbbc says. After this patch, relative_path always tries to return a relative path, even if both absolute paths are completely disjunct. This not only defeats the purpose (by making GIT_DIR longer, thus hurting performance), it is also not Sometimes longer, sometimes shorter maybe. possible in general. POSIX explicitly allows for '//hostname' notation referring to network resources that are not explicitly mounted under '/'. I.e. given two absolute paths '//hostname1/a' and '//hostname2/b', there is no relative path from a to b or vice versa. Yes, path like //hostname/path can be used on Windows. My hack have_same_root does not cover this case, so using a simple_relative_path function instead of relative_path in setup.c may be the better. -- 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: Regression in e02ca72: git svn rebase is broken on Windows
Am 11.09.2013 05:19, schrieb Jiang Xin:
I tested 'relative_path' function using 'test-path-utils', and got the
following result:
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
../../../C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
../..//a/b
$ ./test-path-utils relative_path 'a/b' '/x/y'
../../../a/b
For the first case, in and prefix are on different ROOT, and for the other
two cases, one path is a relative path, and another is an absolute path.
I write a patch to test whether two paths (in and prefix) have the same
root. The result after applied the patch:
$ ./test-path-utils relative_path 'C:/a/b' 'C:/x/y'
../../a/b
$ ./test-path-utils relative_path 'C:/a/b' 'D:/x/y'
C:/a/b
$ ./test-path-utils relative_path '/a/b' 'x/y'
/a/b
$ ./test-path-utils relative_path 'a/b' '/x/y'
a/b
diff --git a/path.c b/path.c
index 7f3324a..51f5d28 100644
--- a/path.c
+++ b/path.c
@@ -441,6 +441,25 @@ int adjust_shared_perm(const char *path)
return 0;
}
+static int have_same_root(const char *path1, const char *path2)
+{
+ /* for POSIX:
+
+ return ((path1 is_dir_sep(*path1)) ^
+ (path2 is_dir_sep(*path2))) == 0;
+ */
+ return path1 path2 *path1 *path2 (
+ (is_dir_sep(*path1)
+is_dir_sep(*path2)) ||
+ (*(path1+1) == ':'
+*(path2+1) == ':'
+!strncasecmp(path1, path2, 1)) ||
+ (!is_dir_sep(*path1)
+!is_dir_sep(*path2)
+*(path1+1) != ':'
+*(path2+1) != ':'));
I think this can be simplified to
return path1 path2
is_absolute_path(path1)
is_absolute_path(path2)
!strncasecmp(path1, path2, 1);
which would not mistake a path D:/foo on Unix as an absolute path.
+}
-- Hannes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
