On Wed, Mar 21, 2018 at 07:28:26PM +, g...@jeffhostetler.com wrote:
> It includes a new "struct json_writer" which is used to guide the
> accumulation of JSON data -- knowing whether an object or array is
> currently being composed. This allows error checking during construction.
>
> It also
On Wed, Mar 21, 2018 at 9:59 PM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> These commands can take options and use parse-options so it's quite
>> easy to allow option completion. This does not pollute the command
>> name completion though. "git " will show you the same set as
>>
Hello,
Facebook is given out 14,000,000.USD (Fourteen Million Dollars) its all about
14 Please, respond with your Unique Code (FB/BF14-13M5250UD) using your
registration email, to the Verification Department at;
dustinmoskovitz.facebo...@gmail.com
Dustin Moskovitz
Facebook Team
Copyright © 2
Brandon Williams writes:
> On 03/03, Nguyễn Thái Ngọc Duy wrote:
>> From: Stefan Beller
>>
>> Signed-off-by: Stefan Beller
>> Signed-off-by: Junio C Hamano
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> This is an invalid conversion.
>
>> packfile.c | 18 +-
>> packfile.h
Hi Alban,
On Wed, 21 Mar 2018, Alban Gruin wrote:
> Le mardi 20 mars 2018 17:29:28 CET, vous avez écrit :
>
> > Also, I have a hunch that there is actually almost nothing left to
> > rewrite after my sequencer improvements that made it into Git v2.13.0,
> > together with the upcoming changes (wh
On Tue, Mar 20, 2018 at 1:51 AM, Junio C Hamano wrote:
>
> I somehow had to stare at the patch for a few minutes, view it in
> two Emacs buffers and run M-x compare-windows before I finally spot
> the single-byte typofix.
>
> Will queue with a retitle.
[resending as plain text]
Thanks, and sorry
Wink Saville writes:
>> Good code simplification that turns
>>
>> if A
>> if B
>> do this thing
>> fi
>> fi
>>
>> into
>>
>> if A & B
>> do this thing
>> fi
>
> Will be keeping this in a future
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> On Sat, Mar 3, 2018 at 9:54 AM, Duy Nguyen wrote:
> > On Thu, Mar 1, 2018 at 2:09 AM, Junio C Hamano wrote:
> >> Stefan Beller writes:
> >>
> >>> On Wed, Feb 28, 2018 at 9:59 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> > Looking at t
On Wed, Mar 21, 2018 at 09:24:06AM -0400, Derrick Stolee wrote:
> On 3/20/2018 6:25 PM, Jonathan Tan wrote:
> > On Tue, 20 Mar 2018 16:03:25 -0400
> > Derrick Stolee wrote:
> > > One caveat about the patch: there is a place where I cast a sha1 hash
> > > into a struct object_id pointer. This is be
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> The reason callers have to call this is to make sure either packed_git
> or packed_git_mru pointers are initialized since we don't do that by
> default. Sometimes it's hard to see this connection between where the
> function is called and where packed_git poi
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
This is an invalid conversion.
> packfile.c | 18 +-
> packfile.h | 3 +--
> 2 files changed, 10 insertio
Hi Junio,
On Tue, 20 Mar 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> + if (!keep_empty && is_empty)
> >>strbuf_addf(&buf, "%c ", comment_line_char);
>
> We are not trying to preserve an empty one, and have found an empty
> one, so we comment it
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Jonathan Nieder
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Jonathan Nieder
> Signed-off-by: Junio C Hamano
> Signed-off-by: Nguyễn Thái Ngọc Duy
Patches up to here look sane.
> ---
> sha1_file.c | 11 +--
> 1 file changed, 5 inse
Hi Joseph,
On Tue, 20 Mar 2018, Joseph Strauss wrote:
> Perfect. Thank you.
You are welcome.
I am puzzled, though... does your message mean that you tested the Git for
Windows v2.17.0-rc0 installer and it did fix your problem? Or do you
simply assume that it does fix your problem because Junio
Hi Junio,
On Mon, 19 Mar 2018, Junio C Hamano wrote:
> David Pursehouse writes:
>
> > From: David Pursehouse
> >
> > Signed-off-by: David Pursehouse
> > ---
>
> I somehow had to stare at the patch for a few minutes, view it in
> two Emacs buffers and run M-x compare-windows before I finally
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> Actually this also allows read_info_alternates and link_alt_odb_entry to
> handle arbitrary repositories, but link_alt_odb_entries is the most
> interesting function in this set of functions, hence the commit subject.
>
> These func
On 03/04, Duy Nguyen wrote:
> On Sun, Mar 4, 2018 at 9:47 AM, Eric Sunshine wrote:
> > On Sat, Mar 3, 2018 at 6:36 AM, Nguyễn Thái Ngọc Duy
> > wrote:
> >> The approximate_object_count() function maintains a rough count of
> >> objects in a repository to estimate how long object name abbreviates
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> Each repository's object store can be initialized independently, so
> they must not share a run_once variable.
Looks good.
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Jonathan Nieder
> Signed-off-by: Nguyễn Thái Ngọc Duy
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> Signed-off-by: Stefan Beller
> Signed-off-by: Junio C Hamano
> Signed-off-by: Nguyễn Thái Ngọc Duy
Looks good.
> ---
> builtin/am.c | 2 +-
> builtin/clone.c| 2 +-
> builtin/fetch.c| 2 +-
> builtin/m
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> In a process with multiple repositories open, packfile accessors
> should be associated to a single repository and not shared globally.
> Move packed_git and packed_git_mru into the_repository and adjust
> callers to reflect this.
>
On 03/03, Eric Sunshine wrote:
> On Sat, Mar 3, 2018 at 6:36 AM, Nguyễn Thái Ngọc Duy
> wrote:
> > Free the memory and reset alt_odb_{list, tail} to NULL.
> >
> > Signed-off-by: Stefan Beller
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
> > diff --git a/object.c b/object.c
> > @@ -450,8 +450
Thomas Gummerer writes:
> On 03/21, Thomas Gummerer wrote:
>>
>> Argh I just noticed we could drop the "$@" here, as this is no longer
>> the pathspec case. It doesn't hurt anything, except it may be a bit
>> confusing when reading the code.
>>
>> Although if we end up implementing 'git checkou
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> From: Stefan Beller
>
> The raw object store field will contain any objects needed for
> access to objects in a given repository.
>
> This patch introduces the raw object store and populates it with the
> `objectdir`, which used to be part of the repositor
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> This variable was added because the repo_set_gitdir() was created to
> cover both submodule and main repos, but these two are initialized a
> bit differently so ignore_env == 0 means main repo, while ignore_env
> != 0 is submodules.
>
> Since the difference
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> getenv() is supposed to work on the main repository only. This delayed
> getenv() code in sha1_file.c makes it more difficult to convert
> sha1_file.c to a generic object store that could be used by both
> submodule and main repositories.
>
> Move the getenv
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> Signed-off-by: Junio C Hamano
> ---
> repository.c | 25 -
> 1 file changed, 25 deletions(-)
>
> diff --git a/repository.c b/repository.c
> index bb53b54b6d..e65f4138a7 100644
> --- a/repositor
Thomas Gummerer writes:
>> > diff --git a/git-stash.sh b/git-stash.sh
>> > index 4c92ec931f..5e06f96da5 100755
>> > --- a/git-stash.sh
>> > +++ b/git-stash.sh
>> > @@ -308,14 +308,16 @@ push_stash () {
>> >if test -z "$patch_mode"
>> >then
>> >test "$untracked" = "all" && CLEA
On 03/19, Duy Nguyen wrote:
> On Mon, Mar 19, 2018 at 7:07 PM, Jonathan Tan
> wrote:
> >> -extern void repo_set_gitdir(struct repository *repo, const char *path);
> >> +struct set_gitdir_args {
> >> + const char *commondir;
> >> + const char *object_dir;
> >> + const char *graft_file;
Hi Michele,
On Mon, 19 Mar 2018, Michele Locati wrote:
> [...]
> --
> 2.16.2.windows.1
Yay!
Out of curiosity: did the CONTRIBUTING.md file help that was recently
turned into a guide how to contribute to Git (for Windows) by Derrick
Stolee?
Ciao,
Johannes
On 03/21, Thomas Gummerer wrote:
>
> Argh I just noticed we could drop the "$@" here, as this is no longer
> the pathspec case. It doesn't hurt anything, except it may be a bit
> confusing when reading the code.
>
> Although if we end up implementing 'git checkout --index ',
> we'd have to add it
On Wed, Mar 21, 2018 at 12:42 PM, Junio C Hamano wrote:
> Wink Saville writes:
>
>> Refactor git_rebase__interactive__preserve_merges out of
>> git_rebase__interactive resulting in fewer conditionals making
>> both routines are simpler.
>>
>> Changed run_specific_rebase in git-rebase to dispatch
On 03/03, Nguyễn Thái Ngọc Duy wrote:
> This simplifies initialization of struct repository and anything
> inside. Easier to read. Easier to add/remove fields.
>
> Everything will go through main() common-main.c so this should cover all
> programs, including t/helper.
>
> Signed-off-by: Nguyễn Th
On 03/20, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > ...
> > Fix this by avoiding the 'git clean' if a pathspec is given, and use the
> > pipeline that's used for pathspec mode to get rid of the untracked files
> > as well.
>
> That made me wonder if we can get rid of 'git clean' alto
g...@jeffhostetler.com writes:
> From: Jeff Hostetler
>
> Add basic routines to generate data in JSON format.
And the point of having capability to write JSON data in our
codebase is...?
> diff --git a/json-writer.c b/json-writer.c
> new file mode 100644
> index 000..89a6abb
> --- /dev/null
Nguyễn Thái Ngọc Duy writes:
> These commands can take options and use parse-options so it's quite
> easy to allow option completion. This does not pollute the command
> name completion though. "git " will show you the same set as
> before. This only kicks in when you type the correct command na
Olga Telezhnaya writes:
> @@ -2144,13 +2151,15 @@ int format_ref_array_item(struct ref_array_item *info,
>
> for (cp = format->format; *cp && (sp = find_next(cp)); cp = ep + 1) {
> struct atom_value *atomv;
> + int pos;
>
> ep = strchr(sp, ')');
>
Olga Telezhnaya writes:
> Add function strbuf_error() that helps to save few lines of code.
> Function expands fmt with placeholders, append resulting error message
> to strbuf *err, and return error code ret.
>
> Signed-off-by: Olga Telezhnaia
> ---
> strbuf.h | 13 +
> 1 file chan
Yuki Kokubun writes:
>> Yuki Kokubun writes:
>>
>> > "git filter-branch -- --all" can be confused when refs that refer to
>> > objects
>> > other than commits or tags exists.
>> > Because "git rev-parse --all" that is internally used can return refs that
>> > refer to an object other than comm
On Wed, Mar 21, 2018 at 3:30 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> strbuf_error() was a possibility proposed in [1], and it does take a
>> strbuf. Failure to pass in a strbuf here is just a typo.
>
> I've seen it; I just thought it was a joke and not a serious
> suggestion.
> A mac
A release candidate Git v2.17.0-rc1 is now available for testing
at the usual places. It is comprised of 493 non-merge commits
since v2.16.0, contributed by 62 people, 19 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
> Yuki Kokubun writes:
>
> > "git filter-branch -- --all" can be confused when refs that refer to objects
> > other than commits or tags exists.
> > Because "git rev-parse --all" that is internally used can return refs that
> > refer to an object other than commit or tag. But it is not considered
Wink Saville writes:
> Refactor git_rebase__interactive__preserve_merges out of
> git_rebase__interactive resulting in fewer conditionals making
> both routines are simpler.
>
> Changed run_specific_rebase in git-rebase to dispatch to the appropriate
> function after sourcing git-rebase--interact
steps to reproduce:
$> git clone git://git.gentoo.org/repo/gentoo.git
$> cd gentoo
$> gitk sys-apps/portage-mgorny
For few minutes I do just read here : "Reading commits..."
--
Toralf
PGP C4EACDDE 0076E94E
signature.asc
Description: OpenPGP digital signature
These commands can take options and use parse-options so it's quite
easy to allow option completion. This does not pollute the command
name completion though. "git " will show you the same set as
before. This only kicks in when you type the correct command name.
Some other builtin commands are not
Eric Sunshine writes:
>> I have no idea what strbuf_error() that does not take any strbuf is
>> doing,...
>
> strbuf_error() was a possibility proposed in [1], and it does take a
> strbuf. Failure to pass in a strbuf here is just a typo.
I've seen it; I just thought it was a joke and not a serio
From: Jeff Hostetler
Add basic routines to generate data in JSON format.
Signed-off-by: Jeff Hostetler
---
Makefile| 2 +
json-writer.c | 321 +
json-writer.h | 86 +
t/helper/test-json-writer.c | 420 ++
From: Jeff Hostetler
This is version 2 of my JSON data format routines. This version addresses
the non-utf8 questions raised on V1.
It includes a new "struct json_writer" which is used to guide the
accumulation of JSON data -- knowing whether an object or array is
currently being composed. Thi
jameson.mille...@gmail.com writes:
> This patch series extracts the memory pool implementation, currently
> used by fast-import, into a generalized component. This memory pool
> can then be generally used by any component that needs a pool of
> memory.
The way this series is organized is quite re
On Wed, Mar 21, 2018 at 5:32 AM, Johannes Schindelin
wrote:
> Hi Paul,
>
> Note! There is one exception, and it is not even a full script. As
> everybody knows who follows my patch series on this here mailing list, I
> consider --preserve-merges one of my stupidest design mistakes ever. To
> undo
Duy Nguyen writes:
> And we could even do something like this to make custom builds
> easier. Some more gluing is needed so you can set this from config.mak
> but you get the idea. This removes all limits set by this
> series.
Yes, we _could_, but it would mean we would have many variants of
the
On Wed, Mar 21, 2018 at 2:11 PM, Junio C Hamano wrote:
> Pratik Karki writes:
>> Avoid using pipes downstream of Git commands since the exit
>> codes of commands upstream of pipes get swallowed, thus potentially hiding
>> failure of those commands. Instead, capture Git command output to a file
On Wed, Mar 21, 2018 at 2:11 PM, Junio C Hamano wrote:
> Pratik Karki writes:
>> The changes in patch increased from v1 to v2 because I
>> got excited to work in Git codebase and I tried to
>> fix the exisiting problems as much as possible.
>> Hence, the large number of changes.
>
> Eric understa
Add strbuf_error() as a first commit and use it in all other commits.
Good line reduction, -67 lines compare to previous version.
Eric, thanks a lot, new code looks much better!
Thank all of you,
Olga
Continue removing die() calls from ref-filter formatting logic,
so that it could be used by other commands.
Change the signature of parse_ref_filter_atom() by adding
strbuf parameter for error message.
The function returns the position in the used_atom[] array
(as before) for the given atom, or -1
Add function strbuf_error() that helps to save few lines of code.
Function expands fmt with placeholders, append resulting error message
to strbuf *err, and return error code ret.
Signed-off-by: Olga Telezhnaia
---
strbuf.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/strbu
Continue removing die() calls from ref-filter formatting logic,
so that it could be used by other commands.
Change the signature of parsers by adding return value and
strbuf parameter for error message.
Return value equals 0 upon success and -1 upon failure.
Upon failure, error message is appended
This is a first step in removing die() calls from ref-filter
formatting logic, so that it could be used by other commands
that do not want to die during formatting process.
die() calls related to bugs in code will not be touched in this patch.
Everything would be the same for show_ref_array_item()
Finish removing die() calls from ref-filter formatting logic,
so that it could be used by other commands.
Change the signature of get_ref_atom_value() and underlying functions
by adding return value and strbuf parameter for error message.
Return value equals 0 upon success and -1 upon failure.
Upo
Continue removing die() calls from ref-filter formatting logic,
so that it could be used by other commands.
Change the signature of handlers by adding return value
and strbuf parameter for errors.
Return value equals 0 upon success and -1 upon failure.
Upon failure, error message is appended to th
Paul-Sebastian Ungureanu writes:
> diff --git a/t/t0041-usage.sh b/t/t0041-usage.sh
> new file mode 100755
> index 0..ac96bc3b9
> --- /dev/null
> +++ b/t/t0041-usage.sh
> @@ -0,0 +1,107 @@
> +#!/bin/sh
> +
> +test_description='Test commands behavior when given invalid argument value'
> +
Pratik Karki writes:
> Thank you Eric, for the review. This is follow on patch[1].
>
> The changes in patch increased from v1 to v2 because I
> got excited to work in Git codebase and I tried to
> fix the exisiting problems as much as possible.
> Hence, the large number of changes.
Eric understa
Version 2 keeps all changes in git-rebase--interactive.sh this should
make it easier to use blame. But there is quite a bit of refactoring
and reformatting so using "git blame -w" or "git blame -w -C -C" is
needed to improve the results of blame.
I can break this into several patches to have the h
Refactor git_rebase__interactive__preserve_merges out of
git_rebase__interactive resulting in fewer conditionals making
both routines are simpler.
Changed run_specific_rebase in git-rebase to dispatch to the appropriate
function after sourcing git-rebase--interactive.
---
git-rebase--interactive.
Jeff King writes:
>> To make it bullet-proof, I think we'd have to actually parse the graph
>> structure, finding a "*" line and then accepting only an indent that
>> matched it.
>
> Wow. Nerd snipe successful. This turned out to be quite tricky, but also
> kind of interesting.
The last patch lo
Yuki Kokubun writes:
> "git filter-branch -- --all" can be confused when refs that refer to objects
> other than commits or tags exists.
> Because "git rev-parse --all" that is internally used can return refs that
> refer to an object other than commit or tag. But it is not considered in the
> ph
On Wed, Mar 21, 2018 at 5:53 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> That's going to be super rare (and probably nonexisting) edge case, but
>> (untested) I wonder if something like this on top would alleviate your
>> concerns, i.e. instead of dying we just take the first
Ævar Arnfjörð Bjarmason writes:
> That's going to be super rare (and probably nonexisting) edge case, but
> (untested) I wonder if something like this on top would alleviate your
> concerns, i.e. instead of dying we just take the first N packs up to our
> limit:
>
> diff --git a/builtin/pack-
On Wed, Mar 21, 2018 at 04:59:19PM +0100, Duy Nguyen wrote:
> About the 16k limit (and some other limits as well), I'm making these
> patches with the assumption that large scale deployment probably will
> go with custom builds anyway. Adjusting the limits back should be
> quite easy while we can s
From: Jameson Miller
Extract the existing memory pool logic used by fast-import into a
generalized component. This memory pool component can then be used by
other components that need this functionality.
Signed-off-by: Jameson Miller
---
Makefile | 1 +
mem-pool.c | 130 +++
From: Jameson Miller
Signed-off-by: Jameson Miller
---
fast-import.c | 50 +++---
1 file changed, 7 insertions(+), 43 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 4e68acc156..126f2da118 100644
--- a/fast-import.c
+++ b/fast-import.c
From: Jameson Miller
Rename the mem_pool variables and structs in fast-import.c that will
conflict with an upcoming global mem_pool type.
Signed-off-by: Jameson Miller
---
fast-import.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fast-import.c b/fast-
From: Jameson Miller
This patch series extracts the memory pool implementation, currently
used by fast-import, into a generalized component. This memory pool
can then be generally used by any component that needs a pool of
memory.
This patch is in preparation for a change to speed up the loading
On Wed, Mar 21 2018, Jeff King wrote:
> On Sun, Mar 18, 2018 at 03:25:15PM +0100, Nguyễn Thái Ngọc Duy wrote:
>
>> v6 fixes the one optimization that I just couldn't get right, fixes
>> two off-by-one error messages and a couple commit message update
>> (biggest change is in 11/11 to record some
On Wed, Mar 21, 2018 at 5:17 PM, Ævar Arnfjörð Bjarmason
wrote:
>>> I think ultimately to work on low-memory machines we'll need a
>>> fundamentally different approach that scales with the objects since the
>>> last pack, and not with the complete history.
>>
>> Absolutely. Which is covered in a s
Dakota Hawkins writes:
> At any rate, would it at least be a good idea to make the "trailing
> slash halts recursion, won't consider nested .gitignore files"
> explicit in the `.gitignore` doc? Unless I'm missing it, I don't think
> that behavior is called out (or at least not called out concisel
On Wed, Mar 21, 2018 at 7:50 AM, Jeff King wrote:
> On Tue, Mar 20, 2018 at 05:41:52PM +0100, Duy Nguyen wrote:
>
>> > +The rules by which the pattern matches paths are the same as in
>> > +`.gitignore` files (see linkgit:gitignore[5]), with a few exceptions:
>> > +
>> > + - negative patterns are
On Wed, Mar 21 2018, Duy Nguyen wrote:
> On Wed, Mar 21, 2018 at 9:24 AM, Jeff King wrote:
>> On Sun, Mar 18, 2018 at 03:25:15PM +0100, Nguyễn Thái Ngọc Duy wrote:
>>
>>> v6 fixes the one optimization that I just couldn't get right, fixes
>>> two off-by-one error messages and a couple commit mes
On Wed, Mar 21, 2018 at 9:03 AM, Jeff King wrote:
> On Tue, Mar 20, 2018 at 07:08:07PM +0100, Duy Nguyen wrote:
>
>> BTW can you apply this patch? This broken && chain made me think the
>> problem was in the next test. It would have saved me lots of time if I
>> saw this "BUG" line coming from the
On Wed, Mar 21, 2018 at 4:22 AM, Dakota Hawkins
wrote:
> Thinking about this a little more, I'm now attracted to the idea that
> its .gitignore that's weird.
>
> As I understand it, .gitignore stops recursion when there's a
> directory match (`somedir/`) but also explicitly allows nested
> .gitnor
Hi Michael,
On Fri, 16 Mar 2018, Michael Haggerty wrote:
> What makes a Git repository unwieldy to work with and host? It turns
> out that the respository's on-disk size in gigabytes is only part of
> the story. From our experience at GitHub, repositories cause problems
> because of poor internal
On Wed, Mar 21, 2018 at 9:24 AM, Jeff King wrote:
> On Sun, Mar 18, 2018 at 03:25:15PM +0100, Nguyễn Thái Ngọc Duy wrote:
>
>> v6 fixes the one optimization that I just couldn't get right, fixes
>> two off-by-one error messages and a couple commit message update
>> (biggest change is in 11/11 to r
"git filter-branch -- --all" can be confused when refs that refer to objects
other than commits or tags exists.
Because "git rev-parse --all" that is internally used can return refs that
refer to an object other than commit or tag. But it is not considered in the
phase of updating refs. Such refs c
Thank you Eric, for the review. This is follow on patch[1].
The changes in patch increased from v1 to v2 because I
got excited to work in Git codebase and I tried to
fix the exisiting problems as much as possible.
Hence, the large number of changes.
>> test_cmp expect.two output.two
>> @
On 3/20/2018 6:25 PM, Jonathan Tan wrote:
On Tue, 20 Mar 2018 16:03:25 -0400
Derrick Stolee wrote:
This patch updates the abbreviation code to use bsearch_hash() as defined
in [1]. It gets a nice speedup since the old implementation did not use
the fanout table at all.
You can refer to the pa
Hi everyone,
The 37th edition of Git Rev News is now published:
https://git.github.io/rev_news/2018/03/21/edition-37/
Thanks a lot to all the contributors!
Enjoy,
Christian, Jakub, Markus and Gabriel.
> I think it makes more sense to document it where it's documented now,
> i.e. under how "!" works in general, since this is an edge case with
> negative matching.
My reasoning is/was that while yes, that's true, I think it's likely
that the positive matches would be added before (in terms of git
Hi Paul,
On Mon, 19 Mar 2018, Paul Sebastian Ungureanu wrote:
> I am interested in the "Convert scripts to builtins" project. I have
> recently started to analyze it better and see exactly what it entails
> and a few questions came to my mind.
Great!
> First of all, I find it difficult to pick
On Wed, Mar 21 2018, Dakota Hawkins wrote:
> Re-reading the section you quoted again a couple of times you're
> correct, but somehow that wasn't clear to me despite reading/searching
> for what I wanted to see several times.
FWIW I just knew this because I'd run into this the other day, so it wa
One additional note, I think I was was wrong about this:
"In order to match `foo/` directories while allowing for
possible later exclusions, consider using a trailing wildcard (`foo/*`).
Note that matching directories with a trailing wildcard incurs some
additional performance cost, since it req
First, apologies since I didn't get the in-reply-to correct in my
email header. I'm not sure how to do that (using gmail/gsuite).
Meant to reply to:
https://public-inbox.org/git/20180321075041.ga24...@sigill.intra.peff.net/
> Just before the context your patch quotes, we have this in gitignore(5)
On Wed, Mar 21 2018, Dakota Hawkins jotted:
>>> At any rate, would it at least be a good idea to make the "trailing
>>> slash halts recursion, won't consider nested .gitignore files"
>>> explicit in the `.gitignore` doc? Unless I'm missing it, I don't think
>>> that behavior is called out (or at
>> At any rate, would it at least be a good idea to make the "trailing
>> slash halts recursion, won't consider nested .gitignore files"
>> explicit in the `.gitignore` doc? Unless I'm missing it, I don't think
>> that behavior is called out (or at least not called out concisely/in
>> one place). I
Hi Johannes,
Le mardi 20 mars 2018 17:29:28 CET, vous avez écrit :
> > Weeks 1 & 2 — May 14, 2018 – May 28, 2018
> > First, I would refactor --preserve-merges in its own shell script, as
> > described in Dscho’s email.
>
> Could you go into detail a bit here? Like, describe what parts of the
> gi
On Mon, Mar 19, 2018 at 1:32 PM, Pratik Karki wrote:
> Thank you Eric Sunshine,
> I have done as you had instructed me. I look forward to more
> understanding of the codebase and would love to fix
> "git rev-parse" problems in my follow-on patches.
> Thank you for the professional review comment.
"git filter-branch -- --all" can be confused when refs that refer to objects
other than commits exists.
Because "git rev-parse --all" that is internally used can return refs that
refer to an object other than commit. But it is not considered in the phase of
updating refs. Such refs can be created b
{cc:+junio}
On Tue, Mar 20, 2018 at 11:31 PM, Wink Saville wrote:
> Anyway, I've played around and my current thoughts are to not create
> any new files and keep git_rebase__interactive and the new
> git_rebase__interactive__preserve_merges functions in
> git-rebase--interactive.sh. Doing that wi
On Wed, Mar 21, 2018 at 04:35:26AM -0400, Dakota Hawkins wrote:
> > I think it means "for the rest of the description of how the patterns
> > work". I.e., "foo/" matches as "foo" when the rest of the matching rules
> > are applied. I agree it's a bit awkward. Patches welcome. :)
>
> I'd be more t
> I think it means "for the rest of the description of how the patterns
> work". I.e., "foo/" matches as "foo" when the rest of the matching rules
> are applied. I agree it's a bit awkward. Patches welcome. :)
I'd be more than happy to do that!
It will take me a while, this (email and text-patche
On Sun, Mar 18, 2018 at 03:25:15PM +0100, Nguyễn Thái Ngọc Duy wrote:
> v6 fixes the one optimization that I just couldn't get right, fixes
> two off-by-one error messages and a couple commit message update
> (biggest change is in 11/11 to record some numbers from AEvar)
I was traveling during so
On Tue, Mar 20, 2018 at 07:08:07PM +0100, Duy Nguyen wrote:
> BTW can you apply this patch? This broken && chain made me think the
> problem was in the next test. It would have saved me lots of time if I
> saw this "BUG" line coming from the previous test.
>
> -- 8< --
> Subject: [PATCH] t9300: f
1 - 100 of 103 matches
Mail list logo
