On Wed, Oct 10, 2018 at 10:41:45AM +, Ævar Arnfjörð Bjarmason wrote:
> Improve the error message added in f8aae12034 ("push: allow
> unqualified dest refspecs to DWIM", 2008-04-23), which before this
> change looks like this:
>
> $ git push avar v2.19.0^{commit}:newbranch -n
> error:
On Wed, Oct 10, 2018 at 10:41:44AM +, Ævar Arnfjörð Bjarmason wrote:
> Mark up the error(...) messages in remote.c for translation. The likes
> of "unable to push to unqualified destination" are relatively big
> parts of the UI, i.e. error messages shown when "git push" fails.
>
> I don't
On Wed, Oct 10, 2018 at 07:27:32PM +, Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
>
> This was
On Wed, Oct 10, 2018 at 09:51:52AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
> > I'm just saying it's hard in this case to remove one piece without the
> > whole Jenga tower collapsing, and it's probably a good idea in some of
> > these cases to pester the user about what
On Wed, Oct 10, 2018 at 09:59:16AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 10 2018, Junio C Hamano wrote:
>
> > * jk/drop-ancient-curl (2017-08-09) 5 commits
> > - http: #error on too-old curl
> > - curl: remove ifdef'd code never used with curl >=7.19.4
> > - http: drop
On Fri, Sep 21, 2018 at 05:57:33PM +0200, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/diff.c b/diff.c
> index 140d0e86df..5256b9eabc 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2093,23 +2093,25 @@ static void diff_words_flush(struct emit_callback
> *ecbdata)
> }
> }
>
> -static void
On Wed, Oct 10, 2018 at 09:33:00AM +, Naja Melan wrote:
> I ran into a strange bug. In the following script the commit at the end will
> fail with:
>
> > The following paths are ignored by one of your .gitignore files:
> > .etckeeper
> > Use -f if you really want to add them.
>
> Note
On Wed, Oct 10, 2018 at 01:44:41PM +0200, SZEDER Gábor wrote:
> > So that's really weird and counter-intuitive, since we should be doing
> > strictly less work. I know that spatch tries to parallelize itself,
> > though from my tests, 1.0.4 does not. I wonder if the version in Travis
> > differs
bitmap).
Signed-off-by: Jeff King
---
t/helper/test-tree-bitmap.c | 105 +++-
1 file changed, 91 insertions(+), 14 deletions(-)
diff --git a/t/helper/test-tree-bitmap.c b/t/helper/test-tree-bitmap.c
index 6f8833344a..36f19ed464 100644
--- a/t/helper/test-tree
it diff-tree --stdin --name-only -t
The one difference is the sort order: git's diff output is
in tree-sort order, so a subtree "foo" sorts like "foo/",
which is after "foo.bar". Whereas the bitmap path list has a
true byte sort, which puts "foo.bar" aft
Signed-off-by: Jeff King
---
Makefile| 1 +
t/helper/test-tree-bitmap.c | 167
2 files changed, 168 insertions(+)
create mode 100644 t/helper/test-tree-bitmap.c
diff --git a/Makefile b/Makefile
index 13e1c52478..f6e823f2d6 100644
On Tue, Oct 09, 2018 at 05:14:50PM -0400, Jeff King wrote:
> Hmph. It really sounds like we could do better with a custom RLE
> solution. But that makes me feel like I'm missing something, because
> surely I can't invent something better than the state of the art in a
> simple though
On Tue, Oct 09, 2018 at 03:03:08PM -0400, Derrick Stolee wrote:
> > I wonder if Roaring does better here.
>
> In these sparse cases, usually Roaring will organize the data as "array
> chunks" which are simply lists of the values. The thing that makes this
> still compressible is that we store
On Tue, Oct 09, 2018 at 09:34:43PM +0200, SZEDER Gábor wrote:
> Creating the Bloom filter is slw. Running it on git.git takes
> about 23s on my hardware, while
>
> git log --format='%H%n%P' --name-only --all >/dev/null
>
> gathers all the information necessary for that in about 5.3s.
On Tue, Oct 09, 2018 at 09:48:20AM -0400, Derrick Stolee wrote:
> [I snipped all of the parts about bloom filters that seemed entirely
> reasonable to me ;) ]
> > Imagine we have that list. Is a bloom filter still the best data
> > structure for each commit? At the point that we have the
but it seems to want to apply our whole conversation as the
commit message.
You may want to repost one more time with this subject in the email
subject line to fix that and to get the maintainer's attention. Feel
free to add my:
Reviewed-by: Jeff King
after your signoff. Thanks for sticking with this topic!
-Peff
On Tue, Oct 09, 2018 at 08:09:32AM +0900, Junio C Hamano wrote:
> Julia Lawall writes:
>
> >> Doing the same for -S is much harder at the machinery level, as it
> >> performs its thing without internally running "diff" twice, but just
> >> counts the number of occurrences of 'foo'---that is
On Fri, Oct 05, 2018 at 09:54:13PM +0200, SZEDER Gábor wrote:
> Runtimes tend to fluctuate quite a bit more on Travis CI compared to
> my machine, but not this much, and it seems to be consistent so far.
>
> After scripting/querying the Travis CI API a bit, I found that from
> the last 100
On Sat, Oct 06, 2018 at 10:42:57AM +0200, René Scharfe wrote:
> > That's OK, too, assuming people would actually want to use it. I'm also
> > OK shipping this (with the "make -j" fix you suggested) and seeing if
> > anybody actually complains. I assume there are only a handful of people
> >
On Mon, Oct 08, 2018 at 11:09:20AM -0700, Taylor Blau wrote:
> Attached is (what I anticipate to be) the final re-roll of my series to
> introduce 'core.alternateRefsCommand' and 'core.alternateRefsPrefixes'
> in order to limit the ".have" advertisement when pushing over protocol
> v1 to a
On Mon, Oct 08, 2018 at 02:29:47PM -0400, Derrick Stolee wrote:
> > > > But I'm afraid it will take a while until I get around to turn it into
> > > > something presentable...
> > > Do you have the code pushed somewhere public where one could take a look?
> > > I
> > > Do you have the code
On Fri, Oct 05, 2018 at 11:22:31PM +0200, René Scharfe wrote:
> > diff --git a/fetch-pack.c b/fetch-pack.c
> > index 53914563b5..c0a1b80f4c 100644
> > --- a/fetch-pack.c
> > +++ b/fetch-pack.c
> > @@ -606,6 +606,12 @@ static void filter_refs(struct fetch_pack_args *args,
> >
On Fri, Oct 05, 2018 at 10:13:34PM +0200, René Scharfe wrote:
> >> -{
> >> - /*
> >> - * Note that this only looks at the ref lists the first time it's
> >> - * called. This works out in filter_refs() because even though it may
> >> - * add to "newlist" between calls, the additions will
On Fri, Oct 05, 2018 at 10:01:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > There's unfortunately not a fast way of doing that. One option would be
> > to keep a counter of "ungraphed commit objects", and have callers update
> > it. Anybody admitting a pack via index-pack or unpack-objects can
On Fri, Oct 05, 2018 at 04:00:12PM -0400, Derrick Stolee wrote:
> On 10/5/2018 3:47 PM, Jeff King wrote:
> > On Fri, Oct 05, 2018 at 03:41:40PM -0400, Derrick Stolee wrote:
> >
> > > > So can we really just take (total_objects - commit_graph_objects) and
> >
On Fri, Oct 05, 2018 at 03:41:40PM -0400, Derrick Stolee wrote:
> > So can we really just take (total_objects - commit_graph_objects) and
> > compare it to some threshold?
>
> The commit-graph only stores the number of _commits_, not total objects.
Oh, right, of course. That does throw a monkey
On Fri, Oct 05, 2018 at 09:42:49PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > that I imagine will create a lot of new problems. (We're just now
> > allowing C99 -- I don't even want to think about what kind of compiler
> > issues we'll run into on antique systems trying to use C++).
>
> ...But
On Fri, Oct 05, 2018 at 09:36:28PM +0200, René Scharfe wrote:
> Am 05.10.2018 um 21:08 schrieb Jeff King:
> > On Fri, Oct 05, 2018 at 08:48:27PM +0200, René Scharfe wrote:
> >> +#define DEFINE_SORT(name, type, compare) \
> >> +static int com
On Fri, Oct 05, 2018 at 09:12:09PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'm not wild about declaring functions inside macros, just because it
> > makes tools like ctags like useful (but I have certainly been guilty of
> > it myself). I'd also worry that taking "code" as a macro parameter
On Fri, Oct 05, 2018 at 09:45:47AM -0400, Derrick Stolee wrote:
> My misunderstanding was that your proposed change to gc computes the
> commit-graph in either of these two cases:
>
> (1) The auto-GC threshold is met.
>
> (2) There is no commit-graph file.
>
> And what I hope to have instead
On Fri, Oct 05, 2018 at 08:48:27PM +0200, René Scharfe wrote:
> If the comparison function has proper types then we need to declare a
> version with void pointer parameters as well to give to qsort(3). I
> think using cast function pointers is undefined. Perhaps like this?
I think it's
On Fri, Oct 05, 2018 at 08:39:04PM +0200, SZEDER Gábor wrote:
> > It should still be a net win, since the total CPU seems to drop by a
> > factor of 3-4.
>
> Well, that's true when you have unlimited resources... :) or it's
> true even then, when I have just enough resources, but not much
>
On Fri, Oct 05, 2018 at 08:50:50PM +0200, SZEDER Gábor wrote:
> On Fri, Oct 05, 2018 at 12:59:01PM -0400, Jeff King wrote:
> > On Fri, Oct 05, 2018 at 04:53:35PM +, Keller, Jacob E wrote:
> >
> > > > Are we OK with saying 1.3-1.8GB is necessary to run coccicheck
On Fri, Oct 05, 2018 at 04:53:35PM +, Keller, Jacob E wrote:
> > Are we OK with saying 1.3-1.8GB is necessary to run coccicheck? That
> > doesn't feel like an exorbitant request for a developer-only tool these
> > days, but I have noticed some people on the list tend to have lousier
> >
On Fri, Oct 05, 2018 at 06:44:25PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Some version of the former. Ones where we haven't found any (or much of)
> useful deltas yet. E.g. say I had a repository with a lot of files
> generated by this command at various points in the history:
>
> dd
On Fri, Oct 05, 2018 at 12:59:02AM +0200, René Scharfe wrote:
> We could also do something like this to reduce the amount of manual
> casting, but do we want to? (Macro at the bottom, three semi-random
> examples at the top.)
> [...]
> diff --git a/git-compat-util.h b/git-compat-util.h
> index
On Fri, Oct 05, 2018 at 02:40:48PM +0200, SZEDER Gábor wrote:
> On Thu, Oct 04, 2018 at 07:17:47PM -0700, Jacob Keller wrote:
> > Junio, do you want me to update the commit message on my side with the
> > memory concerns? Or could you update it to mention memory as a noted
> > trade off.
>
> We
On Fri, Oct 05, 2018 at 05:52:14PM +0800, Tao Qingyun wrote:
> diff --git a/builtin/branch.c b/builtin/branch.c
> index c396c41533..52aad0f602 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -222,10 +222,11 @@ static int delete_branches(int argc, const char **argv,
> int force, int
On Fri, Oct 05, 2018 at 04:20:27PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I.e. something to generate the .gitattributes file using this format:
>
> https://git-scm.com/docs/gitattributes#_packing_objects
>
> Some stuff is obvious, like "*.gpg binary -delta", but I'm wondering if
> there's some
On Thu, Oct 04, 2018 at 03:52:05PM -0700, Jonathan Tan wrote:
> > Or I am even OK with leaving the existing tablesize
> > check. It is a little intimate with the implementation details, but I
> > suspect that if oidset were to change (e.g., to initialize the buckets
> > immediately), the problem
On Thu, Oct 04, 2018 at 05:05:37PM +0200, René Scharfe wrote:
> Two new patches to avoid using oidset internals in fetch-pack:
>
> fetch-pack: factor out is_unmatched_ref()
> fetch-pack: load tip_oids eagerly iff needed
>
> Unchanged patch:
>
> khash: factor out kh_release_*
>
>
On Thu, Oct 04, 2018 at 02:38:13PM -0700, Jonathan Tan wrote:
> > - if ((allow_unadvertised_object_request &
> > -(ALLOW_TIP_SHA1 | ALLOW_REACHABLE_SHA1)) ||
> > - tip_oids_contain(_oids, unmatched, newlist,
> > ->old_oid)) {
On Thu, Oct 04, 2018 at 05:09:39PM +0200, René Scharfe wrote:
> tip_oids_contain() lazily loads refs into an oidset at its first call.
> It abuses the internal (sub)member .map.tablesize of that oidset to
> check if it has done that already.
>
> Determine if the oidset needs to be populated
On Thu, Oct 04, 2018 at 02:48:33AM -0400, Jeff King wrote:
> On Thu, Oct 04, 2018 at 07:56:44AM +0200, René Scharfe wrote:
>
> > > As the comment above notes, I think we're really looking at the case
> > > where this gets populated on the first call, but not subsequ
On Thu, Oct 04, 2018 at 07:56:44AM +0200, René Scharfe wrote:
> > As the comment above notes, I think we're really looking at the case
> > where this gets populated on the first call, but not subsequent ones. It
> > might be less hacky to use a "static int initialized" here. Or if we
> > want to
On Fri, Aug 17, 2018 at 10:26:05PM -0700, Jonathan Nieder wrote:
> > Of course, I could be completely wrong about people using this. Maybe
> > svn-fe builds are just completely broken on my system, and maybe people
> > really do use testsvn::. But if so, they certainly aren't talking about
> > it
On Wed, Oct 03, 2018 at 01:42:39PM +0200, Rasmus Villemoes wrote:
> v2: Added patches 2 and 3, made "git cmd --help" unconditionally (no
> config option, no delay) redirect to the aliased command's help,
> preserve pre-existing behaviour of the spelling "git help cmd".
>
> v3: Add some
On Thu, Oct 04, 2018 at 02:34:17AM +0700, Dimitri Kopriwa wrote:
> I have replaced the way I fill the git credentials store, I have verify
> ~/.git-credentials and information are there, the ~/.gitconfig look fine
> too.
>
> I still have 401 error when reading from that file.
>
> This is the
On Wed, Oct 03, 2018 at 03:16:39PM +0200, René Scharfe wrote:
> Performance of a command that mainly checks for duplicate objects using
> an oidset, with master and Clang 6.0.1:
>
> $ cmd="./git-cat-file --batch-all-objects --unordered --buffer
> --batch-check='%(objectname)'"
>
> $
On Wed, Oct 03, 2018 at 12:08:15PM -0700, Stefan Beller wrote:
> I share these concerns in a slightly more abstract way, as
> I would bucket the actions into two separate bins:
>
> One bin that throws away information.
> this would include removing expired reflog entries (which
> I do not think
On Wed, Oct 03, 2018 at 02:59:34PM -0400, Derrick Stolee wrote:
> > They don't help yet, and there's no good reason to enable bitmaps for
> > clients. I have a few patches that use bitmaps for things like
> > ahead/behind and --contains checks, but the utility of those may be
> > lessened quite a
On Wed, Oct 03, 2018 at 08:47:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 03 2018, Stefan Beller wrote:
>
> >> So we wouldn't be spending 5 minutes repacking linux.git right after
> >> cloning it, just ~10s generating the commit graph, and the same would
> >> happen if you rm'd
On Thu, Oct 04, 2018 at 01:12:11AM +0700, Dimitri Kopriwa wrote:
> Thanks for your reply. I have activated GIT_TRACE_CURL=1 and I can see that
> the request is failing 401.
>
> I can't see which token is used and using what header ?
>
> The log say:
>
> 17:50:26.414654 http.c:657
On Wed, Oct 03, 2018 at 09:06:38PM +0700, Dimitri Kopriwa wrote:
> 18:25:52.940307 git.c:659 trace: exec: git-credential-store
> erase
> 18:25:52.940365 run-command.c:637 trace: run_command:
> git-credential-store erase
> remote: HTTP Basic: Access denied
> fatal:
On Wed, Oct 03, 2018 at 08:24:14AM +0200, Rasmus Villemoes wrote:
> > The comment probably needs to spell out that exclude_guides
> > is the same as your "we were invoked as...".
>
> Will do. That will also make the string --exclude-guides (i.e., with a
> dash) appear in the comment, making it
On Wed, Oct 03, 2018 at 01:28:20AM -0400, _g e r r y _ _l o w r y _ wrote:
> The tutorial "may" have be called something like "Try Git";
> however, I can not find it at try.github.io and other places where i have
> looked.
Unfortunately, Try Git seems to have been shut down. I don't know of any
On Mon, Sep 24, 2018 at 08:27:47PM -0400, Noam Postavsky wrote:
> > So I think this is doing the right thing. I'm not sure if there's a
> > better way to explain "dashless" or not.
>
> I've updated the comments and renamed a few variables, see if that helps.
Yeah, I really like your
On Sat, Sep 29, 2018 at 03:30:21PM +1200, Paul Wratt wrote:
> --
> ...
> Total 21 (delta 8), reused 0 (delta 0)
> error: RPC failed; result=56, HTTP code = 0
> fatal: The remote end hung up unexpectedly
> fatal: The remote end hung up unexpectedly
> Everything up-to-date
>
On Mon, Oct 01, 2018 at 01:21:07PM +0200, Rasmus Villemoes wrote:
> This documents the existing behaviour of "git help cmd" when cmd is an
> alias, as well as providing a hint to use the "git cmd --help" form to
> be taken directly to the man page for the aliased command.
Good idea.
> diff
On Mon, Oct 01, 2018 at 01:21:06PM +0200, Rasmus Villemoes wrote:
> Most git commands respond to -h anywhere in the command line, or at
> least as a first and lone argument, by printing the usage
> information. For aliases, we can provide a little more information that
> might be useful in
On Mon, Oct 01, 2018 at 01:21:05PM +0200, Rasmus Villemoes wrote:
> As discussed in the thread for v1 of this patch [1] [2], this changes the
> rules for "git foo --help" when foo is an alias.
>
> (0) When invoked as "git help foo", we continue to print the "foo is
> aliased to bar" message and
On Mon, Oct 01, 2018 at 07:23:58PM -0700, Taylor Blau wrote:
> +core.alternateRefsCommand::
> + When advertising tips of available history from an alternate, use the
> shell to
> + execute the specified command instead of linkgit:git-for-each-ref[1].
> The
> + first argument is the
On Tue, Oct 02, 2018 at 10:59:28AM -0700, Stefan Beller wrote:
> > Generally speaking, it
> > seems impossible to UNLEAK when dying, since we don't know what we have
> > allocated higher up in the call-stack.
>
> I do not understand; I thought UNLEAK was specifically for the purpose of
> die()
On Tue, Oct 02, 2018 at 12:44:09PM -0700, Stefan Beller wrote:
> > My worry is that one of these would seem to be true:
> >
> > * UNLEAK is unsuitable for the job. Whenever we have a `die()` as we do
> > here, we can UNLEAK the variables we know of, but we can't do anything
> > about the
for
style).
Signed-off-by: Jeff King
---
Jake: I was surprised that this was not a "patch 2" on top of your
earlier coccicheck patch. Apologies if you were planning to send it out.
This doesn't conflict with anything in "pu", so it's a reasonable time
to apply it. There are a
On Tue, Oct 02, 2018 at 01:58:10PM -0700, Jacob Keller wrote:
> On Tue, Oct 2, 2018 at 1:31 PM Jeff King wrote:
> > Actually, I guess we do not need to save $? at all, since we have only a
> > single process to care about. So even simpler:
> >
> >
On Tue, Oct 02, 2018 at 01:00:21PM -0700, Jacob Keller wrote:
> > > This is nearly a 4x decrease in the time required to run make
> > > coccicheck. This is due to the overhead of restarting spatch for every
> > > file. By processing all files at once, we can amortize this startup cost
> > >
On Tue, Oct 02, 2018 at 12:16:42PM -0700, Jacob Keller wrote:
> make coccicheck is used in order to apply coccinelle semantic patches,
> and see if any of the transformations found within contrib/coccinelle/
> can be applied to the current code base.
>
> Pass every file to a single invocation of
On Tue, Oct 02, 2018 at 09:05:32PM +0200, René Scharfe wrote:
> > The reason hashmap.c was added was to avoid open addressing. ;)
> Because efficient removal of elements is easier to implement with
> chaining, according to 6a364ced49 (add a hashtable implementation that
> supports O(1) removal).
On Tue, Oct 02, 2018 at 11:26:19AM +0200, Jayesh Badwaik wrote:
> Is there a way to create git pretty format that sets the color to one
> color (say red) only when the commit is unsigned or the signature
> cannot be verified?
Not currently. There are placeholders to show the signing information
On Tue, Oct 02, 2018 at 06:56:29AM +, peter.doll...@mt.com wrote:
> Please see my original observation below.
> Is it possible, to extend the git-log syntax in the way, that it
> accepts the short -L option (without :file) of blame in unique cases
> (only one file is logged or respectively
On Tue, Oct 02, 2018 at 11:43:50AM +0200, Stanisław Drozd wrote:
> I'm trying to write a fast-import-based git remote helper, but I'm not
> sure what the output of the `list` command should look like. How can I
> find an example of the format in action?
There's some documentation in "git help
On Tue, Oct 02, 2018 at 10:28:38AM +, Jose Gisbert wrote:
> Moreover, assuming that solution #1 will generally work and the facts that:
>
> - I think it would be possible to us to recover from a corrupted repository
> somehow easily. Couldn't we, for instance, reset from a failed push and
On Mon, Oct 01, 2018 at 09:15:53PM +0200, René Scharfe wrote:
> Am 28.08.2018 um 01:03 schrieb Jeff King:
> > On Sun, Aug 26, 2018 at 01:37:41PM +0200, René Scharfe wrote:
> >> So it seems worth it.
> >
> > Hmm, that really does. Which is a shame, because I hoped
On Mon, Oct 01, 2018 at 09:16:07PM +0200, René Scharfe wrote:
> Am 21.09.2018 um 07:22 schrieb Junio C Hamano:
> > * cc/delta-islands (2018-08-16) 7 commits
> [...]
> > * jk/pack-delta-reuse-with-bitmap (2018-08-21) 6 commits
>
> Not sure if it's the interaction of the two topics or if only one
On Mon, Oct 01, 2018 at 08:12:49AM +, Jose Gisbert wrote:
> My proposal consists to import the svn repository to git using git svn and set
> receive.denyCurrentBranch to updateInstead. Then install pre-receive and
> post-receive hooks and set that repository as the central repository for git
On Sat, Sep 29, 2018 at 10:27:15PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > And I think this has to be stderr. We're polluting the output of the
> > aliased command with our extra message, so we have two choices:
> >
> > 1. Pollute stderr, and r
On Sat, Sep 29, 2018 at 12:06:38PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Wow, what's old is new again. Here's more or less the same patch from
> > 2012:
> >
> > https://public-inbox.org/git/20120407033417.ga13...@sigill.intra.peff.net/
> >
On Sat, Sep 29, 2018 at 11:31:08AM -0700, Junio C Hamano wrote:
> > The only funny thing is that you have to "dereference" the iterator like
> > this:
> >
> > struct list_head *pos;
> > struct actual_thing *item;
> > ...
> > item = list_entry(pos, struct actual_thing, list_member);
> >
>
On Sat, Sep 29, 2018 at 10:39:54AM -0700, Junio C Hamano wrote:
> Suppose "git foo" is aliased to a command "git bar".
>
> The best case is when "git bar -h" knows that it is asked to give us
> a short usage. We get "foo is aliased to bar" followed by the short
> usage for "bar" and everything
On Fri, Sep 28, 2018 at 10:18:05AM +0200, Rasmus Villemoes wrote:
> > it, and then it is up to the alias to handle "-h" sensibly.
>
> I'd be nervous about doing this, though, especially if we introduce this
> without a new opt-in config option (which seems to be the direction the
>
On Fri, Sep 28, 2018 at 12:37:16PM -0400, Kyle Hubert wrote:
> When calling the Git Credential Helper that is set in the git config,
> the get command can return a credential. Git immediately turns around
> and calls the store command, even though that credential was just
> retrieved by the
On Fri, Sep 28, 2018 at 05:43:59PM +0200, Martin Ågren wrote:
> Instead of running `test "foo" = "$(bar)"`, we prefix the whole thing
> with `echo`. Comparing to nearby tests makes it clear that this is just
> debug leftover. This line has actually been modified four times since it
> was
On Fri, Sep 28, 2018 at 11:29:32AM -0700, Daniel Lo wrote:
> I was reviewing the tformat parameters on:
> https://git-scm.com/docs/git-log (middle of the page).
>
> Specifically: %<|(): make the next placeholder take at least until
> Nth columns, padding spaces on the right if necessary
>
> I
On Fri, Sep 28, 2018 at 09:50:14AM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: CodingGuidelines: document the API in *.h files
>
> It makes it harder to let the API description and the reality drift
> apart if the doc is kept close to the implementation or the header
> of the API. We
On Fri, Sep 28, 2018 at 10:14:12AM -0700, Stefan Beller wrote:
> > I think other high-level concepts that are _not_ APIs (e.g., file
> > formats, protocol, etc) could go into technical/.
>
> That is what I meant with high level concepts. Anything that talks
> about or implies the existence of a
On Fri, Sep 28, 2018 at 01:11:26PM -0700, Junio C Hamano wrote:
> > I am mildly against giving names to obvious ones.
>
> Just to make sure nobody listening from sidelines do not
> misunderstand, ones like getwholeline_fd() that takes more than one
> parameter with the same time is a prime
On Fri, Sep 28, 2018 at 03:05:57PM -0700, Taylor Blau wrote:
> > > For example, to advertise only tags, a caller using
> > > 'core.alternateRefsCommand' would have to do:
> > >
> > > $ git config core.alternateRefsCommand ' \
> > > git -C "$1" for-each-ref refs/tags
On Fri, Sep 28, 2018 at 03:04:10PM -0700, Taylor Blau wrote:
> > Well, you also need to pass the path so it knows which repo to look at.
> > Which I think is the primary reason we do it, but behaving differently
> > for each alternate is another option.
>
> Yeah. I think that the clearer
On Sat, Sep 29, 2018 at 08:50:56AM +0200, Nguyễn Thái Ngọc Duy wrote:
> Document for uploadpack.packObjectsHook is added in [1] and consists
> of two paragraphs, the second one is quite important about where this
> variable can stay.
>
> When the paragraph about uploadpack.allowFilter is added
On Thu, Sep 27, 2018 at 09:25:45PM -0700, Taylor Blau wrote:
> The recently-introduced "core.alternateRefsCommand" allows callers to
> specify with high flexibility the tips that they wish to advertise from
> alternates. This flexibility comes at the cost of some inconvenience
> when the caller
On Thu, Sep 27, 2018 at 09:25:42PM -0700, Taylor Blau wrote:
> Let the repository that has alternates configure this command to avoid
> trusting the alternate to provide us a safe command to run in the shell.
> To behave differently on each alternate (e.g., only list tags from
> alternate A, only
On Thu, Sep 27, 2018 at 09:25:39PM -0700, Taylor Blau wrote:
> To list alternate references, 'read_alternate_refs' creates a child
> process running 'git for-each-ref' in the alternate's Git directory.
>
> Prepare to run other commands besides 'git for-each-ref' by introducing
> and moving the
> From: Jeff King
Pretty sure that isn't right. :)
The preferred way to send a patch with a different author is to have
actual email be "From:" you, but then include a:
From: Jeff King
as the first line of the body (which git-am will then pick up).
git-send-email will do
if there are multiple alternates.
The users of this interface really only care about seeing some ref tips,
since that promises that the alternate has the full commit graph
reachable from there. So let's keep the information we pass back to the
bare minimum.
Signed-off-by: Jeff King
---
builtin/receive-pack.c
On Thu, Sep 27, 2018 at 04:27:32PM -0700, Jonathan Nieder wrote:
> > There are different opinions on how to document an API properly.
> > Discussion turns out nobody disagrees with documenting new APIs on the
> > function level in the header file and high level concepts in
> >
On Thu, Sep 27, 2018 at 10:35:11PM +0100, Rafael Ascensão wrote:
> git branch has --format, but there's no way (at least to my knowledge)
> to define a value in gitconfig to be used by $git branch.
Oh, you're right. I was thinking of the branch.sort we just added in
v2.19.
I agree that having
On Thu, Sep 27, 2018 at 02:22:49PM -0700, Junio C Hamano wrote:
> The only comment I have is that I strongly suspect we will regret if
> we used an overly bland "worktree" to a rather narrrow "is this ref
> checked out in any worktree?" when we notice we want to learn other
> things that are
On Thu, Sep 27, 2018 at 03:35:59PM -0400, Jeff King wrote:
> now, we could do:
>
> %(if)%(HEAD)%(then)* %(color:bold green)
> %(else)%(if)%(worktree)%(then)+ %(color:green)
> %(else) %(end)%(end)
>
> (respecting the user's color config, of course, rather tha
On Thu, Sep 27, 2018 at 08:28:04PM +0100, Rafael Ascensão wrote:
> On Thu, Sep 27, 2018 at 02:17:08PM -0400, Jeff King wrote:
> > Do we want to limit this to git-branch, though? Ideally any output you
> > get from git-branch could be replicated with for-each-ref (or with
>
401 - 500 of 13736 matches
Mail list logo
