Bug in fetch-pack.c, please confirm
Hi guys,
So I was looking at fetch-pack.c (from master @ 52cae643, but I think
it's the same everywhere):
# Lines 626-648
for (retval = 1, ref = *refs; ref ; ref = ref-next) {
const unsigned char *remote = ref-old_sha1;
unsigned char local[20];
struct object *o;
o = lookup_object(remote);
if (!o || !(o-flags COMPLETE)) {
retval = 0;
if (!args-verbose)
continue;
fprintf(stderr,
want %s (%s)\n, sha1_to_hex(remote),
ref-name);
continue;
}
hashcpy(ref-new_sha1, local);
if (!args-verbose)
continue;
fprintf(stderr,
already have %s (%s)\n, sha1_to_hex(remote),
ref-name);
}
Peff, weren't you having some issue with want and have and hide refs?
Tell me please how the local variable above gets initialized?
It's declared on the stack inside the for loop scope so only
guaranteed to have garbage.
It's passed to hashcpy which has this prototype:
inline void hashcpy(unsigned char *sha_dst, const unsigned char *sha_src);
So it looks to me like garbage is copied into rev-new_sha1, yes?
Something's very wrong here.
It looks to me like the bug was introduced in 49bb805e (Do not ask for
objects known to be complete. 2005-10-19).
I've taken a stab a a fix below.
-Kyle
-- 8 --
Subject: [PATCH] fetch-pack.c: do not use uninitialized sha1 value
Since 49bb805e (Do not ask for objects known to be complete. 2005-10-19)
when the read_ref call was replaced with a parse_object call, the
automatic variable 'local' containing an sha1 has been left uninitialized.
Subsequently in 1baaae5e (Make maximal use of the remote refs, 2005-10-28)
the parse_object call was replaced with a lookup_object call but still
the 'local' variable was left uninitialized.
However, it's used as the source to update another sha1 value in the case
that we already have it and in that case the other ref will end up with
whatever garbage was in the 'local' variable.
Fix this by removing the 'local' variable and using the value from the
result of the lookup_object call instead.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
fetch-pack.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 655ee642..c0b4d84f 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -621,29 +621,28 @@ static int everything_local(struct fetch_pack_args *args,
}
}
filter_refs(args, refs, sought, nr_sought);
for (retval = 1, ref = *refs; ref ; ref = ref-next) {
const unsigned char *remote = ref-old_sha1;
- unsigned char local[20];
struct object *o;
o = lookup_object(remote);
if (!o || !(o-flags COMPLETE)) {
retval = 0;
if (!args-verbose)
continue;
fprintf(stderr,
want %s (%s)\n, sha1_to_hex(remote),
ref-name);
continue;
}
- hashcpy(ref-new_sha1, local);
+ hashcpy(ref-new_sha1, o-sha1);
if (!args-verbose)
continue;
fprintf(stderr,
already have %s (%s)\n, sha1_to_hex(remote),
ref-name);
}
return retval;
---
--
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: fatal: Unable to mark file .ruby-version
Hi, On 03/15, Arup Rakshit wrote: Hi, I am trying to ignore 2 files, but getting error - [arup@sztukajedzenia (SJ002)]$ git status # On branch SJ002 # Untracked files: # (use git add file... to include in what will be committed) # # .ruby-gemset # .ruby-version nothing added to commit but untracked files present (use git add to track) [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-gemset fatal: Unable to mark file .ruby-gemset [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-version fatal: Unable to mark file .ruby-version [arup@sztukajedzenia (SJ002)]$ With --assume-unchanged you're promising git that you will not change a file that is already in the repository. Git doesn't check those files for changes anymore, which can improve performance. Why it is throwing error ? And how to achieve this without taking the help of the file `.gitignore` ? You can create a file .git/info/exclude in the root directory of the repository with the same syntax as .gitignore to ignore these files. This rules will not be commited in the repository. -- Regards, Arup Rakshit Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian Kernighan -- 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: fatal: Unable to mark file .ruby-version
On Sunday, March 15, 2015 01:30:04 PM you wrote: Hi, On 03/15, Arup Rakshit wrote: Hi, I am trying to ignore 2 files, but getting error - [arup@sztukajedzenia (SJ002)]$ git status # On branch SJ002 # Untracked files: # (use git add file... to include in what will be committed) # # .ruby-gemset # .ruby-version nothing added to commit but untracked files present (use git add to track) [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-gemset fatal: Unable to mark file .ruby-gemset [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-version fatal: Unable to mark file .ruby-version [arup@sztukajedzenia (SJ002)]$ With --assume-unchanged you're promising git that you will not change a file that is already in the repository. Git doesn't check those files for changes anymore, which can improve performance. I didn't understand your point. Could you please elaborate more on it ? Why it is throwing error ? And how to achieve this without taking the help of the file `.gitignore` ? You can create a file .git/info/exclude in the root directory of the repository with the same syntax as .gitignore to ignore these files. This rules will not be commited in the repository. -- 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 -- Regards, Arup Rakshit Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian Kernighan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC 1/3] add: add new --exclude option to git add
This patch introduces new --exclude option for the git add
command.
We already have core.excludesfile configuration variable which indicates
a path to file which contains patterns to exclude. This patch provides
ability to pass --exclude option to the git add command to exclude paths
from command line in addition to which found in the ignore files.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/add.c | 20
1 file changed, 20 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..5c602a6 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -244,6 +244,16 @@ static int ignore_removal_cb(const struct option *opt,
const char *arg, int unse
return 0;
}
+struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+struct exclude_list *el;
+
+static int exclude_cb(const struct option *opt, const char *arg, int unset)
+{
+ struct string_list *exclude_list = opt-value;
+ string_list_append(exclude_list, arg);
+ return 0;
+}
+
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -255,6 +265,9 @@ static struct option builtin_add_options[] = {
OPT_BOOL('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOL('N', intent-to-add, intent_to_add, N_(record only the fact
that the path will be added later)),
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+ { OPTION_CALLBACK, 0, exclude, exclude_list, N_(pattern),
+ N_(do no add files matching pattern to index),
+ 0, exclude_cb },
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as --no-all)),
@@ -298,6 +311,7 @@ static int add_files(struct dir_struct *dir, int flags)
int cmd_add(int argc, const char **argv, const char *prefix)
{
+ int i;
int exit_status = 0;
struct pathspec pathspec;
struct dir_struct dir;
@@ -381,6 +395,11 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
if (!ignored_too) {
dir.flags |= DIR_COLLECT_IGNORED;
setup_standard_excludes(dir);
+
+ el = add_exclude_list(dir, EXC_CMDL, --exclude
option);
+ for (i = 0; i exclude_list.nr; i++)
+ add_exclude(exclude_list.items[i].string, ,
0, el, -(i+1));
+
}
memset(empty_pathspec, 0, sizeof(empty_pathspec));
@@ -446,5 +465,6 @@ finish:
die(_(Unable to write new index file));
}
+ string_list_clear(exclude_list, 0);
return exit_status;
}
--
2.3.3.472.g20ceeac
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] t3700-add: added test for --exclude option
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- t/t3700-add.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index f7ff1f5..c52a5d0 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -81,6 +81,13 @@ test_expect_success '.gitignore is honored' ' ! (git ls-files | grep \\.ig) ' +test_expect_success 'Test that git add --exclude works' ' + touch foo + touch bar + git add --exclude=bar . + ! (git ls-files | grep bar) +' + test_expect_success 'error out when attempting to add ignored ones without -f' ' test_must_fail git add a.?? ! (git ls-files | grep \\.ig) -- 2.3.3.472.g20ceeac -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Documentation/git-add.txt: describe --exclude option
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-add.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index f2eb907..4bc156a 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] + [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--exclude=pattern] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--] [pathspec...] @@ -164,6 +164,10 @@ for git add --no-all pathspec..., i.e. ignored removed files. be ignored, no matter if they are already present in the work tree or not. +--exclude=pattern:: + Do not add files to the index in addition which are found in + the .gitignore. + \--:: This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken -- 2.3.3.472.g20ceeac -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
Changes 'git diff --no-index $directory $file' behaviour.
Now it is transformed to 'git diff --no-index $directory/file $file'
instead of throwing an error.
Signed-off-by: Yurii Shevtsov ungetch at gmail.com
---
diff-no-index.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..4e71b36 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o,
if (get_mode(name1, mode1) || get_mode(name2, mode2))
return -1;
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1, name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct strbuf dirnfile;
+ const char *dir, *file;
+ char *filename;
+ int ret = 0;
+
+ dir = S_ISDIR(mode1) ? name1 : name2;
+ file = (dir == name1) ? name2 : name1;
+ strbuf_init(dirnfile, strlen(name1) + strlen(name2) + 2);
+ strbuf_addstr(dirnfile, dir);
+ if (dirnfile.buf[dirnfile.len - 1] != '/')
+ strbuf_addch(dirnfile, '/');
+ filename = strrchr(file, '/');
+ strbuf_addstr(dirnfile, filename ? (filename + 1) : file);
+ ret = queue_diff(o, dirnfile.buf, file);
+ strbuf_release(dirnfile);
+
+ return ret;
+ }
if (S_ISDIR(mode1) || S_ISDIR(mode2)) {
struct strbuf buffer1 = STRBUF_INIT;
--
I hope I understood task correct. I think this patch requires writing
additional tests, so that's what I'm going to do now.
--
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
fatal: Unable to mark file .ruby-version
Hi, I am trying to ignore 2 files, but getting error - [arup@sztukajedzenia (SJ002)]$ git status # On branch SJ002 # Untracked files: # (use git add file... to include in what will be committed) # # .ruby-gemset # .ruby-version nothing added to commit but untracked files present (use git add to track) [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-gemset fatal: Unable to mark file .ruby-gemset [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-version fatal: Unable to mark file .ruby-version [arup@sztukajedzenia (SJ002)]$ Why it is throwing error ? And how to achieve this without taking the help of the file `.gitignore` ? -- Regards, Arup Rakshit Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian Kernighan -- 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 in fetch-pack.c, please confirm
Junio C Hamano gits...@pobox.com writes: Kyle J. McKay mack...@gmail.com writes: Hi guys, So I was looking at fetch-pack.c (from master @ 52cae643, but I think it's the same everywhere): ... -hashcpy(ref-new_sha1, local); +hashcpy(ref-new_sha1, o-sha1); if (!args-verbose) continue; fprintf(stderr, already have %s (%s)\n, sha1_to_hex(remote), ref-name); } return retval; --- One thing I wonder is if this hashcpy() is doing anything useful, though. Is ref-new_sha1 used after we are done in this codepath, or is the reason nobody noticed it is because it does not matter whatever garbage is in that field nobody looks at it? -- 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] diff-files: mark i-t-a paths as new
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/add.c | 1 +
diff-lib.c| 5 +
2 files changed, 6 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..ee370b0 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -63,6 +63,7 @@ static void update_callback(struct diff_queue_struct *q,
switch (fix_unmerged_status(p, data)) {
default:
die(_(unexpected diff status %c), p-status);
+ case DIFF_STATUS_ADDED:
case DIFF_STATUS_MODIFIED:
case DIFF_STATUS_TYPE_CHANGED:
if (add_file_to_index(the_index, path, data-flags)) {
Is this related to making diff-files show an i-t-a as new, or
something else?
Ahh, added would have never appeared in diff-files output (because
by definition comparing index and working tree for only paths known
to the index would never produce add), and the point of this series
is to use that status to signal that the path is marked as i-t-a.
And an i-t-a path is not yet exist in the index, known to the
system, and exists in the working tree, so catching that new case
here and calling add_file_to_index() would cause such a path to be
truly added to the index (this is add -u codepath, right?).
Makes sense.
diff --git a/diff-lib.c b/diff-lib.c
index db0e6f8..5f1afa4 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -212,6 +212,11 @@ int run_diff_files(struct rev_info *revs, unsigned int
option)
ce-sha1,
!is_null_sha1(ce-sha1),
ce-name, 0);
continue;
+ } else if (ce-ce_flags CE_INTENT_TO_ADD) {
+ diff_addremove(revs-diffopt, '+', ce-ce_mode,
+EMPTY_BLOB_SHA1_BIN, 0,
+ce-name, 0);
+ continue;
}
changed = match_stat_with_submodule(revs-diffopt, ce,
st,
And this makes sense, of course.
The way add -N entries appear in git status has been disturbing
for quite a while to me, too. Thanks for starting to look into it.
--
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: Promoting Git developers
On Thu, Mar 12, 2015 at 11:58 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: Seeing my name in shortlog was nice, but not that exciting. I submitted a patch, it was taken, and of course it ends up in any automated lists of authors. What was much more rewarding was being mentioned specifically in A note from the maintainer as a helpful person. That had much more value because: 1. It was one of a handful of names. 2. It was picked by a human. So in that sense, it is quite the opposite of including shortlog output in the release announcements (I still think the shortlog thing we have been discussing is a good thing, but not at the same level). Yes, and that cuts both ways, unfortunately. There always will be I am doing more reviews than X and my reviews are higher quality. Why was X singled out and got thanked but not me?, X is really doing a good job reviewing in this cycle, but could other people who send reviews of lessor quality (to my mind) feel that it is unjustified if I thanked X and nobody else?, etc. A mechanically generated list avoids these issues, but the satisfaction you get from being on the list is not very high, exactly because it is not hand picked. I think it is still much better to have some people positively hand picked than nothing. People who have not been hand picked despite having done something they think is of the same or higher quality can always ask privately about the reason they haven't been hand picked or they can try again expecting that the outcome will be different next time. Anyway if some people are positively hand picked you can always hope that it will happen to you, while otherwise there is no hope at all. I do not know that it is worth having a Best of 2015 Git awards ceremony, but it is sometimes nice to thank people personally when you appreciate their efforts. I sometimes mail people off-list to do so. Yeah, I do the same, but revealing that we do so would defeat what we tried to achieve by doing so off-list in the first place. Now those who haven't got such a piece of e-mail for a while can start to suspect that they have fallen out of favour or something ;-(. I don't think it defeat anything. I think you could even do it more online. Best, Christian. -- 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 in fetch-pack.c, please confirm
Kyle J. McKay mack...@gmail.com writes:
Hi guys,
So I was looking at fetch-pack.c (from master @ 52cae643, but I think
it's the same everywhere):
# Lines 626-648
49bb805e (Do not ask for objects known to be complete., 2005-10-19)
seems to lose the assignment to local[].
Something's very wrong here.
It looks to me like the bug was introduced in 49bb805e (Do not ask for
objects known to be complete. 2005-10-19).
I read that lines 626-648, stopped reading your message and did a
blame session myself, and arrived at the same culprit.
The very original code that read from the ref directly here; I do
not think it was an attempt to catch a race condition where
ref-old_sha1 got stale and the ref on the filesystem has a newer
value. Hence, I think copying from o-sha1 like you did is a fix
that is the most faithful to the original code.
o is lookup_object(remote) which is lookup_object(ref-old_sha1);
that makes o-sha1 always be ref-old_sha1, so either would be fine,
but o-sha1 would be more appropriate in this codeflow. We grab o,
if it is NULL or if we do not like it, we do something and continue,
otherwise we like that o so grabbing o-sha1 out of it makes the
logic look flowing right, at least to me ;-)
-- 8 --
Subject: [PATCH] fetch-pack.c: do not use uninitialized sha1 value
Since 49bb805e (Do not ask for objects known to be complete. 2005-10-19)
when the read_ref call was replaced with a parse_object call, the
automatic variable 'local' containing an sha1 has been left uninitialized.
Subsequently in 1baaae5e (Make maximal use of the remote refs, 2005-10-28)
the parse_object call was replaced with a lookup_object call but still
the 'local' variable was left uninitialized.
However, it's used as the source to update another sha1 value in the case
that we already have it and in that case the other ref will end up with
whatever garbage was in the 'local' variable.
Fix this by removing the 'local' variable and using the value from the
result of the lookup_object call instead.
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
fetch-pack.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 655ee642..c0b4d84f 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -621,29 +621,28 @@ static int everything_local(struct fetch_pack_args
*args,
}
}
filter_refs(args, refs, sought, nr_sought);
for (retval = 1, ref = *refs; ref ; ref = ref-next) {
const unsigned char *remote = ref-old_sha1;
- unsigned char local[20];
struct object *o;
o = lookup_object(remote);
if (!o || !(o-flags COMPLETE)) {
retval = 0;
if (!args-verbose)
continue;
fprintf(stderr,
want %s (%s)\n, sha1_to_hex(remote),
ref-name);
continue;
}
- hashcpy(ref-new_sha1, local);
+ hashcpy(ref-new_sha1, o-sha1);
if (!args-verbose)
continue;
fprintf(stderr,
already have %s (%s)\n, sha1_to_hex(remote),
ref-name);
}
return retval;
---
--
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: Promoting Git developers
On Wed, Mar 11, 2015 at 9:42 PM, Junio C Hamano gits...@pobox.com wrote: Christian Couder christian.cou...@gmail.com writes: On Tue, Mar 10, 2015 at 6:23 PM, Junio C Hamano gits...@pobox.com wrote: I would suspect that those who agree with you would appreciate if you or somebody volunteered to act as our CKDO (chief kudos distribution officer). I do not think I have enough time to do that well. One good place to start might be to scan the list and summarize something like the following on weekly or monthly basis, as these are not something you can get by pointing people to git shortlog output. - Those who gave helpful review comments, how about going this way illustration patches, etc. Bonus points to those who helped onboarding newcomers. - Those who asked pertinent questions on common pain points, and those who answered them helpfully. Ok, I can start something about this two points every week or every few week. It would be best if I could get help from at least one person as I think it is a lot of work. No kidding; even though it may no longer be an impossibly large task as in the infrationary epoch reported in the Git Traffic, this forum is still a high traffic place. I wrote something about a potential Git Rev News news letter: https://github.com/git/git.github.io/pull/15 Peff, could you give me write access so that I don't need to send pull requests? If some people are interested to contribute even if it is only sporadically, I would suggest they ask for write access too. I also appreciate very much that you are willing to improve the release notes by adding a summary with people's names. Just in case you misunderstood, I do not think it is a good idea to add names to release notes and I will not do so. I was and am planning add the list of contributors at the end of the e-mail when the release notes is sent out, i.e. in the Announce message that is sent to the list (and CC'ed to lwn.net). Ok, that is already very nice. Thanks, Christian. -- 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] git prompt: Use toplevel to find untracked files.
Hi, Quoting Junio C Hamano gits...@pobox.com: Cody A Taylor cody.tay...@maternityneighborhood.com writes: The __git_ps1() prompt function would not show an untracked state when the current working directory was not a parent of the untracked file. Good find, and nicely explained. Somehow I had a hard time making sense out of when the current working directory was not a parent of the untracked file. Perhaps when the untracked files are outside of the current working directory would be easier to grok? I wonder if we can add a test or two to t9903-bash-prompt.sh? This test fails without the patch in question and succeeds with it. -- 8 -- diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index 51ecd3e..3d1a95f 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -397,6 +397,16 @@ test_expect_success 'prompt - untracked files status indicator - untracked files test_cmp expected $actual ' +test_expect_success 'prompt - untracked files status indicator - untracked files outside cwd' ' + printf (master %%) expected + ( + cd ignored_dir + GIT_PS1_SHOWUNTRACKEDFILES=y + __git_ps1 $actual + ) + test_cmp expected $actual +' + test_expect_success 'prompt - untracked files status indicator - shell variable unset with config disabled' ' printf (master) expected test_config bash.showUntrackedFiles false -- 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] t2203,t4011: adjust to changed intent-to-add treatment
Michael J Gruber g...@drmicha.warpmail.net writes: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- For the record, the tests would need to change like this, and it makes a lot of sense. After the change, i-t-a is not a change staged in the index any more - and in fact in never was, as git commit shows. Perhaps another follow-up patch can illustrate how these entries should show git status, both in the longform and -s output? t/t2203-add-intent.sh | 7 --- t/t4011-diff-symlink.sh | 10 ++ 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/t/t2203-add-intent.sh b/t/t2203-add-intent.sh index 2a4a749..1a9b3c4 100755 --- a/t/t2203-add-intent.sh +++ b/t/t2203-add-intent.sh @@ -43,7 +43,8 @@ test_expect_success 'i-t-a entry is simply ignored' ' git add -N nitfol git commit -m second test $(git ls-tree HEAD -- nitfol | wc -l) = 0 - test $(git diff --name-only HEAD -- nitfol | wc -l) = 1 + test $(git diff --name-only HEAD -- nitfol | wc -l) = 0 + test $(git diff --name-only -- nitfol | wc -l) = 1 ' test_expect_success 'can commit with an unrelated i-t-a entry in index' ' @@ -71,13 +72,13 @@ test_expect_success 'cache-tree invalidates i-t-a paths' ' : dir/bar git add -N dir/bar - git diff --cached --name-only actual + git diff --name-only actual echo dir/bar expect test_cmp expect actual git write-tree /dev/null - git diff --cached --name-only actual + git diff --name-only actual echo dir/bar expect test_cmp expect actual ' diff --git a/t/t4011-diff-symlink.sh b/t/t4011-diff-symlink.sh index 13e7f62..7452fce 100755 --- a/t/t4011-diff-symlink.sh +++ b/t/t4011-diff-symlink.sh @@ -139,11 +139,13 @@ test_expect_success SYMLINKS 'setup symlinks with attributes' ' test_expect_success SYMLINKS 'symlinks do not respect userdiff config by path' ' cat expect -\EOF diff --git a/file.bin b/file.bin - index e69de29..d95f3ad 100644 - Binary files a/file.bin and b/file.bin differ + new file mode 100644 + index 000..d95f3ad + Binary files /dev/null and b/file.bin differ diff --git a/link.bin b/link.bin - index e69de29..dce41ec 12 - --- a/link.bin + new file mode 12 + index 000..dce41ec + --- /dev/null +++ b/link.bin @@ -0,0 +1 @@ +file.bin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] git-credential-store: support multiple credential files
Junio C Hamano gits...@pobox.com writes: Paul Tan pyoka...@gmail.com writes: I think you could even get away without passing default_fn here, and just use the rule the first file in the list is the default. Unless you are anticipating ever passing something else, but I couldn't think of a case where that would be useful. Even though in this case the store_credential() function is not used anywhere else, from my personal API design experience I think that cementing the rule of the first file in the list is the default in the behavior of the function is not a good thing. For example, in the future, we may wish to keep the precedence ordering the same, but if none of the credential files exist, we create the XDG file by default instead. I am not sure if this is not a premature over-engineering I would say so if having this default_fn made the code more complex, but here the code is basically + if (default_fn) + store_credential_file(default_fn, c); and - store_credential(file, c); + store_credential(fns, c, fns.items[0].string); Taking the first element in the list wouldn't change much. I'm personally fine with both versions. -- 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] git.c: two memory leak fixes
Hello Junio, This is technically correct, but do we really care about it? Yes, as i saw handle_alias called once, and we no need to care about it. I think it is wrong to free alias_string after passing it to split_cmdline() and while you still need to use the new_argv. Yes, right. sorry for the noise. -- 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] diff --cached: do not report i-t-a entries as new
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Paths marked by git add -N are simply a reminder to the user that
these files should be staged. If the user does not stage any of them,
git commit will not record them.
Align the behavior of diff --cached and git commit. The most
prominent result of this patch is git status no longer reports i-t-a
paths as Changes to be committed.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff-lib.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/diff-lib.c b/diff-lib.c
index a85c497..db0e6f8 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -400,6 +400,8 @@ static void do_oneway_diff(struct unpack_trees_options *o,
* Something added to the tree?
*/
if (!tree) {
+ if (idx (idx-ce_flags CE_INTENT_TO_ADD))
+ return;
show_new_file(revs, idx, cached, match_missing);
return;
}
This hunk by itself feels like it is going in the right direction.
The HEAD does not have it, and even though there is idx, it merely
is an i-t-a entry.
Don't you need to special case the call to show_modified() at the
end of this function as well, though? idx is i-t-a, and tree has a
concrete object. Should it appear as if the path already exists in
the index, or should we pretend as if idx is not yet there?
For example, after this sequence:
$ git init
$ void
$ git add void
$ git commit -m void
$ git rm --cached void
$ git add -N void
HEAD has void with an empty blob, the index has i-t-a. I am not
sure if we should say something about path void when asked:
$ git diff --cached
Perhaps something like this to cover that case?
/*
* Something removed from the tree?
*/
- if (!idx) {
+ if (!idx || (ix-ce_flags CE_INTENT_TO_ADD)) {
diff_index_show_file(revs, -, tree, tree-sha1, 1,
tree-ce_mode, 0);
return;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
Yurii Shevtsov unge...@gmail.com writes: Changes 'git diff --no-index $directory $file' behaviour. Now it is transformed to 'git diff --no-index $directory/file $file' I guess the should be a $. instead of throwing an error. Try to insist on _why_ you did this more than what it does in the commit message. Signed-off-by: Yurii Shevtsov ungetch at gmail.com Please, use a real email adress, not a mangled one. --- a/diff-no-index.c +++ b/diff-no-index.c @@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o, if (get_mode(name1, mode1) || get_mode(name2, mode2)) return -1; - if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) - return error(file/directory conflict: %s, %s, name1, name2); I'm surprised to see this error message totally go away. The idea of the microproject was to DWIM (do what I mean) better, but the dwim should apply only when $directory/$file actually exists. Otherwise, the error message should actually be raised. -- I hope I understood task correct. I think this patch requires writing additional tests, so that's what I'm going to do now. This text should go between the --- and the diffstat, not at the end of the message. And yes, this deserves tests ;-). -- 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 RFC 1/3] add: add new --exclude option to git add
Eric Sunshine sunsh...@sunshineco.com writes: The commit message is missing the important justification for why this new option is desirable, and why only git-add needs it. I think that is a very good point. I actually do not see why this option is ever needed, in a modern world that has the negative pathspec magic. Is there a reason why this is undesiable $ git add -- \*.c ':!secret.c' and has to be spelled as $ git add --exclude=secret.c -- \*.c I do not see why... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC] completion: filter sources of git scripts from available commands
A bit of background first: - The completion script gets the lists of available and porcelain git commands from the output of 'git help -a', which, besides the official git commands from $GIT_EXEC_PATH, includes all executables from $PATH whose name begins with 'git-'. Great, this way the completion script can include the user's custom git commands that he dropped somewhere in his $PATH. - The lists of available and porcelain git commands are not initialized when the completion script is sourced, but it's done lazily when the first git completion is performed. Great, this way interactive shells start faster, see eaa4e6ee2a (Speed up bash completion loading, 2009-11-17). - MSysGit's /etc/profile by default includes the current working directory in $PATH. Great, this way MSysGit Bash mimics the Win32 method of finding executables (quoted from /etc/profile). While all three things above are great by themselves, their combination, however, has unwanted side-effects: it makes the list of git commands non-deterministic on MSysGit, as it will depend on the current working directory where the first git completion is performed. Perhaps it's worst when it is performed at the top of a git.git clone because the source files of all git scripts are included in the lists of available and porcelain commands, about twenty, some of them not even sources of porcelains. Possible solutions to avoid this issue are: - Strip the current working directory from $PATH temporarily while we run 'git help -a' to get all the available commands. Care must be taken, because '.' can appear at the very beginning, end, or in the middle of $PATH, not to mention that on unixes it's unlikely but possible to have a directory containing e.g. ':.:' in the $PATH. - Filter out scripts from the output of 'git help -a'. This can be done by either * listing all possible script extensions, but this list will most likely never be complete, or * filtering out all commands containing a filename extension, i.e. anything with a '.' in it. This will bite users whose custom git commands have filename extensions, i.e. who put 'git-mycmd.sh' in '~/bin'. Since this is an RFC, it goes with the last option, because that's the shortest and simplest. Signed-off-by: SZEDER Gábor sze...@ira.uka.de --- contrib/completion/git-completion.bash | 1 + 1 file changed, 1 insertion(+) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index c21190d..9173c41 100644 --- a/contrib/completion/git-completion.bash +++ b/contrib/completion/git-completion.bash @@ -637,6 +637,7 @@ __git_list_all_commands () do case $i in *--*) : helper pattern;; + *.*) : script sources;; *) echo $i;; esac done -- 1.9.5.msysgit.0 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
Hi,
On 03/15, Yurii Shevtsov wrote:
Changes 'git diff --no-index $directory $file' behaviour.
Now it is transformed to 'git diff --no-index $directory/file $file'
instead of throwing an error.
The commit message should describe why the change is made, see
Documentation/SubmittingPatches, section (2)
Signed-off-by: Yurii Shevtsov ungetch at gmail.com
Please use your full email here, without replacing @ with at
---
diff-no-index.c | 21 +++--
You should probably add a test for the new behaviour in
t/t4053-diff-no-index.sh.
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..4e71b36 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o,
if (get_mode(name1, mode1) || get_mode(name2, mode2))
return -1;
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1, name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct strbuf dirnfile;
+ const char *dir, *file;
+ char *filename;
+ int ret = 0;
+
+ dir = S_ISDIR(mode1) ? name1 : name2;
+ file = (dir == name1) ? name2 : name1;
This makes git diff --no-index $directory $file the same as
git diff --no-index $file $directory. Shouldn't these commands give
different results? (See the behaviour of diff in this case, and
compare it to the behaviour you introduced here)
+ strbuf_init(dirnfile, strlen(name1) + strlen(name2) + 2);
+ strbuf_addstr(dirnfile, dir);
+ if (dirnfile.buf[dirnfile.len - 1] != '/')
+ strbuf_addch(dirnfile, '/');
+ filename = strrchr(file, '/');
+ strbuf_addstr(dirnfile, filename ? (filename + 1) : file);
+ ret = queue_diff(o, dirnfile.buf, file);
+ strbuf_release(dirnfile);
+
+ return ret;
+ }
Your MUA seems to have replaced tabs with spaces in this email. The
easiest way to get the formatting correct is the git send-email tool.
You should also try to sending the mail to yourself first and see if
it applies correctly with git am.
if (S_ISDIR(mode1) || S_ISDIR(mode2)) {
struct strbuf buffer1 = STRBUF_INIT;
--
I hope I understood task correct. I think this patch requires writing
additional tests, so that's what I'm going to do now.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] Documentation/git-add.txt: describe --exclude option
On Sun, Mar 15, 2015 at 9:50 AM, Alexander Kuleshov kuleshovm...@gmail.com wrote: Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index f2eb907..4bc156a 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] + [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--exclude=pattern] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--] [pathspec...] @@ -164,6 +164,10 @@ for git add --no-all pathspec..., i.e. ignored removed files. be ignored, no matter if they are already present in the work tree or not. +--exclude=pattern:: + Do not add files to the index in addition which are found in + the .gitignore. This is difficult to understand. Perhaps something like: Also ignore files matching pattern, a .gitignore-like pattern. This option can be specified multiple times, can't it? The documentation should say so. + \--:: This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken -- 2.3.3.472.g20ceeac -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
[re-added cc to the list]
On 03/15, Yurii Shevtsov wrote:
Hi, and thank for your reply
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..4e71b36 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o,
if (get_mode(name1, mode1) || get_mode(name2, mode2))
return -1;
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1,
name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct strbuf dirnfile;
+ const char *dir, *file;
+ char *filename;
+ int ret = 0;
+
+ dir = S_ISDIR(mode1) ? name1 : name2;
+ file = (dir == name1) ? name2 : name1;
This makes git diff --no-index $directory $file the same as
git diff --no-index $file $directory. Shouldn't these commands give
different results? (See the behaviour of diff in this case, and
compare it to the behaviour you introduced here)
I really checked behavior of usual diff. And swapping arguments
doesn't affect result. At first I had doubts about task formulation,
so I asked about it and got the answer:
gmane.comp.version-control.git/265479 Am I misunderstood it again?
Using the same example as in that thread, I get the following output:
tommy at hank in work[1] $ diff -u git junk/diff.h
--- git/diff.h 2014-12-26 21:00:20.690774933 +0100
+++ junk/diff.h 2015-03-15 18:02:03.441049918 +0100
@@ -357,3 +357,4 @@
extern void setup_diff_pager(struct diff_options *);
#endif /* DIFF_H */
+hello
tommy at hank in work $ diff -u junk/diff.h git
--- junk/diff.h 2015-03-15 18:02:03.441049918 +0100
+++ git/diff.h 2014-12-26 21:00:20.690774933 +0100
@@ -357,4 +357,3 @@
extern void setup_diff_pager(struct diff_options *);
#endif /* DIFF_H */
-hello
Notice the +hello vs. -hello in the last line off the diff. Git with
your patch on the other hand gives me +hello in both cases.
tommy at hank in work[1] $ g diff --no-index git junk/diff.h
diff --git a/git/diff.h b/junk/diff.h
index b4a624d..81671dd 100644
--- a/git/diff.h
+++ b/junk/diff.h
@@ -357,3 +357,4 @@ extern int print_stat_summary(FILE *fp, int files,
extern void setup_diff_pager(struct diff_options *);
#endif /* DIFF_H */
+hello
tommy at hank in work[1] $ g diff --no-index junk/diff.h git
diff --git a/git/diff.h b/junk/diff.h
index b4a624d..81671dd 100644
--- a/git/diff.h
+++ b/junk/diff.h
@@ -357,3 +357,4 @@ extern int print_stat_summary(FILE *fp, int files,
extern void setup_diff_pager(struct diff_options *);
#endif /* DIFF_H */
+hello
So while I think the behaviour with git diff --no-index $directory $file
is correct (minus the comments by Matthieu), git diff --no-index $file
$directory is not, I think.
--
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] [GSoC] Add configuration options for some commonly used command-line options
On 03/15/2015 08:29 PM, Koosha Khajehmoogahi wrote:
This patch adds a 'showmerges' config. option for git-log.
This option determines whether the log should contain merge
commits or not. In essence, if this option is set to true,
Sorry, this should be 'false'.
git-log will be run as 'git-log --no-merges'.
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
Documentation/config.txt | 3 +++
builtin/log.c| 8
2 files changed, 11 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1530255..7775b8c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1735,6 +1735,9 @@ log.showroot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
+log.showmerges::
+ If true, merges will be shown in the log list. True by default.
+
log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`.
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..bb36f61 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
static int default_abbrev_commit;
static int default_show_root = 1;
+static int default_max_parents = -1;
static int decoration_style;
static int decoration_given;
static int use_mailmap_config;
@@ -108,6 +109,7 @@ static void cmd_log_init_defaults(struct rev_info *rev)
rev-diffopt.stat_graph_width = -1; /* respect statGraphWidth config */
rev-abbrev_commit = default_abbrev_commit;
rev-show_root_diff = default_show_root;
+ rev-max_parents = default_max_parents;
rev-subject_prefix = fmt_patch_subject_prefix;
DIFF_OPT_SET(rev-diffopt, ALLOW_TEXTCONV);
@@ -390,6 +392,12 @@ static int git_log_config(const char *var, const char
*value, void *cb)
default_show_root = git_config_bool(var, value);
return 0;
}
+
+ if (!strcmp(var, log.showmerges)) {
+ default_max_parents = git_config_bool(var, value) ? -1 : 1;
+ return 0;
+ }
+
if (skip_prefix(var, color.decorate., slot_name))
return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, log.mailmap)) {
--
Koosha
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
Yurii Shevtsov unge...@gmail.com writes:
Changes 'git diff --no-index $directory $file' behaviour.
Now it is transformed to 'git diff --no-index $directory/file $file'
instead of throwing an error.
Is this asymmetric? Shouldn't git diff --no-index $file $directory
behave the same way, i.e. turned into $file $directory/$file?
If you intended the patch to do so, perhaps
git diff --no-index directory/ file used to error out, saying
that you cannot compare a directory and a file (with the
parameters swapped, git diff --no-index file directory/ failed
the same way).
With normal diff, diff D/ F acts as if it were told to
compare D/F and F (when D/F exists---if there isn't, then it
shows a creation of F), and behaving the same way would be more
natural to the users.
or something?
Signed-off-by: Yurii Shevtsov ungetch at gmail.com
---
diff-no-index.c | 21 +++--
1 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..4e71b36 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o,
if (get_mode(name1, mode1) || get_mode(name2, mode2))
return -1;
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1, name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct strbuf dirnfile;
+ const char *dir, *file;
+ char *filename;
+ int ret = 0;
+
+ dir = S_ISDIR(mode1) ? name1 : name2;
+ file = (dir == name1) ? name2 : name1;
+ strbuf_init(dirnfile, strlen(name1) + strlen(name2) + 2);
+ strbuf_addstr(dirnfile, dir);
+ if (dirnfile.buf[dirnfile.len - 1] != '/')
+ strbuf_addch(dirnfile, '/');
+ filename = strrchr(file, '/');
+ strbuf_addstr(dirnfile, filename ? (filename + 1) : file);
+ ret = queue_diff(o, dirnfile.buf, file);
Hmm, it appears that you are turning diff F D/ into diff D/F F,
which is the other way around here, or am I mis-reading queue_diff().
Does queue_diff() do the right thing when D/F does not exist (not a
rhetorical question; I just did not check it myself)?
--
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] [GSoC] Add configuration options for some commonly used command-line options
Koosha Khajehmoogahi koo...@posteo.de writes: This patch adds a 'showmerges' config. option for git-log. This option determines whether the log should contain merge commits or not. In essence, if this option is set to true, git-log will be run as 'git-log --no-merges'. Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de --- Documentation/config.txt | 3 +++ builtin/log.c| 8 2 files changed, 11 insertions(+) diff --git a/Documentation/config.txt b/Documentation/config.txt index 1530255..7775b8c 100644 --- a/Documentation/config.txt +++ b/Documentation/config.txt @@ -1735,6 +1735,9 @@ log.showroot:: Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which normally hide the root commit will now show it. True by default. +log.showmerges:: + If true, merges will be shown in the log list. True by default. When you have to help your colleague by inspecting the history in her repository, and your colleague has this set to false, and you do want your git log to show merge commits, how would you override this setting? git log --merges is not it. Avoid introducing a configuration that users cannot override it from the command line. If there is a way to override (and for the purpose of this discussion, git -c log.showmerges=yes does not count), document it here. Tests need to make sure that (1) with configuration without command line override, the various settings of the variable give behaviour you wanted to give, and (2) with configuration with command line override, the values set to the variable does not have any effect to the behaviour (i.e. the command line override wins). Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] t3700-add: added test for --exclude option
+test_expect_success 'Test that git add --exclude works' ' + touch foo + touch bar can be written shorter as foo bar + git add --exclude=bar . Side question: Do we need here ? Or should we test files with white space as well, like this: foo bar b a z git add --exclude=bar --exclude=b a z . echo bar expect git ls-files actual test_cmp expect actual (Which doesn't use ! grep, but test_cmp, which will give more information when the test case does not pass) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] add: add new --exclude option to git add
Hello All, s /no/not/ ?? Thank you Philip. 2015-03-15 23:51 GMT+06:00 Torsten Bögershausen tbo...@web.de: On 2015-03-15 14.49, Alexander Kuleshov wrote: Thanks for working on Git, some minor remarks/suggestions inline. This patch introduces new --exclude option for the git add command. This patch is redundant. Shorter may be: Introduce the --exclude option for git add Thank you Torsten for you feedback. I will make all fixes and resend patch. One little question, how to better resend it? Just send v2 for the 1/3 or resend all with v2? Or maybe will be better to make one patch from these 3 pathes? Thank you. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fatal: Unable to mark file .ruby-version
On Sun, Mar 15, 2015 at 05:58:19PM +0100, t.gumme...@gmail.com wrote: On 03/15, Arup Rakshit wrote: On Sunday, March 15, 2015 01:30:04 PM you wrote: With --assume-unchanged you're promising git that you will not change a file that is already in the repository. Git doesn't check those files for changes anymore, which can improve performance. I didn't understand your point. Could you please elaborate more on it ? --assume-unchanged only works on files that you added on the repository, not on untracked files. Because you don't seem to want these files in the repository, update-index --assume-unchanged will not work for you. And to elaborate what on what t.gummerer meant earlier: git update-index --assume-unchanged is often abused to ignore already tracked files, thinking that they can change the file while git happily ignores it. --assume-unchanged was neaver built for this purpose, it's built for large code bases where parts of the code base never changes, and git checking this part would only slow it down. So that's why it's called a promise to git that the file never changes, because git doesn't check the status of the file everytime you run git status. But because the file is still tracked, any commit that changes the file causes git to still update that file, but git will then protest, because it found it the file actually changed in the mean time, and you broke that promise. But also already said, this only applies to tracked files, so not to files that aren't being tracked in the first place. 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: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
In addition to the points raised by Matthieu and Thomas...
On Sun, Mar 15, 2015 at 11:35 AM, Yurii Shevtsov unge...@gmail.com wrote:
make git diff --no-index $directory $file DWIM better.
Specify the area affected by the change, followed by a colon, followed
by the change summary. Drop the period at the end. So, something like:
diff: improve '--no-index directory file' DWIMing
Changes 'git diff --no-index $directory $file' behaviour.
Now it is transformed to 'git diff --no-index $directory/file $file'
instead of throwing an error.
Write in imperative mood, so Change rather than Changes. By
itself, the first sentence isn't saying much; it would read better if
you combined the two sentences into one.
Signed-off-by: Yurii Shevtsov ungetch at gmail.com
---
diff --git a/diff-no-index.c b/diff-no-index.c
index 265709b..4e71b36 100644
--- a/diff-no-index.c
+++ b/diff-no-index.c
@@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o,
if (get_mode(name1, mode1) || get_mode(name2, mode2))
return -1;
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1, name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct strbuf dirnfile;
Is this name supposed to stand for dir'n'file, a shorthand for
dir-and-file? Perhaps a simpler more idiomatic name such as path
would suffice. Also, you can initialize the strbuf here at point of
declaration:
struct strbuf path = STRBUF_INIT;
+ const char *dir, *file;
+ char *filename;
+ int ret = 0;
+
+ dir = S_ISDIR(mode1) ? name1 : name2;
+ file = (dir == name1) ? name2 : name1;
+ strbuf_init(dirnfile, strlen(name1) + strlen(name2) + 2);
Unless this is a performance critical loop where you want to avoid
multiple re-allocations, it's customary to pass 0 for the second
argument. Doing so makes the code a bit easier to read and understand,
and avoids questions like this one: Why are you adding 2 to the
requested length? I presume that you're taking the / and NUL into
account, however, strbuf takes NUL into account on its own as part of
its contract, so you probably wanted to add only 1.
+ strbuf_addstr(dirnfile, dir);
+ if (dirnfile.buf[dirnfile.len - 1] != '/')
I don't know how others feel about it, but it makes me a bit
uncomfortable to see potential access of array item -1. I suppose, in
this case, neither name will be zero-length, however, I'd still feel
more comfortable seeing that documented formally, either via assert():
assert(dirnfile.len 0);
if (dirnfile.buf[dirnfile.len - 1] != '/')
or:
if (dirnfile.len 0 dirnfile.buf[dirnfile.len - 1] != '/')
+ strbuf_addch(dirnfile, '/');
+ filename = strrchr(file, '/');
+ strbuf_addstr(dirnfile, filename ? (filename + 1) : file);
+ ret = queue_diff(o, dirnfile.buf, file);
+ strbuf_release(dirnfile);
+
+ return ret;
+ }
if (S_ISDIR(mode1) || S_ISDIR(mode2)) {
struct strbuf buffer1 = STRBUF_INIT;
--
I hope I understood task correct. I think this patch requires writing
additional tests, so that's what I'm going to do now.
--
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] add: add new --exclude option to git add
On 2015-03-15 18.51, Torsten Bögershausen wrote:
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+{ OPTION_CALLBACK, 0, exclude, exclude_list, N_(pattern),
What does pattern mean ?
I was too fast, take that back:
Documentation/gitignore.txt uses pattern as well.
Sorry for the noise.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] t3700-add: added test for --exclude option
On Sun, Mar 15, 2015 at 9:50 AM, Alexander Kuleshov kuleshovm...@gmail.com wrote: t3700-add: added test for --exclude option Write in imperative mood: s/added/add/ Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- diff --git a/t/t3700-add.sh b/t/t3700-add.sh index f7ff1f5..c52a5d0 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -81,6 +81,13 @@ test_expect_success '.gitignore is honored' ' ! (git ls-files | grep \\.ig) ' +test_expect_success 'Test that git add --exclude works' ' + touch foo + touch bar Expanding slightly on what Torsten said: Use 'touch' when the timestamp of the file is significant to the test; otherwise, just use foo. + git add --exclude=bar . + ! (git ls-files | grep bar) For completeness, don't you also want to test that foo _does_ appear in the git-ls-files output? +' + test_expect_success 'error out when attempting to add ignored ones without -f' ' test_must_fail git add a.?? ! (git ls-files | grep \\.ig) -- 2.3.3.472.g20ceeac -- 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/3 v2] add: introduce new --exclude option
From: Alexander Kuleshov kuleshovm...@gmail.com Helped-by: Eric Sunshine sunsh...@sunshineco.com Helped-by: Torsten Bögershausen tbo...@web.de Helped-by: Philip Oakley philipoak...@iee.org While the kudo points are nice to have, I wouldn't say my minor contribution was worthy of the extra Helped-by. I'd be happy for it to be dropped if you have any rewrites. Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: fatal: Unable to mark file .ruby-version
On 03/15, Arup Rakshit wrote: On Sunday, March 15, 2015 01:30:04 PM you wrote: Hi, On 03/15, Arup Rakshit wrote: Hi, I am trying to ignore 2 files, but getting error - [arup@sztukajedzenia (SJ002)]$ git status # On branch SJ002 # Untracked files: # (use git add file... to include in what will be committed) # # .ruby-gemset # .ruby-version nothing added to commit but untracked files present (use git add to track) [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-gemset fatal: Unable to mark file .ruby-gemset [arup@sztukajedzenia (SJ002)]$ git update-index --assume-unchanged .ruby-version fatal: Unable to mark file .ruby-version [arup@sztukajedzenia (SJ002)]$ With --assume-unchanged you're promising git that you will not change a file that is already in the repository. Git doesn't check those files for changes anymore, which can improve performance. I didn't understand your point. Could you please elaborate more on it ? --assume-unchanged only works on files that you added on the repository, not on untracked files. Because you don't seem to want these files in the repository, update-index --assume-unchanged will not work for you. Why it is throwing error ? And how to achieve this without taking the help of the file `.gitignore` ? You can create a file .git/info/exclude in the root directory of the repository with the same syntax as .gitignore to ignore these files. This rules will not be commited in the repository. -- 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 -- Regards, Arup Rakshit Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian Kernighan -- 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 -- Thomas Gummerer -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3 v2] Documentation/git-add.txt: describe --exclude option
Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- Documentation/git-add.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index f2eb907..fee97ed 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] + [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--exclude=pattern] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--] [pathspec...] @@ -164,6 +164,10 @@ for git add --no-all pathspec..., i.e. ignored removed files. be ignored, no matter if they are already present in the work tree or not. +--exclude=pattern:: + Also ignore files matching pattern, a .gitignore-like + pattern. Option can be used multiply times. + \--:: This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken -- 2.3.3.472.g20ceeac.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3 v2] t3700-add: added test for --exclude option
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- t/t3700-add.sh | 18 ++ 1 file changed, 18 insertions(+) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index f7ff1f5..6f71c67 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -332,4 +332,22 @@ test_expect_success 'git add --dry-run --ignore-missing of non-existing file out test_i18ncmp expect.err actual.err ' +test_expect_success 'Test that git add --exclude works' ' + foo + bar + git add --exclude=bar . + ! (git ls-files | grep bar) + (git ls-files | grep foo) +' + +test_expect_success 'Test multiply --exclude' ' + foo + bar + b a z + git add --exclude=bar --exclude=b a z . + (git ls-files | grep foo) + ! (git ls-files | grep b a z) + ! (git ls-files | grep baz) +' + test_done -- 2.3.3.472.g20ceeac.dirty -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3 v2] add: introduce new --exclude option
We already have core.excludesfile configuration variable which indicates
a path to file which contains patterns to exclude. This patch provides
ability to pass --exclude option to the git add command to exclude paths
from command line in addition to which specified in the ignore files.
This option can be useful in a case when we have a directory with some *.ext
files which have changes and we want to commit all files besides one for now.
It can be too annoying to touch .gitignore for this.
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Torsten Bögershausen tbo...@web.de
Helped-by: Philip Oakley philipoak...@iee.org
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/add.c | 12
1 file changed, 12 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..e165fbc 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -244,6 +244,8 @@ static int ignore_removal_cb(const struct option *opt,
const char *arg, int unse
return 0;
}
+static struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -255,6 +257,8 @@ static struct option builtin_add_options[] = {
OPT_BOOL('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOL('N', intent-to-add, intent_to_add, N_(record only the fact
that the path will be added later)),
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+ OPT_STRING_LIST(0, exclude, exclude_list, N_(pattern),
+ N_(do not add files matching pattern to index)),
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as --no-all)),
@@ -305,6 +309,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int add_new_files;
int require_pathspec;
char *seen = NULL;
+ struct exclude_list *el;
git_config(add_config, NULL);
@@ -379,8 +384,14 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
/* Set up the default git porcelain excludes */
memset(dir, 0, sizeof(dir));
if (!ignored_too) {
+ int i;
dir.flags |= DIR_COLLECT_IGNORED;
setup_standard_excludes(dir);
+
+ el = add_exclude_list(dir, EXC_CMDL, --exclude
option);
+ for (i = 0; i exclude_list.nr; i++)
+ add_exclude(exclude_list.items[i].string, ,
0, el, -(i+1));
+
}
memset(empty_pathspec, 0, sizeof(empty_pathspec));
@@ -446,5 +457,6 @@ finish:
die(_(Unable to write new index file));
}
+ string_list_clear(exclude_list, 0);
return exit_status;
}
--
2.3.3.472.g20ceeac.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 RFC 1/3] add: add new --exclude option to git add
From: Alexander Kuleshov kuleshovm...@gmail.com
This patch introduces new --exclude option for the git add
command.
We already have core.excludesfile configuration variable which
indicates
a path to file which contains patterns to exclude. This patch provides
ability to pass --exclude option to the git add command to exclude
paths
from command line in addition to which found in the ignore files.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/add.c | 20
1 file changed, 20 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..5c602a6 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -244,6 +244,16 @@ static int ignore_removal_cb(const struct option
*opt, const char *arg, int unse
return 0;
}
+struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+struct exclude_list *el;
+
+static int exclude_cb(const struct option *opt, const char *arg, int
unset)
+{
+ struct string_list *exclude_list = opt-value;
+ string_list_append(exclude_list, arg);
+ return 0;
+}
+
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -255,6 +265,9 @@ static struct option builtin_add_options[] = {
OPT_BOOL('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOL('N', intent-to-add, intent_to_add, N_(record only the
fact that the path will be added later)),
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+ { OPTION_CALLBACK, 0, exclude, exclude_list, N_(pattern),
+ N_(do no add files matching pattern to index),
s /no/not/ ??
+ 0, exclude_cb },
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as --no-all)),
@@ -298,6 +311,7 @@ static int add_files(struct dir_struct *dir, int
flags)
int cmd_add(int argc, const char **argv, const char *prefix)
{
+ int i;
int exit_status = 0;
struct pathspec pathspec;
struct dir_struct dir;
@@ -381,6 +395,11 @@ int cmd_add(int argc, const char **argv, const
char *prefix)
if (!ignored_too) {
dir.flags |= DIR_COLLECT_IGNORED;
setup_standard_excludes(dir);
+
+ el = add_exclude_list(dir, EXC_CMDL, --exclude option);
+ for (i = 0; i exclude_list.nr; i++)
+ add_exclude(exclude_list.items[i].string, , 0, el, -(i+1));
+
}
memset(empty_pathspec, 0, sizeof(empty_pathspec));
@@ -446,5 +465,6 @@ finish:
die(_(Unable to write new index file));
}
+ string_list_clear(exclude_list, 0);
return exit_status;
}
--
2.3.3.472.g20ceeac
--
Philip
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] add: add new --exclude option to git add
On 2015-03-15 14.49, Alexander Kuleshov wrote:
Thanks for working on Git, some minor remarks/suggestions inline.
This patch introduces new --exclude option for the git add
command.
This patch is redundant. Shorter may be:
Introduce the --exclude option for git add
We already have core.excludesfile configuration variable which indicates
a path to file which contains patterns to exclude. This patch provides
same here: Provide the ability to pass
ability to pass --exclude option to the git add command to exclude paths
from command line in addition to which found in the ignore files.
found ?? Would specified be better?
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
builtin/add.c | 20
1 file changed, 20 insertions(+)
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..5c602a6 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -244,6 +244,16 @@ static int ignore_removal_cb(const struct option *opt,
const char *arg, int unse
return 0;
}
+struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+struct exclude_list *el;
+
+static int exclude_cb(const struct option *opt, const char *arg, int unset)
+{
+ struct string_list *exclude_list = opt-value;
+ string_list_append(exclude_list, arg);
+ return 0;
When we always return 0, the function can be void ?
+}
+
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -255,6 +265,9 @@ static struct option builtin_add_options[] = {
OPT_BOOL('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOL('N', intent-to-add, intent_to_add, N_(record only the fact
that the path will be added later)),
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+ { OPTION_CALLBACK, 0, exclude, exclude_list, N_(pattern),
What does pattern mean ?
Is it the same as a pathspec, used in Documentation/git-add.txt
+ N_(do no add files matching pattern to index),
+ 0, exclude_cb },
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as --no-all)),
@@ -298,6 +311,7 @@ static int add_files(struct dir_struct *dir, int flags)
int cmd_add(int argc, const char **argv, const char *prefix)
{
+ int i;
Do we need i here ?
int exit_status = 0;
struct pathspec pathspec;
struct dir_struct dir;
@@ -381,6 +395,11 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
if (!ignored_too) {
or could it be declared here ?
dir.flags |= DIR_COLLECT_IGNORED;
setup_standard_excludes(dir);
+
+ el = add_exclude_list(dir, EXC_CMDL, --exclude
option);
+ for (i = 0; i exclude_list.nr; i++)
+ add_exclude(exclude_list.items[i].string, ,
0, el, -(i+1));
+
}
memset(empty_pathspec, 0, sizeof(empty_pathspec));
@@ -446,5 +465,6 @@ finish:
die(_(Unable to write new index file));
}
+ string_list_clear(exclude_list, 0);
return exit_status;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] add: add new --exclude option to git add
In addition to points raised by Philip and Torsten...
On Sun, Mar 15, 2015 at 9:49 AM, Alexander Kuleshov
kuleshovm...@gmail.com wrote:
add: add new --exclude option to git add
No need for redundant to git add, since you already have the add: prefix.
This patch introduces new --exclude option for the git add
command.
This line merely repeats the Subject: line, thus can be dropped.
We already have core.excludesfile configuration variable which indicates
a path to file which contains patterns to exclude. This patch provides
ability to pass --exclude option to the git add command to exclude paths
from command line in addition to which found in the ignore files.
The commit message is missing the important justification for why this
new option is desirable, and why only git-add needs it.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..5c602a6 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -244,6 +244,16 @@ static int ignore_removal_cb(const struct option *opt,
const char *arg, int unse
return 0;
}
+struct string_list exclude_list = STRING_LIST_INIT_NODUP;
Shouldn't this be declared static?
+struct exclude_list *el;
Why is this declared globally when it's only needed locally by cmd_add()?
+static int exclude_cb(const struct option *opt, const char *arg, int unset)
+{
+ struct string_list *exclude_list = opt-value;
+ string_list_append(exclude_list, arg);
+ return 0;
+}
+
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -255,6 +265,9 @@ static struct option builtin_add_options[] = {
OPT_BOOL('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOL('N', intent-to-add, intent_to_add, N_(record only the
fact that the path will be added later)),
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+ { OPTION_CALLBACK, 0, exclude, exclude_list, N_(pattern),
+ N_(do no add files matching pattern to index),
+ 0, exclude_cb },
Can this just be OPT_STRING_LIST instead of OPTION_CALLBACK?
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as --no-all)),
@@ -298,6 +311,7 @@ static int add_files(struct dir_struct *dir, int flags)
int cmd_add(int argc, const char **argv, const char *prefix)
{
+ int i;
int exit_status = 0;
struct pathspec pathspec;
struct dir_struct dir;
@@ -381,6 +395,11 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
if (!ignored_too) {
dir.flags |= DIR_COLLECT_IGNORED;
setup_standard_excludes(dir);
+
+ el = add_exclude_list(dir, EXC_CMDL, --exclude
option);
+ for (i = 0; i exclude_list.nr; i++)
+ add_exclude(exclude_list.items[i].string, ,
0, el, -(i+1));
+
}
memset(empty_pathspec, 0, sizeof(empty_pathspec));
@@ -446,5 +465,6 @@ finish:
die(_(Unable to write new index file));
}
+ string_list_clear(exclude_list, 0);
return exit_status;
}
--
2.3.3.472.g20ceeac
--
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] [GSoC] Add configuration options for some commonly used command-line options
This patch adds a 'showmerges' config. option for git-log.
This option determines whether the log should contain merge
commits or not. In essence, if this option is set to true,
git-log will be run as 'git-log --no-merges'.
Signed-off-by: Koosha Khajehmoogahi koo...@posteo.de
---
Documentation/config.txt | 3 +++
builtin/log.c| 8
2 files changed, 11 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1530255..7775b8c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1735,6 +1735,9 @@ log.showroot::
Tools like linkgit:git-log[1] or linkgit:git-whatchanged[1], which
normally hide the root commit will now show it. True by default.
+log.showmerges::
+ If true, merges will be shown in the log list. True by default.
+
log.mailmap::
If true, makes linkgit:git-log[1], linkgit:git-show[1], and
linkgit:git-whatchanged[1] assume `--use-mailmap`.
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..bb36f61 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
static int default_abbrev_commit;
static int default_show_root = 1;
+static int default_max_parents = -1;
static int decoration_style;
static int decoration_given;
static int use_mailmap_config;
@@ -108,6 +109,7 @@ static void cmd_log_init_defaults(struct rev_info *rev)
rev-diffopt.stat_graph_width = -1; /* respect statGraphWidth config */
rev-abbrev_commit = default_abbrev_commit;
rev-show_root_diff = default_show_root;
+ rev-max_parents = default_max_parents;
rev-subject_prefix = fmt_patch_subject_prefix;
DIFF_OPT_SET(rev-diffopt, ALLOW_TEXTCONV);
@@ -390,6 +392,12 @@ static int git_log_config(const char *var, const char
*value, void *cb)
default_show_root = git_config_bool(var, value);
return 0;
}
+
+ if (!strcmp(var, log.showmerges)) {
+ default_max_parents = git_config_bool(var, value) ? -1 : 1;
+ return 0;
+ }
+
if (skip_prefix(var, color.decorate., slot_name))
return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, log.mailmap)) {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] git-credential-store: support multiple credential files
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: Paul Tan pyoka...@gmail.com writes: I think you could even get away without passing default_fn here, and just use the rule the first file in the list is the default. Unless you are anticipating ever passing something else, but I couldn't think of a case where that would be useful. Even though in this case the store_credential() function is not used anywhere else, from my personal API design experience I think that cementing the rule of the first file in the list is the default in the behavior of the function is not a good thing. For example, in the future, we may wish to keep the precedence ordering the same, but if none of the credential files exist, we create the XDG file by default instead. I am not sure if this is not a premature over-engineering I would say so if having this default_fn made the code more complex, True, or if it made caller(s) be redundant or repeat themselves without a good reason. Otherwise we would end up having to drop the redundant and/or unnecessary arguments in future clean-up patches; I had to de-conflict a series with 7ce7c760 (convert: drop arguments other than 'path' from would_convert_to_git(), 2014-08-21) recently, which reminded me of this point ;-). but here the code is basically + if (default_fn) + store_credential_file(default_fn, c); and - store_credential(file, c); + store_credential(fns, c, fns.items[0].string); Taking the first element in the list wouldn't change much. I'm personally fine with both versions. Turning the current code to drop the extra parameter and to use the first element instead wouldn't be a big change, but these things tend to add up, so unless this discussion immediately lead to a future enhancement plan to make use of the flexibility the parameter gives us, I'd rather see things kept simpler. I do not terribly mind either way, either, though. -- 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
What is XDG_CONFIG_HOME for exactly?
My understanding is that git reads the priority of configuration as follows: 1. local_repo/.git/config 2. $HOME/.gitconfig 3. $XDG_CONFIG_HOME/git/config 4. system level git config (not sure exactly where this is; not relevant to me on Windows) I have a .gitconfig in Dropbox that I symlink to my home directory on different platforms. Specifically, I share this gitconfig across Cygwin/msys on Windows and Ubuntu. If I can use XDG_CONFIG_HOME to leverage platform-specific settings, I'd be able to keep platform-agnostic settings in my $HOME/.gitconfig and put platform-specific settings in $XDG_CONFIG_HOME/git/config and simply give XDG_CONFIG_HOME a different name on different platforms. Is this what it was designed for? If not, what would be the best approach for this? I was thinking of contributing a patch that would let you specify the name of your git config in the home directory, but I'm not sure if that is necessary. Something like this: $HOME/$GIT_CONFIG_FILENAME, where GIT_CONFIG_FILENAME defaults to .gitconfig if it is not set or empty. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v2] t3700-add: added test for --exclude option
On Sun, Mar 15, 2015 at 3:07 PM, Alexander Kuleshov kuleshovm...@gmail.com wrote: t3700-add: added test for --exclude option s/added/add/ Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- diff --git a/t/t3700-add.sh b/t/t3700-add.sh index f7ff1f5..6f71c67 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -332,4 +332,22 @@ test_expect_success 'git add --dry-run --ignore-missing of non-existing file out test_i18ncmp expect.err actual.err ' +test_expect_success 'Test that git add --exclude works' ' Rather than inventing a new title style, try to match the style of the existing tests titles in this file. + foo + bar + git add --exclude=bar . + ! (git ls-files | grep bar) Broken -chain. + (git ls-files | grep foo) Unnecessary additional git-ls-files invocation. You could just save the output to a file and then process that file. +' + +test_expect_success 'Test multiply --exclude' ' s/multiply/multiple/ Ditto: Match existing title style. + foo + bar + b a z + git add --exclude=bar --exclude=b a z . + (git ls-files | grep foo) + ! (git ls-files | grep b a z) + ! (git ls-files | grep baz) Broken -chain throughout. Ditto: Unnecessary git-ls-files invocations. +' + test_done -- 2.3.3.472.g20ceeac.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: Bug in fetch-pack.c, please confirm
On Sat, Mar 14, 2015 at 11:37:37PM -0700, Kyle J. McKay wrote:
Peff, weren't you having some issue with want and have and hide refs?
Yes, but the problem was on the server side. I didn't look at this code
at all. :)
Tell me please how the local variable above gets initialized?
So I think we all agree that this is bogus code, and the fix you
proposed is reasonable (but spoiler alert, if you read to the end, I
think we can do something even more extreme). Like Junio, I am puzzled
not by the bug itself, but by its lack of effect over the past 10 years.
I'm not all that familiar with this code, so I started with some rather
blunt-hammer tracing.
If you replace that hashcpy with exit(1), you get quite a few failures
in the test suite. So we really are running the code. Interestingly, if
you replace it with hashclr(ref-old_sha1) (note old, not new, so
impacting the sha1 that we know is actually valid), you still get some
failures, but many fewer.
It looks like one of the ways to hit this code path is by doing a clone
in which we don't actually need any objects (e.g., using --reference).
Clone runs fetch-pack to acquire the objects, but then throws away the
returned refs and writes its own.
But there are still some failures, so clearly some code paths actually
do look at the resulting ref. But nobody seems to care about
ref-new_sha1. Let's take one of the cases that the hashclr() experiment
found and trace that. In t1507, we do a git fetch that hits this case.
I instrumented it like this:
diff --git a/t/t1507-rev-parse-upstream.sh b/t/t1507-rev-parse-upstream.sh
index 1978947..e2a192d 100755
--- a/t/t1507-rev-parse-upstream.sh
+++ b/t/t1507-rev-parse-upstream.sh
@@ -82,7 +82,7 @@ test_expect_success 'refs/heads/my-side@{upstream} does not
resolve to my-side{u
test_expect_success 'my-side@{u} resolves to correct commit' '
git checkout side
test_commit 5
- (cd clone git fetch)
+ (cd clone gdb --args ../../../git fetch /dev/tty /dev/tty)
test 2 = $(commit_subject my-side)
test 5 = $(commit_subject my-side@{u})
'
If we break in everything_local at that hashcpy, we can see:
(gdb) print ref-name
$1 = 0x8422b0 refs/heads/master
(gdb) print sha1_to_hex(ref-old_sha1)
$2 = 0x815a40 hexbuffer 8f489d01d0cc65c3b0f09504ec50b5ed02a70bd5
(gdb) print sha1_to_hex(ref-new_sha1)
$3 = 0x815a69 hexbuffer+41 f2795a0056134b, '0' repeats 11
times, 800
So that's the bogus value copied in. Presumably it's random bytes and
not bleed over from some other sha1, as it's rather unlikely to have
that many zeroes in a real hash.
If we then leave everything_local, we see that the bogus value comes out
to do_fetch_pack via the ref parameter. We feed that into find_common,
but it only looks at ref-old_sha1, the other side. We keep going, and
do_fetch_pack returns the bogus ref up to fetch_pack(). That in turn
passes it up to fetch_refs_via_pack.
And there we stop. We don't pass the refs list out of that function
(which, as an aside, is probably a leak). Instead, we depend on the list
of heads we already knew in the to_fetch array. That comes from
processing the earlier list of refs returned from get_refs_via_connect.
I think it was the case once upon a time that fetch-pack did more of the
which refs to fetch, and how to update them logic. The pipeline for
fetch is now more like:
1. get_refs_via_connect returns a list of refs
2. caller munges the list of refs, based on refspecs
3. fetch_refs_via_pack takes that list of refs as input
Of course, this being git, there's always a way to try to access the
old code paths. :)
You can do something like:
git init
git commit --allow-empty -m foo
git fetch-pack --all .
which hits the same code path, but actually retains the return value
from fetch_pack(). But even there, it looks like we don't look at
ref-new_sha1 at all. fetch-pack doesn't update refs at all, but just
prints the list of new values to stdout.
So I think there is literally no code path that ever looks at the bogus
sha1. We could just drop that hashcpy() entirely.
That doesn't mean there isn't an additional bug lurking. That is,
_should_ somebody be caring about that value? I don't think so. The
old/new pairs in a struct ref are meaningful as I proposed to update
to X, and we are at Y. But this list of refs does not have anything to
do with the update of local refs. It is only what is the value of the
ref on the other side. The local refs are taken care of in a separate
list.
-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 v2] git prompt: Use toplevel to find untracked files.
SZEDER Gábor sze...@ira.uka.de writes: Hi, Quoting Junio C Hamano gits...@pobox.com: Cody A Taylor cody.tay...@maternityneighborhood.com writes: The __git_ps1() prompt function would not show an untracked state when the current working directory was not a parent of the untracked file. Good find, and nicely explained. Somehow I had a hard time making sense out of when the current working directory was not a parent of the untracked file. Perhaps when the untracked files are outside of the current working directory would be easier to grok? Sounds good; let me use that when squashing your test updates in. Thanks, both. I wonder if we can add a test or two to t9903-bash-prompt.sh? This test fails without the patch in question and succeeds with it. -- 8 -- diff --git a/t/t9903-bash-prompt.sh b/t/t9903-bash-prompt.sh index 51ecd3e..3d1a95f 100755 --- a/t/t9903-bash-prompt.sh +++ b/t/t9903-bash-prompt.sh @@ -397,6 +397,16 @@ test_expect_success 'prompt - untracked files status indicator - untracked files test_cmp expected $actual ' +test_expect_success 'prompt - untracked files status indicator - untracked files outside cwd' ' + printf (master %%) expected + ( + cd ignored_dir + GIT_PS1_SHOWUNTRACKEDFILES=y + __git_ps1 $actual + ) + test_cmp expected $actual +' + test_expect_success 'prompt - untracked files status indicator - shell variable unset with config disabled' ' printf (master) expected test_config bash.showUntrackedFiles false -- 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 03/16] list-files: show paths relative to cwd
On Mon, Mar 16, 2015 at 4:16 AM, Junio C Hamano gits...@pobox.com wrote: Duy Nguyen pclo...@gmail.com writes: Exactly. We would need to sort and stuff later on, so true filenames are preserved in util-item. A cleaner way is perhaps carry all metadata in item-util and item-string remains true filename, then do all the formatting, coloring for all strings just before displaying. I guess we are then in agreement with my review comment on [04/16]. Yes. I'm redoing it. I will probably stop using string-list as well (it's inherited from the old code), just an array of struct. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3 v2] add: introduce new --exclude option
On Sun, Mar 15, 2015 at 3:06 PM, Alexander Kuleshov
kuleshovm...@gmail.com wrote:
We already have core.excludesfile configuration variable which indicates
a path to file which contains patterns to exclude. This patch provides
ability to pass --exclude option to the git add command to exclude paths
from command line in addition to which specified in the ignore files.
This option can be useful in a case when we have a directory with some *.ext
files which have changes and we want to commit all files besides one for now.
It can be too annoying to touch .gitignore for this.
Won't this lead to unintuitive behavior? The 'excludes' mechanism does
not unconditionally ignore; instead, it ignores _untracked_ files.
Consider file foo which is already tracked. Make a temporary change
to foo which you don't intend to commit. Since foo is tracked, the
command 'git add . --exclude=foo' will still add foo to the index,
despite the use of --exclude. Most people would probably find such
behavior surprising and undesirable.
The negative pathspec mentioned by Junio[1], on the other hand, does
not suffer this shortcoming.
More below.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/265493/focus=265518
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Helped-by: Torsten Bögershausen tbo...@web.de
Helped-by: Philip Oakley philipoak...@iee.org
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
---
diff --git a/builtin/add.c b/builtin/add.c
index 3390933..e165fbc 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -244,6 +244,8 @@ static int ignore_removal_cb(const struct option *opt,
const char *arg, int unse
return 0;
}
+static struct string_list exclude_list = STRING_LIST_INIT_NODUP;
+
static struct option builtin_add_options[] = {
OPT__DRY_RUN(show_only, N_(dry run)),
OPT__VERBOSE(verbose, N_(be verbose)),
@@ -255,6 +257,8 @@ static struct option builtin_add_options[] = {
OPT_BOOL('u', update, take_worktree_changes, N_(update tracked
files)),
OPT_BOOL('N', intent-to-add, intent_to_add, N_(record only the
fact that the path will be added later)),
OPT_BOOL('A', all, addremove_explicit, N_(add changes from all
tracked and untracked files)),
+ OPT_STRING_LIST(0, exclude, exclude_list, N_(pattern),
+ N_(do not add files matching pattern to index)),
{ OPTION_CALLBACK, 0, ignore-removal, addremove_explicit,
NULL /* takes no arguments */,
N_(ignore paths removed in the working tree (same as --no-all)),
@@ -305,6 +309,7 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
int add_new_files;
int require_pathspec;
char *seen = NULL;
+ struct exclude_list *el;
This variable is only used within the 'if (!ignored_too)' block below,
so its declaration should be moved there.
git_config(add_config, NULL);
@@ -379,8 +384,14 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
/* Set up the default git porcelain excludes */
memset(dir, 0, sizeof(dir));
if (!ignored_too) {
+ int i;
dir.flags |= DIR_COLLECT_IGNORED;
setup_standard_excludes(dir);
+
+ el = add_exclude_list(dir, EXC_CMDL, --exclude
option);
+ for (i = 0; i exclude_list.nr; i++)
+ add_exclude(exclude_list.items[i].string, ,
0, el, -(i+1));
+
}
memset(empty_pathspec, 0, sizeof(empty_pathspec));
@@ -446,5 +457,6 @@ finish:
die(_(Unable to write new index file));
}
+ string_list_clear(exclude_list, 0);
return exit_status;
}
--
2.3.3.472.g20ceeac.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 RFC 1/3] add: add new --exclude option to git add
From: Junio C Hamano gits...@pobox.com Eric Sunshine sunsh...@sunshineco.com writes: The commit message is missing the important justification for why this new option is desirable, and why only git-add needs it. I think that is a very good point. I actually do not see why this option is ever needed, in a modern world that has the negative pathspec magic. Isn't the problem one of how are users to discover such magic. The fact we call it 'magic' (a sleight of hand...) may be why Alexander felt the need for the extra option. Maybe He/We would be better off adjusting the documentation such that these 'magic' capabilities are brought out of their hiding places into regular view - e.g. a paragraph within the 'git add' documentation (and/or other commands) showing how such excludes are easily done with a few simple keystrokes 'git help revisions' doesn't appear to cover it. I'm not sure we even mention negative pathspec in the documentation (apart from rel notes 1.9.0 2.3.0). Maybe Alexander could change itch to: make the magic negative pathspec capability more visible? Is there a reason why this is undesiable $ git add -- \*.c ':!secret.c' and has to be spelled as $ git add --exclude=secret.c -- \*.c I do not see why... -- Philip -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
Eric Sunshine sunsh...@sunshineco.com writes: Is this name supposed to stand for dir'n'file,... ...I personally find the idiomatic name 'path' easier to grok, however, Junio, of course, has final say-so. If I were presented two identical patches, one calling it path and the other calling it dirnfile, I would definitely take the former, but I agree that this is more of a preference than a taste, the latter of which implies that you could make a value judgement, i.e. good taste vs bad taste. If for some reason we had a code that called a variable dirnfile already in our official codebase and we saw a patch to correct that to path, I would likely say that it is not worth the churn to apply such a correction patch. If the new name were pathname, however, I might be pursuaded to take it, simply because a pathname is a lot more familiar word than dirnfile. -- 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: Promoting Git developers
Christian Couder christian.cou...@gmail.com writes: I wrote something about a potential Git Rev News news letter: I read it. Sounds promising. Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. I obviously do not know how the actual contents would look like at this point, but depending on the quality of the publication I might be able to steal some descriptions when keeping the notes on topics in flight that appear in my What's cooking report. And it can go the other way around, too. The publication may want to peek my What's cooking report for hints on how to characterize each topic and assess its impact to the evolution of Git. -- 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: Promoting Git developers
On March 15, 2015 6:19 PM Christian Couder wrote: snip Just one suggestion on the name and half a comment. How would Git Review (or Git Monthly Review, or replace your favourite how-often-per-period-ly in its name) sound? I meant it to sound similar to academic journals that summarize and review contemporary works in the field and keeps your original pun about our culture around patch reviews. If I may humbly offer the suggestion that Git Blame would be a far more appropriate pun as a name :) -- 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 03/16] list-files: show paths relative to cwd
Duy Nguyen pclo...@gmail.com writes: Exactly. We would need to sort and stuff later on, so true filenames are preserved in util-item. A cleaner way is perhaps carry all metadata in item-util and item-string remains true filename, then do all the formatting, coloring for all strings just before displaying. I guess we are then in agreement with my review comment on [04/16]. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC 1/3] add: add new --exclude option to git add
Philip Oakley philipoak...@iee.org writes: Maybe He/We would be better off adjusting the documentation such that these 'magic' capabilities are brought out of their hiding places into regular view - e.g. a paragraph within the 'git add' documentation (and/or other commands) showing how such excludes are easily done with a few simple keystrokes I agree documenting is good, but I do not think it belongs to git add. For example, shouldn't git log -- \*.c ':!secret.c' work the same way? 'git help revisions' doesn't appear to cover it. Of course not, because revisions would cover revisions, and pathspecs are different animals ;-) Again, I agree there should be a section somewhere close to the central place that talks about pathspecs in general and then talk about pathspec magic there. There are some references in git(1) but they talk about ways to implicitly enable the magic to _all_ pathspecs, before introducing the readers to what the magics are and how they can use them. Perhaps in git(1), before we introduce GIT COMMANDS, we may want to have a new section that talks about the general structure of the Git command line, laying out the general rules such as * dashed options come first * revisions and ranges come second * pathspecs come last The first one is described in detail in gitcli(7) and how revisions are spelled is given in gitrevisions(7). How pathspecs are spelled and used may want to be its own gitpathspecs(7), or if there are not too many rules, can be spelled out there inline. Either way, we would want a brief section in git(1) to serve as a jumping board for the former two, at least. Also descriptions for --literal-pathspecs and friends would want to refer to either the section or have a direct reference to gitpathspecs(7) if we are going to write it a new 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: What is XDG_CONFIG_HOME for exactly?
Sorry for the continuous updates... it seems I spoke too soon. This works until you CD into a repository, then none of the settings are accessible. So yeah, basically I need to make sure I'm using this as intended... I still don't understand the purpose of the XDG thing. On Sun, Mar 15, 2015 at 6:50 PM, Robert Dailey rcdailey.li...@gmail.com wrote: As a follow-up, I tested the following in my .bashrc: # Utilize different GIT settings based on platform if [[ $OSTYPE == 'msys' || $OSTYPE == 'cygwin' ]]; then echo 'Using WINDOWS specific git settings' export XDG_CONFIG_HOME=.config-windows else echo 'Using LINUX specific git settings' export XDG_CONFIG_HOME=.config-linux fi This seems to work nicely!! I share my $HOME directory (located in dropbox) across all platforms so this helps me keep a consistent environment across all my machines with zero effort. On Sun, Mar 15, 2015 at 6:37 PM, Robert Dailey rcdailey.li...@gmail.com wrote: My understanding is that git reads the priority of configuration as follows: 1. local_repo/.git/config 2. $HOME/.gitconfig 3. $XDG_CONFIG_HOME/git/config 4. system level git config (not sure exactly where this is; not relevant to me on Windows) I have a .gitconfig in Dropbox that I symlink to my home directory on different platforms. Specifically, I share this gitconfig across Cygwin/msys on Windows and Ubuntu. If I can use XDG_CONFIG_HOME to leverage platform-specific settings, I'd be able to keep platform-agnostic settings in my $HOME/.gitconfig and put platform-specific settings in $XDG_CONFIG_HOME/git/config and simply give XDG_CONFIG_HOME a different name on different platforms. Is this what it was designed for? If not, what would be the best approach for this? I was thinking of contributing a patch that would let you specify the name of your git config in the home directory, but I'm not sure if that is necessary. Something like this: $HOME/$GIT_CONFIG_FILENAME, where GIT_CONFIG_FILENAME defaults to .gitconfig if it is not set or empty. -- 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] git prompt: Use toplevel to find untracked files.
SZEDER Gábor sze...@ira.uka.de writes: Somehow I had a hard time making sense out of when the current working directory was not a parent of the untracked file. Perhaps when the untracked files are outside of the current working directory would be easier to grok? That description doesn't cover all cases. Scenario #1: Let's say there is an untracked file at `$ROOT/file`. When your CWD is `$ROOT/`, all is well. If you cd to `$ROOT/src/` the ls-files command failed to find the untracked file. Scenario #2: Let's say there is an untracked file at `$ROOT/src/file`. The ls-files command would find the file if the CWD is `$ROOT/` or `$ROOT/src/`, but not if the CWD is `$ROOT/bin/` or `$ROOT/src/folder/`. Your description may be easier to understand, but I don't agree it's accurate. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
[re-adding cc:git]
On Sun, Mar 15, 2015 at 2:45 PM, Yurii Shevtsov unge...@gmail.com wrote:
On Sun, Mar 15, 2015 at 11:35 AM, Yurii Shevtsov unge...@gmail.com wrote:
make git diff --no-index $directory $file DWIM better.
Specify the area affected by the change, followed by a colon, followed
by the change summary. Drop the period at the end. So, something like:
diff: improve '--no-index directory file' DWIMing
Changes 'git diff --no-index $directory $file' behaviour.
Now it is transformed to 'git diff --no-index $directory/file $file'
instead of throwing an error.
Write in imperative mood, so Change rather than Changes. By
itself, the first sentence isn't saying much; it would read better if
you combined the two sentences into one.
Got it! My commit message requires improvements
---
- if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2))
- return error(file/directory conflict: %s, %s, name1,
name2);
+ if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) {
+ struct strbuf dirnfile;
Is this name supposed to stand for dir'n'file, a shorthand for
dir-and-file? Perhaps a simpler more idiomatic name such as path
would suffice. Also, you can initialize the strbuf here at point of
declaration:
struct strbuf path = STRBUF_INIT;
Yes it is supposed to be dir-and-file I thought path isn't
descriptive enough because it could be path to dir. But if you insist,
no problems
The reason I asked was because it is not uncommon for variable names
with an 'n' suffix to mean length of something, so the 'n' in 'dirn'
was a bit confusing. I personally find the idiomatic name 'path'
easier to grok, however, Junio, of course, has final say-so. It's okay
to argue for your choice in naming if you feel strongly that it is
better.
+ const char *dir, *file;
+ char *filename;
+ int ret = 0;
+
+ dir = S_ISDIR(mode1) ? name1 : name2;
+ file = (dir == name1) ? name2 : name1;
+ strbuf_init(dirnfile, strlen(name1) + strlen(name2) + 2);
Unless this is a performance critical loop where you want to avoid
multiple re-allocations, it's customary to pass 0 for the second
argument. Doing so makes the code a bit easier to read and understand,
and avoids questions like this one: Why are you adding 2 to the
requested length? I presume that you're taking the / and NUL into
account, however, strbuf takes NUL into account on its own as part of
its contract, so you probably wanted to add only 1.
Yes I thought about performance. I thought it is reasonable since I
always know size of resulting string. Checked strbuf.c one more time,
yoг are right I should really add only 1
A few reasons I probably would just pass 0 in this case: (1) this
string construction is not performance critical; (2) a person reading
the code has to spend extra time double-checking the math; (3) the
math may become outdated if someone later alters the string
construction in some way, thus it's a potential maintenance burden;
(4) terser code tends to be easier to read and understand at a glance,
so the less verbose the code, the better.
However, as usual, it's entirely acceptable to argue for your version
if you feel strongly about it.
+ strbuf_addstr(dirnfile, dir);
+ if (dirnfile.buf[dirnfile.len - 1] != '/')
I don't know how others feel about it, but it makes me a bit
uncomfortable to see potential access of array item -1. I suppose, in
this case, neither name will be zero-length, however, I'd still feel
more comfortable seeing that documented formally, either via assert():
assert(dirnfile.len 0);
if (dirnfile.buf[dirnfile.len - 1] != '/')
or:
if (dirnfile.len 0 dirnfile.buf[dirnfile.len - 1] != '/')
My fault again
--
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 in fetch-pack.c, please confirm
On Mar 15, 2015, at 00:30, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Kyle J. McKay mack...@gmail.com writes: Hi guys, So I was looking at fetch-pack.c (from master @ 52cae643, but I think it's the same everywhere): ... - hashcpy(ref-new_sha1, local); + hashcpy(ref-new_sha1, o-sha1); if (!args-verbose) continue; fprintf(stderr, already have %s (%s)\n, sha1_to_hex(remote), ref-name); } return retval; --- One thing I wonder is if this hashcpy() is doing anything useful, though. Is ref-new_sha1 used after we are done in this codepath, or is the reason nobody noticed it is because it does not matter whatever garbage is in that field nobody looks at it? My thoughts exactly. hence the please confirm request. I'm not familiar enough with the fetch pack code to know the answer off the top of my head. I was hoping someone else who's been in the fetch pack code recently (*Hi Peff*) might just already know. :) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is XDG_CONFIG_HOME for exactly?
As a follow-up, I tested the following in my .bashrc: # Utilize different GIT settings based on platform if [[ $OSTYPE == 'msys' || $OSTYPE == 'cygwin' ]]; then echo 'Using WINDOWS specific git settings' export XDG_CONFIG_HOME=.config-windows else echo 'Using LINUX specific git settings' export XDG_CONFIG_HOME=.config-linux fi This seems to work nicely!! I share my $HOME directory (located in dropbox) across all platforms so this helps me keep a consistent environment across all my machines with zero effort. On Sun, Mar 15, 2015 at 6:37 PM, Robert Dailey rcdailey.li...@gmail.com wrote: My understanding is that git reads the priority of configuration as follows: 1. local_repo/.git/config 2. $HOME/.gitconfig 3. $XDG_CONFIG_HOME/git/config 4. system level git config (not sure exactly where this is; not relevant to me on Windows) I have a .gitconfig in Dropbox that I symlink to my home directory on different platforms. Specifically, I share this gitconfig across Cygwin/msys on Windows and Ubuntu. If I can use XDG_CONFIG_HOME to leverage platform-specific settings, I'd be able to keep platform-agnostic settings in my $HOME/.gitconfig and put platform-specific settings in $XDG_CONFIG_HOME/git/config and simply give XDG_CONFIG_HOME a different name on different platforms. Is this what it was designed for? If not, what would be the best approach for this? I was thinking of contributing a patch that would let you specify the name of your git config in the home directory, but I'm not sure if that is necessary. Something like this: $HOME/$GIT_CONFIG_FILENAME, where GIT_CONFIG_FILENAME defaults to .gitconfig if it is not set or empty. -- 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/3 v2] Documentation/git-add.txt: describe --exclude option
On Sun, Mar 15, 2015 at 3:06 PM, Alexander Kuleshov kuleshovm...@gmail.com wrote: Helped-by: Eric Sunshine sunsh...@sunshineco.com Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com --- diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt index f2eb907..fee97ed 100644 --- a/Documentation/git-add.txt +++ b/Documentation/git-add.txt @@ -9,7 +9,7 @@ SYNOPSIS [verse] 'git add' [--verbose | -v] [--dry-run | -n] [--force | -f] [--interactive | -i] [--patch | -p] - [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] + [--edit | -e] [--[no-]all | --[no-]ignore-removal | [--update | -u]] [--exclude=pattern] [--intent-to-add | -N] [--refresh] [--ignore-errors] [--ignore-missing] [--] [pathspec...] @@ -164,6 +164,10 @@ for git add --no-all pathspec..., i.e. ignored removed files. be ignored, no matter if they are already present in the work tree or not. +--exclude=pattern:: + Also ignore files matching pattern, a .gitignore-like + pattern. Option can be used multiply times. s/multiply/multiple/ + \--:: This option can be used to separate command-line options from the list of files, (useful when filenames might be mistaken -- 2.3.3.472.g20ceeac.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
Why do my .avi files not appear in my XBMC library?
Why do my .avi files not appear in my XBMC library? Convert universal AVI to MP4/WMV for playback on XBMC? This AVI to XBMC Tutorial teaches convert AVI to XBMC video format with fast speed. XBMC has been the most popular media player that can be used to build a home theater system. Although XBMC says that it can play a plenty of media formats including AVI, we still easily find complaints about XBMC won't play AVI issue: The people who have developed XBMC have done a bang-up job, by packaging a nice interface along with a great platform for playing all sorts of videos and even being able to load games. I started using XBMC a few days ago, but now I am frustrated because I couldn't get some AVI files to play. They would act like they were going to start, but after a second or so, they would just stop. I was pulling out what little hair I had left. In fact, XBMC allows users to play AVI files, but the condition is not that stable. Whether we can play AVI on XBMC or not, it mainly depends on the video/audio codec included in the AVI video. So, the best way to get XBMC play AVI movie is to convert AVI to XBMC more compatible formats. Easy Solution to Play AVI on XBMC Smoothly There is a simple tool with which you can do AVI to XBMC converting without the need to know any code knowledge: Pavtube Video Converter Ultimate. This AVI to XBMC Converter helps users to convert AVI to any XBMC supported video formats, be it H.264, MPEG4, MKV, or WMV2, WM3, enabling them to play AVI on XBMC. (Read Best Video Converter Ultimate review) Note: For those who want to watch videos in other formats, such as MKV, MOV, FLV,and etc on mobile devices besides XBMC like iPhone, iPad, Android, XBox, PS3 and etc, eg. AVI to Galaxy Tab S, AVI to iPhone 6 Plus, AVI to PS4 and etc, this video converter, enables conversion with fast speed and no quality loss. How to Play AVI on XBMC with AVI on XBMC Converter Step 1. Start AVI to XBMC Converter(Mac version is here), drag and drop the AVI files to the software window to import. Step 2. After the files are added, click Format HD Video and set output video format as mp4. The reason mp4 is the target format is that by packing the videos in mp4, the file size will be reasonable small and the video quality remains. WMV is also compatible. Tips: There are also some optional tinkering you can take to make the videos look better on a HDTV screen, such as changing the aspect ratio or specifying the video resolution. Just click the Settings icon to do it. Step 3. Finally, hit the Convert button to star converting AVI to MP4 for XBMC playback. After the conversion is completed, transfer the converted videos to XBMC library. Now you can enjoy your AVI movies with XBMC. -- View this message in context: http://git.661346.n2.nabble.com/Why-do-my-avi-files-not-appear-in-my-XBMC-library-tp7627126.html Sent from the git mailing list archive at Nabble.com. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC][GSoC] make git diff --no-index $directory $file DWIM better.
Matthieu Moy matthieu@grenoble-inp.fr writes: --- a/diff-no-index.c +++ b/diff-no-index.c @@ -97,8 +97,25 @@ static int queue_diff(struct diff_options *o, if (get_mode(name1, mode1) || get_mode(name2, mode2)) return -1; - if (mode1 mode2 S_ISDIR(mode1) != S_ISDIR(mode2)) - return error(file/directory conflict: %s, %s, name1, name2); I'm surprised to see this error message totally go away. The idea of the microproject was to DWIM (do what I mean) better, but the dwim should apply only when $directory/$file actually exists. Otherwise, the error message should actually be raised. I actually think this check, when we really fixed diff --no-index to work sensibly, should go away and be replaced with something sensible. As it stands now, even before we think about dwimming diff D/ F into diff D/F F, a simple formulation like this will error out. $ mkdir -p a/sub b $ touch a/file b/file b/sub a/sub/file $ git diff --no-index a b error: file/directory conflict: a/sub, b/sub Admittedly, that is how ordinary diff -r works, but I am not sure if we want to emulate that aspect of GNU diff. If the old tree a has a directory 'sub' with 'file' under it (i.e. a/sub/file) where the new tree has a file at 'sub', then the recursive diff can show the removal of sub/file and creation of sub, no? That is what we show for normal git diff. But I _think_ fixing that is way outside the scope of GSoC Micro. And patching this function, because it is recursively called from within it, to dwim is simply wrong. When we see a/sub that is a directory and b/sub that is a file, we do *NOT* want to rewrite the comparison to comparison between a/sub/sub and b/sub. What needs to be fixed for the Micro is the top-level call to queue_diff() that is made blindly between paths[0] and paths[1] without checking what kind of things these are. -- 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: fatal: Unable to mark file .ruby-version
On Sunday, 15 March 2015 11:15 PM, Kevin D m...@ikke.info wrote: On Sun, Mar 15, 2015 at 05:58:19PM +0100, t.gumme...@gmail.com wrote: On 03/15, Arup Rakshit wrote: On Sunday, March 15, 2015 01:30:04 PM you wrote: With --assume-unchanged you're promising git that you will not change a file that is already in the repository. Git doesn't check those files for changes anymore, which can improve performance. I didn't understand your point. Could you please elaborate more on it ? --assume-unchanged only works on files that you added on the repository, not on untracked files. Because you don't seem to want these files in the repository, update-index --assume-unchanged will not work for you. And to elaborate what on what t.gummerer meant earlier: git update-index --assume-unchanged is often abused to ignore already tracked files, thinking that they can change the file while git happily ignores it. --assume-unchanged was neaver built for this purpose, it's built for large code bases where parts of the code base never changes, and git checking this part would only slow it down. So that's why it's called a promise to git that the file never changes, because git doesn't check the status of the file everytime you run git status. But because the file is still tracked, any commit that changes the file causes git to still update that file, but git will then protest, because it found it the file actually changed in the mean time, and you broke that promise. But also already said, this only applies to tracked files, so not to files that aren't being tracked in the first place. Kevin Thanks both of you. As per your suggestions I resolved it. I found a good link on this topic too https://help.github.com/articles/ignoring-files/. Regards, Arup Rakshit -- 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
