> I was trying to see if this is something we can leave out to limit the
> initial scope.
Oh, in that case, "yes". :-) If there's a need to cut something,
origin parents would be a viable candidate.
I was thinking that this file could document the final goal so that if
anyone else wanted to
On Tue, Nov 20, 2018 at 03:04:39PM +, Ævar Arnfjörð Bjarmason wrote:
> Add more progress output to the output already added in
> 7b0f229222 ("commit-graph write: add progress output", 2018-09-17).
>
> As noted in that commit most of the progress output isn't displayed on
> small repositories,
On Tue, Nov 20, 2018 at 11:04 AM Jeff King wrote:
>
> Commit 108f530385 (pack-objects: move tree_depth into 'struct
> packing_data', 2018-08-16) dynamically manages a tree_depth array in
> packing_data that maintains one of these invariants:
>
> 1. tree_depth is NULL (i.e., the requested
On 11/20/2018 4:44 AM, Jeff King wrote:
In cases like this I think it's often a good idea to have a perf test.
Those are expensive anyway, and we'd have the double benefit of
exercising the code and showing off the performance improvement. But the
delta-island code only makes sense on a very
On 11/20/2018 1:11 AM, Jonathan Nieder wrote:
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git
On 11/20/2018 4:26 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Nov 20 2018, Jonathan Nieder wrote:
Just commenting here on the end-state of this since it's easier than
each patch at a time:
First, do we still need to be doing %.4s instead of just %s? It would be
easier for translators / to
On 11/20/2018 1:14 AM, Jonathan Nieder wrote:
If a user explicitly sets
[index]
threads = true
to read the index using multiple threads, ensure that index writes
include the offset table by default to make that possible. This
ensures that the user's intent of
On Tue, Nov 20, 2018 at 08:06:16AM -0500, Ben Peart wrote:
> >diff --git a/read-cache.c b/read-cache.c
> >index 4ca81286c0..1e9c772603 100644
> >--- a/read-cache.c
> >+++ b/read-cache.c
> >@@ -2689,6 +2689,15 @@ void update_index_if_able(struct index_state *istate,
> >struct lock_file *lockfile
>
On 11/20/2018 1:12 AM, Jonathan Nieder wrote:
As with EOIE, popular versions of Git do not support the new IEOT
extension yet. When accessing a Git repository written by a more
modern version of Git, they correctly ignore the unrecognized section,
but in the process they loudly warn
On 11/20/2018 1:11 AM, Jonathan Nieder wrote:
Since 3b1d9e04 (eoie: add End of Index Entry (EOIE) extension,
2018-10-10) Git defaults to writing the new EOIE section when writing
out an index file. Usually that is a good thing because it improves
threaded performance, but when a Git
On 15/11/2018 00:55, sxe...@google.com wrote:
From: Stefan Xenos
+Obsolescence across cherry-picks
+
+By default the evolve command will treat cherry-picks and squash merges as
being
+completely separate from the original. Further amendments to the original
On 20/11/2018 12:18, Phillip Wood wrote:
On 15/11/2018 00:55, sxe...@google.com wrote:
From: Stefan Xenos
+Divergence
+--
+From the user’s perspective, two changes are divergent if they both
ask for
+different replacements to the same commit. More precisely, a target
commit is
Hi Stefan
Thanks for working on this, I think it could be a really useful addition
to git. I'd echo Gábor's comments about making commands descriptive and
easy for the user to find, git has aliases, accepts abbreviated option
names and has shell completion so I don't think typing is really
On Tue, Nov 20, 2018 at 05:58:25AM -0500, Jeff King wrote:
> On Tue, Nov 20, 2018 at 05:45:28AM -0500, Jeff King wrote:
>
> > On Tue, Nov 20, 2018 at 12:34:04AM +0100, SZEDER Gábor wrote:
> >
> > > > I do notice that many of the existing "FATAL:" errors use descriptor 5,
> > > > which goes to
On Tue, Nov 20, 2018 at 12:25:38PM +0100, SZEDER Gábor wrote:
> > but we do not
> > usually bother to do so for our helper functions (like test_cmp).
>
> test_i18ngrep() does since your 03aa3783f2 (t: send verbose
> test-helper output to fd 4, 2018-02-22).
Oh, indeed. Usually I find myself
On Mon, Nov 19, 2018 at 02:49:20PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
>
> > The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> > checking the output of two 'git rev-parse' commands, which means that
> > its output on failure is
Hi Ævar,
On Mon, 19 Nov 2018, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Nov 14 2018, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin
> >
> > It is a good idea to error out early upon seeing, say, `-Cbad`, rather
> > than starting the rebase only to have the `--am`
On Tue, Nov 20, 2018 at 05:45:28AM -0500, Jeff King wrote:
> On Tue, Nov 20, 2018 at 12:34:04AM +0100, SZEDER Gábor wrote:
>
> > > I do notice that many of the existing "FATAL:" errors use descriptor 5,
> > > which goes to stdout. I'm not sure if those should actually be going to
> > > stderr
On Tue, Nov 20, 2018 at 12:34:04AM +0100, SZEDER Gábor wrote:
> > I do notice that many of the existing "FATAL:" errors use descriptor 5,
> > which goes to stdout. I'm not sure if those should actually be going to
> > stderr (or if there's some TAP significance to those lines).
>
> I chose to
On Tue, Nov 20 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Nov 15 2018, sxe...@google.com wrote:
>
>>> +Parent-type
>>> +---
>>> +The “parent-type” field in the commit header identifies a commit as a
>>> +meta-commit and indicates the meaning for each of its
On Tue, Nov 20 2018, Jonathan Nieder wrote:
Just commenting here on the end-state of this since it's easier than
each patch at a time:
First, do we still need to be doing %.4s instead of just %s? It would be
easier for translators / to understand what's going on if it were just
%s. I.e. "this
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> tests 3-8 seem to fail because perl is hardcoded to /urs/bin/perl in
> t5562/invoke-with-content-length.pl, while I seem to be getting some
> sporadic errors in 9 with the following output :
>
> ++ env
On Sun, Nov 18, 2018 at 6:45 AM Anders Waldenborg wrote:
> By default trailer lines are terminated by linebreaks ('\n'). By
> specifying the new 'separator' option they will instead be separated by
> user provided string and have separator semantics rather than terminator
> semantics. The
On Sun, Nov 18, 2018 at 6:45 AM Anders Waldenborg wrote:
> With the new "key=" option to %(trailers) it often makes little sense to
> show the key, as it by definition already is know which trailer is
s/know/known/
> printed there. This new "valueonly" option makes it omit the key when
>
"Derrick Stolee via GitGitGadget" writes:
> @@ -3143,6 +3144,9 @@ int prepare_revision_walk(struct rev_info *revs)
> commit_list_sort_by_date(>commits);
> if (revs->no_walk)
> return 0;
> + if (revs->limited &&
> + git_env_bool(GIT_TEST_COMMIT_GRAPH,
Anders Waldenborg writes:
> + followed by a colon and zero or more comma-separated options:
> + ** 'only': omit non-trailer lines from the trailer block.
> + ** 'unfold': make it behave as if interpret-trailer's `--unfold`
> + option was given.
> + ** 'key=': only show trailers with
Anders Waldenborg writes:
> + followed by a colon and zero or more comma-separated options:
> + ** 'only': omit non-trailer lines from the trailer block.
> + ** 'unfold': make it behave as if interpret-trailer's `--unfold`
> + option was given.
> + ** 'key=': only show trailers with
On Tue, Nov 20, 2018 at 06:04:54AM +0100, tbo...@web.de wrote:
> From: Torsten Bögershausen
>
> Currently the length of data which is stored in memory is stored
> in "unsigned long" at many places in the code base.
> This is OK when both "unsigned long" and size_t are 32 bits,
> (and is OK when
Duy Nguyen writes:
>> > I see this at the same level as "Switched to branch 'foo'" which is
>> > also protected by opts->quiet. If we start hiding messages based on
>> > tty it should be done for other messages in update_refs_for_switch()
>> > too, I guess?
>
> No let's drop this for now. I
Duy Nguyen writes:
>
> - for (i = 0; i < state->istate->cache_nr; i++) {
> + for (i = 0; i < trust_ino && state->istate->cache_nr; i++) {
There is some typo here, but modulo that this looks like the right
thing to do.
> @@ -419,10 +419,24 @@ static void mark_colliding_entries(const
Sven Strickroth writes:
> This also removes an implicit conversion from size_t (unsigned) to int
> (signed).
>
> _stricmp as well as _strnicmp are both available since VS2012.
>
> Signed-off-by: Sven Strickroth
> ---
> compat/msvc.h | 8 +---
> 1 file changed, 1 insertion(+), 7
Torsten Bögershausen writes:
> The only problematic system is Win64, where "unsigned long" is 32 bit,
> and therefore we must use size_t to address data in memory.
> This is not to be confused with off_t, which is used for "data on disk"
> (and nothing else) or timestamp_t which is used for
Ævar Arnfjörð Bjarmason wrote:
> On Thu, Nov 15 2018, sxe...@google.com wrote:
>> +Parent-type
>> +---
>> +The “parent-type” field in the commit header identifies a commit as a
>> +meta-commit and indicates the meaning for each of its parents. It is never
>> +present for normal commits.
Hi,
Stefan Xenos wrote:
> But since several comments have focused on the commands, let's brainstorm!
>
> Here's some options that occur to me:
>
> 1. Three commands: evolve + change + obslog as top-level commands (the
> current proposal). Change gets a bunch of subcommands for manipulating
> the
ok 99 - colliding file detection
as well in macOS with APFS
Carlo
Stefan Xenos writes:
>> But it is not immediately obvious to me how it would help to have
>> "Z was cherry-picked from W" in "evolve".
>
> The evolve command would use it for handling the
> obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
> a commit and then amends the
On 19/11/2018 23:29, Ramsay Jones wrote:
>
>
> On 19/11/2018 21:03, Duy Nguyen wrote:
>> First of all, Ramsay, it would be great if you could test the below
>> patch and see if it works on Cygwin. I assume since Cygwin shares the
>> underlying filesystem, it will share the same "no trusting
On Mon, Nov 19, 2018 at 02:44:32PM -0500, Jeff King wrote:
> On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
>
> > Send these "bug in the test script" error messages directly to the
> > test scripts standard error and thus to the terminal, so those bugs
> > will be much harder to
On 19/11/2018 21:03, Duy Nguyen wrote:
> First of all, Ramsay, it would be great if you could test the below
> patch and see if it works on Cygwin. I assume since Cygwin shares the
> underlying filesystem, it will share the same "no trusting inode"
> issue with native builds (or it calculates
On Mon, Nov 19, 2018 at 08:23:00PM +, Ævar Arnfjörð Bjarmason wrote:
> Amend the progress output added in 7b0f229222 ("commit-graph write:
> add progress output", 2018-09-17) so that the total numbers it reports
> aren't higher than the total number of commits anymore. See [1] for a
> bug
On Mon, Nov 19, 2018 at 11:26:03PM +0200, Max Kirillov wrote:
> On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> > NO_CURL reflects the build setting (for http support); CURL checks for
> > the curl binary, but as Ævar points out the requirements must be from
> > somewhere else
On Mon, Nov 19, 2018 at 11:36:08AM -0800, Carlo Arenas wrote:
> NO_CURL reflects the build setting (for http support); CURL checks for
> the curl binary, but as Ævar points out the requirements must be from
> somewhere else since a NO_CURL=1 build (tested in macOS) still passes
> the test, but not
> Subcommand names and --long-options are just as descriptive.
Yeah, I'm convinced about the descriptiveness. If you check the latest
version of the patch, I've already updated the "change" command to use
subcommands rather than lettered arguments.
> If a user wants to deal with reflogs, then
On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote:
> Thanks Carlo for the file and "stat" output. The problem is APFS has
> 64-bit inode (according to the Internet) while we store inodes as
> 32-bit, so it's truncated.
> ...
> We will have to deal with the same
> truncated inode elsewhere to make
... and I "dear Ramsay" without CCing him.. sigh.. sorry for the noise.
On Mon, Nov 19, 2018 at 10:03 PM Duy Nguyen wrote:
>
> First of all, Ramsay, it would be great if you could test the below
> patch and see if it works on Cygwin. I assume since Cygwin shares the
> underlying filesystem, it
First of all, Ramsay, it would be great if you could test the below
patch and see if it works on Cygwin. I assume since Cygwin shares the
underlying filesystem, it will share the same "no trusting inode"
issue with native builds (or it calculates inodes anyway using some
other source?).
Back to
On Mon, Nov 19 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>
>>> [...]
>>> builtin/rebase.c
>>> 62c23938fa 55) return env;
>>> [...]
>>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>>> where rebase.useBuiltin is
On 11/19/2018 3:23 PM, Ævar Arnfjörð Bjarmason wrote:
+ if (report_progress)
+ progress = start_delayed_progress(
+ _("Expanding reachable commits in commit graph"), j =
0);
This should be the only one that shows up in all but the very largest of
Hi,
Xenos wrote:
> Lets explore the "when" question. I think there's a compelling reason
> to add them as soon as possible - namely, gerrit. If and when we come
> to some sort of agreement on this proposal, gerrit could start adding
> tooling to understand change graphs as an alternative to
> But it is not immediately obvious to me how it would help to have "Z was
> cherry-picked from W" in "evolve".
The evolve command would use it for handling the
obsolescence-over-cherry-pick (OOCP) feature. If someone cherry-picks
a commit and then amends the original, the evolve command would
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> The 'test_cmp_rev' helper is merely a wrapper around 'test_cmp'
> checking the output of two 'git rev-parse' commands, which means that
> its output on failure is not particularly informative, as it's
> basically two OIDs with a bit
On Mon, Nov 19, 2018 at 02:13:26PM +0100, SZEDER Gábor wrote:
> Send these "bug in the test script" error messages directly to the
> test scripts standard error and thus to the terminal, so those bugs
> will be much harder to overlook. Instead of updating all ~20 such
> 'error' calls with a
On Mon, Nov 19, 2018 at 9:23 AM Ramsay Jones
wrote:
> ok 99 # skip colliding file detection (missing !CYGWIN of
> !MINGW,!CYGWIN,CASE_INSENSITIVE_FS)
you need to enable this specific test first (removing !CYGWIN) so it
doesn't get skipped
Carlo
On Mon, Nov 19, 2018 at 10:40 AM Max Kirillov wrote:
>
> On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> > 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> > 2018-07-27)
> > introduced all tests but without a check for CURL support from git.
>
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 19 2018, Derrick Stolee wrote:
>> [...]
>> builtin/rebase.c
>> 62c23938fa 55) return env;
>> [...]
>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>> where rebase.useBuiltin is off
>
> This one would be covered with
>
On Mon, Nov 19, 2018 at 02:15:35AM -0800, Carlo Marcelo Arenas Belón wrote:
> 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> 2018-07-27)
> introduced all tests but without a check for CURL support from git.
The tests should not be using curl, they just pipe data to
On Mon, Nov 19, 2018 at 6:14 PM Carlo Arenas wrote:
>
> On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
> >
> > Did you test it on Mac ?
>
> macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
>
> > So what exactly are you trying to fix ?
>
> I get
>
> not ok 99 -
Am 19.11.2018 um 06:33 schrieb Torsten Bögershausen:
> The archive-tar.c is actually a good example, why a step-by-step update
> is not ideal (the code would not work any more on Win64).
>
> If we look here:
>
> static int stream_blocked(const struct object_id *oid)
> {
> struct
On Sun, Nov 18, 2018 at 03:18:52PM -0500, Derrick Stolee wrote:
> On 11/17/2018 10:11 AM, tbo...@web.de wrote:
> >From: Torsten Bögershausen
> >
> >Currently Git users can not commit files >4Gib under 64 bit Windows,
> >where "long" is 32 bit but size_t is 64 bit.
> >Improve the code base in
On 19/11/2018 12:28, Torsten Bögershausen wrote:
> On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote:
>> While I don't have an HFS+ volume to test, I suspect this patch should be
>> needed for both, even if I have to say thay even the broken output was
>> better than the current state.
>>
On Mon, Nov 19, 2018 at 4:28 AM Torsten Bögershausen wrote:
>
> Did you test it on Mac ?
macOS 10.14.1 but only using APFS, did you test my patch with HFS+?
> So what exactly are you trying to fix ?
I get
not ok 99 - colliding file detection
#
# grep X icasefs/warning &&
# grep x
Ping?
We are at -rc0, this progress output is a new feature since v2.19.0,
and the numbers shown are still way off.
On Mon, Oct 15, 2018 at 06:54:47PM +0200, SZEDER Gábor wrote:
> On Mon, Sep 17, 2018 at 03:33:35PM +, Ævar Arnfjörð Bjarmason wrote:
>
> > @@ -560,6 +563,9 @@ static int
On Sat, Nov 17, 2018 at 12:30:58PM -0800, Stefan Xenos wrote:
> > Further, I see that this document tries to suggest a proliferation of new
> > commands
>
> It does. Let me explain a bit about the reasoning behind this
> breakdown of commands. My main priority was to keep the commands as
>
On Sun, Nov 18, 2018 at 8:58 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> As noted in
> https://public-inbox.org/git/87d0r217vr@evledraar.gmail.com/ I'm
> happy to see this implemented. I have not read this patch in much
> detail...
>
> > [...]
On Mon, Nov 19, 2018 at 12:42 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
> > When :(attr) was added, it supported one of the two main pathspec
> > matching functions, the one that works on a list of paths. The other
> > one works on a tree,
On Mon, Nov 19, 2018 at 12:16 PM Ævar Arnfjörð Bjarmason
wrote:
> As an aside, how do you do the inverse of matching for an attribute by
> value? I.e.:
>
> $ git ls-files | wc -l; git ls-files ':(attr:diff=perl)' | wc -l
> 3522
> 65
>
> I'd like something gives me all files that don't
On Mon, Nov 19, 2018 at 2:08 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Nov 12 2018, Duy Nguyen wrote:
>
> > On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
> >>
> >> Nguyễn Thái Ngọc Duy writes:
> >>
> >> > Since the purpose of printing this is to help disambiguate. Only do it
> >>
On Mon, Nov 19, 2018 at 02:28:18PM +0100, SZEDER Gábor wrote:
> diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh
> index d158c8d0bf..fc84db67a1 100644
> --- a/t/test-lib-functions.sh
> +++ b/t/test-lib-functions.sh
> @@ -854,9 +854,23 @@ test_must_be_empty () {
>
> # Tests that
On Mon, Nov 12 2018, Duy Nguyen wrote:
> On Mon, Nov 12, 2018 at 7:21 AM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > Since the purpose of printing this is to help disambiguate. Only do it
>> > when "--" is missing (the actual reason though is many tests check
>> > empty
On Wed, Nov 14 2018, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> It is a good idea to error out early upon seeing, say, `-Cbad`, rather
> than starting the rebase only to have the `--am` backend complain later.
>
> Let's do this.
>
> The only options accepting
On 2018-11-19 09:20, Carlo Marcelo Arenas Belón wrote:
> While I don't have an HFS+ volume to test, I suspect this patch should be
> needed for both, even if I have to say thay even the broken output was
> better than the current state.
>
> Travis seems to be using a case sensitive filesystem so
On Sun, Nov 18, 2018 at 08:51:52PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > But this also reveals an interesting thing: even though we walk on a
> > tree, we check attributes from _worktree_ (and optionally fall back to
> > the index). This is how attributes are implemented since forever. I
> >
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
> When :(attr) was added, it supported one of the two main pathspec
> matching functions, the one that works on a list of paths. The other
> one works on a tree, tree_entry_interesting(), which gets :(attr)
> support in this series.
>
> With
On Sun, Nov 18 2018, Ævar Arnfjörð Bjarmason wrote:
> On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
>
>> When :(attr) was added, it supported one of the two main pathspec
>> matching functions, the one that works on a list of paths. The other
>> one works on a tree, tree_entry_interesting(),
On Mon, Nov 19 2018, Carlo Marcelo Arenas Belón wrote:
> 6c213e863a ("http-backend: respect CONTENT_LENGTH for receive-pack",
> 2018-07-27)
> introduced all tests but without a check for CURL support from git.
>
> Signed-off-by: Carlo Marcelo Arenas Belón
> ---
>
On 2018-11-19 00:40, Junio C Hamano wrote:
> Derrick Stolee writes:
>
>>> This needs to go on top of pu, to cover all the good stuff
>>>cooking here.
>>
>> Better to work on top of 'master', as the work in 'pu' will be
>> rewritten several times, probably.
>
> We may not be able to find any
Stefan Xenos writes:
> The scenario you describe would not produce an origin edge in the
> metacommit graph. If the user amended X, there would be no origin
> edges - just a replacement. If you cherry-picked Z you'd get no
> replacements and just an origin. In neither case would you get both
>
Stefan Xenos writes:
>> I meant the project's history, not the meta-graph thing.
>
> In that case, we agree. The proposal suggests that "origin" should be
> reachable from the meta-graph for the cherry-picked commit, NOT the
> cherry-picked commit itself. Does that resolve our disagreement, or
> I meant the project's history, not the meta-graph thing.
In that case, we agree. The proposal suggests that "origin" should be
reachable from the meta-graph for the cherry-picked commit, NOT the
cherry-picked commit itself. Does that resolve our disagreement, or is
reachability from the
Stefan Xenos writes:
>> And the other half is that while I consider the "origin" thing is
>> unnecessary for the above reasons, having it means we need to not
>> just transfer the history reading to aa7ce555 and d664309ee (which
>> are necessary anyway while we have histories to transplant from
Jeff King writes:
> And it seems we worked around this in de2f95ebed (mailmap: work around
> implementations with pure inline strcasecmp, 2013-09-12). So I don't
> think there is any blocker there.
>
> (Though of course I have no idea on other portability questions around
> _stricmp(); I'll
Nguyễn Thái Ngọc Duy writes:
> But this also reveals an interesting thing: even though we walk on a
> tree, we check attributes from _worktree_ (and optionally fall back to
> the index). This is how attributes are implemented since forever. I
> think this is not a big deal if we communicate
> Am I correct to understand that the reason why a commit object is
> (ab|re)used to represent a meta-commit is because by doing so we
> would get connectivity (i.e. fetching & pushing would transfer all
> the associated objects along) for free, and by not representing it
> as a new and different
Derrick Stolee writes:
>> This needs to go on top of pu, to cover all the good stuff
>>cooking here.
>
> Better to work on top of 'master', as the work in 'pu' will be
> rewritten several times, probably.
We may not be able to find any good moment to update some codepaths
with deep
Stefan Xenos writes:
>> I don't think this counts as a typical modification and is probably hard to
>> detect automatically.
>
> Clever use of commands! (side: wouldn't it just be easier to just use
> git commit --amend, though?)
When an original commit is mostly an early part of a feature,
> This breaks the "git change" symmetry with "git branch", but after
> responding to other messages regarding that command, I'm starting to
> think that's not really a problem.
Sorry, I appended that sentence to the wrong paragraph. It should have
gone with the previous one that regarding the
> I don't think this counts as a typical modification and is probably hard to
> detect automatically.
Clever use of commands! (side: wouldn't it just be easier to just use
git commit --amend, though?)
Either way, I agree that there should be a way to manually create a
change graph or modify one
On Sun, Nov 18, 2018 at 10:02:02PM +0100, Sven Strickroth wrote:
> This also removes an implicit conversion from size_t (unsigned) to int
> (signed).
>
> _stricmp as well as _strnicmp are both available since VS2012.
Once upon a time we had problems with taking a function pointer of
strcasecmp
On 11/17/2018 10:11 AM, tbo...@web.de wrote:
From: Torsten Bögershausen
Currently Git users can not commit files >4Gib under 64 bit Windows,
where "long" is 32 bit but size_t is 64 bit.
Improve the code base in small steps, as small as possible.
What started with a small patch to replace
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
As noted in
https://public-inbox.org/git/87d0r217vr@evledraar.gmail.com/ I'm
happy to see this implemented. I have not read this patch in much
detail...
> [...]
> Documentation/glossary-content.txt | 2 +
> [...]
> diff --git
On Sun, Nov 18 2018, Nguyễn Thái Ngọc Duy wrote:
> When :(attr) was added, it supported one of the two main pathspec
> matching functions, the one that works on a list of paths. The other
> one works on a tree, tree_entry_interesting(), which gets :(attr)
> support in this series.
>
> With
On Sat, Nov 17, 2018 at 06:32:33PM -0500, Denton Liu wrote:
> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
> index 106148254d..0d3db34f08 100755
> --- a/t/t7600-merge.sh
> +++ b/t/t7600-merge.sh
> @@ -247,6 +247,54 @@ test_expect_success 'merge --squash c3 with c7' '
> test_cmp expect
On Sun, Nov 18 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> Do you mean that you don't agree that following should always create
>> both "foo" and e.g. ".git/refs/heads/master" with the same 644
>> (-rw-rw-r--) mode:
>>
>> (
>> rm -rf /tmp/repo &&
>>
Ævar Arnfjörð Bjarmason writes:
> Do you mean that you don't agree that following should always create
> both "foo" and e.g. ".git/refs/heads/master" with the same 644
> (-rw-rw-r--) mode:
>
> (
> rm -rf /tmp/repo &&
> umask 022 &&
> git init /tmp/repo &&
> cd
Denton Liu writes:
>> I wonder if this is what you really meant to have instead:
>>
>> >else if (cleanup_mode == COMMIT_MSG_CLEANUP_SCISSORS &&
>> > - whence == FROM_COMMIT)
>> > - wt_status_add_cut_line(s->fp);
>> > + whence ==
Slavica Djukic writes:
>> Yes, but for that you'd need to be checking the resulting commit
>> object that represents the stash entry. It should be created under
>> the substitute identity.
> Would it be correct to check it like this:
>
> git reset &&
> >1 &&
> git add 1
Resending this without HTML enabled... sorry if you receive it twice.
> The file name and the title are in a mismatch.
Good point. However, the focus of this proposal really is supposed to
be on the underlying data structure, not just the evolve command
(which is the driving use-case for the
On Sat, Nov 17 2018, Junio C Hamano wrote:
> Christian Couder writes:
>
>> "However, as noted in those commits we'd still create the file as
>> 0600, and would just re-chmod it only if core.sharedRepository is set
>> to "true" or "all". If core.sharedRepository is unset or set to
>> "false",
> I am not sure that we necessarily need this to be a graph. I think part
> of the problems with not being able to GC *any* of this is by this
> requirement to have it stored in a graph, rather than having mappings from
> which you could reconstruct any non-GC'ed parts of that graph, if you
>
Hi Junio,
On 16-Nov-18 11:12 AM, Junio C Hamano wrote:
Slavica Djukic writes:
+ git var GIT_COMMITTER_IDENT >actual &&
+ test_cmp expected actual &&
I am not sure what you are testing with this step. There is nothing
that changed environment variables or configuration since we
401 - 500 of 63152 matches
Mail list logo
