On Mon, Jan 16, 2017 at 05:33:44PM -0800, Jacob Keller wrote:
> > I am certainly sympathetic to the idea that the "?" is ugly and
> > potentially confusing. But I think it's at least a step forward for this
> > particular example.
>
> Would it be possible to convert the CR to a literal \r printin
Hi Max,
On Tue, 17 Jan 2017, Max Kirillov wrote:
> Apparently various GIT_* environment variables (most
> interesting is GIT_DIR but AFAIR there were more) leak to
> shell session launched from Git Gui's "Git Bash" menu item.
Given that you call it from Git GUI, i.e. for a *specific* worktree, I
Hi Philip,
On Mon, 16 Jan 2017, Philip Oakley wrote:
> In
> https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242
> the procedure `_unset_recentrepo` is called, however the procedure isn't
> declared until line 248. My reading of the various Tcl tutorials suggest
> (but no
On Sun, Jan 15, 2017 at 01:47:01PM -0500, santi...@nyu.edu wrote:
> From: Lukas Puehringer
>
> Calling functions for gpg_verify_tag() may desire to print relevant
> information about the header for further verification. Add an optional
> format argument to print any desired information after GPG
Hi there,
I'm trying to purge a complete folder and its files from the
repository history with:
git-Games# git filter-branch 'git rm -r --ignore-unmatch --
Ubuntu/16.04/' --tag-name-filter cat -- --all HEAD
fatal: bad revision 'git rm -r --ignore-unmatch -- Ubuntu/16.04/'
git does not find the f
On Sun, Jan 15, 2017 at 01:47:03PM -0500, santi...@nyu.edu wrote:
> -static int for_each_tag_name(const char **argv, each_tag_name_fn fn)
> +static int for_each_tag_name(const char **argv, each_tag_name_fn fn,
> + void *cb_data)
> {
> const char **p;
> char ref[PATH_MAX];
On Sun, Jan 15, 2017 at 01:47:05PM -0500, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> tag -v now supports --format specifiers to inspect the contents of a tag
> upon verification. Add two tests to ensure this behavior is respected in
> future changes.
>
> Signed-off-by: Santiago Torres
On Sun, Jan 15, 2017 at 01:46:58PM -0500, santi...@nyu.edu wrote:
> From: Santiago Torres
>
> This is the fifth iteration of [1][2][3][4], and as a result of the
> discussion in [5]. The main goal of this patch series is to bring
> --format to git tag verification so that upper-layer tools can i
On Tue, Jan 17, 2017 at 10:24:55AM -0500, Jeff King wrote:
> On Sun, Jan 15, 2017 at 01:47:01PM -0500, santi...@nyu.edu wrote:
>
> > From: Lukas Puehringer
> >
> > Calling functions for gpg_verify_tag() may desire to print relevant
> > information about the header for further verification. Add
On Tue, Jan 17, 2017 at 04:30:48PM +0100, jean-christophe manciot wrote:
> I'm trying to purge a complete folder and its files from the
> repository history with:
>
> git-Games# git filter-branch 'git rm -r --ignore-unmatch --
> Ubuntu/16.04/' --tag-name-filter cat -- --all HEAD
> fatal: bad revi
It served its purpose, but now we have a builtin difftool. Time for the
Perl script to enjoy Florida.
Signed-off-by: Johannes Schindelin
---
.gitignore | 1 -
Makefile | 1 -
builtin/difftool.c
This patch gives life to the skeleton added in the previous patch.
The motivation for converting the difftool is that Perl scripts are not at
all native on Windows, and that `git difftool` therefore is pretty slow on
that platform, when there is no good reason for it to be slow.
In addition, Perl
This patch series converts the difftool from a Perl script into a
builtin, for three reasons:
1. Perl is really not native on Windows. Not only is there a performance
penalty to be paid just for running Perl scripts, we also have to deal
with the fact that users may have different Perl insta
This adds a builtin difftool that still falls back to the legacy Perl
version, which has been renamed to `legacy-difftool`.
The idea is that the new, experimental, builtin difftool immediately hands
off to the legacy difftool for now, unless the config variable
difftool.useBuiltin is set to true.
> > Hrm. Maybe I am missing something, but what does:
> >
> > verify_and_format_tag(sha1, name, fmt, flags);
> >
> > get you over:
> >
> > gpg_verify_tag(sha1, name, flags);
> > pretty_print_ref(name, sha1, fmt);
> >
> > ? The latter seems much more flexible, and I do not see how the
> >
> > {
> > - return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE);
> > + int flags;
> > + char *fmt_pretty = cb_data;
> > + flags = GPG_VERIFY_VERBOSE;
> > +
> > + if (fmt_pretty)
> > + flags = GPG_VERIFY_QUIET;
> > +
> > + return verify_and_format_tag(sha1, ref,
On Tue, Jan 17, 2017 at 11:57:25AM -0500, Santiago Torres wrote:
> > Having read through the rest of the series, it looks like you'd
> > sometimes have to do:
>
> IIRC, we did this to make the diff "simpler". It also feeds odd that the
> call chain is the following:
>
> verify_and_format_tag
On Tue, Jan 17, 2017 at 12:25:31PM -0500, Jeff King wrote:
> Actually, looking at the callsites, I think they are fine to just call
> pretty_print_ref() themselves, and I don't think it actually matters if
> it happens before or after the verification.
Oh, sorry, I misread it. We do indeed early-
On Tue, Jan 17, 2017 at 12:00:19PM -0500, Santiago Torres wrote:
> > > {
> > > - return verify_and_format_tag(sha1, name, NULL, GPG_VERIFY_VERBOSE);
> > > + int flags;
> > > + char *fmt_pretty = cb_data;
> > > + flags = GPG_VERIFY_VERBOSE;
> > > +
> > > + if (fmt_pretty)
> > > + flags = G
On Tue, Jan 17, 2017 at 12:33:46PM -0500, Santiago Torres wrote:
> Yeah, this actually looks more cleaner.
>
> Let me give it a go.
Neat. Note there's a bug:
> > diff --git a/builtin/tag.c b/builtin/tag.c
> > index 9da11e0c2..068f392b6 100644
> > --- a/builtin/tag.c
> > +++ b/builtin/tag.c
> >
Yeah, this actually looks more cleaner.
Let me give it a go.
Thanks!
-Santiago.
On Tue, Jan 17, 2017 at 12:30:04PM -0500, Jeff King wrote:
> On Tue, Jan 17, 2017 at 12:25:31PM -0500, Jeff King wrote:
>
> > Actually, looking at the callsites, I think they are fine to just call
> > pretty_print_r
> VERBOSE|QUIET _does_ have a meaning, which is "show the payload, but do
> not print the signature buffer". Perhaps just renaming QUIET to
> OMIT_STATUS or something would make it more clear.
>
Let me give this a go too. OMIT_STATUS does sound less confusing.
Thanks,
-Santiago.
> -Peff
signat
Junio C Hamano writes:
> Paul Mackerras writes:
>
>>> Paul, is it a good time to pull, or do you still have something not
>>> published yet that should go together with what you have already
>>> queued?
>>
>> I recently pushed out one more commit to update the Russian
>> translation from Dimitri
This is an issue I've thought a lot about. So apologies in advance that
this response turned out a bit long. :)
On Fri, Jan 13, 2017 at 10:52:53AM -0500, Ben Peart wrote:
> Design
> ~~
>
> Clone and fetch will pass a �--lazy-clone� flag (open to a better name
> here) similar to �--depth� th
On Sun, Jan 15, 2017 at 1:02 PM, Brian J. Davis wrote:
>>
>> Technically it is submodule..url instead of
>> submodule..url. The name is usually the path initially, and once
>> you move the submodule, only the path changes, the name is supposed to
>> be constant and stay the same.
>
> I am not cer
On Tue, Jan 17, 2017 at 11:52:29AM +0100, Johannes Schindelin wrote:
> Hi Max,
>
> On Tue, 17 Jan 2017, Max Kirillov wrote:
>
>> Apparently various GIT_* environment variables (most
>> interesting is GIT_DIR but AFAIR there were more) leak to
>> shell session launched from Git Gui's "Git Bash" me
Jeff King writes:
> On Mon, Jan 16, 2017 at 09:33:07PM +0100, Johannes Sixt wrote:
>
>> However, Jeff's patch is intended to catch exactly these cases (not for the
>> cases where this happens accidentally, but when they happen with malicious
>> intent).
>>
>> We are talking about user-provided d
Jeff King writes:
> Documentation/CodingGuidelines says:
>
> - We avoid using braces unnecessarily. I.e.
>
> if (bla) {
> x = 1;
> }
>
>is frowned upon. A gray area is when the statement extends
>over a few lines, and/or you have a lengthy comment atop o
On Tue, Jan 17, 2017 at 11:20:58AM -0800, Junio C Hamano wrote:
> > Documentation/CodingGuidelines says:
> >
> > - We avoid using braces unnecessarily. I.e.
> >
> > if (bla) {
> > x = 1;
> > }
> >
> >is frowned upon. A gray area is when the statement extends
Jeff King writes:
>> I think this is pretty clearly the "gray area" mentioned there. Which
>> yes, does not say "definitely do it this way", but I hope makes it clear
>> that you're supposed to use judgement about readability.
>
> So here's a patch.
>
> I know we've usually tried to keep this fil
Johannes Schindelin writes:
>> > The original code is:
>> >
>> >. "$author_script"
>>
>> [...]
>>
>> If the code in the sequencer.c reads things other than the three
>> variables we ourselves set, and make them into environment variables
>> and propagate to subprocesses (hooks and editors),
Johannes Schindelin writes:
> Hi Junio,
>
> On Sun, 15 Jan 2017, Junio C Hamano wrote:
>
>> * js/prepare-sequencer-more (2017-01-09) 38 commits
>
> I think that it adds confusion rather than value to specifically use a
> different branch name than I indicated in my submission, unless there is a
>
Matthieu Moy writes:
>> But what if bad-A and bad-B have more than one merge bases? We
>> won't know which side the badness came from.
>>
>> o---o---o---bad-A
>> / \ /
>> -Good---o---o---o /
>> \
When looking for documentation for a specific function, you may be tempted
to run
git -C Documentation grep index_name_pos
only to find the file technical/api-in-core-index.txt, which doesn't
help for understanding the given function. It would be better to not find
these functions in the docume
On Tue, Jan 17, 2017 at 11:39:31AM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> >> I think this is pretty clearly the "gray area" mentioned there. Which
> >> yes, does not say "definitely do it this way", but I hope makes it clear
> >> that you're supposed to use judgement about readabil
Stephan Beyer writes:
> This led to the idea to have something like "git stash --continue"[1]
> that would expect the user to "git add" the resolved files (as "git
> status" suggests) but then leads to the expected result, i.e. the index
> being the same as before the conflict, the stash being dr
Jeff King writes:
> That was my general impression, too. But I seem to recall it was you in
> a nearby thread saying that:
>
> if (foo)
> bar();
> else {
> one();
> two();
> }
>
> was wrong. Maybe I misunderstood.
If it were a new code written like the above, that would
Stefan Beller writes:
> When looking for documentation for a specific function, you may be tempted
> to run
>
> git -C Documentation grep index_name_pos
>
> only to find the file technical/api-in-core-index.txt, which doesn't
> help for understanding the given function. It would be better to no
Signed-off-by: Stefan Beller
---
> These placeholders are meant to encourage those people who dove into
> the code to update it, so from that point of view, I think removing
> it is backwards.
Yes, I am currently understanding and writing up documentation for
index_name_pos. If I recall the late
On Tue, Jan 17, 2017 at 12:32:26PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > That was my general impression, too. But I seem to recall it was you in
> > a nearby thread saying that:
> >
> > if (foo)
> > bar();
> > else {
> > one();
> > two();
> > }
> >
> > was
Jeff King writes:
> This test creates a multi-level set of trees, but its
> cleanup routine only removes the top-level tree. After the
> test finishes, the inner tree and the blob it points to
> remain, making the inner tree dangling.
>
> A later test ("cleaned up") verifies that we've removed an
Jeff King writes:
> After checking connectivity, fsck looks through the list of
> any objects we've seen mentioned, and reports unreachable
> and un-"used" ones as dangling. However, it skips any object
> which is not marked as "parsed", as that is an object that
> we _don't_ have (but that someb
On Tue, Jan 17, 2017 at 12:52:43PM -0800, Junio C Hamano wrote:
> > Since the setup code happens inside a subshell, we can't
> > just set a variable for each object. However, we can stuff
> > all of the sha1s into the $T output variable, which is not
> > used for anything except cleanup.
> >
> > S
Jeff King writes:
> Instead of checking reachability from the refs, you can ask
> fsck to check from a particular set of heads. However, the
> error checking here is quite lax. In particular:
>
> 1. It claims lookup_object() will report an error, which
> is not true. It only does a hash lo
Jeff King writes:
> + # Drop the index now; we want to be sure that we
> + # recursively notice that we notice the broken objects
> + # because they are reachable from refs, not because
> + # they are in the index.
Rephrase to reduce redundunt "not
A surprising behavior triggered the bug report in
https://github.com/git-for-windows/git/issues/888: the mere existence of
the config setting "remote.origin.prune" (in this instance, configured
via ~/.gitconfig so that it applies to all repositories) fooled `git
remote rename ` into believing that
One of the really nice features of the ~/.gitconfig file is that users
can override defaults by their own preferred settings for all of their
repositories.
One such default that some users like to override is whether the
"origin" remote gets auto-pruned or not. The user would simply call
Some users like to set `remote.origin.prune = true` in their ~/.gitconfig
so that all of their repositories use that default.
However, our code is ill-prepared for this, mistaking that single entry to
mean that there is already a remote of the name "origin", even if there is
not.
This patch adds
Jeff King writes:
> +static void mark_object_for_connectivity(const unsigned char *sha1)
> +{
> + struct object *obj = lookup_object(sha1);
> +
> + /*
> + * Setting the object type here isn't strictly necessary here for a
> + * connectivity check.
Drop one of these "here"s?
>
On Tue, Jan 17, 2017 at 01:15:57PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > +static void mark_object_for_connectivity(const unsigned char *sha1)
> > +{
> > + struct object *obj = lookup_object(sha1);
> > +
> > + /*
> > +* Setting the object type here isn't strictly necessar
Johannes Schindelin writes:
> - replaced the cross-validation with the Perl script by a patch that
> retires the Perl script instead.
Yup. That makes things a lot simpler. While we try to be careful
during major rewrite, we usually do not go extra careful to leave
two competing implementatio
Jeff King writes:
> Yeah. I obviously was adapting the original text, and I think I left too
> much of the wishy-washy-ness in. As the point of the patch is to avoid
> that, let's take your suggestion. A re-rolled patch is below.
>
> Now the patch is at least self-consistent. The bigger question
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
>
>> These placeholders are meant to encourage those people who dove into
>> the code to update it, so from that point of view, I think removing
>> it is backwards.
>
> Yes, I am currently understanding and writing up documentation for
>
On Tue, Jan 17, 2017 at 10:18:58PM +0100, Johannes Schindelin wrote:
> A surprising behavior triggered the bug report in
> https://github.com/git-for-windows/git/issues/888: the mere existence of
> the config setting "remote.origin.prune" (in this instance, configured
> via ~/.gitconfig so that it
On Tue, Jan 17, 2017 at 10:19:24PM +0100, Johannes Schindelin wrote:
> One of the really nice features of the ~/.gitconfig file is that users
> can override defaults by their own preferred settings for all of their
> repositories.
>
> One such default that some users like to override is whether t
Johannes Schindelin writes:
> It served its purpose, but now we have a builtin difftool. Time for the
> Perl script to enjoy Florida.
>
> Signed-off-by: Johannes Schindelin
> ---
The endgame makes a lot of sense. Both in the cover letter and in
the previous patch you talk about having both in
On Tue, Jan 17, 2017 at 1:43 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>>
>>> These placeholders are meant to encourage those people who dove into
>>> the code to update it, so from that point of view, I think removing
>>> it is backwards.
>>
>> Y
Thanks for the thoughtful response. No need to appologize for the
length, it's a tough problem to solve so I don't expect it to be handled
with a single, short email. :)
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Tuesday, January 17, 2017 1:43 PM
> To: Ben Pea
Thanks for the encouragement, support, and good ideas to look into.
Ben
> -Original Message-
> From: Shawn Pearce [mailto:spea...@spearce.org]
> Sent: Friday, January 13, 2017 4:07 PM
> To: Ben Peart
> Cc: git ; benpe...@microsoft.com
> Subject: Re: [RFC] Add support for downloading blob
On Tuesday, January 17, 2017 04:50:13 PM Ben Peart wrote:
> While large files can be a real problem, our biggest issue
> today is having a lot (millions!) of source files when
> any individual developer only needs a small percentage of
> them. Git with 3+ million local files just doesn't
> perform
Jeff King writes:
>> Let's fix this by telling Git that a remote is not configured unless any
>> fetch/push URL or refspec is configured explicitly.
>
> I notice here that setting a refspec _does_ define a remote. Is there a
> reason you drew the line there, and not at, say, whether it has a URL?
On Tue, Jan 17, 2017 at 2:05 PM, Martin Fick wrote:
> On Tuesday, January 17, 2017 04:50:13 PM Ben Peart wrote:
>> While large files can be a real problem, our biggest issue
>> today is having a lot (millions!) of source files when
>> any individual developer only needs a small percentage of
>> th
From: "Johannes Schindelin"
Hi Philip,
On Mon, 16 Jan 2017, Philip Oakley wrote:
In
https://github.com/git/git/blob/master/git-gui/lib/choose_repository.tcl#L242
the procedure `_unset_recentrepo` is called, however the procedure isn't
declared until line 248. My reading of the various Tcl tut
On Fri, Jan 13, 2017 at 1:31 PM, Johannes Sixt wrote:
> Am 13.01.2017 um 07:57 schrieb Jacob Keller:
>>
>> On Thu, Jan 12, 2017 at 10:43 PM, Johannes Sixt wrote:
>>>
>>> When you write
>>>
>>> git log --branches --exclude=origin/* --remotes
>>>
>>> --exclude=origin/* applies only to --remotes,
Signed-off-by: Stefan Beller
---
cache.h | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index 26632065a5..acc639d6e0 100644
--- a/cache.h
+++ b/cache.h
@@ -605,13 +605,20 @@ extern int remove_index_entry_at(struct index_state *,
int pos);
Signed-off-by: Stefan Beller
---
cache.h | 3 +++
read-cache.c | 1 -
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 270a0d0ea7..26632065a5 100644
--- a/cache.h
+++ b/cache.h
@@ -599,7 +599,10 @@ extern int index_name_pos(const struct index_state *,
co
The two single patches[1] are turned into a series here.
[1] https://public-inbox.org/git/20170117200147.25425-1-sbel...@google.com/
Thanks,
Stefan
Stefan Beller (4):
document index_name_pos
remove_index_entry_at: move documentation to cache.h
document add_[file_]to_index
documentation:
Signed-off-by: Stefan Beller
---
cache.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/cache.h b/cache.h
index 1b67f078dd..270a0d0ea7 100644
--- a/cache.h
+++ b/cache.h
@@ -575,7 +575,22 @@ extern int verify_path(const char *path);
extern int index_dir_exists(struct index_
From: Santiago Torres
This is the sixth iteration of [1][2][3][4][5], and as a result of the
discussion in [5]. The main goal of this patch series is to bring
--format to git tag verification so that upper-layer tools can inspect
the content of a tag and make decisions based on it.
In this re-wo
From: Santiago Torres
Verify-tag now provides --format specifiers to inspect and ensure the
contents of the tag are proper. We add two tests to ensure this
functionality works as expected: the return value should indicate if
verification passed, and the format specifiers must be respected.
Signe
From: Lukas Puehringer
Adding --format to git tag -v mutes the default output of the GPG
verification and instead prints the formatted tag object.
This allows callers to cross-check the tagname from refs/tags with
the tagname from the tag object header upon GPG verification.
The callback functio
From: Santiago Torres
Callers of verify-tag may want to cross-check the tagname from refs/tags
with the tagname from the tag object header upon GPG verification. This
is to avoid tag refs that point to an incorrect object.
Add a --format parameter to git verify-tag to print the formatted tag
obj
From: Lukas Puehringer
Functions that print git object information may require that the
gpg-interface functions be silent. Add GPG_VERIFY_OMIT_STATUS flag and
prevent print_signature_buffer from being called if flag is set.
Signed-off-by: Lukas Puehringer
---
gpg-interface.h | 5 +++--
tag.c
From: Lukas Puehringer
ref-filter functions are useful for printing git object information
using a format specifier. However, some other modules may not want to use
this functionality on a ref-array but only print a single item.
Expose a pretty_print_ref function to create, pretty print and free
From: Santiago Torres
tag -v now supports --format specifiers to inspect the contents of a tag
upon verification. Add two tests to ensure this behavior is respected in
future changes.
Signed-off-by: Santiago Torres
---
t/t7004-tag.sh | 16
1 file changed, 16 insertions(+)
dif
Stefan Beller writes:
> Trying to push with --recurse-submodules=on-demand would run into
> the same problem. To fix this issue
> 1) specifically mention that we looked for branches on the remote.
That makes an incorrect statement ("not found on any remote"---we
did not inspect all of the sa
santi...@nyu.edu writes:
> + if (gpg_verify_tag(sha1, name, flags))
> + return -1;
> +
> +if (fmt_pretty)
> + pretty_print_ref(name, sha1, fmt_pretty);
That's a funny indentation. I'll fix it up locally while queuing.
> +
> + return 0;
> }
From: Jacob Keller
Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper",
2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated
list of strings. However, this was not documented in the
api-parse-options documentation. Add documentation now so that future
developers ma
From: Jacob Keller
Teach git-describe the `--exclude` option which will allow specifying
a glob pattern of tags to ignore. This can be combined with the
`--match` patterns to enable more flexibility in determining which tags
to consider.
For example, suppose you wish to find the first official r
santi...@nyu.edu writes:
> -static int for_each_tag_name(const char **argv, each_tag_name_fn fn)
> +static int for_each_tag_name(const char **argv, each_tag_name_fn fn,
> + void *cb_data)
> {
> const char **p;
> char ref[PATH_MAX];
> int had_error = 0;
> unsign
From: Jacob Keller
Teach `--match` to be accepted multiple times, accumulating a list of
patterns to match into a string list. Each pattern is inclusive, such
that a tag need only match one of the provided patterns to be
considered for matching.
This extension is useful as it enables more flexib
From: Jacob Keller
Teach git name-rev to take a string list of patterns from --refs instead
of only a single pattern. The list of patterns will be matched
inclusively, such that a ref only needs to match one pattern to be
included. If a ref will only be excluded if it does not match any of the
pa
santi...@nyu.edu writes:
> From: Santiago Torres
>
> This is the sixth iteration of [1][2][3][4][5], and as a result of the
> discussion in [5]. The main goal of this patch series is to bring
> --format to git tag verification so that upper-layer tools can inspect
> the content of a tag and make
From: Jacob Keller
Extend name-rev further to support matching refs by adding `--exclude`
patterns. These patterns will limit the scope of refs by excluding any
ref that matches at least one exclude pattern. Checking the exclude refs
shall happen first, before checking the include --refs patterns
On Tue, Jan 17, 2017 at 3:42 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Trying to push with --recurse-submodules=on-demand would run into
>> the same problem. To fix this issue
>> 1) specifically mention that we looked for branches on the remote.
>
> That makes an incorrect statem
From: Jacob Keller
Commit c8ba16391655 ("parse-options: add OPT_STRING_LIST helper",
2011-06-09) added the OPT_STRING_LIST as a way to accumulate a repeated
list of strings. However, this was not documented in the
api-parse-options documentation. Add documentation now so that future
developers ma
From: Jacob Keller
** v3 fixes a minor typo in one of the test cases, so please ignore v2
I left the interdiff as between v1 and v3 instead of v2 **
Teach git describe and git name-rev the ability to match multiple
patterns inclusively. Additionally, teach these commands to also accept
negati
From: Jacob Keller
Extend name-rev further to support matching refs by adding `--exclude`
patterns. These patterns will limit the scope of refs by excluding any
ref that matches at least one exclude pattern. Checking the exclude refs
shall happen first, before checking the include --refs patterns
From: Jacob Keller
Teach `--match` to be accepted multiple times, accumulating a list of
patterns to match into a string list. Each pattern is inclusive, such
that a tag need only match one of the provided patterns to be
considered for matching.
This extension is useful as it enables more flexib
From: Jacob Keller
Teach git name-rev to take a string list of patterns from --refs instead
of only a single pattern. The list of patterns will be matched
inclusively, such that a ref only needs to match one pattern to be
included. If a ref will only be excluded if it does not match any of the
pa
From: Jacob Keller
Teach git-describe the `--exclude` option which will allow specifying
a glob pattern of tags to ignore. This can be combined with the
`--match` patterns to enable more flexibility in determining which tags
to consider.
For example, suppose you wish to find the first official r
From: Jacob Keller
Teach git describe and git name-rev the ability to match multiple
patterns inclusively. Additionally, teach these commands to also accept
negative patterns to exclude any refs which match.
The pattern lists for positive and negative patterns are inclusive. This
means that for
santi...@nyu.edu writes:
> @@ -428,9 +443,12 @@ int cmd_tag(int argc, const char **argv, const char
> *prefix)
> if (filter.merge_commit)
> die(_("--merged and --no-merged option are only allowed with
> -l"));
> if (cmdmode == 'd')
> - return for_each_tag_na
Stefan Beller writes:
> On Tue, Jan 17, 2017 at 3:42 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> Trying to push with --recurse-submodules=on-demand would run into
>>> the same problem. To fix this issue
>>> 1) specifically mention that we looked for branches on the remote.
>>
On Tue, Jan 17, 2017 at 4:15 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Tue, Jan 17, 2017 at 3:42 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
Trying to push with --recurse-submodules=on-demand would run into
the same problem. To fix this issue
1) sp
When looking for documentation for a specific function, you may be tempted
to run
git -C Documentation grep index_name_pos
only to find the file technical/api-in-core-index.txt, which doesn't
help for understanding the given function. It would be better to not find
these functions in the docume
In the future we want to support working tree operations within submodules,
e.g. "git checkout --recurse-submodules", which will update the submodule
to the commit as recorded in its superproject. In the submodule the
unpack-tree operation is carried out as usual, but the reporting to the
user need
A bug report: I noticed that "git diff --ignore-space-change --stat"
lists files with only whitespace differences as having changed with 0
differing lines. This is inconsistent with the behavior without --
stat, which doesn't list such files at all. (Same behavior with all
the --ignore*space* fla
"make update-po" fails because a previously untranslated string
has now been translated:
Updating po/sv.po
po/sv.po:1388: duplicate message definition...
po/sv.po:380: ...this is the location of the first definition
Remove the duplicate message definition.
Reported-by: Ju
Hi!
For a very long time I had wanted to get the output of diff to include
blame information as well (to see when something was added/removed).
I just created a very small (and rough) tool for that purpose. It's
written in python and if it gets to something better than a small
tool, I think it co
1 - 100 of 102 matches
Mail list logo
