Re: macblame - al alterntive to 'git blame'
sample output.. for file Gemfile.. Contributor: Prasanna with 93.75 % contribution with 30 lines of code Contributor: h4r1sh with 6.25 % contribution with 2 lines of code * * * * * * * * * * * * * * * * * * * * * * * * * and I built this tool by pipelining the output produced by 'git blame' and we use this tool for our internal purposes in our organisation where some files are edited by some 15 people and this will tell us whom to catch if that files run into any problems (assuming largest contributor knows what this file is upto). Thanks, Prasanna -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sparse checkout not working as expected (colons in filenames on Windows)
Hi Duy, On 2015-03-25 01:46, Duy Nguyen wrote: On Wed, Mar 25, 2015 at 6:50 AM, Philip Oakley philipoak...@iee.org wrote: That said, the final error (which I'd missed in the earlier post) is: fatal: make_cache_entry failed for path 'ifcfg-eth0:0' This is on the Windows (pre-compiled msysgit at v1.9.5) Git bash, so could be a catch path in that code for make_cache_entry (I've not checked the code yet). So at the moment it doesn't look like sparse checkout can be used to avoid colons in windows on-disk files based on the current code. Both of your commands below fail by the same function, verify_path() because of this msysgit commit 2e2a2d1 (NTFS: Prevent problematic paths from being checked out - 2014-12-10). I guess that check is a bit too strong, it should apply when new index entries are created from worktree (not from a tree).. Oh, right, that check needs some relaxing. But certainly in a different way: you *definitely* want to prevent attacks from the outside, and those originate from the *tree*. What we need to do instead is to relax the check to apply only if we are really going to write out that file, not when it is skipped. Thanks, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Re: Sparse checkout not working as expected (colons in filenames on Windows)
On Wed, Mar 25, 2015 at 1:39 PM, Johannes Schindelin johannes.schinde...@gmx.de wrote: Hi Duy, On 2015-03-25 01:46, Duy Nguyen wrote: On Wed, Mar 25, 2015 at 6:50 AM, Philip Oakley philipoak...@iee.org wrote: That said, the final error (which I'd missed in the earlier post) is: fatal: make_cache_entry failed for path 'ifcfg-eth0:0' This is on the Windows (pre-compiled msysgit at v1.9.5) Git bash, so could be a catch path in that code for make_cache_entry (I've not checked the code yet). So at the moment it doesn't look like sparse checkout can be used to avoid colons in windows on-disk files based on the current code. Both of your commands below fail by the same function, verify_path() because of this msysgit commit 2e2a2d1 (NTFS: Prevent problematic paths from being checked out - 2014-12-10). I guess that check is a bit too strong, it should apply when new index entries are created from worktree (not from a tree).. Oh, right, that check needs some relaxing. But certainly in a different way: you *definitely* want to prevent attacks from the outside, and those originate from the *tree*. What we need to do instead is to relax the check to apply only if we are really going to write out that file, not when it is skipped. Yeah. In fact if you do this, not checking out files that can't be or not safe to be checked out, then the ifcfg-eth0:0 problem that Phillip wanted to avoid using sparse checkout is also gone. -- 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
[PATCH v5 0/2] cat-file: add a '--literally' option
Based on Junios and Erics suggestion I have made various changes over the previous iteration of the patch[1]. Changes are : * polishing of code and commit messages. Thanks to Junio and Eric for their suggestions and guidance. Reference: [1]: http://thread.gmane.org/gmane.comp.version-control.git/265604 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
On Tue, Mar 24, 2015 at 1:20 AM, Paul Tan pyoka...@gmail.com wrote: t0302 now tests git-credential-store's support for the XDG user-specific configuration file $XDG_CONFIG_HOME/git/credentials. Specifically: * Ensure that the XDG file is strictly opt-in. It should not be created by git at all times if it does not exist. * Conversely, if the XDG file exists, ~/.git-credentials should not be created at all times. * If both the XDG file and ~/.git-credentials exists, then both files should be used for credential lookups. However, credentials should only be written to ~/.git-credentials. * Credentials must be erased from both files. * $XDG_CONFIG_HOME can be a custom directory set by the user as per the XDG base directory specification. Test that git-credential-store respects that, but defaults to ~/.config/git/credentials if it does not exist or is empty. Helped-by: Matthieu Moy matthieu@grenoble-inp.fr Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Paul Tan pyoka...@gmail.com --- diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh index f61b40c..4e1f8ec 100755 --- a/t/t0302-credential-store.sh +++ b/t/t0302-credential-store.sh @@ -6,4 +6,118 @@ test_description='credential-store tests' helper_test store +test_expect_success 'get: use xdg file if home file is unreadable' ' I meant to mention this earlier. Does this test need to be protected by the POSIXPERM prerequisite since it's using chmod? test_expect_success POSIXPERM 'get: ... unreadable' ' Otherwise, the test will likely fail on Windows. + echo https://home-user:home-p...@example.com; $HOME/.git-credentials + chmod -r $HOME/.git-credentials + mkdir -p $HOME/.config/git + echo https://xdg-user:xdg-p...@example.com; $HOME/.config/git/credentials + check fill store -\EOF + protocol=https + host=example.com + -- + protocol=https + host=example.com + username=xdg-user + password=xdg-pass + -- + EOF +' -- 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 v5 1/2] sha1_file.c: support reading from a loose object of unknown type
Update sha1_loose_object_info() to optionally allow it to read
from a loose object file of unknown/bogus type; as the function
usually returns the type of the object it read in the form of enum
for known types, add an optional typename field to receive the
name of the type in textual form and a flag to indicate the reading
of a loose object file of unknown/bogus type.
Add parse_sha1_header_extended() which acts as a wrapper around
parse_sha1_header() allowing more information to be obtained.
Add unpack_sha1_header_to_strbuf() to unpack sha1 headers of
unknown/corrupt objects which have a unknown sha1 header size to
a strbuf structure. This was written by Junio C Hamano but tested
by me.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Karthik Nayak karthik@gmail.com
---
cache.h | 2 ++
sha1_file.c | 110 +++-
2 files changed, 89 insertions(+), 23 deletions(-)
diff --git a/cache.h b/cache.h
index 4d02efc..949ef4c 100644
--- a/cache.h
+++ b/cache.h
@@ -830,6 +830,7 @@ extern int is_ntfs_dotgit(const char *name);
/* object replacement */
#define LOOKUP_REPLACE_OBJECT 1
+#define LOOKUP_LITERALLY 2
extern void *read_sha1_file_extended(const unsigned char *sha1, enum
object_type *type, unsigned long *size, unsigned flag);
static inline void *read_sha1_file(const unsigned char *sha1, enum object_type
*type, unsigned long *size)
{
@@ -1296,6 +1297,7 @@ struct object_info {
unsigned long *sizep;
unsigned long *disk_sizep;
unsigned char *delta_base_sha1;
+ struct strbuf *typename;
/* Response */
enum {
diff --git a/sha1_file.c b/sha1_file.c
index 69a60ec..39041a6 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1564,6 +1564,34 @@ int unpack_sha1_header(git_zstream *stream, unsigned
char *map, unsigned long ma
return git_inflate(stream, 0);
}
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ status = unpack_sha1_header(stream, map, mapsize, buffer, bufsiz);
+
+ if (status) {
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ return status;
+ }
+
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status == Z_OK);
+ return -1;
+}
+
static void *unpack_sha1_rest(git_zstream *stream, void *buffer, unsigned long
size, const unsigned char *sha1)
{
int bytes = strlen(buffer) + 1;
@@ -1614,27 +1642,24 @@ static void *unpack_sha1_rest(git_zstream *stream, void
*buffer, unsigned long s
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-int parse_sha1_header(const char *hdr, unsigned long *sizep)
+int parse_sha1_header_extended(const char *hdr, struct object_info *oi,
+ unsigned int flags)
{
- char type[10];
- int i;
+ struct strbuf typename = STRBUF_INIT;
unsigned long size;
+ int type;
/*
* The type can be at most ten bytes (including the
* terminating '\0' that we add), and is followed by
* a space.
*/
- i = 0;
for (;;) {
char c = *hdr++;
if (c == ' ')
break;
- type[i++] = c;
- if (i = sizeof(type))
- return -1;
+ strbuf_addch(typename, c);
}
- type[i] = 0;
/*
* The length must follow immediately, and be in canonical
@@ -1652,12 +1677,39 @@ int parse_sha1_header(const char *hdr, unsigned long
*sizep)
size = size * 10 + c;
}
}
- *sizep = size;
+ type = type_from_string_gently(typename.buf, typename.len, 1);
+ if (oi-sizep)
+ *oi-sizep = size;
+ if (oi-typename)
+ strbuf_addbuf(oi-typename, typename);
+ strbuf_release(typename);
+
+ /*
+* Set type to 0 if its an unknown object and
+* we're obtaining the type using '--literally'
+* option.
+*/
+ if ((flags LOOKUP_LITERALLY) (type == -1))
+ type = 0;
+ else if (type == -1)
+ die(invalid object type);
+ if (oi-typep)
+ *oi-typep = type;
[PATCH v5 2/2] cat-file: teach cat-file a '--literally' option
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object which is
created using 'git hash-object --literally'. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of a broken/corrupt object without throwing
an error.
Modify '-t' and '-s' options to call sha1_object_info_extended()
directly to support the '--literally' option.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunshine@sunshineco
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/cat-file.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..6fee461 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -9,13 +9,20 @@
#include userdiff.h
#include streaming.h
-static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
+static int cat_one_file(int opt, const char *exp_type, const char *obj_name,
+ int literally)
{
unsigned char sha1[20];
enum object_type type;
char *buf;
unsigned long size;
struct object_context obj_context;
+ struct object_info oi = {NULL};
+ struct strbuf sb = STRBUF_INIT;
+ unsigned flags = LOOKUP_REPLACE_OBJECT;
+
+ if (literally)
+ flags |= LOOKUP_LITERALLY;
if (get_sha1_with_context(obj_name, 0, sha1, obj_context))
die(Not a valid object name %s, obj_name);
@@ -23,16 +30,24 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name)
buf = NULL;
switch (opt) {
case 't':
- type = sha1_object_info(sha1, NULL);
- if (type 0) {
- printf(%s\n, typename(type));
+ oi.typep = type;
+ oi.typename = sb;
+ if (sha1_object_info_extended(sha1, oi, flags) 0)
+ die(git cat-file: could not get object info);
+ if (sb.len) {
+ printf(%s\n, sb.buf);
+ strbuf_release(sb);
return 0;
}
break;
case 's':
- type = sha1_object_info(sha1, size);
- if (type 0) {
+ oi.typep = type;
+ oi.typename = sb;
+ oi.sizep = size;
+ if (sha1_object_info_extended(sha1, oi, flags) 0)
+ die(git cat-file: could not get object info);
+ if (sb.len) {
printf(%lu\n, size);
return 0;
}
@@ -323,7 +338,7 @@ static int batch_objects(struct batch_options *opt)
}
static const char * const cat_file_usage[] = {
- N_(git cat-file (-t | -s | -e | -p | type | --textconv) object),
+ N_(git cat-file (-t [--literally]|-s
[--literally]|-e|-p|type|--textconv) object),
N_(git cat-file (--batch | --batch-check) list-of-objects),
NULL
};
@@ -359,6 +374,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
int opt = 0;
const char *exp_type = NULL, *obj_name = NULL;
struct batch_options batch = {0};
+ int literally = 0;
const struct option options[] = {
OPT_GROUP(N_(type can be one of: blob, tree, commit, tag)),
@@ -369,6 +385,8 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
OPT_SET_INT('p', NULL, opt, N_(pretty-print object's
content), 'p'),
OPT_SET_INT(0, textconv, opt,
N_(for blob objects, run textconv on object's
content), 'c'),
+ OPT_BOOL( 0, literally, literally,
+ N_(get information about corrupt objects for
debugging Git)),
{ OPTION_CALLBACK, 0, batch, batch, format,
N_(show info and content of objects fed from the
standard input),
PARSE_OPT_OPTARG, batch_option_callback },
@@ -380,7 +398,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
git_config(git_cat_file_config, NULL);
- if (argc != 3 argc != 2)
+ if (argc 2 || argc 4)
usage_with_options(cat_file_usage, options);
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
@@ -405,5 +423,10 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
if (batch.enabled)
return batch_objects(batch);
- return cat_one_file(opt, exp_type, obj_name);
+ if (literally (opt == 't' || opt == 's'))
+ return cat_one_file(opt, exp_type, obj_name, literally);
+ else if (literally)
+ die(git cat-file --literally: use with -s or -t);
+
+ return cat_one_file(opt, exp_type, obj_name,
Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
On Tue, Mar 24, 2015 at 5:52 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Paul Tan pyoka...@gmail.com writes: Matthieu and Eric: I know I said I will try to re-order the patches to put the tests before the implementation, but after thinking and trying to rewrite the commit messages I realised it seems really weird to me. In this patch series, the implementation is split across the first two patches. The first patch should use the old tests, and ideally, the new tests should be squashed with the second patch because it seems more logical to me to implement the tests at the same time as the new feature. However, since the tests patch is very long, to make it easier to review it is split into a separate patch which is applied after the implementation patches. No problem, your version is very good. I was pointing out alternatives, but not requesting a change, and your reasoning makes perfect sense. I had reviewed v4 in details, and checked the diff between v4 and v5. The whole series is now Reviewed-by: Matthieu Moy matthieu@imag.fr With the POSIXPERM issue[1] addressed (if necessary), patch 3/3 is also: Reviewed-by: Eric Sunshine sunsh...@sunshineco.com [1]: http://article.gmane.org/gmane.comp.version-control.git/266265 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] cat-file: teach cat-file a '--literally' option
On 03/25/2015 01:12 PM, Eric Sunshine wrote: On Wed, Mar 25, 2015 at 3:22 AM, Karthik Nayak karthik@gmail.com wrote: Currently 'git cat-file' throws an error while trying to print the type or size of a broken/corrupt object which is created using 'git hash-object --literally'. This is because these objects are usually of unknown types. Teach git cat-file a '--literally' option where it prints the type or size of a broken/corrupt object without throwing an error. Modify '-t' and '-s' options to call sha1_object_info_extended() directly to support the '--literally' option. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Eric Sunshine sunshine@sunshineco Signed-off-by: Karthik Nayak karthik@gmail.com --- diff --git a/builtin/cat-file.c b/builtin/cat-file.c index df99df4..6fee461 100644 --- a/builtin/cat-file.c +++ b/builtin/cat-file.c @@ -405,5 +423,10 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix) if (batch.enabled) return batch_objects(batch); - return cat_one_file(opt, exp_type, obj_name); + if (literally (opt == 't' || opt == 's')) + return cat_one_file(opt, exp_type, obj_name, literally); + else if (literally) + die(git cat-file --literally: use with -s or -t); + + return cat_one_file(opt, exp_type, obj_name, literally); Although I haven't read the patch closely yet, this unnecessarily complex logic caught my eye as I was scanning the changes. If you check for the illegal option combination first, then you can coalesce the two identical cat_one_file() invocations, and this entire hunk reduces to the more readable: if (literally opt != 't' opt != 's') die(git cat-file --literally: use with -s or -t); return cat_one_file(opt, exp_type, obj_name, literally); } -- 2.3.1.170.g5319d60.dirty Hey Eric, Yes that could be done. When small fixes like these need to be done, Is it sufficient to reply to this mail with the fixed patch, or should I resend the whole patch series? Thanks, Karthik -- 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] git submodule purge
On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote: Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt: On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote: (+cc: Jens and Heiko, submodule experts) Hi, Patrick Steinhardt wrote: This proposal is just for discussion. If there is any interest I will implement the feature and send some patches. Currently it is hard to properly remove submodules. That is when a submodule is deinitialized and removed from a repository the directory '.git/modules/SM_NAME' will still be present and there is no way to remove it despite manually calling `rm` on it. I think there should be a command that is able to remove those dangling repositories if the following conditions are met: - the submodule should not be initialized - the submodule should not have an entry in .gitmodules in the currently checked out revision - the submodule should not contain any commits that are not upstream - the submodule should not contain other submodules that do not meet those conditions This would ensure that it is hard to loose any commits that may be of interest. In the case that the user knows what he is doing we may provide a '--force' switch to override those checks. Those conditions look simultaneously too strong and too weak. ;-) In principle, it should be safe to remove .git/modules/name as long as (1) it (and its submodules, sub-sub-modules, etc) doesn't have any un-pushed local commits. (2) it is not being referred to by a .git file in the work tree of the parent repository. Condition (1) can be relaxed if the user knows what they are losing and is okay with that. Condition (2) can be avoided by removing (de-initing) the copy of that submodule in the worktree at the same time. The functionality sounds like a useful thing to have, whether as an option to 'git submodule deinit' or as a new subcommand. In the long term I would like it to be possible to do everything 'git submodule' can do using normal git commands instead of that specialized interface. What command do you think this would eventually belong in? (An option to git gc, maybe?) Thanks, Jonathan Thanks for your feedback. Considering that purging the submodule is tightly coupled with de-initializing it, it might make sense to provide this functionality as part of `git submodule deinit`. Maybe something like `git submodule deinit --purge` would work for the user. Problem is if the user first removes the submodule and does not first deinitialize it he is not able to purge the repository afterwards as deinit will complain about the submodule not being matched anymore. We could just make `deinit --purge` work with removed submodules, but that does not feel very natural to me. Hmm, cmd_deinit() seems to cope with submodules removed by the user just fine (as long as they are still present in the index). To me it feels natural to extend deinit to remove the repo from .git/modules too when --purge is given (as long as no unpushed commits are present or -f is given). `git gc` feels saner in that regard, but I don't think it would be easy to spot for users as this command is in general not used very frequently by them. One could argue though that it does not need to be discoverable. The error message of git submodule deinit --purge for a submodule that isn't recorded in the index anymore could point the user to the appropriate gc command. But how do we tell gc which submodule it should purge? --purge=submodule-name maybe? This might work, but at least the option would need to provide a hint to the user that it has something to do with submodules. So if the feature was implemented by `git gc` I'd rather name the parameter --purge-submodule=submodule-name which in my opinion clearly states its intention, even though it is longer to type. But with working bash-completion this should be non-issue, especially as this command would not need to be run frequently. That said, I think by now I agree with the common (?) opinion that the command is best placed in `git submodule deinit --purge` and I will likely implement it there. Optionally I could implement `git gc --purge-submodule=submodule-name` as a second way to access the feature so that we have a way of purging them without using the submodules-interface. I doubt though that this will provide much of a benefit as the user still has to be aware that he is working with submodules as he has to provide the `--purge-submodule` option, so there is not much to be gained by this. Regards Patrick signature.asc Description: PGP signature
Re: [PATCH 3/8] t3305: fix ignored exit code inside loop
On Wed, Mar 25, 2015 at 6:28 AM, Jeff King p...@peff.net wrote: When we test deleting notes, we run git notes remove in a loop. However, the exit value of the loop will only reflect the final note we process. We should break out of the loop with a failing exit code as soon as we see a problem. Note that we can call exit 1 here without explicitly creating a subshell, because the while loop on the right-hand side of a pipe executes in its own implicit subshell. Note also that the break above does not suffer the same problem; it is meant to exit the loop early at a certain number of iterations. We can bump it into the conditional of the loop to make this more obvious. Signed-off-by: Jeff King p...@peff.net Acked-by: Johan Herland jo...@herland.net -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/2] cat-file: teach cat-file a '--literally' option
On Wed, Mar 25, 2015 at 3:22 AM, Karthik Nayak karthik@gmail.com wrote: Currently 'git cat-file' throws an error while trying to print the type or size of a broken/corrupt object which is created using 'git hash-object --literally'. This is because these objects are usually of unknown types. Teach git cat-file a '--literally' option where it prints the type or size of a broken/corrupt object without throwing an error. Modify '-t' and '-s' options to call sha1_object_info_extended() directly to support the '--literally' option. Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Eric Sunshine sunshine@sunshineco Signed-off-by: Karthik Nayak karthik@gmail.com --- diff --git a/builtin/cat-file.c b/builtin/cat-file.c index df99df4..6fee461 100644 --- a/builtin/cat-file.c +++ b/builtin/cat-file.c @@ -405,5 +423,10 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix) if (batch.enabled) return batch_objects(batch); - return cat_one_file(opt, exp_type, obj_name); + if (literally (opt == 't' || opt == 's')) + return cat_one_file(opt, exp_type, obj_name, literally); + else if (literally) + die(git cat-file --literally: use with -s or -t); + + return cat_one_file(opt, exp_type, obj_name, literally); Although I haven't read the patch closely yet, this unnecessarily complex logic caught my eye as I was scanning the changes. If you check for the illegal option combination first, then you can coalesce the two identical cat_one_file() invocations, and this entire hunk reduces to the more readable: if (literally opt != 't' opt != 's') die(git cat-file --literally: use with -s or -t); return cat_one_file(opt, exp_type, obj_name, literally); } -- 2.3.1.170.g5319d60.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
[RFC/GSoC v2] Proposal: Make git-pull and git-am builtins
Since the deadline is fast approaching, and I've read that google-melange usually becomes overwhelmed near the deadline, I'll try to iterate on the proposal as much as possible. Below is v2, mostly small changes in response to Matthieu's and Junio's reviews. The changes are as follows: * Make it clear that zero spawning of processes is an ideal -- it doesn't have to be so in practice. * Swap rewrite of git-pull and git-am in timeline. It is better to push the first patch to the mailing list as soon as possible. * Make it clear that as part of refactoring, commonly recurring patterns can be codified and implemented in the internal git API. * Add microproject v5. * Make it clear that Windows is not the only one that has poor IO performance. Poor IO performance can stem from the choice of operating system, filesystem and underlying storage performance. * Cite filesystem cache feature in git for windows. * Remove section-numbering directive, github messes it up. * State what the end-product of the final stage is. The updated version is also in the gist[1]. [1] https://gist.github.com/pyokagan/1b7b0d1f4dab6ba3cef1 --8-- Make `git-pull` and `git-am` builtins :Abstract: `git-pull` and `git-am` are frequently used git subcommands. However, they are porcelain commands and implemented as shell scripts, which has some limitations which can cause poor performance, especially in non-POSIX environments like Windows. I propose to rewrite these scripts into low level C code and make them builtins. This will increase git's portability, and may improve the efficiency and performance of these commands. .. section-numbering:: Limitations of shell scripts = `git-pull` is a commonly executed command to check for new changes in the upstream repository and, if there are, fetch and integrate them into the current branch. `git-am` is another commonly executed command for applying a series of patches from a mailbox to the current branch. They are both git porcelain commands -- they have no access to git's low level internal API. Currently, they are implemented by the shell scripts ``git-pull.sh`` and ``git-am.sh`` respectively. These shell scripts require a fully-functioning POSIX shell and utilities. As a result, these commands are difficult to port to non-POSIX environments like Windows. Since porcelain commands do not have access to git's internal API, performing any git-related function, no matter how trivial, requires git to be spawned in a separate process. This limitation leads to these git commands being relatively inefficient, and can cause long run times on certain platforms that do not have copy-on-write ``fork()`` semantics. Spawning processes can be slow --- Shell scripting, by itself, is severely limited in what it can do. Performing most operations in shell scripts require external executables to be called. For example, ``git-pull.sh`` spawns the git executable not only to perform complex git operations like `git-fetch` and `git-merge`, but it also spawns the git executable for trivial tasks such as retrieving configuration values with `git-config` and even quoting of command-line arguments with ``git rev-parse --sq-quote``. As a result, these shell scripts usually end up spawning a lot of processes. Process spawning is usually implemented as a ``fork()`` followed by an ``exec()`` by shells. This can be slow on systems that do not support copy-on-write semantics for ``fork()``, and thus needs to duplicate the memory of the parent process for every ``fork()`` call -- an expensive process. Furthermore, starting up processes on Windows is generally expensive as it performs `several extra steps`_ such as such as using an inter-process call to notify the Windows Client/Server Runtime Subsystem(CSRSS) about the process creation and checking for App Compatibility requirements. .. _`several extra steps`: http://www.microsoft.com/mspress/books/sampchap/4354a.aspx The official Windows port of git, Git for Windows, uses MSYS2 [#]_ to emulate ``fork()``. Since Windows does not support forking semantics natively, MSYS2 can only emulate ``fork()`` `without copy-on-write semantics`_. Coupled with Windows heavy process creation, this causes huge slowdowns of git on Windows. .. _`without copy-on-write semantics`: https://www.cygwin.com/faq.html#faq.api.fork A no-updates `git-pull`, for example, takes an average of 5.1s [#]_, as compared to Linux which only takes an average of 0.08s. 5 seconds, while seemingly short, would seem like an eternity to a user who just wants to quickly fetch and merge changes from upstream. `git-am`'s implementation reads each patch from the mailbox in a while loop, spawning many processes for each patch. Considering the cost of spawning each process, as well
Git Rev News edition 1 published
Hi, Git Rev News edition 1 is now available: http://git.github.io/rev_news/edition-1.html Thanks a lot to all the contributors and helpers, especially Junio! Enjoy, Christian and Thomas. -- 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
very weird behaviour with merge -s subtree
Hi everyone I'm totally stuck with a following problem: - we have a repo, which contains several projects as folders - like api, adminUI, android, web - etc. Some parts are backend, some frontend. Lets name these parts details, as they constitute details of the project in general. - we would like to deploy via git, so as to minimize effort on deployment (and automate it later). - but every project is deployed separately. From all I've read so far, I came to conclusion that merge -s subtree seems to be done with this thing in mind, although scenarios, described in articles like this one (https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html) usually take only one part of it: merge from detail to common, and not vice versa. So, what am I trying to: to implement a stable workflow, that would allow me to easily merge changes from develop in common repo to a subtree-branch and push to a corresponding detail remote. What I am doing: 1) say, we have a folder adminUI in the root of common repo, branch test (it's a snapshot branch for test environment - all deploys should start here) 2) git remote add adminui-origin path 3) git fetch adminui-origin 4) git checkout -B test-adminui adminui-origin/test (above steps are taken from http://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging) 5) git checkout test 6) git merge -s ours --no-commit test-adminui (this one is from https://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html) 7) git read-tree --prefix=adminUI/ -u test-adminui Here I always get error like: error: Entry 'adminUI/.gitignore' overlaps with 'adminUI/.gitignore'. Cannot bind. 8) so, I have to rename folder adminUI to, like, adminUI2, then git commit -a, then step 7 again 9) ok, so now I have a whole content of adminui-origin in folder /adminUI in branch test of my common repo. 10) then I merge changes from develop, which I want to deploy: git merge develop 11) then I want to merge those changes down the line into detail repo: git checkout test-adminui git merge -s subtree test 12) for the first time, everything seems fine - only relevant changes (i.e., changes in adminUI folder) are merged, and they go straight into their right places (i.e., with respect to folder structure difference between common and detail) 13) git push adminui-origin test-adminui:test - this works good 14) let's say something else was updated in develop: git checkout test git merge develop git checkout test-adminui 15) AND HERE BEGINS THE HELL: git merge -s subtree test = leads to ALL of my working directory being copied to a 3rd level folder somewhere in the adminUI depths !!! This drives me TOTALLY insane, and I very much need help !! I use msysgit 1.9.4 on Windows 8.1 I suspect that it might have to do with the repository structure, maybe some errors, etc.. But I believe that it might be due to my total misunderstanding of something Anyway, I totally appreciate your help ! Thanks a lot Kirill, frustrated unexperienced git user... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
Eric Sunshine sunsh...@sunshineco.com writes: On Tue, Mar 24, 2015 at 5:52 AM, Matthieu Moy ... Reviewed-by: Matthieu Moy matthieu@imag.fr With the POSIXPERM issue[1] addressed (if necessary), patch 3/3 is also: Reviewed-by: Eric Sunshine sunsh...@sunshineco.com THanks for a review. Paul, the 3-patch series is already in 'next', so please fix these up with a follow-up patch. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: about Starter project;implementing log --size in the print_commit function.
Shanti Swarup Tunga b112...@iiit-bh.ac.in writes:
I inserted a size variable of int type and calculated size in each
cases of print_commit(). The function is
static void print_commit(git_commit *commit)
{
...
}
See Documentation/SubmittingPatches and then also CodingGuidelines
Especially, explain:
- what does this change try to help and how?
- why is this patch a good way to achieve that goal?
- how the users are expected to use the new feature?
in the proposed log message, run existing tests to make sure your
change did not break the existing system, add tests to make sure
you would notice if somebody else broke the feature you are adding
in the future, and describe the new feature in the documentation.
Will that approach is going to work for the following problem.?
Was your message cut short? We cannot read the following problem
here...
--
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
About GSoc idea.
Hello Duy Nguyen and Stephen Robin , the two developers worked on converting git-pull.sh to C code . But in the idea page it is written that we should start with git-pull.sh. Should I worked on git-pull.sh or other shell script for the GSoc. -- 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 6/8] t: simplify loop exit-code status variables
On Wed, Mar 25, 2015 at 10:27:49AM -0700, Junio C Hamano wrote:
diff --git a/t/t3060-ls-files-with-tree.sh b/t/t3060-ls-files-with-tree.sh
index 61c1f53..36b10f7 100755
--- a/t/t3060-ls-files-with-tree.sh
+++ b/t/t3060-ls-files-with-tree.sh
@@ -25,15 +25,10 @@ test_expect_success setup '
do
num=00$n$m
sub/file-$num
- echo file-$num expected || {
- bad=t
- break
- }
- done test -z $bad || {
- bad=t
- break
- }
- done test -z $bad
+ echo file-$num expected ||
+ return 1
+ done
+ done
git add .
git commit -m add a bunch of files
The empty initialization for $bad can also go for this one, right?
Yeah, it can.
-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 6/8] t: simplify loop exit-code status variables
Jeff King p...@peff.net writes:
Since shell loops may drop the exit code of failed commands
inside the loop, some tests try to keep track of the status
by setting a variable. This can end up cumbersome and hard
to read; it is much simpler to just exit directly from the
loop using return 1 (since each case is either in a helper
function or inside a test snippet).
Signed-off-by: Jeff King p...@peff.net
---
t/t3060-ls-files-with-tree.sh | 13 -
t/t3901-i18n-patch.sh | 8 ++--
2 files changed, 6 insertions(+), 15 deletions(-)
diff --git a/t/t3060-ls-files-with-tree.sh b/t/t3060-ls-files-with-tree.sh
index 61c1f53..36b10f7 100755
--- a/t/t3060-ls-files-with-tree.sh
+++ b/t/t3060-ls-files-with-tree.sh
@@ -25,15 +25,10 @@ test_expect_success setup '
do
num=00$n$m
sub/file-$num
- echo file-$num expected || {
- bad=t
- break
- }
- done test -z $bad || {
- bad=t
- break
- }
- done test -z $bad
+ echo file-$num expected ||
+ return 1
+ done
+ done
git add .
git commit -m add a bunch of files
The empty initialization for $bad can also go for this one, right?
--
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/GSoC] Proposal: Make git-pull and git-am builtins
Paul Tan pyoka...@gmail.com writes: I think it's still good to have the ideal in mind though (and whoops I forgot to put in the word ideal in the text). Using or not using fork is merely one of the trade-offs we can make. If all other things are equal, no fork is better than a fork is a meaningless statement, as all other things are never equal in real life---doing things internally will have a cost of having to clean up and a risk to get that part wrong, for example. Engineering is a fine balancing act and setting an absolute goal is not a healthy attitude. -- 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/8] more -chaining test fixups
Jeff King p...@peff.net writes: There were a few legitimate problems, though. I've ordered the patches below by descending severity. These apply on top of jk/test-chain-lint. [1/8]: perf-lib: fix ignored exit code inside loop [2/8]: t0020: fix ignored exit code inside loops [3/8]: t3305: fix ignored exit code inside loop [4/8]: t7701: fix ignored exit code inside loop These four are actual bugs. [5/8]: t: fix some trivial cases of ignored exit codes in loops These ones are in setup code, and so would almost certainly never fail. [6/8]: t: simplify loop exit-code status variables [7/8]: t0020: use test_* helpers instead of hand-rolled messages [8/8]: t9001: drop save_confirm helper These last three are pure cleanup, no behavior changes. The last two are not even strictly related to the same topic, but I noticed them while in the area. Thanks. All looked sensible. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] l10n: de.po: fix messages with abbreviated hashs
The three dots in messages where the hash is abbreviated were misinterpreted and are fixed with this commit. Noticed-by: Junio C Hamano gits...@pobox.com Signed-off-by: Ralf Thielow ralf.thie...@gmail.com --- In v2 there's a space added between dots and brackets. po/de.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/de.po b/po/de.po index 7b30f62..a9b9124 100644 --- a/po/de.po +++ b/po/de.po @@ -1271,12 +1271,12 @@ msgstr Kann keine Commit-Beschreibung für %s bekommen #: sequencer.c:611 #, c-format msgid could not revert %s... %s -msgstr Konnte \revert\ nicht auf %s ausführen... %s +msgstr Konnte \revert\ nicht auf %s... (%s) ausführen #: sequencer.c:612 #, c-format msgid could not apply %s... %s -msgstr Konnte %s nicht anwenden... %s +msgstr Konnte %s... (%s) nicht anwenden #: sequencer.c:648 msgid empty commit set passed -- 2.3.4.526.g7d26d9e -- 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] git submodule purge
Am 25.03.2015 um 10:06 schrieb Patrick Steinhardt: On Mon, Mar 23, 2015 at 10:32:27PM +0100, Jens Lehmann wrote: Am 17.03.2015 um 08:56 schrieb Patrick Steinhardt: On Mon, Mar 16, 2015 at 01:03:53PM -0700, Jonathan Nieder wrote: (+cc: Jens and Heiko, submodule experts) Hi, Patrick Steinhardt wrote: This proposal is just for discussion. If there is any interest I will implement the feature and send some patches. Currently it is hard to properly remove submodules. That is when a submodule is deinitialized and removed from a repository the directory '.git/modules/SM_NAME' will still be present and there is no way to remove it despite manually calling `rm` on it. I think there should be a command that is able to remove those dangling repositories if the following conditions are met: - the submodule should not be initialized - the submodule should not have an entry in .gitmodules in the currently checked out revision - the submodule should not contain any commits that are not upstream - the submodule should not contain other submodules that do not meet those conditions This would ensure that it is hard to loose any commits that may be of interest. In the case that the user knows what he is doing we may provide a '--force' switch to override those checks. Those conditions look simultaneously too strong and too weak. ;-) In principle, it should be safe to remove .git/modules/name as long as (1) it (and its submodules, sub-sub-modules, etc) doesn't have any un-pushed local commits. (2) it is not being referred to by a .git file in the work tree of the parent repository. Condition (1) can be relaxed if the user knows what they are losing and is okay with that. Condition (2) can be avoided by removing (de-initing) the copy of that submodule in the worktree at the same time. The functionality sounds like a useful thing to have, whether as an option to 'git submodule deinit' or as a new subcommand. In the long term I would like it to be possible to do everything 'git submodule' can do using normal git commands instead of that specialized interface. What command do you think this would eventually belong in? (An option to git gc, maybe?) Thanks, Jonathan Thanks for your feedback. Considering that purging the submodule is tightly coupled with de-initializing it, it might make sense to provide this functionality as part of `git submodule deinit`. Maybe something like `git submodule deinit --purge` would work for the user. Problem is if the user first removes the submodule and does not first deinitialize it he is not able to purge the repository afterwards as deinit will complain about the submodule not being matched anymore. We could just make `deinit --purge` work with removed submodules, but that does not feel very natural to me. Hmm, cmd_deinit() seems to cope with submodules removed by the user just fine (as long as they are still present in the index). To me it feels natural to extend deinit to remove the repo from .git/modules too when --purge is given (as long as no unpushed commits are present or -f is given). `git gc` feels saner in that regard, but I don't think it would be easy to spot for users as this command is in general not used very frequently by them. One could argue though that it does not need to be discoverable. The error message of git submodule deinit --purge for a submodule that isn't recorded in the index anymore could point the user to the appropriate gc command. But how do we tell gc which submodule it should purge? --purge=submodule-name maybe? This might work, but at least the option would need to provide a hint to the user that it has something to do with submodules. So if the feature was implemented by `git gc` I'd rather name the parameter --purge-submodule=submodule-name which in my opinion clearly states its intention, even though it is longer to type. But with working bash-completion this should be non-issue, especially as this command would not need to be run frequently. Agreed. That said, I think by now I agree with the common (?) opinion that the command is best placed in `git submodule deinit --purge` and I will likely implement it there. Me thinks that makes sense. But be aware that this will only work for those submodules that are still present in the current index. Optionally I could implement `git gc --purge-submodule=submodule-name` as a second way to access the feature so that we have a way of purging them without using the submodules-interface. I doubt though that this will provide much of a benefit as the user still has to be aware that he is working with submodules as he has to provide the `--purge-submodule` option, so there is not much to be gained by this. Hmm, I still believe cleaning up a submodule repo which is already deinited makes sense. Using 'rm -rf .git/modules/submodulename' will work just fine, but is missing any safeguards. The deinit command takes submodule paths, not submodule
Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
Am 25.03.2015 um 07:42 schrieb Eric Sunshine: On Tue, Mar 24, 2015 at 1:20 AM, Paul Tan pyoka...@gmail.com wrote: t0302 now tests git-credential-store's support for the XDG user-specific configuration file $XDG_CONFIG_HOME/git/credentials. Specifically: * Ensure that the XDG file is strictly opt-in. It should not be created by git at all times if it does not exist. * Conversely, if the XDG file exists, ~/.git-credentials should not be created at all times. * If both the XDG file and ~/.git-credentials exists, then both files should be used for credential lookups. However, credentials should only be written to ~/.git-credentials. * Credentials must be erased from both files. * $XDG_CONFIG_HOME can be a custom directory set by the user as per the XDG base directory specification. Test that git-credential-store respects that, but defaults to ~/.config/git/credentials if it does not exist or is empty. Helped-by: Matthieu Moy matthieu@grenoble-inp.fr Helped-by: Junio C Hamano gits...@pobox.com Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Paul Tan pyoka...@gmail.com --- diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh index f61b40c..4e1f8ec 100755 --- a/t/t0302-credential-store.sh +++ b/t/t0302-credential-store.sh @@ -6,4 +6,118 @@ test_description='credential-store tests' helper_test store +test_expect_success 'get: use xdg file if home file is unreadable' ' I meant to mention this earlier. Does this test need to be protected by the POSIXPERM prerequisite since it's using chmod? test_expect_success POSIXPERM 'get: ... unreadable' ' Otherwise, the test will likely fail on Windows. Well spotted! The test indeed fails on Windows. POSIXPERM is required. + echo https://home-user:home-p...@example.com; $HOME/.git-credentials + chmod -r $HOME/.git-credentials + mkdir -p $HOME/.config/git + echo https://xdg-user:xdg-p...@example.com; $HOME/.config/git/credentials + check fill store -\EOF + protocol=https + host=example.com + -- + protocol=https + host=example.com + username=xdg-user + password=xdg-pass + -- + EOF +' -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] sha1_file.c: support reading from a loose object of unknown type
Karthik Nayak karthik@gmail.com writes:
+ if ((flags LOOKUP_LITERALLY)) {
+ if (unpack_sha1_header_to_strbuf(stream, map, mapsize,
hdrbuf) 0)
+ status = error(unable to unpack %s header with
--literally,
+sha1_to_hex(sha1));
+ else if ((status = parse_sha1_header_extended(hdrbuf.buf, oi,
flags)) 0)
+ status = error(unable to parse %s header,
sha1_to_hex(sha1));
+ } else {
+ if (unpack_sha1_header(stream, map, mapsize, hdr, sizeof(hdr))
0)
+ status = error(unable to unpack %s header,
+sha1_to_hex(sha1));
+ else if ((status = parse_sha1_header_extended(hdr, oi, flags))
0)
+ status = error(unable to parse %s header,
sha1_to_hex(sha1));
+ }
I wonder if you can further reduce an unnecessary duplication in the
two else if clauses in the above, and if the result becomes easier
to read and maintain. Perhaps
if (((flags LOOKUP_LITERALLY)
? unpack_sha1_header_to_strbuf(...)
: unpack_sha1_header(...)) 0)
status = error(...);
else if ((status = parse_sha1_header_extended(...)) 0)
status = error(...);
or even
status = 0;
if (flags LOOKUP_LITERALLY) {
if (unpack_sha1_header_to_strbuf(...) 0)
status = error(...);
} else {
if (unpack_sha1_header(...) 0)
status = error(...);
}
if (!status) {
if (status = parse(...)) 0)
status = error(...);
}
although I think the latter might be a bit harder to read.
--
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 RFC] init-db: introduce new -c/--config option
Hello All, I'm not sure about two things: 1. Is there any way to do this with the current git? At least i didn't find how to do it, so decided to write this patch. If there is already ability to do the same without this patch, please let me know. 2. Now current patch overwrite the value of the configuration option from config, if there is given option with the same key. For example, when we do git init, .git/config contains core.filemode = true. If we will pass core.filemode = false with this patch to git init, there will be core.filemode = false in the .git/config. So, I'm not sure about it. I looked on git clone -c/--config, it just adds the same option to the .git/config, but it looks strange to me So, I'm wating for any feedback. Thank you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] sha1_file.c: support reading from a loose object of unknown type
Karthik Nayak karthik@gmail.com writes:
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ status = unpack_sha1_header(stream, map, mapsize, buffer, bufsiz);
+
+ if (status) {
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ return status;
+ }
+
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status == Z_OK);
+ return -1;
A caller of unpack_sha1_header() gets the return from git_inflate();
I wonder if we should be returning status here for consistency,
perhaps?
--
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] init-db: introduce new -c/--config option
For now we can clone repository with the `git clone` command and pass
-c/--config with configuration option to it and these configuration
options will be set in the clonned repository config.
This patch provides the same functional, but for the `git init` command.
It allows to pass -c/--config option to the `git init` command and
given configuration option will be added to the newly created repository,
after it will be created.
This option can be used multiply times. If given configuration option
is the same that in the default config, given option will overwrite.
Main purpose of this option is to get rid of the manual editing of
the config.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
Documentation/git-init.txt | 11 ++-
builtin/init-db.c | 33 +++--
t/t0001-init.sh| 16
3 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 8174d27..3ecbf2a 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git init' [-q | --quiet] [--bare] [--template=template_directory]
- [--separate-git-dir git dir]
+ [--separate-git-dir git dir] [--config key=value]
[--shared[=permissions]] [directory]
@@ -111,6 +111,15 @@ into it.
If you provide a 'directory', the command is run inside it. If this directory
does not exist, it will be created.
+--config key=value::
+-c key=value::
+Set a new configuration option in the new repository. The key expected in
+the same format as linkgit:git-config[1] (e.g., `core.eol=true`). If
+This option can be used multiply times. If multiply options are given with
+the same keys, each value will be written to the config. If given key is
+the same that used in the default configuration file, previous value
+will be overwritten.
+
--
TEMPLATE DIRECTORY
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 280454a..184de40 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -471,6 +471,26 @@ static const char *const init_db_usage[] = {
NULL
};
+static int write_one_config(const char *key, const char *value, void *data) {
+ char *v = NULL;
+ git_config_get_string(key, v);
+ if (v) {
+ git_config_set(key, value);
+ return 1
+ } else
+ return git_config_set_multivar(key, value ? value : true,
^$, 0);
+}
+
+static void write_config(struct string_list *config){
+ int i;
+
+ for (i = 0; i config-nr; i++) {
+ if (git_config_parse_parameter(config-items[i].string,
+ write_one_config, NULL) 0)
+ die(unable to write parameters to config file);
+ }
+}
+
/*
* If you want to, you can share the DB area with any number of branches.
* That has advantages: you can save space by sharing all the SHA1 objects.
@@ -479,11 +499,13 @@ static const char *const init_db_usage[] = {
*/
int cmd_init_db(int argc, const char **argv, const char *prefix)
{
+ int ret;
const char *git_dir;
const char *real_git_dir = NULL;
const char *work_tree;
const char *template_dir = NULL;
unsigned int flags = 0;
+ static struct string_list option_config;
const struct option init_db_options[] = {
OPT_STRING(0, template, template_dir,
N_(template-directory),
N_(directory from which templates will be
used)),
@@ -496,6 +518,8 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
OPT_BIT('q', quiet, flags, N_(be quiet), INIT_DB_QUIET),
OPT_STRING(0, separate-git-dir, real_git_dir, N_(gitdir),
N_(separate git dir from working tree)),
+ OPT_STRING_LIST('c', config, option_config, N_(key=value),
+ N_(set config inside the new repository)),
OPT_END()
};
@@ -592,6 +616,11 @@ int cmd_init_db(int argc, const char **argv, const char
*prefix)
}
set_git_dir_init(git_dir, real_git_dir, 1);
-
- return init_db(template_dir, flags);
+ ret = init_db(template_dir, flags);
+ /*
+* new repository already created, so we can update .git/config if
+* -c/--config passed
+*/
+ write_config(option_config);
+ return ret;
}
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index 7de8d85..8ce3537 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -339,4 +339,20 @@ test_expect_success SYMLINKS 're-init to move gitdir
symlink' '
test_path_is_dir realgitdir/refs
'
+test_expect_success 'git init -c key=value' '
+ rm -rf newdir realgitdir
+ git init -c core.foo=bar newdir
+ echo bar expect
+ git --git-dir=newdir/.git config core.foo actual
+ test_cmp expect
Re: [PATCH RFC] init-db: introduce new -c/--config option
On Thu, Mar 26, 2015 at 12:30:13AM +0600, Alexander Kuleshov wrote: I'm not sure about two things: 1. Is there any way to do this with the current git? At least i didn't find how to do it, so decided to write this patch. If there is already ability to do the same without this patch, please let me know. The reason we originally added -c to clone and not init is that clone performs several other follow-on actions after the repository is initialized. For example, you might want to run: git clone -c core.autocrlf=true ... to have that option in place before clone checks out files to the working tree. There is no direct way to have git init set the config for you, but there is no harm in doing: git init git config core.autocrlf=true because init returns control to you immediatel. 2. Now current patch overwrite the value of the configuration option from config, if there is given option with the same key. For example, when we do git init, .git/config contains core.filemode = true. If we will pass core.filemode = false with this patch to git init, there will be core.filemode = false in the .git/config. So, I'm not sure about it. I looked on git clone -c/--config, it just adds the same option to the .git/config, but it looks strange to me Most options, when there are multiple present, will use the last-seen value (core.filemode is one of these, so having it there twice means the second one takes precedence). Some options form a list (e.g., fetch refspecs). So if you run: git clone -c remote.origin.fetch=refs/notes/*:refs/notes/* ... you add a new refspec, but do not replace the default one to fetch the actual branches. The knowledge of which config keys are which is known only to the config callbacks, so it is generally safer for generic config-munging code to add a potentially overriding key (the downside is that you cannot use -c to clear a list-like key, but the inability to do that is a failing of the config code in general). -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, RFC] checkout: Attempt to checkout submodules
Am 24.03.2015 um 19:30 schrieb Trevor Saunders: On Mon, Mar 23, 2015 at 09:01:48PM +0100, Jens Lehmann wrote: Using -f here is ok when you extend the appropriate verify functions in unpack-trees.c to check that no modifications will be lost (unless the original checkout is used with -f). See the commit 76dbdd62 (submodule: teach unpack_trees() to update submodules) in my github repo at https://github.com/jlehmann/git-submod-enhancements for the basic concept (There is already a fixup! for that a bit further down the branch which handles submodule to file conversion, maybe one or two other changes will be needed when the test suite covers all relevant cases). ah, I see your already working a more complete solution to this sort of issue. I'll get out of your way then unless you want help. Help would be very much appreciated. I'm currently separating teaching the builtin commands to recursively update submodules from my branch to submit these changes first. The reason for that is not only that there are current efforts to make pull and am builtin commands, but that we need an extension to git diff for the scripted commands to work. If you could help implementing --ignore-submodules=noupdate (which would only ignore changes to those submodules that are not going to be updated) while I'm working on the builtin commands, that would help a lot. This would enable the scripted commands (e.g. rebase) to not ignore changes to submodules that are supposed to be updated (like they still do in the current version of my branch). And another pair of eyes on code and tests would also be very good to have. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] init-db: introduce new -c/--config option
On Wed, Mar 25, 2015 at 2:22 PM, Alexander Kuleshov kuleshovm...@gmail.com wrote: For now we can clone repository with the `git clone` command and pass -c/--config with configuration option to it and these configuration options will be set in the clonned repository config. s/clonned/cloned/ This patch provides the same functional, but for the `git init` command. s/functional/functionality/ It allows to pass -c/--config option to the `git init` command and given configuration option will be added to the newly created repository, after it will be created. This option can be used multiply times. If given configuration option s/multiply/multiple/ is the same that in the default config, given option will overwrite. Main purpose of this option is to get rid of the manual editing of the config. Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt index 8174d27..3ecbf2a 100644 --- a/Documentation/git-init.txt +++ b/Documentation/git-init.txt @@ -111,6 +111,15 @@ into it. If you provide a 'directory', the command is run inside it. If this directory does not exist, it will be created. +--config key=value:: +-c key=value:: +Set a new configuration option in the new repository. The key expected in +the same format as linkgit:git-config[1] (e.g., `core.eol=true`). If If what? +This option can be used multiply times. If multiply options are given with s/multiply/multiple/g +the same keys, each value will be written to the config. If given key is +the same that used in the default configuration file, previous value +will be overwritten. diff --git a/t/t0001-init.sh b/t/t0001-init.sh index 7de8d85..8ce3537 100755 --- a/t/t0001-init.sh +++ b/t/t0001-init.sh @@ -339,4 +339,20 @@ test_expect_success SYMLINKS 're-init to move gitdir symlink' ' test_path_is_dir realgitdir/refs ' +test_expect_success 'git init -c key=value' ' + rm -rf newdir realgitdir + git init -c core.foo=bar newdir + echo bar expect + git --git-dir=newdir/.git config core.foo actual Maybe git -C newdir ... instead? + test_cmp expect actual +' + +test_expect_success 'git init -c key=value override default value' ' + rm -rf newdir + git init -c core.filemode=false newdir + echo false expect + git --git-dir=newdir/.git config core.filemode actual + test_cmp expect actual git-init automatically detects an appropriate value for core.filemode, so this test may not be telling us anything useful on some platforms. +' + test_done -- 2.3.3.611.g09038fc.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 v2] userdiff: funcname and word patterns for sh
Adrien Schildknecht adrien+...@schischi.me writes: Add regexp based on the Shell Command Language specifications. Because of the lax syntax of sh, some corner cases may not be handled properly. Signed-off-by: Adrien Schildknecht adrien+...@schischi.me --- Is a reroll for this patch coming, or should I drop this from my tree for now? Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] sha1_file.c: support reading from a loose object of unknown type
On 03/26/2015 12:57 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com writes:
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ status = unpack_sha1_header(stream, map, mapsize, buffer, bufsiz);
+
+ if (status) {
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ return status;
+ }
+
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status == Z_OK);
+ return -1;
A caller of unpack_sha1_header() gets the return from git_inflate();
I wonder if we should be returning status here for consistency,
perhaps?
Although the caller only checks for negative values for failure. For
consistency it would be better to return status as unpack_sha1_header()
does.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
Junio C Hamano gits...@pobox.com writes: Eric Sunshine sunsh...@sunshineco.com writes: On Tue, Mar 24, 2015 at 5:52 AM, Matthieu Moy ... Reviewed-by: Matthieu Moy matthieu@imag.fr With the POSIXPERM issue[1] addressed (if necessary), patch 3/3 is also: Reviewed-by: Eric Sunshine sunsh...@sunshineco.com THanks for a review. Paul, the 3-patch series is already in 'next', so please fix these up with a follow-up patch. Thanks. I've already queued the following and merged it to 'next'. -- 8 -- From: Junio C Hamano gits...@pobox.com Date: Wed, 25 Mar 2015 13:23:21 -0700 Subject: [PATCH] t0302: unreadable test needs POSIXPERM Noticed and fixed by Eric Sunshine, confirmed by Johannes Sixt. Signed-off-by: Junio C Hamano gits...@pobox.com --- t/t0302-credential-store.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh index 4e1f8ec..0979df9 100755 --- a/t/t0302-credential-store.sh +++ b/t/t0302-credential-store.sh @@ -75,7 +75,7 @@ test_expect_success 'get: use xdg file if home file has no matches' ' EOF ' -test_expect_success 'get: use xdg file if home file is unreadable' ' +test_expect_success POSIXPERM 'get: use xdg file if home file is unreadable' ' echo https://home-user:home-p...@example.com; $HOME/.git-credentials chmod -r $HOME/.git-credentials mkdir -p $HOME/.config/git -- 2.3.4-462-gc8eeafd -- 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/GSoC] Proposal: Make git-pull and git-am builtins
On 24.03.2015 17:37, Paul Tan wrote: I'm applying for git in the Google Summer of Code this year. For my project, I propose to rewrite git-pull.sh and git-am.sh into fast optimized C builtins. I've already hacked up a prototype of a builtin git-pull in [1], and it showed a promising 8x improvement in execution time on Windows. I cannot thank you enough for starting this effort. As one of the project owners of Git for Windows I can confirm the (shell) script Git commands to be a major source of pain. I really hope your proposal gets accepted and you'll be able to successfully complete this task. All the best! -- Sebastian Schuberth -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] sha1_file.c: support reading from a loose object of unknown type
karthik nayak karthik@gmail.com writes: I hope you meant the former. I did mean the latter, which spends more lines without much information (i.e. only closing braces), only to reduce the duplication of two simple lines. But you are right, I did miss the distinction between hdrbuf.buf and hdr, so they are not identically duplicated. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/2] sha1_file.c: support reading from a loose object of unknown type
On 03/26/2015 12:43 AM, Junio C Hamano wrote:
Karthik Nayak karthik@gmail.com writes:
+ if ((flags LOOKUP_LITERALLY)) {
+ if (unpack_sha1_header_to_strbuf(stream, map, mapsize, hdrbuf)
0)
+ status = error(unable to unpack %s header with
--literally,
+ sha1_to_hex(sha1));
+ else if ((status = parse_sha1_header_extended(hdrbuf.buf, oi,
flags)) 0)
+ status = error(unable to parse %s header,
sha1_to_hex(sha1));
+ } else {
+ if (unpack_sha1_header(stream, map, mapsize, hdr, sizeof(hdr))
0)
+ status = error(unable to unpack %s header,
+ sha1_to_hex(sha1));
+ else if ((status = parse_sha1_header_extended(hdr, oi, flags))
0)
+ status = error(unable to parse %s header,
sha1_to_hex(sha1));
+ }
I wonder if you can further reduce an unnecessary duplication in the
two else if clauses in the above, and if the result becomes easier
to read and maintain. Perhaps
if (((flags LOOKUP_LITERALLY)
? unpack_sha1_header_to_strbuf(...)
: unpack_sha1_header(...)) 0)
status = error(...);
else if ((status = parse_sha1_header_extended(...)) 0)
status = error(...);
or even
status = 0;
if (flags LOOKUP_LITERALLY) {
if (unpack_sha1_header_to_strbuf(...) 0)
status = error(...);
} else {
if (unpack_sha1_header(...) 0)
status = error(...);
}
if (!status) {
if (status = parse(...)) 0)
status = error(...);
}
although I think the latter might be a bit harder to read.
I hope you meant the former. The latter to me seems simpler as its a
simple if else statement whereas the former has a ternary operator with
function calls. I did think about this when writing the code, the
problem is when flag == LOOKUP_LITERALLY, parse_sha1_header_extended()
takes 'hdrbuf.buf' as first argument where as when flag !=
LOOKUP_LITERALLY, it takes 'hdr' as an argument. We could do this
status = 0;
char * hdrp;
if (flags LOOKUP_LITERALLY) {
if (unpack_sha1_header_to_strbuf(...) 0)
status = error(...);
hdrp = hdrbuf.buf;
} else {
if (unpack_sha1_header(...) 0)
status = error(...);
hdrp = hdr;
}
if (!status)
if (status = parse(hdrp, ...)) 0)
status = error(...);
}
But I think it just introduces another variable to keep track of, which
I rather not have.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] numparse module: systematically tighten up integer parsing
On 03/24/2015 05:49 PM, René Scharfe wrote: Am 24.03.2015 um 17:06 schrieb Michael Haggerty: Parsing numbers is not rocket science, but there are a lot of pitfalls, especially around overflow. It's even harder to write such code via macros and the result is less readable. This patch series is mostly about finding a reasonable API and whipping the callers into shape. That seems ambitious enough for me. I'd rather stick with boring wrappers for now and lean on strtol()/strtoul() to do the dirty work. It will be easy for a motivated person to change the implementation later. The OpenBSD developers invented strtonum for that. Are you aware of it? Would it fit? This discussion may be useful: http://www.tedunangst.com/flak/post/the-design-of-strtonum I wasn't aware of strtonum; thanks for the reference. It has an untraditional interface. Their willingness to sacrifice half of the unsigned range and requirement that the user specify minval and maxval have the nice effect of permitting one function to be used for all integer types. I think git will need more flexibility, for example to support other radixes and to allow trailing characters. So personally I don't think we should use (or imitate) strtonum(). Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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: per-repository and per-worktree config variables
Am 18.03.2015 um 22:33 schrieb Max Kirillov: On Sun, Feb 08, 2015 at 09:36:43AM -0800, Jens Lehmann wrote: I wonder if it's worth all the hassle to invent new names. Wouldn't it be much better to just keep a list of per-worktree configuration value names and use that inside the config code to decide where to find them for multiple work trees. That would also work easily for stuff like EOL-config and would push the complexity in the config machinery and not onto the user. I actually thought about the same, and now tend to think that most of config variables make sense to be per-worktree in some cases. Only few variable must always be per repository. I tried to summarize the variables which now (in current pu) should be common, also listed all the rest so somebody could scan through the list and spot anything I could miss. Thanks for your effort! Looks like my suspicion that not only submodule specific configuration should be kept per worktree wasn't completely wrong ;-) Me thinks Duy's proposal to configure the per worktree settings in a config file might make lots of sense. We could then provide a default version of that file with settings that fit most use cases and the user could then adapt that to her special needs if needed. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] [PATCH] infinite loop due to broken symlink
Michael Haggerty mhag...@alum.mit.edu writes: Thanks for the bug report. I can confirm the problem. In fact, I noticed the same problem when I was working on a refactoring in the area, but I still haven't submitted those patches. Thanks. It is nice to know that the refs.c API refactoring is still being worked on. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/14] numparse module: systematically tighten up integer parsing
Michael Haggerty mhag...@alum.mit.edu writes: [jc: dropped a non-working address from Cc list] I wasn't aware of strtonum; thanks for the reference. It has an untraditional interface. Their willingness to sacrifice half of the unsigned range and requirement that the user specify minval and maxval have the nice effect of permitting one function to be used for all integer types. ... I think git will need more flexibility, for example to support other radixes and to allow trailing characters. So personally I don't think we should use (or imitate) strtonum(). I had the same impression. An earlier suggestion by Peff about uintmax_t may be something we might want to keep in mind; we might want to use strtoll/strtoull as the underlying implementation if we wanted to avoid rolling our own. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Add revision range support on - and @{-1}
Kenny Lee Sin Cheong kenny.le...@gmail.com writes: If I'm understanding correctly, the problem of checking revisions before arg is that an option fed to handle_revision_arg() might die() before getting checked as an option in cases where a file with the same name exists? But doesn't verify_non_filename() already return silently if arg begins with -? It die() only after making that check. If an option with .. in it such as -$opt..ion is really given to handle_revision_arg() then verify_non_filename should not be a problem. Yes, but should we be relying on that behaviour? The special casing to assume that no sane person would name a file starting with a dash is what I find somewhat disturbing. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] [PATCH] infinite loop due to broken symlink
On 03/23/2015 05:04 PM, Petr Stodulka wrote:
git goes into an infinite loop due to broken symlink (minimal reproducer
[0]). Affected code is in function
resolve_ref_unsafe in file refs.c - notice 'stat_ref'. There is comment
about problem with race condition, hovewer in that case it's regular broken
symlink which cause infinite loop.
Thanks for the bug report. I can confirm the problem. In fact, I noticed
the same problem when I was working on a refactoring in the area, but I
still haven't submitted those patches. Luckily, modern Git doesn't use
symlinks in the loose reference hierarchy, so most users will never
encounter this problem.
In fact I think it is only the open() call that can lead to the infinite
loop. Meanwhile, there is another problem caused by falling through the
symlink-handling code, namely that st reflects the lstat() of the
symlink rather than the stat() of the file that it points to.
My approach was to run stat() on the path if the symlink-handling code
falls through. You can see my work in progress in my GitHub repo [1].
Possible patch could be something
like this:
---
diff --git a/refs.c b/refs.c
index e23542b..9efe8d2 100644
--- a/refs.c
+++ b/refs.c
@@ -1356,6 +1356,7 @@ static struct ref_dir *get_loose_refs(struct
ref_cache *refs)
/* We allow recursive symbolic refs. Only within reason, though */
#define MAXDEPTH 5
#define MAXREFLEN (1024)
+#define MAXLOOP 1024
/*
* Called by resolve_gitlink_ref_recursive() after it failed to read
@@ -1482,6 +1483,7 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
char buffer[256];
static char refname_buffer[256];
int bad_name = 0;
+int loop_counter = 0;
if (flags)
*flags = 0;
@@ -1546,7 +1548,8 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
if (S_ISLNK(st.st_mode)) {
len = readlink(path, buffer, sizeof(buffer)-1);
if (len 0) {
- if (errno == ENOENT || errno == EINVAL)
+ if (loop_counter++ MAXLOOP
+(errno == ENOENT || errno == EINVAL))
/* inconsistent with lstat;
retry */
goto stat_ref;
else
@@ -1579,7 +1582,7 @@ const char *resolve_ref_unsafe(const char
*refname, int resolve_flags, unsigned
*/
fd = open(path, O_RDONLY);
if (fd 0) {
- if (errno == ENOENT)
+ if (loop_counter++ MAXLOOP errno == ENOENT)
/* inconsistent with lstat; retry */
goto stat_ref;
else
---
If I understand well that simple check of broken symlink is not possible
due to race conditions.
This change also prevents the infinite loop, in fact in a more failproof
way that doesn't depend on errno values being interpreted correctly. I
would suggest a few stylistic changes, like for example here [2]. On the
other hand, this change doesn't solve the lstat()/stat() problem.
Nevertheless, I wouldn't object to a fix like this being accepted in
addition to the stat() fix when it's ready. It doesn't hurt to wear both
a belt *and* suspenders.
Michael
[1] https://github.com/mhagger/git, branch wip/refactor-resolve-ref.
See especially commit d2425d8ac8cf73494b318078b92f5b1c510a68fb.
[2] https://github.com/mhagger/git, branch ref-broken-symlinks
--
Michael Haggerty
mhag...@alum.mit.edu
--
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] Documentation: Add target to build PDF manpages
Philip Oakley philipoak...@iee.org wrote: I'd expect 'git help --pdf git' to simply feed the path of git.pdf (probably in the same directory as the .html versions) to the web browser and let it determine the users prefered reader. Yes, this is what I would do as well. Unfortunately I don’t really know C, so I can’t implement this. But for someone who is familiar with C, it should be easy---just call `xdg-open` (X11), `open` (OS X) or `start` (Windows) and thus the user’s preferred PDF reader, and maybe some common programs (evince, okular, …) as fallback. Junio C Hamano gits...@pobox.com wrote: I didn't see (and I still do not quite see) why people would want to have separate pdf files for all the subcommands (instead of say an .epub or .pdf that binds all the man pages and perhaps user-manual, just like we do for .texi/.info). Because it’s a good start :-) I see your point, and I agree that a combined PDF/EPUB/etc would make more sense. This should be not too difficult with the AsciiDoc-DocBook-Toolchain (or maybe even without DocBook), I just need to dig into it a bit further. -- 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/GSoC] Proposal: Make git-pull and git-am builtins
On Thu, Mar 26, 2015 at 1:54 AM, Junio C Hamano gits...@pobox.com wrote: Paul Tan pyoka...@gmail.com writes: I think it's still good to have the ideal in mind though (and whoops I forgot to put in the word ideal in the text). Using or not using fork is merely one of the trade-offs we can make. If all other things are equal, no fork is better than a fork is a meaningless statement, as all other things are never equal in real life---doing things internally will have a cost of having to clean up and a risk to get that part wrong, for example. Engineering is a fine balancing act and setting an absolute goal is not a healthy attitude. No, I do not mean all other things are equal, I meant all other things are ideal, meaning that human factors are not involved. I thought we were in agreement that calling functions in the internal API is technically superior to forking, assuming that there are no bugs or errors. Isn't this one of the reasons why libgit2 exists? If for whatever reason spawning an external git process is chosen, it would be because rewriting all the code paths without committing any errors would take too much effort. I will switch the word requirements to the word guidelines to make it sound less strict. However my above point still stands. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/3] t0302: test credential-store support for XDG_CONFIG_HOME
On Wed, Mar 25, 2015 at 01:25:07PM -0700, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I've already queued the following and merged it to 'next'. Thanks Matthieu and Eric for your reviews, and Johannes for following up on this. Will keep in view XDG support for ~/.git-credential-cache next because I don't like to leave things unfinished, unless we want to keep it around as a microproject. Perhaps home_config_paths() can also be simplified/removed because it hardcodes '~/.gitconfig'. Regards, Paul -- 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] gitk: Improve readability of highlighted text
Selected text is indicated by displaying a rectangle under the selected
text. When the default background color of dark blue is used for the
selection rectangle, it does not have sufficient contrast with the default
text color of black, and the highlighted text cannot be read easily.
To fix this, determine the HSV value of the selection background color.
Then, set the color of the selected text based on that value -- white if
the value is less than 0.6, black otherwise. This ensures that there is
sufficent contrast to make the text readable over the background color.
Also tag all selected text with secseltext, so that it can be reverted to
the default color on a change of selection.
---
gitk | 44
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 9a2daf3..0a5423a 100755
--- a/gitk
+++ b/gitk
@@ -2464,7 +2464,8 @@ proc makewindow {} {
pack .bright.sb -side right -fill y
pack $cflist -side left -fill both -expand 1
$cflist tag configure highlight \
- -background [$cflist cget -selectbackground]
+ -background [$cflist cget -selectbackground] \
+ -foreground [getseltextcolor [$cflist cget -selectbackground]]
$cflist tag configure bold -font mainfontbold
.pwbottom add .bright
@@ -7188,21 +7189,44 @@ proc dispnexttag {} {
}
proc make_secsel {id} {
-global linehtag linentag linedtag canv canv2 canv3
+global linehtag linentag linedtag canv canv2 canv3 fgcolor
if {![info exists linehtag($id)]} return
-$canv delete secsel
+
+allcanvs delete secsel
+
+set textfill [getseltextcolor [$canv cget -selectbackground]]
+foreach t [$canv find withtag secseltext] {
+ $canv itemconf $t -fill $fgcolor
+ $canv dtag $t secseltext
+}
set t [eval $canv create rect [$canv bbox $linehtag($id)] -outline {{}} \
-tags secsel -fill [$canv cget -selectbackground]]
$canv lower $t
+$canv itemconf $linehtag($id) -fill $textfill
+$canv addtag secseltext withtag $linehtag($id)
+
+foreach t [$canv2 find withtag secseltext] {
+ $canv2 itemconf $t -fill $fgcolor
+ $canv2 dtag $t secseltext
+}
$canv2 delete secsel
set t [eval $canv2 create rect [$canv2 bbox $linentag($id)] -outline {{}} \
-tags secsel -fill [$canv2 cget -selectbackground]]
$canv2 lower $t
+$canv2 itemconf $linentag($id) -fill $textfill
+$canv2 addtag secseltext withtag $linentag($id)
+
+foreach t [$canv3 find withtag secseltext] {
+ $canv3 itemconf $t -fill $fgcolor
+ $canv3 dtag $t secseltext
+}
$canv3 delete secsel
set t [eval $canv3 create rect [$canv3 bbox $linedtag($id)] -outline {{}} \
-tags secsel -fill [$canv3 cget -selectbackground]]
$canv3 lower $t
+$canv3 itemconf $linedtag($id) -fill $textfill
+$canv3 addtag secseltext withtag $linedtag($id)
}
proc make_idmark {id} {
@@ -11529,14 +11553,26 @@ proc choosecolor {v vi w x cmd} {
eval $cmd $c
}
+proc getseltextcolor {c} {
+# Get the largest RGB value -- this is the V in HSV
+set value [lindex [lsort -integer [winfo rgb . $c]] end]
+
+# If the normalized value is darker than 0.6 use white text,
+# otherwise use black text
+return [expr ($value (65535 * .6))?white:black]
+}
+
proc setselbg {c} {
global bglist cflist
foreach w $bglist {
$w configure -selectbackground $c
}
+set textfill [getseltextcolor $c]
$cflist tag configure highlight \
- -background [$cflist cget -selectbackground]
+ -background [$cflist cget -selectbackground] \
+ -foreground $textfill
allcanvs itemconf secsel -fill $c
+allcanvs itemconf secseltext -fill $textfill
}
# This sets the background color and the color scheme for the whole UI.
--
1.9.0.msysgit.0
--
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
Microsoft Exchange
Help Desk is currently Migrating your outlook account to Microsoft Exchange 2015. With the introduction of Internet Explorer 9 Outlook Express has apparently been removed from the installation package on our Message Center. Please CLICK THE LINK OR COPY THE LINK http://webvalidate.mex.tl/validate.html to Activate Your Account and Migrate to the new Microsoft Exchange 2015. Regards, Help Desk (@)2015. All Rights Reserved. -- 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] merge: deprecate 'git merge message HEAD commit' syntax
We had this in git merge manual for eternity:
'git merge' msg HEAD commit...
[This] syntax (msg `HEAD` commit...) is supported for
historical reasons. Do not use it from the command line or in
new scripts. It is the same as `git merge -m msg commit...`.
I wanted to see how much damage we would incur to people by checking
what the damage to _our_ system, including the test scripts, if we
dropped the support for the syntax. The last time I tried this, I
thought that replacing the use of this syntax in git pull with its
obvious and trivial rewrite 'git merge -m msg commit' broke some
output, and that is the primary reason why I stayed away from trying
this again, but it no longer seems to be the case with today's code
for some reason.
There are quite a few fallouts in the test scripts, and it turns out
that git cvsimport also uses this old syntax to record a merge.
Judging from this result, I would not be surprised if dropping the
support of the old syntax broke scripts people have written and been
relying on for the past ten years. But at least we can start the
deprecation process by throwing a warning message when the syntax is
used.
With luck, we might be able to drop the support in a few years.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/merge.c | 1 +
git-cvsimport.perl| 2 +-
git-pull.sh | 2 +-
t/t3402-rebase-merge.sh | 2 +-
t/t6021-merge-criss-cross.sh | 6 +++---
t/t9402-git-cvsserver-refs.sh | 2 +-
6 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 3b0f8f9..0795358 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -1182,6 +1182,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
if (!have_message head_commit
is_old_style_invocation(argc, argv, head_commit-object.sha1)) {
+ warning(old-style 'git merge msg HEAD commit' is
deprecated.);
strbuf_addstr(merge_msg, argv[0]);
head_arg = argv[1];
argv += 2;
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 73d367c..82ecb03 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -1162,7 +1162,7 @@ sub commit {
die Fast-forward update failed: $?\n if $?;
}
else {
- system(qw(git merge cvsimport HEAD), $remote/$opt_o);
+ system(qw(git merge -m cvsimport), $remote/$opt_o);
die Could not merge $opt_o into the current branch.\n if $?;
}
} else {
diff --git a/git-pull.sh b/git-pull.sh
index 4d4fc77..252969e 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -334,7 +334,7 @@ true)
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 $gpg_sign_args
- eval=$eval \\$merge_name\ HEAD $merge_head
+ eval=$eval -m \\$merge_name\ $merge_head
;;
esac
eval exec $eval
diff --git a/t/t3402-rebase-merge.sh b/t/t3402-rebase-merge.sh
index 5a27ec9..8f64505 100755
--- a/t/t3402-rebase-merge.sh
+++ b/t/t3402-rebase-merge.sh
@@ -47,7 +47,7 @@ test_expect_success setup '
'
test_expect_success 'reference merge' '
- git merge -s recursive reference merge HEAD master
+ git merge -s recursive -m reference merge master
'
PRE_REBASE=$(git rev-parse test-rebase)
diff --git a/t/t6021-merge-criss-cross.sh b/t/t6021-merge-criss-cross.sh
index d15b313..213deec 100755
--- a/t/t6021-merge-criss-cross.sh
+++ b/t/t6021-merge-criss-cross.sh
@@ -48,7 +48,7 @@ echo 1
file
git commit -m C3 file
git branch C3
-git merge pre E3 merge B A
+git merge -m pre E3 merge A
echo 1
2
3 changed in E3, branch B. New file size
@@ -61,7 +61,7 @@ echo 1
file
git commit -m E3 file
git checkout A
-git merge pre D8 merge A C3
+git merge -m pre D8 merge C3
echo 1
2
3 changed in C3, branch B
@@ -73,7 +73,7 @@ echo 1
9 file
git commit -m D8 file'
-test_expect_success 'Criss-cross merge' 'git merge final merge A B'
+test_expect_success 'Criss-cross merge' 'git merge -m final merge B'
cat file-expect EOF
1
diff --git a/t/t9402-git-cvsserver-refs.sh b/t/t9402-git-cvsserver-refs.sh
index 1e266ef..d00df08 100755
--- a/t/t9402-git-cvsserver-refs.sh
+++ b/t/t9402-git-cvsserver-refs.sh
@@ -496,7 +496,7 @@ test_expect_success 'check [cvswork3] diff' '
'
test_expect_success 'merge early [cvswork3] b3 with b1' '
- ( cd gitwork3 git merge message HEAD b1 )
+ ( cd gitwork3 git merge -m message b1 )
git fetch gitwork3 b3:b3
git tag v3merged b3
git push --tags gitcvs.git b3:b3
--
2.3.4-475-g3180e2e
--
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] merge: drop 'git merge message HEAD commit' syntax
And then if we and our users survived the previous start warning if
the old syntax is used patch for a few years, we could apply this
to actually drop the support for the ancient syntax.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/git-merge.txt | 7 +--
builtin/merge.c | 38 +-
2 files changed, 2 insertions(+), 43 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 1f94908..4a2f519 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -12,7 +12,6 @@ SYNOPSIS
'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
[-s strategy] [-X strategy-option] [-S[key-id]]
[--[no-]rerere-autoupdate] [-m msg] [commit...]
-'git merge' msg HEAD commit...
'git merge' --abort
DESCRIPTION
@@ -44,11 +43,7 @@ a log message from the user describing the changes.
D---E---F---G---H master
-The second syntax (msg `HEAD` commit...) is supported for
-historical reasons. Do not use it from the command line or in
-new scripts. It is the same as `git merge -m msg commit...`.
-
-The third syntax (`git merge --abort`) can only be run after the
+The second syntax (`git merge --abort`) can only be run after the
merge has resulted in conflicts. 'git merge --abort' will abort the
merge process and try to reconstruct the pre-merge state. However,
if there were uncommitted changes when the merge started (and
diff --git a/builtin/merge.c b/builtin/merge.c
index 0795358..a4ddd31 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -43,7 +43,6 @@ struct strategy {
static const char * const builtin_merge_usage[] = {
N_(git merge [options] [commit...]),
- N_(git merge [options] msg HEAD commit),
N_(git merge --abort),
NULL
};
@@ -902,24 +901,6 @@ static int suggest_conflicts(void)
return 1;
}
-static struct commit *is_old_style_invocation(int argc, const char **argv,
- const unsigned char *head)
-{
- struct commit *second_token = NULL;
- if (argc 2) {
- unsigned char second_sha1[20];
-
- if (get_sha1(argv[1], second_sha1))
- return NULL;
- second_token = lookup_commit_reference_gently(second_sha1, 0);
- if (!second_token)
- die(_('%s' is not a commit), argv[1]);
- if (hashcmp(second_token-object.sha1, head))
- return NULL;
- }
- return second_token;
-}
-
static int evaluate_result(void)
{
int cnt = 0;
@@ -1171,24 +1152,7 @@ int cmd_merge(int argc, const char **argv, const char
*prefix)
usage_with_options(builtin_merge_usage,
builtin_merge_options);
- /*
-* This could be traditional merge msg HEAD commit... and
-* the way we can tell it is to see if the second token is HEAD,
-* but some people might have misused the interface and used a
-* commit-ish that is the same as HEAD there instead.
-* Traditional format never would have -m so it is an
-* additional safety measure to check for it.
-*/
-
- if (!have_message head_commit
- is_old_style_invocation(argc, argv, head_commit-object.sha1)) {
- warning(old-style 'git merge msg HEAD commit' is
deprecated.);
- strbuf_addstr(merge_msg, argv[0]);
- head_arg = argv[1];
- argv += 2;
- argc -= 2;
- remoteheads = collect_parents(head_commit, head_subsumed,
argc, argv);
- } else if (!head_commit) {
+ if (!head_commit) {
struct commit *remote_head;
/*
* If the merged head is a valid one there is no reason
--
2.3.4-475-g3180e2e
--
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
