On Mon, Apr 8, 2019 at 5:32 AM Duy Nguyen wrote:
>
> On Mon, Apr 8, 2019 at 8:23 AM Duy Nguyen wrote:
> >
> > On Mon, Apr 8, 2019 at 5:52 AM Christian Couder
> > wrote:
> > > > Git has a very optimized mechanism to compactly store
> > > > objects (blobs, trees, commits, etc.) in packfiles[2]. Th
Jakub Narebski writes:
> As Junio said, the "--author=" sets the author
> identity, but not the committer identity; you can work around the issue
> with "git -c user.name=me -c user.email=m...@email.my".
Having slept on this a bit, I am of two minds here.
It certainly is possible to change the
On Mon, Apr 8, 2019 at 8:03 AM Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
> >>> #include "fetch-object.h"
> >>> +#include "promisor-remote.h"
> >>
> >> Thanks.
> >
> > Together with "if we are forbidding the direct access to the
> > repository_format_partial_clone variable and the fetch_
Eric Sunshine writes:
> On Fri, Apr 5, 2019 at 2:24 PM Jeff King wrote:
>> On Fri, Apr 05, 2019 at 12:50:33PM +0200, SZEDER Gábor wrote:
>> > > + git cat-file commit $commit |
>> > > + perl -lpe "/^author/ && print q(parent $blob)" \
>> > > + >broken-commit &&
>>
>> > Would
On Mon, Apr 8, 2019 at 4:36 AM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > #ifdef NO_FAST_WORKING_DIRECTORY
> > #define FAST_WORKING_DIRECTORY 0
> > @@ -6489,7 +6490,7 @@ static void add_if_missing(struct oid_array *to_fetch,
> >
> > void diffcore_std(struct diff_options *options)
Hi Dear, my name is Jack and i am seeking for a relationship in which i will
feel loved after a series of failed relationships.
I am hoping that you would be interested and we could possibly get to know each
other more if you do not mind. I am open to answering questions from you as i
think my
Junio C Hamano writes:
>>> #include "fetch-object.h"
>>> +#include "promisor-remote.h"
>>
>> Thanks.
>
> Together with "if we are forbidding the direct access to the
> repository_format_partial_clone variable and the fetch_objects()
> funciton, make it clear that is what is being done in the
> m
Junio C Hamano writes:
> Christian Couder writes:
>
>> Thanks for investigating! Yeah, that's part of the problem.
>>
>> The fix I would suggest is:
>>
>> diff --git a/diff.c b/diff.c
>> index f685ab10b5..a2b1241f83 100644
>> --- a/diff.c
>> +++ b/diff.c
>> @@ -26,6 +26,7 @@
>> #include "parse-
On Mon, Apr 8, 2019 at 12:09 AM Thomas Gummerer wrote:
>
> On 04/07, Kapil Jain wrote:
> >
> > what is the use of ce_stage macro ?
> > tells about stage of an index entry.
> > if ce_stage says, stage #0 i.e staging area, then that index entry is
> > in staging area
> > and nothing needs to be done
Jeff King writes:
> I don't think it is, but I could be wrong. POSIX does say that "\n"
> matches a newline in the pattern space, but nothing about it on the RHS
> of a substitution. I have a vague feeling of running into problems in
> the past, but I could just be misremembering.
Yes, it was qu
Jeff King writes:
> On Fri, Apr 05, 2019 at 08:19:30PM +0100, Ramsay Jones wrote:
>
>> > /* global flag to enable extra checks when accessing packed objects */
>> > -extern int do_check_packed_object_crc;
>> > +int do_check_packed_object_crc;
>>
>> ... removing this 'extern' on an int variable
SZEDER Gábor writes:
>> +test_expect_success "git rebase $@" "
>> +...
>> +git rebase $@ &&
>> +...
>> +"
>> +}
>> +
>> +test_rebase 'G F E D B A' ''
>
> It appears that this last empty argument triggers some bug in Bash
> v4.2 and older (and on macOS such an old Bash is the d
Ævar Arnfjörð Bjarmason writes:
> unique (AFAICT "actually unique" in practice) in the parallel in-flight
> jh/trace2-sid-fix
> (https://public-inbox.org/git/4352952677a11776a18ec9b6862cf358307cfafd.1553879063.git.gitgitgad...@gmail.com/)
>
> I think it's fine to merge js/trace2-to-directory down
Ævar Arnfjörð Bjarmason writes:
> On Thu, Apr 04 2019, Junio C Hamano wrote:
>
> Just comments on ab/* stuff:
>
>> * ab/gc-reflog (2019-04-01) 7 commits
>> - gc: handle & check gc.reflogExpire config
>> - reflog tests: assert lack of early exit with expiry="never"
>> - reflog tests: test for t
Ævar Arnfjörð Bjarmason writes:
>> I'd rather pick between (1) using the final name for the concept we
>> want to eventually achieve, i.e. "precious", and starting small,
>> i.e. "initially, only git-clean knows about it", or (2) doing
>> nothing. Per-command 'precious-this', 'precious-that' tha
Duy Nguyen writes:
>> Avoid a usage of the_repository by propagating the configured repository
>> to add_if_missing(). Also, prefetch only if the repository being diffed
>> is the_repository (because we do not support lazy fetching for any other
>> repository anyway).
If we are willing to stay l
Duy Nguyen writes:
>> -static void add_if_missing(struct oid_array *to_fetch,
>> +static void add_if_missing(struct oid_array *to_fetch, struct repository *r,
>
> One last nit. "struct repository *r" is often the first argument. See
Yes, and that's easy enough to tweak locally ;-)
Thanks.
On Mon, Apr 8, 2019 at 8:23 AM Duy Nguyen wrote:
>
> On Mon, Apr 8, 2019 at 5:52 AM Christian Couder
> wrote:
> > > Git has a very optimized mechanism to compactly store
> > > objects (blobs, trees, commits, etc.) in packfiles[2]. These files are
> > > created by[3]:
> > >
> > > 1. listing object
Christian Couder writes:
> Thanks for investigating! Yeah, that's part of the problem.
>
> The fix I would suggest is:
>
> diff --git a/diff.c b/diff.c
> index f685ab10b5..a2b1241f83 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -26,6 +26,7 @@
> #include "parse-options.h"
> #include "help.h"
> #in
On Mon, Apr 8, 2019 at 8:34 AM Junio C Hamano wrote:
>
> Damien Robert writes:
>
> > is there a way to do a git pull without it running git fetch?
> > Looking at the source in builtin/pull.c does not seem to indicate so.
>
> The reason behind that is because it does not make any sense for
> "pull
Damien Robert writes:
> is there a way to do a git pull without it running git fetch?
> Looking at the source in builtin/pull.c does not seem to indicate so.
The reason behind that is because it does not make any sense for
"pull", which is meant as a quick short-cut to say "fetch && merge",
not
On Mon, Apr 8, 2019 at 5:52 AM Christian Couder
wrote:
> > Git has a very optimized mechanism to compactly store
> > objects (blobs, trees, commits, etc.) in packfiles[2]. These files are
> > created by[3]:
> >
> > 1. listing objects;
> > 2. sorting the list with some good heuristics;
> > 3. trave
Philip Oakley writes:
> Signed-off-by: Philip Oakley
> ---
> Noticed while attempting to train the Git-for-Windows rebasing-
> merge series.
> ---
> Documentation/git-rerere.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rerere.txt b/Documentation
Philip Oakley writes:
>> But unlike "git foo --help", if the word that ought to name a
>> subcommand instead names a known concept, e.g. "glossary", I do not
>> think it is too bad if we DWIMmed what the user meant to say,
>> i.e. turning "git glossary --help" into "git help glossary".
>>
> Given
On Sun, Apr 7, 2019 at 7:43 PM SZEDER Gábor wrote:
> [...]
> We could improve the error message, of course, but let's just default
> to HEAD in a bare repository instead, as most likely that is what the
> user wanted anyway (if they wanted to start from an other commit, then
> they would have spec
When 'git blame' is invoked without specifying the commit to start
blaming from, it starts from the given file's state in the work tree.
However, when invoked in a bare repository without a start commit,
then there is no work tree state to start from, and it dies with the
following error message:
On Fri, Apr 5, 2019 at 6:29 PM Matheus Tavares Bernardino
wrote:
>
> On Thu, Apr 4, 2019 at 4:56 AM Christian Couder
> wrote:
> >
> > Nice investigation. About git status I wonder though if they have
> > tried the possible optimizations, like untracked cache or
> > core.fsmonitor.
>
> I don't kno
Hi Rohit,
On Sun, Apr 7, 2019 at 2:17 PM Rohit Ashiwal wrote:
>
> On Sun, 7 Apr 2019 09:15:30 +0200 Christian Couder
> wrote:
>
> > As we are close to the deadline (April 9th) for proposal submissions,
> > I think it's a good idea to already upload your draft proposal on the
> > GSoC site. I th
Hi Matheus
On Sun, Apr 7, 2019 at 10:48 PM Matheus Tavares Bernardino
wrote:
>
> This is my proposal for GSoC with the subject "Make pack access code
> thread-safe".
Thanks!
> I'm late in schedule but I would like to ask for your
> comments on it. Any feedback will be highly appreciated.
>
> Th
Hi Junio,
On 07/04/2019 14:43, Junio C Hamano wrote:
Duy Nguyen writes:
Phew... I didn't break anything!
That behavior has been gone since 2c6b6d9f7d (help: make option --help
open man pages only for Git commands, 2016-08-26). Ralf did not
mention why he thought "git --help" was a bad idea.
Hi Ævar
On 07/04/2019 21:05, Ævar Arnfjörð Bjarmason wrote:
On Sat, Apr 06 2019, Philip Oakley wrote:
While the minimum is 7-char, the unambiguous length can be longer.
Signed-off-by: Philip Oakley
---
noticed while looking int the Git-for-Windows patch thicket -
was looking for the ~n^m sty
mich...@platin.gs writes:
> From: Michael Platings
>
> Hi Barret,
> This is the updated fuzzy matching algorithm, sorry for the delay. It does
> highlight a bug in the calculation for the number of lines ("int
> nr_parent_lines
> = e->num_lines - delta;") - if you apply the patch, build it, the
From: Michael Platings
Hi Barret,
This is the updated fuzzy matching algorithm, sorry for the delay. It does
highlight a bug in the calculation for the number of lines ("int nr_parent_lines
= e->num_lines - delta;") - if you apply the patch, build it, then try to
./git blame --ignore-rev blame.
Ævar Arnfjörð Bjarmason writes:
> I've been meaning to follow-up on
> https://public-inbox.org/git/20190204161217.20047-1-ava...@gmail.com/
> where I among other things wanted to just have these instances all say
> "commits will be abbreviated as described in XYZ in linkgit:"
> and summarize what
On Fri, Apr 05 2019, Jeff King wrote:
> On Fri, Apr 05, 2019 at 08:42:29PM +0200, SZEDER Gábor wrote:
>
>> > > Don't run git commands upstream of a pipe, because the pipe hides
>> > > their exit code. This applies to several other tests below as well.
>> >
>> > I disagree with that rule here. W
Hi, everyone
This is my proposal for GSoC with the subject "Make pack access code
thread-safe". I'm late in schedule but I would like to ask for your
comments on it. Any feedback will be highly appreciated.
The "rendered" version can be seen here:
https://docs.google.com/document/d/1QXT3iiI5zjwus
On Sat, Apr 06 2019, Philip Oakley wrote:
> While the minimum is 7-char, the unambiguous length can be longer.
>
> Signed-off-by: Philip Oakley
> ---
> noticed while looking int the Git-for-Windows patch thicket -
> was looking for the ~n^m style!
> ---
> Documentation/git-describe.txt | 2 +-
v4 fixes a misbalanced quote noted by Todd Zullinger in
<20190330180415.gc4...@pobox.com>, and makes this equivalent to the
post-squash version sitting in gitster/ab/gc-docs now.
Ævar Arnfjörð Bjarmason (11):
gc docs: modernize the advice for manually running "gc"
gc docs: stop noting "repack"
Amend the "NOTES" section to fix up wording that's been with us since
3ffb58be0a ("doc/git-gc: add a note about what is collected",
2008-04-23).
I can't remember when/where anymore (I think Freenode #Git), but at
some point I was having a conversation with someone who was convinced
that "gc" would
Change the AsciiDoc formatting so that an example of "gc --auto" isn't
rendered as "git-gc(1) --auto", but as "git gc --auto". This is
consistent with the rest of the links and command examples in this
documentation.
The formatting I'm changing was initially introduced in
d5d5d7b641 ("gc: automati
Remove the mention of specific flags from the "gc" documentation, and
leave it at describing what we'll do instead. As seen in builtin/gc.c
we'll use various repack flags depending on what we detect we need to
do, so this isn't always accurate.
More importantly, a subsequent change is about to rem
The existing "gc --aggressive" docs come just short of recommending to
users that they run it regularly. I've personally talked to many users
who've taken these docs as an advice to use this option, and have,
usually it's (mostly) a waste of time.
So let's clarify what it really does, and let the
Re-flow the "gc.*" section in "config". A previous commit moved this
over from the "gc" docs, but tried to keep as many of the lines
identical to benefit from diff's move detection.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/config/gc.txt | 17 -
1 file changed, 8 i
Since 07e7dbf0db (gc: default aggressive depth to 50, 2016-08-11) we
somewhat confusingly use the same depth under --aggressive as we do by
default.
As noted in that commit that makes sense, it was wrong to make more
depth the default for "aggressive", and thus save disk space at the
expense of ru
Amend the "PACKFILE OPTIMIZATION" section in "fast-import" to explain
that simply running "git gc --aggressive" after a "fast-import" should
properly optimize the repository. This is simpler and more effective
than the existing "repack" advice (which I'm keeping as it helps
explain things) because
The chance of a repository being corrupted due to a "gc" has nothing
to do with whether or not that "gc" was invoked via "gc --auto", but
whether there's other concurrent operations happening.
This is already noted earlier in the paragraph, so there's no reason
to suggest this here. The user can i
Clean up the grammar in the documentation for
"gc.bigPackThreshold". This documentation was added in 9806f5a7bf ("gc
--auto: exclude base pack if not enough mem to "repack -ad"",
2018-04-15).
Saying "the amount of memory estimated for" flows more smoothly than
the previous "the amount of memory is
Rather than duplicating the documentation for the various "gc" options
let's include the "gc" docs from git-config. They were mostly better
already, and now we don't have the same docs in two places with subtly
different wording.
In the cases where the git-gc(1) docs were saying something the "gc"
The docs have been recommending that users need to run this manually,
but that hasn't been needed in practice for a long time except in
exceptional circumstances.
Let's instead have this reflect reality and say that most users don't
need to run this manually at all, while briefly describing the so
struct stat_data and struct cache_time both use unsigned ints for all
their members. However the format string for 'git ls-files --debug'
currently uses %d for formatting these numbers. This means that we
potentially print these values incorrectly if they are greater than
INT_MAX.
This has been
On 04/07, Kapil Jain wrote:
> below is my understanding from reading the parts of code as suggested on IRC.
>
> what is the use of ce_stage macro ?
> tells about stage of an index entry.
> if ce_stage says, stage #0 i.e staging area, then that index entry is
> in staging area
> and nothing needs t
Duy Nguyen writes:
> Phew... I didn't break anything!
>
> That behavior has been gone since 2c6b6d9f7d (help: make option --help
> open man pages only for Git commands, 2016-08-26). Ralf did not
> mention why he thought "git --help" was a bad idea. But it
> was considered a bug by Junio [1]
>
>
On Fri, Apr 05, 2019 at 10:36:48PM -0700, Taylor Blau wrote:
> > > Of those, I think (3) is probably the best path forward. However, this
> > > patch does none of them. In the name of expediently fixing the
> > > regression to a normal "rev-list --objects" that we use for connectivity
> > > checks
below is my understanding from reading the parts of code as suggested on IRC.
what is the use of ce_stage macro ?
tells about stage of an index entry.
if ce_stage says, stage #0 i.e staging area, then that index entry is
in staging area
and nothing needs to be done.
else a temporary index entry is
Hey Chris!
On Sun, 7 Apr 2019 09:15:30 +0200 Christian Couder
wrote:
> As we are close to the deadline (April 9th) for proposal submissions,
> I think it's a good idea to already upload your draft proposal on the
> GSoC site. I think you will be able to upload newer versions until the
> deadlin
Hi Duy,
On 07/04/2019 04:20, Duy Nguyen wrote:
On Sun, Apr 7, 2019 at 12:31 AM Philip Oakley wrote:
Following the discussions about the tag peeling issue, I thought to have
a look at what the git glossary says.
I had it in my head that when the git guides were linked to the help
system, that
On Sun, Apr 07, 2019 at 05:00:11PM +0700, Duy Nguyen wrote:
> So, with something like a patch below (not tested), you should be able
> to write
>
> worktrees = repo_get_worktrees(revs->repo, 0);
> ...
> struct repository *r = repo_worktree_init(wt);
> if (re
On Sun, Apr 07, 2019 at 01:07:12PM +0530, Kapil Jain wrote:
> Signed-off-by: Kapil Jain
> ---
>
> In read-cache, the read_index_from() function had a TODO task, this
> patch completes that.
This line at least should be above the "---" line (i.e. part of the
commit message).
> diff --git a/read-
Signed-off-by: Kapil Jain
---
In read-cache, the read_index_from() function had a TODO task,
this patch completes that. There are some other functions in the same file
where this exact TODO needs to be done, will proceed to do them once this patch
is accepted.
running test gave 256 not okays, e
Hi Rohit,
On Fri, Apr 5, 2019 at 11:32 PM Rohit Ashiwal
wrote:
>
> Here is one more iteration of my draft proposal[1]. RFC.
Nice, thanks for iterating on this!
As we are close to the deadline (April 9th) for proposal submissions,
I think it's a good idea to already upload your draft proposal on
60 matches
Mail list logo
