On Tue, Dec 29, 2015 at 7:10 PM, Nguyễn Thái Ngọc Duy wrote:
> This could be convenient when tests are independent from the rest in the
> same file. Normally we would do this
> ...
Before anybody comments about this patch. I missed Junio and Jeff's
comments when the patch was posted separately a
On Wed, Dec 30, 2015 at 1:27 AM, Junio C Hamano wrote:
> It is more important to envision what we would do in the future when
> a command that takes a pattern (or a set of patterns) to match the
> refnames with _and_ another pattern (or a set of patterns) to match
> something else, and take that i
On Wed, Dec 30, 2015 at 4:24 PM, Dennis Kaarsemaker
wrote:
> I've hit a segfault in git reflog with latest git, reproducable in git.git:
>
> spirit:~/code/git (master)$ ./git describe
> v2.7.0-rc3
>
> I've minimized the reflog to:
>
> spirit:~/code/git (master)$ cat .git/logs/HEAD
> 2635c2b8bfc9ae
On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
wrote:
> On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote:
>> spirit:~/code/git (master)$ cat .git/logs/HEAD
>> 2635c2b8bfc9aec07b7f023d8e3b3d02df715344
>> 54bc41416c5d3ecb978acb0df80d57aa3e54494c Dennis Kaarsemaker
>> 1446765642 +01
On Wed, Dec 30, 2015 at 6:26 PM, Duy Nguyen wrote:
> On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
> wrote:
>> On wo, 2015-12-30 at 10:24 +0100, Dennis Kaarsemaker wrote:
>>> spirit:~/code/git (master)$ cat .git/logs/HEAD
>>> 2635c2b8bf
On Wed, Dec 30, 2015 at 01:28:06PM +0100, Dennis Kaarsemaker wrote:
> On wo, 2015-12-30 at 18:28 +0700, Duy Nguyen wrote:
> > On Wed, Dec 30, 2015 at 6:26 PM, Duy Nguyen
> > wrote:
> > > On Wed, Dec 30, 2015 at 6:17 PM, Dennis Kaarsemaker
> > > wrote:
> &
On Tue, Dec 29, 2015 at 1:35 PM, Jeff King wrote:
> We sometimes use 32-bit unsigned integers as bit-fields.
> It's fine to access the MSB, because it's unsigned. However,
> doing so as "1 << 31" is wrong, because the constant "1" is
> a signed int, and we shift into the sign bit, causing
> undefi
On Wed, Jan 6, 2016 at 4:13 PM, Dennis Kaarsemaker
wrote:
> On di, 2016-01-05 at 20:52 -0500, Eric Sunshine wrote:
>> On Tue, Jan 5, 2016 at 8:28 PM, Eric Sunshine <
>> sunsh...@sunshineco.com> wrote:
>> > On Tue, Jan 5, 2016 at 8:20 PM, Dennis Kaarsemaker
>> > wrote:
>> > > On di, 2016-01-05 at
On Tue, Jan 5, 2016 at 10:06 PM, Jeff King wrote:
> On Tue, Jan 05, 2016 at 02:40:16PM +, Mike McQuaid wrote:
>
>> Homebrew has a series of convoluted .gitignore rules due to our
>> special/weird use-case of wanting to ignore everything in a working
>> directory except a select few files/direc
On Tue, Jan 5, 2016 at 10:24 PM, Jeff King wrote:
> If you can find a fuzzed packfile that crashes "index-pack", then _that_
> would be a big deal.
I'm sure you know this, but if Jacek moves to break index-pack, then
he/she should also try to break unpack-objects because sometimes we
use that com
On Wed, Jan 6, 2016 at 4:50 PM, Mike McQuaid wrote:
> it’s also a big area where libgit2 was inconsistent with Git’s behaviour on
> either of those versions too.
Yeah.. it looks like libgit2's gitignore support was written new, not
imported from C Git, so behavior differences (especially in corn
On Wed, Jan 6, 2016 at 8:08 AM, Mostyn Bramley-Moore wrote:
> On 01/04/2016 06:46 PM, Junio C Hamano wrote:
Magic pattern annotation like we do for pathspecs Duy raised may not
be a bad idea, either, and would probably be easier to teach people.
Just like in Perl "(?i)$any_pattern"
On Wed, Jan 6, 2016 at 7:30 PM, Sebastian Schuberth
wrote:
> Hi,
>
> I recently compared the results of doing
>
> $ git clone --depth=1 https://github.com/git/git.git git-clone-depth-1
>
> versus
>
> $ mkdir git-fetch-depth-1
> $ cd git-fetch-depth-1
> $ git init
> $ git remote
On Wed, Dec 23, 2015 at 8:34 PM, Michael Haggerty wrote:
> On 12/03/2015 01:35 AM, David Turner wrote:
>> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
>> index 8174d27..9ea6753 100644
>> --- a/Documentation/git-init.txt
>> +++ b/Documentation/git-init.txt
>> @@ -12,7 +12,7
On Sat, Dec 8, 2018 at 7:09 AM Junio C Hamano wrote:
> If this were "Jonathan asked Brandon if we want to record an address
> we can reach him in our .mailmap file and sent a patch to add one",
Not sure about Jonathan, but I did.
> then the story is different, and I tend to agree with you that s
On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day wrote:
>
>
> from "man git-reset":
>
> SYNOPSIS
> git reset [-q] [] [--] ...
> git reset (--patch | -p) [] [--] [...]
> git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q]
> []
>
> oddly, the third form says nothing about poss
On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day wrote:
>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day
> > wrote:
> > >
> > >
> > > from "man git-reset":
> > >
> > >
On Sat, Dec 8, 2018 at 6:37 PM Robert P. J. Day wrote:
>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day
> > wrote:
> > >
> > > On Sat, 8 Dec 2018, Duy Nguyen wrote:
> > >
> > > > On
On Thu, Nov 29, 2018 at 9:15 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Thu, Nov 29 2018, Stefan Beller wrote:
>
> > On Thu, Nov 29, 2018 at 7:00 AM Ævar Arnfjörð Bjarmason
> > wrote:
> >>
> >> A co-worker asked me today how space could be saved when you have
> >> multiple checkouts of the same r
On Mon, Dec 10, 2018 at 03:36:54PM +0900, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > The compiler reports this because show_gitcomp() never actually
> > returns a value:
> >
> > "parse-options.c", line 520: warning: Function has no return
> > statement : show_gitcomp
> >
On Sun, Dec 9, 2018 at 9:04 PM Thomas Gummerer wrote:
>
> The 'git worktree' command used to be just another mode in 'git
> checkout', namely 'git checkout --to'. When the tests for the latter
> were retrofitted for the former, the test name was adjusted, but the
> test number was kept, even thou
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
>
> Factor out the 'unlink_entry()' function from unpack-trees.c to
> entry.c. It will be used in other places as well in subsequent
> steps.
>
> As it's no longer a static function, also move the documentation to
> the header file to make it
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
>
> 'checkout_entry()' currently only supports creating new entries in the
> working tree, but not deleting them. Add the ability to remove
> entries at the same time if the entry is marked with the CE_WT_REMOVE
> flag.
>
> Currently this does
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
>
> When marking cache entries for removal, and later removing them all at
> once using 'remove_marked_cache_entries()', cache entries currently
> have to be invalidated manually in the cache tree and in the untracked
> cache.
>
> Add an invali
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
> @@ -302,15 +310,29 @@ static int checkout_paths(const struct checkout_opts
> *opts,
> ce->ce_flags &= ~CE_MATCHED;
> if (!opts->ignore_skipworktree && ce_skip_worktree(ce))
> continue;
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
>
> Add a new --cached option to git checkout, which works only on the
> index, but not the working tree, similar to what 'git reset
> -- ... does.
Elijah wanted another mode (and I agree) that modifies worktree but
leaves the index alone. Th
On Sun, Dec 9, 2018 at 9:05 PM Thomas Gummerer wrote:
>
> Currently when 'git checkout -- ...' is invoked with
> multiple pathspecs, where one or more of the pathspecs don't match
> anything, checkout errors out.
>
> This can be inconvenient in some cases, such as when using git
> checkout from a
On Sun, Dec 9, 2018 at 9:04 PM Thomas Gummerer wrote:
> My hope is also that the no-overlay mode could become the new default
> in the restore-files command Duy is currently working on.
I already wrote something like that in git-restore-files.txt even
though the implementation is not there :D
Th
On Mon, Dec 10, 2018 at 6:23 PM Elijah Newren wrote:
> > I wonder if we should move the 'removal' variable in symlinks to
> > 'struct checkout' to reduce another global variable. But I guess
> > that's the problem for another day. It's not the focus of this series.
>
> "move the 'removal' variable
On Mon, Dec 10, 2018 at 7:09 PM Elijah Newren wrote:
> > > For the two current callsites, unpack-trees seems to do this
> > > invalidation itself internally.
> >
> > I'm still a bit scared of this invalidation business in unpack-trees.
> > The thing is, we handle two separate index_state there, sr
On Mon, Dec 10, 2018 at 7:25 PM Elijah Newren wrote:
> > I'm not the unpack-trees man (I think that would still be Junio). And
> > I'm not saying it's sane either. I think it's just some leftover
> > things since Linus split "the index" in unpack-tree operation to
> > 'src', 'result' and 'dst' man
On Mon, Dec 10, 2018 at 6:18 PM Elijah Newren wrote:
> > The final step in the series is to actually make use of this in 'git
> > stash', which simplifies the code there a bit. I am however happy to
> > hold off on this step until the stash-in-C series is merged, so we
> > don't delay that furthe
On Mon, Dec 10, 2018 at 7:47 PM Stefan Beller wrote:
>
> On Sun, Dec 9, 2018 at 2:25 AM Nguyễn Thái Ngọc Duy wrote:
> >
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
> > bisect.c | 3 ++-
> > builtin/config.c | 3 ++-
> > builtin/push.c | 4 +++-
> > co
On Tue, Dec 11, 2018 at 3:13 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > The reason it's in parse_options_step() is because -h is also handled
> > in there. Although -h does not bury exit() deep in the call chain. So
> > how about this as a replacem
On Tue, Dec 11, 2018 at 6:42 PM Sebastian Gniazdowski
wrote:
>
> Hello,
> I've attached a screenshot for running `git help -a' that ends in a
> hang and ~100% cpu usage, for the following ~/.gitconfig (it's also
> attached):
>
> https://raw.githubusercontent.com/agostonbarna/dotfiles-base/master/.
On Tue, Dec 11, 2018 at 7:12 AM Elijah Newren wrote:
>
> On Mon, Dec 10, 2018 at 7:13 PM Junio C Hamano wrote:
> >
> > Duy Nguyen writes:
> >
> > > Elijah wanted another mode (and I agree) that modifies worktree but
> > > leaves the index alone. Thi
On Tue, Dec 11, 2018 at 3:28 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> + if (ce->ce_flags & CE_WT_REMOVE) {
> >> + if (topath)
> >> + BUG("Can't remove entry to a path");
> >&
On Wed, Dec 12, 2018 at 2:27 PM Eric Sunshine wrote:
>
> On Tue, Dec 11, 2018 at 4:50 PM Thomas Gummerer wrote:
> > On 12/10, Duy Nguyen wrote:
> > > On Sun, Dec 9, 2018 at 9:04 PM Thomas Gummerer
> > > wrote:
> > > > Move the worktree tests
I'm not going to bother you with patches (yet) but I could use a few
eyeballs to check the help usage (and perhaps the option grouping) for
commands that take diff options.
Forget about hiding irrelevant options for this particular command for
now. This is something we can do later.
usage: git ra
On Wed, Dec 12, 2018 at 9:05 PM Stefan Beller wrote:
>
> On Wed, Dec 12, 2018 at 11:47 AM Duy Nguyen wrote:
> >
> > I'm not going to bother you with patches (yet) but I could use a few
> > eyeballs to check the help usage (and perhaps the option grouping) for
> &
On Thu, Dec 13, 2018 at 3:05 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Thu, Dec 13 2018, Junio C Hamano wrote:
>
> > Here is an excerpt from a draft edition of "What's cooking" report
> > for topics that are about an immediate 2.20.1 maintenance release,
> > with five topics that I plan to merge
On Thu, Dec 13, 2018 at 7:08 PM Duy Nguyen wrote:
> There's also a bug in my patch (-2 is already being used by
> parse_opt_unknown_cb and my patch will change behavior of git-blame at
> least in theory).
Ah no. Too many magic numbers in parse-options.c code. It's working
fi
On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
wrote:
>
> From: Michael Rappazzo
>
> On a worktree which is not the primary, using the symbolic-ref 'head' was
> incorrectly pointing to the main worktree's HEAD. The same was true for
> any other case of the word 'Head'.
>
> Sig
On Thu, Dec 13, 2018 at 9:34 PM Mike Rappazzo wrote:
>
> On Thu, Dec 13, 2018 at 3:23 PM Duy Nguyen wrote:
> >
> > On Thu, Dec 13, 2018 at 8:56 PM Michael Rappazzo via GitGitGadget
> > wrote:
> > >
> > > From: Michael Rappazzo
> > >
>
On Fri, Dec 14, 2018 at 7:50 AM Jacob Keller wrote:
>
> On Thu, Dec 13, 2018 at 1:16 PM Mike Rappazzo wrote:
> >
> > On Thu, Dec 13, 2018 at 3:48 PM Stefan Beller wrote:
> > >
> > > > > The current situation is definitely a problem. If I am in a worktree,
> > > > > using "head" should be the sa
On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
>
> On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> > FETCH_HEAD... will forever be backed by filesystem. HEAD for example
> > is part of
On Fri, Dec 14, 2018 at 6:38 PM Duy Nguyen wrote:
>
> On Fri, Dec 14, 2018 at 6:22 PM Jacob Keller wrote:
> >
> > On Thu, Dec 13, 2018 at 11:38 PM Duy Nguyen wrote:
> > > Even with a new ref storage, I'm pretty sure pseudo refs like HEAD,
> > > FETCH_HEA
On Sun, Dec 16, 2018 at 7:10 PM Anthony Sottile wrote:
>
> $ git rm foo
> rm 'foo'
> $ touch foo
> $ git add --intent-to-add foo
> $ git status --short
> DA foo
Twisted, but not wrong. It may also be a good idea to describe
intent-to-add status, which is probably something like
[ D]A
On Sun, Dec 16, 2018 at 04:14:46PM -0800, Jonathan Nieder wrote:
> Hi,
>
> Farhan Khan wrote:
> >> Farhan Khan wrote:
>
> >>> I am having trouble figuring out the boundary between two objects in
> >>> the pack file.
> [...]
> > I think the issue is, the compressed object has a fixed
On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
wrote:
>
> Hi,
> I have asked this question on SO
> (https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)
> and usually there are tons of responses on Git questions, but not on
> this o
On Mon, Dec 17, 2018 at 6:17 PM Elijah Newren wrote:
>
> On Mon, Dec 17, 2018 at 8:26 AM Duy Nguyen wrote:
> >
> > On Mon, Dec 17, 2018 at 2:11 PM Mark Kharitonov
> > wrote:
> > >
> > > Hi,
> > > I have asked this question on SO
> > >
On Wed, Dec 19, 2018 at 12:15 AM Robin H. Johnson wrote:
>
> I think this is encapsulated in the v2/promisor work, but wanted to
> check how close that was to fruition, and that it would indeed be
> possible.
>
> This would enable replacement of any workflow that presently uses rsync
> to update.
On Wed, Dec 19, 2018 at 6:04 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Dec 17 2018, Jonathan Nieder wrote:
>
> > v2.11.0-rc3~3^2~1 (stripspace: respect repository config, 2016-11-21)
>
> Minor nit not just on this patch, but your patches in general: I think
> you're the only one using this t
On Thu, Dec 20, 2018 at 1:26 AM brian m. carlson
wrote:
> @@ -5159,6 +5159,8 @@ int diff_opt_parse(struct diff_options *options,
> options->flags.funccontext = 1;
> else if (!strcmp(arg, "--no-function-context"))
> options->flags.funccontext = 0;
> + e
On Thu, Dec 20, 2018 at 6:18 PM Jeff King wrote:
> > I wonder if --follow-symlinks would be a good alternative for this
> > (then if the final destination is unmmapable then we just read the
> > file whole in memory without the user asking, so it will work with
> > pipes). --follow-symlinks then c
On Thu, Dec 20, 2018 at 6:32 PM Jeff King wrote:
>
> On Thu, Dec 20, 2018 at 06:23:42PM +0100, Duy Nguyen wrote:
>
> > On Thu, Dec 20, 2018 at 6:18 PM Jeff King wrote:
> > > > I wonder if --follow-symlinks would be a good alternative for this
> > > > (then
On Fri, Dec 21, 2018 at 9:40 AM Nicholas Hsiang wrote:
>
> Dear git:
>
> When I type `git remote --usage`, The command panel will prompt
> 'error: unknown option `usage', Then there will be `git remote`
> related instructions.
> But I type `git show --usage`, just display 'fatal: unrecognized
> ar
On Thu, Dec 20, 2018 at 2:48 PM Thomas Gummerer wrote:
> diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
> index 801de2f764..4ac8c55865 100644
> --- a/Documentation/git-checkout.txt
> +++ b/Documentation/git-checkout.txt
> @@ -260,6 +260,9 @@ the conflicted merge in th
On Sun, Dec 23, 2018 at 11:40:59PM +, Stan Hu wrote:
> Previously, calling ls-tree with a revision such as
> `master^{tree}:foo/{{path}}` would show the root tree instead of the
> correct tree pointed by foo/{{path}}. If a colon is present in the revision
> name, peel_onion() should assume that
On Thu, Dec 27, 2018 at 7:18 PM Masaya Suzuki wrote:
>
> Without -Wformat, -Wformat-security won't work.
>
> > cc1: error: -Wformat-security ignored without -Wformat
> > [-Werror=format-security]
Compiler name and version?
>
> Signed-off-by: Masaya Suzuki
> ---
> config.mak.dev | 1 +
> 1 fil
On Fri, Dec 28, 2018 at 4:46 PM H. Peter Anvin wrote:
>
> On 12/27/18 3:55 PM, Jonathan Nieder wrote:
> > Hi,
> >
> > H. Peter Anvin wrote:
> >
> >> [merge "version"]
> >> name = Version file merge driver
> >> driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f
> >> %A.tmp.
On Sun, Dec 30, 2018 at 7:38 AM Jeffrey Walton wrote:
>
> I'm trying to determine why a new installation of GnuPG is having
> trouble. The new install is in /usr/local. The other install is from
> the distro and is OK.
>
> Here's the new installation error message:
>
> $ git commit -vvv -S -am
On Mon, Dec 31, 2018 at 5:44 PM Marc Balmer wrote:
>
> Hi
>
> One of the last three commits in git-subtree.sh introduced a regression
> leading to a segfault.
>
> Here is the error message when I try to split out my i18n files:
>
> $ git subtree split --prefix=i18n
> cache for e39a2a0c6431773a5d8
On Mon, Dec 31, 2018 at 6:13 PM Marc Balmer wrote:
>
>
>
> > Am 31.12.2018 um 11:51 schrieb Duy Nguyen :
> >
> > On Mon, Dec 31, 2018 at 5:44 PM Marc Balmer wrote:
> >>
> >> Hi
> >>
> >> One of the last three commits in git
On Mon, Dec 31, 2018 at 6:24 PM Marc Balmer wrote:
> In a (private) Email to me, he indicated that had no time for a fix. Maybe
> he can speak up here?
Well, I guess Junio will revert when he's back after the holidays
then. Meanwhile..
> In any case, if I can help testing, I am in. I just don
On Tue, Jan 1, 2019 at 7:02 AM Albert Burt wrote:
>
> The code that was merged with commit 1102405 left in an TODO that
People usually use something this to produce the commit reference
git show -s --date=short --pretty='format:%h (%s - %ad)'
which produces
110240588d (Merge branch 'sb/obj
On Mon, Dec 31, 2018 at 01:31:21PM +0100, Marc Balmer wrote:
>
>
> > Am 31.12.2018 um 12:36 schrieb Duy Nguyen :
> >
> > On Mon, Dec 31, 2018 at 6:24 PM Marc Balmer wrote:
> >> In a (private) Email to me, he indicated that had no time for a fix.
> >>
On Wed, Jan 2, 2019 at 6:36 AM Anthony Sottile wrote:
>
> Here's a simple regression test -- haven't had time to bisect this
I can't reproduce with either 2.20.0, 2.20.1 or 'master'. It would be
great if you could bisect this.
There are no suspicious commits from 2.27.1 touching
builtin/checkout
On Wed, Jan 2, 2019 at 3:09 AM Albert Burt wrote:
>
> Remove TODO that was left in from:
> commit 110240588d (Merge branch 'sb/object-store-alloc' - 2018-06-25)
>
> Todo can be removed as:
> 9d2c97016f (commit.h: delete 'util' field in struct commit - 2018-05-19)
> deletes commit->util.
>
> Signed
On Wed, Jan 2, 2019 at 11:18 PM Anthony Sottile wrote:
> heated a small room but here's the results of the bisect!
>
> fa655d8411cc2d7ffcf898e53a1493c737d7de68 is the first bad commit
> commit fa655d8411cc2d7ffcf898e53a1493c737d7de68
> Author: Ben Peart
> Date: Thu Aug 16 18:27:11 2018 +
>
On Sat, Jan 5, 2019 at 9:49 AM Farhan Khan wrote:
>
> Hi all,
>
> I'm having trouble understanding how OBJ_REF_DELTA and OBJ_REF_DELTA
> (deltas) work in git. Where does git calculate the sha1 hash values
> when doing "git index-pack" in builtin/index-pack.c. I think my lack
> of understanding of
On Sun, Jan 6, 2019 at 5:32 AM Farhan Khan wrote:
> Hi Duy,
>
> Thanks for explaining the Delta objects.
>
> What does a OBJ_REF_DELTA object itself consist of?
from pack-format.txt
(deltified representation)
n-byte type and length (3-bit type, (n-1)*7+4-bit length)
20-byte base o
On Sun, Jan 6, 2019 at 10:46 PM Christian Couder
wrote:
>
> It looks like it is a copy-paste error made in 80f2a6097c
> (t/helper: add test-ref-store to test ref-store functions,
> 2017-03-26) to pass "old-sha1" instead of "new-sha1" to
> notnull() when we get the new sha1 argument from
> const c
On Sat, Jan 5, 2019 at 9:34 PM Martin Ågren wrote:
>
> On Sat, 5 Jan 2019 at 07:07, Nguyễn Thái Ngọc Duy wrote:
> >
> > hold_locked_index() assumes the index path at $GIT_DIR/index. This is
> > not good for places that take an arbitrary index_state instead of
> > the_index, which is basically eve
On Tue, Jan 8, 2019 at 2:28 PM Anthony Sottile wrote:
>
> ```
> git --version
> rm -rf t
> git init t
> cd t
> touch a
> git add a
> git commit -m "add a"
> git rm a
> touch a
> git add --intent-to-add a
> git status --short
> git reset -- a
"git reset" without "-- a" does remove intent-to-add st
On Tue, Jan 8, 2019 at 4:44 PM Duy Nguyen wrote:
>
> On Tue, Jan 8, 2019 at 2:28 PM Anthony Sottile wrote:
> >
> > ```
> > git --version
> > rm -rf t
> > git init t
> > cd t
> > touch a
> > git add a
> > git commit -m "add a"
On Wed, Jan 9, 2019 at 5:56 AM Tomasz Śniatowski wrote:
>
> After upgrading to 2.20.1 I noticed in some submodule+worktree scenarios git
> will break the submodule configuration. Reproducible with:
> git init a && (cd a; touch a; git add a; git commit -ma)
> git init b && (cd b; git submod
On Wed, Jan 9, 2019 at 1:40 PM Tomasz Śniatowski wrote:
> > The good news is, I have something that should make it work reliably.
> > But I don't know if it will make it to 2.21 or not.
>
> That's good to hear, is there something I can try out or track?
You can try this
https://gitlab.com/pcloud
On Fri, Jan 11, 2019 at 3:07 AM Stefan Beller wrote:
>
> > I had a look at
> > https://gitlab.com/pclouds/git/commits/submodules-in-worktrees,
> > and it doesn't seem to be quite all okay.
> >
> > The submodule update step of the repro (that breaks the config on 2.20)
> > emits
> > an error mess
On Mon, Jan 14, 2019 at 4:02 AM Ramsay Jones
wrote:
>
>
> commit 8f7c7f ("config.c: add repo_config_set_worktree_gently()",
> 2018-12-27) adds three function declarations that cause the hdr-check
> make target to complain. The hdr-check complaint is caused by placing
> the new declarations, wh
On Mon, Jan 14, 2019 at 7:19 PM Ντέντος Σταύρος wrote:
>
> I have install the latest git version from the PPA:
> $ git --version
> git version 2.20.1
> $ lsb_release -rd
> Description: Ubuntu 16.04.5 LTS
> Release: 16.04
>
> Running
> `https://github.com/git/git/blob/master/contrib/completion/git
On Mon, Jan 14, 2019 at 9:51 PM Randall S. Becker
wrote:
>
> Hi All,
>
> I'm trying to track down what happened this morning. We had a commit that
> caused a background gc to occur. What happened was:
>
> $ git commit -m "history commit ... "
> Auto packing the repository in background for optimum
On Mon, Jan 14, 2019 at 10:03 PM Duy Nguyen wrote:
>
> On Mon, Jan 14, 2019 at 9:51 PM Randall S. Becker
> wrote:
> >
> > Hi All,
> >
> > I'm trying to track down what happened this morning. We had a commit that
> > caused a background gc to occur
On Tue, Jan 15, 2019 at 4:38 AM Jonathan Nieder wrote:
>
> Hi,
>
> Junio C Hamano wrote:
>
> > Patterns with slash is anchored at
> > one directory, and that directory is the one that has per-directory
> > .gitignore file. Patterns without slash (including a patte
On Wed, Jan 16, 2019 at 5:31 AM Junio C Hamano wrote:
> [Discarded]
>
> * nd/backup-log (2018-12-10) 24 commits
Discarding this series is not at all a problem. But should I be
worried about the silence on this one? Perhaps nobody is interested in
the idea and it's better to drop it?
--
Duy
On Wed, Jan 16, 2019 at 5:02 PM Kaustubh Shankar wrote:
>
> Hello everyone,
>
> I'm new to this mailing list and have also joined the IRC channel recently.
> I want to start contributing by possibly fixing small bugs or errors.
> I have gone through the suggested guidelines and documentation but i
On Thu, Jan 17, 2019 at 8:21 AM Ramsay Jones
wrote:
>
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Duy,
>
> If you need to re-roll your 'nd/the-index-final' branch, could you
> please squash this into the relevant patch (commit 4478671442,
> "cache.h: flip NO_THE_INDEX_COMPATIBILITY_MACROS switch
On Thu, Jan 17, 2019 at 5:06 AM Stefan Beller wrote:
> > clones from $GIT_COMMON_DIR/worktrees/X/modules to
> > $GIT_COMMON_DIR/common/modules.
>
> ... from the submodule side of things this is big problem,
> as the submodule is usually assumed at $GIT_DIR/modules/
> (I think we have not been stri
On Fri, Jan 18, 2019 at 3:10 AM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> the change itself looks good, but...
>
> On Thu, 17 Jan 2019, Nguyễn Thái Ngọc Duy wrote:
>
> > diff_opt_parse() is a heavy hammer to just set diff filter. But it's
> > the only way because of the diff_status_letters[] mapp
On Fri, Jan 18, 2019 at 9:28 AM Patrick Hogg wrote:
>
> ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
> 2018-04-14) added an extra usage of read_lock/read_unlock in the newly
> introduced oe_get_size_slow for thread safety in parallel calls to
> try_delta(). Unfortunately oe
nOn Fri, Jan 18, 2019 at 2:46 AM Stefan Beller wrote:
> > and we get a
> > looong 'git range-diff -h'
>
> This is an interesting tidbit to put into the commit message.
>
> range-diff is interesting in that in it is unclear where the options
> should take effect. My mental model of range-diff is
>
On Fri, Jan 18, 2019 at 8:04 PM Patrick Hogg wrote:
>
> On Fri, Jan 18, 2019 at 4:21 AM Duy Nguyen wrote:
>>
>> On Fri, Jan 18, 2019 at 9:28 AM Patrick Hogg wrote:
>> >
>> > ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
>
On Sat, Jan 19, 2019 at 10:45 PM Patrick Hogg wrote:
>
> ac77d0c37 ("pack-objects: shrink size field in struct object_entry",
> 2018-04-14) added an extra usage of read_lock/read_unlock in the newly
> introduced oe_get_size_slow for thread safety in parallel calls to
> try_delta(). Unfortunately o
On Sat, Jan 19, 2019 at 4:35 AM Jeff King wrote:
>
> On Fri, Jan 18, 2019 at 11:58:01AM -0500, Jeff King wrote:
>
> > Now, on to the actual bug. The simplest reproduction is:
> >
> > (echo "[attr]foo bar"; echo "* foo") >.gitattributes
> > git check-attr foo file
>
> Actually, even simpler is
On Sat, Jan 19, 2019 at 4:35 AM Jeff King wrote:
>
> On Fri, Jan 18, 2019 at 11:58:01AM -0500, Jeff King wrote:
>
> > Now, on to the actual bug. The simplest reproduction is:
> >
> > (echo "[attr]foo bar"; echo "* foo") >.gitattributes
> > git check-attr foo file
>
> Actually, even simpler is
On Tue, Jan 22, 2019 at 2:19 PM Jeff King wrote:
> Yes, that's the interesting part. I think I've convinced myself, too,
> that it doesn't do the _wrong_ thing ever. But I think it misses the
> point of the original, which is that you want common ones like "diff"
> not to trigger in_stack if nobod
On Tue, Jan 15, 2019 at 12:55 AM Matthieu Moy wrote:
>
> Hi,
>
> ...
>
> You may suggest ideas by editting the wiki page, or just by replying to
> this email (I'll point my students to the thread). Don't hesitate to
> remove entries (or ask me to do so) on the wiki page if you think they
> are not
On Tue, Jan 22, 2019 at 2:28 PM Jeff King wrote:
>
> On Mon, Jan 21, 2019 at 05:02:33PM +0700, Duy Nguyen wrote:
>
> > > As I mentioned in the prior thread I think that it will be simpler
> > > to simply use the existing lock in packing_data instead of moving
> &g
On Thu, Jan 24, 2019 at 8:06 AM Patrick Hogg wrote:
> diff --git a/pack-objects.h b/pack-objects.h
> index 0a038e3bc..dc869f26c 100644
> --- a/pack-objects.h
> +++ b/pack-objects.h
> @@ -146,7 +146,6 @@ struct packing_data {
> struct packed_git **in_pack;
>
> pthread_mutex_t lock;
ng
> it in prepare_packing_data which is initialized in cmd_pack_objects.
Obviously correct.
Reviewed-by: Duy Nguyen
>
> Signed-off-by: Patrick Hogg
> ---
> builtin/pack-objects.c | 7 ++-
> pack-objects.c | 1 +
> pack-objects.h | 10 ++
> 3
1001 - 1100 of 4016 matches
Mail list logo
