Re: support git+mosh for unreliable connections
On wo, 2015-04-15 at 18:37 +0530, Pirate Praveen wrote: Hi, When working with big projects over a slow, unreliable connection, currently there is no way to resume a clone or pull when the connection breaks. mosh is a better replacement for ssh over unreliable connections. supporting git+mosh protocol will go a long way in supporting people who work with unreliable, mobile networks, especially in developed countries (I personally have to try many times when working with large projects as my 3g mobile connection keeps dropping. I recently discovered mosh and it works like a charm. More about mosh https://mosh.mit.edu/ mosh isn't a generic transport though, it's a udp-based session state synchronization protocol. I don't think it can be used as a git transport. -- Dennis Kaarsemaker www.kaarsemaker.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: support git+mosh for unreliable connections
On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote: What would that require git to do, beyond taking whatever you tell it (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh? Michael May be support git+mosh as a protocol, since it is not a drop in replacement. It is redesigned remote shell. The ideas it uses for session resumption needs to be reimplemented. This will need support from git, because it needs server side to be modified. Use SSP to return the the current progress for a particular session (it uses AES session ids). So when a client connect with a session id, git server side can respond with the current state, how many objects received in that session, and client can continue from where it stopped. Client also will need to store session information. signature.asc Description: OpenPGP digital signature
support git+mosh for unreliable connections
Hi, When working with big projects over a slow, unreliable connection, currently there is no way to resume a clone or pull when the connection breaks. mosh is a better replacement for ssh over unreliable connections. supporting git+mosh protocol will go a long way in supporting people who work with unreliable, mobile networks, especially in developed countries (I personally have to try many times when working with large projects as my 3g mobile connection keeps dropping. I recently discovered mosh and it works like a charm. More about mosh https://mosh.mit.edu/ Thanks Praveen signature.asc Description: OpenPGP digital signature
Re: support git+mosh for unreliable connections
Pirate Praveen venit, vidit, dixit 15.04.2015 15:07: Hi, When working with big projects over a slow, unreliable connection, currently there is no way to resume a clone or pull when the connection breaks. mosh is a better replacement for ssh over unreliable connections. supporting git+mosh protocol will go a long way in supporting people who work with unreliable, mobile networks, especially in developed countries (I personally have to try many times when working with large projects as my 3g mobile connection keeps dropping. I recently discovered mosh and it works like a charm. More about mosh https://mosh.mit.edu/ What would that require git to do, beyond taking whatever you tell it (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh? Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: support git+mosh for unreliable connections
Hi Praveen, On 2015-04-15 16:18, Pirate Praveen wrote: On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote: What would that require git to do, beyond taking whatever you tell it (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh? May be support git+mosh as a protocol, since it is not a drop in replacement. It is redesigned remote shell. The ideas it uses for session resumption needs to be reimplemented. This will need support from git, because it needs server side to be modified. Use SSP to return the the current progress for a particular session (it uses AES session ids). It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further. So when a client connect with a session id, git server side can respond with the current state, how many objects received in that session, and client can continue from where it stopped. Client also will need to store session information. No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: support git+mosh for unreliable connections
On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote: Hi Praveen, On 2015-04-15 16:18, Pirate Praveen wrote: On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote: What would that require git to do, beyond taking whatever you tell it (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh? May be support git+mosh as a protocol, since it is not a drop in replacement. It is redesigned remote shell. The ideas it uses for session resumption needs to be reimplemented. This will need support from git, because it needs server side to be modified. Use SSP to return the the current progress for a particular session (it uses AES session ids). It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further. is that really relevent? mosh doesn't support things like X forwarding or port forwarding, but it certainly does support ssh host command and then doing IO. It might not support not doing terminal emulation stuff, but that seems like a simple thing to change in principal at which point I think it would support enough of ssh's functionality its a drop in replacement as far as git is concerned. Seems to me mosh is close enough on its own its worth experimentation by someone who cares. Trev So when a client connect with a session id, git server side can respond with the current state, how many objects received in that session, and client can continue from where it stopped. Client also will need to store session information. No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: support git+mosh for unreliable connections
Hi Praveen A, On 2015-04-15 15:07, Pirate Praveen wrote: When working with big projects over a slow, unreliable connection, currently there is no way to resume a clone or pull when the connection breaks. mosh is a better replacement for ssh over unreliable connections. supporting git+mosh protocol will go a long way in supporting people who work with unreliable, mobile networks, especially in developed countries (I personally have to try many times when working with large projects as my 3g mobile connection keeps dropping. I recently discovered mosh and it works like a charm. More about mosh https://mosh.mit.edu/ From https://github.com/keithw/mosh: Mosh does not support X forwarding or the non-interactive uses of SSH, including port forwarding. In particular it does not support [...] the non-interactive uses of SSH, which the git+mosh transport would require, though. That means that you would have to invest quite a bit of effort into enhancing mosh to *support* the non-interactive uses of SSH before you could start implementing `git-remote-mosh`... Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: support git+mosh for unreliable connections
On Wednesday 15 April 2015 07:52 PM, Johannes Schindelin wrote: From https://github.com/keithw/mosh: Mosh does not support X forwarding or the non-interactive uses of SSH, including port forwarding. In particular it does not support [...] the non-interactive uses of SSH, which the git+mosh transport would require, though. That means that you would have to invest quite a bit of effort into enhancing mosh to *support* the non-interactive uses of SSH before you could start implementing `git-remote-mosh`... Ciao, Johannes Q: Are the mosh principles relevant to other network applications? We think so. The design principles that Mosh stands for are conservative: warning the user if the state being displayed is out of date, serializing and checkpointing all transactions so that if there are no warnings, the user knows every prior transaction has succeeded, and handling expected events (like roaming from one WiFi network to another) gracefully. Can the ideas be used to resume a pull, push or clone operation? Especially serializing and checkpointing. signature.asc Description: OpenPGP digital signature
Re: Odd broken --date=now behavior in current git
Eric Sunshine sunsh...@sunshineco.com writes:
Later parse_date_basic() computes the offset from GMT by comparing
the values returned by tm_to_time_t() and mktime(). The existing 'tm'
is passed to mktime() with the tm_isdst field already set to 0 by
gmtime_r(), and mktime() respects that as a statement that DST is not
in effect, rather than determining it dynamically.
The fix seems to be simply:
8
diff --git a/date.c b/date.c
index 3eba2df..99ad2a0 100644
--- a/date.c
+++ b/date.c
@@ -707,6 +707,7 @@ int parse_date_basic(const char *date, unsigned long
*timestamp, int *offset)
/* mktime uses local timezone */
*timestamp = tm_to_time_t(tm);
if (*offset == -1) {
+ tm.tm_isdst = -1;
time_t temp_time = mktime(tm);
if ((time_t)*timestamp temp_time) {
*offset = ((time_t)*timestamp - temp_time) / 60;
8
I briefly wondered if the caller of gmtime_r() in match_digit()
should be preserving the tm_isdst, though, as that codepath knows
that it is handling a bare number without GMT offset.
But resetting it to -1 here makes it even less error prone (we may
gain other code that stomp on tm.tm_isdst before we get here, and
having -1 in *offset is a sign that nobody saw GMT offset in the
input).
I think I see a decl-after-statment, but other than that, this looks
like a good fix.
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: PATH modifications for git-hook processes
Hmm, this all makes sense as to why it's happening, thank you. In my case the ` /usr/local/Cellar/git/2.3.5/libexec/git-core` (git --exec-path) does give all the proper binaries and sub-binaries. It shows up twice because the GIT_EXEC_PATH environment variable is used too (which is the same in my case since it hasn't been overriden). The /usr/local/bin therefore comes from **the path to the running git itself**. There still seems to be a potential issue I can't figure out how to work around with this. If **the path to the running git itself** is in /usr/local/bin or some other common area, then that would still always get prepended prior to external PATH -- which means **other** external programs will inherit precedence overriding the system PATH preferences. For example, in our case, many scripts run in our specific Python environment, which ala virtualenv is located in a user-specific path (e.g. ~/.virtualenv/foo/bin/python), which appears earlier in the user PATH so it affects all shell processes using `#!/usr/bin/env python`. When a git-exec prepends /usr/local/bin, the system installed Python is used instead. There are other use cases I can think of that would cause this issue as well -- user provides more recent version of bazfoo program in ~/bin which they prepend of their system PATH, git-exec then prepends shared path of a system binary directory which also contains older version of bazfoo, older version then gets used instead. So, I guess what I'm looking for is: - A way to prevent the **path to the running git itself** portion of setup_path from firing, (OR) - A way to specify (via env var?) paths that must remain in high precedence even during a git-exec, e.g.: NEWPATH = [git --exec-path] : [GIT_EXEC_PATH] : [$PROPOSED_HIGH_PRECENDENCE_PATH] : ['git itself' path] : [$PATH] (OR) - A way to refine git-exec default behavior to avoid this edge case (my C is a little rusty but I'm happy to try to help out if we can think of a good logic), (OR) - Something else clever I am not aware of. Thanks so much for your assistance. On Tue, Apr 14, 2015 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote: Matthew Rothenberg mr...@khanacademy.org writes: - what is the expected PATH modification behavior for subprocesses of git-hooks? Is this documented anywhere? - what would be causing /usr/local/bin to be prepended here, and can it be adjusted via preference? This is not limited to hooks and very much deliberate, I think. In order to make sure anything that is called from git wrapper gets picked up from GIT_EXEC_PATH so that the matching version of the git subprogram is used, git cmd does this before running git-cmd (in git.c): /* * We use PATH to find git commands, but we prepend some higher * precedence paths: the --exec-path option, the GIT_EXEC_PATH * environment, and the $(gitexecdir) from the Makefile at build * time. */ setup_path(); And setup_path() is defined in exec_cmd.c to start the new PATH with git-exec-path, and then the path to the running git itself, and then finally the external PATH. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v8 0/4] cat-file: teach cat-file a '--literally' option
Version 7 can be found here : http://thread.gmane.org/gmane.comp.version-control.git/266761/match=patch+v7+0+4 Changes In this version : sha1_file.c * sha1_object_info_extended() can now accept object_info *oi with oi-typename without needing a oi-typep. * Changes in parse_sha1_header_extended() to make the code more organized. cat-file.c * Rephrasing of the '--literally' option. * cat_one_file() only uses oi.typename for case 't' and oi.sizep for case 's'. t1006 * Changed the size of bogus type from 0 to strlen(bogus_content). Documentation * Rephrasing of the explanation for '--literally' option. Suggestion's given by Eric Sunshine and Junio Hamano. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] parse_date_basic(): let the system handle DST conversion
The function parses the input to compute the broken-down time in
struct tm, and the GMT timezone offset. If the timezone offset
does not exist in the input, the broken-down time is turned into the
number of seconds since epoch both in the current timezone and in
GMT and the offset is computed as their difference.
However, we forgot to make sure tm.tm_isdst is set to -1 (i.e. let
the system figure out if DST is in effect in the current timezone
when turning the broken-down time to the number of seconds since
epoch); it is done so at the beginning of the function, but a call
to match_digit() in the function can lead to a call to gmtime_r() to
clobber the field.
Reported-by: Linus Torvalds torva...@linux-foundation.org
Diagnosed-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
date.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 01fd73f..8ad6cef 100644
--- a/date.c
+++ b/date.c
@@ -700,7 +700,11 @@ int parse_date_basic(const char *date, unsigned long
*timestamp, int *offset)
return -1;
if (*offset == -1) {
- time_t temp_time = mktime(tm);
+ time_t temp_time;
+
+ /* gmtime_r() in match_digit() may have clobbered it */
+ tm.tm_isdst = -1;
+ temp_time = mktime(tm);
if ((time_t)*timestamp temp_time) {
*offset = ((time_t)*timestamp - temp_time) / 60;
} else {
--
2.4.0-rc2-165-g862640d
--
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: Odd broken --date=now behavior in current git
Linus Torvalds torva...@linux-foundation.org writes: On Wed, Apr 15, 2015 at 12:22 AM, Eric Sunshine sunsh...@sunshineco.com wrote: The fix seems to be simply: Yup, that seems to do it for me. I'm not sure how we get to match_digit() with the time string now, though. The --date=when parameter is read by determine_author_info() and then parse_force_date(), both in builtin/commit.c. This calls parse_date(), which first calls (and fails) parse_date_basic() when it is not a strict timestamp. now, 4.days.ago, etc. are then passed to approxidate_careful() which in turn calls approxidate_str(). Note that the approxidate formats do not usually spell out the TZ offset. The result is turned into @numseconds by parse_force_date(). The string @numseconds without TZ offset is re-interpreted by parse_date() called by fmt_ident(); the last function prepares the author ident line Name email numseconds offset. The --date=when does not force committer information, which goes through the usual codepath of grabbing the current time. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git + SFC Status Update
On Tue, Apr 14, 2015 at 4:54 PM, Jeff King p...@peff.net wrote: On Tue, Apr 14, 2015 at 12:30:23PM -0700, Junio C Hamano wrote: If I recall correctly, Scott said onstage that some/all of the conference proceeds would be going directly into this fund. So this might need to be revised upward by 50-100% sometime soon :) I think you misheard it. The above is money earmarked for Git at SFC; the admission for GitMerge were going to SFC general fund without earmarked for us, IIUC. Yeah, that's my understanding as well. Ah, thanks for the clarification. -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: Odd broken --date=now behavior in current git
On Wed, Apr 15, 2015 at 12:22 AM, Eric Sunshine sunsh...@sunshineco.com wrote: The fix seems to be simply: Yup, that seems to do it for me. I'm not sure how we get to match_digit() with the time string now, though. So your patch fixes things for me, but I think: - we should move the tm.tm_isdst = -1; up a bit and add a comment - I'd like to know why it affected the author date but not the committer date, and how it got to match_digit() with that date string that didn't contain any digits. I'd spend the time on this myself, but I'm in the middle of the kernel merge window, so.. Thanks, Linus -- 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 v8 1/4] 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 | 126 +---
2 files changed, 105 insertions(+), 23 deletions(-)
diff --git a/cache.h b/cache.h
index c47323e..ea6faf0 100644
--- a/cache.h
+++ b/cache.h
@@ -881,6 +881,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)
{
@@ -1349,6 +1350,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 980ce6b..267399d 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_STREAM_END);
+ 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,40 @@ 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;
+
+ type = type_from_string_gently(typename.buf, typename.len, 1);
+ 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;
/*
* The length must follow immediately, and be in canonical
@@ -1652,12 +1693,24 @@ int parse_sha1_header(const char *hdr, unsigned long
*sizep)
size = size * 10 + c;
}
}
- *sizep = size;
+
+ if (oi-sizep)
+ *oi-sizep =
[PATCH v8 2/4] 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. 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 sunsh...@sunshineco.com
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/cat-file.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..1ec7190 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,20 +30,22 @@ 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.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) {
- printf(%lu\n, size);
- return 0;
- }
- break;
+ oi.sizep = size;
+ if ((type = sha1_object_info_extended(sha1, oi, flags)) 0)
+ die(git cat-file: could not get object info);
+ printf(%lu\n, size);
+ return 0;
case 'e':
return !has_sha1_file(sha1);
@@ -323,7 +332,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 +368,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 +379,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_(allow -s and -t to work with broken/corrupt
objects)),
{ 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 +392,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 +417,7 @@ 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')
+ die(git cat-file --literally: use with -s or -t);
+ return cat_one_file(opt, exp_type, obj_name, literally);
}
--
2.4.0.rc1.249.gb598846
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
[PATCH 3/3] t0027: Add repoMIX and LF_nul
new safer autocrlf handling:
Check if eols are converted at commit, which have CR (or CLLF) in the repo
(technically speaking in the index)
Add a test-file repoMIX with mixed line-endings.
Check the warnings when converting LF-CRLF or CRLF-LF
checkout_files():
Checking out CRLF_nul and checking eol coversion does not
make much sense (CRLF will stay CRLF).
Use the file LF_nul instead: It is handled a binary in auto modes, and when
declared as text the LF should be replaced with CRLF
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t0027-auto-crlf.sh | 155 ---
1 file changed, 84 insertions(+), 71 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 59dfe02..7b85ffb 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -71,12 +71,21 @@ commit_check_warn () {
attr=$2
lfname=$3
crlfname=$4
- lfmixcrlf=$5
- lfmixcr=$6
- crlfnul=$7
- create_gitattributes $attr
+ repoMIX=$5
+ lfmixcrlf=$6
+ lfmixcr=$7
+ crlfnul=$8
pfx=crlf_${crlf}_attr_${attr}
- for f in LF CRLF LF_mix_CR CRLF_mix_LF CRLF_nul
+ # Special handling for repoMIX: It should already be in the repo
+ # with CRLF
+ f=repoMIX
+ fname=${pfx}_$f.txt
+ echo .gitattributes
+ cp $f $fname
+ git -c core.autocrlf=false add $fname 2${pfx}_$f.err
+ git commit -m repoMIX
+ create_gitattributes $attr
+ for f in LF CRLF repoMIX LF_mix_CR CRLF_mix_LF LF_nul CRLF_nul
do
fname=${pfx}_$f.txt
cp $f $fname
@@ -120,7 +129,7 @@ checkout_files () {
git config core.autocrlf $crlf
pfx=eol_${eol}_crlf_${crlf}_attr_${attr}_
src=crlf_false_attr__
- for f in LF CRLF LF_mix_CR CRLF_mix_LF CRLF_nul
+ for f in LF CRLF LF_mix_CR CRLF_mix_LF LF_nul
do
rm $src$f.txt
if test -z $eol; then
@@ -142,8 +151,8 @@ checkout_files () {
test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=LF_mix_CR
compare_ws_file $pfx $lfmixcr ${src}LF_mix_CR.txt
- test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=CRLF_nul
- compare_ws_file $pfx $crlfnul ${src}CRLF_nul.txt
+ test_expect_success checkout core.eol=$eol core.autocrlf=$crlf
gitattributes=$attr file=LF_nul
+ compare_ws_file $pfx $crlfnul ${src}LF_nul.txt
}
@@ -155,6 +164,7 @@ test_expect_success 'setup master' '
git commit -m add .gitattributes
printf line1\nline2\nline3 LF
printf line1\r\nline2\r\nline3 CRLF
+ printf line1\r\nline2\nline3 repoMIX
printf line1\r\nline2\nline3 CRLF_mix_LF
printf line1\nline2\rline3 LF_mix_CR
printf line1\r\nline2\rline3 CRLF_mix_CR
@@ -178,40 +188,41 @@ WCL=CRLF_LF
WMIX=CRLF_LF
fi
+# attr LFCRLF repoMIX CRLFmixLF
LFmixCR CRLFNUL
test_expect_success 'commit files empty attr' '
- commit_check_warn false
- commit_check_warn true LF_CRLF LF_CRLF
- commit_check_warn input CRLF_LF CRLF_LF
+ commit_check_warn false
+ commit_check_warn true LF_CRLF LF_CRLF LF_CRLF
+ commit_check_warn input CRLF_LF CRLF_LF CRLF_LF
'
test_expect_success 'commit files attr=auto' '
- commit_check_warn false auto $WLC$WCL$WMIX
- commit_check_warn true auto LF_CRLF LF_CRLF
- commit_check_warn input auto CRLF_LF CRLF_LF
+ commit_check_warn false auto $WLC$WCL$WMIX $WMIX
+ commit_check_warn true auto LF_CRLF LF_CRLF LF_CRLF
+ commit_check_warn input auto CRLF_LF CRLF_LF CRLF_LF
'
test_expect_success 'commit files attr=text' '
- commit_check_warn false text $WLC$WCL$WMIX $WLC
$WCL
- commit_check_warn true text LF_CRLF LF_CRLF LF_CRLF
- commit_check_warn input text CRLF_LF CRLF_LF
CRLF_LF
+ commit_check_warn false text $WLC$WCL$WMIX $WMIX
$WLC$WCL
+ commit_check_warn true text LF_CRLF LF_CRLF LF_CRLF
LF_CRLF
+ commit_check_warn input text CRLF_LF CRLF_LF CRLF_LF
CRLF_LF
'
test_expect_success 'commit files attr=-text' '
- commit_check_warn false -text
- commit_check_warn true -text
- commit_check_warn input -text
+ commit_check_warn false -text
[PATCH 1/2] parse_date_basic(): return early when given a bogus timestamp
When the input does not have GMT timezone offset, the code computes
it by computing the local and GMT time for the given timestamp. But
there is no point doing so if the given timestamp is known to be a
bogus one.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* A simple preliminary clean-up while we are in the vicinity. We
may want to use time_t throughout the codepath and turn it into
ulong at the very last, but that would be a separate topic.
date.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/date.c b/date.c
index 782de95..01fd73f 100644
--- a/date.c
+++ b/date.c
@@ -696,6 +696,9 @@ int parse_date_basic(const char *date, unsigned long
*timestamp, int *offset)
/* mktime uses local timezone */
*timestamp = tm_to_time_t(tm);
+ if (*timestamp == -1)
+ return -1;
+
if (*offset == -1) {
time_t temp_time = mktime(tm);
if ((time_t)*timestamp temp_time) {
@@ -705,8 +708,6 @@ int parse_date_basic(const char *date, unsigned long
*timestamp, int *offset)
}
}
- if (*timestamp == -1)
- return -1;
if (!tm_gmt)
*timestamp -= *offset * 60;
--
2.4.0-rc2-165-g862640d
--
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 v8 4/4] t1006: add tests for git cat-file --literally
Signed-off-by: Karthik Nayak karthik@gmail.com --- t/t1006-cat-file.sh | 29 + 1 file changed, 29 insertions(+) diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh index ab36b1e..61fab78 100755 --- a/t/t1006-cat-file.sh +++ b/t/t1006-cat-file.sh @@ -47,6 +47,18 @@ $content test_cmp expect actual ' +test_expect_success Type of $type is correct using --literally ' + echo $type expect + git cat-file -t --literally $sha1 actual + test_cmp expect actual +' + +test_expect_success Size of $type is correct using --literally ' + echo $size expect + git cat-file -s --literally $sha1 actual + test_cmp expect actual +' + test -z $content || test_expect_success Content of $type is correct ' maybe_remove_timestamp $content $no_ts expect @@ -296,4 +308,21 @@ test_expect_success '%(deltabase) reports packed delta bases' ' } ' +bogus_type=bogus +bogus_content=bogus +bogus_size=$(strlen $bogus_content) +bogus_sha1=$(printf $bogus_content | git hash-object -t $bogus_type --literally -w --stdin) + +test_expect_success Type of broken object is correct ' + echo $bogus_type expect + git cat-file -t --literally $bogus_sha1 actual + test_cmp expect actual +' + +test_expect_success Size of broken object is correct ' +echo $bogus_size expect + git cat-file -s --literally $bogus_sha1 actual + test_cmp expect actual +' + test_done -- 2.4.0.rc1.249.gb598846 -- 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 v8 3/4] cat-file: add documentation for '--literally' option.
Signed-off-by: Karthik Nayak karthik@gmail.com --- Documentation/git-cat-file.txt | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index f6a16f4..226a9c4 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -9,7 +9,7 @@ git-cat-file - Provide content or type and size information for repository objec SYNOPSIS [verse] -'git cat-file' (-t | -s | -e | -p | type | --textconv ) object +'git cat-file' (-t [--literally]| -s [--literally]| -e | -p | type | --textconv ) object 'git cat-file' (--batch | --batch-check) list-of-objects DESCRIPTION @@ -69,6 +69,9 @@ OPTIONS not be combined with any other options or arguments. See the section `BATCH OUTPUT` below for details. +--literally:: + Allow -s or -t to query broken/corrupt objects of unknown type. + OUTPUT -- If '-t' is specified, one of the type. -- 2.4.0.rc1.249.gb598846 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] t0027: Cleanup: rename functions, avoid TABs
Make more clear what the tests are doing:
commit_check_warn():
Commit files and checks for conversion warnings.
Old name: create_file_in_repo()
checkout_files():
Checkout files from the repo and check if they have
the appropriate line endings in the work space.
Old name: check_files_in_ws()
Replace non-leading TABS with spaces
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
Before this changes manage to stay on the FINO stack
(First In, Never Out), I send them as RFC.
t/t0027-auto-crlf.sh | 184 +--
1 file changed, 92 insertions(+), 92 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 452320d..5858397 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -68,7 +68,7 @@ check_warning () {
esac
}
-create_file_in_repo () {
+commit_check_warn () {
crlf=$1
attr=$2
lfname=$3
@@ -109,7 +109,7 @@ check_files_in_repo () {
}
-check_files_in_ws () {
+checkout_files () {
eol=$1
crlf=$2
attr=$3
@@ -169,40 +169,40 @@ test_expect_success 'setup master' '
warn_LF_CRLF=LF will be replaced by CRLF
warn_CRLF_LF=CRLF will be replaced by LF
-test_expect_success 'add files empty attr' '
- create_file_in_repo false
- create_file_in_repo true LF_CRLF LF_CRLF
- create_file_in_repo input CRLF_LF CRLF_LF
+test_expect_success 'commit files empty attr' '
+ commit_check_warn false
+ commit_check_warn true LF_CRLF LF_CRLF
+ commit_check_warn input CRLF_LF CRLF_LF
'
-test_expect_success 'add files attr=auto' '
- create_file_in_repo false auto CRLF_LF CRLF_LF
- create_file_in_repo true auto LF_CRLF LF_CRLF
- create_file_in_repo input auto CRLF_LF CRLF_LF
+test_expect_success 'commit files attr=auto' '
+ commit_check_warn false auto CRLF_LF CRLF_LF
+ commit_check_warn true auto LF_CRLF LF_CRLF
+ commit_check_warn input auto CRLF_LF CRLF_LF
'
-test_expect_success 'add files attr=text' '
- create_file_in_repo false text CRLF_LF CRLF_LF
CRLF_LF
- create_file_in_repo true text LF_CRLF LF_CRLF
LF_CRLF
- create_file_in_repo input text CRLF_LF CRLF_LF
CRLF_LF
+test_expect_success 'commit files attr=text' '
+ commit_check_warn false text CRLF_LF CRLF_LF
CRLF_LF
+ commit_check_warn true text LF_CRLF LF_CRLF LF_CRLF
+ commit_check_warn input text CRLF_LF CRLF_LF
CRLF_LF
'
-test_expect_success 'add files attr=-text' '
- create_file_in_repo false -text
- create_file_in_repo true -text
- create_file_in_repo input -text
+test_expect_success 'commit files attr=-text' '
+ commit_check_warn false -text
+ commit_check_warn true -text
+ commit_check_warn input -text
'
-test_expect_success 'add files attr=lf' '
- create_file_in_repo false lf CRLF_LF CRLF_LF
CRLF_LF
- create_file_in_repo true lf CRLF_LF CRLF_LF
CRLF_LF
- create_file_in_repo input lf CRLF_LF CRLF_LF
CRLF_LF
+test_expect_success 'commit files attr=lf' '
+ commit_check_warn false lf CRLF_LF CRLF_LF
CRLF_LF
+ commit_check_warn true lf CRLF_LF CRLF_LF
CRLF_LF
+ commit_check_warn input lf CRLF_LF CRLF_LF
CRLF_LF
'
-test_expect_success 'add files attr=crlf' '
- create_file_in_repo false crlf LF_CRLF LF_CRLF
LF_CRLF
- create_file_in_repo true crlf LF_CRLF LF_CRLF
LF_CRLF
- create_file_in_repo input crlf LF_CRLF LF_CRLF
LF_CRLF
+test_expect_success 'commit files attr=crlf' '
+ commit_check_warn false crlf LF_CRLF LF_CRLF LF_CRLF
+ commit_check_warn true crlf LF_CRLF LF_CRLF LF_CRLF
+ commit_check_warn input crlf LF_CRLF LF_CRLF LF_CRLF
'
test_expect_success 'create files cleanup' '
@@ -237,7 +237,7 @@ test_expect_success 'commit -text' '
# Check how files in the repo are changed when they are checked out
# How to read the table below:
-# - check_files_in_ws will check multiple files with a combination of settings
+# - checkout_files will check multiple files with a combination of settings
# and attributes (core.autocrlf=input
[PATCH 2/3] t0027: Adapt check_warning() to MINGW
When running under MINGW, the native line ending is CRLF and not LF.
Adjust the check of the warnings with macros:
WLC: LF become CRLF on non-MINGW
WCL: CRLF become LF on non-MINGW
WMIX: Mixed line endings: either CRLF-LF or LF-CRLF
Improve the information given by check_warning():
Use test_cmp to show which warning is missing (or should'n t be there)
Signed-off-by: Torsten Bögershausen tbo...@web.de
---
t/t0027-auto-crlf.sh | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/t/t0027-auto-crlf.sh b/t/t0027-auto-crlf.sh
index 5858397..59dfe02 100755
--- a/t/t0027-auto-crlf.sh
+++ b/t/t0027-auto-crlf.sh
@@ -57,15 +57,13 @@ create_gitattributes () {
check_warning () {
case $1 in
- LF_CRLF) grep LF will be replaced by CRLF $2;;
- CRLF_LF) grep CRLF will be replaced by LF $2;;
- '')
- expect
- grep will be replaced by $2 actual
- test_cmp expect actual
- ;;
- *) false ;;
+ LF_CRLF) echo warning: LF will be replaced by CRLF $2.expect ;;
+ CRLF_LF) echo warning: CRLF will be replaced by LF $2.expect ;;
+ '') $2.expect ;;
+ *) echo 2 Illegal 1: $1 ; return false ;;
esac
+ grep will be replaced by $2 | sed -e s/\(.*\) in [^ ]*$/\1/
$2.actual
+ test_cmp $2.expect $2.actual
}
commit_check_warn () {
@@ -169,6 +167,17 @@ test_expect_success 'setup master' '
warn_LF_CRLF=LF will be replaced by CRLF
warn_CRLF_LF=CRLF will be replaced by LF
+if test_have_prereq MINGW
+then
+WLC=LF_CRLF
+WCL=
+WMIX=LF_CRLF
+else
+WLC=
+WCL=CRLF_LF
+WMIX=CRLF_LF
+fi
+
test_expect_success 'commit files empty attr' '
commit_check_warn false
commit_check_warn true LF_CRLF LF_CRLF
@@ -176,13 +185,13 @@ test_expect_success 'commit files empty attr' '
'
test_expect_success 'commit files attr=auto' '
- commit_check_warn false auto CRLF_LF CRLF_LF
+ commit_check_warn false auto $WLC$WCL$WMIX
commit_check_warn true auto LF_CRLF LF_CRLF
commit_check_warn input auto CRLF_LF CRLF_LF
'
test_expect_success 'commit files attr=text' '
- commit_check_warn false text CRLF_LF CRLF_LF
CRLF_LF
+ commit_check_warn false text $WLC$WCL$WMIX $WLC
$WCL
commit_check_warn true text LF_CRLF LF_CRLF LF_CRLF
commit_check_warn input text CRLF_LF CRLF_LF
CRLF_LF
'
--
2.2.0.rc1.790.ge19fcd2
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git + SFC Status Update
Jeff King p...@peff.net writes: On Tue, Apr 14, 2015 at 12:30:23PM -0700, Junio C Hamano wrote: If I recall correctly, Scott said onstage that some/all of the conference proceeds would be going directly into this fund. So this might need to be revised upward by 50-100% sometime soon :) I think you misheard it. The above is money earmarked for Git at SFC; the admission for GitMerge were going to SFC general fund without earmarked for us, IIUC. Yeah, that's my understanding as well. To elaborate on this a bit more, there are two ways for people to support software freedom conservancy (SFC) by donation: - People can give money to the Git project, a member of the conservancy. 90% of that money will be earmarked for the Git project's use, and the rest goes to general fund to run SFC. The Donate button on http://git-scm.com/sfc goes to this pot. The Check option on http://git-scm.com/sfc can be directed to this way by earmarking the money for the Git project. - People can give money direct to the conservancy. The Check option on http://git-scm.com/sfc can be directed to this way by not earmarking the money for the Git project. -- 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: Allow to quickly go to a specific commit
Binds g to focus the sha1 entry box.
Signed-off-by: Ismael Luceno ism...@iodev.co.uk
---
gitk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gitk b/gitk
index 9a2daf3..0e9d884 100755
--- a/gitk
+++ b/gitk
@@ -2568,6 +2568,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d $ctext yview scroll 18 units
bindkey u $ctext yview scroll -18 units
+bindkey g {$sha1entry delete 0 end; focus $sha1entry}
bindkey / {focus $fstring}
bindkey Key-KP_Divide {focus $fstring}
bindkey Key-Return {dofind 1 1}
@@ -3069,6 +3070,7 @@ proc keys {} {
[mc %s-FFind $M1T]
[mc %s-GMove to next find hit $M1T]
[mc Return Move to next find hit]
+[mc g Go to commit]
[mc / Focus the search box]
[mc ? Move to previous find hit]
[mc f Scroll diff view to next file]
--
2.3.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] parse_date_basic(): let the system handle DST conversion
On Wed, Apr 15, 2015 at 12:24 PM, Junio C Hamano gits...@pobox.com wrote:
The function parses the input to compute the broken-down time in
struct tm, and the GMT timezone offset. If the timezone offset
does not exist in the input, the broken-down time is turned into the
number of seconds since epoch both in the current timezone and in
GMT and the offset is computed as their difference.
However, we forgot to make sure tm.tm_isdst is set to -1 (i.e. let
the system figure out if DST is in effect in the current timezone
when turning the broken-down time to the number of seconds since
epoch); it is done so at the beginning of the function, but a call
to match_digit() in the function can lead to a call to gmtime_r() to
clobber the field.
Thanks for composing the commit message and turning this into a proper patch.
Reported-by: Linus Torvalds torva...@linux-foundation.org
Diagnosed-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Junio C Hamano gits...@pobox.com
For what it's worth:
Reviewed-by: Eric Sunshine sunsh...@sunshineco.com
---
date.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/date.c b/date.c
index 01fd73f..8ad6cef 100644
--- a/date.c
+++ b/date.c
@@ -700,7 +700,11 @@ int parse_date_basic(const char *date, unsigned long
*timestamp, int *offset)
return -1;
if (*offset == -1) {
- time_t temp_time = mktime(tm);
+ time_t temp_time;
+
+ /* gmtime_r() in match_digit() may have clobbered it */
+ tm.tm_isdst = -1;
+ temp_time = mktime(tm);
if ((time_t)*timestamp temp_time) {
*offset = ((time_t)*timestamp - temp_time) / 60;
} else {
--
2.4.0-rc2-165-g862640d
--
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: support git+mosh for unreliable connections
Hi Trevor, On 2015-04-15 17:33, Trevor Saunders wrote: On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote: On 2015-04-15 16:18, Pirate Praveen wrote: On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote: What would that require git to do, beyond taking whatever you tell it (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh? May be support git+mosh as a protocol, since it is not a drop in replacement. It is redesigned remote shell. The ideas it uses for session resumption needs to be reimplemented. This will need support from git, because it needs server side to be modified. Use SSP to return the the current progress for a particular session (it uses AES session ids). It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further. is that really relevent? mosh doesn't support things like X forwarding or port forwarding, but it certainly does support ssh host command and then doing IO. Ah, so mosh's README lied to me! If `mosh user@host command` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it? Ciao, Johannes It might not support not doing terminal emulation stuff, but that seems like a simple thing to change in principal at which point I think it would support enough of ssh's functionality its a drop in replacement as far as git is concerned. Seems to me mosh is close enough on its own its worth experimentation by someone who cares. Trev So when a client connect with a session id, git server side can respond with the current state, how many objects received in that session, and client can continue from where it stopped. Client also will need to store session information. No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] refs.c: remove lock_fd from struct ref_lock
Michael Haggerty mhag...@alum.mit.edu writes:
This whole series LGTM; however, I suggest that this patch be split up.
See below.
Signed-off-by: Stefan Beller sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
refs.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index 14e52ca..4066752 100644
--- a/refs.c
+++ b/refs.c
[...]
@@ -2335,8 +2333,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
goto error_return;
}
-lock-lock_fd = hold_lock_file_for_update(lock-lk, ref_file, lflags);
-if (lock-lock_fd 0) {
+if (hold_lock_file_for_update(lock-lk, ref_file, lflags) 0) {
+last_errno = errno;
if (errno == ENOENT --attempts_remaining 0)
/*
* Maybe somebody just deleted one of the
[...]
Here you add the line last_errno = errno. It is a good change, but it
is not part of removing ref_lock::lock_fd.
I think this patch came from an ancient codebase before 06839515
(lock_ref_sha1_basic: do not die on locking errors, 2014-11-19),
which added the last_errno = errno, and was not rebased to match
more recent codebase.
I am planning to apply these on top of v2.4.0-rc, so there will be
no new save to last_errno in the end.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] compat/mingw: stubs for getpgid() and tcgetpgrp()
Windows does not have process groups. It is, therefore, the simplest
to pretend that each process is in its own process group.
While here, move the getppid() stub from its old location (between
two sync related functions) next to the two new functions.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
compat/mingw.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 7b523cf..a552026 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -95,8 +95,6 @@ static inline unsigned int alarm(unsigned int seconds)
{ return 0; }
static inline int fsync(int fd)
{ return _commit(fd); }
-static inline pid_t getppid(void)
-{ return 1; }
static inline void sync(void)
{}
static inline uid_t getuid(void)
@@ -118,6 +116,12 @@ static inline int sigaddset(sigset_t *set, int signum)
#define SIG_UNBLOCK 0
static inline int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
{ return 0; }
+static inline pid_t getppid(void)
+{ return 1; }
+static inline pid_t getpgid(pid_t pid)
+{ return pid == 0 ? getpid() : pid; }
+static inline pid_t tcgetpgrp(int fd)
+{ return getpid(); }
/*
* simple adaptors
--
2.3.2.245.gb5bf9d3
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] t0027: Add repoMIX and LF_nul
Hi Torsten, On 2015-04-15 19:01, Torsten Bögershausen wrote: t/t0027-auto-crlf.sh | 155 --- I fear that we duplicated work here, due to me working on Git for Windows 2.x and you sending mails to the non-Windows mailing list. For what it is worth, my patches can be viewed here: https://github.com/git-for-windows/git/commits/master/t/t0027-auto-crlf.sh And in particular this one is important: https://github.com/git-for-windows/git/commit/c07cae2576cd3ed193bb766959f226a8fac5aa17 It would maybe be a good idea to work together? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] clean: improve performance when removing lots of directories
Erik Elfström erik.elfst...@gmail.com writes:
Before this change, clean used resolve_gitlink_ref to check for the
presence of nested git repositories. This had the drawback of creating
a ref_cache entry for every directory that should potentially be
cleaned. The linear search through the ref_cache list caused a massive
performance hit for large number of directories.
I'd prefer to see the current state described in the current
tense, e.g.
git clean uses resolve_gitlink_ref() to check for the presence of
nested git repositories, but it has the drawback of creating a
ref_cache entry for every directory that should potentially be
cleaned. The linear search through the ref_cache list causes a
massive performance hit for large number of directories.
Teach clean.c:remove_dirs to use setup.c:is_git_directory
instead. is_git_directory will actually open HEAD and parse the HEAD
ref but this implies a nested git repository and should be rare when
cleaning.
I am not sure what you wanted to say in this paragraph. What does
it being rare have to do with it? Even if it is not rare (i.e. the
top-level project you are working with has many submodules checked
out without using the more recent a file .git pointing into
.git/modules/ via 'gitdir: $overThere' mechanism), if we found a
nested git repository, we treat it as special and exclude it from
cleaning it out, which is a good thing, no?
Doesn't this implementation get confused by modern submodule
checkouts and descend into and clean their working tree, though?
Module M with path P would have a directory P in the working tree of
the top-level project, and P/.git is a regular file that will fail
is_git_directory() test but records the location of the real
submodule repository i.e. .git/modules/M via the gitdir:
mechanism.
Using is_git_directory should give a more standardized check for what
is and what isn't a git repository but also gives a slight behavioral
change. We will now detect and respect bare and empty nested git
repositories (only init run). Update t7300 to reflect this.
The time to clean an untracked directory containing 10 sub
directories went from 61s to 1.7s after this change.
Helped-by: Jeff King p...@peff.net
Signed-off-by: Erik Elfström erik.elfst...@gmail.com
---
builtin/clean.c | 24
t/t7300-clean.sh | 4 ++--
2 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 98c103f..b679913 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -10,7 +10,6 @@
#include cache.h
#include dir.h
#include parse-options.h
-#include refs.h
#include string-list.h
#include quote.h
#include column.h
@@ -148,6 +147,25 @@ static int exclude_cb(const struct option *opt, const
char *arg, int unset)
return 0;
}
+static int is_git_repository(struct strbuf *path)
+{
+ int ret = 0;
+ if (is_git_directory(path-buf))
+ ret = 1;
+ else {
+ size_t orig_path_len = path-len;
+ assert(orig_path_len != 0);
+ if (path-buf[orig_path_len - 1] != '/')
+ strbuf_addch(path, '/');
+ strbuf_addstr(path, .git);
+ if (is_git_directory(path-buf))
+ ret = 1;
+ strbuf_setlen(path, orig_path_len);
+ }
+
+ return ret;
+}
+
static int remove_dirs(struct strbuf *path, const char *prefix, int
force_flag,
int dry_run, int quiet, int *dir_gone)
{
@@ -155,13 +173,11 @@ static int remove_dirs(struct strbuf *path, const char
*prefix, int force_flag,
struct strbuf quoted = STRBUF_INIT;
struct dirent *e;
int res = 0, ret = 0, gone = 1, original_len = path-len, len;
- unsigned char submodule_head[20];
struct string_list dels = STRING_LIST_INIT_DUP;
*dir_gone = 1;
- if ((force_flag REMOVE_DIR_KEEP_NESTED_GIT)
- !resolve_gitlink_ref(path-buf, HEAD,
submodule_head)) {
+ if ((force_flag REMOVE_DIR_KEEP_NESTED_GIT)
is_git_repository(path)) {
if (!quiet) {
quote_path_relative(path-buf, prefix, quoted);
printf(dry_run ? _(msg_would_skip_git_dir) :
_(msg_skip_git_dir),
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 58e6b4a..da294fe 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -455,7 +455,7 @@ test_expect_success 'nested git work tree' '
! test -d bar
'
-test_expect_failure 'nested git (only init) should be kept' '
+test_expect_success 'nested git (only init) should be kept' '
rm -fr foo bar
git init foo
mkdir bar
@@ -465,7 +465,7 @@ test_expect_failure 'nested git (only init) should be
kept' '
test_path_is_missing bar
'
-test_expect_failure 'nested git (bare) should be kept' '
+test_expect_success 'nested git (bare) should be kept' '
rm -fr foo
Re: Feature Request: provide cmdline args to git hooks
Chris O'Kelly ch...@mapcreative.com.au writes: To reiterate and clarify I'm not saying the undesirable behavior is a built in part of git, just a feature of our hosting platform's Git deployment mechanisms, although if what you mean is that the post-receive hook on the receiving end shouldn't be getting passed pushed tag refs that the local git believed to be already up to date on the remote (as of most recent fetch), then yeah... that is weird because it seems to be the behavior in this case. I just checked. $ rm -fr new mkdir new cd new $ git init src git init --bare dst $ cd src $ echo (date;cat) pushlog .git/hooks/pre-push $ chmod +x .git/hooks/pre-push $ git commit -m 'initial' --allow-empty $ git tag -m 'initial' initial Push only the branch: $ GIT_TRACE_PACKET=1 git push ../dst master 21 | grep 'push' 11:07:26 packet: push ... 66ba... refs/heads/master\0report-st... 11:07:26 packet: push $ cat pushlog Wed Apr 15 11:07:26 PDT 2015 refs/heads/master 66ba... refs/heads/master ... In the packet trace, we can see that we told the remote to update 'master', and the pre-push logger also records the same. Then push with --follow-tags: $ GIT_TRACE_PACKET=1 git push --follow-tags ../dst master 21 | grep 'push' 11:09:53 packet: push ... 30fa... refs/tags/initial\0report-st... 11:09:53 packet: push $ cat pushlog Wed Apr 15 11:09:53 PDT 2015 refs/tags/initial 30fa... refs/tags/initial ... We can see that we told the remote to store the tag, which matches what the pre-push saw. And then an empty push: $ GIT_TRACE_PACKET=1 git push --follow-tags ../dst master 21 | grep 'push' 11:11:23 packet: push $ cat pushlog Wed Apr 15 11:11:23 PDT 2015 We tell them to do nothing, and pre-push saw nothing. For a good measure, let's advance the branch and push it out: $ git commit --allow-empty -m second $ GIT_TRACE_PACKET=1 git push --follow-tags ../dst master 21 | grep 'push' 11:13:43 packet: push 66ba... e711... refs/heads/master\0report-st... 11:13:43 packet: push $ cat pushlog Wed Apr 15 11:13:43 PDT 2015 refs/heads/master e711... refs/heads/master 66ba... We notice that the tag is up to date and do not tell them to do anything to it, and pre-push did not see the tag either. As far as I can see so far, the behaviour of the underlying push (i.e. what we decide to tell the remote to update) is sensible, and what pre-push is told we are doing by the command is consistent with what is really pushed. So Anyway it sounds like the answer here is that it really isn't a feasible task in a client side hook, and we should stick with the current solution of Don't use the GUI to push to Live for now, which is fine; I should probably stop trying to script around every single problem anyway (https://xkcd.com/1319/). It appears that your GUI is a broken implementation of Git, that tells the other side to update what it did not even send, and that is what is causing the trouble, 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
Re: [PATCH] compat/mingw: stubs for getpgid() and tcgetpgrp()
Johannes Sixt j...@kdbg.org writes:
Windows does not have process groups. It is, therefore, the simplest
to pretend that each process is in its own process group.
While here, move the getppid() stub from its old location (between
two sync related functions) next to the two new functions.
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Thanks for a quick update.
The patch should do for now, but I suspect that it may give us a
better abstraction to make the is_foreground_fd(int fd) or even
is_foreground(void) the public API that would be implemented as
int we_are_in_the_foreground(void)
{
return getpgid(0) == tcgetpgrp(fileno(stderr));
}
in POSIX and Windows can implement entirely differently.
Thoughts?
compat/mingw.h | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index 7b523cf..a552026 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -95,8 +95,6 @@ static inline unsigned int alarm(unsigned int seconds)
{ return 0; }
static inline int fsync(int fd)
{ return _commit(fd); }
-static inline pid_t getppid(void)
-{ return 1; }
static inline void sync(void)
{}
static inline uid_t getuid(void)
@@ -118,6 +116,12 @@ static inline int sigaddset(sigset_t *set, int signum)
#define SIG_UNBLOCK 0
static inline int sigprocmask(int how, const sigset_t *set, sigset_t *oldset)
{ return 0; }
+static inline pid_t getppid(void)
+{ return 1; }
+static inline pid_t getpgid(pid_t pid)
+{ return pid == 0 ? getpid() : pid; }
+static inline pid_t tcgetpgrp(int fd)
+{ return getpid(); }
/*
* simple adaptors
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2015, #02; Tue, 14)
Torsten Bögershausen tbo...@web.de writes: On 2015-04-14 23.49, Junio C Hamano wrote: * tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits - perf-lib: add test_perf_cleanup target - perf-lib: split starting the test from the execution Add test_perf_cleanup shell function to the perf suite, that allows the script writers to define a test with a clean-up action. Will hold. Is there a chance to squeeze in a fix for this: ./t/perf/perf-lib.sh:185: error: echo -n is not portable (please use printf): echo -n c$i Of course; please send a follow-up patch. The topic has been stalled for too long. -- 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] compat/mingw: stubs for getpgid() and tcgetpgrp()
Am 15.04.2015 um 20:48 schrieb Junio C Hamano:
The patch should do for now, but I suspect that it may give us a
better abstraction to make the is_foreground_fd(int fd) or even
is_foreground(void) the public API that would be implemented as
int we_are_in_the_foreground(void)
{
return getpgid(0) == tcgetpgrp(fileno(stderr));
}
in POSIX and Windows can implement entirely differently.
Thoughts?
IMHO, this level of abstraction goes too far. It may be that I am not
familiar with process groups, and I find the implementation of
is_foreground_fd() in progress.c close to where it's used quite
educating and enlightening. Hiding a similar implementation miles away
in cache.h and/or compat/ would not pay off for me.
-- 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: support git+mosh for unreliable connections
On Wed, Apr 15, 2015 at 08:13:51PM +0530, Pirate Praveen wrote: Q: Are the mosh principles relevant to other network applications? We think so. The design principles that Mosh stands for are conservative: warning the user if the state being displayed is out of date, serializing and checkpointing all transactions so that if there are no warnings, the user knows every prior transaction has succeeded, and handling expected events (like roaming from one WiFi network to another) gracefully. Can the ideas be used to resume a pull, push or clone operation? Especially serializing and checkpointing. Well, it is possible to write a remote helper and serverside program that internally handles connection unreliability, so Git itself (upload-archive, upload-pack, receive-pack, archive, fetch-pack and send-pack) sees a reliable (full-duplex, half-closeable, stream) channel. Suitably done, that can resume (from Git POV, nothing special happened) across things like IP address changes. However, that is quite difficult to do in practice. Not because interface to Git is complicated, but because the transport problem itself is complicated (however, it still seems way easier than making Git internally be able to resume interrupted operations). Mosh needs to solve at least most of that, it just doesn't provode the right kind of interface. -Ilari -- 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 v8 2/4] cat-file: teach cat-file a '--literally' option
Junio C Hamano gits...@pobox.com writes:
Karthik Nayak karthik@gmail.com writes:
...
-if (argc != 3 argc != 2)
+if (argc 2 || argc 4)
usage_with_options(cat_file_usage, options);
Hmm, why this change?
By allowing 4 args blindly like this, you will let something like
these to pass:
$ git cat-file --textconv -t HEAD
commit
$ git cat-file -p -t HEAD
commit
$ git cat-file -s -t HEAD
commit
$ git cat-file -t -s HEAD
879
It is fine if you are declaring that the last one wins when these
mutually-exclusive options are given. git cat-file -e -s -t HEAD
should also say commit if that is what you are doing, but instead
the code with this patch complains, which is bad.
It also is fine and is more in line with the spirit of the original
code if you keep the rule tight and only one of these mutually
exclusive options is allowed.
In either case, this check needs to be rethought.
I wonder if we want to do something like this as a preliminary step
before your [PATCH 2/4]. Everything after the parse_options() call
seems to protect against leftover argc depending on what they need
already, so the only thing existing we take only 2 or 3 args check
is doing is to protect against giving more than one command mode
options, I think. And OPT_CMDMODE() should do a much better job at
that that kind of thing, by giving a more informative error message
e.g.
$ git cat-file -p -e HEAD
error: switch 'e': incompatible with -p
This is a tangent, but while we are in the vicinity, we may want to
rethink the help message we attach to the '-e' option. Technically
the current message is _not_ wrong per-se, but it misses the point.
The primary thing the option does is to check the (e)xistence of the
named object, and the fact that it does so silently is merely a
detail of the operation. The current help text omits the more
important part of what the option is.
builtin/cat-file.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 1ec7190..534991d 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -372,12 +372,12 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
const struct option options[] = {
OPT_GROUP(N_(type can be one of: blob, tree, commit, tag)),
- OPT_SET_INT('t', NULL, opt, N_(show object type), 't'),
- OPT_SET_INT('s', NULL, opt, N_(show object size), 's'),
- OPT_SET_INT('e', NULL, opt,
+ OPT_CMDMODE('t', NULL, opt, N_(show object type), 't'),
+ OPT_CMDMODE('s', NULL, opt, N_(show object size), 's'),
+ OPT_CMDMODE('e', NULL, opt,
N_(exit with zero when there's no error), 'e'),
- OPT_SET_INT('p', NULL, opt, N_(pretty-print object's
content), 'p'),
- OPT_SET_INT(0, textconv, opt,
+ OPT_CMDMODE('p', NULL, opt, N_(pretty-print object's
content), 'p'),
+ OPT_CMDMODE(0, textconv, opt,
N_(for blob objects, run textconv on object's
content), 'c'),
OPT_BOOL( 0, literally, literally,
N_(allow -s and -t to work with broken/corrupt
objects)),
@@ -392,9 +392,6 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
git_config(git_cat_file_config, NULL);
- if (argc 2 || argc 4)
- usage_with_options(cat_file_usage, options);
-
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
if (opt) {
--
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 v8 2/4] cat-file: teach cat-file a '--literally' option
Karthik Nayak karthik@gmail.com writes:
case 's':
- type = sha1_object_info(sha1, size);
- if (type 0) {
- printf(%lu\n, size);
- return 0;
- }
- break;
+ oi.sizep = size;
+ if ((type = sha1_object_info_extended(sha1, oi, flags)) 0)
Do you still need to assign to type here?
+ die(git cat-file: could not get object info);
+ printf(%lu\n, size);
+ return 0;
@@ -323,7 +332,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 +368,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 +379,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_(allow -s and -t to work with broken/corrupt
objects)),
{ 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 +392,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);
Hmm, why this change?
By allowing 4 args blindly like this, you will let something like
these to pass:
$ git cat-file --textconv -t HEAD
commit
$ git cat-file -p -t HEAD
commit
$ git cat-file -s -t HEAD
commit
$ git cat-file -t -s HEAD
879
It is fine if you are declaring that the last one wins when these
mutually-exclusive options are given. git cat-file -e -s -t HEAD
should also say commit if that is what you are doing, but instead
the code with this patch complains, which is bad.
It also is fine and is more in line with the spirit of the original
code if you keep the rule tight and only one of these mutually
exclusive options is allowed.
In either case, this check needs to be rethought.
--
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 v8 1/4] sha1_file.c: support reading from a loose object of unknown type
Karthik Nayak karthik@gmail.com writes:
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
---
I see that you made the type parsing to happen earlier than the
previous round (which used to do the size first and then type).
Not a problem, though. Just something I noticed...
@@ -1614,27 +1642,40 @@ 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;
This _might_ have some performance impact in that strbuf_addch()
involves strbuf_grow(*, 1), which does does it overflow to
increment sb-len by one?; I would say it should be unmeasurable
because the function is expected to be used only on loose objects
and you shouldn't have very many of them without packing in your
repository in the first place.
I guess Peff's c1822d4f (strbuf: add an optimized 1-character
strbuf_grow, 2015-04-04) may want to teach strbuf_addch() to use his
new strbuf_grow_ch(), and once that happens the performance worry
would disappear without this code to be changed at all.
@@ -2541,7 +2596,7 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
* return value implicitly indicates whether the
* object even exists.
*/
- if (!oi-typep !oi-sizep) {
+ if (!oi-typep !oi-typename !oi-sizep) {
You didn't have this check in the earlier round, and this new one is
correct, I think. Good eyes to spot this potential problem.
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: support git+mosh for unreliable connections
On Wed, Apr 15, 2015 at 07:46:15PM +0200, Johannes Schindelin wrote: Hi Trevor, On 2015-04-15 17:33, Trevor Saunders wrote: On Wed, Apr 15, 2015 at 04:41:42PM +0200, Johannes Schindelin wrote: On 2015-04-15 16:18, Pirate Praveen wrote: On Wednesday 15 April 2015 07:22 PM, Michael J Gruber wrote: What would that require git to do, beyond taking whatever you tell it (using GIT_SSH or _GIT_SSH_COMMAND) to use as a drop in replacement for ssh? May be support git+mosh as a protocol, since it is not a drop in replacement. It is redesigned remote shell. The ideas it uses for session resumption needs to be reimplemented. This will need support from git, because it needs server side to be modified. Use SSP to return the the current progress for a particular session (it uses AES session ids). It will need support from Git alright, but not as much as from mosh, see my other reply: Mosh was not designed for non-interactive use. That support would have to be added before we can go any further. is that really relevent? mosh doesn't support things like X forwarding or port forwarding, but it certainly does support ssh host command and then doing IO. Ah, so mosh's README lied to me! I wouldn't say it lied, its just not really clear what is interactive I'd say git's use of ssh is kind of interactive compared to things like port forwarding. If `mosh user@host command` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it? it does work, I just tried mosh $host cat and then typing stuff and having it printed back at me. However it clears the terminal before hand and prints a message on exit. I tried GIT_SSH=mosh git clone and it failed, but I haven't really dug into why. SO I suspect this can be made to work with some work on the mosh side, but I'm not sure exactly how ssh and mosh are behaving differently here. Trev Ciao, Johannes It might not support not doing terminal emulation stuff, but that seems like a simple thing to change in principal at which point I think it would support enough of ssh's functionality its a drop in replacement as far as git is concerned. Seems to me mosh is close enough on its own its worth experimentation by someone who cares. Trev So when a client connect with a session id, git server side can respond with the current state, how many objects received in that session, and client can continue from where it stopped. Client also will need to store session information. No, the protocol can stay exactly the same, once you have a way to communicate non-interactively via mosh. Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: support git+mosh for unreliable connections
On wo, 2015-04-15 at 19:46 +0200, Johannes Schindelin wrote: On 2015-04-15 17:33, Trevor Saunders wrote: but it certainly does support ssh host command and then doing IO. Yes, in interactive sessions. mosh synchronizes terminal state, it doesn't allow random I/O between client and server. Ah, so mosh's README lied to me! If `mosh user@host command` works, then a simple `GIT_SSH=mosh` should work out of the box, too. Have you tried it? It does not and cannot work. The way mosh works, is that it uses ssh to log in and launch a mosh-server daemon. This daemon and the mosh client then communicate via a custom UDP protocol. The SSH connection is closed after the mosh-server has been launched as it is no longer needed. The communication between the mosh client and server synchronizes terminal state, somewhat like what screen/tmux do. -- Dennis Kaarsemaker www.kaarsemaker.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: [msysGit] [PATCH] compat/mingw: stubs for getpgid() and tcgetpgrp()
On Wed, Apr 15, 2015 at 8:29 PM, Johannes Sixt j...@kdbg.org wrote: Windows does not have process groups. It is, therefore, the simplest to pretend that each process is in its own process group. Windows does have some concept of process groups, but probably not quite what you want: https://msdn.microsoft.com/en-us/library/windows/desktop/ms682083%28v=vs.85%29.aspx -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] t0027: Add repoMIX and LF_nul
On 2015-04-15 19.36, Johannes Schindelin wrote: Hi Torsten, On 2015-04-15 19:01, Torsten Bögershausen wrote: t/t0027-auto-crlf.sh | 155 --- I fear that we duplicated work here, due to me working on Git for Windows 2.x and you sending mails to the non-Windows mailing list. Good to here that this TC is alive, sorry for the breakage. For what it is worth, my patches can be viewed here: https://github.com/git-for-windows/git/commits/master/t/t0027-auto-crlf.sh And in particular this one is important: https://github.com/git-for-windows/git/commit/c07cae2576cd3ed193bb766959f226a8fac5aa17 Thanks for the info and the fix. It would maybe be a good idea to work together? Yes, I try to be up-to-date with Git for Windows, but missed to follow this very patch. Do you plan to send it to git.git ? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 1/4] sha1_file.c: support reading from a loose object of unknown type
On Wed, Apr 15, 2015 at 01:21:15PM -0700, Junio C Hamano wrote: - type[i++] = c; - if (i = sizeof(type)) - return -1; + strbuf_addch(typename, c); } - type[i] = 0; This _might_ have some performance impact in that strbuf_addch() involves strbuf_grow(*, 1), which does does it overflow to increment sb-len by one?; I would say it should be unmeasurable because the function is expected to be used only on loose objects and you shouldn't have very many of them without packing in your repository in the first place. I guess Peff's c1822d4f (strbuf: add an optimized 1-character strbuf_grow, 2015-04-04) may want to teach strbuf_addch() to use his new strbuf_grow_ch(), and once that happens the performance worry would disappear without this code to be changed at all. I haven't re-rolled that series yet, but the discussion there showed that strbuf_grow_ch() is unnecessary; call-sites can just check: if (!strbuf_avail(sb)) strbuf_grow(sb, 1); to get the fast inline check. Since we go to the trouble to inline strbuf_addch, we should probably teach it the same trick. It would be nice to identify a place with a tight strbuf_addch() loop that could demonstrate the speed increase, though. -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] fmt-merge-msg: plug small leak of commit buffer
On Wed, Apr 15, 2015 at 02:30:17PM -0700, Junio C Hamano wrote:
I spoke too soon. There are two error-exit paths in this function.
-- 8 --
A broken or badly formatted commit might not record author or
committer lines or we may not find a valid name on them. The
function record_person() returned after calling get_commit_buffer()
without calling unuse_commit_buffer() on the memory it obtained in
such cases, potentially leaking it.
Looks good. Thanks for cleaning my mess. I looked over the offending
bc6b8fc1, and the other changed spots all look OK.
I note that record_person does not seem to care about the commit at all,
so an alternative fix would be:
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 1d962dc..9f0e608 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -223,16 +223,14 @@ static void add_branch_desc(struct strbuf *out, const
char *name)
#define util_as_integral(elem) ((intptr_t)((elem)-util))
-static void record_person(int which, struct string_list *people,
- struct commit *commit)
+static void record_person_from_buf(int which, struct string_list *people,
+ const char *buffer)
{
- const char *buffer;
char *name_buf, *name, *name_end;
struct string_list_item *elem;
const char *field;
field = (which == 'a') ? \nauthor : \ncommitter ;
- buffer = get_commit_buffer(commit, NULL);
name = strstr(buffer, field);
if (!name)
return;
@@ -245,7 +243,6 @@ static void record_person(int which, struct string_list
*people,
if (name_end name)
return;
name_buf = xmemdupz(name, name_end - name + 1);
- unuse_commit_buffer(commit, buffer);
elem = string_list_lookup(people, name_buf);
if (!elem) {
@@ -256,6 +253,14 @@ static void record_person(int which, struct string_list
*people,
free(name_buf);
}
+static void record_person(int which, struct string_list *people,
+ struct commit *commit)
+{
+ const char *buf = get_commit_buffer(commit, NULL);
+ record_person_from_buf(which, people, buf);
+ unuse_commit_buffer(commit, buf);
+}
+
static int cmp_string_list_util_as_integral(const void *a_, const void *b_)
{
const struct string_list_item *a = a_, *b = b_;
This has the slight advantage that it adapts naturally if record_person
grows more exits, but I don't think it is a big deal either way (it only
matters if the new exit fails to copy the surrounding code and use goto
leave).
-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] fmt-merge-msg: plug small leak of commit buffer
Junio C Hamano gits...@pobox.com writes:
A broken or badly formatted commit might not record author or
committer lines; the function record_person() returned after
calling get_commit_buffer() without calling unuse_commit_buffer()
on the memory, potentially leaking it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* to be applied on bc6b8fc1 (use get_commit_buffer everywhere,
2014-06-10)
I spoke too soon. There are two error-exit paths in this function.
-- 8 --
A broken or badly formatted commit might not record author or
committer lines or we may not find a valid name on them. The
function record_person() returned after calling get_commit_buffer()
without calling unuse_commit_buffer() on the memory it obtained in
such cases, potentially leaking it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/fmt-merge-msg.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 01f6d59..76277d1 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -239,7 +239,7 @@ static void record_person(int which, struct string_list
*people,
buffer = get_commit_buffer(commit);
name = strstr(buffer, field);
if (!name)
- return;
+ goto leave;
name += strlen(field);
name_end = strchrnul(name, '');
if (*name_end)
@@ -247,9 +247,8 @@ static void record_person(int which, struct string_list
*people,
while (isspace(*name_end) name = name_end)
name_end--;
if (name_end name)
- return;
+ goto leave;
name_buf = xmemdupz(name, name_end - name + 1);
- unuse_commit_buffer(commit, buffer);
elem = string_list_lookup(people, name_buf);
if (!elem) {
@@ -258,6 +257,8 @@ static void record_person(int which, struct string_list
*people,
}
elem-util = (void*)(util_as_integral(elem) + 1);
free(name_buf);
+leave:
+ unuse_commit_buffer(commit, buffer);
}
static int cmp_string_list_util_as_integral(const void *a_, const void *b_)
--
2.4.0-rc2-173-gefc434b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] Documentation: add git-log --merges= option and log.merges config. var
On 04/14/2015 08:42 AM, Eric Sunshine wrote:
On Mon, Apr 13, 2015 at 11:29 AM, Koosha Khajehmoogahi koo...@posteo.de
wrote:
From: Junio C Hamano gits...@pobox.com
[kk: added documentation in git-log.txt]
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
diff --git a/Documentation/rev-list-options.txt
b/Documentation/rev-list-options.txt
index f620ee4..88f152f 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -96,6 +96,23 @@ if it is part of the log message.
--remove-empty::
Stop when a given path disappears from the tree.
+--merges={show|hide|only}::
+
+ Limit the output by type of commits.
+
+ `hide`;;
+ Hide merge commits from the output.
+
+ `only`;;
+ Hide non-merge commits from the output (i.e showing
+ only merge commits).
+
+ `show`;;
+ Do not hide either merge or non-merge commits. This
+ is primarily useful when the user has non-standard
+ setting of `log.merges` configuration variable that
+ needs to be overriden from the command line.
s/overriden/overridden/
--merges::
Print only merge commits. This is exactly the same as
`--min-parents=2`.
--
2.3.3.263.g095251d.dirty
Should I send a new reroll or wait for reviews on my other commits.
I have not received any review on other patches of this series yet.
--
Koosha
--
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: [ANNOUNCE] Git v2.4.0-rc2
On April 15, 2015 10:22 PM Jeff King wrote:
Sent: April 15, 2015 10:22 PM
To: Bryan Turner
Cc: Junio C Hamano; Git Users
Subject: Re: [ANNOUNCE] Git v2.4.0-rc2
[side note: please trim your quoted material when doing inline quoting]
On Thu, Apr 16, 2015 at 12:05:57PM +1000, Bryan Turner wrote:
merge: pass verbosity flag down to merge-recursive
I'm pretty confident this change is working as intended, but the
intended change is causing a regression in behavior for me. I'll
readily admit that my workflow is probably wrong, but I thought
perhaps it would be worth surfacing.
[...]
If the goal of passing the verbosity flag down was to fix git merge
--quiet, should the Automatic merge failed line also be omitted? But
if that line should _stay_, wouldn't it be better for the CONFLICT
lines to also stay?
Yeah, I feared there might be fallouts like this. We are somewhat blindly
passing down the --quiet flag without doing a careful audit of the severity
levels in merge-recursive. Potentially we would want a few levels of
verbosity:
-2: totally silent (-q -q)
-1: silence chat, mention important errors like CONFLICT markers (-q)
0: current defaults
1: more verbosity (-v, what is currently level 3, I guess?)
1: and so on with more -v; I don't even know what levels are used
That's off the top of my head. I think it really needs somebody to look
through
and categorize all of the messages generated by merge-recursive.
In the meantime, unless somebody is planning to jump on this topic
immediately (I am not), I think we can revert 2bf15a3330a from master.
It's definitely fixing _a_ problem, but it's one we've lived with for many
years
already.
-Peff
As a more (slightly nano) enhanced suggestion, please consider adding something
along the lines of multiple occurrences of -v:{module=level} to specifically
show messages from things like git-upload-pak, specifically passing verbosity
down to selective components. I do not know whether there is value in the git
subject domain for this, but I'm bringing it up since I have had specific
issues with that part of the code while porting on my platform and I would have
liked to be able to ignore verbosity from everything other than that module
while diagnosing issues. Having this available to test suites would be a bit
more useful as well.
Cheers,
Randall
-- Brief whoami: NonStopUNIX developer since approximately
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/5] Documentation: add git-log --merges= option and log.merges config. var
On Wed, Apr 15, 2015 at 6:27 PM, Koosha Khajehmoogahi koo...@posteo.de wrote:
On 04/14/2015 08:42 AM, Eric Sunshine wrote:
On Mon, Apr 13, 2015 at 11:29 AM, Koosha Khajehmoogahi koo...@posteo.de
wrote:
From: Junio C Hamano gits...@pobox.com
[kk: added documentation in git-log.txt]
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
@@ -96,6 +96,23 @@ if it is part of the log message.
--remove-empty::
Stop when a given path disappears from the tree.
+--merges={show|hide|only}::
+
+ Limit the output by type of commits.
+
+ `hide`;;
+ Hide merge commits from the output.
+
+ `only`;;
+ Hide non-merge commits from the output (i.e showing
+ only merge commits).
+
+ `show`;;
+ Do not hide either merge or non-merge commits. This
+ is primarily useful when the user has non-standard
+ setting of `log.merges` configuration variable that
+ needs to be overriden from the command line.
s/overriden/overridden/
Should I send a new reroll or wait for reviews on my other commits.
I have not received any review on other patches of this series yet.
Lack of review comments does not necessarily mean that people did not
review the patches; it could mean that reviewers had nothing more to
say. In addition to pointing out the typo above, I also made a small
comment[1] on patch 4/5, but otherwise did not find anything else
about which to comment.
Whether or not you should re-send is something Junio can answer. He
will sometimes silently pick up a series as-is or sometimes silently
make minor fixes based upon review comments. Check his 'pu' branch
periodically to see if your series appears there and if it has those
minor adjustments. If not, and if he doesn't answer this question,
then you may need to re-roll.
[1]: http://article.gmane.org/gmane.comp.version-control.git/267118
--
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: [ANNOUNCE] Git v2.4.0-rc2
On Wed, Apr 15, 2015 at 7:22 PM, Jeff King p...@peff.net wrote: In the meantime, unless somebody is planning to jump on this topic immediately (I am not), I think we can revert 2bf15a3330a from master. It's definitely fixing _a_ problem, but it's one we've lived with for many years already. Yeah, I agree. Nobody should be reading the output to find CONFLICT anyway (isn't ls-files -u for these scripts?), but the current error/info levels do look inconsistent. -- 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: [ANNOUNCE] Git v2.4.0-rc2
[side note: please trim your quoted material when doing inline quoting] On Thu, Apr 16, 2015 at 12:05:57PM +1000, Bryan Turner wrote: merge: pass verbosity flag down to merge-recursive I'm pretty confident this change is working as intended, but the intended change is causing a regression in behavior for me. I'll readily admit that my workflow is probably wrong, but I thought perhaps it would be worth surfacing. [...] If the goal of passing the verbosity flag down was to fix git merge --quiet, should the Automatic merge failed line also be omitted? But if that line should _stay_, wouldn't it be better for the CONFLICT lines to also stay? Yeah, I feared there might be fallouts like this. We are somewhat blindly passing down the --quiet flag without doing a careful audit of the severity levels in merge-recursive. Potentially we would want a few levels of verbosity: -2: totally silent (-q -q) -1: silence chat, mention important errors like CONFLICT markers (-q) 0: current defaults 1: more verbosity (-v, what is currently level 3, I guess?) 1: and so on with more -v; I don't even know what levels are used That's off the top of my head. I think it really needs somebody to look through and categorize all of the messages generated by merge-recursive. In the meantime, unless somebody is planning to jump on this topic immediately (I am not), I think we can revert 2bf15a3330a from master. It's definitely fixing _a_ problem, but it's one we've lived with for many years already. -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: [ANNOUNCE] Git v2.4.0-rc2
On Wed, Apr 15, 2015 at 7:48 AM, Junio C Hamano gits...@pobox.com wrote: A release candidate Git v2.4.0-rc2 is now available for testing at the usual places. The difference since -rc1 is mostly l10n and a handful of documentation clean-ups. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.4.0-rc2' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git 2.4 Release Notes (draft) = Backward compatibility warning(s) - This release has a few changes in the user-visible output from Porcelain commands. These are not meant to be parsed by scripts, but the users still may want to be aware of the changes: * Output from git log --decorate (and %d format specifier used in the userformat --format=string parameter git log family of command takes) used to list HEAD just like other tips of branch names, separated with a comma in between. E.g. $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master) ... This release updates the output slightly when HEAD refers to the tip of a branch whose name is also shown in the output. The above is shown as: $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD - master) ... * The phrasing git branch uses to describe a detached HEAD has been updated to match that of git status: - When the HEAD is at the same commit as it was originally detached, they now both show detached at commit object name. - When the HEAD has moved since it was originally detached, they now both show detached from commit object name. Earlier git branch always used from Updates since v2.3 -- Ports * Our default I/O size (8 MiB) for large files was too large for some platforms with smaller SSIZE_MAX, leading to read(2)/write(2) failures. * We did not check the curl library version before using CURLOPT_PROXYAUTH feature that may not exist. * We now detect number of CPUs on older BSD-derived systems. * Portability fixes and workarounds for shell scripts have been added to help BSD-derived systems. UI, Workflows Features * The command usage info strings given by git cmd -h and in documentation have been tweaked for consistency. * The sync subcommand of git p4 now allows users to exclude subdirectories like its clone subcommand does. * git log --invert-grep --grep=WIP will show only commits that do not have the string WIP in their messages. * git push has been taught a --atomic option that makes push to update more than one ref an all-or-none affair. * Extending the push to deploy added in 2.3, the behaviour of git push when updating the branch that is checked out can now be tweaked by push-to-checkout hook. * Using environment variable LANGUAGE and friends on the client side, HTTP-based transports now send Accept-Language when making requests. * git send-email used to accept a mistaken y (or yes) as an answer to What encoding do you want to use [UTF-8]? without questioning. Now it asks for confirmation when the answer looks too short to be a valid encoding name. * When git apply --whitespace=fix fixed whitespace errors in the common context lines, the command reports that it did so. * git status now allows the -v to be given twice to show the differences that are left in the working tree not to be committed. * git cherry-pick used to clean-up the log message even when it is merely replaying an existing commit. It now replays the message verbatim unless you are editing the message of resulting commits. * git archive can now be told to set the 'text' attribute in the resulting zip archive. * Output from git log --decorate mentions HEAD when it points at a tip of an branch differently from a detached HEAD. This is a potentially backward-incompatible change. * git branch on a detached HEAD always said (detached from xyz), even when git status would report detached at xyz. The HEAD is actually at xyz and haven't been moved since it was detached in such a case, but the user cannot read what the current value of HEAD is when detached from is used. * git -C '' subcmd refused to work in the current directory, unlike cd '' which silently behaves as a no-op. (merge 6a536e2 kn/git-cd-to-empty later to maint). * The
[PATCH] fmt-merge-msg: plug small leak of commit buffer
A broken or badly formatted commit might not record author or
committer lines; the function record_person() returned after
calling get_commit_buffer() without calling unuse_commit_buffer()
on the memory, potentially leaking it.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* to be applied on bc6b8fc1 (use get_commit_buffer everywhere,
2014-06-10)
builtin/fmt-merge-msg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/fmt-merge-msg.c b/builtin/fmt-merge-msg.c
index 01f6d59..076264d 100644
--- a/builtin/fmt-merge-msg.c
+++ b/builtin/fmt-merge-msg.c
@@ -238,8 +238,10 @@ static void record_person(int which, struct string_list
*people,
field = (which == 'a') ? \nauthor : \ncommitter ;
buffer = get_commit_buffer(commit);
name = strstr(buffer, field);
- if (!name)
+ if (!name) {
+ unuse_commit_buffer(commit, buffer);
return;
+ }
name += strlen(field);
name_end = strchrnul(name, '');
if (*name_end)
--
2.4.0-rc2-173-gefc434b
--
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: Odd broken --date=now behavior in current git
On Tue, Apr 14, 2015 at 09:47:38PM -0700, Junio C Hamano wrote:
Linus Torvalds torva...@linux-foundation.org writes:
Lookie here, I can reproduce it trivially with current git (in the git
repo itself):
[torvalds@i7 git]$ date; git commit -m Test --allow-empty --date=now
Tue Apr 14 21:11:03 PDT 2015
[master ec7733db5360] Test
Date: Tue Apr 14 20:11:03 2015 -0800
notice how the commit date message shows something funny. It shows an
hour earlier, but in -0800.
And the resulting commit is broken:
[torvalds@i7 git]$ git show --pretty=fuller
commit ec7733db5360966434e03eab1a849e6d4227231c (HEAD - master)
Author: Linus Torvalds torva...@linux-foundation.org
AuthorDate: Tue Apr 14 20:11:03 2015 -0800
Commit: Linus Torvalds torva...@linux-foundation.org
CommitDate: Tue Apr 14 21:11:03 2015 -0700
Test
notice how the AuthorDate has that -0800, but the CommitDate has -0700.
With a quick check, the symptom exists at least at v2.1.4. v2.0.x
series does not seem to have --date=now support but since there is
no change to date.c between v2.0.0 to v2.1.4, older approxidate may
be equally broken.
Will dig tomorrow, if nobody beats me to it, that is.
I'm not familiar with this code, but have been studying it since
reading this email, and I think I know what's going on. The problem
isn't with approxidate, but rather with the date form @nseconds
returned by approxidate. builtin/commit.c calls fmt_ident() with the
@nseconds date, which calls parse_date(), which finally calls
parse_date_basic(), and therein lies the problem.
parse_date_basic() does correctly set tm_isdst=-1, however, when it
encounters a date of form @nseconds, it invokes match_digit() which
calls gmtime_r() to fill in the 'tm' structure, and gmtime_r() sets
tm_isdst=0 (since DST is definitely false at GMT).
Later parse_date_basic() computes the offset from GMT by comparing
the values returned by tm_to_time_t() and mktime(). The existing 'tm'
is passed to mktime() with the tm_isdst field already set to 0 by
gmtime_r(), and mktime() respects that as a statement that DST is not
in effect, rather than determining it dynamically.
The fix seems to be simply:
8
diff --git a/date.c b/date.c
index 3eba2df..99ad2a0 100644
--- a/date.c
+++ b/date.c
@@ -707,6 +707,7 @@ int parse_date_basic(const char *date, unsigned long
*timestamp, int *offset)
/* mktime uses local timezone */
*timestamp = tm_to_time_t(tm);
if (*offset == -1) {
+ tm.tm_isdst = -1;
time_t temp_time = mktime(tm);
if ((time_t)*timestamp temp_time) {
*offset = ((time_t)*timestamp - temp_time) / 60;
8
However, I'm still digesting the code, so I haven't fully convinced
myself that that's all that's needed. (It doesn't break any tests,
and it does fix this issue.)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-gui: sort entries in tclIndex
Ping? On Tue, Feb 10, Olaf Hering wrote: Ping? On Mon, Jan 26, Olaf Hering wrote: ALL_LIBFILES uses wildcard, which provides the result in directory order. This order depends on the underlying filesystem on the buildhost. To get reproducible builds it is required to sort such list before using them. Signed-off-by: Olaf Hering o...@aepfle.de --- git-gui/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/git-gui/Makefile b/git-gui/Makefile index cde8b2e..7564a18 100644 --- a/git-gui/Makefile +++ b/git-gui/Makefile @@ -258,7 +258,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS rm -f $@ ; \ echo '# Autogenerated by git-gui Makefile' $@ \ echo $@ \ -$(foreach p,$(PRELOAD_FILES) $(ALL_LIBFILES),echo '$(subst lib/,,$p)' $@ ) \ +$(foreach p,$(PRELOAD_FILES) $(sort $(ALL_LIBFILES)),echo '$(subst lib/,,$p)' $@ ) \ echo $@ ; \ fi -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git Rev News edition 2 published
Hi, Git Rev News edition 2 is now available: https://git.github.io/rev_news/2015/04/05/edition-2/ Thanks a lot to all the helpers! Enjoy, Christian, Thomas and Nicola. -- 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: Odd broken --date=now behavior in current git
Linus Torvalds: I can't be the only one seeing this? My guess is that there's a missing initialization of tm.tm_isdst somewhere or whatever. I can confirm it if I enable DST on my machine (I usually run my machines on CET all-year, to avoid these kind of issues): $ echo $TZ Europe/Oslo $ git commit -m b [master dee7ec1] b 1 file changed, 1 insertion(+) create mode 100644 b.txt $ git show --pretty=fuller commit dee7ec1cda74a8abd7f26c60ee1e83f73bb31194 (HEAD - master) Author: Peter Krefting peter.kreft...@bridgetech.tv AuthorDate: 2015-04-15 09:04:34 +0200 Commit: Peter Krefting peter.kreft...@bridgetech.tv CommitDate: 2015-04-15 09:04:34 +0200 [...] $ git commit --amend --date=now [...] $ git show --pretty=fuller commit b4561e5a077de7bbcaf9fc06350ea24407adcec0 (HEAD - master) Author: Peter Krefting peter.kreft...@bridgetech.tv AuthorDate: 2015-04-15 08:05:04 +0100 Commit: Peter Krefting peter.kreft...@bridgetech.tv CommitDate: 2015-04-15 09:05:04 +0200 So the datetime is correct, it's just the timezone that is wrong (08:05+0100 = 09:05+0200). $ git --version git version 2.4.0.rc1 -- \\// Peter - http://www.softwolves.pp.se/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2015, #02; Tue, 14)
Hi Junio, On 2015-04-14 23:49, Junio C Hamano wrote: * jc/update-instead-into-void (2015-04-01) 1 commit (merged to 'next' on 2015-04-08 at 8ef4e15) + push-to-deploy: allow pushing into an unborn branch and updating it A push into an unborn branch, with receive.denyCurrentBranch set to updateInstead, did not check out the working tree as expected. Thank you for cleaning up after me. * js/fsck-opt (2015-01-21) 19 commits - fsck: support ignoring objects in `git fsck` via fsck.skiplist - fsck: git receive-pack: support excluding objects from fsck'ing - fsck: introduce `git fsck --quick` - fsck: support demoting errors to warnings - fsck: document the new receive.fsck.* options - fsck: allow upgrading fsck warnings to errors - fsck: optionally ignore specific fsck issues completely - fsck: disallow demoting grave fsck errors to warnings - fsck: add a simple test for receive.fsck.* - fsck: make fsck_tag() warn-friendly - fsck: handle multiple authors in commits specially - fsck: make fsck_commit() warn-friendly - fsck: make fsck_ident() warn-friendly - fsck: report the ID of the error/warning - fsck: allow demoting errors to warnings via receive.fsck.warn = key - fsck: offer a function to demote fsck errors to warnings - fsck: provide a function to parse fsck message IDs - fsck: introduce identifiers for fsck messages - fsck: introduce fsck options fsck.warnings = list of error tokens I suggested turned out to be an unpopular choice (sorry Dscho). Expecting a reroll. Yeah, I'll get to this either today or tomorrow. Sorry for the long wait, Dscho -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2015, #02; Tue, 14)
On 2015-04-14 23.49, Junio C Hamano wrote: * tg/perf-lib-test-perf-cleanup (2013-09-19) 2 commits - perf-lib: add test_perf_cleanup target - perf-lib: split starting the test from the execution Add test_perf_cleanup shell function to the perf suite, that allows the script writers to define a test with a clean-up action. Will hold. Is there a chance to squeeze in a fix for this: ./t/perf/perf-lib.sh:185: error: echo -n is not portable (please use printf): echo -n c$i -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] refs.c: remove lock_fd from struct ref_lock
On 04/15/2015 12:25 AM, Stefan Beller wrote:
The 'lock_fd' is the same as 'lk-fd'. No need to store it twice so remove
it. You may argue this introduces more coupling as we need to know more
about the internals of the lock file mechanism, but this will be solved in
a later patch.
No functional changes intended.
This whole series LGTM; however, I suggest that this patch be split up.
See below.
Signed-off-by: Stefan Beller sbel...@google.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
refs.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index 14e52ca..4066752 100644
--- a/refs.c
+++ b/refs.c
[...]
@@ -2335,8 +2333,8 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
goto error_return;
}
- lock-lock_fd = hold_lock_file_for_update(lock-lk, ref_file, lflags);
- if (lock-lock_fd 0) {
+ if (hold_lock_file_for_update(lock-lk, ref_file, lflags) 0) {
+ last_errno = errno;
if (errno == ENOENT --attempts_remaining 0)
/*
* Maybe somebody just deleted one of the
[...]
Here you add the line last_errno = errno. It is a good change, but it
is not part of removing ref_lock::lock_fd.
I suggest that you move this change to a separate commit. You might also
consider moving the new line to the else clause, because it's really
about preserving errno around the call to error() and preparing for
goto error_return.
With or without this split, this patch is
Reviewed-by: Michael Haggerty mhag...@alum.mit.edu
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: How to send a warning message from git hosting server?
On 04/12/2015 04:55 PM, Yi, EungJun wrote: On Wed, Apr 8, 2015 at 8:08 PM, Tony Finch d...@dotat.at wrote: Yi, EungJun semtlen...@gmail.com wrote: I want a way to response a remote message when a client send any kind of request. Is it possible? Yes, though you need a wrapper around git. Recent versions of gitolite have a motd message of the day feature. It sounds nice. Is the wrapper for git client or git server? Gitolite is -- in this context -- a wrapper on the git server. It's main purpose is access control; the motd feature is just an extra that just happened to be easy once there was a wrapper anyway. -- 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] progress: no progress in background
Disable the display of the progress if stderr is not the
current foreground process.
Still display the final result when done.
Signed-off-by: Luke Mewburn l...@mewburn.net
Acked-by: Nicolas Pitre n...@fluxnic.net
---
progress.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/progress.c b/progress.c
index 412e6b1..43d9228 100644
--- a/progress.c
+++ b/progress.c
@@ -72,6 +72,11 @@ static void clear_progress_signal(void)
progress_update = 0;
}
+static int is_foreground_fd(int fd)
+{
+ return getpgid(0) == tcgetpgrp(fd);
+}
+
static int display(struct progress *progress, unsigned n, const char *done)
{
const char *eol, *tp;
@@ -98,16 +103,21 @@ static int display(struct progress *progress, unsigned n,
const char *done)
unsigned percent = n * 100 / progress-total;
if (percent != progress-last_percent || progress_update) {
progress-last_percent = percent;
- fprintf(stderr, %s: %3u%% (%u/%u)%s%s,
- progress-title, percent, n,
- progress-total, tp, eol);
- fflush(stderr);
+ if (is_foreground_fd(fileno(stderr)) || done) {
+ fprintf(stderr, %s: %3u%% (%u/%u)%s%s,
+ progress-title, percent, n,
+ progress-total, tp, eol);
+ fflush(stderr);
+ }
progress_update = 0;
return 1;
}
} else if (progress_update) {
- fprintf(stderr, %s: %u%s%s, progress-title, n, tp, eol);
- fflush(stderr);
+ if (is_foreground_fd(fileno(stderr)) || done) {
+ fprintf(stderr, %s: %u%s%s,
+ progress-title, n, tp, eol);
+ fflush(stderr);
+ }
progress_update = 0;
return 1;
}
--
2.3.5.1.g63ef1a0
pgpGj_5bLCqHt.pgp
Description: PGP signature
Re: [msysGit] Re: Sneak peek of the upcoming Git for Windows 2.x
Hi Vitaly, On 2015-04-15 09:17, Vitaly wrote: feel free to give it a spin: https://git-for-windows.github.io/#download I have installed msysgit 1.9.4, installing git for windows 2.3.5.8 (into default localtion and with use from Windows command prompt) Which version, 32-bit or 64-bit? PortableGit or regular Git? and call git --version still give me msysgit1.9.4 And the path was not adjusted at all? That would be strange indeed. I have delete gfw 2.3.5.8 and msysgit 1.9.4, install gfw 2.3.5.8 once again (and check use from Windows command prompt) and now I have: C:\git error launching git: . I see C:\Program Files (x86)\Git\bin in my PATH (from old installs?), but did not see this directory (bin) under Git installation There is explicit code to modify the PATH environment variable when you choose the from Windows command prompt option: https://github.com/git-for-windows/build-extra/blob/4fdceef37514d1b35d524a8752ccf4e7ad778f60/installer/install.iss.in#L1163-L1177 Just to make sure, you are certain that the PATH variable is not touched, even if you reinstall (without uninstalling Git for Windows first)? Ciao, Johannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
