Re: [PATCH] t5516-fetch-push: Correct misspelled pushInsteadOf
Junio C Hamano venit, vidit, dixit 02.03.2015 20:43: Anders Kaseorg ande...@mit.edu writes: Signed-off-by: Anders Kaseorg ande...@mit.edu --- t/t5516-fetch-push.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 85c7fec..594d7a6 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -238,7 +238,7 @@ test_expect_success 'push with pushInsteadOf' ' test_expect_success 'push with pushInsteadOf and explicit pushurl (pushInsteadOf should not rewrite)' ' mk_empty testrepo test_config url.trash2/.pushInsteadOf testrepo/ -test_config url.trash3/.pusnInsteadOf trash/wrong +test_config url.trash3/.pushInsteadOf trash/wrong test_config remote.r.url trash/wrong test_config remote.r.pushurl testrepo/ git push r refs/heads/master:refs/remotes/origin/master Interesting. Now an obvious and natural question after seeing this change is how the original test passed with misspelled configuration. Is a test that pushes into trash/wrong checking the right outcome? If the reason why the existing tests passed without this patch is because they do not test the right thing, then shouldn't they be corrected together with the above fix? Ha, I was look there, too, just today and was wondering the same. I guess the test wanted to make sure (among other things) that url.trash3/.pushInsteadOf does not affect the push to remote r (which has an explicit pushurl)... 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
[PATCH] git: make git -C '' cmd not to barf
now it works like cd which silently succeeds Signed-off-by: Karthik Nayak karthik@gmail.com --- git.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/git.c b/git.c index 8c7ee9c..f4c2285 100644 --- a/git.c +++ b/git.c @@ -204,7 +204,9 @@ static int handle_options(const char ***argv, int *argc, int *envchanged) fprintf(stderr, No directory given for -C.\n ); usage(git_usage_string); } - if (chdir((*argv)[1])) + if (*(*argv)[1] == 0) + ; /* Ignore as a directory */ + else if (chdir((*argv)[1])) die_errno(Cannot change to '%s', (*argv)[1]); if (envchanged) *envchanged = 1; -- 2.3.1.167.g7f4ba4b.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GSoC15] Interested in contributing to git
Hi all, git is one of the projects that I wish to contribute to for Google Summer of Code 2015 as it's an integral part of my workflow. I'm from Singapore, and have been accepted to the National University of Singapore for Computer Engineering, and will only matriculate on 3 Aug 2015. I have experience in programming with Python, C and C++, and have successfully submitted patches to projects such as libuv[1] and node-contextify[2]. [1]: https://github.com/joyent/libuv/commit/347000929de775ae6b975a2959f5fabe81d6f1f0 [2]: https://github.com/brianmcd/contextify/commit/7e3e0a89779cd892b3d8604795b6675d6aecff17 I understand that I have to complete a microproject. I would like complete Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git. I'm thinking that the XDG locations should take precedence over the non-XDG locations? For the project, I am interested in implementing git fetch --deepen because I use the shallow clone feature quite often. I'm looking over the source code to see how difficult it would be to implement it :) Thanks, Paul -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interested in helping open source friends on HP-UX?
On Tue, 03 Mar 2015 15:55:48 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56: On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: Jeff, you got it wrong. You should do the hard part and leave the easy part to us! Thanks anyways, I'll add this to my HP_UX branch. I did not mention this in earlier mails. When using the HP C-ANSI-C compiler, MAX_INT is not set. I had to add --8--- #ifndef SIZE_MAX # define SIZE_MAX (18446744073709551615UL) /* define SIZE_MAX (4294967295U) */ # endif --8--- to these files sha1_file.c utf8.c walker.c wrapper.c And yes, that could be dynamic and probably be in another header file In compat/regex/regex_internal.h we have /* For loser systems without the definition. */ #ifndef SIZE_MAX # define SIZE_MAX ((size_t) -1) #endif Does this work in your environment? I think it does: make CC sha1_file.o CC utf8.o CC walker.o walker.c, line 119: warning #4232-D: conversion from struct object * to a more strictly aligned type struct commit * may cause misaligned access if (process_commit(walker, (struct commit *)obj)) ^ walker.c, line 124: warning #4232-D: conversion from struct object * to a more strictly aligned type struct tree * may cause misaligned access if (process_tree(walker, (struct tree *)obj)) ^ walker.c, line 132: warning #4232-D: conversion from struct object * to a more strictly aligned type struct tag * may cause misaligned access if (process_tag(walker, (struct tag *)obj)) ^ CC wrapper.o AR libgit.a [Trying to not let this fall into oblivion...] Much appreciated! Michael -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpLyUnJ3rHuG.pgp Description: OpenPGP digital signature
[PATCH v2 0/3] cat-file: add --literally option
Second version of the patch submitted to add -literlly option to cat-file http://article.gmane.org/gmane.comp.version-control.git/264383 Thanks to Eric, Junio and David for suggesting changes on my first version. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] sha1_file: implement changes for cat-file --literally -t
add sha1_object_info_literally() which is to be used when
the literally option is given to get the type of object
and print it, using sha1_object_info_extended().
add unpack_sha1_header_literally() to unpack sha headers
which may be greater than 32 bytes, which is the threshold
for a regular object header.
modify sha1_loose_object_info() to include a flag argument
and also include changes to call unpack_sha1_header_literally()
when the literally flag is passed. Also copies the obtained
type to the typename field of object_info.
modify sha1_object_info_extended() to call the function
sha1_loose_object_info() with flags.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
sha1_file.c | 84 +++--
1 file changed, 77 insertions(+), 7 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 69a60ec..1068ca0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1564,6 +1564,36 @@ int unpack_sha1_header(git_zstream *stream, unsigned
char *map, unsigned long ma
return git_inflate(stream, 0);
}
+static int unpack_sha1_header_literally(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ /* Get the data stream */
+ memset(stream, 0, sizeof(*stream));
+ stream-next_in = map;
+ stream-avail_in = mapsize;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+
+ git_inflate_init(stream);
+
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status == Z_OK);
+ return -1;
+}
+
static void *unpack_sha1_rest(git_zstream *stream, void *buffer, unsigned long
size, const unsigned char *sha1)
{
int bytes = strlen(buffer) + 1;
@@ -2524,13 +2554,16 @@ struct packed_git *find_sha1_pack(const unsigned char
*sha1,
}
static int sha1_loose_object_info(const unsigned char *sha1,
- struct object_info *oi)
+ struct object_info *oi,
+ int flags)
{
- int status;
+ int status = 0;
unsigned long mapsize, size;
void *map;
git_zstream stream;
char hdr[32];
+ struct strbuf hdrbuf = STRBUF_INIT;
+ char *hdrp;
if (oi-delta_base_sha1)
hashclr(oi-delta_base_sha1);
@@ -2557,10 +2590,25 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
return -1;
if (oi-disk_sizep)
*oi-disk_sizep = mapsize;
- if (unpack_sha1_header(stream, map, mapsize, hdr, sizeof(hdr)) 0)
- status = error(unable to unpack %s header,
- sha1_to_hex(sha1));
- else if ((status = parse_sha1_header(hdr, size)) 0)
+ if ((flags LOOKUP_LITERALLY)) {
+ if (unpack_sha1_header_literally(stream, map, mapsize,
hdrbuf) 0)
+ status = error(unable to unpack %s header with
--literally,
+ sha1_to_hex(sha1));
+ hdrp = hdrbuf.buf;
+ } else {
+ if (unpack_sha1_header(stream, map, mapsize, hdr, sizeof(hdr))
0) {
+ status = error(unable to unpack %s header,
+ sha1_to_hex(sha1));
+ }
+ hdrp = hdr;
+ }
+ if (status)
+ ; /* We're already checking for errors */
+ else if ((flags LOOKUP_LITERALLY)) {
+ size_t typelen = strcspn(hdrbuf.buf, );
+ strbuf_add(oi-typename, hdrbuf.buf, typelen);
+ }
+ else if ((status = parse_sha1_header(hdrp, size)) 0)
status = error(unable to parse %s header, sha1_to_hex(sha1));
else if (oi-sizep)
*oi-sizep = size;
@@ -2568,6 +2616,10 @@ static int sha1_loose_object_info(const unsigned char
*sha1,
munmap(map, mapsize);
if (oi-typep)
*oi-typep = status;
+ if (oi-typename 0 = status typename(status))
+ strbuf_addstr(oi-typename, typename(status));
+ if (hdrp == hdrbuf.buf)
+ strbuf_release(hdrbuf);
return 0;
}
@@ -2594,7 +2646,7 @@ int sha1_object_info_extended(const unsigned char *sha1,
struct object_info *oi,
if (!find_pack_entry(real, e)) {
/* Most likely it's a loose object. */
- if
[PATCH v2 3/3] cat-file: add --literally option
made changes to cat-file to include a --literally
option which prints the type of the object without any
complaints.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/cat-file.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..2af9f40 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -9,7 +9,8 @@
#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;
@@ -23,6 +24,8 @@ static int cat_one_file(int opt, const char *exp_type, const
char *obj_name)
buf = NULL;
switch (opt) {
case 't':
+ if (literally)
+ return sha1_object_info_literally(sha1);
type = sha1_object_info(sha1, NULL);
if (type 0) {
printf(%s\n, typename(type));
@@ -323,7 +326,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|-s|-e|-p|type|--textconv|-t --literally)
object),
N_(git cat-file (--batch | --batch-check) list-of-objects),
NULL
};
@@ -359,6 +362,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 +373,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_(show the type of the given loose object, use for
debugging)),
{ 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 +386,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 != 3 argc != 2 argc != 4)
usage_with_options(cat_file_usage, options);
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
@@ -405,5 +411,10 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
if (batch.enabled)
return batch_objects(batch);
- return cat_one_file(opt, exp_type, obj_name);
+ if (literally opt == 't')
+ return cat_one_file(opt, exp_type, obj_name, literally);
+ else if (literally)
+ usage_with_options(cat_file_usage, options);
+
+ return cat_one_file(opt, exp_type, obj_name, literally);
}
--
2.3.1.169.ga243085.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git: make was_alias and done_help non-static
Am 02.03.2015 um 13:02 schrieb Alexander Kuleshov:
'was_alias' variable does not need to store it's value on each
iteration in the loop, anyway this variable changes it's value with run_argv.
s/it's/its/
'done_help' variable does not need to be static variable too if we'll move it
out the loop.
So these variables do not need to be static.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
git.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 1780233..96723b8 100644
--- a/git.c
+++ b/git.c
@@ -619,6 +619,7 @@ int main(int argc, char **av)
{
const char **argv = (const char **) av;
const char *cmd;
+ int done_help, was_alias;
startup_info = git_startup_info;
@@ -681,8 +682,6 @@ int main(int argc, char **av)
setup_path();
while (1) {
- static int done_help = 0;
- static int was_alias = 0;
was_alias = run_argv(argc, argv);
if (errno != ENOENT)
break;
/S
--
/dev/random says: Recovery program for excessive talkers: On-and-on-Anon.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] cache: modify for cat-file --literally -t
Add a struct strbuf *typename to object_info to hold the
typename when the literally option is used. Add a flag to
notify functions when literally is used.
Signed-off-by: Karthik Nayak karthik@gmail.com
---
cache.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/cache.h b/cache.h
index 4d02efc..949ef4c 100644
--- a/cache.h
+++ b/cache.h
@@ -830,6 +830,7 @@ extern int is_ntfs_dotgit(const char *name);
/* object replacement */
#define LOOKUP_REPLACE_OBJECT 1
+#define LOOKUP_LITERALLY 2
extern void *read_sha1_file_extended(const unsigned char *sha1, enum
object_type *type, unsigned long *size, unsigned flag);
static inline void *read_sha1_file(const unsigned char *sha1, enum object_type
*type, unsigned long *size)
{
@@ -1296,6 +1297,7 @@ struct object_info {
unsigned long *sizep;
unsigned long *disk_sizep;
unsigned char *delta_base_sha1;
+ struct strbuf *typename;
/* Response */
enum {
--
2.3.1.169.ga243085.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Interested in helping open source friends on HP-UX?
H.Merijn Brand venit, vidit, dixit 03.03.2015 16:30: On Tue, 03 Mar 2015 15:55:48 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56: On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: Jeff, you got it wrong. You should do the hard part and leave the easy part to us! Thanks anyways, I'll add this to my HP_UX branch. I did not mention this in earlier mails. When using the HP C-ANSI-C compiler, MAX_INT is not set. I had to add --8--- #ifndef SIZE_MAX # define SIZE_MAX (18446744073709551615UL) /* define SIZE_MAX (4294967295U) */ # endif --8--- to these files sha1_file.c utf8.c walker.c wrapper.c And yes, that could be dynamic and probably be in another header file In compat/regex/regex_internal.h we have /* For loser systems without the definition. */ #ifndef SIZE_MAX # define SIZE_MAX ((size_t) -1) #endif Does this work in your environment? I think it does: make CC sha1_file.o CC utf8.o CC walker.o walker.c, line 119: warning #4232-D: conversion from struct object * to a more strictly aligned type struct commit * may cause misaligned access if (process_commit(walker, (struct commit *)obj)) ^ walker.c, line 124: warning #4232-D: conversion from struct object * to a more strictly aligned type struct tree * may cause misaligned access if (process_tree(walker, (struct tree *)obj)) ^ walker.c, line 132: warning #4232-D: conversion from struct object * to a more strictly aligned type struct tag * may cause misaligned access if (process_tag(walker, (struct tag *)obj)) ^ CC wrapper.o AR libgit.a Hmmh. Did you get these same warnings with the fix you had before? They don't make feel that confident... [Trying to not let this fall into oblivion...] Much appreciated! Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git: make git -C '' cmd not to barf
Karthik Nayak karthik@gmail.com writes: now it works like cd which silently succeeds Missing . at end of sentence. git.c | 4 +++- That would probably also deserve a test. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
bug: git mv dir with submodule in dir/sub
Hi all, First, many thanks for all your work on git. It has been an invaluable tool. I believe I've found a bug. Submodules break when I use ``git mv`` to rename a directory, which contains a submodule as one of its _sub_directories. Here's the script I've been using to reproduce: #!/bin/bash # Settings REPO_TO_CLONE=$HOME/www/wfpl.git # run in new directory export REPODIR=git-bug-$(date '+%s') mkdir $REPODIR || exit $? cd $REPODIR || exit $? git --version # make a git repo with a submodule git init || exit $? mkdir old || exit $? git submodule add ~/www/wfpl.git old/wfpl || exit $? # run the command that borks the submodule git mv old new || exit $? # demonstrate that it's borked: git status || exit $? # for me this command produces: # fatal: Could not chdir to '../../../../old/wfpl': No such file or directory # fatal: 'git status --porcelain' failed in submodule new/wfpl I run that and get this: git version 2.3.1.431.g836cf63 Initialized empty Git repository in /home/jasonwoof/git-bug/git-bug-1425397321/.git/ Cloning into 'old/wfpl'... done. fatal: Could not chdir to '../../../../old/wfpl': No such file or directory fatal: 'git status --porcelain' failed in submodule new/wfpl zsh: exit 128 ./script.sh I got this same error (every time) with git-2.1.4-2.1 from debian unstable, and from github's master (7f4ba4b6e3ba7), and from github's pu branch (836cf6345) All of the above running on debian unstable. You'll need to change REPO_TO_CLONE of course. It's probably worth noting that if I use ``git mv`` on the submodule directly, it works fine. eg if I replace the ``git mv`` line in the above script with: mkdir new git mv old/wfpl new/wfpl then it works fine (no error messages). I am not subscribed to this list, so please remember to reply-all if I can be of further assistance. Thanks you! -- Jason -- To unsubscribe from this list: send the line 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: [GSoC15] Interested in contributing to git
Paul Tan pyoka...@gmail.com writes: Hi all, git is one of the projects that I wish to contribute to for Google Summer of Code 2015 as it's an integral part of my workflow. I'm from Singapore, and have been accepted to the National University of Singapore for Computer Engineering, and will only matriculate on 3 Aug 2015. Be carefull: a GSoC is a full-time job. The GSoC itself ends on August 21st, so there would be a substantial (too big?) overlap between the GSoC and your studies. I understand that I have to complete a microproject. I would like complete Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git. I'm thinking that the XDG locations should take precedence over the non-XDG locations? The logic is different for reading and for writting, see how Git deals with it for ~/.gitconfig for example. Essentially, we read both, and we write to the one which exists if there's only one. I'm the one who proposed this microproject, and some feedback on the mailing-list was that it was not so micro and probably too big already. Both for the microproject and the GSoC itself, don't be too ambitious on the feature you target, and don't underestimate the effort needed to get from the code looks OK to me to the code has been reviewed on list and merged upstream. Cheers, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
Duy Nguyen pclo...@gmail.com writes: Junio pointed out in private that I didn't address the packet length limit (64k). I thought I could get away with a new capability (i.e. not worry about it now) but I finally admit that was a bad hack. So perhaps this on top. No, I didn't ;-) but I tend to agree that perhaps 4GB huge packet? is a bad idea. The problem I had with the version in your write-up was that it still assumed that all capabilities must come on one packet-line. The immediate issue that limitation in the current protocol we had was that the usual we can help newer programs to operate better while getting ignored by existing programs by sending optional information as part of the capability advert would not work for upload-pack to enumerate symrefs and their targets to help clone. The lesson to draw from that experience is not we should have an option to use large packets. 64kB is plenty but the senders and the receivers have a lot lower limit in practice to avoid harming latency (I think it is like 1000 bytes before both ends agree to switch talking over the sideband multiplexer). It is not we should anticipate and design protocol better, either. We are humans and it is hard to predict things, especially things in the future. The lesson we should learn is that it is important to leave us enough wiggle room to allow us cope with such unanticipated limitations ;-). My recollection is that the consensus from the last time we discussed protocol revamping was to list one capability per packet so that packet length limit does not matter, but you may want to check with the list archive yourself. -- To unsubscribe from this list: send the line 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: make git -C '' cmd not to barf
On Tue, Mar 3, 2015 at 8:22 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Karthik Nayak karthik@gmail.com writes: now it works like cd which silently succeeds Missing . at end of sentence. And lack of capitalization at the beginning. More importantly, lack of justification--why is it a good idea to make it works like cd '' in the first place? git.c | 4 +++- That would probably also deserve a test. Another huh? I had on the actual code was if this counts as envchanged, if you are not actually changing the directory at all. Is this meant as a micro for GSoC, by the way? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
Junio C Hamano gits...@pobox.com writes: Duy Nguyen pclo...@gmail.com writes: Junio pointed out in private that I didn't address the packet length limit (64k). I thought I could get away with a new capability (i.e. not worry about it now) but I finally admit that was a bad hack. So perhaps this on top. No, I didn't ;-) but I tend to agree that perhaps 4GB huge packet? is a bad idea. ... I realize that I responded with No, I did not complain about X, I had trouble about Y and here is why and talked mostly about Y without talking much about X. So let's touch X a bit. As to the packet length, I think it is a good idea to give us an escape hatch to bust 64k limit. Refs may not be the reason to do so, but as I said, we cannot forsee the future needs. Having X behind us, now back to Y, and then I'll remind us of Z ;-) [*1*] My recollection is that the consensus from the last time we discussed protocol revamping was to list one capability per packet ... And the above is the right thing from the protocol point of view. The only reason the current protocol says capabilities go on a single line separated by SP is because the hole we found to add to the protocol was to piggyback after the ref advertisement lines, and there was no guarantee that we have more than one ref advertised, so we needed to be able to stuff everything on a single line. Stepping back and thinking about what a packet in pkt-line protocol is, we realize that it is the smallest logical unit of transferring information. The state of a single ref in a series of ref advertisement. The fact that receiving end has all the history leading up to a single commit. The request to obtain all history leading up to a single commit. That is why I say that one-cap-per-packet is the right thing. These individual logical units are grouped into a larger logical unit by (1) being at a specific point in the protocol exchange, (2) being adjacent to each other and (3) terminated by a flush packet. Examples: - A bunch of individual ref states that is at the beginning of the upload-pack to fetch-pack commniucation that ends with a flush constitutes a ref advertisement. - A series of want packets at the beginning of the fetch-pack to upload-pack communiucation that ends with a flush constitutes a fetch request. Another thing I didn't find in the updated documentation was a proposal to define what a flush exactly means. In my above writing, it should be clear that a flush is merely the end of a group. It does not mean (and it never meant, until smart HTTP) I am finished talking, now it is your turn. If a requestor needs to give two groups of items before the responder can process the request, we would want to be able to say A1, A2, ..., now I am done with As; B1, B2, B3, ..., now I am done with Bs; this concludes my request, and it is your turn to process and respond to me. But you cannot easily do so without affecting smart HTTP, as it is written in such a way that it assumes flush is I am done, it is your turn. I am perfectly OK if v2 redefined flush to mean I am done, it is yoru turn. But then the protocol should have another way to allow packets into larger groups. A sequence of packets begin A, A1, A2, ..., end, begin B, B1, B2, B3, end, flush may be a way to do so, and if we continue to rely on the order of packets to help determine the semantics (aka being at a specific point in the protocol exchange above), we may even be able to omit begin A and begin B packets (i.e. the end is the new end of a logical group, which is what flush originally was). [Footnote] *1* For those who haven't been following the discussion: X: maximum packet length being 64kB might be problematic. Y: requiring capability advertisement and request in a single packet is wrong. Z: the meaning of flush needs to be clarified. -- To unsubscribe from this list: send the line 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] t5516-fetch-push: Correct misspelled pushInsteadOf
Michael J Gruber g...@drmicha.warpmail.net writes: Junio C Hamano venit, vidit, dixit 02.03.2015 20:43: Anders Kaseorg ande...@mit.edu writes: Signed-off-by: Anders Kaseorg ande...@mit.edu --- t/t5516-fetch-push.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh index 85c7fec..594d7a6 100755 --- a/t/t5516-fetch-push.sh +++ b/t/t5516-fetch-push.sh @@ -238,7 +238,7 @@ test_expect_success 'push with pushInsteadOf' ' test_expect_success 'push with pushInsteadOf and explicit pushurl (pushInsteadOf should not rewrite)' ' mk_empty testrepo test_config url.trash2/.pushInsteadOf testrepo/ - test_config url.trash3/.pusnInsteadOf trash/wrong + test_config url.trash3/.pushInsteadOf trash/wrong test_config remote.r.url trash/wrong test_config remote.r.pushurl testrepo/ git push r refs/heads/master:refs/remotes/origin/master Interesting. Now an obvious and natural question after seeing this change is how the original test passed with misspelled configuration. Is a test that pushes into trash/wrong checking the right outcome? If the reason why the existing tests passed without this patch is because they do not test the right thing, then shouldn't they be corrected together with the above fix? Ha, I was look there, too, just today and was wondering the same. I guess the test wanted to make sure (among other things) that url.trash3/.pushInsteadOf does not affect the push to remote r (which has an explicit pushurl)... OK, so it makes sure the push goes to testrepo/ but it does not make sure trash2 or trash3 are not touched. Makes sort of sense. Thanks. I am not sure how the intention of the commit 1c2eafb8 (Add url.base.pushInsteadOf: URL rewriting for push only, 2009-09-07), which introduced the behaviour verified by this test, interacts with the desire to redefine what URL and pushURL mean in our recent past, what e.g. e6196ae1 (remote: add --fetch and --both options to set-url, 2014-11-25) wanted to do, though. Thoughts? -- To unsubscribe from this list: send the line 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: [GSoC15] Interested in contributing to git
Hi Matthieu, On Wed, Mar 4, 2015 at 12:20 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Be carefull: a GSoC is a full-time job. The GSoC itself ends on August 21st, so there would be a substantial (too big?) overlap between the GSoC and your studies. I understand. I will have to try my best to complete most of the work before then. I understand that I have to complete a microproject. I would like complete Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git. I'm thinking that the XDG locations should take precedence over the non-XDG locations? The logic is different for reading and for writting, see how Git deals with it for ~/.gitconfig for example. Essentially, we read both, and we write to the one which exists if there's only one. I will try to implement something similar. My idea for credential-store.c is: * For get, lookup_credential() on the XDG file first if it exists, and if it fails call it on the home file. * For remove, remove_credential() from both the xdg file and the home file. * For store, if the XDG file exists store_credential() in the XDG file and remove_credential() from the home file, otherwise just store_credential() in the home file. * For all operations, if --file is provided, use it instead. I'm the one who proposed this microproject, and some feedback on the mailing-list was that it was not so micro and probably too big already. Both for the microproject and the GSoC itself, don't be too ambitious on the feature you target, and don't underestimate the effort needed to get from the code looks OK to me to the code has been reviewed on list and merged upstream. Thanks, I will keep that in mind. Also, quick question, where should the XDG tests go for git-credential-store? I see t1306-xdg-files.sh and t0302-credentials-store.sh. Cheers, -- Matthieu Moy http://www-verimag.imag.fr/~moy/ Regards, Paul -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GSoC15] Interested in contributing to git
Paul Tan pyoka...@gmail.com writes: Also, quick question, where should the XDG tests go for git-credential-store? I see t1306-xdg-files.sh and t0302-credentials-store.sh. I think both could make sense, but it will probably be more natural in t1306-xdg-files.sh. See what the other tests took like. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xmerge.c: fix xdl_merge to conform with the manual
On 2015-03-03 18.37, Anton Trunov wrote: [] Signed-off-by: Anton Trunov anton.a.trunov at gmail.com Should we use the real email here (with the '@') ? --- t/t3032-merge-recursive-options.sh | 43 ++ xdiff/xmerge.c | 10 - 2 files changed, 48 insertions(+), 5 deletions(-) diff --git a/t/t3032-merge-recursive-options.sh b/t/t3032-merge-recursive-options.sh index 4029c9c..4cbedb4 100755 --- a/t/t3032-merge-recursive-options.sh +++ b/t/t3032-merge-recursive-options.sh @@ -204,4 +204,47 @@ test_expect_success '--ignore-space-at-eol' ' test_cmp expected actual ' +# Setup for automerging with whitespace-only changes +# on both sides and in *all* lines + +test_expect_success 'setup: w/s only changes in all lines on both sides' ' + git rm -rf . + git clean -fdqx + rm -rf .git + git init missing + + echo two words text.txt + git add text.txt + test_tick + git commit -m Initial revision + + git checkout -b remote + echo \t\ttwo words text.txt + git commit -a -m remote: insert whitespace only + + git checkout master + echo two words text.txt + git commit -a -m master: insert whitespace only +' + +test_expect_success 'w/s only in all lines: --ignore-space-change preserves ours' ' [] -- To unsubscribe from this list: send the line 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 for design
Ernesto Alonso Montaño Ramírez ernestoalonso...@gmail.com writes: I've a question about Git, can I use this application for design (architecture, no programming)? for example, controlling the versions of designs on AUTOCAD, PHOTOSHOP, ILLUSTRATOR, etc; management of documents... Yes you can use this application. But it depends on your definition of use how useful the end result would be. The features programmers find helpful by placing their end products (i.e. the source code and text files in general) under control in Git are: 1. You can go back to any arbitrary version. 2. You can inspect what the textual differences between two arbitrary versions A and B (but most often, two adjacent versions) are. This is called diff. 3. You can take the textual differences from 2. and replay the change between A and C on top of another version C, which lets you pretend as if you did the same work you did going from A to B but starting at version C. This is apply, merge, cherry-pick, and rebase. Using Git (or any version control system) on non-text files, you would still get the same benefit 1., obviously. If the assets you feed Git are not something intelligible as text (and I am guessing AUTOCAD, PHOTOSHOP and ILLUSTRATOR files are not), you would not gain 2. or 3. immediately. You however can still gain benefit 2., if you have a way to compare two versions of these files in a non-textual way. For example, I do not know AUTOCAD at all, but if the program autocad has a mode where it lets you feed two AUTOCAD files and point out how the two are different visually (let's assume there is such a program autocad-compare that takes two filename parameters to compare), Git has a way for you to plug into its machinery so that git diff v1.0 v2.0 -- an-autocad-file will write out the file at version 1 and version 2 into two temproary files and call out to autocad-compare tmp1 tmp2 to have them compared. For 3., too, Git has a mechanism to plug in a merge-driver of your own, e.g. if you have a version of an AUTOCAD file A that was modified to B by you and modified to C by your colleague and an AUTOCAD program autocad-merge A B C is a way to merge the work you two did starting from the same A to produce B and C into a single unified version, then git merge can be told to use such an external program as a plug-in to perform the file-level merge. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Unexpected/unexplained difference between git pull --rebase and git rebase
Hello, I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. Thanks! -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line 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] reset: allow - short hand for previous commit
From: SudShekhar sudshekha...@gmail.com
Teach reset the same shorthand as checkout and merge. - means the
previous commit.
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
This is done as a microproject for gsoc purposes. I am looking forward to your
feedback/comments. Thanks
builtin/reset.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..3e0378b 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -205,6 +205,8 @@ static void parse_args(struct pathspec *pathspec,
*/
if (argv[0]) {
+ if(!strcmp(argv[0],-))
+ argv[0]=@{-1};
if (!strcmp(argv[0], --)) {
argv++; /* reset to HEAD, possibly with paths */
} else if (argv[1] !strcmp(argv[1], --)) {
--
2.3.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 1/2] t7508: test git status -v
Michael J Gruber g...@drmicha.warpmail.net writes: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- t/t7508-status.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index 8ed5788..4989e98 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' ' test_i18ncmp expect output ' +test_expect_success 'status -v' ' + git diff --cached expect This makes the test rely on the previous one succeeding. Do we care, or is reproducing what ought to be in 'expect' at this step too expensive? + git status -v output + test_cmp expect output +' + test_expect_success 'setup fake editor' ' cat .git/editor -\EOF #! /bin/sh -- To unsubscribe from this list: send the line 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: Interested in helping open source friends on HP-UX?
On Tue, 03 Mar 2015 17:05:53 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: H.Merijn Brand venit, vidit, dixit 03.03.2015 16:30: On Tue, 03 Mar 2015 15:55:48 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56: On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: Jeff, you got it wrong. You should do the hard part and leave the easy part to us! Thanks anyways, I'll add this to my HP_UX branch. I did not mention this in earlier mails. When using the HP C-ANSI-C compiler, MAX_INT is not set. I had to add --8--- #ifndef SIZE_MAX # define SIZE_MAX (18446744073709551615UL) /* define SIZE_MAX (4294967295U) */ # endif --8--- to these files sha1_file.c utf8.c walker.c wrapper.c And yes, that could be dynamic and probably be in another header file In compat/regex/regex_internal.h we have /* For loser systems without the definition. */ #ifndef SIZE_MAX # define SIZE_MAX ((size_t) -1) #endif Does this work in your environment? I think it does: make CC sha1_file.o CC utf8.o CC walker.o walker.c, line 119: warning #4232-D: conversion from struct object * to a more strictly aligned type struct commit * may cause misaligned access if (process_commit(walker, (struct commit *)obj)) ^ walker.c, line 124: warning #4232-D: conversion from struct object * to a more strictly aligned type struct tree * may cause misaligned access if (process_tree(walker, (struct tree *)obj)) ^ walker.c, line 132: warning #4232-D: conversion from struct object * to a more strictly aligned type struct tag * may cause misaligned access if (process_tag(walker, (struct tag *)obj)) ^ CC wrapper.o AR libgit.a Hmmh. Did you get these same warnings with the fix you had before? They don't make feel that confident... Yes, these are unrelated to SIZE_MAX [Trying to not let this fall into oblivion...] Much appreciated! Michael -- H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/ using perl5.00307 .. 5.21 porting perl5 on HP-UX, AIX, and openSUSE http://mirrors.develooper.com/hpux/http://www.test-smoke.org/ http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/ pgpdtSQT1IaEQ.pgp Description: OpenPGP digital signature
Re: git notes from incoming patch
Keller, Jacob E jacob.e.kel...@intel.com writes:
I am wondering whether it is possible to read from a format-patch input
and add notes when we generate the applied patch.
I would think post-applypatch hook is the right place to do this.
The hook has access to the incoming message in $GIT_DIR/rebase-apply
directory ('next' records the message number in the series, and then
you have individual pieces of e-mails separated out into 0001, 0002,
etc. you can read from), and HEAD already points at the result of
applying the patch.
Peek 'post-applypatch' on my 'todo' branch for inspirations.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] git-credential-store: support XDG config dir
Teach git-credential-store to read/write credentials from
$XDG_CONFIG_HOME/git/credentials and ~/.git-credentials where
appropriate:
* get: call lookup_credential() on the XDG file first if it exists. If
the credential can't be found, call lookup_credential() on the HOME
file.
* erase: Call remove_credential() on both the XDG file if it exists and
the HOME file if it exists.
* store: If the XDG file exists, call store_credential() on the XDG file
and remove_credential() on the HOME file to prevent duplicates.
* If --file is provided, use the file for all operations instead.
In order to support the above, parse_credential_file() now returns 1 if
it finds a matching credential, and 0 if it does not. Likewise,
lookup_credential() returns 1 if it could find the credential, and 0 if
it could not.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
credential-store.c | 60 --
1 file changed, 45 insertions(+), 15 deletions(-)
diff --git a/credential-store.c b/credential-store.c
index 925d3f4..18b8897 100644
--- a/credential-store.c
+++ b/credential-store.c
@@ -6,7 +6,7 @@
static struct lock_file credential_lock;
-static void parse_credential_file(const char *fn,
+static int parse_credential_file(const char *fn,
struct credential *c,
void (*match_cb)(struct credential *),
void (*other_cb)(struct strbuf *))
@@ -14,18 +14,20 @@ static void parse_credential_file(const char *fn,
FILE *fh;
struct strbuf line = STRBUF_INIT;
struct credential entry = CREDENTIAL_INIT;
+ int found_credential = 0;
fh = fopen(fn, r);
if (!fh) {
if (errno != ENOENT)
die_errno(unable to open %s, fn);
- return;
+ return 0;
}
while (strbuf_getline(line, fh, '\n') != EOF) {
credential_from_url(entry, line.buf);
if (entry.username entry.password
credential_match(c, entry)) {
+ found_credential = 1;
if (match_cb) {
match_cb(entry);
break;
@@ -38,6 +40,7 @@ static void parse_credential_file(const char *fn,
credential_clear(entry);
strbuf_release(line);
fclose(fh);
+ return found_credential;
}
static void print_entry(struct credential *c)
@@ -111,8 +114,7 @@ static void remove_credential(const char *fn, struct
credential *c)
static int lookup_credential(const char *fn, struct credential *c)
{
- parse_credential_file(fn, c, print_entry, NULL);
- return c-username c-password;
+ return parse_credential_file(fn, c, print_entry, NULL);
}
int main(int argc, char **argv)
@@ -124,6 +126,9 @@ int main(int argc, char **argv)
const char *op;
struct credential c = CREDENTIAL_INIT;
char *file = NULL;
+ char *home_file = NULL;
+ char *xdg_file = NULL;
+ int ret = 0;
struct option options[] = {
OPT_STRING(0, file, file, path,
fetch and store credentials in path),
@@ -137,21 +142,46 @@ int main(int argc, char **argv)
usage_with_options(usage, options);
op = argv[0];
- if (!file)
- file = expand_user_path(~/.git-credentials);
- if (!file)
- die(unable to set up default path; use --file);
+ if (!file) {
+ home_config_paths(NULL, xdg_file, credentials);
+ home_file = expand_user_path(~/.git-credentials);
+ if (!xdg_file !home_file)
+ die(unable to set up default path; use --file);
+ }
if (credential_read(c, stdin) 0)
die(unable to read credential);
- if (!strcmp(op, get))
- lookup_credential(file, c);
- else if (!strcmp(op, erase))
- remove_credential(file, c);
- else if (!strcmp(op, store))
- store_credential(file, c);
- else
+ if (!strcmp(op, get)) {
+ if (file) {
+ lookup_credential(file, c);
+ } else {
+ if (xdg_file access_or_warn(xdg_file, R_OK, 0) == 0)
+ ret = lookup_credential(xdg_file, c);
+ if (!ret home_file access_or_warn(home_file,
R_OK, 0) == 0)
+ lookup_credential(home_file, c);
+ }
+ } else if (!strcmp(op, erase)) {
+ if (file) {
+ remove_credential(file, c);
+ } else {
+ if (xdg_file access(xdg_file, F_OK) == 0)
+ remove_credential(xdg_file, c);
+ if (home_file access(home_file, F_OK) == 0)
+
Re: [PATCH] xmerge.c: fix xdl_merge to conform with the manual
Anton Trunov anton.a.tru...@gmail.com writes: The git-merge manual says that the ignore-space-change, ignore-all-space, ignore-space-at-eol options preserve our version if their version only introduces whitespace changes to a line. So far if there is whitespace-only changes to both sides in *all* lines their version will be used. I am having hard time understanding the last sentence, especially the So far part. Do you mean With the current code, if ours and theirs change whitespaces on all lines, we take theirs? I find the description in the documentation is a bit hard to read. * If 'their' version only introduces whitespace changes to a line, 'our' version is used; * If 'our' version introduces whitespace changes but 'their' version includes a substantial change, 'their' version is used; * Otherwise, the merge proceeds in the usual way. And it is unclear if your reading is correct to me. In your So far scenario, 'our' version does introduce whitespace changes and 'their' version does quite a bit of damage to the file (after all, they both change *all* lines, right?). It does not seem too wrong to invoke the second clause above and take 'theirs', at least to me. It is an entirely different matter if the behaviour the document describes is sane, and I didn't ask git log what the reasoning behind that second point is, but my guess is that a change made by them being substantial is a sign that it is a whitespace cleanup change and we should take the cleanup in such a case, 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: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 01:31:39PM -0800, Mike Botsko wrote: I'm using git 2.2.1 on Mac OS X Yosemite. I just tried the git rebase with --fork-point added, and it works properly: $ git rebase upstream/our-branch-name --fork-point First, rewinding head to replay your work on top of it... Applying: B-07241 While discussing with someone else, he mentioned poking about a bit more, git rebase began defaulting to --fork-point in git 1.9, so one might expect it to be there in that version - but we figured it might be related to https://github.com/git/git/commit/1e0dacdbdb751caa5936b6d1510f5e8db4d1ed5f. I upgraded my version of git, but it wasn't fixed. I assume he was incorrect in that git rebase uses --fork-point by default? git-rebase assumes that if you give an explicit upstream then you want precisely what you asked for. From git-rebase(1): If either upstream or --root is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. On Tue, Mar 3, 2015 at 1:09 PM, John Keeping j...@keeping.me.uk wrote: On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. What version of Git are you using? Does it work if you add the `--fork-point` argument to git-rebase? If so, does it do the same if you just do git rebase with no arguments (see the documentation of `--fork-point` in git-rebase(1) for details of this)? -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line 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: [PATCHv2 1/2] t7508: test git status -v
Junio C Hamano gits...@pobox.com writes: Michael J Gruber g...@drmicha.warpmail.net writes: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- t/t7508-status.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index 8ed5788..4989e98 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' ' test_i18ncmp expect output ' +test_expect_success 'status -v' ' +git diff --cached expect This makes the test rely on the previous one succeeding. Do we care, or is reproducing what ought to be in 'expect' at this step too expensive? Ahh, OK. The way the existing tests prepare 'expect' is by hand. So I think what is wrong with this new test is not that relies on the current contents of 'expect', but that it modifies it (imagine being a merge/patch monkey who has to accept this change while a change from somebody else that wants to add another test that relies on the original 'expect' intact and then have to scratch his or her head when the two topics are merged, wondering why the latter test starts failing). Perhaps ( cat expect git diff --cached ) expect-with-v git status -v actual test_cmp expect-with-v actual or something? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git for design
Hello! I've a question about Git, can I use this application for design (architecture, no programming)? for example, controlling the versions of designs on AUTOCAD, PHOTOSHOP, ILLUSTRATOR, etc; management of documents... Thank you. Atte: Ernesto -- To unsubscribe from this list: send the line 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] tests: test credential-store XDG support
Paul Tan pyoka...@gmail.com writes:
+# Tests for when $XDG_CONFIG_HOME/git/credentials exists but
+# ~/.git-credentials does not.
As much as possible, put text in the $1 of test_expect_success instead
of comments.
+rm $HOME/.git-credentials
+mkdir -p ${XDG_CONFIG_HOME:-$HOME/.config}/git
+echo '' ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+helper_test store
Don't write code outside test_expect_success (read Do's, don'ts
things to keep in mind in t/README).
+test_expect_success '~/.git-credentials will not be created if XDG
git-credentials exist' '
+ test ! -e $HOME/.git-credentials
+'
test_path_is_missing (see test-lib-functions.sh)
+echo '' $HOME/.git-credentials
+echo '' ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
Not even that outside test_expect_success ;-).
Also, no space after (Documentation/CodingGuidelines).
+test_expect_success 'Credentials are stored in XDG file if both XDG and HOME
files exist' '
+ check approve store -\EOF
+ protocol=https
+ host=example.com
+ username=store-user
+ password=store-pass
+ EOF
+ read contents ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+ test ! -z $contents
+ read contents $HOME/.git-credentials
No space after .
+ test -z $contents
+'
+test_expect_success 'Credentials from XDG file are used if the
+ credentials exist in both XDG and HOME files' '
Blank line between tests please.
+test_expect_success 'Credentials from both XDG and HOME files meeting the
criteria are erased' '
+ check reject $HELPER -\EOF
+ protocol=https
+ host=example.com
+ EOF
+ read contents ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+ test -z $contents
+ read contents $HOME/.git-credentials
+ test -z $contents
+'
I'd rather do stg like
echo expected
test_cmp expected ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
test_cmp expected $HOME/.git-credentials
so that a test failure shows a diagnosis.
Regards,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-remote add: --no-tags/--tags which one is the default option
On Mon, Mar 02, 2015 at 10:48:24AM +0100, Francis Moreau wrote: Hi, git remote add has --no-tags/--tags option, but I can't find in the man page which one is the default. Could anybody tell me the default option ? Neither is default. This option has three states, set, unset and default: - unset (--no-tags) doesn't fetch any tags at all - default (no option passed) will fetch any tags that are reachable from the refs that are being fetch - set (--tags) will fetch all tags, even if they aren't reachable. These options can also be set with the remote.name.tagopt config option, which takes values [--tags|--no-tags]. Kevin -- To unsubscribe from this list: send the line 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: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. What version of Git are you using? Does it work if you add the `--fork-point` argument to git-rebase? If so, does it do the same if you just do git rebase with no arguments (see the documentation of `--fork-point` in git-rebase(1) for details of this)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-credential-store: support XDG config dir
Paul Tan pyoka...@gmail.com writes:
Teach git-credential-store to read/write credentials from
$XDG_CONFIG_HOME/git/credentials and ~/.git-credentials where
appropriate:
Thanks for your patch. Below is a partial review. Don't take my comments
as negative criticisms, they are all directions for improvement. I'm
actually positively surprised by the quality for a first patch :-).
Looking forward to your version2.
* get: call lookup_credential() on the XDG file first if it exists. If
the credential can't be found, call lookup_credential() on the HOME
file.
* erase: Call remove_credential() on both the XDG file if it exists and
the HOME file if it exists.
* store: If the XDG file exists, call store_credential() on the XDG file
and remove_credential() on the HOME file to prevent duplicates.
* If --file is provided, use the file for all operations instead.
When writting a commit message, always insist on _why_ you did what you
did, not _what_ you did (the patch already says it). For example, your
proposal for erase makes sense because if you're using erase, you
probably don't want to leave cleartext passwords in another file. But
you didn't give the argument.
In other words: I hate GNU-style changelogs ;-).
Also, we usually put blank lines between items (read the output of git
log --no-merges in git.git to get an idea of the conventions).
Likewise,
lookup_credential() returns 1 if it could find the credential, and 0 if
it could not.
Err, you're changing the calling convention, and you're not the only
caller (git grep lookup_credential).
If you need to change this existing function, best is to start your
series with a preparatory patch that does the calling convention change,
adapts the other caller, and then write your change on top, as [PATCH 2].
- if (!strcmp(op, get))
- lookup_credential(file, c);
- else if (!strcmp(op, erase))
- remove_credential(file, c);
- else if (!strcmp(op, store))
- store_credential(file, c);
- else
+ if (!strcmp(op, get)) {
+ if (file) {
+ lookup_credential(file, c);
+ } else {
+ if (xdg_file access_or_warn(xdg_file, R_OK, 0) == 0)
+ ret = lookup_credential(xdg_file, c);
+ if (!ret home_file access_or_warn(home_file,
R_OK, 0) == 0)
+ lookup_credential(home_file, c);
+ }
+ } else if (!strcmp(op, erase)) {
+ if (file) {
+ remove_credential(file, c);
+ } else {
+ if (xdg_file access(xdg_file, F_OK) == 0)
+ remove_credential(xdg_file, c);
+ if (home_file access(home_file, F_OK) == 0)
+ remove_credential(home_file, c);
Why is it somethimes access_or_warn and sometimes just access? (genuine
question)
+ }
+ } else if (!strcmp(op, store)) {
+ if (file) {
+ store_credential(file, c);
+ } else if (xdg_file access(xdg_file, F_OK) == 0) {
+ store_credential(xdg_file, c);
+ if (home_file access(home_file, F_OK) == 0
+ c.protocol (c.host || c.path) c.username
+ c.password)
It would make sense to introduce a helper like sensible_credential(c),
or sanity_check(c). It could be used in store_credential too.
I'm not convinced you need to remove the credential from home_file if
the xdg_file takes precedence. Not saying you shouldn't, but you should
argue more at least.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reset: allow - short hand for previous commit
Sudhanshu Shekhar sudshekha...@gmail.com writes:
From: SudShekhar sudshekha...@gmail.com
Please, set your configuration to have the same identity for commit and
send-email. It seems your commiter ID (user.name) does not contain your
last name.
builtin/reset.c | 2 ++
Doesn't this deserve a test?
+ if(!strcmp(argv[0],-))
+ argv[0]=@{-1};
Wrong spacing (around = and after ,).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: git notes from incoming patch
-Original Message-
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Tuesday, March 03, 2015 12:14 PM
To: Keller, Jacob E
Cc: git@vger.kernel.org
Subject: Re: git notes from incoming patch
Keller, Jacob E jacob.e.kel...@intel.com writes:
I am wondering whether it is possible to read from a format-patch input
and add notes when we generate the applied patch.
I would think post-applypatch hook is the right place to do this.
The hook has access to the incoming message in $GIT_DIR/rebase-apply
directory ('next' records the message number in the series, and then
you have individual pieces of e-mails separated out into 0001, 0002,
etc. you can read from), and HEAD already points at the result of
applying the patch.
Peek 'post-applypatch' on my 'todo' branch for inspirations.
Excellent, I will investigate this.
Regards,
Jake
--
To unsubscribe from this list: send the line 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: [PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v
Michael J Gruber g...@drmicha.warpmail.net writes: +diff --git INDEX=staged-for-commit/dir1/modified WORKTREE=not-staged-for-commit/dir1/modified +index e69de29..d00491f 100644 +--- INDEX=staged-for-commit/dir1/modified WORKTREE=not-staged-for-commit/dir1/modified This might be OK for a project like Git itself, but I suspect people with long pathnames (like, eh, those in Java land) would not appreciate it. Wouldn't mnemonic prefix, which the users are already familiar with, be the most suitable tool for this disambiguation? After all that was what it was invented for 8 years ago. -- To unsubscribe from this list: send the line 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] tests: test credential-store XDG support
* helper_test store is run for when $XDG_CONFIG_HOME/git/credentials
exists and ~/.git-credentials does not and the other way around.
* Test that credentials are stored in XDG file if both XDG and HOME
files exist.
* Test that credentials from XDG file are used if matching credentials
are found in both XDG and HOME files.
* Test that credentials from HOME file are used if a matching credential
could not be found in the XDG file.
* Test that when erasing credentials, matching credentials in both the
XDG and HOME files are erase.d
Signed-off-by: Paul Tan pyoka...@gmail.com
---
t/t0302-credential-store.sh | 74 +
1 file changed, 74 insertions(+)
diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh
index f61b40c..80893b9 100755
--- a/t/t0302-credential-store.sh
+++ b/t/t0302-credential-store.sh
@@ -4,6 +4,80 @@ test_description='credential-store tests'
. ./test-lib.sh
. $TEST_DIRECTORY/lib-credential.sh
+# Tests for when ~/.git-credentials exists but
+# $XDG_CONFIG_HOME/git/credentials does not
helper_test store
+test_expect_success '~/.git-credentials is written to when XDG git-credentials
does not exist' '
+ test -s $HOME/.git-credentials
+'
+test_expect_success 'XDG credentials will not be created if it does not exist'
'
+ test ! -e ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+'
+
+# Tests for when $XDG_CONFIG_HOME/git/credentials exists but
+# ~/.git-credentials does not.
+rm $HOME/.git-credentials
+mkdir -p ${XDG_CONFIG_HOME:-$HOME/.config}/git
+echo '' ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+helper_test store
+test_expect_success '~/.git-credentials will not be created if XDG
git-credentials exist' '
+ test ! -e $HOME/.git-credentials
+'
+test_expect_success 'XDG credentials will be written to if it exists' '
+ test -s ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+'
+
+# Tests for when both $XDG_CONFIG_HOME/git/credentials and
+# ~/.git-credentials exists.
+echo '' $HOME/.git-credentials
+echo '' ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+test_expect_success 'Credentials are stored in XDG file if both XDG and HOME
files exist' '
+ check approve store -\EOF
+ protocol=https
+ host=example.com
+ username=store-user
+ password=store-pass
+ EOF
+ read contents ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+ test ! -z $contents
+ read contents $HOME/.git-credentials
+ test -z $contents
+'
+test_expect_success 'Credentials from XDG file are used if the credentials
exist in both XDG and HOME files' '
+ echo https://baduser:badp...@example.com; $HOME/.git-credentials
+ check fill store -\EOF
+ protocol=https
+ host=example.com
+ --
+ protocol=https
+ host=example.com
+ username=store-user
+ password=store-pass
+ --
+ EOF
+'
+test_expect_success 'Credentials from HOME file are used if the XDG files does
not have them' '
+ echo ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+ check fill store -\EOF
+ protocol=https
+ host=example.com
+ --
+ protocol=https
+ host=example.com
+ username=baduser
+ password=badpass
+ --
+ EOF
+'
+test_expect_success 'Credentials from both XDG and HOME files meeting the
criteria are erased' '
+ check reject $HELPER -\EOF
+ protocol=https
+ host=example.com
+ EOF
+ read contents ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+ test -z $contents
+ read contents $HOME/.git-credentials
+ test -z $contents
+'
test_done
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [GSoC15] git-credentials-store: support XDG config dir
Hi all, This is my initial implementation for the GSoC15 microproject for supporting both ~/.git-credentials and the XDG standard $XDG_CONFIG_HOME/git/credentials. I wrote the XDG tests in t0302-credential-store.sh in the end because it depends on the helper_test and check functions defined in lib-credential.sh. For your feedback please. Regards, Paul -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unexpected/unexplained difference between git pull --rebase and git rebase
I'm using git 2.2.1 on Mac OS X Yosemite. I just tried the git rebase with --fork-point added, and it works properly: $ git rebase upstream/our-branch-name --fork-point First, rewinding head to replay your work on top of it... Applying: B-07241 While discussing with someone else, he mentioned poking about a bit more, git rebase began defaulting to --fork-point in git 1.9, so one might expect it to be there in that version - but we figured it might be related to https://github.com/git/git/commit/1e0dacdbdb751caa5936b6d1510f5e8db4d1ed5f. I upgraded my version of git, but it wasn't fixed. I assume he was incorrect in that git rebase uses --fork-point by default? On Tue, Mar 3, 2015 at 1:09 PM, John Keeping j...@keeping.me.uk wrote: On Tue, Mar 03, 2015 at 12:39:31PM -0800, Mike Botsko wrote: I'm seeing unexpected behavior between git pull --rebase and git rebase commands, which are supposed to be (and always described as) synonymous: git pull --rebase upstream our-branch-name and git fetch upstream git rebase upstream/our-branch-name We have a situation where the upstream/our-branch-name was rebased, to incorporate changes from master. Somehow, the person who did the rebase discarded a merge commit: 634b622 Sue Merge pull request #254 from bob/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments became: c1452be Sue [B-07290] Order Parts Ship To/Comments A developer who had a local branch tried to rebase their work (a single commit on top of that feature branch). At the moment, his now-out-of-date branch looks like this: 92b2194 Rick B-07241 634b622 Sue Merge pull request #254 from dboyle/B-07290 bc76e5b Bob [B-07290] Order Parts Ship To/Comments I've done some debugging, and the above git pull command generates the following and sends it to eval(): git-rebase --onto c1452be62cf271a25d3d74cc63cd67eca51a127d 634b622870a1016e717067281c7739b1fe08e08d This process works perfectly. The old commits are discarded and his branch now correctly reflects upstream/our-branch-name, with his single new commit at the top. However, if he runs the git rebase command above, several of the commits that have changed hashes (they've also changed patch id slightly, because during the rebase someone fixed a merge conflict) are treated as new work, and git tries to re-apply them and we get tons of merge conflicts. The git rebase command above is trying to rebase onto: revisions = c1452be62cf271a25d3d74cc63cd67eca51a127d..92b2194e3adc29eb3fadd93ddded0ed34513d587 These two features should work the same, yet one is choosing a different commit hash than the other. If this is not a bug, I can't find anyone who can explain what's happening. I'm using git 2.2.1 on mac, but other people on our team have a variety of older versions and we're all seeing the same result. What version of Git are you using? Does it work if you add the `--fork-point` argument to git-rebase? If so, does it do the same if you just do git rebase with no arguments (see the documentation of `--fork-point` in git-rebase(1) for details of this)? -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line 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] reset: allow - short hand for previous commit
On Wed, Mar 4, 2015 at 2:07 AM, Sudhanshu Shekhar
sudshekha...@gmail.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Sudhanshu Shekhar sudshekha...@gmail.com writes:
From: SudShekhar sudshekha...@gmail.com
+ if(!strcmp(argv[0],-))
+ argv[0]=@{-1};
Wrong spacing (around = and after ,).
Thanks for pointing this out. I have corrected it.
Also, add a space after 'if'.
--
To unsubscribe from this list: send the line 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] reset: allow - short hand for previous commit
Teach reset the same shorthand as checkout and merge. - means the
previous commit.
Signed-off-by: Sudhanshu Shekhar sudshekha...@gmail.com
---
builtin/reset.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 4c08ddc..9f8967d 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -192,6 +192,7 @@ static void parse_args(struct pathspec *pathspec,
{
const char *rev = HEAD;
unsigned char unused[20];
+ int substituted_minus = 0;
/*
* Possible arguments are:
*
@@ -205,6 +206,10 @@ static void parse_args(struct pathspec *pathspec,
*/
if (argv[0]) {
+ if(!strcmp(argv[0], -)) {
+ argv[0] = @{-1};
+ substituted_minus = 1;
+ }
if (!strcmp(argv[0], --)) {
argv++; /* reset to HEAD, possibly with paths */
} else if (argv[1] !strcmp(argv[1], --)) {
@@ -225,12 +230,14 @@ static void parse_args(struct pathspec *pathspec,
verify_non_filename(prefix, argv[0]);
rev = *argv++;
} else {
+ /* We were treating - as a commit and not a file */
+ if(substituted_minus)
+ argv[0] = -;
/* Otherwise we treat this as a filename */
verify_filename(prefix, argv[0], 1);
}
}
*rev_ret = rev;
-
if (read_cache() 0)
die(_(index file corrupt));
--
2.3.1.168.gfd4bc34.dirty
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Disclaimer about the number of slots.
On Wed, Mar 04, 2015 at 08:19:31AM +0100, Matthieu Moy wrote: So, sending this in case other people think it's a good idea, but I won't fight for it in case you don't think it is. [...] --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -20,6 +20,11 @@ Please, include link(s) to the mailing-list discussion(s) related to your microproject in your application (e.g. linking to [gmane](http://news.gmane.org/gmane.comp.version-control.git)). +## Note about the number of slots + +In 2015, the Git organization has very limited mentoring capacity. +We will probably be able to accept 2 students only this year. I'm on the fence. I don't mind giving a warning, but I'm not sure that this isn't just as likely to scare off students we want. :) Maybe something along the lines of If you are really excited about working on git, we would love to see your application; if you are just looking for a random project, there may be a lot of competition for a small number of slots. Except I am not quite sure how to phrase just looking for a random project that does not sound quite so demeaning. -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: Git Newbie - GSoC mini Project
On wo, 2015-03-04 at 11:50 +0530, Prudhvee Narasimha Sadha wrote: I'm a newbie to git. I started working on git. I cloned the git repository and started hacking it. I need a suggestion on how to start working on the micro project Make git -C '' cmd not to barf. git -C '' cmd currently throws an error: $ git -C '' status fatal: Cannot change to '': No such file or directory So the two things you should do are - Determine what the desired behavior would be - Implementing that behavior For the first step, I'd send a mail to this list asking people for input, paying special attention to the responses of the core maintainers and possible GSOC mentors (I'm not one of them, but I think the error is actually the right behavior, I'd prefer git -C $repodir to bomb out if $repodir is unset. On the other hand cd '' is equivalent to not cd'ing at all so there's precedent to change this). For the second step, you'll need to find the bit of code where the -C option is handled and add a special case for the empty string to do what came out of the discussion about wanted behavior. -- 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: Unexpected/unexplained difference between git pull --rebase and git rebase
John Keeping j...@keeping.me.uk writes: git-rebase assumes that if you give an explicit upstream then you want precisely what you asked for. From git-rebase(1): If either upstream or --root is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. Correct. You ask it to rebase the history without guessing by being explicit; the command guesses when you are not explicit and being lazy ;-). -- To unsubscribe from this list: send the line 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: An interesting opinion on DVCS/git
Shawn Pearce spea...@spearce.org writes: We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( IIU/RC, GSoC is not only about coding. Perhaps doing a proper technical editing of the manual pages could be a summer project, to which GitHub or somebody more skilled than us developers can supply mentorship? -- To unsubscribe from this list: send the line 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: Unexpected/unexplained difference between git pull --rebase and git rebase
Thanks, that clarifies a lot.
I only have two follow-up questions:
In your branch example, how does git determine that C/D have been
rewritten and need to be replaced with their current versions
existing upstream? In this scenario I've encountered, the commit hash
and the patch ID of those commits changed because the contents of the
patches had to be modified slightly due to merge conflicts which
occurred when the upstream branch was rebased.
Also, you mentioned not building off of upstream branches which might
be rewritten. We generally try to avoid this but I don't see any
alternative with the way we do things.
upstream/master - An always-clean copy of what's fully approved and live
upstreamfeature-A
upstreamfeature-B, etc - Feature branches designed to organized
long-term new feature work
Individual developers will then create local development branches
based on those feature branches. If three people are responsible for
tasks for feature-A, they'll create development branches for each
task, do their work, and(via github enterprise) submit a pull request
so we can properly review their work, test it, etc.
The problem I have today stems from situations where a feature branch
has been merged with master. If feature-B is merged with master, and
someone rebases feature-A, there may be merge conflicts. If they fix
the conflicts, that may alter the commit history of the feature
branch, which then impacts all branches developers have based on it.
Part of me feels like we should be able to never rebase feature
branches, they should exist outside of new work merged to master.
However, it's much easier to resolve merge conflicts in small doses,
and we're in a much better position to know that we're fully updated
and can catch other problems early.
Is there a better way to do this, so that we never risk rewriting the
middle tier?
On Tue, Mar 3, 2015 at 3:40 PM, John Keeping j...@keeping.me.uk wrote:
On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
Maybe I'm lacking the distinction regarding what I'm being specific about.
In both examples, I'm asking it specifically to rebase in changes from
the remote upstream and a named branch at that location. I'm giving
git the same information, it's just interpreting it differently - and
I'm not understanding why.
Not quite. If you say:
git rebase $sha1
then you're telling git-rebase to apply the commits $sha1..HEAD onto
$sha1.
If you say:
git rebase
then it will be re-written as:
git rebase --fork-point @{upstream}
in which case Git will apply more complicated logic so that you can
recover from the case where @{upstream} has been re-written.
Consider the following scenario:
F branch
/
C -- D master@{1}
/
A -- B -- C' -- D' -- E master
where C' and D' are rewritten versions of C and D.
In this case, imagine you are at F on branch, git rebase master will
replace C, D and F onto E because you have explicitly selected to replay
master..branch onto master.
git rebase will apply the fork-point logic and realise that D is a
previous version of master, so it will only replay F onto E.
In general if you just want to rebase onto your upstream it is simpler
to just call git rebase which will do the right thing; it's also
shorter to type ;-)
My local branch would have been created from the
upstream/feature-branch, and will eventually be merged back into it.
Until I'm ready for that, I regularly rebase the work done on
upstream/feature-branch so that my local work is always clean and
above anything else.
In this case the problem stems from the fact that
upstream/feature-branch has been rewritten. Building on top of branches
that will be rewritten is not advisable unless you have a really good
reason to do so.
On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
git-rebase assumes that if you give an explicit upstream then you want
precisely what you asked for. From git-rebase(1):
If either upstream or --root is given on the command line,
then the default is `--no-fork-point`, otherwise the default is
`--fork-point`.
Correct.
You ask it to rebase the history without guessing by being explicit;
the command guesses when you are not explicit and being lazy ;-).
--
Mike Botsko
Lead Dev @ Helion3
Ph: 1-(503)-897-0155
--
To unsubscribe from this list: send the line 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] Disclaimer about the number of slots.
This is debatable, but this may discourrage students who picked Git more or less at random. If I read https://code.google.com/p/google-summer-of-code/wiki/ProgramStatistics correctly, the average number of slots per organization is closer to 10 than 2, hence students have better chance to get accepted in other organizations. OTOH, 2 slots is not so much worse than the 3 we had last year. And now that Dscho is volunteer to mentor a GSoC too, we may actually end up accepting 3 students. Signed-off-by: Matthieu Moy matthieu@imag.fr --- So, sending this in case other people think it's a good idea, but I won't fight for it in case you don't think it is. SoC-2015-Ideas.md | 5 + 1 file changed, 5 insertions(+) diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index d2b7d75..23c8313 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -20,6 +20,11 @@ Please, include link(s) to the mailing-list discussion(s) related to your microproject in your application (e.g. linking to [gmane](http://news.gmane.org/gmane.comp.version-control.git)). +## Note about the number of slots + +In 2015, the Git organization has very limited mentoring capacity. +We will probably be able to accept 2 students only this year. + ## Summer of code main project ideas **Students**: Please consider these ideas as starting points for -- 2.3.0.157.g79e124b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Ask students to include a link to their microproject in their application
It makes it easier for us when reviewing/selecting candidates. Signed-off-by: Matthieu Moy matthieu@imag.fr --- (Sending this to the list for comments, but now I can even do the push myself :-) ) SoC-2015-Ideas.md | 4 1 file changed, 4 insertions(+) diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md index 86de476..d2b7d75 100644 --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -16,6 +16,10 @@ way for us to get experience with applicants, but it will also help applicants become familiar with Git's development and submission process. +Please, include link(s) to the mailing-list discussion(s) related to +your microproject in your application (e.g. linking to +[gmane](http://news.gmane.org/gmane.comp.version-control.git)). + ## Summer of code main project ideas **Students**: Please consider these ideas as starting points for -- 2.3.0.157.g79e124b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Ask students to include a link to their microproject in their application
On Wed, Mar 04, 2015 at 08:19:30AM +0100, Matthieu Moy wrote: --- a/SoC-2015-Ideas.md +++ b/SoC-2015-Ideas.md @@ -16,6 +16,10 @@ way for us to get experience with applicants, but it will also help applicants become familiar with Git's development and submission process. +Please, include link(s) to the mailing-list discussion(s) related to +your microproject in your application (e.g. linking to +[gmane](http://news.gmane.org/gmane.comp.version-control.git)). Yeah, this is a good idea. In fact, we can provide an application template to students via the Melange system. I don't recall doing so in the past few years, but we did use this feature at one point: https://git.wiki.kernel.org/index.php/SoC2007Template However, I don't recall it leading to especially better-quality applications (in fact, it may have made things worse because many students filled it out in a very perfunctory way and then assumed that was enough). -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 2/2] Disclaimer about the number of slots.
Jeff King p...@peff.net writes: Maybe something along the lines of If you are really excited about working on git, we would love to see your application; if you are just looking for a random project, there may be a lot of competition for a small number of slots. Except I am not quite sure how to phrase just looking for a random project that does not sound quite so demeaning. Yes, that's the idea, but I didn't find a way to say if you're one of the great students we're looking for, please come in, otherwise go away, so I went for a neutral wording that would let the reader infer it by themselves ;-). -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reset: allow - short hand for previous commit
Hi,
Matthieu Moy matthieu@grenoble-inp.fr writes:
Sudhanshu Shekhar sudshekha...@gmail.com writes:
From: SudShekhar sudshekha...@gmail.com
Please, set your configuration to have the same identity for commit and
send-email. It seems your commiter ID (user.name) does not contain your
last name.
Actually, the token does not match either of the two names; it looks
like two names smashed together into a single nickname token.
Sorry, I had set my irc nick as the commiter id. I have changed this to my name.
builtin/reset.c | 2 ++
Doesn't this deserve a test?
+ if(!strcmp(argv[0],-))
+ argv[0]=@{-1};
Wrong spacing (around = and after ,).
Thanks for pointing this out. I have corrected it.
What should worry us even more is what the user would get when @{-1}
does not resolve to something the command can use. It would be bad
if we give an error message with @{-1} in it that the user never
typed (and may not even understand what it means).
I apologize for having overlooked this use case. I have made some
changes and I think this should work now. I will email the updated
patch in the next email (I hope this is the correct procedure). Please
let me know your thoughts.
Also, this use case hasn't been handled in the case of git merge.
Another thing, can someone guide me regarding the right place to add a
test case? Should it be t7102-reset.sh or some other file?
--
To unsubscribe from this list: send the line 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] xmerge.c: fix xdl_merge to conform with the manual
On Tue, Mar 3, 2015 at 3:17 PM, Torsten Bögershausen tbo...@web.de wrote: On 2015-03-03 18.37, Anton Trunov wrote: [] Signed-off-by: Anton Trunov anton.a.trunov at gmail.com Should we use the real email here (with the '@') ? --- diff --git a/t/t3032-merge-recursive-options.sh b/t/t3032-merge-recursive-options.sh index 4029c9c..4cbedb4 100755 --- a/t/t3032-merge-recursive-options.sh +++ b/t/t3032-merge-recursive-options.sh @@ -204,4 +204,47 @@ test_expect_success '--ignore-space-at-eol' ' test_cmp expected actual ' +# Setup for automerging with whitespace-only changes +# on both sides and in *all* lines + +test_expect_success 'setup: w/s only changes in all lines on both sides' ' + git rm -rf . + git clean -fdqx + rm -rf .git + git init missing + + echo two words text.txt + git add text.txt + test_tick + git commit -m Initial revision + + git checkout -b remote + echo \t\ttwo words text.txt Use of echo \t is not portable. Either embed literal tab characters or use printf \t. + git commit -a -m remote: insert whitespace only + + git checkout master + echo two words text.txt + git commit -a -m master: insert whitespace only +' + +test_expect_success 'w/s only in all lines: --ignore-space-change preserves ours' ' -- To unsubscribe from this list: send the line 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] rebase-interactive: re-word item count comment
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10)
taught rebase-interactive to display an item count in the instruction
list comments:
# Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s))
#
# Commands:
# p, pick = use commit
# ...
However, with the exception of the --edit-todo option, TODO is a
one-off term, never presented to the user by rebase-interactive in
any other context. The item count is in fact the number of commands
(pick, edit, etc.) remaining on the instruction sheet, and the
comment immediately following it talks about Commands. Consequently,
replace (# TODO item(s)) with the more accurate and meaningful
(# command(s)).
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Junio suggested[1] the wording # todo items in place of # commits
from the original submission, however, I find (# TODO items) quite
clunky to read. (# commands) feels more natural and streamlined, but
is also a case of bike-shedding and personal preference, so this patch
could easily be dropped.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/259365/focus=261143
git-rebase--interactive.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index ab98b13..f7deeb0 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1034,7 +1034,7 @@ todocount=${todocount##* }
cat $todo EOF
-$comment_char Rebase $shortrevisions onto $shortonto ($todocount TODO item(s))
+$comment_char Rebase $shortrevisions onto $shortonto ($todocount command(s))
EOF
append_todo_help
git stripspace --comment-lines $todo \EOF
--
2.3.1.340.gf490742
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] rebase-interactive: suppress whitespace preceding item count
97f05f43 (Show number of TODO items for interactive rebase, 2014-12-10)
taught rebase-interactive to compute an item count with 'wc -l' and
display it in the instruction list comments:
# Rebase 46640c6..5568fd5 onto 46640c6 (4 TODO item(s))
On Mac OS X, however, it renders as:
# Rebase 46640c6..5568fd5 onto 46640c6 ( 4 TODO item(s))
since 'wc -l' indents its output with leading spaces. Fix this.
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
---
Consistent with existing tests in t3404, the new test uses plain 'grep'
rather than 'test_i18ngrep'.
git-rebase--interactive.sh| 1 +
t/t3404-rebase-interactive.sh | 9 +
2 files changed, 10 insertions(+)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c96b984..ab98b13 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -1030,6 +1030,7 @@ test -n $autosquash rearrange_squash $todo
test -n $cmd add_exec_commands $todo
todocount=$(git stripspace --strip-comments $todo | wc -l)
+todocount=${todocount##* }
cat $todo EOF
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index a31f7e0..034eb35 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -1046,4 +1046,13 @@ test_expect_success 'respect core.abbrev' '
test 4 = $(grep -c pick [0-9a-f]\{12,\} todo-list)
'
+test_expect_success 'todo count' '
+ write_script dump-raw.sh -\EOF
+ cat $1
+ EOF
+ test_set_editor $(pwd)/dump-raw.sh
+ git rebase -i HEAD~4 actual
+ grep ^# Rebase ..* onto ..* ([0-9] actual
+'
+
test_done
--
2.3.1.340.gf490742
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Git Newbie - GSoC mini Project
Hi, I'm a newbie to git. I started working on git. I cloned the git repository and started hacking it. I need a suggestion on how to start working on the micro project Make git -C '' cmd not to barf. Thank you for your suggestion in advance. Regards, Prudhvee, open source enthusiast. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] git-credential-store: support XDG config dir
Paul Tan pyoka...@gmail.com writes:
Teach git-credential-store to read/write credentials from
$XDG_CONFIG_HOME/git/credentials and ~/.git-credentials where
appropriate:
* get: call lookup_credential() on the XDG file first if it exists. If
the credential can't be found, call lookup_credential() on the HOME
file.
* erase: Call remove_credential() on both the XDG file if it exists and
the HOME file if it exists.
* store: If the XDG file exists, call store_credential() on the XDG file
and remove_credential() on the HOME file to prevent duplicates.
* If --file is provided, use the file for all operations instead.
In order to support the above, parse_credential_file() now returns 1 if
it finds a matching credential, and 0 if it does not. Likewise,
lookup_credential() returns 1 if it could find the credential, and 0 if
it could not.
Signed-off-by: Paul Tan pyoka...@gmail.com
---
I agree with everything Matthieu said ;-)
diff --git a/credential-store.c b/credential-store.c
index 925d3f4..18b8897 100644
--- a/credential-store.c
+++ b/credential-store.c
@@ -6,7 +6,7 @@
static struct lock_file credential_lock;
-static void parse_credential_file(const char *fn,
+static int parse_credential_file(const char *fn,
struct credential *c,
void (*match_cb)(struct credential *),
void (*other_cb)(struct strbuf *))
@@ -14,18 +14,20 @@ static void parse_credential_file(const char *fn,
FILE *fh;
struct strbuf line = STRBUF_INIT;
struct credential entry = CREDENTIAL_INIT;
+ int found_credential = 0;
fh = fopen(fn, r);
if (!fh) {
if (errno != ENOENT)
die_errno(unable to open %s, fn);
- return;
+ return 0;
Returning found_credential here would be easier to read, no? After
all, that is why you explicitly initialized it to 0 up there to say
no we haven't found any yet.
+ if (!strcmp(op, get)) {
+ if (file) {
+ lookup_credential(file, c);
+ } else {
+ if (xdg_file access_or_warn(xdg_file, R_OK, 0) == 0)
+ ret = lookup_credential(xdg_file, c);
+ if (!ret home_file access_or_warn(home_file,
R_OK, 0) == 0)
+ lookup_credential(home_file, c);
+ }
+ } else if (!strcmp(op, erase)) {
+ if (file) {
+ remove_credential(file, c);
+ } else {
+ if (xdg_file access(xdg_file, F_OK) == 0)
+ remove_credential(xdg_file, c);
+ if (home_file access(home_file, F_OK) == 0)
+ remove_credential(home_file, c);
+ }
+ } else if (!strcmp(op, store)) {
+ if (file) {
+ store_credential(file, c);
+ } else if (xdg_file access(xdg_file, F_OK) == 0) {
+ store_credential(xdg_file, c);
+ if (home_file access(home_file, F_OK) == 0
+ c.protocol (c.host || c.path) c.username
+ c.password)
If you have to chomp, do it like this instead:
+ if (home_file access(home_file, F_OK) == 0
+ c.protocol (c.host || c.path)
+ c.username c.password)
It would make it more clear that the second line is about the URL
being accessed while the last line is about the user.
+ remove_credential(home_file, c);
+ } else
+ store_credential(home_file, c);
The repetitiousness of the above three blocks looked somewhat
disturbing, but I guess you cannot avoid it because of the subtle
differences among these codepaths. When getting, you want to get
from only one place, and while not having an earlier candidate is
not an error, an existing but unreadable file deserves a warning.
When erasing, you want to erase from everywhere.
I am not sure if I understand what you are doing in the store
codepath. If your get will read from xdg (if available) without
looking at home anyway, why do you need to remove it from home?
Wouldn't the leftover be ignored 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 1/2] docs: explain behaviour with no tagopt set
Currently, only the behaviour when this option is set is explained, but it's unclear what happens when this option hasn't been set. Signed-off-by: Kevin Daudt m...@ikke.info --- Documentation/config.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt index 440784c..394042a 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -2241,8 +2241,9 @@ remote.name.tagopt:: Setting this value to \--no-tags disables automatic tag following when fetching from remote name. Setting it to \--tags will fetch every tag from remote name, even if they are not reachable from remote - branch heads. Passing these flags directly to linkgit:git-fetch[1] can - override this setting. See options \--tags and \--no-tags of + branch heads. When not set, fetches only tags reachable by the + downloaded refs. Passing these flags directly to linkgit:git-fetch[1] + can override this setting. See options \--tags and \--no-tags of linkgit:git-fetch[1]. remote.name.vcs:: -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] docs: explain behaviour of remote add without tag option
Only behaviour with these options are currently explained. Add explanation what the default behaviour is. Signed-off-by: Kevin Daudt m...@ikke.info --- Documentation/git-remote.txt | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt index a77607b..5bde0e1 100644 --- a/Documentation/git-remote.txt +++ b/Documentation/git-remote.txt @@ -58,6 +58,9 @@ remote repository. With `--no-tags` option, `git fetch name` does not import tags from the remote repository. + +With neither `--tags` or `--no-tags` set, imports only tags that are +reachable from downloaded history. ++ With `-t branch` option, instead of the default glob refspec for the remote to track all branches under the `refs/remotes/name/` namespace, a refspec to track only `branch` -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] reset: allow - short hand for previous commit
Matthieu Moy matthieu@grenoble-inp.fr writes:
Sudhanshu Shekhar sudshekha...@gmail.com writes:
From: SudShekhar sudshekha...@gmail.com
Please, set your configuration to have the same identity for commit and
send-email. It seems your commiter ID (user.name) does not contain your
last name.
Actually, the token does not match either of the two names; it looks
like two names smashed together into a single nickname token.
builtin/reset.c | 2 ++
Doesn't this deserve a test?
+ if(!strcmp(argv[0],-))
+ argv[0]=@{-1};
Wrong spacing (around = and after ,).
What should worry us even more is what the user would get when @{-1}
does not resolve to something the command can use. It would be bad
if we give an error message with @{-1} in it that the user never
typed (and may not even understand what it means).
--
To unsubscribe from this list: send the line 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: Unexpected/unexplained difference between git pull --rebase and git rebase
Maybe I'm lacking the distinction regarding what I'm being specific about. In both examples, I'm asking it specifically to rebase in changes from the remote upstream and a named branch at that location. I'm giving git the same information, it's just interpreting it differently - and I'm not understanding why. My local branch would have been created from the upstream/feature-branch, and will eventually be merged back into it. Until I'm ready for that, I regularly rebase the work done on upstream/feature-branch so that my local work is always clean and above anything else. On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote: John Keeping j...@keeping.me.uk writes: git-rebase assumes that if you give an explicit upstream then you want precisely what you asked for. From git-rebase(1): If either upstream or --root is given on the command line, then the default is `--no-fork-point`, otherwise the default is `--fork-point`. Correct. You ask it to rebase the history without guessing by being explicit; the command guesses when you are not explicit and being lazy ;-). -- Mike Botsko Lead Dev @ Helion3 Ph: 1-(503)-897-0155 -- To unsubscribe from this list: send the line 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: Unexpected/unexplained difference between git pull --rebase and git rebase
On Tue, Mar 03, 2015 at 03:20:48PM -0800, Mike Botsko wrote:
Maybe I'm lacking the distinction regarding what I'm being specific about.
In both examples, I'm asking it specifically to rebase in changes from
the remote upstream and a named branch at that location. I'm giving
git the same information, it's just interpreting it differently - and
I'm not understanding why.
Not quite. If you say:
git rebase $sha1
then you're telling git-rebase to apply the commits $sha1..HEAD onto
$sha1.
If you say:
git rebase
then it will be re-written as:
git rebase --fork-point @{upstream}
in which case Git will apply more complicated logic so that you can
recover from the case where @{upstream} has been re-written.
Consider the following scenario:
F branch
/
C -- D master@{1}
/
A -- B -- C' -- D' -- E master
where C' and D' are rewritten versions of C and D.
In this case, imagine you are at F on branch, git rebase master will
replace C, D and F onto E because you have explicitly selected to replay
master..branch onto master.
git rebase will apply the fork-point logic and realise that D is a
previous version of master, so it will only replay F onto E.
In general if you just want to rebase onto your upstream it is simpler
to just call git rebase which will do the right thing; it's also
shorter to type ;-)
My local branch would have been created from the
upstream/feature-branch, and will eventually be merged back into it.
Until I'm ready for that, I regularly rebase the work done on
upstream/feature-branch so that my local work is always clean and
above anything else.
In this case the problem stems from the fact that
upstream/feature-branch has been rewritten. Building on top of branches
that will be rewritten is not advisable unless you have a really good
reason to do so.
On Tue, Mar 3, 2015 at 3:15 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
git-rebase assumes that if you give an explicit upstream then you want
precisely what you asked for. From git-rebase(1):
If either upstream or --root is given on the command line,
then the default is `--no-fork-point`, otherwise the default is
`--fork-point`.
Correct.
You ask it to rebase the history without guessing by being explicit;
the command guesses when you are not explicit and being lazy ;-).
--
To unsubscribe from this list: send the line 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: An interesting opinion on DVCS/git
On 03 Mar 2015, Shawn Pearce Wrote: On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( In real life, I do process automation, so I'm coming at this from a slightly different point of view. What appeals to me about git is the richness of processes that can be implemented with it. You may want to consider it a complex process enabler engine that happens to do DVCS. Having built one of these also, and being saddled with huge numbers of requirements, I can say from experience that complexity is a side effect of doing what you need to do. Like many complex products, git takes on a life of its own, and obviously chose completeness instead of simplicity as a goal. Personally, I am not complaining, but I hear the complaints too. The bigger complaints are when you cannot do your job because the engine is not rich enough (see anything derived from SCCS - yes saying that shows my hair colour), which forced my company *to* git. When looking at git, I personally feel that it is important to deploy simple-to-use scripts and instructions to implement the process you want to use - and I hate to leave a footprint saying this, but, people are fundamentally lazy about non-goal activities. Thinking about mundane tasks like committing and delivering is outside the typical work-instruction box, but if, as a repository manager, you need a rich engine, spend the couple of days and script it. I think the objections in the article are essentially sound, from one point of view, but omit the core domain-space of why git is around and necessary, as opposed to many other unnamed RCS-like systems that are *not* sufficient. http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( Mockery is the not the kindest form of flattery, but it sure is the sincerest. I've been the target of this too. Laugh, and suggest workflows. And, for the record, the only way you will remove atomicity/immutability of changes is out of my cold dead hands. :) Cheers, Randall -- To unsubscribe from this list: send the line 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: An interesting opinion on DVCS/git
On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An interesting opinion on DVCS/git
On Tue, 3 Mar 2015, Shawn Pearce wrote: On Sun, Mar 1, 2015 at 7:29 PM, Stefan Beller sbel...@google.com wrote: bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity Indeed, a DVCS like Git or Hg does not fit everyone. And neither do centralized systems like Subversion. Choice is good. However... I found some passages troubling for Git, e.g.: ---snip--- Git is so amazingly simple to use that APress, a single publisher, needs to have three different books on how to use it. It’s so simple that Atlassian and GitHub both felt a need to write their own online tutorials to try to clarify the main Git tutorial on the actual Git website. It’s so transparent that developers routinely tell me that the easiest way to learn Git is to start with its file formats and work up to the commands. ---snap--- We have heard this sort of feedback for years. But we have been unable to adequately write our own documentation or clean up our man pages to be useful to the average person who doesn't know why the --no-frobbing option doesn't disable the --frobinator option to the --frobbing-subcommand of git frob. :( http://git-man-page-generator.lokaltog.net/ shouldn't exist and shouldn't be funny. Yet it does. :( As for the different online tutorials, I'll point out that every university that supports it's students using Thunderbird has it's own version of a tutorial on how to use and configure Thunderbird. The question is if they are coverying their one use case of how to use git with their service, or if they are trying to duplicate the git documentation. There are two reasons for having multiple books out for a piece of software 1. the software is horribly complicated to use, even for beginners 2. the software is extremely powerful, to to understand all the different advanced options, and when to use them, takes a lot of explination In the case of git, there's a bit of both. Part of the problem is that there are so many different ways to use it (all in common use) that there isn't one simple set of insructions that will be right in all the different use cases (thus the value of services that force users to operate in one specific model providing a tutorial in how to use it with their service) At this point, Internet Lore says git is hard to use, and if you approach any software with that attitude, you will find lots of things to point at to justify your opinion. I'm not saying that there isn't room for improvement, I'm just saying that the evidence provided is not as one-sided as they make it sound. David Lang
Re: [PATCH 2/2] tests: test credential-store XDG support
Paul Tan pyoka...@gmail.com writes:
* helper_test store is run for when $XDG_CONFIG_HOME/git/credentials
exists and ~/.git-credentials does not and the other way around.
* Test that credentials are stored in XDG file if both XDG and HOME
files exist.
* Test that credentials from XDG file are used if matching credentials
are found in both XDG and HOME files.
* Test that credentials from HOME file are used if a matching credential
could not be found in the XDG file.
* Test that when erasing credentials, matching credentials in both the
XDG and HOME files are erase.d
Signed-off-by: Paul Tan pyoka...@gmail.com
---
Again, I agree with everything Matthieu said ;-)
+test_expect_success 'XDG credentials will not be created if it does not
exist' '
+ test ! -e ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+'
You repeat this ${XDG_CONFIG_HOME:-$HOME/.config} all over, but is
that necessary? The test environment is under your control, so if
you know you have XDG_CONFIG_HOME at this point in the test, don't
use the fallback. If you want to test _both_, on the other hand,
then test both in separate tests.
+# Tests for when both $XDG_CONFIG_HOME/git/credentials and
+# ~/.git-credentials exists.
+echo '' $HOME/.git-credentials
+echo '' ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
Do you need one empty line in each of these file, or is existence of
these two files what you care? If the latter, then just redirect
into it without any command, like this:
$HOME/.git-credentials
+test_expect_success 'Credentials are stored in XDG file if both XDG and HOME
files exist' '
+ check approve store -\EOF
+ protocol=https
+ host=example.com
+ username=store-user
+ password=store-pass
+ EOF
+ read contents ${XDG_CONFIG_HOME:-$HOME/.config}/git/credentials
+ test ! -z $contents
In an earlier part of this patch, you used test -s FILE. Do you
have to use read $it test [!] -z $it here?
+ read contents $HOME/.git-credentials
+ test -z $contents
Missing everywhere (not just this test).
check approve store -\EOF
...
EOF
read ...
...
If check approve exited with a non-zero status, that won't be
noticed as long as .../git/credentials file happens to have the
contents that passes the later part of the test, which is not what
we want.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Tue, Mar 3, 2015 at 5:54 PM, Duy Nguyen pclo...@gmail.com wrote: On Wed, Mar 4, 2015 at 12:13 AM, Junio C Hamano gits...@pobox.com wrote: My recollection is that the consensus from the last time we discussed protocol revamping was to list one capability per packet so that packet length limit does not matter, but you may want to check with the list archive yourself. I couldn't find that consensus mail, but this one [1] is good enough evidence that we can hit packet length limit in capability line easily. With an escape hatch to allow maximum packet length up to uint_max, I The symbolic ref thing was done badly. There isn't an escape hatch in current v1 protocol sufficient to allow this but each ref should be its own pkt-line, or should be a small batch of refs per pkt-line, or the ref advertisement should be a data stream in a side-band-64k sort of format inside the pkt-line framing. At 64k per frame of side-band there is plenty of data to header ratio that we don't need to escape to uint_max. Looks like one cap per pkt-line is winning.. Yes. [1] http://thread.gmane.org/gmane.comp.version-control.git/237929 Let me go on a different tangent a bit from the current protocol. http://www.grpc.io/ was recently released and is built on the HTTP/2 standard. It uses protobuf as a proven extensibility mechanism. Including a full C based grpc stack just to speak the Git wire protocol is quite likely overkill, but I think the embedding of a proven extensible format inside of a bi-directional framed streaming system like HTTP/2 offers some good guidance. Network protocol parsing is hard. Especially in languages like C where buffer overflows are possible. Or where a client could trivially DoS a server by sending a packet of size uint_max and the server naively trying to malloc() that buffer. Defining the network protocol in an IDL like protobuf 3 and being machine generated from stable well maintained code has its advantages. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] gitk: write only changed configuration variables
When gitk contains some changed parameter, and there is existing
instance of gitk where the parameter is still old, it is reverted to
that old value when the instance exits.
Instead, store a parameter in config only it is has been modified in the
exiting instance. Otherwise, preserve the value which currently is in
file. This allows editing the configuration when several instances are
running, and don't get rollback of the modification if some other
instance where the configuration was not edited is closed last.
For scalar variables, use trace(3tcl) to detect their change. Since `trace` can
send bogus events, doublecheck if the value has really been changed, but once
it is marked as changed, do not reset it back to unchanged ever, because if
user has restored the original value, it's the decision which should be stored
as well as modified value.
Treat view list especially: instead of rewriting the whole list, merge
individual views. Place old and updated views at their older placed, add
new ones to the end of list. Collect modified view explicitly, in newviewok{}
and delview{}.
Do not merge geometry values. They are almost always changing because
user moves and resises windows, and there is no way to find which one of
the geometries is most desired. Just overwrite them unconditionally,
like earlier.
Signed-off-by: Max Kirillov m...@max630.net
---
gitk | 86
1 file changed, 76 insertions(+), 10 deletions(-)
diff --git a/gitk b/gitk
index 78358a7..5f09756 100755
--- a/gitk
+++ b/gitk
@@ -2776,12 +2776,38 @@ proc doprogupdate {} {
}
}
+proc config_init_trace {name} {
+global config_variable_changed config_variable_original
+
+upvar #0 $name var
+set config_variable_changed($name) 0
+set config_variable_original($name) $var
+}
+
+proc config_variable_change_cb {name name2 op} {
+global config_variable_changed config_variable_original
+
+upvar #0 $name var
+if {$op eq write
+ (![info exists config_variable_original($name)] ||
+$config_variable_original($name) ne $var)} {
+ set config_variable_changed($name) 1
+}
+}
+
proc savestuff {w} {
-global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
-global use_ttk
global stuffsaved
global config_file config_file_tmp
-global config_variables
+global config_variables config_variable_changed
+global viewchanged
+
+upvar #0 viewname current_viewname
+upvar #0 viewfiles current_viewfiles
+upvar #0 viewargs current_viewargs
+upvar #0 viewargscmd current_viewargscmd
+upvar #0 viewperm current_viewperm
+upvar #0 nextviewnum current_nextviewnum
+upvar #0 use_ttk current_use_ttk
if {$stuffsaved} return
if {![winfo viewable .]} return
@@ -2793,16 +2819,24 @@ proc savestuff {w} {
if {$::tcl_platform(platform) eq {windows}} {
file attributes $config_file_tmp -hidden true
}
+ if {[file exists $config_file]} {
+ source $config_file
+ }
foreach var_name $config_variables {
upvar #0 $var_name var
- puts $f [list set $var_name $var]
+ upvar 0 $var_name old_var
+ if {!$config_variable_changed($var_name) [info exists old_var]} {
+ puts $f [list set $var_name $old_var]
+ } else {
+ puts $f [list set $var_name $var]
+ }
}
puts $f set geometry(main) [wm geometry .]
puts $f set geometry(state) [wm state .]
puts $f set geometry(topwidth) [winfo width .tf]
puts $f set geometry(topheight) [winfo height .tf]
- if {$use_ttk} {
+ if {$current_use_ttk} {
puts $f set geometry(pwsash0) \[.tf.histframe.pwclist sashpos 0]
1\
puts $f set geometry(pwsash1) \[.tf.histframe.pwclist sashpos 1]
1\
} else {
@@ -2812,11 +2846,33 @@ proc savestuff {w} {
puts $f set geometry(botwidth) [winfo width .bleft]
puts $f set geometry(botheight) [winfo height .bleft]
+ array set view_save {}
+ array set views {}
+ if {![info exists permviews]} { set permviews {} }
+ foreach view $permviews {
+ set view_save([lindex $view 0]) 1
+ set views([lindex $view 0]) $view
+ }
puts -nonewline $f set permviews {
- for {set v 0} {$v $nextviewnum} {incr v} {
- if {$viewperm($v)} {
- puts $f {[list $viewname($v) $viewfiles($v) $viewargs($v)
$viewargscmd($v)]}
+ for {set v 1} {$v $current_nextviewnum} {incr v} {
+ if {$viewchanged($v)} {
+ if {$current_viewperm($v)} {
+ set views($current_viewname($v)) [list
$current_viewname($v) $current_viewfiles($v) $current_viewargs($v)
$current_viewargscmd($v)]
+ } else {
+ set view_save($current_viewname($v)) 0
+ }
+ }
+ }
+
[PATCH v5 3/3] gitk: synchronize config write
If several gitk instances are closed simultaneously, safestuff procedure
can run at the same time, resulting in a conflict which may cause losing
of some of the instance's changes, failing the saving operation or even
corrupting the configuration file. This can happen, for example, at user
session closing, or at group closing of all instances of an application
which is possible in some desktop environments.
To avoid this, make sure that only one saving operation is in progress.
It is guarded by existance of $config_file_tmp file. Both creating the
file and moving it to $config_file are atomic operations, so it should
be reliable.
Reading does not need to be syncronized, because moving is atomic
operation, and the $config_file always refers to full and correct file.
But, if there is a stale $config_file_tmp file, report it at gitk start.
If such file is detected at saving, just report it abort the saving, as
other saving error does.
Signed-off-by: Max Kirillov m...@max630.net
---
gitk | 29 ++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 9404d5d..b2cfd47 100755
--- a/gitk
+++ b/gitk
@@ -2776,6 +2776,19 @@ proc doprogupdate {} {
}
}
+proc config_check_tmp_exists {tries_left} {
+global config_file_tmp
+
+if {[file exists $config_file_tmp]} {
+ incr tries_left -1
+ if {$tries_left 0} {
+ after 100 [list config_check_tmp_exists $tries_left]
+ } else {
+ error_popup Probably there is stale $config_file_tmp file; config
saving is going to fail. Check if it is being used by any existing gitk process
and remove it otherwise
+ }
+}
+}
+
proc config_init_trace {name} {
global config_variable_changed config_variable_original
@@ -2811,11 +2824,16 @@ proc savestuff {w} {
if {$stuffsaved} return
if {![winfo viewable .]} return
+set remove_tmp 0
if {[catch {
- if {[file exists $config_file_tmp]} {
- file delete -force $config_file_tmp
+ set try_count 0
+ while {[catch {set f [open $config_file_tmp {WRONLY CREAT EXCL}]}]} {
+ if {[incr try_count] 50} {
+ error Unable to write config file: $config_file_tmp exists
+ }
+ after 100
}
- set f [open $config_file_tmp w]
+ set remove_tmp 1
if {$::tcl_platform(platform) eq {windows}} {
file attributes $config_file_tmp -hidden true
}
@@ -2877,9 +2895,13 @@ proc savestuff {w} {
puts $f }
close $f
file rename -force $config_file_tmp $config_file
+ set remove_tmp 0
} err]} {
puts Error saving config: $err
}
+if {$remove_tmp} {
+ file delete -force $config_file_tmp
+}
set stuffsaved 1
}
@@ -12170,6 +12192,7 @@ catch {
}
source $config_file
}
+config_check_tmp_exists 50
set config_variables {
mainfont textfont uifont tabstop findmergefiles maxgraphpct maxwidth
--
2.1.1.391.g7a54a76
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 2/3] gitk: report file saving error
Signed-off-by: Max Kirillov m...@max630.net
---
gitk | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 5f09756..9404d5d 100755
--- a/gitk
+++ b/gitk
@@ -2811,7 +2811,7 @@ proc savestuff {w} {
if {$stuffsaved} return
if {![winfo viewable .]} return
-catch {
+if {[catch {
if {[file exists $config_file_tmp]} {
file delete -force $config_file_tmp
}
@@ -2877,6 +2877,8 @@ proc savestuff {w} {
puts $f }
close $f
file rename -force $config_file_tmp $config_file
+} err]} {
+puts Error saving config: $err
}
set stuffsaved 1
}
--
2.1.1.391.g7a54a76
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/3] gitk: save only changed configuration on exit
The changes:
* remove unused views_modified_names assignment
* use if {[catch...] to check saving error
* split error reporting from busy wait
The busy wait parameters are unchanged, mostly because I did not have time yet
to test them.
Max Kirillov (3):
gitk: write only changed configuration variables
gitk: report file saving error
gitk: synchronize config write
gitk | 119 +++
1 file changed, 105 insertions(+), 14 deletions(-)
--
2.1.1.391.g7a54a76
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Segfault with rev-list --bisect
On Tue, Mar 03, 2015 at 09:19:14AM -0500, Troy Moure wrote:
I've found a case where git rev-list --bisect segfaults reproducibly
(git version is 2.3.1). This is the commit topology (A2 is the first
parent of M):
I - A1 - A2
\\
- B1 -- M (HEAD)
Thanks for finding a simple history which shows the problem. I recreated
this with:
git init repo cd repo
echo I I git add I git commit -m I
echo A1 A git add A git commit -m A1
echo A2 A git add A git commit -m A2
git checkout -b side HEAD~2
echo B1 B git add B git commit -m B1
git checkout master
GIT_EDITOR=: git merge side
and was able to reproduce the segfault with:
git rev-list --bisect --first-parent HEAD --not HEAD~1
(it drops --parents from your command, which is not relevant to the
segfault). The segfault itself happens because we try to access the
weight() of B1, even though we never called weight_set() on it.
And that, I think, is related to --first-parent. We do not set a weight
because B1 is not an interesting commit to us (it is accessible only as
a second parent). I am not too familiar with the bisect code, but it
looks like it is not really ready to handle --first-parent. There are
several spots where it enumerates the parent list, which is going to
examine parents other than the first.
Below is a fairly hacky patch to respect --first-parent through the
bisection code. Like I said, I'm not very familiar with this code, so I
basically just blindly limited any traversal of commit-parents. It does
solve this particular segfault, but I have no clue if it is fixing other
bugs introducing them. :) E.g., it's changing count_distance(), so
perhaps our bisection counts were all off with --first-parent, even when
it didn't segfault?
diff --git a/bisect.c b/bisect.c
index 8c6d843..c51f37a 100644
--- a/bisect.c
+++ b/bisect.c
@@ -31,7 +31,7 @@ static const char *argv_update_ref[] = {update-ref,
--no-deref, BISECT_HEAD
* We care just barely enough to avoid recursing for
* non-merge entries.
*/
-static int count_distance(struct commit_list *entry)
+static int count_distance(struct commit_list *entry, int max_parents)
{
int nr = 0;
@@ -47,9 +47,10 @@ static int count_distance(struct commit_list *entry)
p = commit-parents;
entry = p;
if (p) {
+ int n = max_parents - 1;
p = p-next;
- while (p) {
- nr += count_distance(p);
+ while (p n-- 0) {
+ nr += count_distance(p, max_parents);
p = p-next;
}
}
@@ -79,12 +80,12 @@ static inline void weight_set(struct commit_list *elem, int
weight)
*((int*)(elem-item-util)) = weight;
}
-static int count_interesting_parents(struct commit *commit)
+static int count_interesting_parents(struct commit *commit, int max_parents)
{
struct commit_list *p;
int count;
- for (count = 0, p = commit-parents; p; p = p-next) {
+ for (count = 0, p = commit-parents; p max_parents-- 0; p =
p-next) {
if (p-item-object.flags UNINTERESTING)
continue;
count++;
@@ -117,7 +118,7 @@ static inline int halfway(struct commit_list *p, int nr)
#define show_list(a,b,c,d) do { ; } while (0)
#else
static void show_list(const char *debug, int counted, int nr,
- struct commit_list *list)
+ struct commit_list *list, int max_parents)
{
struct commit_list *p;
@@ -132,6 +133,7 @@ static void show_list(const char *debug, int counted, int
nr,
char *buf = read_sha1_file(commit-object.sha1, type, size);
const char *subject_start;
int subject_len;
+ int n = max_parents;
fprintf(stderr, %c%c%c ,
(flags TREESAME) ? ' ' : 'T',
@@ -142,7 +144,7 @@ static void show_list(const char *debug, int counted, int
nr,
else
fprintf(stderr, ---);
fprintf(stderr, %.*s, 8, sha1_to_hex(commit-object.sha1));
- for (pp = commit-parents; pp; pp = pp-next)
+ for (pp = commit-parents; pp n-- 0; pp = pp-next)
fprintf(stderr, %.*s, 8,
sha1_to_hex(pp-item-object.sha1));
@@ -245,7 +247,7 @@ static struct commit_list *best_bisection_sorted(struct
commit_list *list, int n
*/
static struct commit_list *do_find_bisection(struct commit_list *list,
int nr, int *weights,
-int find_all)
+int find_all, int max_parents)
{
int n, counted;
struct commit_list *p;
@@ -257,7 +259,7 @@ static struct
Re: [RFC/PATCH 0/3] protocol v2
On Wed, Mar 4, 2015 at 12:13 AM, Junio C Hamano gits...@pobox.com wrote: My recollection is that the consensus from the last time we discussed protocol revamping was to list one capability per packet so that packet length limit does not matter, but you may want to check with the list archive yourself. I couldn't find that consensus mail, but this one [1] is good enough evidence that we can hit packet length limit in capability line easily. With an escape hatch to allow maximum packet length up to uint_max, I think we'll be fine for a long time even if we don't send one cap per pkt-line. So I'm trying to see if we really want to go with one cap per pkt-line.. Pros: - better memory management, current pkt-line static buffer is probably fine - a capability can contain spaces after '=' Cons: - some refactoring needed to hide away differences between v1 and v2 Looks like one cap per pkt-line is winning.. [1] http://thread.gmane.org/gmane.comp.version-control.git/237929 -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xmerge.c: fix xdl_merge to conform with the manual
The git-merge manual says that the ignore-space-change,
ignore-all-space, ignore-space-at-eol options preserve our version
if their version only introduces whitespace changes to a line.
So far if there is whitespace-only changes to both sides
in *all* lines their version will be used.
This commit fixes merge behavior in this case by checking
change for their version first.
Signed-off-by: Anton Trunov anton.a.trunov at gmail.com
---
t/t3032-merge-recursive-options.sh | 43 ++
xdiff/xmerge.c | 10 -
2 files changed, 48 insertions(+), 5 deletions(-)
diff --git a/t/t3032-merge-recursive-options.sh
b/t/t3032-merge-recursive-options.sh
index 4029c9c..4cbedb4 100755
--- a/t/t3032-merge-recursive-options.sh
+++ b/t/t3032-merge-recursive-options.sh
@@ -204,4 +204,47 @@ test_expect_success '--ignore-space-at-eol' '
test_cmp expected actual
'
+# Setup for automerging with whitespace-only changes
+# on both sides and in *all* lines
+
+test_expect_success 'setup: w/s only changes in all lines on both sides' '
+ git rm -rf .
+ git clean -fdqx
+ rm -rf .git
+ git init
+
+ echo two words text.txt
+ git add text.txt
+ test_tick
+ git commit -m Initial revision
+
+ git checkout -b remote
+ echo \t\ttwo words text.txt
+ git commit -a -m remote: insert whitespace only
+
+ git checkout master
+ echo two words text.txt
+ git commit -a -m master: insert whitespace only
+'
+
+test_expect_success 'w/s only in all lines: --ignore-space-change preserves
ours' '
+ echo two words expected
+ git read-tree --reset -u HEAD
+ git merge-recursive --ignore-space-change HEAD^ -- HEAD remote
+ test_cmp expected text.txt
+'
+
+test_expect_success 'w/s only in all lines: --ignore-all-space preserves ours'
'
+ echo two words expected
+ git read-tree --reset -u HEAD
+ git merge-recursive --ignore-all-space HEAD^ -- HEAD remote
+ test_cmp expected text.txt
+'
+
+test_expect_success 'w/s only in all lines: --ignore-space-at-eol fails' '
+ git read-tree --reset -u HEAD
+ test_must_fail git merge-recursive --ignore-space-at-eol HEAD^ -- HEAD
remote
+ grep text.txt
+'
+
test_done
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 625198e..2c7db26 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -596,14 +596,14 @@ int xdl_merge(mmfile_t *orig, mmfile_t *mf1, mmfile_t
*mf2,
return -1;
}
status = 0;
- if (!xscr1) {
- result-ptr = xdl_malloc(mf2-size);
- memcpy(result-ptr, mf2-ptr, mf2-size);
- result-size = mf2-size;
- } else if (!xscr2) {
+ if (!xscr2) {
result-ptr = xdl_malloc(mf1-size);
memcpy(result-ptr, mf1-ptr, mf1-size);
result-size = mf1-size;
+ } else if (!xscr1) {
+ result-ptr = xdl_malloc(mf2-size);
+ memcpy(result-ptr, mf2-ptr, mf2-size);
+ result-size = mf2-size;
} else {
status = xdl_do_merge(xe1, xscr1,
xe2, xscr2,
--
2.3.1.167.g7f4ba4b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/2] t7508: test git status -v
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- t/t7508-status.sh | 6 ++ 1 file changed, 6 insertions(+) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index 8ed5788..4989e98 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -133,6 +133,12 @@ test_expect_success 'status with status.displayCommentPrefix=false' ' test_i18ncmp expect output ' +test_expect_success 'status -v' ' + git diff --cached expect + git status -v output + test_cmp expect output +' + test_expect_success 'setup fake editor' ' cat .git/editor -\EOF #! /bin/sh -- 2.3.1.303.g5174db1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v
git commit and git status in long format show the diff between HEAD
and the index when given -v. This allows previewing a commit to be made.
They also list tracked files with unstaged changes, but without a diff.
Introduce '-v -v' which shows the diff between the index and the
worktree in addition to the HEAD index diff. This allows a review of unstaged
changes which might be missing from the commit.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
Documentation/git-commit.txt | 4
t/t7508-status.sh| 43 +++
wt-status.c | 10 ++
3 files changed, 57 insertions(+)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1e74b75..f14d2ec 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -284,6 +284,10 @@ configuration variable documented in linkgit:git-config[1].
would be committed at the bottom of the commit message
template. Note that this diff output doesn't have its
lines prefixed with '#'.
++
+If specified twice, show in addition the unified diff between
+what would be committed and the worktree files, i.e. the unstaged
+changes to tracked files.
-q::
--quiet::
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 4989e98..6779195 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -139,6 +139,49 @@ test_expect_success 'status -v' '
test_cmp expect output
'
+cat expect \EOF
+On branch master
+Changes to be committed:
+ (use git reset HEAD file... to unstage)
+
+ new file: dir2/added
+
+Changes not staged for commit:
+ (use git add file... to update what will be committed)
+ (use git checkout -- file... to discard changes in working directory)
+
+ modified: dir1/modified
+
+Untracked files:
+ (use git add file... to include in what will be committed)
+
+ dir1/untracked
+ dir2/modified
+ dir2/untracked
+ expect
+ output
+ untracked
+
+diff --git HEAD=base-commit/dir2/added INDEX=staged-for-commit/dir2/added
+new file mode 100644
+index 000..00750ed
+--- /dev/null
INDEX=staged-for-commit/dir2/added
+@@ -0,0 +1 @@
++3
+diff --git INDEX=staged-for-commit/dir1/modified
WORKTREE=not-staged-for-commit/dir1/modified
+index e69de29..d00491f 100644
+--- INDEX=staged-for-commit/dir1/modified
WORKTREE=not-staged-for-commit/dir1/modified
+@@ -0,0 +1 @@
++1
+EOF
+
+test_expect_success 'status -v -v' '
+ git status -v -v output
+ test_cmp expect output
+'
+
test_expect_success 'setup fake editor' '
cat .git/editor -\EOF
#! /bin/sh
diff --git a/wt-status.c b/wt-status.c
index 29666d0..b6e9837 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -873,7 +873,17 @@ static void wt_status_print_verbose(struct wt_status *s)
rev.diffopt.use_color = 0;
wt_status_add_cut_line(s-fp);
}
+ if (s-verbose 1) {
+ rev.diffopt.a_prefix = HEAD=base-commit/;
+ rev.diffopt.b_prefix = INDEX=staged-for-commit/;
+ } /* else use prefix as per user config */
run_diff_index(rev, 1);
+ if (s-verbose 1) {
+ setup_work_tree();
+ rev.diffopt.a_prefix = INDEX=staged-for-commit/;
+ rev.diffopt.b_prefix = WORKTREE=not-staged-for-commit/;
+ run_diff_files(rev, 0);
+ }
}
static void wt_status_print_tracking(struct wt_status *s)
--
2.3.1.303.g5174db1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/2] More diffs for commit/status
Trying to clean up my old RFCs, so here's a mini-series that 1) adds a test for status -v (the diff between HEAD and index) and 2) implements status -v -v (additional diff between index and worktree). The idea is that in a case where commit -v would list fils with unstaged changes one would get the diff for these changes with '-v -v' easily. 2/2 also sets the diff prefixes (a/,b/ etc.) for both diffs in the '-v -v' case to a really verbose version to avoid any confusion between the two types of diffs. We may want to do that for '-v' already, although that would be a change in behavior. The wording for the new prefixes is chosen after the status hints, although they are not localised. Michael J Gruber (2): t7508: test git status -v commit/status: show the index-worktree diff with -v -v Documentation/git-commit.txt | 4 t/t7508-status.sh| 49 wt-status.c | 10 + 3 files changed, 63 insertions(+) -- 2.3.1.303.g5174db1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG] Segfault with rev-list --bisect
Hi, I've found a case where git rev-list --bisect segfaults reproducibly (git version is 2.3.1). This is the commit topology (A2 is the first parent of M): I - A1 - A2 \\ - B1 -- M (HEAD) And this is an example of a command that segfaults: git rev-list --bisect --first-parent --parents HEAD --not HEAD~1 I tried a couple of variations quickly: It does not segfault if a non-merge commit is made on top of M (so HEAD is no longer pointing directly to M). It also does not segfault if 'HEAD~1' is changed to 'HEAD~2'. Thanks, Troy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] protocol v2
On Mon, Mar 02, 2015 at 04:21:36PM +0700, Duy Nguyen wrote: On Sun, Mar 01, 2015 at 07:47:40PM -0800, Junio C Hamano wrote: It seems, however, that our current thinking is that it is OK to do the allow new v1 clients to notice the availabilty of v2 servers, so that they can talk v2 the next time thing, so my preference is to throw this client first and let server notice into maybe doable but not our first choice bin, at least for now. OK let's see if first choice like this could work. Very draft but it should give some idea how to make a prototype to test it out. Note that the server still speaks first in this proposal. Junio pointed out in private that I didn't address the packet length limit (64k). I thought I could get away with a new capability (i.e. not worry about it now) but I finally admit that was a bad hack. So perhaps this on top. The WARN line was originally supposed to be used when packet length is still 64k and the server has a ref longer than that. It could then skip that long ref and inform the user, so the user could re-request again, this time asking for long packet length capability. That's irrelevant now. But I think an option to say something without abort may still be a good idea, especially if we allow hooks to intercept the protocol. -- 8 -- diff --git a/Documentation/technical/pack-protocol.txt b/Documentation/technical/pack-protocol.txt index 32a1186..e2003c0 100644 --- a/Documentation/technical/pack-protocol.txt +++ b/Documentation/technical/pack-protocol.txt @@ -37,6 +37,20 @@ communicates with that invoked process over the SSH connection. The file:// transport runs the 'upload-pack' or 'receive-pack' process locally and communicates with it over a pipe. +Pkt-line format +--- + +In version 1, a packet line consists of four bytes containing the +length of the entire line plus four, in hexadecimal format. A flush +consists of four zero bytes. + +In version 2, the four-byte header format remains supported but the +maximum length is 0xfffe. If the length is 0x, the actual length +follows in variable encoding in hexadecimal. + +XXX: perhaps go with 2-byte length by default instead because we don't +usually need pkt-line longer than 256?? Maybe not worth saving a couple bytes + Git Transport - @@ -68,10 +82,12 @@ process on the server side over the Git protocol is this: nc -v example.com 9418 If the server refuses the request for some reasons, it could abort -gracefully with an error message. +gracefully with an error message, or show a warning but and keep +moving. error-line = PKT-LINE(ERR SP explanation-text) + warning-line = PKT-LINE(WARN SP explanation-text) SSH Transport -- 8 -- -- To unsubscribe from this list: send the line 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 4/7] struct ref_lock: delete the force_write member
On 03/02/2015 10:44 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Instead, compute the value when it is needed.
@@ -2318,8 +2317,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
-if ((flags REF_NODEREF) (type REF_ISSYMREF))
-lock-force_write = 1;
retry:
switch (safe_create_leading_directories(ref_file)) {
@@ -3787,8 +3784,13 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
struct ref_update *update = updates[i];
if (!is_null_sha1(update-new_sha1)) {
-if (!update-lock-force_write
-!hashcmp(update-lock-old_sha1, update-new_sha1))
{
+if (!((update-type REF_ISSYMREF)
+ (update-flags REF_NODEREF))
+ !hashcmp(update-lock-old_sha1,
update-new_sha1)) {
+/*
+ * The reference already has the desired
+ * value, so we don't need to write it.
+ */
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock,
update-new_sha1,
The code before and after the change are equivalent.
It shouldn't be the case, but somehow I find the original slightly
easier to understand. [...]
I had the same feeling; thanks for confirming it. How about I introduce
a temporary variable `overwriting_symref` as an aid to the reader? I
think this makes it pretty clear:
if (!is_null_sha1(update-new_sha1)) {
- if (!update-lock-force_write
- !hashcmp(update-lock-old_sha1, update-new_sha1))
{
+ int overwriting_symref = ((update-type REF_ISSYMREF)
+ (update-flags
REF_NODEREF));
+
+ if (!overwriting_symref
+ !hashcmp(update-lock-old_sha1,
update-new_sha1)) {
+ /*
+ * The reference already has the desired
+ * value, so we don't need to write it.
+ */
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock,
update-new_sha1,
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
[PATCH v3 1/7] write_ref_sha1(): remove check for lock == NULL
None of the callers pass NULL to this function, and there doesn't seem
to be any usefulness to allowing them to do so.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
Reviewed-by: Stefan Beller sbel...@google.com
---
refs.c | 4
1 file changed, 4 deletions(-)
diff --git a/refs.c b/refs.c
index ab2f2a9..e82d503 100644
--- a/refs.c
+++ b/refs.c
@@ -3079,10 +3079,6 @@ static int write_ref_sha1(struct ref_lock *lock,
static char term = '\n';
struct object *o;
- if (!lock) {
- errno = EINVAL;
- return -1;
- }
if (!lock-force_write !hashcmp(lock-old_sha1, sha1)) {
unlock_ref(lock);
return 0;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] Fix some problems with reflog expiration
This is v3 of the patch series. Thanks to Junio for his comments about v2 [1]; I think this version addresses all of his points. Changes since v2: * Introduce a temporary in struct ref_lock: delete the force_write member to make a complicated boolean expression easier to understand. * Split the documentation of options for reflog expire and reflog delete, and make another couple tweaks to the reflog documentation. * Add a NEEDSWORK comment suggesting that the reflog command should use parse_options() to process its command line. [1] http://thread.gmane.org/gmane.comp.version-control.git/264586 Michael Haggerty (6): write_ref_sha1(): remove check for lock == NULL write_ref_sha1(): Move write elision test to callers lock_ref_sha1_basic(): do not set force_write for missing references reflog: improve and update documentation reflog_expire(): ignore --updateref for symbolic references reflog_expire(): never update a reference to null_sha1 Stefan Beller (1): struct ref_lock: delete the force_write member Documentation/git-reflog.txt | 144 ++- builtin/reflog.c | 9 +-- refs.c | 65 ++- 3 files changed, 126 insertions(+), 92 deletions(-) -- 2.1.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 v2 5/7] reflog: improve and update documentation
On 03/02/2015 11:04 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
+Reference logs, or reflogs, record when the tips of branches and
+other references were updated in the local repository. Reflogs are
+useful in various Git commands, to specify the old value of a
+reference. For example, `HEAD@{2}` means where HEAD used to be two
+moves ago, `master@{one.week.ago}` means where master used to point
+to one week ago, and so on. See linkgit:gitrevisions[7] for more
+details.
Looks very good, especially the part that mentions in the local
repository. It seems to be a common novice misunderstanding what
`master@{one.week.ago}` means, and it might be beneficial to be more
verbose by saying where master used to point to one week ago in
this local repository.
Yes, that's good. I will change it.
+The expire subcommand prunes older reflog entries. Entries older
+than `expire` time, or entries older than `expire-unreachable` time
+and not reachable from the current tip, are removed from the reflog.
+This is typically not used directly by end users -- instead, see
+linkgit:git-gc[1].
+
+The delete subcommand deletes single entries from the reflog. Its
+argument must be an _exact_ entry (e.g. `git reflog delete
+master@{2}`).
Just like expire, delete should be accompanied by the same
typically not. I do not think it is even worth mentioning that it
exists merely as an implementation detail for likgit:git-stash[1]
and for no other reason.
OK, will change.
+Options for `expire` and/or `delete`
+
I think this started from a hope that these two share many, but
looking at the result I notice the shared ones are a tiny and
trivial minority. It probably makes sense to retitle this section
Options for expire (and remove For the expire command only), and
add an Options for delete section immediately after it that looks
like:
Options for `delete`
--updateref::
--rewrite::
--dry-run::
The `delete` command takes these options whose
meanings are the same as those for `expire`.
Either way is a little bit awkward, because these two subcommands share
4 out of 8 of their options. But since delete is really quite useless
to end users, I stuck its options in a separate section as you
suggested, but inline in a paragraph, where they won't bother anybody.
diff --git a/builtin/reflog.c b/builtin/reflog.c
index 49c64f9..dd68a72 100644
--- a/builtin/reflog.c
+++ b/builtin/reflog.c
@@ -13,9 +13,9 @@
*/
static const char reflog_expire_usage[] =
-git reflog expire [--verbose] [--dry-run] [--stale-fix] [--expire=time]
[--expire-unreachable=time] [--all] refs...;
+git reflog expire [--expire=time] [--expire-unreachable=time]
[--rewrite] [--updateref] [--stale-fix] [--dry-run | -n] [--verbose] [--all]
refs...;
static const char reflog_delete_usage[] =
-git reflog delete [--verbose] [--dry-run] [--rewrite] [--updateref]
refs...;
+git reflog delete [--rewrite] [--updateref] [--dry-run | -n] [--verbose]
refs...;
static unsigned long default_reflog_expire;
static unsigned long default_reflog_expire_unreachable;
Thanks for being complete, but I sense that it may be time we
switched to parse-options here, which gives us the help string for
free. Perhaps throw in a comment line before this hunk
/* NEEDSWORK: switch to parse-options */
or something to leave hint for other people?
OK.
Thanks for your review! A reroll will be coming soon.
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
[PATCH v3 6/7] reflog_expire(): ignore --updateref for symbolic references
If we are expiring reflog entries for a symbolic reference, then how
should --updateref be handled if the newest reflog entry is expired?
Option 1: Update the referred-to reference. (This is what the current
code does.) This doesn't make sense, because the referred-to reference
has its own reflog, which hasn't been rewritten.
Option 2: Update the symbolic reference itself (as in, REF_NODEREF).
This would convert the symbolic reference into a non-symbolic
reference (e.g., detaching HEAD), which is surely not what a user
would expect.
Option 3: Error out. This is plausible, but it would make the
following usage impossible:
git reflog expire ... --updateref --all
Option 4: Ignore --updateref for symbolic references.
We choose to implement option 4.
Note: another problem in this code will be fixed in a moment.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-reflog.txt | 3 ++-
refs.c | 15 ---
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 730106c..5e7908e 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -88,7 +88,8 @@ Options for `expire`
--updateref::
Update the reference to the value of the top reflog entry (i.e.
- ref@\{0\}) if the previous top entry was pruned.
+ ref@\{0\}) if the previous top entry was pruned. (This
+ option is ignored for symbolic references.)
--rewrite::
If a reflog entry's predecessor is pruned, adjust its old
diff --git a/refs.c b/refs.c
index 7a2f53f..48bb9e8 100644
--- a/refs.c
+++ b/refs.c
@@ -4028,6 +4028,7 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
struct ref_lock *lock;
char *log_file;
int status = 0;
+ int type;
memset(cb, 0, sizeof(cb));
cb.flags = flags;
@@ -4039,7 +4040,7 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
* reference itself, plus we might need to update the
* reference if --updateref was specified:
*/
- lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, NULL);
+ lock = lock_ref_sha1_basic(refname, sha1, NULL, 0, type);
if (!lock)
return error(cannot lock ref '%s', refname);
if (!reflog_exists(refname)) {
@@ -4076,10 +4077,18 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
(*cleanup_fn)(cb.policy_cb);
if (!(flags EXPIRE_REFLOGS_DRY_RUN)) {
+ /*
+* It doesn't make sense to adjust a reference pointed
+* to by a symbolic ref based on expiring entries in
+* the symbolic reference's reflog.
+*/
+ int update = (flags EXPIRE_REFLOGS_UPDATE_REF)
+ !(type REF_ISSYMREF);
+
if (close_lock_file(reflog_lock)) {
status |= error(couldn't write %s: %s, log_file,
strerror(errno));
- } else if ((flags EXPIRE_REFLOGS_UPDATE_REF)
+ } else if (update
(write_in_full(lock-lock_fd,
sha1_to_hex(cb.last_kept_sha1), 40) != 40 ||
write_str_in_full(lock-lock_fd, \n) != 1 ||
@@ -4090,7 +4099,7 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
} else if (commit_lock_file(reflog_lock)) {
status |= error(unable to commit reflog '%s' (%s),
log_file, strerror(errno));
- } else if ((flags EXPIRE_REFLOGS_UPDATE_REF)
commit_ref(lock)) {
+ } else if (update commit_ref(lock)) {
status |= error(couldn't set %s, lock-ref_name);
}
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] reflog: improve and update documentation
Revamp the git reflog usage documentation in the manpage and the
command help to match the current reality and improve its clarity:
* Add documentation for some options that had been left out.
* Group the subcommands and options more logically and move more
common subcommands/options higher.
* Improve some explanations.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Documentation/git-reflog.txt | 143 +--
builtin/reflog.c | 9 +--
2 files changed, 88 insertions(+), 64 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 70791b9..730106c 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -17,85 +17,112 @@ The command takes various subcommands, and different
options
depending on the subcommand:
[verse]
-'git reflog expire' [--dry-run] [--stale-fix] [--verbose]
- [--expire=time] [--expire-unreachable=time] [--all] refs...
-'git reflog delete' ref@\{specifier\}...
'git reflog' ['show'] [log-options] [ref]
+'git reflog expire' [--expire=time] [--expire-unreachable=time]
+ [--rewrite] [--updateref] [--stale-fix]
+ [--dry-run] [--verbose] [--all | refs...]
+'git reflog delete' [--rewrite] [--updateref]
+ [--dry-run] [--verbose] ref@\{specifier\}...
+
+Reference logs, or reflogs, record when the tips of branches and
+other references were updated in the local repository. Reflogs are
+useful in various Git commands, to specify the old value of a
+reference. For example, `HEAD@{2}` means where HEAD used to be two
+moves ago, `master@{one.week.ago}` means where master used to point
+to one week ago in this local repository, and so on. See
+linkgit:gitrevisions[7] for more details.
+
+This command manages the information recorded in the reflogs.
+
+The show subcommand (which is also the default, in the absence of
+any subcommands) shows the log of the reference provided in the
+command-line (or `HEAD`, by default). The reflog covers all recent
+actions, and in addition the `HEAD` reflog records branch switching.
+`git reflog show` is an alias for `git log -g --abbrev-commit
+--pretty=oneline`; see linkgit:git-log[1] for more information.
+
+The expire subcommand prunes older reflog entries. Entries older
+than `expire` time, or entries older than `expire-unreachable` time
+and not reachable from the current tip, are removed from the reflog.
+This is typically not used directly by end users -- instead, see
+linkgit:git-gc[1].
+
+The delete subcommand deletes single entries from the reflog. Its
+argument must be an _exact_ entry (e.g. `git reflog delete
+master@{2}`). This subcommand is also typically not used directly by
+end users.
-Reflog is a mechanism to record when the tip of branches are
-updated. This command is to manage the information recorded in it.
-The subcommand expire is used to prune older reflog entries.
-Entries older than `expire` time, or entries older than
-`expire-unreachable` time and not reachable from the current
-tip, are removed from the reflog. This is typically not used
-directly by the end users -- instead, see linkgit:git-gc[1].
-
-The subcommand show (which is also the default, in the absence of any
-subcommands) will take all the normal log options, and show the log of
-the reference provided in the command-line (or `HEAD`, by default).
-The reflog will cover all recent actions (HEAD reflog records branch switching
-as well). It is an alias for `git log -g --abbrev-commit --pretty=oneline`;
-see linkgit:git-log[1].
+OPTIONS
+---
-The reflog is useful in various Git commands, to specify the old value
-of a reference. For example, `HEAD@{2}` means where HEAD used to be
-two moves ago, `master@{one.week.ago}` means where master used to
-point to one week ago, and so on. See linkgit:gitrevisions[7] for
-more details.
+Options for `show`
+~~
-To delete single entries from the reflog, use the subcommand delete
-and specify the _exact_ entry (e.g. `git reflog delete master@{2}`).
+`git reflog show` accepts any of the options accepted by `git log`.
-OPTIONS
+Options for `expire`
+
---stale-fix::
- This revamps the logic -- the definition of broken commit
- becomes: a commit that is not reachable from any of the refs and
- there is a missing object among the commit, tree, or blob
- objects reachable from it that is not reachable from any of the
- refs.
-+
-This computation involves traversing all the reachable objects, i.e. it
-has the same cost as 'git prune'. Fortunately, once this is run, we
-should not have to ever worry about missing objects, because the current
-prune and pack-objects know about reflogs and protect objects referred by
-them.
+--all::
+ Process the reflogs of all references.
--expire=time::
- Entries older than this time are pruned. Without the
- option it is taken from configuration
[PATCH v3 7/7] reflog_expire(): never update a reference to null_sha1
Currently, if --updateref is specified and the very last reflog entry
is expired or deleted, the reference's value is set to 0{40}. This is
an invalid state of the repository, and breaks, for example, git
fsck and git for-each-ref.
The only place we use --updateref in our own code is when dropping
stash entries. In that code, the very next step is to check if the
reflog has been made empty, and if so, delete the refs/stash
reference entirely. Thus that code path ultimately leaves the
repository in a valid state.
But we don't want to the repository in an invalid state even
temporarily, and we don't want to leave an invalid state if other
callers of git reflog expire|delete --updateref don't think to do
the extra cleanup step.
So, if git reflog expire|delete leaves no more entries in the
reflog, just leave the reference unchanged.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 48bb9e8..d6244b6 100644
--- a/refs.c
+++ b/refs.c
@@ -4080,10 +4080,13 @@ int reflog_expire(const char *refname, const unsigned
char *sha1,
/*
* It doesn't make sense to adjust a reference pointed
* to by a symbolic ref based on expiring entries in
-* the symbolic reference's reflog.
+* the symbolic reference's reflog. Nor can we update
+* a reference if there are no remaining reflog
+* entries.
*/
int update = (flags EXPIRE_REFLOGS_UPDATE_REF)
- !(type REF_ISSYMREF);
+ !(type REF_ISSYMREF)
+ !is_null_sha1(cb.last_kept_sha1);
if (close_lock_file(reflog_lock)) {
status |= error(couldn't write %s: %s, log_file,
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/7] write_ref_sha1(): Move write elision test to callers
write_ref_sha1() previously skipped the write if the reference already
had the desired value, unless lock-force_write was set. Instead,
perform that test at the callers.
Two of the callers (in rename_ref()) unconditionally set force_write
just before calling write_ref_sha1(), so they don't need the extra
check at all. Nor do they need to set force_write anymore.
The last caller, in ref_transaction_commit(), still needs the test.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index e82d503..dd30bfa 100644
--- a/refs.c
+++ b/refs.c
@@ -2877,7 +2877,6 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
error(unable to lock %s for update, newrefname);
goto rollback;
}
- lock-force_write = 1;
hashcpy(lock-old_sha1, orig_sha1);
if (write_ref_sha1(lock, orig_sha1, logmsg)) {
error(unable to write current sha1 into %s, newrefname);
@@ -2893,7 +2892,6 @@ int rename_ref(const char *oldrefname, const char
*newrefname, const char *logms
goto rollbacklog;
}
- lock-force_write = 1;
flag = log_all_ref_updates;
log_all_ref_updates = 0;
if (write_ref_sha1(lock, orig_sha1, NULL))
@@ -3079,10 +3077,6 @@ static int write_ref_sha1(struct ref_lock *lock,
static char term = '\n';
struct object *o;
- if (!lock-force_write !hashcmp(lock-old_sha1, sha1)) {
- unlock_ref(lock);
- return 0;
- }
o = parse_object(sha1);
if (!o) {
error(Trying to write ref %s with nonexistent object %s,
@@ -3796,15 +3790,21 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
struct ref_update *update = updates[i];
if (!is_null_sha1(update-new_sha1)) {
- if (write_ref_sha1(update-lock, update-new_sha1,
- update-msg)) {
+ if (!update-lock-force_write
+ !hashcmp(update-lock-old_sha1, update-new_sha1))
{
+ unlock_ref(update-lock);
+ update-lock = NULL;
+ } else if (write_ref_sha1(update-lock,
update-new_sha1,
+ update-msg)) {
update-lock = NULL; /* freed by write_ref_sha1
*/
strbuf_addf(err, Cannot update the ref '%s'.,
update-refname);
ret = TRANSACTION_GENERIC_ERROR;
goto cleanup;
+ } else {
+ /* freed by write_ref_sha1(): */
+ update-lock = NULL;
}
- update-lock = NULL; /* freed by write_ref_sha1 */
}
}
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] lock_ref_sha1_basic(): do not set force_write for missing references
If a reference is missing, its SHA-1 will be null_sha1, which can't
possibly match a new value that ref_transaction_commit() is trying to
update it to. So there is no need to set force_write in this scenario.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index dd30bfa..3ed9ea6 100644
--- a/refs.c
+++ b/refs.c
@@ -2258,7 +2258,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
int type, lflags;
int mustexist = (old_sha1 !is_null_sha1(old_sha1));
int resolve_flags = 0;
- int missing = 0;
int attempts_remaining = 3;
lock = xcalloc(1, sizeof(struct ref_lock));
@@ -2297,13 +2296,13 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
orig_refname, strerror(errno));
goto error_return;
}
- missing = is_null_sha1(lock-old_sha1);
- /* When the ref did not exist and we are creating it,
-* make sure there is no existing ref that is packed
-* whose name begins with our refname, nor a ref whose
-* name is a proper prefix of our refname.
+ /*
+* If the ref did not exist and we are creating it, make sure
+* there is no existing packed ref whose name begins with our
+* refname, nor a packed ref whose name is a proper prefix of
+* our refname.
*/
- if (missing
+ if (is_null_sha1(lock-old_sha1)
!is_refname_available(refname, skip, get_packed_refs(ref_cache)))
{
last_errno = ENOTDIR;
goto error_return;
@@ -2319,8 +2318,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
- if (missing)
- lock-force_write = 1;
if ((flags REF_NODEREF) (type REF_ISSYMREF))
lock-force_write = 1;
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] struct ref_lock: delete the force_write member
From: Stefan Beller sbel...@google.com
Instead, compute the value when it is needed.
Signed-off-by: Stefan Beller sbel...@google.com
Edited-by: Michael Haggerty mhag...@alum.mit.edu
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index 3ed9ea6..7a2f53f 100644
--- a/refs.c
+++ b/refs.c
@@ -12,7 +12,6 @@ struct ref_lock {
struct lock_file *lk;
unsigned char old_sha1[20];
int lock_fd;
- int force_write;
};
/*
@@ -2318,8 +2317,6 @@ static struct ref_lock *lock_ref_sha1_basic(const char
*refname,
lock-ref_name = xstrdup(refname);
lock-orig_ref_name = xstrdup(orig_refname);
ref_file = git_path(%s, refname);
- if ((flags REF_NODEREF) (type REF_ISSYMREF))
- lock-force_write = 1;
retry:
switch (safe_create_leading_directories(ref_file)) {
@@ -3787,8 +3784,15 @@ int ref_transaction_commit(struct ref_transaction
*transaction,
struct ref_update *update = updates[i];
if (!is_null_sha1(update-new_sha1)) {
- if (!update-lock-force_write
- !hashcmp(update-lock-old_sha1, update-new_sha1))
{
+ int overwriting_symref = ((update-type REF_ISSYMREF)
+ (update-flags
REF_NODEREF));
+
+ if (!overwriting_symref
+!hashcmp(update-lock-old_sha1,
update-new_sha1)) {
+ /*
+* The reference already has the desired
+* value, so we don't need to write it.
+*/
unlock_ref(update-lock);
update-lock = NULL;
} else if (write_ref_sha1(update-lock,
update-new_sha1,
--
2.1.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: Interested in helping open source friends on HP-UX?
H.Merijn Brand venit, vidit, dixit 19.02.2015 19:56: On Thu, 19 Feb 2015 14:21:11 +0100, Michael J Gruber g...@drmicha.warpmail.net wrote: Jeff, you got it wrong. You should do the hard part and leave the easy part to us! Thanks anyways, I'll add this to my HP_UX branch. I did not mention this in earlier mails. When using the HP C-ANSI-C compiler, MAX_INT is not set. I had to add --8--- #ifndef SIZE_MAX # define SIZE_MAX (18446744073709551615UL) /* define SIZE_MAX (4294967295U) */ # endif --8--- to these files sha1_file.c utf8.c walker.c wrapper.c And yes, that could be dynamic and probably be in another header file In compat/regex/regex_internal.h we have /* For loser systems without the definition. */ #ifndef SIZE_MAX # define SIZE_MAX ((size_t) -1) #endif Does this work in your environment? [Trying to not let this fall into oblivion...] 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
