Re: Having Git follow symlinks
Matthieu Moy: One option is to have the symlink in the other direction: make /etc/foo a symlink to $GIT_WORKTREE/foo and version the later. I do that for the software that supports it, but ssh, for instance, is very picky that ~/.ssh is a directory and such. And at least one of the other files I version-control will be unlinked and overwritten in such a way that that does not work. I could split the repo up (that seems to be what vcsh is doing) and check the parts out in the corresponding directories, but I do like the idea of having one single repo. Oh, well, if I have the time, maybe I can come up with a patch. There is already some hacks in the core.symlinks setting, so I guess it should be possible. -- \\// Peter - http://www.softwolves.pp.se/ -- To unsubscribe from this list: send the line 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 PULL] l10n updates for 1.9 round 1
Hi, Junio Please merge the following updates on l10n, and after your merge another round of l10n will start in order to translate one extra message introduced by commit b861e23 (repack: propagate pack-objects options as strings). The following changes since commit 79fcbf7e703ca5805ebd46b2c7e09d0703f1c1ff: Git 1.9-rc0 (2014-01-17 12:30:14 -0800) are available in the git repository at: git://github.com/git-l10n/git-po master for you to fetch changes up to 25e2fbb4e2d99f2f1e04f0ae2588ab8396217ee4: l10n: Bulgarian translation of git (222t21f1967u) (2014-01-29 14:29:15 +0200) Alexander Shopov (2): po/TEAMS: Added Bulgarian team l10n: Bulgarian translation of git (222t21f1967u) Jean-Noel Avila (1): [fr] update french translation 2210/2210 Jiang Xin (4): l10n: git.pot: v1.9 round 1 (27 new, 11 removed) Merge branch 'fr-po' of git://github.com/jnavila/git l10n: zh_CN.po: translate 27 messages (2210t0f0u) l10n: remove 2 blank translations on Danish, Dutch Peter Krefting (1): l10n: Update Swedish translation (2210t0f0u) Tran Ngoc Quan (1): l10n: vi.po (2210t): Updated git-core translation po/TEAMS|10 +- po/bg.po| 10404 ++ po/da.po| 3503 po/fr.po| 1807 +- po/git.pot | 1704 +- po/nl.po| 3493 po/sv.po| 1759 +- po/vi.po| 2389 +++--- po/zh_CN.po | 1809 +- 9 files changed, 15408 insertions(+), 11470 deletions(-) create mode 100644 po/bg.po delete mode 100644 po/da.po delete mode 100644 po/nl.po -- 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
A few contributor's questions
I'm still in the process of finishing the rewrite of the builtin/blame.c internals. Now there are various questions regarding the final patch proposals and commit messages. Point 1) signing off implies that I'm fine with the licensing of the file. builtin/blame.c merely states /* * Blame * * Copyright (c) 2006, Junio C Hamano */ which obviously will not match the authorship of my contributions. Since Junio has given blanket permission to reuse his Git contributions under other licenses (see URL:https://github.com/libgit2/libgit2/blob/development/git.git-authors#L58) that I am not going to license my work under, the first commit in the respective series would replace this header with /* * Blame * * Copyright (c) 2006--2014, Junio C Hamano and others * Licensed under GPLv2. See Git's COPYING file for details. */ That should be reasonably accurate boilerplate, I think, and should avoid code from multiple authors to be erroneously assumed subjected to agreements other than the default Git project licensing. Which brings us to further nitty-gritty details. Personally, I'm fine with permitting licensing contributions of mine under GPLv2 or later. Is there any clearing house where I can have this sentiment recorded in a manner where potential heirs (which according to copyright law will retain control over my works even when born after my demise, so I cannot in good conscience vouch for their common sense) cannot contest it? Like putting Permissable-Licenses: GPL Version 2 or later in the commit message? And finally, the ugly: I don't have any income apart from volunteers paying me for writing Free Software, so a contribution like this one, having taken substantial time, will make for a rather tepid report of my GNU LilyPond activities in January and a corresponding slackening of volunteer payments for what I could have been doing instead. It's not the first performance shortcoming of Git I have worked on. In contrast to most other contributors, I won't be able to afford following a whim for addressing such deficiencies in future without a chance for recouping my losses. My experience with GNU LilyPond has led me to conclude that the best chance of getting voluntary payments is to appeal to those who are most invested in the well-being of the software. It's a sad reality that they tend to be identical to those who are already investing substantial amounts of time and effort into the project themselves. So I'll put the respective begging notice into the cover letter of the patch series: I don't think it belongs in the commit messages, and it's not likely to be effective anyway. While I could put a Prepaid-by: footer into the commit messages, the main effect would likely be to trigger the somebody else's problem effect. My experience with this kind of polite notice is that it's good for the equivalent of a case of beer every ten years. If the performance enhancements are mentioned in a release announcement, adding a notice along the line The performance of git blame has been significantly improved by David Kastrup d...@gnu.org. If this affects you, consider contributing to his reimbursement. would of course also be welcome. Ok, this should be about covering the bad and the ugly. I'm still working on the -C and -M replacements given the new code. Hopefully finished this weekend. All the best -- David Kastrup -- To unsubscribe from this list: send the line 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: Having Git follow symlinks
On 01/31/2014 04:56 AM, Peter Krefting wrote: Matthieu Moy: One option is to have the symlink in the other direction: make /etc/foo a symlink to $GIT_WORKTREE/foo and version the later. I do that for the software that supports it, but ssh, for instance, is very picky that ~/.ssh is a directory and such. And at least one of the other files I version-control will be unlinked and overwritten in such a way that that does not work. I could split the repo up (that seems to be what vcsh is doing) and check the parts out in the corresponding directories, but I do like the idea of having one single repo. Oh, well, if I have the time, maybe I can come up with a patch. There is already some hacks in the core.symlinks setting, so I guess it should be possible. This is now unrelated to Git, but I have .ssh symlinked to a version-controlled directory on all of my machines (Kubuntu 13.10, 14.04, and recent Gentoo systems, but I've also done this on CentOS 5 and 6). SSH doesn't care whether ~/.ssh is a symlink, but it *does* //care about permissions: mruffalo@giygas:~$ ls -ld .ssh lrwxrwxrwx 1 mruffalo mruffalo 13 Mar 17 2013 .ssh - .home-git/ssh mruffalo@giygas:~$ ls -ld .home-git drwx-- 1 mruffalo mruffalo 116 Dec 8 01:26 .home-git If .home-git is mode 0755, SSH may refuse to use any private keys that it finds, though I was unable to reproduce this with a few quick tests. MMR... -- To unsubscribe from this list: send the line 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 pull does no longer work due to a Cr-Lf issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Ick, today I run again into a problem with the git tree of the BOINC project: http://boinc.berkeley.edu/git/boinc-v2.git A git pull won't work any longer due to: $ git pull Updating 089459d..01f0ead error: Your local changes to the following files would be overwritten by merge: lib/boinc_win.h Please, commit your changes or stash them before you can merge. Aborting A git diff gave : diff --git a/lib/boinc_win.h b/lib/boinc_win.h index 0676372..4c62ed5 100644 - --- a/lib/boinc_win.h +++ b/lib/boinc_win.h @@ -137,7 +137,7 @@ typedef size_t socklen_t; #include stdint.h #include imagehlp.h #else - -#include security.h +#include security.h #include dbghelp.h #endif #include tlhelp32.h which pointed me to a ^M in line 137 of that file. I removed that ^M, but a pull still wonät work. Then I removed the file and checked it out again - no chance, git pull always fails with the same massage. Finally I tried : $ git stash warning: CRLF will be replaced by LF in lib/boinc_win.h. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in lib/boinc_win.h. The file will have its original line endings in your working directory. Saved working directory and index state WIP on master: 089459d locale: Update compiled localization files HEAD is now at 089459d locale: Update compiled localization files but again I run into : $ git pull Updating 089459d..01f0ead error: Your local changes to the following files would be overwritten by merge: lib/boinc_win.h Please, commit your changes or stash them before you can merge. Aborting /me wonders how to solve this w/o cloning the complete repo again. - -- MfG/Sincerely Toralf Förster pgp finger print:1A37 6F99 4A9D 026F 13E2 4DCF C4EA CDDE 0076 E94E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREIAAYFAlLrutIACgkQxOrN3gB26U5ZHwD/eGEr4hR+F5TVP7m0/JO6Km+j VN6ak30WMPK8Fe9pWHYBAIWD4EDIspHUkNfq76Vakc6uNaLVne8MFiikniH7WjhL =xwGS -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] diff: turn skip_stat_unmatch on selectively
Duy Nguyen pclo...@gmail.com writes: On Thu, Jan 30, 2014 at 2:25 AM, Junio C Hamano gits...@pobox.com wrote: On Tue, Jan 28, 2014 at 02:51:45PM -0800, Junio C Hamano wrote: This however shows that the existing test *KNEW* that it was enough to check just a few cases (especially, there is no reason to make sure that blob vs file-in-working-tree case behaves sanely), because the auto-refresh would kick in for all codepaths. Now you are making that assumption invalid, shouldn't the patch also split the tests to cover individual cases? Drop the last patch, then. It's a while at there cleanup patch. If it's non trivial then it could be taken up later... I am leaning towards that because... ... not sure I'll go through diff.c to identify and write tests for all cases. ... the effort to ensure the correctness of the patch itself involves the same identification of the cases. We know the single place skip-stat-unmatch was assigned used to cover all cases, and the patch was to stop covering cases the unnecessary assignments are made while making sure the resulting code still covers cases that assignments are necessary. -- To unsubscribe from this list: send the line 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: A few contributor's questions
Hi, David Kastrup wrote: builtin/blame.c merely states /* * Blame * * Copyright (c) 2006, Junio C Hamano */ I think you planned to make substantial changes, so /* * Blame * * Copyright (c) 2006--2014, Junio C Hamano and others * Licensed under GPLv2. See Git's COPYING file for details. */ towards the end of the series (or squashed into some patch that makes significant changes) looks fine to me. Also keep in mind that you don't need a copyright notice to own copyright, that it would be crazy for someone to claim you've assigned copyright on your changes without an explicit reassignment, and that libgit2's git.git-authors file that keeps coming up includes a comment with a heuristic for delving into the history to find the authors of some code. [...] Permissable-Licenses: GPL Version 2 or later Wouldn't a signed message on your website or some other public place (e.g., the mailing list) do the trick? Or a sentence in a commit message saying I'd be happy to have these changes relicensed under the GPL version 2 or later. sounds fine to me, at least. Thanks and hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 04/17] trailer: process command line trailer arguments
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This patch parses the trailer command line arguments
and put the result into an arg_tok doubly linked
list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
diff --git a/trailer.c b/trailer.c
index d979a0f..f48fd94 100644
--- a/trailer.c
+++ b/trailer.c
@@ -362,3 +362,80 @@ static int git_trailer_config(const char *conf_key,
const char *value, void *cb)
}
return 0;
}
+
+static void parse_trailer(struct strbuf *tok, struct strbuf *val, const char
*trailer)
+{
+ char *end = strchr(trailer, '=');
This can be 'const char *'.
+ if (!end)
+ end = strchr(trailer, ':');
+ if (end) {
+ strbuf_add(tok, trailer, end - trailer);
+ strbuf_trim(tok);
+ strbuf_addstr(val, end + 1);
+ strbuf_trim(val);
+ } else {
+ strbuf_addstr(tok, trailer);
+ strbuf_trim(tok);
+ }
+}
+
+static struct trailer_item *create_trailer_item(const char *string)
+{
+ struct strbuf tok = STRBUF_INIT;
+ struct strbuf val = STRBUF_INIT;
+ struct trailer_item *new;
+ struct trailer_item *item;
+ int tok_alnum_len;
+
+ parse_trailer(tok, val, string);
+
+ tok_alnum_len = alnum_len(tok.buf, tok.len);
+
+ /* Lookup if the token matches something in the config */
+ for (item = first_conf_item; item; item = item-next) {
+ if (!strncasecmp(tok.buf, item-conf-key, tok_alnum_len) ||
+ !strncasecmp(tok.buf, item-conf-name, tok_alnum_len)) {
+ new = xcalloc(sizeof(struct trailer_item), 1);
sizeof(*new) would be more future-proof.
+ new-conf = item-conf;
+ new-token = xstrdup(item-conf-key);
+ new-value = strbuf_detach(val, NULL);
+ strbuf_release(tok);
+ return new;
+ }
+ }
+
+ new = xcalloc(sizeof(struct trailer_item), 1);
Ditto.
+ new-conf = xcalloc(sizeof(struct conf_info), 1);
+ new-token = strbuf_detach(tok, NULL);
+ new-value = strbuf_detach(val, NULL);
+
+ return new;
+}
--
To unsubscribe from this list: send the line 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 v4 06/17] trailer: parse trailers from input file
On Thu, Jan 30, 2014 at 1:49 AM, Christian Couder
chrisc...@tuxfamily.org wrote:
This patch reads trailers from an input file, parses
them and puts the result into a doubly linked list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
trailer.c | 62 ++
1 file changed, 62 insertions(+)
diff --git a/trailer.c b/trailer.c
index f48fd94..084b3e1 100644
--- a/trailer.c
+++ b/trailer.c
@@ -439,3 +439,65 @@ static struct trailer_item
*process_command_line_args(int argc, const char **arg
+static void process_input_file(const char *infile,
+ struct trailer_item **infile_tok_first,
+ struct trailer_item **infile_tok_last)
+{
+ struct strbuf **lines = read_input_file(infile);
+ int start = find_trailer_start(lines);
+ int i;
+
+ /* Print non trailer lines as is */
+ for (i = 0; lines[i] i start; i++) {
+ printf(%s, lines[i]-buf);
+ }
+
+ /* Parse trailer lines */
+ for (i = start; lines[i]; i++) {
+ struct trailer_item *new = create_trailer_item(lines[i]-buf);
+ add_trailer_item(infile_tok_first, infile_tok_last, new);
Leaking 'lines'. Perhaps you want to invoke strbuf_list_free() here.
+ }
+}
--
1.8.5.2.201.gacc5987
--
To unsubscribe from this list: send the line 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: A few contributor's questions
Jonathan Nieder jrnie...@gmail.com writes: Also keep in mind that you don't need a copyright notice to own copyright, that it would be crazy for someone to claim you've assigned copyright on your changes without an explicit reassignment, Not at all crazy: Documentation/SubmittingPatches states that adding a Signed-off-by: footer to a commit among other things constitutes agreement to Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or The only relevant notice to licensing indicated in the file currently is Copyright (c) 2006 by Junio Hamano. Also whether or not this implies an assignment of copyright, it is a reasonable assumption for people working with a copy of Git distributed by tar file or otherwise that a file with such a copyright notice only contains material copyrighted by Junio Hamano. So if I want to assert my copyright in the case of licensing breaches, the party in breach may claim estoppel by me hiding material copyrighted by myself in a file with such a notice. and that libgit2's git.git-authors file that keeps coming up includes a comment with a heuristic for delving into the history to find the authors of some code. Sure. But that does not mean that this is the only means to reasonably infer the authorship of a file. [...] Permissable-Licenses: GPL Version 2 or later Wouldn't a signed message on your website or some other public place (e.g., the mailing list) do the trick? Legally? Sure. The whole point of such a notice in the commit message (or in some central file in the Git repository) is to save people the hassle of second-guessing or sleuthing for every single contribution. Or a sentence in a commit message saying I'd be happy to have these changes relicensed under the GPL version 2 or later. sounds fine to me, at least. It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. If it's going to be per-commit, a footer line would be less obtrusive than a whole sentence. But it would seem that there's no rule/standard here. Thanks -- David Kastrup -- To unsubscribe from this list: send the line 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 jn/pager-lv-default-env] pager test: make fake pager consume all its input
Jonathan Nieder jrnie...@gmail.com writes: Otherwise there is a race: if 'git log' finishes writing before the pager terminates and closes the pipe, all is well, and if the pager finishes quickly enough then 'git log' terminates with SIGPIPE. died of signal 13 at /build/buildd/git-1.9~rc1/t/test-terminal.perl line 33. not ok 6 - LESS and LV envvars are set for pagination Noticed on Ubuntu PPA builders, where the race was lost about half the time. Compare v1.7.0.2~6^2 (tests: Fix race condition in t7006-pager, 2010-02-22). Reported-by: Anders Kaseorg ande...@mit.edu Signed-off-by: Jonathan Nieder jrnie...@gmail.com --- Thanks. The use of wc looks cute (I would have used cat). Anders Kaseorg wrote: On 01/06/2014 09:14 PM, Jonathan Nieder wrote: + PAGER=env pager-env.out + export PAGER + + test_terminal git log [...] On the Ubuntu PPA builders, I’m seeing this new test fail with SIGPIPE about half the time: died of signal 13 at /build/buildd/git-1.9~rc1/t/test-terminal.perl line 33. not ok 6 - LESS and LV envvars are set for pagination Good catch. Sorry for the trouble. t/t7006-pager.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t7006-pager.sh b/t/t7006-pager.sh index 7fe3367..b9365b4 100755 --- a/t/t7006-pager.sh +++ b/t/t7006-pager.sh @@ -40,7 +40,7 @@ test_expect_failure TTY 'pager runs from subdir' ' test_expect_success TTY 'LESS and LV envvars are set for pagination' ' ( sane_unset LESS LV - PAGER=env pager-env.out + PAGER=env pager-env.out; wc export PAGER test_terminal git log -- To unsubscribe from this list: send the line 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: Having Git follow symlinks
Peter Krefting pe...@softwolves.pp.se writes: ...if I have the time, maybe I can come up with a patch. There is already some hacks in the core.symlinks setting, so I guess it should be possible. That is totally unrelated. The variable only says on this platform and/or filesystem, you cannot symlink(2), so instead create a regular file with the symlink contents when checking out a symlink blob. Most importantly, the variable does not change the fact that symbolic links are explicitly tracked without dereferencing. If you have, under a directory foo/, a symbolic link foo/bar that points at ../baz, a directory foo/baz/, and you have a file at foo/baz/hello: 1. git add foo and git add foo/bar will add foo/bar as a symlink; and 2. git add foo/bar/hello is an error. The variable does not have any interactions with the logic to make sure 2. errors out correctly, so the presense of it does not imply anything. -- To unsubscribe from this list: send the line 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] Cleanly redefine (v)snprintf when needed.
Benoit Sigoure tsuna...@gmail.com writes: When we detect that vsnprintf / snprintf are broken, we #define them to an alternative implementation. On OS X, stdio.h already #define's them, which causes a warning to be issued at the point we re-define them in `git-compat-util.h'. --- Makes perfect sense. Please sign-off your patch (see Documentation/SubmittingPatches). Thanks. git-compat-util.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index cbd86c3..614a5e9 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -480,9 +480,15 @@ extern FILE *git_fopen(const char*, const char*); #endif #ifdef SNPRINTF_RETURNS_BOGUS +#ifdef snprintf +#undef snprintf +#endif #define snprintf git_snprintf extern int git_snprintf(char *str, size_t maxsize, const char *format, ...); +#ifdef vsnprintf +#undef vsnprintf +#endif #define vsnprintf git_vsnprintf extern int git_vsnprintf(char *str, size_t maxsize, const char *format, va_list ap); -- To unsubscribe from this list: send the line 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] Cleanly redefine (v)snprintf when needed.
When we detect that vsnprintf / snprintf are broken, we #define them to an alternative implementation. On OS X, stdio.h already #define's them, which causes a warning to be issued at the point we re-define them in `git-compat-util.h'. Signed-off-by: Benoit Sigoure tsuna...@gmail.com --- git-compat-util.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index cbd86c3..614a5e9 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -480,9 +480,15 @@ extern FILE *git_fopen(const char*, const char*); #endif #ifdef SNPRINTF_RETURNS_BOGUS +#ifdef snprintf +#undef snprintf +#endif #define snprintf git_snprintf extern int git_snprintf(char *str, size_t maxsize, const char *format, ...); +#ifdef vsnprintf +#undef vsnprintf +#endif #define vsnprintf git_vsnprintf extern int git_vsnprintf(char *str, size_t maxsize, const char *format, va_list ap); -- 1.9.rc1.1.g186f0be.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git variable expansion when pulling ?
Hi , I’ve just setup a variable expansion scheme via the attribues filters for our versioning purposes. I do realise there is much debate on whether to do this or not but it is an indispensable part for our code. However i just realised the filters are not executed if we update the code via a pull command and the file with the metadata is not modified . Is there a correct way to have the filter execute even for a pull and update the Git sha1 info in our log file ? Thanks Gabriel -- To unsubscribe from this list: send the line 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: Having Git follow symlinks
Peter Krefting pe...@softwolves.pp.se writes: Oh, well, if I have the time, maybe I can come up with a patch. There is already some hacks in the core.symlinks setting, so I guess it should be possible. I'd love to have a way to follow symlinks, but this needs to be done with care: when following symlinks, writing to a link may mean writing outside the Git repository, which brings some security concerns. Not that following symlinks has to be insecure, but we'd have to make sure that it does not allow a malicious user to e.g. setup a symlink to ~/.bashrc and then write to it. -- 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] add: don't complain when adding empty project root
Torsten Bögershausen tbo...@web.de writes: But, look at https://www.kernel.org/pub/software/scm/git/docs/git-add.html This page seems to need an update too, and I wonder why: a) The makefile did'nt re-generate html even if it should have b) That page is not owned or updated by the git.git maintainer c) Any other reason? Sorry, but if I understand correctly, k.org these days requires each file to be GPG signed and uploaded individually (i.e. there is no way as far as I can tell to say here is a tarball, and I've even signed it with my key to convince you that it is from me. Please accept it and then unpack the contents there). There is no way I'd do that every time I update git-htmldocs repository for 500+ files. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: A few contributor's questions
Hi, David Kastrup wrote: Also whether or not this implies an assignment of copyright, it is a reasonable assumption for [...] Since I think we've completely gone off the rails: I assume the problem you're trying to solve is that files don't have clear enough notices of their licensing. That could be a real problem for people using the code, since if you no one gave you a license then you don't have a license at all. It's also a problem in that it makes it harder to interpret the phrase under the same open source license (though I have no idea how that could be read as I give up my copyright completely). The way git currently works in that area is the same as the Linux kernel: * the code is copyright by the authors and we try not to waste fuss on maintaining a comprehensive list in notices. If you want to find the authors to negotiate special licensing, you get to do the work. * license is GPLv2-only where not otherwise specified * relicensing, when needed, happens by contacting all the copyright holders and getting their consent I don't see anything weird about that. But people using the code might like clearer notices, so I personally would not mind an extra line in most files stating the license. (More than that and it becomes absurd.) That's all just my opinion --- Junio might think differently, etc. [...] It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. For relicensing the existing practice is to just contact people. That has the advantage that I can make a decision about whether to allow relicensing code I've written in the context of how I expect it to be used. I expect that if you had a stance on GPLv2+ licensing of contributions to git published in some place easily found by search engines (for example a message on the mailing list), interested people would not have too much trouble finding it when the time comes. Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/4] setup: Add 'abspath_part_inside_repo' function
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which incrementally checks
each path level by temporarily NUL-terminating at each '/' and comparing
against the work tree path. When a match is found, it copies the
remainder (which will be the in-repo part) to a destination
buffer.
The path being the filesystem root or exactly equal to the work tree are
special cases handled separately, since then there is no directory
separator between the work tree and in-repo part.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
---
cache.h | 1 +
setup.c | 63 +++
2 files changed, 64 insertions(+)
diff --git a/cache.h b/cache.h
index ce377e1..242f27d 100644
--- a/cache.h
+++ b/cache.h
@@ -426,6 +426,7 @@ extern void verify_filename(const char *prefix,
int diagnose_misspelt_rev);
extern void verify_non_filename(const char *prefix, const char *name);
extern int path_inside_repo(const char *prefix, const char *path);
+extern int abspath_part_inside_repo(char *dst, const char *path);
#define INIT_DB_QUIET 0x0001
diff --git a/setup.c b/setup.c
index 5432a31..e606846 100644
--- a/setup.c
+++ b/setup.c
@@ -77,6 +77,69 @@ int path_inside_repo(const char *prefix, const char *path)
return 0;
}
+/*
+ * It is ok if dst == src, but they should not overlap otherwise.
+ * No checking if the path is in fact an absolute path is done, and it must
+ * already be normalized.
+ *
+ * Find the part of an absolute path that lies inside the work tree by
+ * dereferencing symlinks outside the work tree, for example:
+ * /dir1/repo/dir2/file (work tree is /dir1/repo) - dir2/file
+ * /dir/file (work tree is /) - dir/file
+ * /dir/symlink1/symlink2 (symlink1 points to work tree) - symlink2
+ * /dir/repo (exactly equal to work tree) - (empty string)
+ */
+int abspath_part_inside_repo(char *dst, const char* src)
+{
+ size_t len;
+ char *dst0;
+ char temp;
+
+ const char* work_tree = get_git_work_tree();
+ if (!work_tree)
+ return -1;
+ len = strlen(src);
+ dst0 = dst;
+
+ // check root level
+ if (has_dos_drive_prefix(src)) {
+ *dst++ = *src++;
+ *dst++ = *src++;
+ *dst++ = *src++;
+ } else {
+ *dst++ = *src++;
+ }
+ temp = *dst;
+ *dst = '\0';
+ if (strcmp(real_path(dst0), work_tree) == 0) {
+ *dst = temp;
+ memmove(dst0, src, len - (dst - dst0) + 1);
+ return 0;
+ }
+ *dst = temp;
+
+ // check each level
+ while (*dst != '\0') {
+ *dst++ = *src++;
+ if (*dst == '/') {
+ *dst = '\0';
+ if (strcmp(real_path(dst0), work_tree) == 0) {
+ memmove(dst0, src + 1, len - (dst - dst0));
+ return 0;
+ }
+ *dst = '/';
+ }
+ }
+
+ // check whole path
+ if (strcmp(real_path(dst0), work_tree) == 0) {
+ *dst0 = '\0';
+ return 0;
+ }
+
+ return -1;
+}
+
int check_filename(const char *prefix, const char *arg)
{
const char *name;
--
1.8.5.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 v3 1/4] t0060: Add test for manipulating symlinks via absolute paths
When symlinks in the working tree are manipulated using the absolute path, git dereferences them, and tries to manipulate the link target instead. This is a regression introduced by 18e051a: setup: translate symlinks in filename when using absolute paths (which did not take symlinks in the work tree into consideration). Add a known-breakage tests using the prefix_path function, which currently uses real_path, causing the dereference. Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com --- t/t0060-path-utils.sh | 5 + 1 file changed, 5 insertions(+) diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh index 07c10c8..0bba988 100755 --- a/t/t0060-path-utils.sh +++ b/t/t0060-path-utils.sh @@ -190,6 +190,11 @@ test_expect_success SYMLINKS 'real path works on symlinks' ' test $sym = $(test-path-utils real_path $dir2/syml) ' +test_expect_failure SYMLINKS 'prefix_path works with absolute paths to work tree symlinks' ' + ln -s target symlink + test $(test-path-utils prefix_path prefix $(pwd)/symlink) = symlink +' + relative_path /foo/a/b/c/ /foo/a/b/ c/ relative_path /foo/a/b/c/ /foo/a/bc/ relative_path /foo/a//b//c////foo/a/b//c/ POSIX -- 1.8.5.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 v3 4/4] setup: Don't dereference in-tree symlinks for absolute paths
The 'prefix_path_gently' function currently applies real_path to
everything if given an absolute path, dereferencing symlinks both
outside and inside the work tree. In order to manipulate symlinks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
Modify the 'prefix_path_gently' to first normalize the path in order to
make sure path levels are separated by '/', then pass the result to
'abspath_part_inside_repo' to find the in-repo part (without dereferencing
any symlinks inside the work tree).
For absolute paths, 'prefix_path_gently' did not, nor does now do, any
actual prefixing, hence the result from 'abspath_part_in_repo' is
returned as-is.
Fixes t0060-82.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
---
setup.c | 36
t/t0060-path-utils.sh | 2 +-
2 files changed, 17 insertions(+), 21 deletions(-)
diff --git a/setup.c b/setup.c
index e606846..2e65b48 100644
--- a/setup.c
+++ b/setup.c
@@ -22,11 +22,23 @@ char *prefix_path_gently(const char *prefix, int len,
const char *orig = path;
char *sanitized;
if (is_absolute_path(orig)) {
- const char *temp = real_path(path);
- sanitized = xmalloc(len + strlen(temp) + 1);
- strcpy(sanitized, temp);
+ char *npath;
+
+ npath = xmalloc(strlen(path) + 1);
if (remaining_prefix)
*remaining_prefix = 0;
+ if (normalize_path_copy_len(npath, path, remaining_prefix)) {
+ free(npath);
+ return NULL;
+ }
+ if (abspath_part_inside_repo(npath, npath)) {
+ free(npath);
+ return NULL;
+ }
+
+ sanitized = xmalloc(strlen(npath) + 1);
+ strcpy(sanitized, npath);
+ free(npath);
} else {
sanitized = xmalloc(len + strlen(path) + 1);
if (len)
@@ -34,26 +46,10 @@ char *prefix_path_gently(const char *prefix, int len,
strcpy(sanitized + len, path);
if (remaining_prefix)
*remaining_prefix = len;
- }
- if (normalize_path_copy_len(sanitized, sanitized, remaining_prefix))
- goto error_out;
- if (is_absolute_path(orig)) {
- size_t root_len, len, total;
- const char *work_tree = get_git_work_tree();
- if (!work_tree)
- goto error_out;
- len = strlen(work_tree);
- root_len = offset_1st_component(work_tree);
- total = strlen(sanitized) + 1;
- if (strncmp(sanitized, work_tree, len) ||
- (len root_len sanitized[len] != '\0' sanitized[len]
!= '/')) {
- error_out:
+ if (normalize_path_copy_len(sanitized, sanitized,
remaining_prefix)) {
free(sanitized);
return NULL;
}
- if (sanitized[len] == '/')
- len++;
- memmove(sanitized, sanitized + len, total - len);
}
return sanitized;
}
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index b8e92e1..f6f378b 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -190,7 +190,7 @@ test_expect_success SYMLINKS 'real path works on symlinks' '
test $sym = $(test-path-utils real_path $dir2/syml)
'
-test_expect_failure SYMLINKS 'prefix_path works with absolute paths to work
tree symlinks' '
+test_expect_success SYMLINKS 'prefix_path works with absolute paths to work
tree symlinks' '
ln -s target symlink
test $(test-path-utils prefix_path prefix $(pwd)/symlink) =
symlink
'
--
1.8.5.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 v3 2/4] t0060: Add test for prefix_path when path == work tree
The current behaviour of prefix_path is to return an empty string if prefixing and absolute path that only contains exactly the work tree. This behaviour is a potential regression point. Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com --- t/t0060-path-utils.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh index 0bba988..b8e92e1 100755 --- a/t/t0060-path-utils.sh +++ b/t/t0060-path-utils.sh @@ -195,6 +195,12 @@ test_expect_failure SYMLINKS 'prefix_path works with absolute paths to work tree test $(test-path-utils prefix_path prefix $(pwd)/symlink) = symlink ' +test_expect_success 'prefix_path works with only absolute path to work tree' ' + echo expected + test-path-utils prefix_path prefix $(pwd) actual + test_cmp expected actual +' + relative_path /foo/a/b/c/ /foo/a/b/ c/ relative_path /foo/a/b/c/ /foo/a/bc/ relative_path /foo/a//b//c////foo/a/b//c/ POSIX -- 1.8.5.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 v3 0/4] setup: Don't dereference in-tree symlinks for absolute paths
On Mon, Jan 27, 2014 at 08:31:37AM -0800, Junio C Hamano wrote:
Martin Erik Werner martinerikwer...@gmail.com writes:
In order to manipulate symliks in the
work tree using absolute paths, symlinks should only be dereferenced
outside the work tree.
I agree 100% with this reasoning (modulo s/symliks/symlinks/).
As to the implementation, it looks a bit overly complicated,
though. I haven't tried writing the same myself, but
* I suspect that strbuf would help simplifying the allocation and
deallocation;
* Also I suspect that use of string-list to split and then join is
making the code unnecessarily complex. In Python/Perl, that would
be a normal approach, but in C, it would be a lot simpler if you
prepare a writable temporary in wtpart[], walk from left to right
finding '/' and replacing it temporarily with NUL to terminate in
order to check with real_path(), restore the NUL back to '/' to
check deeper, and rinse and repeat.
Having said that, I am not absolutely sure if the repeated
calls to real_path() are doing the right thing, though ;-)
diff --git a/setup.c b/setup.c
index 5432a31..0789a96 100644
--- a/setup.c
+++ b/setup.c
@@ -22,11 +22,51 @@ char *prefix_path_gently(const char *prefix, int len,
const char *orig = path;
char *sanitized;
if (is_absolute_path(orig)) {
- const char *temp = real_path(path);
- sanitized = xmalloc(len + strlen(temp) + 1);
- strcpy(sanitized, temp);
+ int i, match;
+ size_t wtpartlen;
+ char *npath, *wtpart;
+ struct string_list list = STRING_LIST_INIT_DUP;
+ const char *work_tree = get_git_work_tree();
+ if (!work_tree)
+ return NULL;
+ npath = xmalloc(strlen(path) + 1);
if (remaining_prefix)
*remaining_prefix = 0;
+ if (normalize_path_copy_len(npath, path, remaining_prefix)) {
+ free(npath);
+ return NULL;
+ }
+
+ string_list_split(list, npath, '/', -1);
+ wtpart = xmalloc(strlen(npath) + 1);
+ i = 0;
+ match = 0;
+ strcpy(wtpart, list.items[i++].string);
+ strcat(wtpart, /);
+ if (strcmp(real_path(wtpart), work_tree) == 0) {
+ match = 1;
+ } else {
+ while (i list.nr) {
+ strcat(wtpart, list.items[i++].string);
+ if (strcmp(real_path(wtpart), work_tree) == 0) {
+ match = 1;
+ break;
+ }
+ strcat(wtpart, /);
+ }
+ }
+ string_list_clear(list, 0);
+ if (!match) {
+ free(npath);
+ free(wtpart);
+ return NULL;
+ }
+
+ wtpartlen = strlen(wtpart);
+ sanitized = xmalloc(strlen(npath) - wtpartlen);
+ strcpy(sanitized, npath + wtpartlen + 1);
+ free(npath);
+ free(wtpart);
} else {
sanitized = xmalloc(len + strlen(path) + 1);
if (len)
@@ -34,26 +74,10 @@ char *prefix_path_gently(const char *prefix, int len,
strcpy(sanitized + len, path);
if (remaining_prefix)
*remaining_prefix = len;
- }
- if (normalize_path_copy_len(sanitized, sanitized, remaining_prefix))
- goto error_out;
- if (is_absolute_path(orig)) {
- size_t root_len, len, total;
- const char *work_tree = get_git_work_tree();
- if (!work_tree)
- goto error_out;
- len = strlen(work_tree);
- root_len = offset_1st_component(work_tree);
- total = strlen(sanitized) + 1;
- if (strncmp(sanitized, work_tree, len) ||
- (len root_len sanitized[len] != '\0' sanitized[len]
!= '/')) {
- error_out:
+ if (normalize_path_copy_len(sanitized, sanitized,
remaining_prefix)) {
free(sanitized);
return NULL;
}
- if (sanitized[len] == '/')
- len++;
- memmove(sanitized, sanitized + len, total - len);
}
return sanitized;
}
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 3a0677a..03a12ac 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -190,7 +190,7 @@ test_expect_success SYMLINKS 'real path works on
symlinks' '
test $sym = $(test-path-utils real_path $dir2/syml)
'
-test_expect_failure SYMLINKS 'prefix_path works with work tree symlinks' '
+test_expect_success SYMLINKS 'prefix_path works
Performance regression in git fetch between 1.8.3.4 and 1.8.5.3
At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3. We've noticed a significant performance regression in git fetch. The numbers below are for an up-to-date branch (that is, no data is actually being fetched) for a git-over-ssh remote on our gitorious server. This is an auxiliary repository, so its size is probably between 6-7 GiB. It does not have an especially large number of refs, but is a clone of our main repository. Other than the new version, the only difference is that 1.8.5.3 is built against libpcre. These are both running on the same CentOS 6 system; literally the only difference is installing one RPM or the other. 1.8.3.4: brianc ok # for i in `seq 1 3`; do time git fetch; done git fetch 0.86s user 0.18s system 78% cpu 1.314 total git fetch 0.88s user 0.19s system 79% cpu 1.348 total git fetch 0.84s user 0.18s system 78% cpu 1.299 total 1.8.5.3: brianc ok # for i in `seq 1 3`; do time git fetch; done git fetch 17.11s user 1.22s system 98% cpu 18.652 total git fetch 16.74s user 1.24s system 98% cpu 18.286 total git fetch 17.78s user 1.35s system 98% cpu 19.446 total Does anyone have any idea what might be causing this? -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: A few contributor's questions
Jonathan Nieder jrnie...@gmail.com writes: I assume the problem you're trying to solve is that files don't have clear enough notices of their licensing. No, just the file that I'm contributing to. It has a single copyright attribution that arguably is already less than accurate _unless_ the respective authors can be considered to have been acting with the intent of letting Junio do whatever he wants to do with their contribution. That could be a real problem for people using the code, since if you no one gave you a license then you don't have a license at all. In that case, it is reasonably to revert to the general license. It's also a problem in that it makes it harder to interpret the phrase under the same open source license (though I have no idea how that could be read as I give up my copyright completely). If the existing notice is (c) Junio Hamano that means that Junio is fully able to license at his will. And in the case of his work on Git, this includes his expressive permission to relicense under the conditions of libgit2, including a no-modification binary-only licensing option. So my problem is not as much that people might get the idea they might not use/copy my work at all (which would be silly), but rather that they have reasonable expectation to use it under the licensing scheme of libgit2 without getting back to me. * the code is copyright by the authors and we try not to waste fuss on maintaining a comprehensive list in notices. That's fine, but we are talking not about a list but a single named copyright holder. I was proposing adding and others to clarify that the list is not exhaustive. * relicensing, when needed, happens by contacting all the copyright holders and getting their consent I don't see anything weird about that. Neither do I. But people using the code might like clearer notices, so I personally would not mind an extra line in most files stating the license. I was more concerned about amending the copyright attribution, though a single line pointing out GPLv2 and referring the reader to the general COPYING file does not seem excessive, either. It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. For relicensing the existing practice is to just contact people. Well, that stops working once they are dead. And it's probably rather tricky to locate their heirs even in case they have placed instructions concerning their copyrights into their last will. While I am not in a rush here, I am still likely to turn decomposing into a fulltime occupation earlier than most other contributors: I started working with computers at a time when the single most imminent danger to long-term data archival were mice. That has the advantage that I can make a decision about whether to allow relicensing code I've written in the context of how I expect it to be used. I expect that if you had a stance on GPLv2+ licensing of contributions to git published in some place easily found by search engines (for example a message on the mailing list), interested people would not have too much trouble finding it when the time comes. Maybe, maybe not. There is a big hole in the indexing of the Google News history that was taken over from what once was Dejanews. Putting the information regarding prospective licensing close to the actual source seems like a smart move. At any rate, if there is no stock procedure for that, that's it. -- David Kastrup -- To unsubscribe from this list: send the line 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: Performance regression in git fetch between 1.8.3.4 and 1.8.5.3
On Fri, Jan 31, 2014 at 09:02:15PM +, brian m. carlson wrote: At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3. We've noticed a significant performance regression in git fetch. The numbers below are for an up-to-date branch (that is, no data is actually being fetched) for a git-over-ssh remote on our gitorious server. Is it better with v1.9-rc1? There was a slowdown in v1.8.4.2 that I addressed with commit 200abe7 (which is slated for v1.9). -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 3/4] setup: Add 'abspath_part_inside_repo' function
On 2014-01-31 21.22, Martin Erik Werner wrote:
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which incrementally checks
each path level by temporarily NUL-terminating at each '/' and comparing
against the work tree path. When a match is found, it copies the
remainder (which will be the in-repo part) to a destination
buffer.
The path being the filesystem root or exactly equal to the work tree are
special cases handled separately, since then there is no directory
separator between the work tree and in-repo part.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
---
cache.h | 1 +
setup.c | 63 +++
2 files changed, 64 insertions(+)
diff --git a/cache.h b/cache.h
index ce377e1..242f27d 100644
--- a/cache.h
+++ b/cache.h
@@ -426,6 +426,7 @@ extern void verify_filename(const char *prefix,
int diagnose_misspelt_rev);
extern void verify_non_filename(const char *prefix, const char *name);
extern int path_inside_repo(const char *prefix, const char *path);
+extern int abspath_part_inside_repo(char *dst, const char *path);
abspath_part_inside_repo() is only used in setup.c, isn't it?
In this case we don't need it in cache.h, it can be declared inside setup.c as
static int abspath_part_inside_repo(char *dst, const char *path);
(or static inline )
-
(And not in this patch: see the final setup.c:)
if (g) {
free(npath);
return NULL;
}
If this is the only caller of abspath_part_inside_repo(),
then do we need npath 2 times as a parameter ?
Or can we re-write it to look like this:
static inline int abspath_part_inside_repo(char *path)
[
]
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v1.9-rc2
A release candidate Git v1.9-rc2 is now available for testing at the usual places. I've heard rumours that various third-party tools do not like the two-digit version numbers (e.g. Git 2.0) and started barfing left and right when the users install v1.9-rc1. While it is tempting to laugh at them for their sloppy assumption, I am also practical and do not mind calling the upcoming release v1.9.0 to help them. If we go that route (and I am inclined to go that route at this moment), the versioning scheme will be - The next release candidate will be v1.9.0-rc3, not v1.9-rc3; - The first maintenance release for v1.9.0 will be v1.9.1 (and Nth one be v1.9.N); and - The feature release after v1.9.0 will be either v1.10.0 or v2.0.0, depending on how big the feature jump we are looking at. The release tarballs are found at: http://code.google.com/p/git-core/downloads/list and their SHA-1 checksums are: c21bb5f8a138a5af9d330ce7289f5c533d49e2a2 git-1.9.rc2.tar.gz dec30e4b187c84c08c02d53aa5d5d4d3fae9bbda git-htmldocs-1.9.rc2.tar.gz 207e1e91357eed351b5b7cd4a7d2cc8985cd git-manpages-1.9.rc2.tar.gz The following public repositories all have a copy of the v1.9-rc2 tag and the master branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git v1.9 Release Notes (draft) == Backward compatibility notes git submodule foreach $cmd $args used to treat $cmd $args the same way ssh did, concatenating them into a single string and letting the shell unquote. Careless users who forget to sufficiently quote $args gets their argument split at $IFS whitespaces by the shell, and got unexpected results due to this. Starting from this release, the command line is passed directly to the shell, if it has an argument. Read-only support for experimental loose-object format, in which users could optionally choose to write in their loose objects for a short while between v1.4.3 to v1.5.3 era, has been dropped. The meanings of --tags option to git fetch has changed; the command fetches tags _in addition to_ what are fetched by the same command line without the option. The way git push $there $what interprets $what part given on the command line, when it does not have a colon that explicitly tells us what ref at the $there repository is to be updated, has been enhanced. A handful of ancient commands that have long been deprecated are finally gone (repo-config, tar-tree, lost-found, and peek-remote). Backward compatibility notes (for Git 2.0) -- When git push [$there] does not say what to push, we have used the traditional matching semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). In Git 2.0, the default will change to the simple semantics, which pushes: - only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or - only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from. Use the user preference configuration variable push.default to change this. If you are an old-timer who is used to the matching semantics, you can set the variable to matching to keep the traditional behaviour. If you want to live in the future early, you can set it to simple today without waiting for Git 2.0. When git add -u (and git add -A) is run inside a subdirectory and does not specify which paths to add on the command line, it will operate on the entire tree in Git 2.0 for consistency with git commit -a and other commands. There will be no mechanism to make plain git add -u behave like git add -u .. Current users of git add -u (without a pathspec) should start training their fingers to explicitly say git add -u . before Git 2.0 comes. A warning is issued when these commands are run without a pathspec and when you have local changes outside the current directory, because the behaviour in Git 2.0 will be different from today's version in such a situation. In Git 2.0, git add path will behave as git add -A path, so that git add dir/ will notice paths you removed from the directory and record the removal. Versions before Git 2.0, including this release, will keep ignoring removals, but the users who rely on this behaviour are encouraged to start using git add --ignore-removal path now before 2.0 is released. The default prefix for git svn will change in Git 2.0. For a long time, git svn created its remote-tracking branches directly under refs/remotes, but it will place
[RFC/PATCH] howto/maintain-git.txt: new version numbering scheme
We wanted to call the upcoming release Git 1.9, with its maintenance track being Git 1.9.1, Git 1.9.2, etc., but various third-party tools are reported to assume that there are at least three dewey-decimal components in our version number. Adjust the plan so that vX.Y.0 are feature releases while vX.Y.Z (Z 0) are maintenance releases. Signed-off-by: Junio C Hamano gits...@pobox.com --- * Haven't committed to this outline, but I am raising a weather-balloon to see reaction from the list. Comments? Documentation/howto/maintain-git.txt | 18 +++--- 1 file changed, 11 insertions(+), 7 deletions(-) diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt index 33ae69c..ca43787 100644 --- a/Documentation/howto/maintain-git.txt +++ b/Documentation/howto/maintain-git.txt @@ -39,26 +39,26 @@ The policy on Integration is informally mentioned in A Note from the maintainer message, which is periodically posted to this mailing list after each feature release is made. - - Feature releases are numbered as vX.Y.Z and are meant to + - Feature releases are numbered as vX.Y.0 and are meant to contain bugfixes and enhancements in any area, including functionality, performance and usability, without regression. - One release cycle for a feature release is expected to last for eight to ten weeks. - - Maintenance releases are numbered as vX.Y.Z.W and are meant - to contain only bugfixes for the corresponding vX.Y.Z feature - release and earlier maintenance releases vX.Y.Z.V (V W). + - Maintenance releases are numbered as vX.Y.Z and are meant + to contain only bugfixes for the corresponding vX.Y.0 feature + release and earlier maintenance releases vX.Y.W (W Z). - 'master' branch is used to prepare for the next feature release. In other words, at some point, the tip of 'master' - branch is tagged with vX.Y.Z. + branch is tagged with vX.Y.0. - 'maint' branch is used to prepare for the next maintenance - release. After the feature release vX.Y.Z is made, the tip + release. After the feature release vX.Y.0 is made, the tip of 'maint' branch is set to that release, and bugfixes will accumulate on the branch, and at some point, the tip of the - branch is tagged with vX.Y.Z.1, vX.Y.Z.2, and so on. + branch is tagged with vX.Y.1, vX.Y.2, and so on. - 'next' branch is used to publish changes (both enhancements and fixes) that (1) have worthwhile goal, (2) are in a fairly @@ -86,6 +86,10 @@ this mailing list after each feature release is made. users are encouraged to test it so that regressions and bugs are found before new topics are merged to 'master'. +Note that before v1.9.0 release, the version numbers used to be +structured slightly differently. vX.Y.Z were feature releases while +vX.Y.Z.W were maintenance releases for vX.Y.Z. + A Typical Git Day - -- To unsubscribe from this list: send the line 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: A few contributor's questions
when relicensing, people use git blame, not header copyright notices to track down the authors. if you are bothered by the copyright notice at the top, modify it as part of your patchset, it's very unlikely that anyone will care enough to object. But copyright assignment has very strict requirements, it can't just be implicit or in e-mail, it requires a signed document, so unless you sign a document stating that you are transferring copyright, you don't have to worry about that. David Lang On Fri, 31 Jan 2014, David Kastrup wrote: Date: Fri, 31 Jan 2014 22:06:16 +0100 From: David Kastrup d...@gnu.org To: Jonathan Nieder jrnie...@gmail.com Cc: git@vger.kernel.org Subject: Re: A few contributor's questions Jonathan Nieder jrnie...@gmail.com writes: I assume the problem you're trying to solve is that files don't have clear enough notices of their licensing. No, just the file that I'm contributing to. It has a single copyright attribution that arguably is already less than accurate _unless_ the respective authors can be considered to have been acting with the intent of letting Junio do whatever he wants to do with their contribution. That could be a real problem for people using the code, since if you no one gave you a license then you don't have a license at all. In that case, it is reasonably to revert to the general license. It's also a problem in that it makes it harder to interpret the phrase under the same open source license (though I have no idea how that could be read as I give up my copyright completely). If the existing notice is (c) Junio Hamano that means that Junio is fully able to license at his will. And in the case of his work on Git, this includes his expressive permission to relicense under the conditions of libgit2, including a no-modification binary-only licensing option. So my problem is not as much that people might get the idea they might not use/copy my work at all (which would be silly), but rather that they have reasonable expectation to use it under the licensing scheme of libgit2 without getting back to me. * the code is copyright by the authors and we try not to waste fuss on maintaining a comprehensive list in notices. That's fine, but we are talking not about a list but a single named copyright holder. I was proposing adding and others to clarify that the list is not exhaustive. * relicensing, when needed, happens by contacting all the copyright holders and getting their consent I don't see anything weird about that. Neither do I. But people using the code might like clearer notices, so I personally would not mind an extra line in most files stating the license. I was more concerned about amending the copyright attribution, though a single line pointing out GPLv2 and referring the reader to the general COPYING file does not seem excessive, either. It's verbose and cumbersome enough that I would not have been surprised if there'd be an established way of getting this information on record, preferably per-project rather than per-commit. For relicensing the existing practice is to just contact people. Well, that stops working once they are dead. And it's probably rather tricky to locate their heirs even in case they have placed instructions concerning their copyrights into their last will. While I am not in a rush here, I am still likely to turn decomposing into a fulltime occupation earlier than most other contributors: I started working with computers at a time when the single most imminent danger to long-term data archival were mice. That has the advantage that I can make a decision about whether to allow relicensing code I've written in the context of how I expect it to be used. I expect that if you had a stance on GPLv2+ licensing of contributions to git published in some place easily found by search engines (for example a message on the mailing list), interested people would not have too much trouble finding it when the time comes. Maybe, maybe not. There is a big hole in the indexing of the Google News history that was taken over from what once was Dejanews. Putting the information regarding prospective licensing close to the actual source seems like a smart move. At any rate, if there is no stock procedure for that, that's it.
Re: Performance regression in git fetch between 1.8.3.4 and 1.8.5.3
On Fri, Jan 31, 2014 at 04:35:05PM -0500, Jeff King wrote: On Fri, Jan 31, 2014 at 09:02:15PM +, brian m. carlson wrote: At work, we recently upgraded our git version from 1.8.3.4 to 1.8.5.3. We've noticed a significant performance regression in git fetch. The numbers below are for an up-to-date branch (that is, no data is actually being fetched) for a git-over-ssh remote on our gitorious server. Is it better with v1.9-rc1? There was a slowdown in v1.8.4.2 that I addressed with commit 200abe7 (which is slated for v1.9). Yes. The time is much lower with 1.9-rc1: brianc ok # for i in `seq 1 3`; do time git fetch; done git fetch 0.90s user 0.18s system 74% cpu 1.447 total git fetch 0.88s user 0.20s system 74% cpu 1.456 total git fetch 0.88s user 0.19s system 74% cpu 1.438 total I'll open a case to get it updated once 1.9 is finally released. Thanks for your suggestion. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH v2 9/9] pull: add the --gpg-sign option.
On Mon, Jan 27, 2014 at 03:31:36PM -0800, Junio C Hamano wrote: ... but here it is used as if it is properly quoted so that later eval $eval will take it as a single argument. git pull --gpg-sign='foo bar' will probably ask the command to use 'foo' as the signer key id, with 'bar' as an extra, unknown token on the command line of the underlying 'git merge', I suspect. A git rev-parse --sq-quote in the earlier hunk may be all it takes to fix it. Yes, you were correct that that was broken, and yes, it turns out that your fix is sufficient. It also happens to fix the issue where the help text is improperly quoted. With your suggested fix, it is now quoted (ugly, but quoted): Stopped at aba3d3ff83b59627adbdafe1b334a46ed5b7ec17... am: add the --gpg-sign option You can amend the commit now, with git commit --amend '-Sbrian m. carlson sand...@crustytoothpaste.net' Since I expect most users are going to use -S, either because they have a key specifically specified in .gitconfig, or because the default key is the right thing anyway, I don't see this as a huge problem. I think I'll probably end up fixing it anyway and then send out the reroll. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH v3 3/4] setup: Add 'abspath_part_inside_repo' function
On Fri, Jan 31, 2014 at 11:37:29PM +0100, Torsten Bögershausen wrote:
On 2014-01-31 21.22, Martin Erik Werner wrote:
In order to extract the part of an absolute path which lies inside the
repo, it is not possible to directly use real_path, since that would
dereference symlinks both outside and inside the work tree.
Add an 'abspath_part_inside_repo' function which incrementally checks
each path level by temporarily NUL-terminating at each '/' and comparing
against the work tree path. When a match is found, it copies the
remainder (which will be the in-repo part) to a destination
buffer.
The path being the filesystem root or exactly equal to the work tree are
special cases handled separately, since then there is no directory
separator between the work tree and in-repo part.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
---
cache.h | 1 +
setup.c | 63
+++
2 files changed, 64 insertions(+)
diff --git a/cache.h b/cache.h
index ce377e1..242f27d 100644
--- a/cache.h
+++ b/cache.h
@@ -426,6 +426,7 @@ extern void verify_filename(const char *prefix,
int diagnose_misspelt_rev);
extern void verify_non_filename(const char *prefix, const char *name);
extern int path_inside_repo(const char *prefix, const char *path);
+extern int abspath_part_inside_repo(char *dst, const char *path);
abspath_part_inside_repo() is only used in setup.c, isn't it?
In this case we don't need it in cache.h, it can be declared inside setup.c as
static int abspath_part_inside_repo(char *dst, const char *path);
(or static inline )
-
(And not in this patch: see the final setup.c:)
if (g) {
free(npath);
return NULL;
}
If this is the only caller of abspath_part_inside_repo(),
then do we need npath 2 times as a parameter ?
Or can we re-write it to look like this:
static inline int abspath_part_inside_repo(char *path)
[
]
I guess I've over-generalised it a bit too much, that should rather be
done if-and-when, I presume?
It is indeed only used in setup.c and only by the prefix_path_gently
function so static inline then?
Hmm, for single-parameter it should suffice to simply move the parameter
down into the function, like so?:
const char* src;
src = dst;
and carry on as before (obviously also renaming the variables sensibly),
or did you have something else in mind?
(I added two parameters since I was glancing at 'normalize_path_copy_len'
for inspiration, and was thinking about (purely theoretical) re-use in
other cases rather than minimizing it for the time being.)
What do you mean with the (And not in this patch... bit; what final
setup.c?
--
Martin Erik Werner martinerikwer...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/9] rebase: remove useless arguments check
From: Nicolas Vigier bo...@mars-attacks.org
Remove a check on the number of arguments for --onto and -x options.
It is not possible for $# to be = 2 at this point :
- if --onto or -x has an argument, git rev-parse --parseopt will
provide something like this :
set -- --onto 'x' --
when parsing the --onto option, $# will be 3 or more if there are
other options.
- if --onto or -x doesn't have an argument, git rev-parse --parseopt
will exit with an error and display usage information.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-rebase.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index c1f98ae..d1835ba 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -238,12 +238,10 @@ do
action=${1##--}
;;
--onto)
- test 2 -le $# || usage
onto=$2
shift
;;
-x)
- test 2 -le $# || usage
cmd=${cmd}exec $2${LF}
shift
;;
--
1.9.rc1.1006.g13f506b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/9] rebase: parse options in stuck-long mode
From: Nicolas Vigier bo...@mars-attacks.org
There is no functionnal change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-rebase.sh | 50 ++
1 file changed, 22 insertions(+), 28 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 3b55211..842d7d4 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -5,7 +5,7 @@
SUBDIRECTORY_OK=Yes
OPTIONS_KEEPDASHDASH=
-OPTIONS_STUCKLONG=
+OPTIONS_STUCKLONG=t
OPTIONS_SPEC=\
git rebase [-i] [options] [--exec cmd] [--onto newbase] [upstream]
[branch]
git rebase [-i] [options] [--exec cmd] [--onto newbase] --root [branch]
@@ -237,21 +237,19 @@ do
test $total_argc -eq 2 || usage
action=${1##--}
;;
- --onto)
- onto=$2
- shift
+ --onto=*)
+ onto=${1#--onto=}
;;
- -x)
- cmd=${cmd}exec $2${LF}
- shift
+ --exec=*)
+ cmd=${cmd}exec ${1#--exec=}${LF}
;;
- -i)
+ --interactive)
interactive_rebase=explicit
;;
- -k)
+ --keep-empty)
keep_empty=yes
;;
- -p)
+ --preserve-merges)
preserve_merges=t
test -z $interactive_rebase interactive_rebase=implied
;;
@@ -267,21 +265,19 @@ do
--no-fork-point)
fork_point=
;;
- -m)
+ --merge)
do_merge=t
;;
- -X)
- shift
- strategy_opts=$strategy_opts $(git rev-parse --sq-quote
--$1)
+ --strategy-option=*)
+ strategy_opts=$strategy_opts $(git rev-parse --sq-quote
--${1#--strategy-option=})
do_merge=t
test -z $strategy strategy=recursive
;;
- -s)
- shift
- strategy=$1
+ --strategy=*)
+ strategy=${1#--strategy=}
do_merge=t
;;
- -n)
+ --no-stat)
diffstat=
;;
--stat)
@@ -290,21 +286,20 @@ do
--autostash)
autostash=true
;;
- -v)
+ --verbose)
verbose=t
diffstat=t
GIT_QUIET=
;;
- -q)
+ --quiet)
GIT_QUIET=t
git_am_opt=$git_am_opt -q
verbose=
diffstat=
;;
- --whitespace)
- shift
- git_am_opt=$git_am_opt --whitespace=$1
- case $1 in
+ --whitespace=*)
+ git_am_opt=$git_am_opt --whitespace=${1#--whitespace=}
+ case ${1#--whitespace=} in
fix|strip)
force_rebase=t
;;
@@ -317,14 +312,13 @@ do
git_am_opt=$git_am_opt $1
force_rebase=t
;;
- -C)
- shift
- git_am_opt=$git_am_opt -C$1
+ -C*)
+ git_am_opt=$git_am_opt $1
;;
--root)
rebase_root=t
;;
- -f|--no-ff)
+ --force-rebase|--no-ff)
force_rebase=t
;;
--rerere-autoupdate|--no-rerere-autoupdate)
--
1.9.rc1.1006.g13f506b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/9] am: parse options in stuck-long mode
From: Nicolas Vigier bo...@mars-attacks.org
There is no functional change. The reason for this change is to be able
to add a new option taking an optional argument.
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-am.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index a3b6f98..020abf6 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -4,7 +4,7 @@
SUBDIRECTORY_OK=Yes
OPTIONS_KEEPDASHDASH=
-OPTIONS_STUCKLONG=
+OPTIONS_STUCKLONG=t
OPTIONS_SPEC=\
git am [options] [(mbox|Maildir)...]
git am [options] (--continue | --skip | --abort)
@@ -414,14 +414,14 @@ it will be removed. Please do not use it anymore.
abort=t ;;
--rebasing)
rebasing=t threeway=t ;;
- --resolvemsg)
- shift; resolvemsg=$1 ;;
- --whitespace|--directory|--exclude|--include)
- git_apply_opt=$git_apply_opt $(sq $1=$2); shift ;;
- -C|-p)
- git_apply_opt=$git_apply_opt $(sq $1$2); shift ;;
- --patch-format)
- shift ; patch_format=$1 ;;
+ --resolvemsg=*)
+ resolvemsg=${1#--resolvemsg=} ;;
+ --whitespace=*|--directory=*|--exclude=*|--include=*)
+ git_apply_opt=$git_apply_opt $(sq $1) ;;
+ -C*|-p*)
+ git_apply_opt=$git_apply_opt $(sq $1) ;;
+ --patch-format=*)
+ patch_format=${1#--patch-format=} ;;
--reject|--ignore-whitespace|--ignore-space-change)
git_apply_opt=$git_apply_opt $1 ;;
--committer-date-is-author-date)
--
1.9.rc1.1006.g13f506b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/9] git-sh-setup.sh: add variable to use the stuck-long mode
From: Nicolas Vigier bo...@mars-attacks.org If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse option parsing is done in --stuck-long mode. Signed-off-by: Nicolas Vigier bo...@mars-attacks.org Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- contrib/git-resurrect.sh | 1 + git-am.sh| 1 + git-instaweb.sh | 1 + git-quiltimport.sh | 1 + git-rebase.sh| 1 + git-request-pull.sh | 1 + git-sh-setup.sh | 2 ++ 7 files changed, 8 insertions(+) diff --git a/contrib/git-resurrect.sh b/contrib/git-resurrect.sh index a4ed4c3..d7e97bb 100755 --- a/contrib/git-resurrect.sh +++ b/contrib/git-resurrect.sh @@ -10,6 +10,7 @@ is rather slow but allows you to resurrect other people's topic branches. OPTIONS_KEEPDASHDASH= +OPTIONS_STUCKLONG= OPTIONS_SPEC=\ git resurrect $USAGE -- diff --git a/git-am.sh b/git-am.sh index bbea430..a3b6f98 100755 --- a/git-am.sh +++ b/git-am.sh @@ -4,6 +4,7 @@ SUBDIRECTORY_OK=Yes OPTIONS_KEEPDASHDASH= +OPTIONS_STUCKLONG= OPTIONS_SPEC=\ git am [options] [(mbox|Maildir)...] git am [options] (--continue | --skip | --abort) diff --git a/git-instaweb.sh b/git-instaweb.sh index e93a238..4aa3eb8 100755 --- a/git-instaweb.sh +++ b/git-instaweb.sh @@ -5,6 +5,7 @@ PERL='@@PERL@@' OPTIONS_KEEPDASHDASH= +OPTIONS_STUCKLONG= OPTIONS_SPEC=\ git instaweb [options] (--start | --stop | --restart) -- diff --git a/git-quiltimport.sh b/git-quiltimport.sh index 8e17525..167d79f 100755 --- a/git-quiltimport.sh +++ b/git-quiltimport.sh @@ -1,5 +1,6 @@ #!/bin/sh OPTIONS_KEEPDASHDASH= +OPTIONS_STUCKLONG= OPTIONS_SPEC=\ git quiltimport [options] -- diff --git a/git-rebase.sh b/git-rebase.sh index 8a3efa2..c1f98ae 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -5,6 +5,7 @@ SUBDIRECTORY_OK=Yes OPTIONS_KEEPDASHDASH= +OPTIONS_STUCKLONG= OPTIONS_SPEC=\ git rebase [-i] [options] [--exec cmd] [--onto newbase] [upstream] [branch] git rebase [-i] [options] [--exec cmd] [--onto newbase] --root [branch] diff --git a/git-request-pull.sh b/git-request-pull.sh index fe21d5d..cf4f150 100755 --- a/git-request-pull.sh +++ b/git-request-pull.sh @@ -9,6 +9,7 @@ LONG_USAGE='Summarizes the changes between two commits to the standard output, and includes the given URL in the generated summary.' SUBDIRECTORY_OK='Yes' OPTIONS_KEEPDASHDASH= +OPTIONS_STUCKLONG= OPTIONS_SPEC='git request-pull [options] start url [end] -- pshow patch text as well diff --git a/git-sh-setup.sh b/git-sh-setup.sh index fffa3c7..5f28b32 100644 --- a/git-sh-setup.sh +++ b/git-sh-setup.sh @@ -72,6 +72,8 @@ if test -n $OPTIONS_SPEC; then parseopt_extra= [ -n $OPTIONS_KEEPDASHDASH ] parseopt_extra=--keep-dashdash + [ -n $OPTIONS_STUCKLONG ] + parseopt_extra=$parseopt_extra --stuck-long eval $( echo $OPTIONS_SPEC | -- 1.9.rc1.1006.g13f506b.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/9] rebase: don't try to match -M option
From: Nicolas Vigier bo...@mars-attacks.org The -M option does not exist in OPTIONS_SPEC, so there is no use to try to find it. Signed-off-by: Nicolas Vigier bo...@mars-attacks.org Signed-off-by: brian m. carlson sand...@crustytoothpaste.net --- git-rebase.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-rebase.sh b/git-rebase.sh index d1835ba..3b55211 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -267,7 +267,7 @@ do --no-fork-point) fork_point= ;; - -M|-m) + -m) do_merge=t ;; -X) -- 1.9.rc1.1006.g13f506b.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/9] add --gpg-sign to rebase and pull
This series was posted to the list some time back. This is a re-send of Nicolas Vigier's work with an additional patch that adds --gpg-sign to pull as well, as well as the fixes that Junio suggested in review. Since the parsed option value for --gpg-sign=value is used not only as an argument to other commands, but also as output to the user, I chose to abuse git rev-parse --sq-quote slightly to quote only the argument, which I feel is more aesthetically pleasing than quoting the entire option, and perhaps less confusing for the novice shell user. Both options are equally functional. Other than that, this is a simple reroll addressing Junio's review comments. I've been using it on my laptop for some time, and it works fine for me, although further comments are certainly welcome. Nicolas Vigier (8): cherry-pick, revert: add the --gpg-sign option git-sh-setup.sh: add variable to use the stuck-long mode am: parse options in stuck-long mode am: add the --gpg-sign option rebase: remove useless arguments check rebase: don't try to match -M option rebase: parse options in stuck-long mode rebase: add the --gpg-sign option brian m. carlson (1): pull: add the --gpg-sign option. Documentation/git-am.txt | 6 +++- Documentation/git-cherry-pick.txt | 7 - Documentation/git-rebase.txt | 4 +++ Documentation/git-revert.txt | 6 +++- builtin/revert.c | 2 ++ contrib/git-resurrect.sh | 1 + git-am.sh | 26 ++-- git-instaweb.sh | 1 + git-pull.sh | 13 +++- git-quiltimport.sh| 1 + git-rebase--am.sh | 8 +++-- git-rebase--interactive.sh| 32 +++ git-rebase--merge.sh | 2 +- git-rebase.sh | 65 ++- git-request-pull.sh | 1 + git-sh-setup.sh | 2 ++ sequencer.c | 11 +++ sequencer.h | 2 ++ 18 files changed, 132 insertions(+), 58 deletions(-) -- 1.9.rc1.1006.g13f506b.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/9] cherry-pick, revert: add the --gpg-sign option
From: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-cherry-pick.txt | 7 ++-
Documentation/git-revert.txt | 6 +-
builtin/revert.c | 2 ++
sequencer.c | 11 +++
sequencer.h | 2 ++
5 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..f1e6b2f 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -8,7 +8,8 @@ git-cherry-pick - Apply the changes introduced by some existing
commits
SYNOPSIS
[verse]
-'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff] commit...
+'git cherry-pick' [--edit] [-n] [-m parent-number] [-s] [-x] [--ff]
+ [-S[keyid]] commit...
'git cherry-pick' --continue
'git cherry-pick' --quit
'git cherry-pick' --abort
@@ -100,6 +101,10 @@ effect to your index in a row.
--signoff::
Add Signed-off-by line at the end of the commit message.
+-S[keyid]::
+--gpg-sign[=keyid]::
+ GPG-sign commits.
+
--ff::
If the current HEAD is the same as the parent of the
cherry-pick'ed commit, then a fast forward to this commit will
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index 2de67a5..9eb83f0 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -8,7 +8,7 @@ git-revert - Revert some existing commits
SYNOPSIS
[verse]
-'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] commit...
+'git revert' [--[no-]edit] [-n] [-m parent-number] [-s] [-S[keyid]]
commit...
'git revert' --continue
'git revert' --quit
'git revert' --abort
@@ -80,6 +80,10 @@ more details.
This is useful when reverting more than one commits'
effect to your index in a row.
+-S[keyid]::
+--gpg-sign[=keyid]::
+ GPG-sign commits.
+
-s::
--signoff::
Add Signed-off-by line at the end of the commit message.
diff --git a/builtin/revert.c b/builtin/revert.c
index 87659c9..065d88d 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -89,6 +89,8 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
OPT_STRING(0, strategy, opts-strategy, N_(strategy),
N_(merge strategy)),
OPT_CALLBACK('X', strategy-option, opts, N_(option),
N_(option for merge strategy), option_parse_x),
+ { OPTION_STRING, 'S', gpg-sign, opts-gpg_sign, N_(key id),
+ N_(GPG sign commit), PARSE_OPT_OPTARG, NULL, (intptr_t)
},
OPT_END(),
OPT_END(),
OPT_END(),
diff --git a/sequencer.c b/sequencer.c
index 90cac7b..bde5f04 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -392,11 +392,18 @@ static int run_git_commit(const char *defmsg, struct
replay_opts *opts,
{
struct argv_array array;
int rc;
+ char *gpg_sign;
argv_array_init(array);
argv_array_push(array, commit);
argv_array_push(array, -n);
+ if (opts-gpg_sign) {
+ gpg_sign = xmalloc(3 + strlen(opts-gpg_sign));
+ sprintf(gpg_sign, -S%s, opts-gpg_sign);
+ argv_array_push(array, gpg_sign);
+ free(gpg_sign);
+ }
if (opts-signoff)
argv_array_push(array, -s);
if (!opts-edit) {
@@ -808,6 +815,8 @@ static int populate_opts_cb(const char *key, const char
*value, void *data)
opts-mainline = git_config_int(key, value);
else if (!strcmp(key, options.strategy))
git_config_string(opts-strategy, key, value);
+ else if (!strcmp(key, options.gpg-sign))
+ git_config_string(opts-gpg_sign, key, value);
else if (!strcmp(key, options.strategy-option)) {
ALLOC_GROW(opts-xopts, opts-xopts_nr + 1, opts-xopts_alloc);
opts-xopts[opts-xopts_nr++] = xstrdup(value);
@@ -981,6 +990,8 @@ static void save_opts(struct replay_opts *opts)
}
if (opts-strategy)
git_config_set_in_file(opts_file, options.strategy,
opts-strategy);
+ if (opts-gpg_sign)
+ git_config_set_in_file(opts_file, options.gpg-sign,
opts-gpg_sign);
if (opts-xopts) {
int i;
for (i = 0; i opts-xopts_nr; i++)
diff --git a/sequencer.h b/sequencer.h
index 1fc22dc..db43e9c 100644
--- a/sequencer.h
+++ b/sequencer.h
@@ -37,6 +37,8 @@ struct replay_opts {
int mainline;
+ const char *gpg_sign;
+
/* Merge strategy */
const char *strategy;
const char **xopts;
--
1.9.rc1.1006.g13f506b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
[PATCH v3 9/9] pull: add the --gpg-sign option.
git merge already allows us to sign commits, and git rebase has recently
learned how to do so as well. Teach git pull to parse the -S/--gpg-sign
option and pass this along to merge or rebase, as appropriate.
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
git-pull.sh | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/git-pull.sh b/git-pull.sh
index 0a5aa2c..3b2ea9e 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -138,6 +138,15 @@ do
--no-verify-signatures)
verify_signatures=--no-verify-signatures
;;
+ --gpg-sign|-S)
+ gpg_sign_args=-S
+ ;;
+ --gpg-sign=*)
+ gpg_sign_args=$(git rev-parse --sq-quote -S${1#--gpg-sign=})
+ ;;
+ -S*)
+ gpg_sign_args=-S${1#-S}
+ ;;
--d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
dry_run=--dry-run
;;
@@ -305,11 +314,13 @@ merge_name=$(git fmt-merge-msg $log_arg
$GIT_DIR/FETCH_HEAD) || exit
case $rebase in
true)
eval=git-rebase $diffstat $strategy_args $merge_args $rebase_args
$verbosity
+ eval=$eval $gpg_sign_args
eval=$eval --onto $merge_head ${oldremoteref:-$merge_head}
;;
*)
eval=git-merge $diffstat $no_commit $verify_signatures $edit $squash
$no_ff $ff_only
- eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
+ eval=$eval $log_arg $strategy_args $merge_args $verbosity $progress
+ eval=$eval $gpg_sign_args
eval=$eval \\$merge_name\ HEAD $merge_head
;;
esac
--
1.9.rc1.1006.g13f506b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 8/9] rebase: add the --gpg-sign option
From: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-rebase.txt | 4
git-rebase--am.sh| 8 +---
git-rebase--interactive.sh | 32
git-rebase--merge.sh | 2 +-
git-rebase.sh| 14 ++
5 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 2889be6..2a93c64 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -281,6 +281,10 @@ which makes little sense.
specified, `-s recursive`. Note the reversal of 'ours' and
'theirs' as noted above for the `-m` option.
+-S[keyid]::
+--gpg-sign[=keyid]::
+ GPG-sign commits.
+
-q::
--quiet::
Be quiet. Implies --no-stat.
diff --git a/git-rebase--am.sh b/git-rebase--am.sh
index a4f683a..df46f4c 100644
--- a/git-rebase--am.sh
+++ b/git-rebase--am.sh
@@ -6,7 +6,8 @@
case $action in
continue)
- git am --resolved --resolvemsg=$resolvemsg
+ git am --resolved --resolvemsg=$resolvemsg \
+ ${gpg_sign_opt:+$gpg_sign_opt}
move_to_original_branch
return
;;
@@ -26,7 +27,7 @@ then
# empty commits and even if it didn't the format doesn't really lend
# itself well to recording empty patches. fortunately, cherry-pick
# makes this easy
- git cherry-pick --allow-empty $revisions
+ git cherry-pick ${gpg_sign_opt:+$gpg_sign_opt} --allow-empty
$revisions
ret=$?
else
rm -f $GIT_DIR/rebased-patches
@@ -60,7 +61,8 @@ else
return $?
fi
- git am $git_am_opt --rebasing --resolvemsg=$resolvemsg
$GIT_DIR/rebased-patches
+ git am $git_am_opt --rebasing --resolvemsg=$resolvemsg \
+ ${gpg_sign_opt:+$gpg_sign_opt} $GIT_DIR/rebased-patches
ret=$?
rm -f $GIT_DIR/rebased-patches
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 43c19e0..73d32dd 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -181,7 +181,7 @@ exit_with_patch () {
git rev-parse --verify HEAD $amend
warn You can amend the commit now, with
warn
- warn git commit --amend
+ warn git commit --amend $gpg_sign_opt
warn
warn Once you are satisfied with your changes, run
warn
@@ -248,7 +248,8 @@ pick_one () {
test -d $rewritten
pick_one_preserving_merges $@ return
- output eval git cherry-pick $strategy_args $empty_args $ff $@
+ output eval git cherry-pick ${gpg_sign_opt:+$gpg_sign_opt} \
+ $strategy_args $empty_args $ff $@
}
pick_one_preserving_merges () {
@@ -359,7 +360,8 @@ pick_one_preserving_merges () {
echo $sha1 $(git rev-parse HEAD^0)
$rewritten_list
;;
*)
- output eval git cherry-pick $strategy_args $@ ||
+ output eval git cherry-pick
${gpg_sign_opt:+$gpg_sign_opt} \
+ $strategy_args $@ ||
die_with_patch $sha1 Could not pick $sha1
;;
esac
@@ -470,7 +472,8 @@ do_pick () {
--no-post-rewrite -n -q -C $1
pick_one -n $1
git commit --allow-empty --allow-empty-message \
- --amend --no-post-rewrite -n -q -C $1 ||
+ --amend --no-post-rewrite -n -q -C $1 \
+ ${gpg_sign_opt:+$gpg_sign_opt} ||
die_with_patch $1 Could not apply $1... $2
else
pick_one $1 ||
@@ -497,7 +500,7 @@ do_next () {
mark_action_done
do_pick $sha1 $rest
- git commit --amend --no-post-rewrite || {
+ git commit --amend --no-post-rewrite
${gpg_sign_opt:+$gpg_sign_opt} || {
warn Could not amend commit after successfully picking
$sha1... $rest
warn This is most likely due to an empty commit
message, or the pre-commit hook
warn failed. If the pre-commit hook failed, you may
need to resolve the issue before
@@ -542,19 +545,22 @@ do_next () {
squash|s|fixup|f)
# This is an intermediate commit; its message will only
be
# used in case of trouble. So use the long version:
- do_with_author output git commit --amend --no-verify -F
$squash_msg ||
+ do_with_author output git commit --amend --no-verify -F
$squash_msg \
+ ${gpg_sign_opt:+$gpg_sign_opt} ||
[PATCH v3 4/9] am: add the --gpg-sign option
From: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: Nicolas Vigier bo...@mars-attacks.org
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
Documentation/git-am.txt | 6 +-
git-am.sh| 9 -
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 54d8461..17924d0 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -14,7 +14,7 @@ SYNOPSIS
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=option] [-Cn] [-pn] [--directory=dir]
[--exclude=path] [--include=path] [--reject] [-q | --quiet]
-[--[no-]scissors]
+[--[no-]scissors] [-S[keyid]]
[(mbox | Maildir)...]
'git am' (--continue | --skip | --abort)
@@ -119,6 +119,10 @@ default. You can use `--no-utf8` to override this.
Skip the current patch. This is only meaningful when
restarting an aborted patch.
+-S[keyid]::
+--gpg-sign[=keyid]::
+ GPG-sign commits.
+
--continue::
-r::
--resolved::
diff --git a/git-am.sh b/git-am.sh
index 020abf6..78517f2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -38,6 +38,7 @@ abort restore the original branch and abort the
patching operation.
committer-date-is-author-datelie about committer date
ignore-date use current timestamp for author date
rerere-autoupdate update the index with reused conflict resolution if possible
+S,gpg-sign? GPG-sign commits
rebasing* (internal use for git-rebase)
. git-sh-setup
@@ -375,6 +376,7 @@ git_apply_opt=
committer_date_is_author_date=
ignore_date=
allow_rerere_autoupdate=
+gpg_sign_opt=
if test $(git config --bool --get am.keepcr) = true
then
@@ -436,6 +438,10 @@ it will be removed. Please do not use it anymore.
keepcr=t ;;
--no-keep-cr)
keepcr=f ;;
+ --gpg-sign)
+ gpg_sign_opt=-S ;;
+ --gpg-sign=*)
+ gpg_sign_opt=-S${1#--gpg-sign=} ;;
--)
shift; break ;;
*)
@@ -900,7 +906,8 @@ did you forget to use 'git add'?
GIT_COMMITTER_DATE=$GIT_AUTHOR_DATE
export GIT_COMMITTER_DATE
fi
- git commit-tree $tree ${parent:+-p} $parent
$dotest/final-commit
+ git commit-tree ${parent:+-p} $parent
${gpg_sign_opt:+$gpg_sign_opt} $tree \
+ $dotest/final-commit
)
git update-ref -m $GIT_REFLOG_ACTION: $FIRSTLINE HEAD $commit $parent
||
stop_here $this
--
1.9.rc1.1006.g13f506b.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] setup: Add 'abspath_part_inside_repo' function
On Sat, Feb 1, 2014 at 3:22 AM, Martin Erik Werner
martinerikwer...@gmail.com wrote:
diff --git a/setup.c b/setup.c
index 5432a31..e606846 100644
--- a/setup.c
+++ b/setup.c
@@ -77,6 +77,69 @@ int path_inside_repo(const char *prefix, const char *path)
return 0;
}
+/*
+ * It is ok if dst == src, but they should not overlap otherwise.
+ * No checking if the path is in fact an absolute path is done, and it must
+ * already be normalized.
+ *
+ * Find the part of an absolute path that lies inside the work tree by
+ * dereferencing symlinks outside the work tree, for example:
+ * /dir1/repo/dir2/file (work tree is /dir1/repo) - dir2/file
+ * /dir/file (work tree is /) - dir/file
+ * /dir/symlink1/symlink2 (symlink1 points to work tree) - symlink2
+ * /dir/repo (exactly equal to work tree) - (empty string)
+ */
+int abspath_part_inside_repo(char *dst, const char* src)
+{
+ size_t len;
+ char *dst0;
+ char temp;
+
+ const char* work_tree = get_git_work_tree();
+ if (!work_tree)
+ return -1;
+ len = strlen(src);
+ dst0 = dst;
+
+ // check root level
Um.. no C++ style comments. And there should be a test that work_tree
is the prefix of src (common case). If so we can return early and do
not need to do real_path() on every path component.
+ if (has_dos_drive_prefix(src)) {
+ *dst++ = *src++;
+ *dst++ = *src++;
+ *dst++ = *src++;
+ } else {
+ *dst++ = *src++;
+ }
+ temp = *dst;
+ *dst = '\0';
+ if (strcmp(real_path(dst0), work_tree) == 0) {
+ *dst = temp;
+ memmove(dst0, src, len - (dst - dst0) + 1);
+ return 0;
+ }
+ *dst = temp;
+
+ // check each level
+ while (*dst != '\0') {
+ *dst++ = *src++;
+ if (*dst == '/') {
+ *dst = '\0';
+ if (strcmp(real_path(dst0), work_tree) == 0) {
+ memmove(dst0, src + 1, len - (dst - dst0));
+ return 0;
+ }
+ *dst = '/';
+ }
+ }
+
+ // check whole path
+ if (strcmp(real_path(dst0), work_tree) == 0) {
+ *dst0 = '\0';
+ return 0;
+ }
+
+ return -1;
+}
+
int check_filename(const char *prefix, const char *arg)
{
const char *name;
--
1.8.5.2
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
