Re: [PATCH v4] notes: Allow treeish expressions as notes ref
On Fri, Jul 10, 2015 at 3:28 AM, Mike Hommey wrote:
> init_notes() is the main point of entry to the notes API. It is an arbitrary
> restriction that all it allows as input is a strict ref name, when callers
> may want to give an arbitrary treeish.
>
> However, some operations that require updating the notes tree require a
> strict ref name, because they wouldn't be able to update e.g. foo@{1}.
>
> So we allow treeish expressions to be used in the case the notes tree is
> going to be used without write "permissions", and to distinguish whether
> the notes tree is intended to be used for reads only, or will be updated,
> a flag is added.
>
> This has the side effect of enabling the use of treeish as notes refs in
> commands allowing them, e.g. git log --notes=foo@{1}.
Looks good. However, on a second pass I noticed that the patch comes
with no tests. I'd like at least a couple of tests thrown in there to verify
correctness; e.g. reading notes from refs/notes/commits^{tree} shall
succeed, and trying to write notes to refs/notes/commits^{tree} shall fail.
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] notes: Allow treeish expressions as notes ref
On Fri, Jul 10, 2015 at 09:16:16AM +0200, Johan Herland wrote:
> On Fri, Jul 10, 2015 at 3:28 AM, Mike Hommey wrote:
> > init_notes() is the main point of entry to the notes API. It is an arbitrary
> > restriction that all it allows as input is a strict ref name, when callers
> > may want to give an arbitrary treeish.
> >
> > However, some operations that require updating the notes tree require a
> > strict ref name, because they wouldn't be able to update e.g. foo@{1}.
> >
> > So we allow treeish expressions to be used in the case the notes tree is
> > going to be used without write "permissions", and to distinguish whether
> > the notes tree is intended to be used for reads only, or will be updated,
> > a flag is added.
> >
> > This has the side effect of enabling the use of treeish as notes refs in
> > commands allowing them, e.g. git log --notes=foo@{1}.
>
> Looks good. However, on a second pass I noticed that the patch comes
> with no tests. I'd like at least a couple of tests thrown in there to verify
> correctness; e.g. reading notes from refs/notes/commits^{tree} shall
> succeed, and trying to write notes to refs/notes/commits^{tree} shall fail.
Fair enough. Will update.
Mike
--
To unsubscribe from this list: send the line "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: Reset sometimes updates mtime
On do, 2015-07-09 at 10:56 -0700, Junio C Hamano wrote: > Dennis Kaarsemaker writes: > > > I'm seeing some behaviour with git reset that I find odd. Basically if I > > do > > > > git fetch && \ > > git reset --hard simple-tag-that-points-to-the-current-commit > > > > sometimes the reset will update the mtime of all files and directories > > in the repo and sometimes it will leave them alone. Changing it to > > > > git fetch && \ > > git status && \ > > git reset --hard simple-tag-that-points-to-the-current-commit > > > > Cause the mtime update to reliably not happen. > > If my theory on what is happening is correct, I do not think there > is any bug in what "reset --hard" is doing. > > My theory is that something is causing the stat info that is cached > in your index and the lstat(2) return you get from your working tree > files go out of sync. Even though you are not actively touching any > working tree files (otherwise, you wouldn't be complaining about > mtime changing in the first place), perhaps your build of Git > records timestamps in NS but your filesystem and the operating > system does not preserve nanosecond resolution of timestamps when it > evicts inode data from the core, or something like that? If that is > what is happening, I think that "fetch" is a red herring, but any > operation that takes some time and/or hits filesystem reasonably > hard would trigger it. > > And the reason why I say there is no bug in what "reset --hard" is > doing here, if the above theory is correct, is because: > > - The user asked "reset --hard" to "make sure that my working tree >files are identical to those of HEAD"; > > - "reset --hard" looks at lstat(2) return and the cached stat info >in the index and find them not to match. It can do one of two >things: > >(1) see if the user did something stupid, like "touch file", that >modifies only lstat(2) info without actually changing its >contents, by reading from the working tree, reading HEAD:file >from the object database, and comparing them, and overwrite >the working tree file only when they do not match. > >or > >(2) the contents might happen to be the same, but the end result >user desires to have is that the contents of the working tree >file is the same as that from the HEAD, so overwrite it >without wasting time reading two and compare before doing so. > >and it is perfectly reasonable to do the latter. After all, the >whole point of having its cached lstat(2) data in the index is to >so that we do not have to always compare the contents before >deciding something has changed in the working tree. > > Running "git update-index --refresh" immediately before "reset" may > alleviate the issue. "git status" has the same effect, only because > it does "update-index --refresh" at the beginning of its processing, > but it wastes a lot more time and resource doing other things. > > But unless/until you know _why_ the cached stat info in your index > goes stale relative to what lstat(2) tells you, it would not "solve" > it, because that magical thing (and my theory is cached data in your > operating system that keeps a file timestamp with more precision > than your underlying filesystem can represent is being flushed, and > reading the file timestamp back from the disk has to truncate the > nanoseconds part) can happen at any time between the "--refresh" and > your "reset". Thanks Junio! If I understand you correctly, reset should not touch files if it thinks they are up-to-date, so at least that assumption is safe to make. I'll test your theory about why reset thinks all the files are outdated. I did notice 'fetch' updates the index (well, mtime of .git/index changes, I didn't look at index content yet), so maybe fetch isn't quite a red herring. I'll try to eliminate this variable as well. -- Dennis Kaarsemaker www.kaarsemaker.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git rerere is confused with identical conflicts in multiple files
Hi, (Please keep me on CC as I am not subscribed to the list) I am having a weird problem when merging a branch which causes some conflicts This is the initial status for the rerere cache $ tree .git/rr-cache .git/rr-cache [error opening dir] 0 directories, 0 files I then go ahead and merge the said branch and I end up with the following conflicts Auto-merging arch/mips/mm/sc-mips.c Auto-merging arch/mips/mm/c-r4k.c CONFLICT (content): Merge conflict in arch/mips/mm/c-r4k.c Auto-merging arch/mips/kernel/traps.c CONFLICT (content): Merge conflict in arch/mips/kernel/traps.c Auto-merging arch/mips/kernel/spram.c CONFLICT (content): Merge conflict in arch/mips/kernel/spram.c Auto-merging arch/mips/kernel/idle.c CONFLICT (content): Merge conflict in arch/mips/kernel/idle.c Auto-merging arch/mips/kernel/cpu-probe.c Auto-merging arch/mips/include/asm/mipsregs.h Auto-merging arch/mips/include/asm/cpu.h CONFLICT (content): Merge conflict in arch/mips/include/asm/cpu.h Auto-merging arch/mips/include/asm/cpu-type.h CONFLICT (content): Merge conflict in arch/mips/include/asm/cpu-type.h Recorded preimage for 'arch/mips/include/asm/cpu-type.h' Recorded preimage for 'arch/mips/include/asm/cpu.h' Automatic merge failed; fix conflicts and then commit the result. As you see, git only records two preimage files instead of 6. the rr-cache is like this now $ tree .git/rr-cache .git/rr-cache ├── 5563edc0fb427275a0ca5677c93c40def8b53258 │ └── preimage └── f175ff6228f624296b661664bce4ab4e84d712cc └── preimage 2 directories, 2 files and .git/MERGE_RR $ cat .git/MERGE_RR 5563edc0fb427275a0ca5677c93c40def8b53258 arch/mips/include/asm/cpu-type.hf175ff6228f624296b661664bce4ab4e84d712cc arch/mips/include/asm/cpu.h5563edc0fb427275a0ca5677c93c40def8b53258 arch/mips/kernel/idle.c5563edc0fb427275a0ca5677c93c40def8b53258 arch/mips/kernel/spram.c5563edc0fb427275a0ca5677c93c40def8b53258 arch/mips/kernel/traps.c5563edc0fb427275a0ca5677c93c40def8b53258 arch/mips/mm/c-r4k.c so as you see, multiple files share the same hash. That's probably because the "conflicting context ( the part between >>> )" in every file but cpu.h is identical and git seems to calculate the hash purely on the conflicting context. That makes git rerere thinks that it only has to resolve 2 conflicts instead of 6. Does anyone have an idea how to resolve that? If my assumption is correct (I only looked at the git code briefly) I believe it would make sense to throw the filepath into the sha1 calculation as well in order to ensure it will not conflict with similar changes across different files. -- markos -- To unsubscribe from this list: send the line "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] Documentation clarification on git-checkout regarding ours/theirs
From: "Simon A. Eugster"
Signed-off-by: Simon A. Eugster
---
Documentation/git-checkout.txt | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a56..d69306f 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -115,7 +115,21 @@ entries; instead, unmerged entries are ignored.
--ours::
--theirs::
When checking out paths from the index, check out stage #2
- ('ours') or #3 ('theirs') for unmerged paths.
+ ('ours', HEAD) or #3 ('theirs', MERGE_HEAD) for unmerged paths.
+ See linkgit:git-merge[1] for details about stages #2 and #3.
++
+Note that during `git rebase` and `git pull --rebase`, 'theirs' checks out
+the local version, and 'ours' the remote version or the history that is rebased
+against.
++
+The reason ours/theirs appear to be swapped during a rebase is that we
+define the remote history as the canonical history, on top of which our
+private commits are applied on, as opposed to normal merging where the
+local history is the canonical one.
+During merging, we assume the role of the canonical history’s keeper,
+which, in case of a rebase, is the remote history, and our private commits
+look to the keeper as “their” commits which need to be integrated on top
+of “our” work.
-b ::
Create a new branch named and start it at
--
1.8.5.1
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] notes: Allow treeish expressions as notes ref
init_notes() is the main point of entry to the notes API. It is an arbitrary
restriction that all it allows as input is a strict ref name, when callers
may want to give an arbitrary treeish.
However, some operations that require updating the notes tree require a
strict ref name, because they wouldn't be able to update e.g. foo@{1}.
So we allow treeish expressions to be used in the case the notes tree is
going to be used without write "permissions", and to distinguish whether
the notes tree is intended to be used for reads only, or will be updated,
a flag is added.
This has the side effect of enabling the use of treeish as notes refs in
commands allowing them, e.g. git log --notes=foo@{1}.
Signed-off-by: Mike Hommey
---
builtin/notes.c | 29 -
notes-cache.c| 11 ++-
notes-utils.c| 6 +++---
notes.c | 11 +++
notes.h | 10 +-
t/t3301-notes.sh | 10 ++
6 files changed, 51 insertions(+), 26 deletions(-)
diff --git a/builtin/notes.c b/builtin/notes.c
index 63f95fc..0fc6e7a 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -285,7 +285,7 @@ static int notes_copy_from_stdin(int force, const char
*rewrite_cmd)
if (!c)
return 0;
} else {
- init_notes(NULL, NULL, NULL, 0);
+ init_notes(NULL, NULL, NULL, NOTES_INIT_WRITABLE);
t = &default_notes_tree;
}
@@ -328,15 +328,18 @@ static int notes_copy_from_stdin(int force, const char
*rewrite_cmd)
return ret;
}
-static struct notes_tree *init_notes_check(const char *subcommand)
+static struct notes_tree *init_notes_check(const char *subcommand,
+ int flags)
{
struct notes_tree *t;
- init_notes(NULL, NULL, NULL, 0);
+ const char *ref;
+ init_notes(NULL, NULL, NULL, flags);
t = &default_notes_tree;
- if (!starts_with(t->ref, "refs/notes/"))
+ ref = (flags & NOTES_INIT_WRITABLE) ? t->update_ref : t->ref;
+ if (!starts_with(ref, "refs/notes/"))
die("Refusing to %s notes in %s (outside of refs/notes/)",
- subcommand, t->ref);
+ subcommand, ref);
return t;
}
@@ -359,7 +362,7 @@ static int list(int argc, const char **argv, const char
*prefix)
usage_with_options(git_notes_list_usage, options);
}
- t = init_notes_check("list");
+ t = init_notes_check("list", 0);
if (argc) {
if (get_sha1(argv[0], object))
die(_("Failed to resolve '%s' as a valid ref."),
argv[0]);
@@ -419,7 +422,7 @@ static int add(int argc, const char **argv, const char
*prefix)
if (get_sha1(object_ref, object))
die(_("Failed to resolve '%s' as a valid ref."), object_ref);
- t = init_notes_check("add");
+ t = init_notes_check("add", NOTES_INIT_WRITABLE);
note = get_note(t, object);
if (note) {
@@ -510,7 +513,7 @@ static int copy(int argc, const char **argv, const char
*prefix)
if (get_sha1(object_ref, object))
die(_("Failed to resolve '%s' as a valid ref."), object_ref);
- t = init_notes_check("copy");
+ t = init_notes_check("copy", NOTES_INIT_WRITABLE);
note = get_note(t, object);
if (note) {
@@ -588,7 +591,7 @@ static int append_edit(int argc, const char **argv, const
char *prefix)
if (get_sha1(object_ref, object))
die(_("Failed to resolve '%s' as a valid ref."), object_ref);
- t = init_notes_check(argv[0]);
+ t = init_notes_check(argv[0], NOTES_INIT_WRITABLE);
note = get_note(t, object);
prepare_note_data(object, &d, edit ? note : NULL);
@@ -651,7 +654,7 @@ static int show(int argc, const char **argv, const char
*prefix)
if (get_sha1(object_ref, object))
die(_("Failed to resolve '%s' as a valid ref."), object_ref);
- t = init_notes_check("show");
+ t = init_notes_check("show", 0);
note = get_note(t, object);
if (!note)
@@ -812,7 +815,7 @@ static int merge(int argc, const char **argv, const char
*prefix)
}
}
- t = init_notes_check("merge");
+ t = init_notes_check("merge", NOTES_INIT_WRITABLE);
strbuf_addf(&msg, "notes: Merged notes from %s into %s",
remote_ref.buf, default_notes_ref());
@@ -878,7 +881,7 @@ static int remove_cmd(int argc, const char **argv, const
char *prefix)
argc = parse_options(argc, argv, prefix, options,
git_notes_remove_usage, 0);
- t = init_notes_check("remove");
+ t = init_notes_check("remove", NOTES_INIT_WRITABLE);
if (!argc && !from_stdin) {
retval = remove_one_note(t, "HEAD", flag);
@@ -920,7 +923,7 @@ static int prune(int argc, const char **argv, const char
*prefix)
Re: [PATCH v2 08/10] tag.c: use 'ref-filter' APIs
On Thu, Jul 9, 2015 at 7:13 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> If anyone can help, this is what it's saying. >> "[Net::SMTP::SSL] Connection closed at > > Perhaps your SMTP server thought you were sending too many emails to too > many people and closed the connection thinking you were a spammer. > > If you're having this kind of issues, it may make sense to run > "format-patch" and "send-email" as two separate steps. This way, you can > re-run "send-email" on the pieces which failed manually (adjusting > --in-reply-to). > I'm guessing the same. That's what I usually do, separate format-patch and send-email. >Spaces around +. Thanks :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] ident: support per-path configs by matching the path against a pattern
Support per-path identities by configuring Git like
$ git config user..email
e.g.
$ git config user.github.email sschuberth+git...@gmail.com
In this example, the middle "github" pattern is searched for
case-insensitively in the absolute path name to the current git work tree.
If there is a match the configured email address is used instead of what
otherwise would be the default email address.
Note that repository-local identities still take precedence over global /
system ones even if the pattern configured in the global / system identity
matches the path to the local work tree.
This change avoids the need to use external tools like [1].
TODO: Once the community agrees that this is a feature worth having, add
tests and adjust the docs.
[1] https://github.com/prydonius/karn
Signed-off-by: Sebastian Schuberth
---
ident.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/ident.c b/ident.c
index 5ff1aad..2429ed8 100644
--- a/ident.c
+++ b/ident.c
@@ -390,7 +390,21 @@ int author_ident_sufficiently_given(void)
int git_ident_config(const char *var, const char *value, void *data)
{
- if (!strcmp(var, "user.name")) {
+ /* the caller has already checked that var starts with "user." */
+
+ const char *first_period = strchr(var, '.');
+ const char *last_period = strrchr(var, '.');
+
+ if (first_period < last_period) {
+ ++first_period;
+ char *pattern = xstrndup(first_period, last_period -
first_period);
+ const char *match = strcasestr(get_git_work_tree(), pattern);
+ free(pattern);
+ if (!match)
+ return 0;
+ }
+
+ if (ends_with(var, ".name")) {
if (!value)
return config_error_nonbool(var);
strbuf_reset(&git_default_name);
@@ -400,7 +414,7 @@ int git_ident_config(const char *var, const char *value,
void *data)
return 0;
}
- if (!strcmp(var, "user.email")) {
+ if (ends_with(var, ".email")) {
if (!value)
return config_error_nonbool(var);
strbuf_reset(&git_default_email);
---
https://github.com/git/git/pull/161
--
To unsubscribe from this list: send the line "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 03/10] ref-filter: support printing N lines from tag annotation
On Thu, Jul 9, 2015 at 6:37 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> In 'tag.c' we can print N lines from the annotation of the tag
>> using the '-n' option.
>
> Not only annotation of the tag, but also from the commit message for
> lightweight tags.
will do.
>
>> --- a/builtin/tag.c
>> +++ b/builtin/tag.c
>> @@ -185,6 +185,10 @@ static enum contains_result contains(struct commit
>> *candidate,
>> return contains_test(candidate, want);
>> }
>>
>> +/*
>> + * Currently dupplicated in ref-filter, will eventually be removed as
>
> dupplicated -> duplicated.
>
Thanks :)
>> --- a/ref-filter.h
>> +++ b/ref-filter.h
>> @@ -55,6 +55,7 @@ struct ref_filter {
>> struct commit *merge_commit;
>>
>> unsigned int with_commit_tag_algo : 1;
>> + unsigned int lines;
>> };
>>
>> struct ref_filter_cbdata {
>> @@ -87,7 +88,7 @@ int verify_ref_format(const char *format);
>> /* Sort the given ref_array as per the ref_sorting provided */
>> void ref_array_sort(struct ref_sorting *sort, struct ref_array *array);
>> /* Print the ref using the given format and quote_style */
>> -void show_ref_array_item(struct ref_array_item *info, const char *format,
>> int quote_style);
>> +void show_ref_array_item(struct ref_array_item *info, const char *format,
>> int quote_style, unsigned int lines);
>
> I would add "If lines > 0, prints the first 'lines' no of lines of the
> object pointed to" or so to the docstring.
>
Will do, thanks.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Combined diff with name-only option
Hello, When I run: git diff-tree --cc 511f273b99af4529f6eb30069bb9070dc73fbbb4 As expected, I get the diff for the files that are changed in both parents. When I run: git diff-tree --cc --name-only 511f273b99af4529f6eb30069bb9070dc73fbbb4 I get all the files listed including ones that are changed only in one parent. I would expect to see only names of the files changed in both parents like in the case when --name-only parameter was not present. Is it a bug or is it done by design? BR, Janusz. -- To unsubscribe from this list: send the line "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 04/10] ref-filter: add support to sort by version
On Thu, Jul 9, 2015 at 6:59 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> Add support to sort by version using the "v:refname" and >> "version:refname" option. This is achieved by using the >> 'version_cmp()' function as the comparing function for qsort. > > You should elaborate on why you need this. Given the context, I can > guess that you will need this to implement tag, but for example I first > wondered why you needed both version: and v:, but I guess it comes from > the fact that 'git tag --sort' can take version:refname or v:refname. > > I think this deserves a test and documentation in for-each-ref.txt. I'll add it to "for-each-ref.txt" documentation. About the tests, there are already tests for the same in git-tag.txt and that's the only reason I did not repeat the tests in for-each-ref. > > As-is, the code is a bit hard to understand. I first saw you were > allowing > > git for-each-ref --format '%(version:refname)' > > (which you are, but only as a side effect), and then understood that > this was also allowing > > git for-each-ref --sort version:refname > > A test would have shown me this immediately. Some hints in the commit > message would clearly have helped too. > Most of the sorting options have side effects in "--format", but yeah will add details in the commit message. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "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 04/10] ref-filter: add support to sort by version
On Fri, Jul 10, 2015 at 4:22 PM, Karthik Nayak wrote: > On Thu, Jul 9, 2015 at 6:59 PM, Matthieu Moy > wrote: >> Karthik Nayak writes: >> >>> Add support to sort by version using the "v:refname" and >>> "version:refname" option. This is achieved by using the >>> 'version_cmp()' function as the comparing function for qsort. >> >> You should elaborate on why you need this. Given the context, I can >> guess that you will need this to implement tag, but for example I first >> wondered why you needed both version: and v:, but I guess it comes from >> the fact that 'git tag --sort' can take version:refname or v:refname. >> >> I think this deserves a test and documentation in for-each-ref.txt. > > I'll add it to "for-each-ref.txt" documentation. > About the tests, there are already tests for the same in git-tag.txt and > that's the only reason I did not repeat the tests in for-each-ref. > But since the porting is in a later commit, will add tests to for-each-ref. >> >> As-is, the code is a bit hard to understand. I first saw you were >> allowing >> >> git for-each-ref --format '%(version:refname)' >> >> (which you are, but only as a side effect), and then understood that >> this was also allowing >> >> git for-each-ref --sort version:refname >> >> A test would have shown me this immediately. Some hints in the commit >> message would clearly have helped too. >> > > Most of the sorting options have side effects in "--format", but yeah will add > details in the commit message. > > -- > Regards, > Karthik Nayak -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "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 05/10] ref-filter: add option to match literal pattern
On Thu, Jul 9, 2015 at 7:02 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> Since 'ref-filter' only has an option to match path names >> add an option for regular pattern matching. > > Here also, a hint on why this is needed would be welcome. > Will add. >> --- a/ref-filter.c >> +++ b/ref-filter.c >> @@ -956,6 +956,20 @@ static int commit_contains(struct ref_filter *filter, >> struct commit *commit) >> >> /* >> * Return 1 if the refname matches one of the patterns, otherwise 0. >> + * A pattern can be a literal prefix (e.g. a refname "refs/heads/master" >> + * matches a pattern "refs/heads/m") or a wildcard (e.g. the same ref >> + * matches "refs/heads/m*",too). > > Missing space after , (same in the hunk context below) > Noted. Thanks :) -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "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 04/10] ref-filter: add support to sort by version
Karthik Nayak writes: > On Fri, Jul 10, 2015 at 4:22 PM, Karthik Nayak wrote: >> On Thu, Jul 9, 2015 at 6:59 PM, Matthieu Moy >> wrote: >>> Karthik Nayak writes: >>> Add support to sort by version using the "v:refname" and "version:refname" option. This is achieved by using the 'version_cmp()' function as the comparing function for qsort. >>> >>> You should elaborate on why you need this. Given the context, I can >>> guess that you will need this to implement tag, but for example I first >>> wondered why you needed both version: and v:, but I guess it comes from >>> the fact that 'git tag --sort' can take version:refname or v:refname. >>> >>> I think this deserves a test and documentation in for-each-ref.txt. >> >> I'll add it to "for-each-ref.txt" documentation. >> About the tests, there are already tests for the same in git-tag.txt and >> that's the only reason I did not repeat the tests in for-each-ref. >> > > But since the porting is in a later commit, will add tests to for-each-ref. Yes: to me "it's tested through 'git tag'" is a good argument to do only a superficial test, check that 'for-each-ref --sort v:refname' activate the sorting, but no detailed corner-case testing. But not a good argument to have no test at all on for-each-ref. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rerere is confused with identical conflicts in multiple files
Markos Chandras writes:
> $ cat .git/MERGE_RR
> 5563edc0fb427275a0ca5677c93c40def8b53258
> arch/mips/include/asm/cpu-type.hf175ff6228f624296b661664bce4ab4e84d712cc
>
> arch/mips/include/asm/cpu.h5563edc0fb427275a0ca5677c93c40def8b53258
>arch/mips/kernel/idle.c5563edc0fb427275a0ca5677c93c40def8b53258
> arch/mips/kernel/spram.c5563edc0fb427275a0ca5677c93c40def8b53258
> arch/mips/kernel/traps.c5563edc0fb427275a0ca5677c93c40def8b53258
> arch/mips/mm/c-r4k.c
>
> so as you see, multiple files share the same hash. That's probably
> because the "conflicting context ( the part between >>> )" in every
> file but cpu.h is identical and git seems to calculate the hash purely
> on the conflicting context. That makes git rerere thinks that it only
> has to resolve 2 conflicts instead of 6.
Yes, that is by design, and should not change. The thing is, you do
want to share the same resolution across files, regardless of the
path, when the recorded resolution replays cleanly [*1*].
> Does anyone have an idea how to resolve that? If my assumption is
> correct (I only looked at the git code briefly) I believe it would make
> sense to throw the filepath into the sha1 calculation as well in order
> to ensure it will not conflict with similar changes across different files.
Interesting coincidence, but I have been looking at this for the
past few weeks myself but when you are doing the maintainer of a
reasonably active project, time for your own development is hard
to come by X-<.
My current plan is to allow hashing exactly the same way, but
recording different preimage/postimage pairs as necessary.
Right now we do something like this:
- See conflict; compute conflict ID.
- Does rr-cache/$ID/ exist?
- If not, record rr-cache/$ID/preimage
- Add $ID to MERGE_RR.
And then for each $ID (and path) in MERGE_RR:
- Does rr-cache/$ID/postimage exist?
- If so, attempt three-way merge using preimage, postimage and
thisimage.
- Did three-way merge replay cleanly? If so, be happy.
- Did three-way merge conflict? If so, punt.
- Does path still have conflicts?
- If not, record rr-cache/$ID/postimage.
The thing to fix is "did it conflict, if so punt" step. Within the
same conflict ID, we would introduce the concept of "variant", and
allow you to keep rr_cache/$ID/{preimage,postimage}.$variant. The
first part of the per MERGE_RR entry process would instead go like
so:
- Does rr-cache/$ID/ has one or more postimages?
- If so, for each variant, attempt three-way merge using
preimage, postimage and thisimage.
- Did one of the three-way merges replay cleanly?
- If so, be happy.
- If not, assign an unused variant to this path and change
its MERGE_RR entry from $ID to $ID.$variant
- Does path still have conflicts?
- If not, record rr-cache/$ID/postimage for "variant".
The current "preimage", "postimage" will be kept as the first
variant in rr-cache/$ID/ directory. The second variant will likely
be named (I don't have a code yet but have been slowly laying out
the fundation to allow us to do this) "preimage.0" and "postimage.0",
and the third one will have ".1" suffix.
This approach has the added benefit that existing rr-cache entries
will stay valid (in addition to being able to replay the same
resolution even after you renamed the path that conflict, unlike the
case when you hashed the pathname together to break the conflict ID
computtion).
A WIP has been published on jc/rerere topic in my repository for the
past few weeks, but I haven't reached the interesting "multi variant"
part yet, as I said.
[Footnote]
*1* My experience urges me to add "And most of the time, the same
resolution does apply cleanly even to multiple paths conflicted in
the same merge" to that sentence.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ident: support per-path configs by matching the path against a pattern
Sebastian Schuberth writes: > Support per-path identities by configuring Git like > > $ git config user..email > > e.g. > > $ git config user.github.email sschuberth+git...@gmail.com > > In this example, the middle "github" pattern is searched for > case-insensitively in the absolute path name to the current git work tree. I do agree it is a good feature to have to allow you to keep a centralized registry of possible configuration in a single place, e.g. $HOME/.gitconfig, and selectively apply pieces for multiple places. Having said that, a few comments. - It feels very hacky to only do this for the ident. You would want to have, (conceptually, not necessarily at the syntax level) something more along the lines of: if path matches this pattern [user] email = address name = name end to allow any configuration to be covered by this new "selectively use from the centralized registry" feature. - It is iffy to match the pattern with "working tree". There are pros and cons but a viable alternative would be to match with the location of the $GIT_DIR. Given that we now are slowly moving to a world where a single $GIT_DIR can have multiple working trees, and that user.name ultimately matters per-project you are contributing to, it is more likely that you would want to tie it to a local repository, i.e. $GIT_DIR, no matter where working trees you have a checkout out of that repository live. They would want to share the same setting. On the other hand, some things may be truly per working tree even if it is tied to the same local repository. I am not saying it is better to tie this to $GIT_DIR not $GIT_WORK_TREE. I am not necessarily saying we should support both. I am only saying that we need to consider if tying only to $GIT_WORK_TREE makes sense (and if so, clearly communicate that to the end users). I couldn't read from your patch [*1*] what your stance on this point. - The pattern defined to be case-insensitive substring would not be a sane general design. I would have expected it to be fnmatch pattern that may match case insensitively only on case insensitive filesystems. [Footnote] *1* this is one of the reasons why I usually ignore "I'll do the doc and test if people agree it is a good idea." Often, we cannot judge if it is a good idea without these things. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rerere is confused with identical conflicts in multiple files
Hi,
On 07/10/2015 03:13 PM, Junio C Hamano wrote:
> Markos Chandras writes:
>
>> $ cat .git/MERGE_RR
>> 5563edc0fb427275a0ca5677c93c40def8b53258
>> arch/mips/include/asm/cpu-type.hf175ff6228f624296b661664bce4ab4e84d712cc
>>
>> arch/mips/include/asm/cpu.h5563edc0fb427275a0ca5677c93c40def8b53258
>>arch/mips/kernel/idle.c5563edc0fb427275a0ca5677c93c40def8b53258
>> arch/mips/kernel/spram.c5563edc0fb427275a0ca5677c93c40def8b53258
>> arch/mips/kernel/traps.c5563edc0fb427275a0ca5677c93c40def8b53258
>> arch/mips/mm/c-r4k.c
>>
>> so as you see, multiple files share the same hash. That's probably
>> because the "conflicting context ( the part between >>> )" in every
>> file but cpu.h is identical and git seems to calculate the hash purely
>> on the conflicting context. That makes git rerere thinks that it only
>> has to resolve 2 conflicts instead of 6.
>
> Yes, that is by design, and should not change. The thing is, you do
> want to share the same resolution across files, regardless of the
> path, when the recorded resolution replays cleanly [*1*].
I see.
> [...]
>
> The thing to fix is "did it conflict, if so punt" step. Within the
> same conflict ID, we would introduce the concept of "variant", and
> allow you to keep rr_cache/$ID/{preimage,postimage}.$variant. The
> first part of the per MERGE_RR entry process would instead go like
> so:
>
> - Does rr-cache/$ID/ has one or more postimages?
> - If so, for each variant, attempt three-way merge using
> preimage, postimage and thisimage.
> - Did one of the three-way merges replay cleanly?
> - If so, be happy.
> - If not, assign an unused variant to this path and change
> its MERGE_RR entry from $ID to $ID.$variant
>
> - Does path still have conflicts?
> - If not, record rr-cache/$ID/postimage for "variant".
>
> The current "preimage", "postimage" will be kept as the first
> variant in rr-cache/$ID/ directory. The second variant will likely
> be named (I don't have a code yet but have been slowly laying out
> the fundation to allow us to do this) "preimage.0" and "postimage.0",
> and the third one will have ".1" suffix.
>
> This approach has the added benefit that existing rr-cache entries
> will stay valid (in addition to being able to replay the same
> resolution even after you renamed the path that conflict, unlike the
> case when you hashed the pathname together to break the conflict ID
> computtion).
I understand. Thanks for the explanation.
>
> A WIP has been published on jc/rerere topic in my repository for the
> past few weeks, but I haven't reached the interesting "multi variant"
> part yet, as I said.
I am happy to test it when you have something more complete. If you can
reply to this e-mail when the 'variant' patch finds its way into the
master branch that would be great as well
--
markos
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ident: support per-path configs by matching the path against a pattern
On Fri, Jul 10, 2015 at 08:10:54AM -0700, Junio C Hamano wrote:
> I do agree it is a good feature to have to allow you to keep a
> centralized registry of possible configuration in a single place,
> e.g. $HOME/.gitconfig, and selectively apply pieces for multiple
> places.
>
> Having said that, a few comments.
>
> - It feels very hacky to only do this for the ident. You would
>want to have, (conceptually, not necessarily at the syntax level)
>something more along the lines of:
>
> if path matches this pattern
> [user]
> email = address
> name = name
> end
>
>to allow any configuration to be covered by this new "selectively
>use from the centralized registry" feature.
Yeah, I agree it would be nice to cover all config keys. Since it's
syntactically difficult to add conditionals to the existing config
format, I tried to leave open a space for this in the "include" design.
That is, right now:
[include]
path = foo
will unconditionally include "foo". But something like:
[include "gitdir:bar"]
path = foo
could do so only when the "gitdir:bar" conditional is satisfied (where
that is just a syntax I made up to mean fnmatch("bar", $GIT_DIR)). So
like user..*, we still put our section-specific hack into one
special section, but that one place is capable of chaining to multiple
other config keys. :)
My only request is that any conditional we add have some prefix (like
"gitdir:") so that we have space to add more types later if we choose.
There's discussion on this topic somewhere on the list, but I didn't
bother to dig it up. I don't think it adds anything over what I
summarized above.
-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 01/10] ref-filter: add %(refname:shortalign=X) option
Karthik Nayak writes:
> Add support for %(refname:shortalign=X) where X is a number.
> This will print a shortened refname aligned to the left
> followed by spaces for a total length of X characters.
> If X is less than the shortened refname size, the entire
> shortened refname is printed.
>
> Mentored-by: Christian Couder
> Mentored-by: Matthieu Moy
> Signed-off-by: Karthik Nayak
> ---
> ref-filter.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
This may be enough to support the various existing formats that are
offered by "git branch" and/or "git tag", but I do not think if this
is the right approach in the longer term, or if we are painting
ourselves in a corner we cannot cleanly get out of later [*1*].
Will the "refname" stay to be the only thing that may want alignment
padding appended in the future? Will it stay true that we want to
align only to the left? Etc., etc.
Cc'ed Duy as %< in the pretty-format was his invention at around
a5752342 (pretty: support padding placeholders, %< %> and %><,
2013-04-19).
> diff --git a/ref-filter.c b/ref-filter.c
> index dd0709d..3098497 100644
> --- a/ref-filter.c
> +++ b/ref-filter.c
> @@ -10,6 +10,7 @@
> #include "quote.h"
> #include "ref-filter.h"
> #include "revision.h"
> +#include "utf8.h"
>
> typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
>
> @@ -695,7 +696,23 @@ static void populate_value(struct ref_array_item *ref)
> int num_ours, num_theirs;
>
> formatp++;
> - if (!strcmp(formatp, "short"))
> + if (starts_with(formatp, "shortalign=")) {
When adding a new thing to an existing list, we prefer to append it
at the end of the list, if there is no other reason not to do so
(e.g. "the existing list is sorted in this order, and the new
location was chosen to fit the new item to honor the existing
ordering rule" is a valid reason to put it at the beginning, if the
existing sorting rule dictates that the new thing must come at the
beginning).
> + const char *valp, *short_refname = NULL;
> + int val, len;
> +
> + skip_prefix(formatp, "shortalign=", &valp);
> + val = atoi(valp);
In newer code, we would want to avoid atoi() so that "foo:shortalign=1z"
that is a typo of "12" can be caught as an error. Either strtol_i()
or strtoul_ui() may be better (we would need to adjust it further
when Michael decides to resurrect his numparse thing that has been
in the stalled bin for quite a while, though).
> + refname = short_refname =
> shorten_unambiguous_ref(refname,
> +
> warn_ambiguous_refs);
> + len = utf8_strwidth(refname);
> + if (val > len) {
> + struct strbuf buf = STRBUF_INIT;
> + strbuf_addstr(&buf, refname);
> + strbuf_addchars(&buf, ' ', val - len);
> + free((char *)short_refname);
> + refname = strbuf_detach(&buf, NULL);
> + }
What should happen when the display column width of the string is
wider? If a user wants to align the refs that are usually usually
short start the next thing at the 8th column, which should she use?
"%(refname:shorta=7) %(next item)"
"%(refname:shorta=8)%(next item)"
> + } else if (!strcmp(formatp, "short"))
> refname = shorten_unambiguous_ref(refname,
> warn_ambiguous_refs);
> else if (!strcmp(formatp, "track") &&
--
To unsubscribe from this list: send the line "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 05/10] ref-filter: add option to match literal pattern
Karthik Nayak writes: > Since 'ref-filter' only has an option to match path names > add an option for regular pattern matching. There is nothing "regular" about the pattern matching you are adding. Everywhere else we use patterns on refs we call wildmatch(), which is an enhanced implementation of fnmatch(3), and you are doing the same in this new codepath. Just drop that word from here (and if you said something similar in the documentation, drop "regular" ffrom there as well). It would invite confusion with regular expression matching, which we will not do for refs. -- To unsubscribe from this list: send the line "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 06/10] Documentation/tag: remove double occurance of ""
Christian Couder writes: > On Thu, Jul 9, 2015 at 12:27 PM, Karthik Nayak wrote: >> Mentored-by: Christian Couder >> Mentored-by: Matthieu Moy >> Signed-off-by: Karthik Nayak >> --- >> Documentation/git-tag.txt | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt >> index 034d10d..4b04c2b 100644 >> --- a/Documentation/git-tag.txt >> +++ b/Documentation/git-tag.txt >> @@ -14,7 +14,6 @@ SYNOPSIS >> 'git tag' -d ... >> 'git tag' [-n[]] -l [--contains ] [--points-at ] >> [--column[=] | --no-column] [...] >> - [...] >> 'git tag' -v ... > > As this patch could be applied directly to master and to maint maybe > you could send it at the top of this patch series or alone outside of > this patch series. Thanks. I'll pick this patch from the remainder of the series and queue it on a separate topic. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ident: support per-path configs by matching the path against a pattern
On Fri, Jul 10, 2015 at 11:43:08AM -0400, Jeff King wrote:
> But something like:
>
> [include "gitdir:bar"]
> path = foo
>
> could do so only when the "gitdir:bar" conditional is satisfied (where
> that is just a syntax I made up to mean fnmatch("bar", $GIT_DIR)). So
> like user..*, we still put our section-specific hack into one
> special section, but that one place is capable of chaining to multiple
> other config keys. :)
Here's a sketch if anybody is inclined to pick it up and run with it.
Note that I did not think too hard about little things like the
de-anchoring.
---
diff --git a/config.c b/config.c
index 29fa012..47b01f0 100644
--- a/config.c
+++ b/config.c
@@ -139,9 +139,45 @@ static int handle_path_include(const char *path, struct
config_include_data *inc
return ret;
}
+static int include_condition_is_true(const char *cond, int cond_len)
+{
+ const char *value;
+
+ /* no condition (i.e., "include.path") is always true */
+ if (!cond)
+ return 1;
+
+ /*
+* It's OK to run over cond_len in our checks here, as that just pushes
+* us past the final ".", which cannot match any of our prefixes.
+*/
+ if (skip_prefix(cond, "gitdir:", &value)) {
+ struct strbuf text = STRBUF_INIT;
+ struct strbuf pattern = STRBUF_INIT;
+ int ret;
+
+ strbuf_add_absolute_path(&text, get_git_dir());
+
+ /* de-anchor match for convenience */
+ strbuf_addstr(&pattern, "**");
+ strbuf_add(&pattern, value, cond_len - (value - cond));
+ strbuf_addstr(&pattern, "**");
+
+ ret = !wildmatch(pattern.buf, text.buf, 0, NULL);
+ strbuf_release(&pattern);
+ strbuf_release(&text);
+ return ret;
+ }
+
+ /* unknown conditionals are always false */
+ return 0;
+}
+
int git_config_include(const char *var, const char *value, void *data)
{
struct config_include_data *inc = data;
+ const char *cond, *key;
+ int cond_len;
int ret;
/*
@@ -152,8 +188,12 @@ int git_config_include(const char *var, const char *value,
void *data)
if (ret < 0)
return ret;
- if (!strcmp(var, "include.path"))
- ret = handle_path_include(value, inc);
+ if (!parse_config_key(var, "include", &cond, &cond_len, &key) &&
+ include_condition_is_true(cond, cond_len)) {
+ if (!strcmp(key, "path"))
+ ret = handle_path_include(value, inc);
+ /* else we do not know about this type of include; ignore */
+ }
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 0/7] ref backend preamble
From: "David Turner" The current state of the discussion on alternate ref backends is that we're going to continue to store pseudorefs (e.g. CHERRY_PICK_HEAD) as Assuming this is accepted, should the definition of pseudorefs be included in the gitglossary? Once ref backends become common, the distinction will needed in the docs. files in $GIT_DIR. So this re-roll of the refs backend preamble doesn't do anything to pseudorefs. It just does reflog stuff. -- 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 v8 0/7] ref backend preamble
On Fri, 2015-07-10 at 15:34 +0100, Philip Oakley wrote: > From: "David Turner" > > The current state of the discussion on alternate ref backends is that > > we're going to continue to store pseudorefs (e.g. CHERRY_PICK_HEAD) as > > Assuming this is accepted, should the definition of pseudorefs be > included in the gitglossary? > > Once ref backends become common, the distinction will needed in the > docs. This term is only in this message (that is, I don't think I used it in any commit messages yet). The code uses it in at least one place already. But yes, I think if we decided to go with the pseudoref concept, we should document 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: Combined diff with name-only option
Janusz Białobrzewski writes: > Is it a bug or is it done by design? I suspect the answer is "no and not really". The truth would be closer to: we didn't bother to write code in the command line parser to check and flag it as an error when "--cc" and "--name-only" is given together. Unlike "-c" that works solely on the tree level changes, "--cc" looks into blob contents involved in the merge, but things like "--name-status", etc., do not work at blob levels (you can consider that part is "by design"). Similarly, if you make a whitespace-only change to a file and use git diff-tree -b -p you will still see the name of the commit object, but no patch. git diff-tree -b --name-only still reports the modified paths as tree-level differences. -- To unsubscribe from this list: send the line "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 v4] log: add log.follow config option
On Thu, 2015-07-09 at 10:58 -0700, Junio C Hamano wrote: > David Turner writes: > > > On Thu, 2015-07-09 at 10:23 -0700, Junio C Hamano wrote: > > > >> If I were David and sending this v4 patch, it would have looked like > >> this. > >> > >> -- >8 -- > >> > >> From: David Turner > >> Date: Tue, 7 Jul 2015 21:29:34 -0400 > >> Subject: [PATCH v4] log: add "log.follow" configuration variable > >> > >> People who work on projects with mostly linear history with frequent > >> whole file renames may want to always use "git log --follow" when > >> inspecting the life of the content that live in a single path. > >> > >> Teach the command to behave as if "--follow" was given from the > >> command line when log.follow configuration variable is set *and* > >> there is one (and only one) path on the command line. > > > > > > Thanks. That version is much better. > > No, thank _you_; we should be thanking you for helping us improve > the system ;-) Do I need to re-send, or will you queue your version? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 2/8] cherry-pick: treat CHERRY_PICK_HEAD and REVERT_HEAD as refs
On Fri, 2015-07-10 at 06:30 +0200, Michael Haggerty wrote: > On 07/10/2015 12:06 AM, Junio C Hamano wrote: > > David Turner writes: > > > >> OK, here's my current best idea: > >> > >> 1. A "pseudoref" is an all-caps file in $GIT_DIR/ that always contains > >> at least a SHA1. CHERRY_PICK_HEAD and REVERT_HEAD are examples. Because > >> HEAD might be a symbolic ref, it is not a pseudoref. > >> > >> Refs backends do not manage pseudorefs. Instead, when a pseudoref (an > >> all-caps ref containing no slashes) is requested (e.g. git rev-parse > >> FETCH_HEAD) the generic refs code checks for the existence of that > >> file and if it exists, returns immediately without hitting the backend. > >> The generic code will refuse to allow updates to pseudorefs. > >> > >> 2. The pluggable refs backend manages all refs other than HEAD. > >> > >> 3. The "files" backend always manages HEAD. This allows for a reflog > >> and for HEAD to be a symbolic ref. > >> > >> The major complication here is ref transactions -- what if there's a > >> transaction that wants to update e.g. both HEAD and refs/heads/master? > > > > An update to the current branch (e.g. "git commit") does involve at > > least update to the reflog of HEAD, the current branch somewhere in > > refs/heads/ and its log, so it is not "what if" but is a norm [*1*]. > > The updating of symlink reflogs in general, and particularly that of > HEAD, is not done very cleanly. You can see the code in > `commit_ref_update()` (some of it helpfully commented to be a "Special > hack"): > > * If a reference is modified through a symlink, the symlink is locked > rather than the reference itself. > * If a reference is modified directly, and HEAD points at it, then the > HEAD reflog is amended without locking HEAD. > > Aside from the lack of proper locking, which could result in races with > other processes, we also have the problem that the same reference that > is being changed via one of these implicit updates could *also* be being > changed directly in the same transaction. Such an update would evade the > `ref_update_reject_duplicates()` check. > > Previously my thinking was that the locking should be done differently: > when the transaction is being processed, extra ref_update records could > be created for the extra reference(s) that have to be modified, then > these could be handled more straightforwardly. So supposing that HEAD > points at refs/heads/master, > > * An update of HEAD would be turned into a reflog update and also add a > synthetic update to refs/heads/master. > * An update of refs/heads/master would add a synthetic update to the > HEAD reflog > > The first point would obviously apply to any updates via symbolic refs. > The second one should too, thought this is a case that we currently punt > on to avoid the need to do reverse symbolic ref lookups. All of this is worth fixing, but I don't know that it needs to be fixed before ref backends hit. What do you think? > >> It may be the case that this never happens; I have not actually audited > >> the code to figure it out. If someone knows for sure that it does not > >> happen, please say so. But assuming it does happen, here's my idea: > >> > >> If the refs backend is the files backend, we can simply treat HEAD like > >> any other ref. > >> > >> If the refs backend is different, then the refs code needs to hold a > >> files-backend transaction for HEAD, which it will commit immediately > >> after the other transaction succeeds. We can stick a pointer to the > >> extra transaction in the generic struct ref_transaction, which (as > >> Michael Haggerty suggests) specific backends will extend. > >> > >> A failure to commit either transaction will be reported as a failure, > >> and we'll give an additional inconsistent state warning if the main > >> transaction succeeds but the HEAD transaction fails. > > > > Yeah, I was thinking along those lines, too. Thanks for clearly > > writing it down. > > > >> What do other folks think? > > > > Me too ;-) > > I don't have an answer right now, and I have to get on an airplane in a > few hours so I can't think hard about it at the moment. But let me also > braindump another vague plan that I have had for a long time: > overlayable reference storage schemes. Think of the way that loose refs > are currently overlaid on top of packed refs. I think it might be useful > to support overlaying more generally. > > In this particular case there could be a workspace-local reference > storage that only handles HEAD and perhaps some of the other > pseudoreferences. That could be overlaid onto loose reference storage > (which would then only concern itself with references under "refs/"), > which would in turn be overlaid onto packed refs. The workspace-local > reference storage layer would have evil special-cased code for dealing > with the references that live outside of "refs/". > > A `ref_transaction_commit()` would be broken into phases: first each of > the st
Re: [PATCH] Documentation clarification on git-checkout regarding ours/theirs
"Simon A. Eugster" writes:
> From: "Simon A. Eugster"
>
> Signed-off-by: Simon A. Eugster
> ---
For those who are looking from the sideline, this is a reroll from a
month-old thread $gmane/271680.
> Documentation/git-checkout.txt | 16 +++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index d263a56..d69306f 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -115,7 +115,21 @@ entries; instead, unmerged entries are ignored.
> --ours::
> --theirs::
> When checking out paths from the index, check out stage #2
> - ('ours') or #3 ('theirs') for unmerged paths.
> + ('ours', HEAD) or #3 ('theirs', MERGE_HEAD) for unmerged paths.
I'd drop the change on this line. Your conflict may or may not be
from these two places when you are using "checkout". Even if it
came from "git merge", when you are doing "merge", the roles 'ours'
and 'theirs' are very clear and mentioning HEAD/MERGE_HEAD does not
add more clarity than it clutters the description, I would think.
> + See linkgit:git-merge[1] for details about stages #2 and #3.
> ++
> +Note that during `git rebase` and `git pull --rebase`, 'theirs' checks out
> +the local version, and 'ours' the remote version or the history that is
> rebased
> +against.
> ++
> +The reason ours/theirs appear to be swapped during a rebase is that we
> +define the remote history as the canonical history, on top of which our
> +private commits are applied on, as opposed to normal merging where the
> +local history is the canonical one.
It appears to me that this patch text predates my comment in
$gmane/271720 and your response to it?
> +During merging, we assume the role of the canonical history’s keeper,
> +which, in case of a rebase, is the remote history, and our private commits
> +look to the keeper as “their” commits which need to be integrated on top
> +of “our” work.
>
> -b ::
> Create a new branch named and start it at
Thanks for reminding of the discussion that did not conclude with a
patch.
How about this?
-- >8 --
From: "Simon A. Eugster"
Subject: checkout: document subtlety around --ours/--theirs
During a 'rebase' (hence 'pull --rebase'), --ours/--theirs may
appear to be swapped to those who are not aware of the fact that
they are temporarily playing the role of the keeper of the more
authoritative history.
Add a note to clarify.
Helped-by: Junio C Hamano
Signed-off-by: Simon A. Eugster
---
Documentation/git-checkout.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a565..8c921e7 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -116,6 +116,21 @@ entries; instead, unmerged entries are ignored.
--theirs::
When checking out paths from the index, check out stage #2
('ours') or #3 ('theirs') for unmerged paths.
++
+Note that during `git rebase` and `git pull --rebase`, 'ours' and
+'theirs' may appear swapped; `--ours` gives the version from the
+branch the changes are rebased onto, while `--theirs` gives the
+version from the branch that holds your work that is being rebased.
++
+This is because `rebase` is used in a workflow that treats the
+history at the remote as the shared canonical one, and treat the
+work done on the branch you are rebasing as the third-party work to
+be integrated, and you are temporarily assuming the role of the
+keeper of the canonical history during the rebase. As the keeper of
+the canonical history, you need to view the history from the remote
+as `ours` (i.e. "our shared canonical history"), while what you did
+on your side branch as `theirs` (i.e. "one contributor's work on top
+of it").
-b ::
Create a new branch named and start it at
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] ident: support per-path configs by matching the path against a pattern
Jeff King writes:
> Here's a sketch if anybody is inclined to pick it up and run with it.
> Note that I did not think too hard about little things like the
> de-anchoring.
> ...
> int git_config_include(const char *var, const char *value, void *data)
> {
> struct config_include_data *inc = data;
> + const char *cond, *key;
> + int cond_len;
> int ret;
>
> /*
> @@ -152,8 +188,12 @@ int git_config_include(const char *var, const char
> *value, void *data)
> if (ret < 0)
> return ret;
>
> - if (!strcmp(var, "include.path"))
> - ret = handle_path_include(value, inc);
> + if (!parse_config_key(var, "include", &cond, &cond_len, &key) &&
> + include_condition_is_true(cond, cond_len)) {
I really like these two lines.
Whoever designed that parse_config_key() interface either is a
genious or had a foresight with a crystal ball, or perhaps both.
> + if (!strcmp(key, "path"))
> + ret = handle_path_include(value, inc);
> + /* else we do not know about this type of include; ignore */
> + }
> return ret;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git@vger.kernel.org
Signed-off-by: Rene Scharfe --- GIT_TEST_CHAIN_LINT complains about the missing &&s and is enabled by default now. t/perf/p5310-pack-bitmaps.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh index f8ed857..de2a224 100755 --- a/t/perf/p5310-pack-bitmaps.sh +++ b/t/perf/p5310-pack-bitmaps.sh @@ -39,14 +39,14 @@ test_expect_success 'create partial bitmap state' ' # now kill off all of the refs and pretend we had # just the one tip - rm -rf .git/logs .git/refs/* .git/packed-refs - git update-ref HEAD $cutoff + rm -rf .git/logs .git/refs/* .git/packed-refs && + git update-ref HEAD $cutoff && # and then repack, which will leave us with a nice # big bitmap pack of the "old" history, and all of # the new history will be loose, as if it had been pushed # up incrementally and exploded via unpack-objects - git repack -Ad + git repack -Ad && # and now restore our original tip, as if the pushes # had happened -- 2.4.4 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git@vger.kernel.org
On Fri, Jul 10, 2015 at 10:40:57PM +0200, René Scharfe wrote: > diff --git a/t/perf/p5310-pack-bitmaps.sh b/t/perf/p5310-pack-bitmaps.sh > index f8ed857..de2a224 100755 > --- a/t/perf/p5310-pack-bitmaps.sh > +++ b/t/perf/p5310-pack-bitmaps.sh > @@ -39,14 +39,14 @@ test_expect_success 'create partial bitmap state' ' > > # now kill off all of the refs and pretend we had > # just the one tip > - rm -rf .git/logs .git/refs/* .git/packed-refs > - git update-ref HEAD $cutoff > + rm -rf .git/logs .git/refs/* .git/packed-refs && > + git update-ref HEAD $cutoff && Thanks, this definitely is a problem, but we already have a fix in the sb/p5310-and-chain topic. I thought that had been merged-up, but it looks like it is only in "next" right now. -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: [RFC] ident: support per-path configs by matching the path against a pattern
On Fri, Jul 10, 2015 at 01:23:07PM -0700, Junio C Hamano wrote:
> > - if (!strcmp(var, "include.path"))
> > - ret = handle_path_include(value, inc);
> > + if (!parse_config_key(var, "include", &cond, &cond_len, &key) &&
> > + include_condition_is_true(cond, cond_len)) {
>
> I really like these two lines.
>
> Whoever designed that parse_config_key() interface either is a
> genious or had a foresight with a crystal ball, or perhaps both.
Heh. I peeked at the archive, and I think it was actually designed by
committee. Perhaps we are greater than the sum of our parts? ;)
-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 v4] log: add log.follow config option
David Turner writes: > On Thu, 2015-07-09 at 10:58 -0700, Junio C Hamano wrote: >> David Turner writes: >> >> > On Thu, 2015-07-09 at 10:23 -0700, Junio C Hamano wrote: >> > >> >> If I were David and sending this v4 patch, it would have looked like >> >> this. >> >> >> >> -- >8 -- >> >> >> >> From: David Turner >> >> Date: Tue, 7 Jul 2015 21:29:34 -0400 >> >> Subject: [PATCH v4] log: add "log.follow" configuration variable >> >> >> >> People who work on projects with mostly linear history with frequent >> >> whole file renames may want to always use "git log --follow" when >> >> inspecting the life of the content that live in a single path. >> >> >> >> Teach the command to behave as if "--follow" was given from the >> >> command line when log.follow configuration variable is set *and* >> >> there is one (and only one) path on the command line. >> > >> > >> > Thanks. That version is much better. >> >> No, thank _you_; we should be thanking you for helping us improve >> the system ;-) > > Do I need to re-send, or will you queue your version? I think I've already queued this version to my tree. ... goes and looks ... Yup, it is near 'next' and I'm planning to merge it down to 'next' and then to 'master' as time passes ;-) 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: [RFC] ident: support per-path configs by matching the path against a pattern
Jeff King writes:
> On Fri, Jul 10, 2015 at 01:23:07PM -0700, Junio C Hamano wrote:
>
>> > - if (!strcmp(var, "include.path"))
>> > - ret = handle_path_include(value, inc);
>> > + if (!parse_config_key(var, "include", &cond, &cond_len, &key) &&
>> > + include_condition_is_true(cond, cond_len)) {
>>
>> I really like these two lines.
>>
>> Whoever designed that parse_config_key() interface either is a
>> genious or had a foresight with a crystal ball, or perhaps both.
>
> Heh. I peeked at the archive, and I think it was actually designed by
> committee. Perhaps we are greater than the sum of our parts? ;)
It does not look like a camel, though ;-).
Thanks. Let's see if Sebastian finds the direction satisfactory.
--
To unsubscribe from this list: send the line "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's cooking in git.git (Jul 2015, #03; Fri, 10)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. For updated schedule for 2.5 final please see tinyurl.com/gitCal Also note that when I say "Will merge to 'master'", I am not saying if that happens before or after the upcoming release, at least not yet ;-). You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [Graduated to "master"] * cb/rebase-am-exit-code (2015-07-08) 1 commit (merged to 'next' on 2015-07-09 at ca9b7e1) + rebase: return non-zero error code if format-patch fails "git rebase" did not exit with failure when format-patch it invoked failed for whatever reason. * cb/subtree-tests-update (2015-06-22) 3 commits (merged to 'next' on 2015-06-24 at 31a2938) + contrib/subtree: small tidy-up to test + contrib/subtree: fix broken &&-chains and revealed test error + contrib/subtree: use tabs consitently for indentation in tests Tests update in contrib/subtree. * jc/fix-alloc-sortbuf-in-index-pack (2015-07-04) 1 commit (merged to 'next' on 2015-07-06 at c05da06) + index-pack: fix allocation of sorted_by_pos array A hotfix for what is in 2.5-rc but not in 2.4. * jk/fix-refresh-utime (2015-07-08) 1 commit (merged to 'next' on 2015-07-09 at 323b86d) + check_and_freshen_file: fix reversed success-check Fix a small bug in our use of umask() return value. * jk/maint-for-each-packed-object (2015-06-22) 1 commit (merged to 'next' on 2015-06-24 at 162e134) + for_each_packed_object: automatically open pack index (this branch is used by jk/cat-file-batch-all.) The for_each_packed_object() API function did not iterate over objects in a packfile that hasn't been used yet. * jk/pretty-encoding-doc (2015-06-17) 1 commit (merged to 'next' on 2015-07-09 at f61edd3) + docs: clarify that --encoding can produce invalid sequences Doc update. * jk/rev-list-no-bitmap-while-pruning (2015-07-01) 1 commit (merged to 'next' on 2015-07-09 at 81d6d1b) + rev-list: disable --use-bitmap-index when pruning commits A minor bugfix when pack bitmap is used with "rev-list --count". * ls/hint-rev-list-count (2015-07-01) 1 commit (merged to 'next' on 2015-07-09 at 84139dc) + rev-list: add --count to usage guide * mm/branch-doc-updates (2015-07-06) 2 commits (merged to 'next' on 2015-07-09 at 4b0fa63) + Documentation/branch: document -M and -D in terms of --force + Documentation/branch: document -d --force and -m --force * nd/dwim-wildcards-as-pathspecs (2015-07-01) 1 commit (merged to 'next' on 2015-07-09 at a376360) + Add tests for wildcard "path vs ref" disambiguation Test updates to a topic already in 2.5-rc. * rh/test-color-avoid-terminfo-in-original-home (2015-06-17) 2 commits (merged to 'next' on 2015-06-24 at 6af5fa7) + test-lib.sh: fix color support when tput needs ~/.terminfo + Revert "test-lib.sh: do tests for color support after changing HOME" An ancient test framework enhancement to allow color was not entirely correct; this makes it work even when tput needs to read from the ~/.terminfo under the user's real HOME directory. * sb/p5310-and-chain (2015-06-26) 1 commit (merged to 'next' on 2015-07-09 at c54ee67) + p5310: Fix broken && chain in performance test Code clean-up. * tb/checkout-doc (2015-06-17) 1 commit (merged to 'next' on 2015-07-09 at 74226c9) + git-checkout.txt: document "git checkout " better Doc update. -- [New Topics] * dt/log-follow-config (2015-07-09) 1 commit (merged to 'next' on 2015-07-10 at b8fbb43) + log: add "log.follow" configuration variable Add a new configuration variable to enable "--follow" automatically when "git log" is run with one pathspec argument. Will merge to 'master'. * ss/clone-guess-dir-name-simplify (2015-07-09) 1 commit (merged to 'next' on 2015-07-10 at 8a62f4d) + clone: simplify string handling in guess_dir_name() Will merge to 'master'. * kn/tag-doc-fix (2015-07-10) 1 commit - Documentation/tag: remove double occurance of "" Will merge to 'next'. * se/doc-checkout-ours-theirs (2015-07-10) 1 commit - checkout: document subtlety around --ours/--theirs A "rebase" replays changes of the local branch on top of something else, as such they are placed in stage #3 and referred to as "theirs", while the changes in the new base, typically a foreign work, are placed in stage #2 and referred to as "ours". Clarify the "checkout --ours/--theirs". -- [Stalled] * sg/config-name-only (2015-05-28) 3 commits - completion: use new 'git config' options to reliably list variable names - SQUASH - config: add options to list only variable names "git config --list" output was hard to parse when values consist of multi
Re: What's cooking in git.git (Jul 2015, #03; Fri, 10)
On Fri, Jul 10, 2015 at 6:45 PM, Junio C Hamano wrote: > * es/worktree-add (2015-07-07) 23 commits > (merged to 'next' on 2015-07-10 at 304e329) > + checkout: retire --ignore-other-worktrees in favor of --force > + worktree: add: auto-vivify new branch when is omitted > + worktree: add: make -b/-B default to HEAD when is omitted > + worktree: extract basename computation to new function > + checkout: require worktree unconditionally > + checkout: retire --to option > + tests: worktree: retrofit "checkout --to" tests for "worktree add" > + worktree: add -b/-B options > + worktree: add --detach option > + worktree: add --force option > + worktree: introduce "add" command > + checkout: drop 'checkout_opts' dependency from prepare_linked_checkout > + checkout: make --to unconditionally verbose > + checkout: prepare_linked_checkout: drop now-unused 'new' argument > + checkout: relocate --to's "no branch specified" check > + checkout: fix bug with --to and relative HEAD > + Documentation/git-worktree: add EXAMPLES section > + Documentation/git-worktree: add high-level 'lock' overview > + Documentation/git-worktree: split technical info from general description > + Documentation/git-worktree: add BUGS section > + Documentation: move linked worktree description from checkout to worktree > + Documentation/git-worktree: associate options with commands > + Documentation/git-checkout: fix incorrect worktree prune command > (this branch uses nd/multiple-work-trees.) > > Update to the "linked checkout" in 2.5.0-rc1. > > Instead of "checkout --to" that does not do what "checkout" > normally does, move the functionality to "git worktree add". > > Will merge to 'master'. Did you want to drop the final patch[*1*] which retires --ignore-other-worktrees in favor of --force before letting this graduate to 'master'? By the way, v1 of the follow-on series which replaces "git checkout" with "git reset --hard" to populate the new worktree is ready. I expect to send it out shortly. [*1*]: http://thread.gmane.org/gmane.comp.version-control.git/273415/focus=273585 -- To unsubscribe from this list: send the line "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 01/10] ref-filter: add %(refname:shortalign=X) option
On Thu, Jul 9, 2015 at 6:28 PM, Matthieu Moy
wrote:
> Karthik Nayak writes:
>
>> Add support for %(refname:shortalign=X) where X is a number.
>> This will print a shortened refname aligned to the left
>> followed by spaces for a total length of X characters.
>> If X is less than the shortened refname size, the entire
>> shortened refname is printed.
>
> Not really an issue, but you're wrapping your text at ~60 characters.
> The common use is to wrap around 70 to 80. Using Emacs, auto-fill-mode
> or M-q does this automatically. If you use another text editor, it can
> probably do that for you too.
>
Thanks, I was just manually clipping it.
>> Mentored-by: Christian Couder
>> Mentored-by: Matthieu Moy
>> Signed-off-by: Karthik Nayak
>> ---
>> ref-filter.c | 19 ++-
>
> I think this would deserve a test and documentation. Even though your
> motivation is for an internal implementation, some users may want to use
> the feature in 'git for-each-ref --format=...'.
>
I didn't want to include documentation as this is mostly for internal use,
but will add with tests.
>> 1 file changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/ref-filter.c b/ref-filter.c
>> index dd0709d..3098497 100644
>> --- a/ref-filter.c
>> +++ b/ref-filter.c
>> @@ -10,6 +10,7 @@
>> #include "quote.h"
>> #include "ref-filter.h"
>> #include "revision.h"
>> +#include "utf8.h"
>>
>> typedef enum { FIELD_STR, FIELD_ULONG, FIELD_TIME } cmp_type;
>>
>> @@ -695,7 +696,23 @@ static void populate_value(struct ref_array_item *ref)
>> int num_ours, num_theirs;
>>
>> formatp++;
>> - if (!strcmp(formatp, "short"))
>> + if (starts_with(formatp, "shortalign=")) {
>> + const char *valp, *short_refname = NULL;
>> + int val, len;
>> +
>> + skip_prefix(formatp, "shortalign=", &valp);
>> + val = atoi(valp);
>
> You're silently accepting %(refname:shortalign=foo) and
> %(refname:shortalign=). I think it would be better to reject such cases
> explicitly.
>
Oh yeah! will do.
--
Regards,
Karthik Nayak
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Git Smart HTTP with HTTP/2.0
As we known, HTTP/2.0 has been released. All Git-Smart-HTTP are currently
implemented using HTTP/1.1.
Frequently used Git developers often feel Git HTTP protocol is not
satisfactory, slow and unstable.This is because the HTTP protocol itself
decides
When HTTP/2.0 is published. We might be able to git developers jointly,
based on HTTP/2.0 Git-Smart-HTTP service and client support.
HTTP/2.0: https://tools.ietf.org/html/rfc7540
Github Mirror: https://httpwg.github.io/specs/rfc7540.html
HTTP/2.0 has Flow Controller like SSH,
HTTP/2.0 has Server Push POST upload-pack can download large more
object-pack
..
libcurl now has begun to support HTTP/2.0, git is also using curl, as well
libgit2 may use libcurl
I suggest the git of developer joint developer of libgit2 and jgit
developers discussion based on HTTP/2.0 Git-Smart-HTTP
Now Subversion developer begin write a New HTTP Protocol for svn ("HTTP
v2"):http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/
http-protocol-v2.txt
What about 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: [PATCH v2 04/10] ref-filter: add support to sort by version
On Fri, Jul 10, 2015 at 5:48 PM, Matthieu Moy wrote: > Karthik Nayak writes: > >> On Fri, Jul 10, 2015 at 4:22 PM, Karthik Nayak wrote: >>> On Thu, Jul 9, 2015 at 6:59 PM, Matthieu Moy >>> wrote: Karthik Nayak writes: > Add support to sort by version using the "v:refname" and > "version:refname" option. This is achieved by using the > 'version_cmp()' function as the comparing function for qsort. You should elaborate on why you need this. Given the context, I can guess that you will need this to implement tag, but for example I first wondered why you needed both version: and v:, but I guess it comes from the fact that 'git tag --sort' can take version:refname or v:refname. I think this deserves a test and documentation in for-each-ref.txt. >>> >>> I'll add it to "for-each-ref.txt" documentation. >>> About the tests, there are already tests for the same in git-tag.txt and >>> that's the only reason I did not repeat the tests in for-each-ref. >>> >> >> But since the porting is in a later commit, will add tests to for-each-ref. > > Yes: to me "it's tested through 'git tag'" is a good argument to do only > a superficial test, check that 'for-each-ref --sort v:refname' activate > the sorting, but no detailed corner-case testing. But not a good > argument to have no test at all on for-each-ref. > Agreed, I've written tests for the same. -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation clarification on git-checkout regarding ours/theirs
Am 10.07.2015 um 22:07 schrieb Junio C Hamano:
"Simon A. Eugster" writes:
From: "Simon A. Eugster"
Signed-off-by: Simon A. Eugster
---
For those who are looking from the sideline, this is a reroll from a
month-old thread $gmane/271680.
Documentation/git-checkout.txt | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a56..d69306f 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -115,7 +115,21 @@ entries; instead, unmerged entries are ignored.
--ours::
--theirs::
When checking out paths from the index, check out stage #2
- ('ours') or #3 ('theirs') for unmerged paths.
+ ('ours', HEAD) or #3 ('theirs', MERGE_HEAD) for unmerged paths.
I'd drop the change on this line. Your conflict may or may not be
from these two places when you are using "checkout". Even if it
came from "git merge", when you are doing "merge", the roles 'ours'
and 'theirs' are very clear and mentioning HEAD/MERGE_HEAD does not
add more clarity than it clutters the description, I would think.
Agree! How about the reference to git-merge? I had to google for stage
to find the documentation on it.
+ See linkgit:git-merge[1] for details about stages #2 and #3.
++
+Note that during `git rebase` and `git pull --rebase`, 'theirs' checks out
+the local version, and 'ours' the remote version or the history that is rebased
+against.
++
+The reason ours/theirs appear to be swapped during a rebase is that we
+define the remote history as the canonical history, on top of which our
+private commits are applied on, as opposed to normal merging where the
+local history is the canonical one.
It appears to me that this patch text predates my comment in
$gmane/271720 and your response to it?
Yes.
+During merging, we assume the role of the canonical history’s keeper,
+which, in case of a rebase, is the remote history, and our private commits
+look to the keeper as “their” commits which need to be integrated on top
+of “our” work.
-b ::
Create a new branch named and start it at
Thanks for reminding of the discussion that did not conclude with a
patch.
How about this?
-- >8 --
From: "Simon A. Eugster"
Subject: checkout: document subtlety around --ours/--theirs
During a 'rebase' (hence 'pull --rebase'), --ours/--theirs may
appear to be swapped to those who are not aware of the fact that
they are temporarily playing the role of the keeper of the more
authoritative history.
Add a note to clarify.
Helped-by: Junio C Hamano
Signed-off-by: Simon A. Eugster
---
Documentation/git-checkout.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index d263a565..8c921e7 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -116,6 +116,21 @@ entries; instead, unmerged entries are ignored.
--theirs::
When checking out paths from the index, check out stage #2
('ours') or #3 ('theirs') for unmerged paths.
++
+Note that during `git rebase` and `git pull --rebase`, 'ours' and
+'theirs' may appear swapped; `--ours` gives the version from the
+branch the changes are rebased onto, while `--theirs` gives the
+version from the branch that holds your work that is being rebased.
++
+This is because `rebase` is used in a workflow that treats the
+history at the remote as the shared canonical one, and treat the
+work done on the branch you are rebasing as the third-party work to
+be integrated, and you are temporarily assuming the role of the
+keeper of the canonical history during the rebase. As the keeper of
+the canonical history, you need to view the history from the remote
+as `ours` (i.e. "our shared canonical history"), while what you did
+on your side branch as `theirs` (i.e. "one contributor's work on top
+of it").
-b ::
Create a new branch named and start it at
I think there is an “s” missing in “… and treat the work done on the
branch …”, but not quite sure.
Apart from this, very clear and perfect to me.
Thanks for your effort!
Simon
--
To unsubscribe from this list: send the line "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 05/10] ref-filter: add option to match literal pattern
On Fri, Jul 10, 2015 at 10:13 PM, Junio C Hamano wrote: > Karthik Nayak writes: > >> Since 'ref-filter' only has an option to match path names >> add an option for regular pattern matching. > > There is nothing "regular" about the pattern matching you are > adding. > > Everywhere else we use patterns on refs we call wildmatch(), which > is an enhanced implementation of fnmatch(3), and you are doing the > same in this new codepath. > > Just drop that word from here (and if you said something similar in > the documentation, drop "regular" ffrom there as well). It would > invite confusion with regular expression matching, which we will not > do for refs. Ok, will do. Thanks -- Regards, Karthik Nayak -- To unsubscribe from this list: send the line "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: Building git 2.4.5 on AIX 6.1 problems
This is the output I got from using V=1 with make
gcc -g -O2 -I. -D_LARGE_FILES -DNO_D_TYPE_IN_DIRENT -DNO_NSEC -DOLD_ICONV
-pthread -DHAVE_PATHS_H -DHAVE_
LIBCHARSET_H -DHAVE_STRINGS_H -DSHA1_HEADER=''
-DFREAD_READS_DIRECTORIES -DNO_STRCASESTR -
DNO_STRLCPY -Icompat/fnmatch -DNO_FNMATCH_CASEFOLD -DUSE_WILDMATCH
-DNO_MKSTEMPS -DINTERNAL_QSORT -Icompat
/regex -DDEFAULT_PAGER='"more"' -DSHELL_PATH='"/bin/sh"' -o
git-credential-store credential-store.o libg
it.a xdiff/lib.a -lz -liconv -lintl -lcrypto -pthread
Also, the undefined symbol errors - does anyone know which library these are
supposed to be in?
So when I grep for one undefined symbol
$: git-2.4.5 $ grep -R diff_queued_diff *
builtin/blame.c:if (!diff_queued_diff.nr) {
builtin/blame.c:for (i = 0; i < diff_queued_diff.nr; i++) {
builtin/blame.c:p = diff_queued_diff.queue[i];
..
builtin/diff.c: diff_queue(&diff_queued_diff, one, two);
builtin/fast-export.c: for (i = 0; i < diff_queued_diff.nr; i++)
builtin/fast-export.c: if
(!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
builtin/fast-export.c:
export_blob(diff_queued_diff.queue[i]->two->sha1);
diff.c: struct diff_queue_struct *q = &diff_queued_diff;
diff.c: struct diff_queue_struct *q = &diff_queued_diff;
So it is obviously a structure or variable that is being used so does anyone
know the library that this is defined in?
--
View this message in context:
http://git.661346.n2.nabble.com/Building-git-2-4-5-on-AIX-6-1-problems-tp7635435p7635513.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] git-filter-branch.sh: clarify an error message
How does "You did not provide a valid range of commits. At least one tip in your range must be a ref." sound? -- Chris http://christopherjones.us/ On Sun, Jul 5, 2015, at 10:41 AM, Johannes Schindelin wrote: > Hi, > > On 2015-07-05 15:07, Jeff King wrote: > > On Sat, Jul 04, 2015 at 07:39:04PM -0400, Chris Jones wrote: > > > >> Make git filter-branch output a useful error message when a single > >> commit is given instead of a range. Currently, when given a command > >> like git filter-branch --msg-filter 'echo "TEST"' -- abc123, it will > >> give the message "Which ref do you want to rewrite?". Instead, what > >> is needed is a range of commits to rewrite. This makes it give an > >> error message that says "You didn't provide a valid range of > >> commits". > > > > Yeah, I agree the current message is a little confusing, and I think > > your message is an improvement. I wonder if we can even go a step > > further, like mentioning that at least one of the positive tips in your > > range must be a ref. > > I agree, and would even further suggest to use the "did not" form instead > of the abbreviated "didn't" one. > > Thanks, > Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/16] worktree: make setup of new HEAD distinct from worktree population
The eventual goal is for git-worktree to populate the new worktree via
"git reset --hard" rather than "git checkout". As a consequence,
git-worktree will no longer be able to delegate to git-branch the
setting of the new worktree's HEAD to the desired branch (or commit, if
detached). Therefore, make git-worktree responsible for setting up HEAD
as either a symbolic reference if associated with a branch, or detached
if not.
Signed-off-by: Eric Sunshine
---
As with the patch which separates branch creation from worktree
population (by using git-branch instead of "git checkout -b"), this
patch invokes git-symbolic-ref and git-update-ref rather than using the
lower-level C API, due to the added value of those commands. If this
proves the wrong approach, then the series can be re-rolled or follow-on
patches can instead use the C API.
builtin/worktree.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index babdef1..94c1701 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -274,12 +274,20 @@ static int add_worktree(const char *path, const char
*refname,
setenv(GIT_WORK_TREE_ENVIRONMENT, path, 1);
memset(&cp, 0, sizeof(cp));
cp.git_cmd = 1;
+
+ if (commit)
+ argv_array_pushl(&cp.args, "update-ref", "HEAD",
+sha1_to_hex(commit->object.sha1), NULL);
+ else
+ argv_array_pushl(&cp.args, "symbolic-ref", "HEAD",
+symref.buf, NULL);
+ ret = run_command(&cp);
+ if (ret)
+ goto done;
+
+ cp.argv = NULL;
+ argv_array_clear(&cp.args);
argv_array_push(&cp.args, "checkout");
- if (opts->force)
- argv_array_push(&cp.args, "--ignore-other-worktrees");
- if (opts->detach)
- argv_array_push(&cp.args, "--detach");
- argv_array_push(&cp.args, refname);
ret = run_command(&cp);
if (!ret) {
is_junk = 0;
@@ -288,6 +296,7 @@ static int add_worktree(const char *path, const char
*refname,
junk_work_tree = NULL;
junk_git_dir = NULL;
}
+done:
strbuf_reset(&sb);
strbuf_addf(&sb, "%s/locked", sb_repo.buf);
unlink_or_warn(sb.buf);
--
2.5.0.rc1.201.ga12d9f8
--
To unsubscribe from this list: send the line "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 07/16] worktree: simplify new branch (-b/-B) option checking
Make 'new_branch' be the name of the new branch for both forced and
non-forced cases; and add boolean 'force_new_branch' to indicate forced
branch creation. This will simplify logic later on when git-worktree
handles branch creation locally rather than delegating it to
git-checkout as part of the worktree population phase.
Signed-off-by: Eric Sunshine
---
builtin/worktree.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 69248ba..c267410 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -272,7 +272,7 @@ static int add_worktree(const char *path, const char
**child_argv)
static int add(int ac, const char **av, const char *prefix)
{
- int force = 0, detach = 0;
+ int force = 0, detach = 0, force_new_branch;
const char *new_branch = NULL, *new_branch_force = NULL;
const char *path, *branch;
struct argv_array cmd = ARGV_ARRAY_INIT;
@@ -295,7 +295,11 @@ static int add(int ac, const char **av, const char *prefix)
path = prefix ? prefix_filename(prefix, strlen(prefix), av[0]) : av[0];
branch = ac < 2 ? "HEAD" : av[1];
- if (ac < 2 && !new_branch && !new_branch_force) {
+ force_new_branch = !!new_branch_force;
+ if (force_new_branch)
+ new_branch = new_branch_force;
+
+ if (ac < 2 && !new_branch) {
int n;
const char *s = worktree_basename(path, &n);
new_branch = xstrndup(s, n);
@@ -305,9 +309,8 @@ static int add(int ac, const char **av, const char *prefix)
if (force)
argv_array_push(&cmd, "--ignore-other-worktrees");
if (new_branch)
- argv_array_pushl(&cmd, "-b", new_branch, NULL);
- if (new_branch_force)
- argv_array_pushl(&cmd, "-B", new_branch_force, NULL);
+ argv_array_pushl(&cmd, force_new_branch ? "-B" : "-b",
+new_branch, NULL);
if (detach)
argv_array_push(&cmd, "--detach");
argv_array_push(&cmd, branch);
--
2.5.0.rc1.201.ga12d9f8
--
To unsubscribe from this list: send the line "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 08/16] worktree: introduce options container
add_worktree() will eventually need to deal with some options itself, so
introduce a structure into which options can be conveniently bundled,
and pass it along to add_worktree().
Signed-off-by: Eric Sunshine
---
builtin/worktree.c | 45 +++--
1 file changed, 27 insertions(+), 18 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index c267410..253382a 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -12,6 +12,13 @@ static const char * const worktree_usage[] = {
NULL
};
+struct add_opts {
+ int force;
+ int detach;
+ const char *new_branch;
+ int force_new_branch;
+};
+
static int show_only;
static int verbose;
static unsigned long expire;
@@ -171,7 +178,8 @@ static const char *worktree_basename(const char *path, int
*olen)
return name;
}
-static int add_worktree(const char *path, const char **child_argv)
+static int add_worktree(const char *path, const char **child_argv,
+ const struct add_opts *opts)
{
struct strbuf sb_git = STRBUF_INIT, sb_repo = STRBUF_INIT;
struct strbuf sb = STRBUF_INIT;
@@ -272,22 +280,23 @@ static int add_worktree(const char *path, const char
**child_argv)
static int add(int ac, const char **av, const char *prefix)
{
- int force = 0, detach = 0, force_new_branch;
- const char *new_branch = NULL, *new_branch_force = NULL;
+ struct add_opts opts;
+ const char *new_branch_force = NULL;
const char *path, *branch;
struct argv_array cmd = ARGV_ARRAY_INIT;
struct option options[] = {
- OPT__FORCE(&force, N_("checkout even if already
checked out in other worktree")),
- OPT_STRING('b', NULL, &new_branch, N_("branch"),
+ OPT__FORCE(&opts.force, N_("checkout even if already
checked out in other worktree")),
+ OPT_STRING('b', NULL, &opts.new_branch, N_("branch"),
N_("create a new branch")),
OPT_STRING('B', NULL, &new_branch_force, N_("branch"),
N_("create or reset a branch")),
- OPT_BOOL(0, "detach", &detach, N_("detach HEAD at named
commit")),
+ OPT_BOOL(0, "detach", &opts.detach, N_("detach HEAD at named
commit")),
OPT_END()
};
+ memset(&opts, 0, sizeof(opts));
ac = parse_options(ac, av, prefix, options, worktree_usage, 0);
- if (new_branch && new_branch_force)
+ if (opts.new_branch && new_branch_force)
die(_("-b and -B are mutually exclusive"));
if (ac < 1 || ac > 2)
usage_with_options(worktree_usage, options);
@@ -295,27 +304,27 @@ static int add(int ac, const char **av, const char
*prefix)
path = prefix ? prefix_filename(prefix, strlen(prefix), av[0]) : av[0];
branch = ac < 2 ? "HEAD" : av[1];
- force_new_branch = !!new_branch_force;
- if (force_new_branch)
- new_branch = new_branch_force;
+ opts.force_new_branch = !!new_branch_force;
+ if (opts.force_new_branch)
+ opts.new_branch = new_branch_force;
- if (ac < 2 && !new_branch) {
+ if (ac < 2 && !opts.new_branch) {
int n;
const char *s = worktree_basename(path, &n);
- new_branch = xstrndup(s, n);
+ opts.new_branch = xstrndup(s, n);
}
argv_array_push(&cmd, "checkout");
- if (force)
+ if (opts.force)
argv_array_push(&cmd, "--ignore-other-worktrees");
- if (new_branch)
- argv_array_pushl(&cmd, force_new_branch ? "-B" : "-b",
-new_branch, NULL);
- if (detach)
+ if (opts.new_branch)
+ argv_array_pushl(&cmd, opts.force_new_branch ? "-B" : "-b",
+opts.new_branch, NULL);
+ if (opts.detach)
argv_array_push(&cmd, "--detach");
argv_array_push(&cmd, branch);
- return add_worktree(path, cmd.argv);
+ return add_worktree(path, cmd.argv, &opts);
}
int cmd_worktree(int ac, const char **av, const char *prefix)
--
2.5.0.rc1.201.ga12d9f8
--
To unsubscribe from this list: send the line "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: Building git 2.4.5 on AIX 6.1 problems
On Fri, Jul 10, 2015 at 11:31 PM, norricorp wrote:
>
> This is the output I got from using V=1 with make
> gcc -g -O2 -I. -D_LARGE_FILES -DNO_D_TYPE_IN_DIRENT -DNO_NSEC -DOLD_ICONV
> -pthread -DHAVE_PATHS_H -DHAVE_
> LIBCHARSET_H -DHAVE_STRINGS_H -DSHA1_HEADER=''
> -DFREAD_READS_DIRECTORIES -DNO_STRCASESTR -
> DNO_STRLCPY -Icompat/fnmatch -DNO_FNMATCH_CASEFOLD -DUSE_WILDMATCH
> -DNO_MKSTEMPS -DINTERNAL_QSORT -Icompat
> /regex -DDEFAULT_PAGER='"more"' -DSHELL_PATH='"/bin/sh"' -o
> git-credential-store credential-store.o libg
> it.a xdiff/lib.a -lz -liconv -lintl -lcrypto -pthread
>
> Also, the undefined symbol errors - does anyone know which library these are
> supposed to be in?
> So when I grep for one undefined symbol
> $: git-2.4.5 $ grep -R diff_queued_diff *
> builtin/blame.c:if (!diff_queued_diff.nr) {
> builtin/blame.c:for (i = 0; i < diff_queued_diff.nr; i++) {
> builtin/blame.c:p = diff_queued_diff.queue[i];
> ..
> builtin/diff.c: diff_queue(&diff_queued_diff, one, two);
> builtin/fast-export.c: for (i = 0; i < diff_queued_diff.nr; i++)
> builtin/fast-export.c: if
> (!S_ISGITLINK(diff_queued_diff.queue[i]->two->mode))
> builtin/fast-export.c:
> export_blob(diff_queued_diff.queue[i]->two->sha1);
>
> diff.c: struct diff_queue_struct *q = &diff_queued_diff;
> diff.c: struct diff_queue_struct *q = &diff_queued_diff;
>
> So it is obviously a structure or variable that is being used so does anyone
> know the library that this is defined in?
Most of our objects should be found in libgit.a (you can see it on your
command line) that our Makefile builds.
Now, it has been more than a decade since I last had to deal with a
system that needs this the last time, but perhaps AIX linker needs the
archives explicitly prepared with ranlib(1)? Just a shot in the dark...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
