Re: [PATCH v2 10/19] pack-bitmap: add support for bitmap indexes
On Fri, Oct 25, 2013 at 08:26:29PM -0400, Jeff King wrote: On Fri, Oct 25, 2013 at 04:06:19PM -0700, Junio C Hamano wrote: Jeff King p...@peff.net writes: diff --git a/pack-bitmap.c b/pack-bitmap.c new file mode 100644 index 000..73c52fd --- /dev/null +++ b/pack-bitmap.c @@ -0,0 +1,965 @@ +#include stdlib.h + +#include cache.h You among all people already know why this is bad, no? Yes, I am well aware of why we do not want it. I thought I removed that, but it appears I missed one. Sorry. In addition to that one, there are a few other system header includes: - the ewah/*.c files include the necessary standard headers, and do not include git-compat-util.h at all. I do not really consider these git code, but rather a black box we have imported into the tree to ease the dependency chain. So in that sense, they operate like xdiff/*.c or compat/regex/*.c, which also compile on their own (and can get away with it because they are mostly standard C and do not do system things. However, the code in the ewah/ directory has been hacked up a bit from its original, and ewah_io.c _does_ include git-compat-util.h. So it may make sense to consider our copy a fork and git-ify it more. The upstream Java EWAH library is active and separate, but the C port done by Vicent, while theoretically a separate project, does not actually have any users besides git (though presumably libgit2 will build on it at some point). - Regardless of the decision above, ewah/ewok.h includes stdlib.h, which will pollute git source files which use it. - Ditto for khash.h. -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] pathspec: stop --*-pathspecs impact on internal parse_pathspec() uses
On Sat, Oct 26, 2013 at 09:09:20AM +0700, Nguyen Thai Ngoc Duy wrote: Jeff, how about this? It's similar to your last suggestion (i.e. relaxing the magic mask about literal magic). In addition, it forces literal magic unconditionally in this case, which I think is the right thing to do. And it will fix other --*-pathspecs as well. Yeah, I think I follow your reasoning. The problem I saw was just about --literal-pathspec, but the real issue is that blame does not want magic pathspecs at all, and your new flag turns that off. So it fixes both my problem, as well as git blame -- :(foo)bar. -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 11/15] fetch --prune: prune only based on explicit refspecs
On 10/24/2013 11:11 PM, Junio C Hamano wrote: Michael Haggerty mhag...@alum.mit.edu writes: ... Signed-off-by: Michael Haggerty mhag...@alum.mit.edu Everything in the proposed log message made sense to me. diff --git a/Documentation/config.txt b/Documentation/config.txt index d4d93c9..83c1700 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2086,7 +2086,7 @@ remote.name.vcs:: remote.name.prune:: When set to true, fetching from this remote by default will also remove any remote-tracking branches which no longer exist on the -remote (as if the `--prune` option was give on the command line). +remote (as if the `--prune` option was given on the command line). Shouldn't we stop saying branches here? diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt index 0e6d2ac..5d12219 100644 --- a/Documentation/fetch-options.txt +++ b/Documentation/fetch-options.txt @@ -41,8 +41,14 @@ ifndef::git-pull[] -p:: --prune:: -After fetching, remove any remote-tracking branches which -no longer exist on the remote. +After fetching, remove any remote-tracking branches that Likewise. This is a lot more important than the one in remote.name.prune documentation, as the next sentence Tags are not subject to ... implies that they fall into the same category as what gets pruned here, i.e. remote-tracking branches in the above sentence, but nobody calls refs/tags/v1.0.0 a remote-tracking branch even if it came from your 'origin'. OK, I will change both of the above from remote-tracking branches to remote-tracking references. +no longer exist on the remote. Tags are not subject to +pruning in the usual case that they are fetched because of the +--tags option or remote.name.tagopt. We should mention the most usual case tags are fetched, before mentioning the case the unusual option --tags was used from the command line or .tagopt configuration was used. Namely, when the tags are automatically followed. OK, I will change this in the next draft. @@ -63,7 +69,10 @@ ifndef::git-pull[] --tags:: This is a short-hand requesting that all tags be fetched from the remote in addition to whatever else is being fetched. It -is similar to using the refspec `refs/tags/*:refs/tags/*`. +is similar to using the refspec `refs/tags/*:refs/tags/*`, +except that it doesn't subject tags to pruning, regardless of +a --prune option or the configuration settings of fetch.prune +or remote.name.prune. Using --tags is not similar to using refs/tags/*:refs/tags/* after the previous patch already; git fetch origin --tags and git fetch origin refs/tags/*:refs/tags/* are vastly different and that was the whole point of the previous step. And that calling something not so similar similar needs to be fixed further here to clarify that they are not similar in yet another way. We should just lose It is similar to using from 10/15 and start over, perhaps? Add the first paragraph of the below in 10/15 and add the rest in 11/15, or something. --tags:: Request that all tags be fetched from the remote under the same name (i.e. `refs/tags/X` is created in our repository by copying their `refs/tags/X`), in addition to whatever is fetched by the same `git fetch` command without this option on the command line. + When `refs/tags/*` hierarchy from the remote is copied only because this option was given, they are not subject to be pruned when `--prune` option (or configuration variables like `fetch.prune` or `remote.name.prune`) is in effect. That would make it clear that they are subject to pruning when --mirror or an explicit refspec refs/tags/*:refs/tags/* is given, as tags are not fetched only because of --tags in such cases. I see your point. What do you think about the following version, which is a bit more compact and refers the reader to --prune for the full story: -t:: --tags:: Fetch all tags from the remote (i.e., fetch remote tags `refs/tags/*` into local tags with the same name), in addition to whatever else would otherwise be fetched. Using this option does not subject tags to pruning, even if --prune is used (though tags may be pruned anyway if they are also the destination of an explicit refspec; see '--prune'). I also want to improve the description of tag auto-following in general. I will send a re-rolled patch series in the next couple of days. Thanks for your prompt and helpful advice! Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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
Good Morning;
Happy Good day; Hope you are doing well today? I am happy to write you today. I am Maguetta Grace, a lady looking for friendship, I believe that life is what you give it, to me race, sex, age, and colour of the skin, are all jokes, they are not barrier when we have affection to humanity, i like creative and happy people. I come across to your contact today hoping to establish a good friendship with you. I will like us to chat, exchange mails, then I will send you my photo and tell you more about me. I will want to know more about you as well. I will be hoping for your kind response. Yours; Meg -- To unsubscribe from this list: send the line 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 07/19] compat: add endianness helpers
Jeff King p...@peff.net writes:
From: Vicent Marti tan...@gmail.com
The POSIX standard doesn't currently define a `nothll`/`htonll`
typo: ntohll
function pair to perform network-to-host and host-to-network
swaps of 64-bit data. These 64-bit swaps are necessary for the on-disk
storage of EWAH bitmaps if they are not in native byte order.
[...]
+#include byteswap.h
Do we need a hack on top similar to what ntoh_l and hton_l do, for
platforms that do not support unaligned access?
read-cache.c:1316
#ifndef NEEDS_ALIGNED_ACCESS
#define ntoh_s(var) ntohs(var)
#define ntoh_l(var) ntohl(var)
#else
static inline uint16_t ntoh_s_force_align(void *p)
{
uint16_t x;
memcpy(x, p, sizeof(x));
return ntohs(x);
}
static inline uint32_t ntoh_l_force_align(void *p)
{
uint32_t x;
memcpy(x, p, sizeof(x));
return ntohl(x);
}
#define ntoh_s(var) ntoh_s_force_align((var))
#define ntoh_l(var) ntoh_l_force_align((var))
#endif
--
Thomas Rast
t...@thomasrast.ch
--
To unsubscribe from this list: send the line 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] for-each-ref: avoid loading objects to print %(objectname)
Jeff King p...@peff.net writes: diff --git a/t/t6300-for-each-ref.sh b/t/t6300-for-each-ref.sh index 752f5cb..2b4b9a9 100755 [...] +test_atom head *objectname '' +test_atom head *objecttype '' [...] +test_atom tag *objectname '67a36f10722846e891fbada1ba48ed035de75581' +test_atom tag *objecttype 'commit' Can you quote the *? I may have become somewhat paranoid, but still. This is the first use of the *field syntax, and test_atom seems written to correctly quote its arguments, so why risk it? :-) -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line 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 2/2] merge-base: teach --fork-point mode
On Fri, Oct 25, 2013 at 02:38:08PM -0700, Junio C Hamano wrote: It also comes with a documentation update. The option is not called --reflog but --fork-point; naming a feature after what it does (i.e. it finds the fork point) is a lot more sensible than naming it after how it happens to do what it does (i.e. it does so by peeking into the reflog). I think the new name is likely to confuse normal users - when talking about a branch, you can talk about where it forked from and in that case it normally means the merge-base of that branch and master. The --reflog name has the advantage that it makes clear that this is looking at something more than the commit graph and I don't think --fork-point does imply that. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Improving git-scm.com/community [Re: git 1.8.4.1 configure should ship TYPE_SOCKLEN_T source macro]
Tim Mooney tim.moo...@ndsu.edu writes: [git-scm.com/community doesn't say whether the address for bug reports allows posting by non-list members, so hopefully this makes it through the moderation process] The text is here: https://github.com/github/gitscm-next So we can actively improve such things. I just sent this pull request: https://github.com/github/gitscm-next/pull/318 -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT Hooks and security
Very helpful :) thanks ! 2013/10/26 Bryan Turner btur...@atlassian.com: No, the .git/hooks directory in your clone is created from your local templates, installed with your Git distribution, not the remote hooks. On Linux distributions, these templates are often in someplace like /usr/share/git-core/templates (for normal packages), and on Windows with msysgit they are in share\git-core\templates under your installation directory. If you look in this directory you will see a hooks directory containing the sample hooks. Hooks from a remote repository are never cloned. As far as I'm aware, nothing from the .git directory (aside from refs and packs, of course) is cloned, including configuration. Your .git directory after a clone is completely new, assembled from scratch. There's nothing in the Git wire protocol (currently) for moving other data like configuration or hooks, and this sort of malicious code injection is one of the reasons I've seen discussed on the list for why that's the case. Hope this helps, Bryan Turner On 26 October 2013 09:25, Olivier Revollat revol...@gmail.com wrote: But when someone do a clone he don't have .git/hooks directory downloaded to his local computer ? I thought so ... 2013/10/26 Junio C Hamano gits...@pobox.com: Olivier Revollat revol...@gmail.com writes: I was wondering : What if I had a malicious GIT repository who can inject code via git hooks mechanism : someone clone my repo and some malicious code is executed when a certain GIT hook is triggered (for example on commit (prepare-commit-msg' hook)) In that somebody else's clone, you will not have _your_ malicious hook installed, unless that cloner explicitly does something stupid, like copying that malicious hook. -- Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- Mathematics is made of 50 percent formulas, 50 percent proofs, and 50 percent imagination. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GIT Hooks and security
2013/10/26 Bryan Turner btur...@atlassian.com: No, the .git/hooks directory in your clone is created from your local templates, installed with your Git distribution, not the remote hooks. On Linux distributions, these templates are often in someplace like /usr/share/git-core/templates (for normal packages), and on Windows with msysgit they are in share\git-core\templates under your installation directory. If you look in this directory you will see a hooks directory containing the sample hooks. Hooks from a remote repository are never cloned. As far as I'm aware, nothing from the .git directory (aside from refs and packs, of course) is cloned, including configuration. Your .git directory after a clone is completely new, assembled from scratch. There's nothing in the Git wire protocol (currently) for moving other data like configuration or hooks, and this sort of malicious code injection is one of the reasons I've seen discussed on the list for why that's the case. Hope this helps, Bryan Turner On 26 October 2013 09:25, Olivier Revollat revol...@gmail.com wrote: But when someone do a clone he don't have .git/hooks directory downloaded to his local computer ? I thought so ... 2013/10/26 Junio C Hamano gits...@pobox.com: Olivier Revollat revol...@gmail.com writes: I was wondering : What if I had a malicious GIT repository who can inject code via git hooks mechanism : someone clone my repo and some malicious code is executed when a certain GIT hook is triggered (for example on commit (prepare-commit-msg' hook)) In that somebody else's clone, you will not have _your_ malicious hook installed, unless that cloner explicitly does something stupid, like copying that malicious hook. Also copying hooks is relatively low risk, real hackers hide exploits in 1MB configure scripts. -- To unsubscribe from this list: send the line 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 10/19] pack-bitmap: add support for bitmap indexes
If it's not mentioned yet, maybe you should note that this code
currently supports only one pack with .bitmap file.
On Fri, Oct 25, 2013 at 1:03 PM, Jeff King p...@peff.net wrote:
diff --git a/khash.h b/khash.h
new file mode 100644
index 000..0fdf39d
--- /dev/null
+++ b/khash.h
@@ -0,0 +1,342 @@
I notice the line continuations '\' in this file look more aligned if
tab length is set to 4. No idea how many emacs users out there but it
probably does not harm to put
/* -*- mode: c; tab-width: 4; -*- */
at the beginning of this file? Another option is realign the file,
which I doubt is good because this file is imported.
+static int load_pack_bitmap(void)
+{
+ assert(bitmap_git.map !bitmap_git.loaded);
+
+ bitmap_git.bitmaps = kh_init_sha1();
+ bitmap_git.ext_index.positions = kh_init_sha1_pos();
+ bitmap_git.reverse_index = revindex_for_pack(bitmap_git.pack);
+
+ if (!(bitmap_git.commits = read_bitmap_1(bitmap_git)) ||
+ !(bitmap_git.trees = read_bitmap_1(bitmap_git)) ||
+ !(bitmap_git.blobs = read_bitmap_1(bitmap_git)) ||
+ !(bitmap_git.tags = read_bitmap_1(bitmap_git)))
+ goto failed;
+
+ if (load_bitmap_entries_v1(bitmap_git) 0)
+ goto failed;
I don't see any mechanism to protect us from corrupt .bitmap files. If
.bitmap is not very large, maybe just check the trailing checksum in
the file when we open it? Else maybe add a crc32 or something after
each commit bitmap in .bitmap v2 and only verify the ones we actually
use?
+static int open_pack_bitmap(void)
+{
+ struct packed_git *p;
+
+ assert(!bitmap_git.map !bitmap_git.loaded);
+
+ prepare_packed_git();
+ for (p = packed_git; p; p = p-next) {
+ if (open_pack_bitmap_1(p) == 0)
+ return 0;
It maybe a good idea to go on anyway, checking for another .bitmap.
Just warn the user about that if found.
+ }
+
+ return -1;
+}
+
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 11/19] pack-objects: use bitmaps when packing objects
On Fri, Oct 25, 2013 at 1:03 PM, Jeff King p...@peff.net wrote: From: Vicent Marti tan...@gmail.com In this patch, we use the bitmap API to perform the `Counting Objects` phase in pack-objects, rather than a traditional walk through the object graph. For a reasonably-packed large repo, the time to fetch and clone is often dominated by the full-object revision walk during the Counting Objects phase. Using bitmaps can reduce the CPU time required on the server (and therefore start sending the actual pack data with less delay). For bitmaps to be used, the following must be true: 1. We must be packing to stdout (as a normal `pack-objects` from `upload-pack` would do). 2. There must be a .bitmap index containing at least one of the have objects that the client is asking for. 3. Bitmaps must be enabled (they are enabled by default, but can be disabled by setting `pack.usebitmaps` to false, or by using `--no-use-bitmap-index` on the command-line). If any of these is not true, we fall back to doing a normal walk of the object graph. I haven't read the bitmap creation code yet. But it probably does not matter. If the client requests a shallow fetch, you probably want to fall back to normal walk too. Bitmaps may be made work with shallow fetches too, I'm not sure. We could substract the shallow'd commits out. The problem is if some other commits share parts of the shallow'd commits, I'm not sure how to detect that. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] During a shallow fetch, prevent sending over unneeded objects
On Mon, Oct 21, 2013 at 2:51 PM, Matthijs Kooijman matth...@stdin.nl wrote: Hi Duy, I saw your patch series got accepted in git master a while back, great! Since I hope to be using the fixed behaviour soon, what was the plan for including it? Am I correct in thinking that git master will become 1.8.5 in a while? Would this series perhaps be considered for backporting to 1.8.4.x? I was waiting for Junio to answer this as I rarely run released versions and do not care much about releases. I think normally master will be cut for the next release (1.8.5?), maint branches have backported bug fixes. I consider this an improvement rather than bug fix. So my guess is it will not be back ported to 1.8.4.x. Gr. Matthijs -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAlJk3QsACgkQz0nQ5oovr7wVOwCgvQCmB4IJ6X86727/5Kslg83G A4UAoI8fBIXGnE1PwtwqFk/Od697dgNM =rjMT -END PGP SIGNATURE- -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] merge -Xindex-only
Thomas Rast tr...@inf.ethz.ch writes: Michael Haggerty mhag...@alum.mit.edu writes: On IRC you said you would like a version that always acts as --no-commit, and simply returns the conflict/no conflict bit as usual. The caller would then proceed using commit-tree itself. I think that is probably a saner solution than this output ref idea. I just had a huge facepalm moment. We already have this option. It is called git-merge-recursive. That is, git merge-recursive $(git merge-base --all HEAD other) -- HEAD other will internally do all the work that 'git merge other' would do, but not update any refs. With this series, you can therefore say git merge-recursive --index-only $(git merge-base --all HEAD other) -- HEAD other and get an *index-only* merge of HEAD and other. Can you see if this is enough to build git-imerge on top of it? Otherwise I'm glad to help with building the git-merge infrastucture to support it. I'll send v2 of the series in a minute; the only change is that I changed the internal flag semantics as per Junio's comment in http://thread.gmane.org/gmane.comp.version-control.git/229787/focus=229797 -- Thomas Rast t...@thomasrast.ch -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] merge-recursive: -Xindex-only to leave worktree unchanged
From: Thomas Rast tr...@inf.ethz.ch Using the new no_worktree flag from the previous commit, we can teach merge-recursive to leave the worktree untouched. Expose this with a new strategy option so that scripts can use it. --- Unchanged. Documentation/merge-strategies.txt | 4 merge-recursive.c | 2 ++ t/t3030-merge-recursive.sh | 13 + 3 files changed, 19 insertions(+) diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt index 49a9a7d..b663a2e 100644 --- a/Documentation/merge-strategies.txt +++ b/Documentation/merge-strategies.txt @@ -92,6 +92,10 @@ subtree[=path];; is prefixed (or stripped from the beginning) to make the shape of two trees to match. +index-only;; + Write the merge result only to the index; do not touch the + worktree. + octopus:: This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is diff --git a/merge-recursive.c b/merge-recursive.c index 922a259..addfb72 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -2096,6 +2096,8 @@ int parse_merge_opt(struct merge_options *o, const char *s) if ((o-rename_score = parse_rename_score(score)) == -1 || *score != 0) return -1; } + else if (!strcmp(s, index-only)) + o-no_worktree = 1; else return -1; return 0; diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh index 2f96100..2f3a16c 100755 --- a/t/t3030-merge-recursive.sh +++ b/t/t3030-merge-recursive.sh @@ -296,6 +296,19 @@ test_expect_success 'merge-recursive result' ' ' +test_expect_success 'merge-recursive --index-only' ' + + rm -fr [abcd] + git checkout -f $c2 + test_expect_code 1 git merge-recursive --index-only $c0 -- $c2 $c1 + git ls-files -s actual + # reuses expected from previous test! + test_cmp expected actual + git diff HEAD actual-diff + : expected-diff + test_cmp expected-diff actual-diff +' + test_expect_success 'fail if the index has unresolved entries' ' rm -fr [abcd] -- 1.8.4.1.841.gb1dcd95 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] merge-recursive: remove dead conditional in update_stages()
From: Thomas Rast tr...@inf.ethz.ch 650467c (merge-recursive: Consolidate different update_stages functions, 2011-08-11) changed the former argument 'clear' to always be true. Remove the useless conditional. Signed-off-by: Thomas Rast tr...@inf.ethz.ch --- Unchanged. merge-recursive.c | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index dbb7104..bdf69cb 100644 --- a/merge-recursive.c +++ b/merge-recursive.c @@ -545,11 +545,9 @@ static int update_stages(const char *path, const struct diff_filespec *o, * would_lose_untracked). Instead, reverse the order of the calls * (executing update_file first and then update_stages). */ - int clear = 1; int options = ADD_CACHE_OK_TO_ADD | ADD_CACHE_SKIP_DFCHECK; - if (clear) - if (remove_file_from_cache(path)) - return -1; + if (remove_file_from_cache(path)) + return -1; if (o) if (add_cacheinfo(o-mode, o-sha1, path, 1, 0, options)) return -1; -- 1.8.4.1.841.gb1dcd95 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] merge-recursive: internal flag to avoid touching the worktree
From: Thomas Rast tr...@inf.ethz.ch
o-call_depth has a double function: a nonzero call_depth means we
want to construct virtual merge bases, but it also means we want to
avoid touching the worktree. Introduce a new flag o-no_worktree to
trigger only the latter.
Signed-off-by: Thomas Rast tr...@inf.ethz.ch
---
Adapted as per Junio's comments in
http://thread.gmane.org/gmane.comp.version-control.git/229787/focus=229797
I'm not sure which way is better; the downside of this version is that
we now have the burden of ensuring that o-no_worktree always remains
a strict subset of o-call_depth whenever we touch this code.
merge-recursive.c | 37 +
merge-recursive.h | 1 +
2 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index bdf69cb..922a259 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -408,10 +408,10 @@ static void record_df_conflict_files(struct merge_options
*o,
int i;
/*
-* If we're merging merge-bases, we don't want to bother with
-* any working directory changes.
+* If we're working in-core only (e.g., merging merge-bases),
+* we don't want to bother with any working directory changes.
*/
- if (o-call_depth)
+ if (o-call_depth || o-no_worktree)
return;
/* Ensure D/F conflicts are adjacent in the entries list. */
@@ -724,7 +724,7 @@ static void update_file_flags(struct merge_options *o,
int update_cache,
int update_wd)
{
- if (o-call_depth)
+ if (o-call_depth || o-no_worktree)
update_wd = 0;
if (update_wd) {
@@ -931,7 +931,8 @@ static struct merge_file_info merge_file_1(struct
merge_options *o,
result.clean = merge_submodule(result.sha,
one-path, one-sha1,
a-sha1, b-sha1,
- !o-call_depth);
+ !(o-call_depth ||
+o-no_worktree));
} else if (S_ISLNK(a-mode)) {
hashcpy(result.sha, a-sha1);
@@ -1003,7 +1004,7 @@ static void handle_change_delete(struct merge_options *o,
const char *change, const char *change_past)
{
char *renamed = NULL;
- if (dir_in_way(path, !o-call_depth)) {
+ if (dir_in_way(path, !(o-call_depth || o-no_worktree))) {
renamed = unique_path(o, path, a_sha ? o-branch1 : o-branch2);
}
@@ -1128,10 +1129,10 @@ static void handle_file(struct merge_options *o,
char *add_name = unique_path(o, rename-path, other_branch);
update_file(o, 0, add-sha1, add-mode, add_name);
- remove_file(o, 0, rename-path, 0);
+ remove_file(o, 0, rename-path, o-call_depth ||
o-no_worktree);
dst_name = unique_path(o, rename-path, cur_branch);
} else {
- if (dir_in_way(rename-path, !o-call_depth)) {
+ if (dir_in_way(rename-path, !(o-call_depth ||
o-no_worktree))) {
dst_name = unique_path(o, rename-path, cur_branch);
output(o, 1, _(%s is a directory in %s adding as %s
instead),
rename-path, other_branch, dst_name);
@@ -1238,7 +1239,7 @@ static void conflict_rename_rename_2to1(struct
merge_options *o,
* merge base just undo the renames; they can be detected
* again later for the non-recursive merge.
*/
- remove_file(o, 0, path, 0);
+ remove_file(o, 0, path, o-call_depth || o-no_worktree);
update_file(o, 0, mfi_c1.sha, mfi_c1.mode, a-path);
update_file(o, 0, mfi_c2.sha, mfi_c2.mode, b-path);
} else {
@@ -1246,7 +1247,7 @@ static void conflict_rename_rename_2to1(struct
merge_options *o,
char *new_path2 = unique_path(o, path, ci-branch2);
output(o, 1, _(Renaming %s to %s and %s to %s instead),
a-path, new_path1, b-path, new_path2);
- remove_file(o, 0, path, 0);
+ remove_file(o, 0, path, o-call_depth || o-no_worktree);
update_file(o, 0, mfi_c1.sha, mfi_c1.mode, new_path1);
update_file(o, 0, mfi_c2.sha, mfi_c2.mode, new_path2);
free(new_path2);
@@ -1405,6 +1406,7 @@ static int process_renames(struct merge_options *o,
* add-source case).
*/
remove_file(o, 1, ren1_src,
+ o-call_depth || o-no_worktree ||
renamed_stage == 2 ||
[PATCH 1/2] refs: remove unused function invalidate_ref_cache
The function 'invalidate_ref_cache' was introduced in 79c7ca5 (2011-10-17,
invalidate_ref_cache(): rename function from invalidate_cached_refs())
by a rename and elevated to be publicly usable in 8be8bde (2011-10-17,
invalidate_ref_cache(): expose this function in the refs API)
However it is not used anymore, as 8bf90dc (2011-10-17, write_ref_sha1():
only invalidate the loose ref cache) and (much) later 506a760 (2013-04-22,
refs: change how packed refs are deleted) removed any calls to this
function. So it seems as if we don't need that function any more,
good bye!
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
refs.c | 7 ---
refs.h | 8
2 files changed, 15 deletions(-)
diff --git a/refs.c b/refs.c
index 3710748..f9c1957 100644
--- a/refs.c
+++ b/refs.c
@@ -947,13 +947,6 @@ static struct ref_cache *get_ref_cache(const char
*submodule)
return refs;
}
-void invalidate_ref_cache(const char *submodule)
-{
- struct ref_cache *refs = get_ref_cache(submodule);
- clear_packed_ref_cache(refs);
- clear_loose_ref_cache(refs);
-}
-
/* The length of a peeled reference line in packed-refs, including EOL: */
#define PEELED_LINE_LENGTH 42
diff --git a/refs.h b/refs.h
index b113377..87a1a79 100644
--- a/refs.h
+++ b/refs.h
@@ -165,14 +165,6 @@ extern void unlock_ref(struct ref_lock *lock);
/** Writes sha1 into the ref specified by the lock. **/
extern int write_ref_sha1(struct ref_lock *lock, const unsigned char *sha1,
const char *msg);
-/*
- * Invalidate the reference cache for the specified submodule. Use
- * submodule=NULL to invalidate the cache for the main module. This
- * function must be called if references are changed via a mechanism
- * other than the refs API.
- */
-extern void invalidate_ref_cache(const char *submodule);
-
/** Setup reflog before using. **/
int log_ref_setup(const char *ref_name, char *logfile, int bufsize);
--
1.8.4.1.605.g23c6912
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] cache: remove unused function 'have_git_dir'
This function was added in d2b0708 (2008-09-27, add have_git_dir()
function) as a preparation for adbc0b6 (2008-09-30, cygwin: Use native
Win32 API for stat).
However the second referenced commit was reverted in f66450a (2013-06-22,
cygwin: Remove the Win32 l/stat() implementation), so we don't need to
expose this wrapper function any more as a public API.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
cache.h | 1 -
environment.c | 5 -
2 files changed, 6 deletions(-)
diff --git a/cache.h b/cache.h
index 464c8fb..7e98f9e 100644
--- a/cache.h
+++ b/cache.h
@@ -398,7 +398,6 @@ extern int is_bare_repository(void);
extern int is_inside_git_dir(void);
extern char *git_work_tree_cfg;
extern int is_inside_work_tree(void);
-extern int have_git_dir(void);
extern const char *get_git_dir(void);
extern int is_git_directory(const char *path);
extern char *get_object_directory(void);
diff --git a/environment.c b/environment.c
index 378254c..0a15349 100644
--- a/environment.c
+++ b/environment.c
@@ -155,11 +155,6 @@ int is_bare_repository(void)
return is_bare_repository_cfg !get_git_work_tree();
}
-int have_git_dir(void)
-{
- return !!git_dir;
-}
-
const char *get_git_dir(void)
{
if (!git_dir)
--
1.8.4.1.605.g23c6912
--
To unsubscribe from this list: send the line 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] web--browse: Add support for xdg-open.
xdg-open is a tool similar to git-web--browse. It opens a file or URL in the
user's preferred application. It could probably be made default at least on
Linux with a graphical environment.
Signed-off-by: Rüdiger Sonderfeld ruedi...@c-plusplus.de
---
Documentation/git-web--browse.txt | 1 +
git-web--browse.sh| 6 +++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-web--browse.txt
b/Documentation/git-web--browse.txt
index 5aec4ec..2de575f 100644
--- a/Documentation/git-web--browse.txt
+++ b/Documentation/git-web--browse.txt
@@ -35,6 +35,7 @@ The following browsers (or commands) are currently supported:
* open (this is the default under Mac OS X GUI)
* start (this is the default under MinGW)
* cygstart (this is the default under Cygwin)
+* xdg-open
Custom commands may also be specified.
diff --git a/git-web--browse.sh b/git-web--browse.sh
index 1d72ec7..ebdfba6 100755
--- a/git-web--browse.sh
+++ b/git-web--browse.sh
@@ -34,7 +34,7 @@ valid_tool() {
firefox | iceweasel | seamonkey | iceape | \
chrome | google-chrome | chromium | chromium-browser | \
konqueror | opera | w3m | elinks | links | lynx | dillo | open | \
- start | cygstart)
+ start | cygstart | xdg-open)
;; # happy
*)
valid_custom_tool $1 || return 1
@@ -112,7 +112,7 @@ fi
if test -z $browser ; then
if test -n $DISPLAY; then
- browser_candidates=firefox iceweasel google-chrome chrome
chromium chromium-browser konqueror opera seamonkey iceape w3m elinks links
lynx dillo
+ browser_candidates=firefox iceweasel google-chrome chrome
chromium chromium-browser konqueror opera seamonkey iceape w3m elinks links
lynx dillo xdg-open
if test $KDE_FULL_SESSION = true; then
browser_candidates=konqueror $browser_candidates
fi
@@ -179,7 +179,7 @@ konqueror)
;;
esac
;;
-w3m|elinks|links|lynx|open|cygstart)
+w3m|elinks|links|lynx|open|cygstart|xdg-open)
$browser_path $@
;;
start)
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH] t3200: do not open a HTML manual page when DEFAULT_MAN_FORMAT is html
We have the build configuration option DEFAULT_MAN_FORMAT to choose a format different from man pages to be used by 'git help' when no format is requested explicitly. Since 65db0443 (Set the default help format to html for msys builds, 2013-06-04) we use html on Windows by default. There is one test in t3200-branch.sh that invokes a help page. The intent of the redirections applied to the command invocation is to avoid that the man page viewer interferes with the automated test. But when the default format is not man, this does not have the intended effect, and the HTML manual page is opened during the test run. Request man format explicitly to keep the test silent. Signed-off-by: Johannes Sixt j...@kdbg.org --- I've posted this patch to the msysgit list in July, and Dscho has picked it up for Git on Windows. t/t3200-branch.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index 44ec6a4..e9823a0 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -17,7 +17,7 @@ test_expect_success 'prepare a trivial repository' ' HEAD=$(git rev-parse --verify HEAD)' test_expect_success 'git branch --help should not have created a bogus branch' ' - test_might_fail git branch --help /dev/null /dev/null 2/dev/null + test_might_fail git branch --man --help /dev/null /dev/null 21 test_path_is_missing .git/refs/heads/--help ' -- 1.8.4.33.gd68f7e8 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] git clone: is an URL local or ssh
Commit 8d3d28f5 added test cases for URLs which should be ssh.
Add more tests testing all the combinations:
-IPv4 or IPv6
-path starting with / or with /~
-with and without the ssh:// scheme
Add tests for ssh:// with port number.
When a git repository foo:bar exist, git clone will call
absolute_path() and git_connect() will be called with
something like /home/user/projects/foo:bar
Tighten the test and use foo:bar instead of ./foo:bar,
refactor clear_ssh() and expect_ssh() into test_clone_url().
git clone foo/bar:baz should not be ssh:
Make the rule
if there is a slash before the first colon, it is not ssh
more strict by using the same is_local() in both connect.c
and transport.c. Add a test case.
Bug fixes for corner cases:
- Handle clone of [::1]:/~repo correctly (2e7766655):
Git should call ssh ::1 ~repo, not ssh ::1 /~repo
This was caused by looking at (host != url), which never
worked for host names with literal IPv6 adresses, embedded by []
Support for the [] URLs was introduced in 356bece0a.
- Do not tamper local URLs starting with '[' which have a ']'
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
(This does apply on pu, not on master.
I'm almost sure there are more corner cases, but the
most important things should be covered)
connect.c| 47 +--
connect.h| 1 +
t/t5601-clone.sh | 96 +++-
transport.c | 8 -
4 files changed, 106 insertions(+), 46 deletions(-)
diff --git a/connect.c b/connect.c
index 06e88b0..903063e 100644
--- a/connect.c
+++ b/connect.c
@@ -231,6 +231,7 @@ int server_supports(const char *feature)
}
enum protocol {
+ PROTO_LOCAL_OR_SSH = 0,
PROTO_LOCAL = 1,
PROTO_SSH,
PROTO_GIT
@@ -547,6 +548,15 @@ static char *get_port(char *host)
static struct child_process no_fork;
+int is_local(const char *url)
+{
+ const char *colon = strchr(url, ':');
+ const char *slash = strchr(url, '/');
+ return !colon || (slash slash colon) ||
+ has_dos_drive_prefix(url);
+}
+
+
/*
* This returns a dummy child_process if the transport protocol does not
* need fork(2), or a struct child_process object if it does. Once done,
@@ -564,9 +574,9 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
char *url;
char *host, *path;
char *end;
- int c;
+ int seperator;
struct child_process *conn = no_fork;
- enum protocol protocol = PROTO_LOCAL;
+ enum protocol protocol = PROTO_LOCAL_OR_SSH;
int free_path = 0;
char *port = NULL;
const char **arg;
@@ -587,20 +597,23 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
*host = '\0';
protocol = get_protocol(url);
host += 3;
- c = '/';
+ seperator = '/';
} else {
host = url;
- c = ':';
+ seperator = ':';
+ if (is_local(url))
+ protocol = PROTO_LOCAL;
}
/*
* Don't do destructive transforms with git:// as that
* protocol code does '[]' unwrapping of its own.
+* Don't change local URLs
*/
if (host[0] == '[') {
end = strchr(host + 1, ']');
if (end) {
- if (protocol != PROTO_GIT) {
+ if (protocol != PROTO_GIT protocol != PROTO_LOCAL) {
*end = 0;
host++;
}
@@ -610,17 +623,17 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
} else
end = host;
- path = strchr(end, c);
- if (path !has_dos_drive_prefix(end)) {
- if (c == ':') {
- if (host != url || path strchrnul(host, '/')) {
- protocol = PROTO_SSH;
- *path++ = '\0';
- } else /* '/' in the host part, assume local path */
- path = end;
+ path = strchr(end, seperator);
+ if (seperator == ':') {
+ if (path protocol == PROTO_LOCAL_OR_SSH) {
+ /* We have a ':' */
+ protocol = PROTO_SSH;
+ *path++ = '\0';
+ } else {/* assume local path */
+ protocol = PROTO_LOCAL;
+ path = end;
}
- } else
- path = end;
+ }
if (!path || !*path)
die(No path specified. See 'man git-pull' for valid url
syntax);
@@ -629,7 +642,7 @@ struct child_process *git_connect(int fd[2], const char
*url_orig,
* null-terminate hostname and point path to ~ for URL's like this:
*ssh://host.xz/~user/repo
[PATCH 3/3] tests: undo special treatment of CRLF for Windows
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/lib-credential.sh | 4
t/t7407-submodule-foreach.sh | 4
t/t9001-send-email.sh| 1 -
3 files changed, 9 deletions(-)
diff --git a/t/lib-credential.sh b/t/lib-credential.sh
index 3c43ff1..957ae93 100755
--- a/t/lib-credential.sh
+++ b/t/lib-credential.sh
@@ -18,10 +18,6 @@ check() {
cat stderr
false
fi
- if test_have_prereq MINGW
- then
- dos2unix -q stderr
- fi
test_cmp expect-stdout stdout
test_cmp expect-stderr stderr
}
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index be93f10..b64c9ed 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -254,10 +254,6 @@ test_expect_success 'ensure status --cached --recursive
preserves the --cached
)
git submodule status --cached --recursive -- nested1 ../actual
)
- if test_have_prereq MINGW
- then
- dos2unix actual
- fi
test_cmp expect actual
'
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 2813aa9..3119c8c 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -23,7 +23,6 @@ test_expect_success $PREREQ \
echo do
echo echo \!\$a!\
echo done commandline\$output
- test_have_prereq MINGW echo dos2unix commandline\$output
echo cat msgtxt\$output
) fake.sendmail
chmod +x ./fake.sendmail
--
1.8.4.33.gd68f7e8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] Fix tests on Windows caused by random CRLF output
When git, the executable, invokes a bash script (hooks, scripted git commands, ...), bash writes its output with CRLF. This causes tests to fail because the expected output does not contain CR, only LF. This fixes the tests by replacing test_cmp with a diff computation that disregards the CR. Patch 1 replaces test_cmp with cmp when binary data is compared. Patch 2 is the actual fix. Patch 3 removes some work-arounds that are not necessary anymore. Johannes Sixt (3): t5300-pack-object: do not compare binary data using test_cmp Windows: a test_cmp that is agnostic to random LF CRLF conversions tests: undo special treatment of CRLF for Windows t/lib-credential.sh | 4 --- t/t5300-pack-object.sh | 10 +++ t/t7407-submodule-foreach.sh | 4 --- t/t9001-send-email.sh| 1 - t/test-lib-functions.sh | 66 t/test-lib.sh| 1 + 6 files changed, 72 insertions(+), 14 deletions(-) -- 1.8.4.33.gd68f7e8 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] t5300-pack-object: do not compare binary data using test_cmp
Users may set test_cmp to a comparison tool of their liking. The intent is
that the tool performs comparison of line-oriented texts. However, t5300
uses it also to compare binary data. Change those tests to use 'cmp'.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/t5300-pack-object.sh | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index a07c871..61e787d 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -151,7 +151,7 @@ test_expect_success \
git cat-file $t $object || return 1
done obj-list
} current
-test_cmp expect current'
+cmp expect current'
test_expect_success \
'use packed deltified (REF_DELTA) objects' \
@@ -166,7 +166,7 @@ test_expect_success \
git cat-file $t $object || return 1
done obj-list
} current
-test_cmp expect current'
+cmp expect current'
test_expect_success \
'use packed deltified (OFS_DELTA) objects' \
@@ -181,7 +181,7 @@ test_expect_success \
git cat-file $t $object || return 1
done obj-list
} current
-test_cmp expect current'
+cmp expect current'
unset GIT_OBJECT_DIRECTORY
@@ -195,9 +195,9 @@ test_expect_success 'survive missing objects/pack
directory' '
rm -fr $GOP
git index-pack --stdin --keep=test
../test-3-${packname_3}.pack
test -f $GOP/pack-${packname_3}.pack
- test_cmp $GOP/pack-${packname_3}.pack
../test-3-${packname_3}.pack
+ cmp $GOP/pack-${packname_3}.pack ../test-3-${packname_3}.pack
test -f $GOP/pack-${packname_3}.idx
- test_cmp $GOP/pack-${packname_3}.idx
../test-3-${packname_3}.idx
+ cmp $GOP/pack-${packname_3}.idx ../test-3-${packname_3}.idx
test -f $GOP/pack-${packname_3}.keep
)
'
--
1.8.4.33.gd68f7e8
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Windows: a test_cmp that is agnostic to random LF CRLF conversions
In a number of tests, output that was produced by a shell script is
compared to expected output using test_cmp. Unfortunately, the MSYS bash--
when invoked via git, such as in hooks--converts LF to CRLF on output
(as produced by echo and printf), which leads to many false positives.
Implements a diff tool that undoes the converted CRLF. To avoid that
sub-processes are spawned (which is very slow on Windows), the tool is
implemented as a shell function. Diff is invoked as usual only when a
difference is detected by the shell code.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
t/test-lib-functions.sh | 66 +
t/test-lib.sh | 1 +
2 files changed, 67 insertions(+)
diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
index a7e9aac..f987694 100644
--- a/t/test-lib-functions.sh
+++ b/t/test-lib-functions.sh
@@ -710,3 +710,69 @@ test_ln_s_add () {
git update-index --add --cacheinfo 12 $ln_s_obj $2
fi
}
+
+# The following mingw_* functions obey POSIX shell syntax, but are actually
+# bash scripts, and are meant to be used only with bash on Windows.
+
+# A test_cmp function that treats LF and CRLF equal and avoids to fork
+# diff when possible.
+mingw_test_cmp () {
+ # Read text into shell variables and compare them. If the results
+ # are different, use regular diff to report the difference.
+ local test_cmp_a= test_cmp_b=
+
+ # When text came from stdin (one argument is '-') we must feed it
+ # to diff.
+ local stdin_for_diff=
+
+ # Since it is difficult to detect the difference between an
+ # empty input file and a failure to read the files, we go straight
+ # to diff if one of the inputs is empty.
+ if test -s $1 test -s $2
+ then
+ # regular case: both files non-empty
+ mingw_read_file_strip_cr_ test_cmp_a $1
+ mingw_read_file_strip_cr_ test_cmp_b $2
+ elif test -s $1 test $2 = -
+ then
+ # read 2nd file from stdin
+ mingw_read_file_strip_cr_ test_cmp_a $1
+ mingw_read_file_strip_cr_ test_cmp_b
+ stdin_for_diff='$test_cmp_b'
+ elif test $1 = - test -s $2
+ then
+ # read 1st file from stdin
+ mingw_read_file_strip_cr_ test_cmp_a
+ mingw_read_file_strip_cr_ test_cmp_b $2
+ stdin_for_diff='$test_cmp_a'
+ fi
+ test -n $test_cmp_a
+ test -n $test_cmp_b
+ test $test_cmp_a = $test_cmp_b ||
+ eval diff -u \\$@\ $stdin_for_diff
+}
+
+# $1 is the name of the shell variable to fill in
+mingw_read_file_strip_cr_ () {
+ # Read line-wise using LF as the line separator
+ # and use IFS to strip CR.
+ local line
+ while :
+ do
+ if IFS=$'\r' read -r -d $'\n' line
+ then
+ # good
+ line=$line$'\n'
+ else
+ # we get here at EOF, but also if the last line
+ # was not terminated by LF; in the latter case,
+ # some text was read
+ if test -z $line
+ then
+ # EOF, really
+ break
+ fi
+ fi
+ eval $1=\$$1\$line
+ done
+}
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0fa7dfd..77e487b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -817,6 +817,7 @@ case $(uname -s) in
test_set_prereq NOT_CYGWIN
test_set_prereq SED_STRIPS_CR
test_set_prereq GREP_STRIPS_CR
+ GIT_TEST_CMP=mingw_test_cmp
;;
*CYGWIN*)
test_set_prereq POSIXPERM
--
1.8.4.33.gd68f7e8
--
To unsubscribe from this list: send the line 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] rev-parse --parseopt: add the --sticked-long mode
From: Junio C Hamano gits...@pobox.com Nicolas Vigier bo...@mars-attacks.org writes: On Fri, 25 Oct 2013, Junio C Hamano wrote: Nicolas Vigier bo...@mars-attacks.org writes: Add the --sticked-long option to output the options in their long form if available, and with their arguments sticked. Hmph, doesn't verb stick conjugate to (present) stick (past) stuck (pp) stuck? Ah, yes it seems. I don't know if 'sticked' is also correct or not. However, 'sticked' is the word that is used in Documentation/gitcli.txt and Documentation/technical/api-parse-options.txt. Yes, I know. That is why I brought it up before we inflict more damage to us. -- Isn't the origin of the description that it looks like a stick (cane), and 'sticked' is a modern verbing of that form? That's what I'd assumed anyway. Googleing Sticked option only linked back to Git. Philip -- To unsubscribe from this list: send the line 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] remote-curl: fix large pushes with GSSAPI
Due to an interaction between the way libcurl handles GSSAPI authentication over
HTTP and the way git uses libcurl, large pushes (those over http.postBuffer
bytes) would fail due to an authentication failure requiring a rewind of the
curl buffer. Such a rewind was not possible because the data did not fit into
the entire buffer.
Enable the use of the Expect: 100-continue header for large requests where the
server offers GSSAPI authentication to avoid this issue, since the request would
otherwise fail. This allows git to get the authentication data right before
sending the pack contents. Existing cases where pushes would succeed, including
small requests using GSSAPI, still disable the use of 100 Continue, as it causes
problems for some remote HTTP implementations (servers and proxies).
Signed-off-by: brian m. carlson sand...@crustytoothpaste.net
---
remote-curl.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/remote-curl.c b/remote-curl.c
index c9b891a..35698e7 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -449,6 +449,7 @@ static int post_rpc(struct rpc_state *rpc)
char *gzip_body = NULL;
size_t gzip_size = 0;
int err, large_request = 0;
+ int needs_100_continue = 0;
/* Try to load the entire request, if we can fit it into the
* allocated buffer space we can use HTTP/1.0 and avoid the
@@ -472,6 +473,8 @@ static int post_rpc(struct rpc_state *rpc)
}
if (large_request) {
+ long authtype = 0;
+
do {
err = probe_rpc(rpc);
if (err == HTTP_REAUTH)
@@ -479,11 +482,17 @@ static int post_rpc(struct rpc_state *rpc)
} while (err == HTTP_REAUTH);
if (err != HTTP_OK)
return -1;
+
+ slot = get_active_slot();
+ curl_easy_getinfo(slot-curl, CURLINFO_HTTPAUTH_AVAIL,
authtype);
+ if (authtype CURLAUTH_GSSNEGOTIATE)
+ needs_100_continue = 1;
}
headers = curl_slist_append(headers, rpc-hdr_content_type);
headers = curl_slist_append(headers, rpc-hdr_accept);
- headers = curl_slist_append(headers, Expect:);
+ headers = curl_slist_append(headers, needs_100_continue ?
+ Expect: 100-continue : Expect:);
retry:
slot = get_active_slot();
--
1.8.4.1.635.g6a5
--
To unsubscribe from this list: send the line 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] sha1_file: move comment about return value where it belongs
Commit 5b0864070 (sha1_object_info_extended: make type calculation
optional, Jul 12 2013) changed the return value of the
sha1_object_info_extended function to 0/-1 for success/error.
Previously this function returned the object type for success or
-1 for error. But unfortunately the above commit forgot to change
or move the comment above this function that says returns enum
object_type or negative.
To fix this inconsistency, let's move the comment above the
sha1_object_info function where it is still true.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
sha1_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index f80bbe4..7dadd04 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2514,7 +2514,6 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
return 0;
}
-/* returns enum object_type or negative */
int sha1_object_info_extended(const unsigned char *sha1, struct object_info
*oi)
{
struct cached_object *co;
@@ -2563,6 +2562,7 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi)
return 0;
}
+/* returns enum object_type or negative */
int sha1_object_info(const unsigned char *sha1, unsigned long *sizep)
{
enum object_type type;
--
1.8.4.rc1.28.ge2684af
--
To unsubscribe from this list: send the line 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] commit: Add -f, --fixes commit option to add Fixes: line
Linux Kernel Summit 2013 decided on a commit message convention to
identify commits containing bugs fixed by a commit: a Fixes: line,
included in the standard commit footer (along with Signed-off-by: if
present), containing an abbreviated commit hash (at least 12 characters
to keep it valid for a long time) and the subject of the commit (for
human readers). This helps people (or automated tools) determine how
far to backport a commit.
Add a command line option for git commit to automatically construct the
Fixes: line for a commit. This avoids the need to manually construct
that line by copy-pasting the commit hash and subject.
Also works with --amend to modify an existing commit's message. To add
a Fixes line to an earlier commit in a series, use rebase -i and add the
following line after the existing commit:
x git commit --amend --no-edit -f $commit_containing_bug
Generalize append_signoff to support appending arbitrary extra lines to
a commit in the signoff block; this avoids duplicating the logic to find
or construct that block.
Signed-off-by: Josh Triplett j...@joshtriplett.org
---
Documentation/git-commit.txt | 12 ++--
builtin/commit.c | 29 +++--
sequencer.c | 31 +++
sequencer.h | 3 +++
t/t7502-commit.sh| 39 ++-
5 files changed, 101 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1a7616c..fcc6ed2 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -8,8 +8,8 @@ git-commit - Record changes to the repository
SYNOPSIS
[verse]
-'git commit' [-a | --interactive | --patch] [-s] [-v] [-umode] [--amend]
- [--dry-run] [(-c | -C | --fixup | --squash) commit]
+'git commit' [-a | --interactive | --patch] [-s] [-f commit] [-v] [-umode]
+ [--amend] [--dry-run] [(-c | -C | --fixup | --squash) commit]
[-F file | -m msg] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=author]
[--date=date] [--cleanup=mode] [--[no-]status]
@@ -156,6 +156,14 @@ OPTIONS
Add Signed-off-by line by the committer at the end of the commit
log message.
+-f commit::
+--fixes=commit::
+ Add Fixes line for the specified commit at the end of the commit
+ log message. This line includes an abbreviated commit hash for
+ the specified commit; the `core.abbrev` option determines the
+ length of the abbreviated commit hash used, with a minimum length
+ of 12 hex digits.
+
-n::
--no-verify::
This option bypasses the pre-commit and commit-msg hooks.
diff --git a/builtin/commit.c b/builtin/commit.c
index 6ab4605..9bbcd8a 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -123,6 +123,7 @@ static int use_editor = 1, include_status = 1;
static int show_ignored_in_status, have_option_m;
static const char *only_include_assumed;
static struct strbuf message = STRBUF_INIT;
+static struct strbuf fixes = STRBUF_INIT;
static enum status_format {
STATUS_FORMAT_NONE = 0,
@@ -133,6 +134,28 @@ static enum status_format {
STATUS_FORMAT_UNSPECIFIED
} status_format = STATUS_FORMAT_UNSPECIFIED;
+static int opt_parse_f(const struct option *opt, const char *arg, int unset)
+{
+ struct strbuf *sb = opt-value;
+ if (unset) {
+ strbuf_setlen(sb, 0);
+ } else {
+ struct pretty_print_context ctx = {0};
+ struct commit *commit;
+
+ commit = lookup_commit_reference_by_name(arg);
+ if (!commit)
+ die(_(could not lookup commit %s), arg);
+ ctx.output_encoding = get_commit_output_encoding();
+ ctx.abbrev = DEFAULT_ABBREV;
+ if (ctx.abbrev 12)
+ ctx.abbrev = 12;
+ format_commit_message(commit, Fixes: %h ('%s')\n, sb, ctx);
+ }
+
+ return 0;
+}
+
static int opt_parse_m(const struct option *opt, const char *arg, int unset)
{
struct strbuf *buf = opt-value;
@@ -718,7 +741,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
if (clean_message_contents)
stripspace(sb, 0);
- if (signoff) {
+ if (signoff || fixes.len) {
/*
* See if we have a Conflicts: block at the end. If yes, count
* its size, so we can ignore it.
@@ -742,7 +765,8 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
previous = eol;
}
- append_signoff(sb, ignore_footer, 0);
+ append_signoff_extra(sb, ignore_footer,
+signoff ? 0 : APPEND_EXTRA_ONLY, fixes);
}
if (fwrite(sb.buf, 1, sb.len, s-fp) sb.len)
@@ -1463,6 +1487,7
[PATCH v3 11/10] fixup! transport-helper: add support to delete branches
Patch 2/10 (transport-helper: fix extra lines) deleted one copy of the
lines; patch 9/10 (transport-helper: add support to delete branches)
should delete the other copy of the lines.
Signed-off-by: Richard Hansen rhan...@bbn.com
---
transport-helper.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 10db28e..23526de 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -878,9 +878,6 @@ static int push_refs_with_export(struct transport
*transport,
char *private;
unsigned char sha1[20];
- if (ref-deletion)
- die(remote-helpers do not support ref deletion);
-
private = apply_refspecs(data-refspecs, data-refspec_nr,
ref-name);
if (private !get_sha1(private, sha1)) {
strbuf_addf(buf, ^%s, private);
--
1.8.4.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 11/10] fixup! transport-helper: add support to delete branches
On Sat, Oct 26, 2013 at 11:55 PM, Felipe Contreras felipe.contre...@gmail.com wrote: On Sat, Oct 26, 2013 at 11:34 PM, Richard Hansen rhan...@bbn.com wrote: Patch 2/10 (transport-helper: fix extra lines) deleted one copy of the lines; patch 9/10 (transport-helper: add support to delete branches) should delete the other copy of the lines. Looks awfully familiar to: http://article.gmane.org/gmane.comp.version-control.git/235973 But since the project does have double standards, you might have better luck by simply not using my name. Ahh, nevermind, it's a fix on top of my patch. I actually found this and fixed it on my local branch, but didn't push it. Now I have. https://github.com/felipec/git/commit/4820caafc1f0b9e346b369bb2bc2b7bfdc8a1957 -- Felipe Contreras -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] commit: Add -f, --fixes commit option to add Fixes: line
On 10/27/2013 02:34 AM, Josh Triplett wrote: Linux Kernel Summit 2013 decided on a commit message convention to identify commits containing bugs fixed by a commit: a Fixes: line, included in the standard commit footer (along with Signed-off-by: if present), containing an abbreviated commit hash (at least 12 characters to keep it valid for a long time) and the subject of the commit (for human readers). This helps people (or automated tools) determine how far to backport a commit. Add a command line option for git commit to automatically construct the Fixes: line for a commit. This avoids the need to manually construct that line by copy-pasting the commit hash and subject. Also works with --amend to modify an existing commit's message. To add a Fixes line to an earlier commit in a series, use rebase -i and add the following line after the existing commit: x git commit --amend --no-edit -f $commit_containing_bug Generalize append_signoff to support appending arbitrary extra lines to a commit in the signoff block; this avoids duplicating the logic to find or construct that block. I have a few comments and questions about the design of this feature: First of all, let me show my ignorance. How formalized is the use of metadata lines at the end of a commit message? I don't remember seeing documentation about such lines in general (as opposed to documentation about particular types of lines). Is the format defined well enough that tools that don't know about a particular line could nonetheless preserve it correctly? Is there/should there be a standard recommended order of metadata lines? (For example, should Fixes: lines always appear before Signed-off-by lines, or vice versa?) If so, is it documented somewhere and preserved by tools when such lines are added/modified? Should there be support for querying such lines? There is another thread [1] proposing the addition of a Change-Id: metadata line, so maybe now would be a good time to discuss such lines in general. Too bad your proposed new option sounds so similar to --fixup, which does something conceptually similar albeit very different in effect. This will likely lead to confusion. I wonder if the two features could be combined in some way? The main difference between the two features is how they are intended to be used: --fixup is to fix a commit that hasn't been pushed yet (where the user intends to squash the commits together), whereas --fixes is to mark a commit as a fix to a commit that has already been pushed (where the commits will remain separate). But there seems to be a common concept here. For example, what happens if a --fixes commit is rebase -ied at the same time as the commit that it fixes? It might make sense to do the autosquash thing just like with a --fixup/--squash commit. (Otherwise the SHA-1 in the Fixes: line will become invalid anyway.) Conversely, I suppose one could ask whether there should be some way to prevent fixup! or squash! commits from being pushed, at least without some kind of --force option. This could of course be enforced by a hook but it might be nice to have some protection by default. I see that there a consistency check that the --fixes argument is a valid commit. But is there/should there be a check that it is an ancestor of the commit being created? Is there/should there be a check that both of these facts remain true if the the commit containing it is rebased, cherry-picked, etc? In workflows that make more use of cherry-picking, it could be that the original buggy commit was cherry-picked to a different branch. In this case the user would probably want to cherry-pick the fixing commit to the other branch, too. But then the commit that it would be fixing would have a different SHA-1 than it did on the original branch. A check that the Fixes: line refers to an ancestor of the current commit could warn against such errors. (In some cases it might be possible to use cherry-pick's -x lines to figure out how to rewrite the Fixes: line, but I doubt that would work often enough to be worthwhile.) Signed-off-by: Josh Triplett j...@joshtriplett.org --- Documentation/git-commit.txt | 12 ++-- builtin/commit.c | 29 +++-- sequencer.c | 31 +++ sequencer.h | 3 +++ t/t7502-commit.sh| 39 ++- 5 files changed, 101 insertions(+), 13 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 1a7616c..fcc6ed2 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -8,8 +8,8 @@ git-commit - Record changes to the repository SYNOPSIS [verse] -'git commit' [-a | --interactive | --patch] [-s] [-v] [-umode] [--amend] -[--dry-run] [(-c | -C | --fixup | --squash) commit] +'git commit' [-a | --interactive | --patch] [-s] [-f commit]
Re: [PATCH] rev-parse --parseopt: add the --sticked-long mode
On 10/25/2013 10:18 PM, Nicolas Vigier wrote: Add the --sticked-long option to output the options in their long form if available, and with their arguments sticked. Contrary to the default form (non sticked arguments and short options), this can be parsed unambiguously when using options with optional arguments : - in the non sticked form, when an option is taking an optional argument you cannot know if the next argument is its optional argument, or the next option. - the long options form allows to differenciate between an empty argument '--option=' and an unset argument '--option', which is not possible with short options. Trivial: s/differenciate/differentiate/ Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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
