On Fri, Aug 10, 2018 at 07:04:08PM +0100, Paul Jolly wrote:
> I've tried to skim through the archive, but I couldn't find anything
> that describes what I'm seeing. Apologies if that's because I missed
> something/used the wrong search terms, or this is an intentional
> change in behaviour.
>
>
On Fri, Aug 10, 2018 at 06:43:07PM +0200, Johannes Schindelin wrote:
> > > Correct. But I am more worried about the "mixed/overwriting"
> > > breakage, if there is one; it means we may need to be prepared for
> > > systems that lack O_APPEND that works correctly. I initially just
> > > assumed
On Thu, Aug 09, 2018 at 01:49:52PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Are you sure that it's not well-defined? We open the path with O_APPEND,
> > which means every write() will be atomically positioned at the end of
> > file. So we would neve
On Thu, Aug 09, 2018 at 02:53:42PM -0700, Elijah Newren wrote:
> On Thu, Aug 9, 2018 at 2:44 PM Jeff King wrote:
> > > The error message isn't quite as good, but does the user really need
> > > all the names of the file? If so, we gave them enough information t
On Thu, Aug 09, 2018 at 02:52:29PM -0700, Stefan Beller wrote:
> > In many cases you can just do:
> >
> > while (list->nr) {
> > work_on(list->items[list->nr - 1]);
> > list_remove(list, list->nr - 1);
> > }
> >
> > and then all of those memory ownership issues like:
>
>
On Thu, Aug 09, 2018 at 02:40:58PM -0700, Elijah Newren wrote:
> > I worry that the false positives make this a non-starter. I mean, if
> > clone creates files 'A' and 'B' (both equal) and then tries to create
> > 'b', would the collision code reports that 'b' collided with 'A' because
> > that
On Thu, Aug 09, 2018 at 02:29:32PM -0700, Junio C Hamano wrote:
> >> +struct string_list_item *string_list_pop(struct string_list *list)
> >> +{
> >> + if (list->nr == 0)
> >> + return 0;
> >
> > return NULL, not 0.
>
> It is OK to return NULL, which may make the caller a bit
On Thu, Aug 09, 2018 at 05:14:16PM -0400, Jeff Hostetler wrote:
> > Clever. You might still run into false positives when there is
> > duplicated content in the repository (especially, say, zero-length
> > files). But the fact that you only do the hashing on known duplicates
> > helps with that.
On Thu, Aug 09, 2018 at 02:08:56PM -0700, Junio C Hamano wrote:
> > Correct. But I am more worried about the "mixed/overwriting"
> > breakage, if there is one; it means we may need to be prepared for
> > systems that lack O_APPEND that works correctly. I initially just
> > assumed that it was
On Wed, Aug 08, 2018 at 03:33:23PM -0700, Brandon Williams wrote:
> Commit 0383bbb901 (submodule-config: verify submodule names as paths,
> 2018-04-30) introduced some checks to ensure that submodule names don't
> include directory traversal components (e.g. "../").
>
> This addresses the
On Thu, Aug 09, 2018 at 01:04:43PM +0200, Bartosz Konikiewicz wrote:
> Hi there!
>
> I hope that the subject of my message (i.e. the question) is
> exhaustive enough, so I'll just stick to reproducing my issue.
>
> Steps to reproduce:
>
> 1. Create a new file.
> 2. Stage the file.
> 3. Add the
On Thu, Aug 09, 2018 at 11:40:27AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I guess leaving it serves as a sort of cross-check if gpg would return a
> > zero exit code but indicate in the status result that the signature was
> > not good. Sort of a belt
On Thu, Aug 09, 2018 at 10:35:24AM -0700, Johannes Schindelin via GitGitGadget
wrote:
> The culprit is that two processes try simultaneously to write to the same
> file specified via GIT_TRACE_PACKET, and it is not well defined how that
> should work, even on Linux.
Are you sure that it's not
On Thu, Aug 09, 2018 at 10:25:52AM -0700, Stefan Beller wrote:
> On Thu, Aug 9, 2018 at 12:39 AM Martin Ågren wrote:
> >
> > On 9 August 2018 at 00:17, Stefan Beller wrote:
> > > +int oid_array_remove_if(struct oid_array *array,
> > > + for_each_oid_fn fn,
> > > +
On Thu, Aug 09, 2018 at 08:30:25AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > There was a patch at the start of this thread, but it specifically
> > checks for "sigc->result == U". That's probably OK, since I think it
> > restores the behav
On Wed, Aug 08, 2018 at 10:45:49PM -0400, Paul Smith wrote:
> On Wed, 2018-08-08 at 14:24 -0400, Jeff King wrote:
> > If so, can you try running it under gdb and getting a stack trace?
> > Something like:
> >
> > gdb git
> > [and then inside gdb...]
> >
On Thu, Aug 09, 2018 at 01:43:02AM +, brian m. carlson wrote:
> On Wed, Aug 08, 2018 at 05:59:43PM -0700, Junio C Hamano wrote:
> > "brian m. carlson" writes:
> >
> > >> FWIW, I'm on board with returning non-zero in any case where gpg would.
> > >
> > > I think that's probably the best
On Thu, Aug 09, 2018 at 01:58:05AM -0400, Eric Sunshine wrote:
> On Wed, Aug 8, 2018 at 6:50 PM Jeff King wrote:
> > On Tue, Aug 07, 2018 at 04:21:31AM -0400, Eric Sunshine wrote:
> > > +# Swallowing here-docs with arbitrary tags requires a bit of finesse.
> >
On Wed, Aug 08, 2018 at 05:41:10PM -0700, Junio C Hamano wrote:
> > If we have an equivalence-class hashmap and feed it inodes (or again,
> > some system equivalent) as the keys, we should get buckets of
> > collisions.
>
> I guess one way to get "some system equivalent" that can be used as
>
lity reasons, it is thus better to iterate in
> pack order, instead of index order. Teach for_each_object_in_pack() to
> iterate in pack order by first creating a reverse index.
>
> This is based off work by Jeff King.
>
> Signed-off-by: Jonathan Tan
> ---
> After writing
On Mon, Aug 06, 2018 at 08:24:25PM +, Tacitus Aedifex wrote:
> the older patch set suggested the idea of using PEM strings to match up the
> signature payload with a certain signing tool. i can't tell if they mean
> the 'pre-ecapsulation boundary' (e.g. '-BEGIN FOO-') or if they mean
On Sat, Aug 04, 2018 at 10:43:46AM +0200, Karel Kočí wrote:
> > I think the only sensible thing is to err on the conservative side, and
> > return non-zero if we saw _any_ invalid signature.
> >
> > I will note, though, that just checking the exit code of `verify-tag`
> > isn't really that
On Tue, Aug 07, 2018 at 04:21:30AM -0400, Eric Sunshine wrote:
> This series improves chainlint's robustness when faced with the sort of
> unusual shell coding in contrib/subtree/t7900 which triggered a
> false-positive, as reported by Jonathan[1]. Jonathan has already
> rewritten[2] that code to
On Tue, Aug 07, 2018 at 04:21:31AM -0400, Eric Sunshine wrote:
> diff --git a/t/chainlint.sed b/t/chainlint.sed
> index 5f0882cb38..bd76c5d181 100644
> --- a/t/chainlint.sed
> +++ b/t/chainlint.sed
> @@ -61,6 +61,22 @@
> # "else", and "fi" in if-then-else likewise must not end with "&&", thus
>
On Wed, Aug 08, 2018 at 02:35:18PM -0700, Junio C Hamano wrote:
> Back when we removed `git apply --index-info` in 2007, we forgot to
> adjust the documentation for update-index that reads its output.
>
> Let's reorder the description of three formats to present the other
> two formats that are
On Wed, Aug 08, 2018 at 03:48:04PM -0400, Jeff Hostetler wrote:
> > ce_match_stat() may not be a very good measure to see if two paths
> > refer to the same file, though. After a fresh checkout, I would not
> > be surprised if two completely unrelated paths have the same size
> > and have same
On Wed, Aug 08, 2018 at 01:35:30PM -0400, Paul Smith wrote:
> Thanks for the note! Unhappily for me none of these operations seem to
> find any actionable problems...
> [...]
Drat.
One other option is that it _could_ be related to the "old unreachable
objects that are reachable from recent
On Wed, Aug 08, 2018 at 10:30:11AM -0400, Paul Smith wrote:
> I recently upgraded from Git 2.9.2 to 2.18.0 (note, I have no
> particular reason to believe this is related just passing info). I'm
> running on Linux (64bit Ubuntu 18.04.1 but I've compiled Git myself
> from source, I'm not using
On Tue, Aug 07, 2018 at 04:23:04PM -0700, Jonathan Tan wrote:
> > Do we already have an access to the in-core reverse index for the
> > pack at this point in the code?
>
> As far as I can tell, no. These patches construct the list of promisor
> objects in repack.c (which does not use the
On Tue, Aug 07, 2018 at 08:58:51PM -0700, Brady Trainor wrote:
> If I am reading the git book or manual (https://git-scm.com/), and zoom
> in, and/or have browser sized to a fraction of the screen, I cannot see
> all the text, and have to horizontally scroll back and forth to read at
> that zoom.
On Mon, Aug 06, 2018 at 02:34:45PM -0400, Noam Postavsky wrote:
> On 30 June 2018 at 08:47, Noam Postavsky
> wrote:
>
> > I'm still having trouble getting a big picture understanding of how
> > the graph struct relates the what gets drawn on screen, but through
> > some poking around with the
On Sat, Jun 30, 2018 at 08:47:16AM -0400, Noam Postavsky wrote:
> I'm still having trouble getting a big picture understanding of how
> the graph struct relates the what gets drawn on screen, but through
> some poking around with the debugger + trial & error, I've arrived at
> a new patch which
On Mon, Aug 06, 2018 at 10:11:19AM -0700, Jonathan Nieder wrote:
> > We're developers ourselves, and we interact with new developers that we
> > want to help. But there are masses of people[1] building Git who are
> > _not_ developers, and want the default to be as robust as possible.
> >
On Mon, Aug 06, 2018 at 11:25:07AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +while test $# -gt 0
> > +do
> > + case "$1" in
> > + -j)
> > + parallel=${1#-j} ;;
>
> This is curious. Did you mean "-j*)" o
On Fri, Aug 03, 2018 at 04:52:05PM -0400, Jeff King wrote:
> I wrote this up for my own use after our discussion in [1]. I'm not sure
> if it's too ugly for inclusion, or if it might be helpful to others.
> I've only just written it, but my plan is to try to run it on anything I
> sub
On Mon, Aug 06, 2018 at 06:40:14PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Responding to the thread in general, perhaps people would like this more
> if we turned DEVELOPER=1 DEVOPTS=no-error on by default?
>
> That's basically why I added it in 99f763baf5 ("Makefile: add a DEVOPTS
> to suppress
On Mon, Aug 06, 2018 at 08:16:47AM -0700, Junio C Hamano wrote:
> It's a bit dissapointing that we cannot express personal preference
> in config.mak ;-)
Try this:
diff --git a/Makefile b/Makefile
index e7994888e8..36bddff3be 100644
--- a/Makefile
+++ b/Makefile
@@ -1119,6 +1119,11 @@ ifdef
On Mon, Aug 06, 2018 at 08:01:00AM -0700, Jonathan Nieder wrote:
> Jeff King wrote:
>
> > 3. Default to number of CPUs, which is what a lot of other threading
> > in Git does. Unfortunately getting that from the shell is
> > non-trivial. I'm OK with $(grep -c
On Mon, Aug 06, 2018 at 06:07:06PM +0200, SZEDER Gábor wrote:
> 'git ls-files' has the options '--exclude', '--exclude-from',
> '--exclude-per-directory', and '--exclude-standard', which all work
> fine. However, it also allows the negated version of all these four
> options, and they definitely
On Sun, Aug 05, 2018 at 08:53:19PM +0200, Christian Couder wrote:
> - 'layer' is used in add_to_write_order() which is called from many
> places in add_descendants_to_write_order() and compute_write_order()
> for example like this:
>
> for (s = DELTA_SIBLING(e); s; s =
On Mon, Aug 06, 2018 at 10:44:14AM +0200, Christian Couder wrote:
> Taking a look at how we use regexec() in our code base, it looks like
> it might be better to use regexec_buf() defined in
> "git-compat-util.h".
>
> I am not completely sure about that because apply.c has:
>
> status =
On Mon, Aug 06, 2018 at 09:39:55AM -0400, Jeff King wrote:
> 3. Default to number of CPUs, which is what a lot of other threading
> in Git does. Unfortunately getting that from the shell is
> non-trivial. I'm OK with $(grep -c ^processor /proc/cpuinfo), but
> people
On Sun, Aug 05, 2018 at 08:49:31PM +, brian m. carlson wrote:
> > +parallel=8
>
> I'm not sure -j8 is a great default. There are still a lot of
> two-core/four-thread machines out there, such as my laptop (from 2016).
> Maybe we should default this to 1 unless -j is provided, like make
On Sun, Aug 05, 2018 at 04:52:31PM -0400, Jeff King wrote:
> On Sun, Aug 05, 2018 at 01:23:05AM -0400, Eric Sunshine wrote:
>
> > A simpler approach, without the portability concerns of -A, would be
> > to remove the "." and ".." lines from the top of the l
On Sun, Aug 05, 2018 at 01:23:05AM -0400, Eric Sunshine wrote:
> A simpler approach, without the portability concerns of -A, would be
> to remove the "." and ".." lines from the top of the listing:
>
> ls -f1 "$1" | sed '1,2d'
>
> If we're worried about -f not being sufficiently portable,
On Fri, Aug 03, 2018 at 09:38:34PM +, Tacitus Aedifex wrote:
> I'm looking at the existing commit signing and verification
> integration and it is all GPG specific. I'm interested in refactoring
> the code to have a generic signing/verifying interface so that "drivers"
> for other signing
On Fri, Aug 03, 2018 at 05:33:17PM -0400, Eric Sunshine wrote:
> > +OPTIONS_SPEC="\
> > +doc-diff [-- diff options]
>
> Should this be?
>
> doc-diff [] [-- ]
I suppose so. Frankly I only added that line to appease git-sh-options
anyway.
> > +--
> > +j parallel argument to pass to
ll-man" working, this script should work
for generating a diff between any two versions, whether they
include this script or not.
Signed-off-by: Jeff King
---
I wrote this up for my own use after our discussion in [1]. I'm not sure
if it's too ugly for inclusion, or if it might be helpful to ot
On Fri, Aug 03, 2018 at 02:23:17PM -0400, Jeff Hostetler wrote:
> > Maybe. It might not work as ino_t. Or it might be expensive to get. Or
> > maybe it's simply impossible. I don't know much about Windows. Some
> > searching implies that NTFS does have a "file index" concept which is
> >
On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote:
> > This is not a deviation. GPG correctly recognizes difference between
> > trusted,
> > untrusted and unknown levels. git on the other hand does not. Well it did
> > until
> > the commit a4cc18f29. That one removed GPG exit code
On Fri, Aug 03, 2018 at 03:01:15PM +0300, Vadim Belov wrote:
> 1. This merges successfully without squash:
> git checkout origin/master
> git merge ${PR-Branch}
> git push origin HEAD:master
> git push origin --delete ${PR-Branch}
Right, this is a normal merge.
> 2. This closes the PR, but
On Fri, Aug 03, 2018 at 03:25:08PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I'd be a bit careful with that, though, as the definition of "new" is
> > vague there.
> >
> > For example, completing a thin pack may mean that the receiver creates a
> > copy of a base object found in the main repo.
On Mon, Jul 30, 2018 at 08:25:16PM +0200, SZEDER Gábor wrote:
> > diff --git a/sequencer.c b/sequencer.c
> > index 1c035ceec7..d257903db0 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
>
> > +int write_basic_state(struct replay_opts *opts, const char *head_name,
> > + const
On Thu, Aug 02, 2018 at 11:21:44PM -0700, Jonathan Nieder wrote:
> > diff --git a/Makefile b/Makefile
> > index d616c0412..86fdcf567 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -2674,15 +2674,17 @@ COCCI_SOURCES = $(filter-out
> > sha1collisiondetection/%,$(C_SOURCES))
> > else
> >
On Thu, Aug 02, 2018 at 08:29:48PM -0700, Jonathan Nieder wrote:
> (cc-ing peff, config whiz)
Actually, this is all about the configset caching layer, which I never
really worked on. This is mostly from Tanay Abhra ,
who was a GSoC student mentored by Matthieu Moy .
That said...
> > +
> > +/*
On Fri, Aug 03, 2018 at 02:56:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Any Git commands you run should therefore find objects from either
> > location, but any writes would go to the quarantine (most notably, Git's
> > own index-pack/unpack-objects processes, which is the point of the
> >
On Thu, Aug 02, 2018 at 03:46:08PM -0400, Eric Sunshine wrote:
> On Thu, Aug 2, 2018 at 2:02 PM Jeff King wrote:
> > On Thu, Aug 02, 2018 at 01:55:22PM +0200, SZEDER Gábor wrote:
> > > This approach uses $(eval), which we haven't used in any of our
> > > Makef
On Thu, Aug 02, 2018 at 02:14:30PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I also wonder if Windows could return some other file-unique identifier
> > that would work in place of an inode here. That would be pretty easy to
> > swap in via an #ifdef's he
On Sun, Jul 29, 2018 at 05:46:17PM +0200, Duy Nguyen wrote:
> tOn Sun, Jul 29, 2018 at 5:36 PM Nguyễn Thái Ngọc Duy
> wrote:
> >
> > These extra comments should be make it easier to understand how to use
> > locks in pack-objects delta search code. For reference, see
>
> Side note. I wonder if
On Sun, Jul 29, 2018 at 05:36:05PM +0200, Nguyễn Thái Ngọc Duy wrote:
> These extra comments should be make it easier to understand how to use
> locks in pack-objects delta search code. For reference, see
>
> 8ecce684a3 (basic threaded delta search - 2007-09-06)
> 384b32c09b (pack-objects: fix
On Thu, Aug 02, 2018 at 12:24:54PM -0700, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > On Thu, Aug 2, 2018 at 1:37 PM Junio C Hamano wrote:
> >> Johannes Schindelin writes:
> >> > ACK!
> >>
> >> Did you write a buggy caller that would have been caught or helped
> >> with this change?
On Thu, Aug 02, 2018 at 11:47:30AM -0700, Stefan Beller wrote:
> > +static int module_config(int argc, const char **argv, const char *prefix)
> > +{
> > + if (argc < 2 || argc > 3)
> > + die("submodule--helper config takes 1 or 2 arguments: name
> > [value]");
> > +
> > +
On Thu, Aug 02, 2018 at 09:27:31AM -0700, Junio C Hamano wrote:
> > OK so we're going back to the original way of checking that we check
> > out the different files on the same place (because fs is icase) and
> > try to collect all paths for reporting, yes? I can give it another go
> > (but of
On Wed, Aug 01, 2018 at 02:58:50AM +0200, René Scharfe wrote:
> Am 31.07.2018 um 23:06 schrieb Junio C Hamano:
> > Jeff King writes:
> >
> >> On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> >> ...
> >> So here it is fixed, and wi
On Tue, Jul 31, 2018 at 02:06:12PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> > ...
> > So here it is fixed, and with a commit message. I'm not happy to omit a
> > regression test, b
On Thu, Aug 02, 2018 at 12:58:52PM -0500, Liam Decker wrote:
> I've been working on a git hook in golang recently. However, the library I
> was using did not support a possible quarantine directory, which I would
> use for my hook.
>
> I have been trying to find out how git finds this incoming
On Thu, Aug 02, 2018 at 02:01:55PM -0400, Jeff King wrote:
> I suspect if we go with the one-spatch-per-source route, though, that we
> could do this just with regular make rules.
Yeah, it's pretty straightforward:
diff --git a/Makefile b/Makefile
index d616c0412..86fdcf567
On Thu, Aug 02, 2018 at 01:55:22PM +0200, SZEDER Gábor wrote:
> Let's add a bit of Makefile metaprogramming to generate finer-grained
> make targets applying one semantic patch to only a single source file,
> and specify these as dependencies of the targets applying one semantic
> patch to all
On Thu, Aug 02, 2018 at 08:31:57AM -0700, Junio C Hamano wrote:
> > diff --git a/parse-options.c b/parse-options.c
> > index 7db84227ab..fadfc6a833 100644
> > --- a/parse-options.c
> > +++ b/parse-options.c
> > @@ -660,7 +660,8 @@ int parse_options(int argc, const char **argv, const
> > char
On Wed, Aug 01, 2018 at 01:13:20PM -0700, Jonathan Tan wrote:
> When a user fetches:
> - at least one up-to-date ref and at least one non-up-to-date ref,
> - using HTTP with protocol v0 (or something else that uses the fetch
>command of a remote helper)
> some refs might not be updated
On Tue, Jul 31, 2018 at 04:23:43PM -0700, Jonathan Tan wrote:
> > > Because transport_fetch_refs() filters the refs sent to the transport,
> > > it cannot just report the transport's result directly, but first needs
> > > to readd the excluded refs, pretending that they are fetched. However,
> >
; Signed-off-by: Jeff King
> > ---
> > match-trees.c | 43 ++-
> > 1 file changed, 26 insertions(+), 17 deletions(-)
Sorry, I meant to actually add a:
Reported-by: George Shammas
here.
-Peff
On Tue, Jul 31, 2018 at 01:12:14PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> > ...
> >> collapses two (or more) paths if we go that way. We only need to
> >> report "
On Tue, Jul 31, 2018 at 12:12:58PM -0700, Junio C Hamano wrote:
> Elijah Newren writes:
>
> > Is it worth attempting to also warn about paths that only differ in
> > UTF-normalization on relevant MacOS systems?
>
> I hate to bring up a totally different approach this late in the
> party, but I
On Mon, Jul 30, 2018 at 03:56:01PM -0700, Jonathan Tan wrote:
> Commit 989b8c4452 ("fetch-pack: put shallow info in output parameter",
> 2018-06-28) allows transports to report the refs that they have fetched
> in a new out-parameter "fetched_refs". If they do so,
> transport_fetch_refs() makes
On Tue, Jul 31, 2018 at 02:55:51PM -0400, Eric Sunshine wrote:
> > I hesitate to make any suggestion here, as I think we may have passed
> > a point of useful cost/benefit in sinking more time into this script.
> > But...is switching to awk or perl an option? Our test suite already
> > depends on
On Tue, Jul 31, 2018 at 01:23:04PM -0400, Jeff King wrote:
> On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > +...
> > > + } else if (cmp > 0) {
> > > /* path2 does no
On Tue, Jul 31, 2018 at 10:17:15AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > +...
> > + } else if (cmp > 0) {
> > /* path2 does not appear in one */
> > + score += score_missi
On Tue, Jul 31, 2018 at 08:53:23AM -0700, Junio C Hamano wrote:
> George Shammas writes:
>
> > Bisecting around, this might be the commit that introduced the breakage.
> >
> > https://github.com/git/git/commit/d8febde
>
> Interesting. I've never used the "-s subtree" strategy without
>
On Tue, Jul 31, 2018 at 11:03:17AM -0400, George Shammas wrote:
> Bisecting around, this might be the commit that introduced the breakage.
>
> https://github.com/git/git/commit/d8febde
>
> I really hope that it hasn't been broken for 5 years and I am just doing
> something wrong.
On Mon, Jul 30, 2018 at 05:38:06PM -0400, Eric Sunshine wrote:
> > I wonder if it should look for something like [A-Z][A-Z_]* to catch
> > all of these.
>
> I considered that, but it doesn't handle nested here-docs, which we
> actually have in the test suite. For instance, from
On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote:
> I'm trying to search my git log history for a particular term -
> "unobtrusive" - so I run this command:
>
> git log -S unobtrusive --oneline
>
> When I do this, this is displayed and I'm in an interactive less terminal or
>
I've noticed for the past couple of weeks that some of my fetches don't
seem to actually update refs, but a follow-up fetch will. I finally
managed to catch it in the act and track it down. It bisects to your
989b8c4452 (fetch-pack: put shallow info in output parameter,
2018-06-27).
A
On Sun, Jul 29, 2018 at 07:26:41AM +0200, Duy Nguyen wrote:
> > strcasecmp() will only catch a subset of the cases. We really need to
> > follow the same folding rules that the filesystem would.
>
> True. But that's how we handle case insensitivity internally. If a
> filesytem has more
On Fri, Jul 27, 2018 at 08:52:59PM -0700, Stefan Beller wrote:
> > > + for key in "v.a.r" "V.A.r" "v.A.r" "V.a.r"
> > > + do
> > > + cp testConfig testConfig_actual &&
> > > + git config -f testConfig_actual v.a.r value2 &&
> > > + test_cmp
On Sat, Jul 28, 2018 at 07:11:05AM +0200, Duy Nguyen wrote:
> > It might be enough to just issue a warning and give an advise() hint
> > that tells the user what's going on. Then they can decide what to do
> > (hide both paths, or just work in the index, or move to a different fs,
> > or complain
On Fri, Jul 27, 2018 at 10:34:20AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >> $ git rebase --onto HEAD @{-1}~3 @{-1}^0
> >
> > Interesting. I'd have probably done it with an interactive rebase:
> >
> > $ git rebase -i HEAD~4
> > [
On Fri, Jul 27, 2018 at 10:22:09AM -0700, Stefan Beller wrote:
> > That would solve the problem that fetching torvalds/linux from GitHub
> > yields a bigger pack than fetching it from kernel.org. But again, it's
> > making that root fork weirdly magical. People who fetch solely from
> > other
On Sat, Jul 28, 2018 at 06:45:43AM +0200, Duy Nguyen wrote:
> > I agree throwing a real exception would be bad. But how about detecting
> > the problem and trying our best to keep the repo in somewhat usable
> > state like this?
> >
> > This patch uses sparse checkout to hide all those paths that
On Tue, Jul 24, 2018 at 10:20:05AM -0700, Stefan Beller wrote:
> So in my understanding we have a "common base pack" and specific
> packs on top for each "island".
Sort of. This is another hacky part. The islands themselves are
generally just about forbidding deltas, and not any particular kind
On Tue, Jul 24, 2018 at 09:47:29AM -0700, Junio C Hamano wrote:
> > +/*
> > + * Allocate a new bitmap; if "old" is not NULL, the new bitmap will be a
> > copy
> > + * of "old". Otherwise, the new bitmap is empty.
> > + */
> > +static struct island_bitmap *island_bitmap_new(const struct
On Tue, Jul 24, 2018 at 09:19:27AM -0700, Junio C Hamano wrote:
> Christian Couder writes:
>
> > From: Jeff King
> >
> > As get_delta_base() will be used outside 'packfile.c' in
> > a following commit, let's make it non static and let's
> > declare it in 'pa
On Sun, Jul 22, 2018 at 07:48:33AM +0200, Christian Couder wrote:
> + /*
> + * We process only trees, as commits and tags have already been handled
> + * (and passed their marks on to root trees, as well. We must make sure
> + * to process them in descending tree-depth order so
On Thu, Jul 26, 2018 at 12:01:34PM -0700, Junio C Hamano wrote:
> Tejun Heo writes:
>
> > I should have explained the use case better.
>
> No, you did not need to. I was not saying the feature is not useful.
> I was only saying that "explain where in the history X sits" command
> (i.e.
On Thu, Jul 26, 2018 at 10:33:27AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So here's a replacement for just patch 1 (I'm assuming this creates less
> > work than re-posting them all, but it may not be if Junio prefers
> > dealing with a whole new mbox
On Thu, Jul 26, 2018 at 09:57:42AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Jul 25, 2018 at 03:13:37PM -0700, Junio C Hamano wrote:
> >
> >> * jk/banned-function (2018-07-24) 5 commits
> >> - banned.h: mark strncpy() as banned
> &
On Wed, Jul 25, 2018 at 03:13:37PM -0700, Junio C Hamano wrote:
> * jk/banned-function (2018-07-24) 5 commits
> - banned.h: mark strncpy() as banned
> - banned.h: mark sprintf() as banned
> - banned.h: mark strcat() as banned
> - automatically ban strcpy()
> - Merge branch 'sb/blame-color'
On Thu, Jul 26, 2018 at 02:58:40AM -0400, Jeff King wrote:
> On Tue, Jul 24, 2018 at 01:20:58PM -0400, Eric Sunshine wrote:
>
> > On Tue, Jul 24, 2018 at 5:26 AM Jeff King wrote:
> > > 1. We'll only trigger with -Wimplicit-function-declaration
> > >
On Tue, Jul 24, 2018 at 01:20:58PM -0400, Eric Sunshine wrote:
> On Tue, Jul 24, 2018 at 5:26 AM Jeff King wrote:
> > 1. We'll only trigger with -Wimplicit-function-declaration
> > (and only stop compilation with -Werror). These are
> > generally enabled b
On Wed, Jul 25, 2018 at 08:41:00PM +0200, Torsten Bögershausen wrote:
> On Tue, Jul 24, 2018 at 06:51:39AM -0400, Jeff King wrote:
> > When we initially added the strbuf_readlink() function in
> > b11b7e13f4 (Add generic 'strbuf_readlink()' helper function,
> > 2008-12-17),
901 - 1000 of 13736 matches
Mail list logo
