Hi,
Michael Muré wrote:
> I released today git-bug, a distributed bug tracker that embeds in
> git. It use git's internal storage to store bugs information in a way
> that can be merged without conflict. You can push/pull to the normal
> git remote you are already using to interact with other
Hi,
Jeff King wrote:
> The code in vcs-svn was started in 2010 as an attempt to
> build a remote-helper for interacting with svn repositories
> (as opposed to git-svn). However, we never got as far as
> shipping a mature remote helper, and the last substantive
> commit was e99d012a6bc in 2012.
checkout with the -p switch uses the "add interactive" framework which
is written in Perl. Add a PERL prerequisite to skip this test when built
with NO_PERL.
Signed-off-by: CB Bailey
---
t/t2024-checkout-dwim.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On Fri, Aug 17, 2018 at 03:57:18PM -0700, Stefan Beller wrote:
> On Fri, Aug 17, 2018 at 2:06 PM Jeff King wrote:
> >
> > When we serve a fetch, we pass the "wants" and "haves" from
> > the fetch negotiation to pack-objects. That tells us not
> > only which objects we need to send, but we also
I really like this idea. I've often wanted an integrated bug database like
this. My solution has always been to have a subrepo storing bug reports and
coments in .txt files and then using bash porcelain scripts to make a git-like
interface. I think I like this better. My only nit is Go. That
On Fri, Aug 17, 2018 at 2:06 PM Jeff King wrote:
>
> When we serve a fetch, we pass the "wants" and "haves" from
> the fetch negotiation to pack-objects. That tells us not
> only which objects we need to send, but we also use the
> boundary commits as "preferred bases": their trees and blobs
>
On Fri, Aug 17, 2018 at 03:39:29PM -0700, Stefan Beller wrote:
> > diff --git a/pack-bitmap.h b/pack-bitmap.h
> > index 4555907dee..02a60ce670 100644
> > --- a/pack-bitmap.h
> > +++ b/pack-bitmap.h
> > @@ -50,6 +50,13 @@ int rebuild_existing_bitmaps(struct bitmap_index *,
> > struct packing_data
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Quite a many topics have
> diff --git a/pack-bitmap.h b/pack-bitmap.h
> index 4555907dee..02a60ce670 100644
> --- a/pack-bitmap.h
> +++ b/pack-bitmap.h
> @@ -50,6 +50,13 @@ int rebuild_existing_bitmaps(struct bitmap_index *, struct
> packing_data *mapping
> khash_sha1 *reused_bitmaps, int
On Fri, Aug 17, 2018 at 3:20 PM Matthew DeVore wrote:
>
> On Fri, Aug 17, 2018 at 2:42 PM Stefan Beller wrote:
> >
> > On Wed, Aug 15, 2018 at 4:23 PM Matthew DeVore wrote:
> > >
> > > Teach list-objects the "tree:0" filter which allows for filtering
> > > out all tree and blob objects (unless
On Fri, Aug 17, 2018 at 2:42 PM Stefan Beller wrote:
>
> On Wed, Aug 15, 2018 at 4:23 PM Matthew DeVore wrote:
> >
> > Teach list-objects the "tree:0" filter which allows for filtering
> > out all tree and blob objects (unless other objects are explicitly
> > specified by the user). The purpose
On Fri, Aug 17, 2018 at 3:04 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > This improves colors of the range-diff, see last patch for details.
>
> How does this relate to your other "color with range-diff" topic
> that is still in flight? This supersedes it? Builds on it?
>
Hi everyone,
I released today git-bug, a distributed bug tracker that embeds in
git. It use git's internal storage to store bugs information in a way
that can be merged without conflict. You can push/pull to the normal
git remote you are already using to interact with other people. Normal
code
Stefan Beller writes:
> This improves colors of the range-diff, see last patch for details.
How does this relate to your other "color with range-diff" topic
that is still in flight? This supersedes it? Builds on it?
Something else?
Thanks.
On Wed, Aug 15, 2018 at 4:23 PM Matthew DeVore wrote:
>
> Teach list-objects the "tree:0" filter which allows for filtering
> out all tree and blob objects (unless other objects are explicitly
> specified by the user). The purpose of this patch is to allow smaller
> partial clones.
>
> The name
When we serve a fetch, we pass the "wants" and "haves" from
the fetch negotiation to pack-objects. That tells us not
only which objects we need to send, but we also use the
boundary commits as "preferred bases": their trees and blobs
are candidates for delta bases, both for reusing on-disk
deltas
When we do a bitmap walk, we save the result, which
represents (WANTs & ~HAVEs); i.e., every object we care
about visiting in our walk. However, we throw away the
haves bitmap, which can sometimes be useful, too. Save it
and provide an access function so code which has performed a
walk can query
A server with bitmapped packs can serve a clone very
quickly. However, fetches are not necessarily made any
faster, because we spend a lot less time in object traversal
(which is what bitmaps help with) and more time finding
deltas (because we may have to throw out on-disk deltas if
the client
The main objective of scripts in the perf framework is to
run "test_perf", which measures the time it takes to run
some operation. However, it can also be interesting to see
the change in the output size of certain operations.
This patch introduces test_size, which records a single
numeric output
This will let us reuse the code when we add new values to
aggregate besides times.
Signed-off-by: Jeff King
---
t/perf/aggregate.perl | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/t/perf/aggregate.perl b/t/perf/aggregate.perl
index
About half of test_perf() is boilerplate preparing to run
_any_ test, and the other half is specifically running a
timing test. Let's split it into two functions, so that we
can reuse the boilerplate in future commits.
Signed-off-by: Jeff King
---
Best viewed with "-w".
t/perf/perf-lib.sh | 61
This series more aggressively reuses on-disk deltas to serve fetches
when reachability bitmaps tell us a more complete picture of what the
client has. That saves server CPU and results in smaller packs. See the
final patch for numbers and more discussion.
It's a resurrection of this very old
This improves colors of the range-diff, see last patch for details.
it is also available via
git fetch https://github.com/stefanbeller/git sb/range-diff-better-colors
Thanks,
Stefan
Stefan Beller (3):
diff.c: add --output-indicator-{new, old, context}
range-diff: make use of different
The range-diff coloring is a bit fuzzy when it comes to special lines of
a diff, such as indicating new and old files with +++ and ---, as it
would pickup the first character and interpret it for its coloring, which
seems annoying as in regular diffs, these lines are colored bold via
This will prove useful in range-diff in a later patch as we will be able to
differentiate between adding a new file (that line is starting with +++
and then the file name) and regular new lines.
It could also be useful for experimentation in new patch formats, i.e.
we could teach git to emit
This change itself only changes the internal communication and should
have no visible effect to the user. We instruct the diff code that
produces the inner diffs to use other markers instead of the
usual markers for new, old and context lines.
Signed-off-by: Stefan Beller
---
range-diff.c | 20
On Fri, Aug 17, 2018 at 9:27 PM Andrei Rybak wrote:
>
> On 17/08/18 19:39, SZEDER Gábor wrote:
> >
> > See, we have quite a few tests that extract repetitive common tasks
> > into helper functions, which sometimes includes preparing the expected
> > results and running 'test_cmp', e.g. something
Andrei Rybak writes:
> I think it would be a good trade-off to allow these helper functions to skip
> checking emptiness of arguments for test_cmp. Such patch will require only
> s/test_cmp/&_allow_empty/ for these helper functions and it will help catch
> cases as bogus test in t5310.
>
> I'll
On Fri, Aug 17, 2018 at 06:16:45PM +0200, Nguyễn Thái Ngọc Duy wrote:
The whole patch looks good to me.
(I was just sending a different version, but your version is better :-)
One minor remark, should the line
warning: the following paths have collided
start with a capital letter:
Warning: the
Hi Jeff,
Jeff King wrote:
> .gitignore | 1 -
> Makefile | 22 --
> contrib/svn-fe/.gitignore | 4 -
> contrib/svn-fe/Makefile| 105 ---
> contrib/svn-fe/svn-fe.c| 18 --
> contrib/svn-fe/svn-fe.txt | 71 -
>
On 17/08/18 19:39, SZEDER Gábor wrote:
>
> See, we have quite a few tests that extract repetitive common tasks
> into helper functions, which sometimes includes preparing the expected
> results and running 'test_cmp', e.g. something like this
> (oversimplified) example:
>
> check_cmd () {
>
The code in vcs-svn was started in 2010 as an attempt to
build a remote-helper for interacting with svn repositories
(as opposed to git-svn). However, we never got as far as
shipping a mature remote helper, and the last substantive
commit was e99d012a6bc in 2012.
We do have a git-remote-testsvn,
Junio C Hamano writes:
> This loop can run out of bytes in src in search of non-space before
> n gets to zero or negative, and when that happens ...
>
>> +for (i = 0; i < ARRAY_SIZE(keywords); i++) {
>> +struct keyword_entry *p = keywords + i;
>> +int len =
Han-Wen Nienhuys writes:
> +/*
> + * Optionally highlight one keyword in remote output if it appears at the
> start
> + * of the line. This should be called for a single line only, which is
> + * passed as the first N characters of the SRC array.
> + */
> +static void
On Fri, Aug 17, 2018 at 7:33 PM Jeff King wrote:
>
> On Fri, Aug 17, 2018 at 10:07:36AM -0700, Junio C Hamano wrote:
>
> > Junio C Hamano writes:
> >
> > > It is a bit sad that
> > >
> > > - if (E)
> > > FREE_AND_NULL(E);
> > >
> > > is not sufficient to catch it. Shouldn't we be
On Fri, Aug 17, 2018 at 10:20:36AM -0700, Junio C Hamano wrote:
> I highly suspect that the above was written in that way to reduce
> the indentation level, but the right way to reduce the indentation
> level, if it bothers readers too much, is to make the whole thing
> inside the above if
On Fri, Aug 17, 2018 at 01:33:08PM -0400, Jeff King wrote:
> > And revised even more to also spell "E" as "E != NULL" (and "!E" as
> > "E == NULL"), which seems to make a difference, which is even more
> > sad. I do not want to wonder if I have to also add "NULL == E" and
> > other variants, so
On Fri, Aug 17, 2018 at 01:39:51PM -0400, Jeff King wrote:
> > I wonder if there is a way to "relax" a pattern where these semantically
> > equivalent cases can all be covered automatically. I don't know enough
> > about the tool to say.
>
> Hmm. They seem to call these "standard isomorphisms":
On Fri, Aug 17, 2018 at 12:36 AM Junio C Hamano wrote:
>
> Andrei Rybak writes:
>
> > On 14/08/18 13:47, SZEDER Gábor wrote:
> >> ... both
> >> invocations produce empty 'pack{a,b}.objects' files, and the
> >> subsequent 'test_cmp' happily finds those two empty files identical.
> >
> > Is
On Fri, Aug 17, 2018 at 10:07:36AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > It is a bit sad that
> >
> > - if (E)
> > FREE_AND_NULL(E);
> >
> > is not sufficient to catch it. Shouldn't we be doing the same for
> > regular free(E) as well? IOW, like the attached
Nguyễn Thái Ngọc Duy writes:
> I still don't trust magic st_ino zero, or core.checkStat being zero
> on Windows, so the #if condition still remains but it covers smallest
> area possible and I tested it by manually make it "#if 1"
>
> The fallback with fspathcmp() is only done when inode
Junio C Hamano writes:
> It is a bit sad that
>
> - if (E)
> FREE_AND_NULL(E);
>
> is not sufficient to catch it. Shouldn't we be doing the same for
> regular free(E) as well? IOW, like the attached patch.
> ...
And revised even more to also spell "E" as "E != NULL" (and "!E" as
Duy Nguyen writes:
> Just fyi this seems to do the trick. Although I'm nowhere good at
> coccinelle to say if we should include this (or something like it)
>
> -- 8< --
> diff --git a/contrib/coccinelle/free.cocci b/contrib/coccinelle/free.cocci
> index 4490069df9..f8e018d104 100644
> ---
On Fri, Aug 17, 2018 at 09:28:59AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > So all of this really implies to me that you want to be able to say
> > "take this symref on the other side and update this one on the local
> > side". I.e., some way to tell a refspec "don't update the
Jonathan Nieder writes:
> Michał Górny wrote:
>
>> GnuPG supports creating signatures consisting of multiple signature
>> packets. If such a signature is verified, it outputs all the status
>> messages for each signature separately. However, git currently does not
>> account for such scenario
Jeff King writes:
> So all of this really implies to me that you want to be able to say
> "take this symref on the other side and update this one on the local
> side". I.e., some way to tell a refspec "don't update the value, update
> the symref destination". ...
> ...
> git fetch origin
Paths that only differ in case work fine in a case-sensitive
filesystems, but if those repos are cloned in a case-insensitive one,
you'll get problems. The first thing to notice is "git status" will
never be clean with no indication what exactly is "dirty".
This patch helps the situation a bit by
On Fri, Aug 17, 2018 at 5:26 PM Jeff King wrote:
>
> On Fri, Aug 17, 2018 at 04:33:30PM +0200, Duy Nguyen wrote:
>
> > On Fri, Aug 17, 2018 at 8:47 AM Jonathan Nieder wrote:
> > >
> > > Nguyễn Thái Ngọc Duy wrote:
> > >
> > > > --- a/builtin/commit.c
> > > > +++ b/builtin/commit.c
> > > > @@
Duy Nguyen writes:
> The alternative is -A or -M which may be easier associated with
> --amend.
I would be confused to mistake that "git commit -A $args" would do
something similar to "git add -A && git commit $args".
I do my fair share of amends during the day, and I've never felt the
need
On Fri, Aug 17, 2018 at 5:26 PM Junio C Hamano wrote:
> -- >8 --
> Subject: [PATCH] config.txt: clarify core.checkStat
>
> The description of this key does not really tell what the 'minimal'
> mode checks and does not check. The description for the 'default'
> mode is not much better and just
On Fri, Aug 17, 2018 at 04:33:30PM +0200, Duy Nguyen wrote:
> On Fri, Aug 17, 2018 at 8:47 AM Jonathan Nieder wrote:
> >
> > Nguyễn Thái Ngọc Duy wrote:
> >
> > > --- a/builtin/commit.c
> > > +++ b/builtin/commit.c
> > > @@ -1489,7 +1489,7 @@ int cmd_commit(int argc, const char **argv, const
>
Duy Nguyen writes:
> Perfect. I could wrap it in a patch, but I feel you should take
> authorship for that one. I'll leave it to you to create this commit.
OK, here is what I ended up with. An extra paragraph was taken from
the old commit you referrred to, which is probably the only
remaining
On Mon, Aug 13, 2018 at 10:42 PM Stefan Beller wrote:
> Ævar specifically pointed out that we might want to hear from you and Duy
> if you want to attend a conference and if so how we can make that happen
> (by choosing location/time/setting appropriately) IIUC.
Since my name shows up... I'm
On Fri, Aug 17, 2018 at 04:36:13PM +0200, Duy Nguyen wrote:
> On Fri, Aug 17, 2018 at 3:05 PM Ævar Arnfjörð Bjarmason
> wrote:
> >
> > Change the few conditional uses of FREE_AND_NULL(x) to be
> > unconditional. As noted in the standard[1] free(NULL) is perfectly
> > valid, so we might as well
On Thu, Aug 16, 2018 at 1:01 AM Junio C Hamano wrote:
> * bp/checkout-new-branch-optim (2018-07-31) 1 commit
> - checkout: optimize "git checkout -b "
>
> "git checkout -b newbranch [HEAD]" should not have to do as much as
> checking out a commit different from HEAD. An attempt is made to
>
On Thu, Aug 16, 2018 at 8:42 PM Ævar Arnfjörð Bjarmason
wrote:
>
> The PARSE_OPT_HIDDEN is, per the documentation of the "option" struct
> in option parse-options.h, only supposed to affect -h output, not
> completion. That's what the PARSE_OPT_NOCOMPLETE flag is supposed to
> be for.
>
> Since
On Thu, Aug 16, 2018 at 11:08 PM Jeff King wrote:
>
> On Thu, Aug 16, 2018 at 04:55:56PM -0400, Jeff King wrote:
>
> > > * We spend the majority of the ~30s on this:
> > >
> > > https://github.com/git/git/blob/63749b2dea5d1501ff85bab7b8a7f64911d21dea/pack-check.c#L70-L79
> >
> > This is
On Fri, Aug 17, 2018 at 3:05 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Change the few conditional uses of FREE_AND_NULL(x) to be
> unconditional. As noted in the standard[1] free(NULL) is perfectly
> valid, so we might as well leave this check up to the C library.
I'm not trying to make you work
On Fri, Aug 17, 2018 at 8:47 AM Jonathan Nieder wrote:
>
> Nguyễn Thái Ngọc Duy wrote:
>
> > --- a/builtin/commit.c
> > +++ b/builtin/commit.c
> > @@ -1489,7 +1489,7 @@ int cmd_commit(int argc, const char **argv, const
> > char *prefix)
> > STATUS_FORMAT_LONG),
> >
On 10/08/2018 17:51, Alban Gruin wrote:
> This rewrites write_basic_state() from git-rebase.sh in C. This is the
> first step in the conversion of init_basic_state(), hence the mode in
> rebase--helper.c is called INIT_BASIC_STATE. init_basic_state() will be
> converted in the next commit.
>
>
On Fri, Aug 17 2018, Samuel Maftoul wrote:
> I recently contributed for the first time patches on this maillist and
> used for the first time `git format-patch` and `git send-email`.
> I had hard times making `git send-email` work on my mac, because the
> OSX bundled perl was missing the
Hi Alban
The interdiff from v5 to v6 looks good, I think the changes you have
made the the other patches in this series are fine, I've just got a
couple of small comments below about this one.
Best Wishes
Phillip
On 10/08/2018 17:51, Alban Gruin wrote:
>
> This rewrites complete_action() from
I recently contributed for the first time patches on this maillist and
used for the first time `git format-patch` and `git send-email`.
I had hard times making `git send-email` work on my mac, because the
OSX bundled perl was missing the Net::SMTP::SSL module.
So I did `cpan -f Net::SMTP::SSL`
Change the few conditional uses of FREE_AND_NULL(x) to be
unconditional. As noted in the standard[1] free(NULL) is perfectly
valid, so we might as well leave this check up to the C library.
1. http://pubs.opengroup.org/onlinepubs/9699919799/functions/free.html
Signed-off-by: Ævar Arnfjörð
On 8/16/2018 2:37 PM, Duy Nguyen wrote:
On Thu, Aug 16, 2018 at 8:27 PM Ben Peart wrote:
From: Ben Peart
Skip merging the commit, updating the index and working directory if and
only if we are creating a new branch via "git checkout -b ."
Any other checkout options will still go through
did you get my last letter?
On Fri, 2018-08-17 at 05:28 -0400, Eric Sunshine wrote:
> On Fri, Aug 17, 2018 at 5:17 AM Michał Górny wrote:
> > Fix signature_check_clear() to free only values that are non-NULL. This
> > especially applies to 'key' and 'signer' members that can be NULL during
> > normal operations, depending
On Fri, Aug 17, 2018 at 5:17 AM Michał Górny wrote:
> Fix signature_check_clear() to free only values that are non-NULL. This
> especially applies to 'key' and 'signer' members that can be NULL during
> normal operations, depending on exact GnuPG output. While at it, also
> allow other members
Fix signature_check_clear() to free only values that are non-NULL. This
especially applies to 'key' and 'signer' members that can be NULL during
normal operations, depending on exact GnuPG output. While at it, also
allow other members to be NULL to make the function easier to use,
even if there
Hi Dear,
Sorry to invade your privacy, I am Mrs. Daniella Kyle the wife of Mr
Angelo Kyle,my husband worked with Central Bank Of Philippines for ten
years before he died in the year 2012. When my late husband was alive
he deposited sum amount of Money with a Bank in UK, Presently,this
money is
GnuPG supports creating signatures consisting of multiple signature
packets. If such a signature is verified, it outputs all the status
messages for each signature separately. However, git currently does not
account for such scenario and gets terribly confused over getting
multiple *SIG
Michał Górny wrote:
> On Wed, 2018-08-15 at 14:31 -0700, Jonathan Nieder wrote:
>> It's not clear to me that the name is_status or SIGNATURE_STATUS
>> captures what this field represents. Aren't these all sigcheck
>> statuses? Can you describe briefly what distinguishes the cases where
>> this
Nguyễn Thái Ngọc Duy wrote:
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -1489,7 +1489,7 @@ int cmd_commit(int argc, const char **argv, const char
> *prefix)
> STATUS_FORMAT_LONG),
> OPT_BOOL('z', "null", _termination,
>
On Wed, 2018-08-15 at 14:31 -0700, Jonathan Nieder wrote:
> Michał Górny wrote:
>
> > GnuPG supports creating signatures consisting of multiple signature
> > packets. If such a signature is verified, it outputs all the status
> > messages for each signature separately. However, git currently
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Extend the NO_TCLTK=NoThanks flag to be understood by the
> Documentation Makefile.
>
> Before this change compiling and installing with NO_TCLTK would result
> in no git-gui, gitk or git-citool being installed, but their
> respective manual pages would still
75 matches
Mail list logo
