On Mon, Apr 1, 2019 at 5:47 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > diff --git a/Documentation/git-read-tree.txt
> > b/Documentation/git-read-tree.txt
> > index 5c70bc2878..12a25bc954 100644
> > --- a/Documentation/git-read-tree.txt
> > +++ b/Documentation/git-read-tree.
On Fri, Mar 29, 2019 at 11:32 PM Phillip Wood wrote:
>
> From: Phillip Wood
>
> When cherry-picking or reverting a sequence of commits and if the final
> pick/revert has conflicts and the user uses `git commit` to commit the
> conflict resolution and does not run `git cherry-pick --continue` then
On Mon, Apr 1, 2019 at 5:03 AM Andrei Rybak wrote:
>
> 'git am --scissors' allows cutting a patch from an email at a scissors
> line. Such a line should contain perforation, i.e. hyphens, and a
> scissors symbol. Only ASCII graphics scissors '8<' '>8' '%<' '>%' are
> recognized by 'git am --scis
sion
> from there:
Actually if you want to reach the git development community, this is the place.
> Am So., 31. März 2019 um 11:54 Uhr schrieb Duy Nguyen :
>>
>> On Sun, Mar 31, 2019 at 2:53 AM Dr. Adam Nielsen wrote:
>> >
>> > Hi everyone,
>>
On Sun, Mar 31, 2019 at 4:54 PM Duy Nguyen wrote:
> The "does not contain" is correct, but perhaps the wording is a bit
> too easy to misunderstand. If you go back to the original version of
> this document in cedb8d5d33 (Create a new manpage for the gitignore
> format, and
On Sun, Mar 31, 2019 at 2:53 AM Dr. Adam Nielsen wrote:
>
> Hi everyone,
>
> I think there is a typo in the gitignore docs.
>
> Its stated on https://git-scm.com/docs/gitignore that
>
> >If the pattern does not contain a slash /, Git treats it as a shell
> >glob pattern and checks for a match agai
On Thu, Feb 21, 2019 at 7:06 AM Duy Nguyen wrote:
> >
> > On Thu, Feb 21, 2019 at 1:07 AM Joe Enzminger
> > wrote:
> > >
> > > That is correct. What you suggest is actually what I tried (using
> > > sha-1 syntax). For my purposes, excluding th
On Fri, Mar 29, 2019 at 6:04 PM Phillip Wood wrote:
> > I am especially concerned with the idea of
> > having something like "git switch --ignore-in-progress
> > --discard-changes" being used to quit merges or cherry-picks or
> > reverts or even rebases. In my opinion, doing so is creating flags t
On Wed, Mar 27, 2019 at 5:24 PM Phillip Wood wrote:
>
> On 26/03/2019 15:48, Elijah Newren wrote:
> > On Tue, Mar 26, 2019 at 8:24 AM Duy Nguyen wrote:
> >> On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren wrote:
> >
> >> Yeah.. --ignore-in-proces
On Wed, Mar 27, 2019 at 3:26 PM Michael Platings wrote:
>
> > Another good place to keep these revs is git-notes,
> > which probably could result in faster lookups too and can be made
> > visible in git-log.
>
> Oh wow, I really like this. A major concern I had about the revisions
> file was that
On Wed, Mar 27, 2019 at 3:27 AM Michael Platings wrote:
> I think it's really important that we make this dead easy for everyone
> to use. The ultimate in ease of use would be for git blame to
> automatically pick up ignore settings without the user having to even
> know that it's happening. But t
On Tue, Mar 26, 2019 at 10:48 PM Elijah Newren wrote:
> > > > PS. git-reset shares the same behavior, but it's in a different boat,
> > > > I think. Or maybe I should scrap/replace that one as well.
> > >
> > > reset has traditionally been the home of
> > > how-to-clear-in-progress-state. e.g. ab
On Tue, Mar 26, 2019 at 10:18 PM Jeff King wrote:
>
> On Tue, Mar 26, 2019 at 05:14:11PM +0700, Duy Nguyen wrote:
>
> > > That seems like the best we can do without the protocol change. And even
> > > if we adjust the protocol, we need some fallback behavior for existin
On Tue, Mar 26, 2019 at 10:01 PM Elijah Newren wrote:
>
> On Tue, Mar 26, 2019 at 5:50 AM Duy Nguyen wrote:
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > wrote:
> > > On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > > > "git checkout&quo
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > "git checkout" doing too many things is a source of confusion for many
> > users (and it even bites old timers sometimes). To remedy that, the
> > command will be split into two new ones: swi
On Tue, Mar 26, 2019 at 12:20 PM Jeff King wrote:
>
> On Mon, Mar 25, 2019 at 01:43:23PM -0700, Jonathan Tan wrote:
>
> > In protocol v0, when sending "shallow" lines, the server distinguishes
> > between lines caused by the remote repo being shallow and lines caused
> > by client-specified depth
On Tue, Mar 26, 2019 at 1:29 PM Ævar Arnfjörð Bjarmason
wrote:
> I don't see how a new "abbreviatedOptions" is plausibly going to crowd
> out anything else, sounds pretty unambiguous to me.
By crowded I mean a lot of configuration variables under "core"
> By my count out of the the existing GIT_
On Tue, Mar 26, 2019 at 5:48 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Mon, Mar 25 2019, Eric Sunshine wrote:
>
> > On Mon, Mar 25, 2019 at 4:23 PM Ævar Arnfjörð Bjarmason
> > wrote:
> >> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
> >> @@ -1,3 +1,15 @@
> >> +core.
On Mon, Mar 25, 2019 at 5:41 PM SZEDER Gábor wrote:
>
> Some of the recently added progress indicators have quite long titles,
> which might be even longer when translated to some languages, and when
> they are shown while operating on bigger repositories, then the
> progress bar grows longer than
(Including Stefan, in case he's still interested in git and planned
something for the "submodule" restore part I mention below)
On Fri, Mar 08, 2019 at 10:01:25AM -0800, Elijah Newren wrote:
> Thanks for working on this; overall looks really good. I've got a few
> comments here and there on the w
On Sun, Mar 24, 2019 at 6:01 AM Klaatu wrote:
>
> Working with Git 2.21.0 on Linux:
>
> The git-add(1) man page says:
>
> "The optional configuration variable core.excludesFile indicates a path to a
> file containing patterns of file names to exclude from git-add"
>
> But if I do this:
>
> $ echo
On Fri, Mar 22, 2019 at 3:00 PM Andrei Rybak wrote:
>
> On 3/21/19 2:16 PM, Nguyễn Thái Ngọc Duy wrote:
> > ...
> >
> > diff --git a/advice.c b/advice.c
> > index b224825637..27e39e6514 100644
> > --- a/advice.c
> > +++ b/advice.c
> > @@ -191,20 +191,20 @@ void NORETURN die_conclude_merge(void)
>
On Fri, Mar 22, 2019 at 11:26 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > This adds a new command 'git-switch' as the half-replacement for
> > 'git-checkout'. Jump to 12/26 as the starting point. The other half is
> > git-restore, which is dealt with separately.
> >
> > The d
On Thu, Mar 21, 2019 at 5:37 PM Ævar Arnfjörð Bjarmason
wrote:
> diff --git a/commit-graph.c b/commit-graph.c
> index b2f64790aa..28b5b599ee 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -155,14 +155,8 @@ struct commit_graph *parse_commit_graph(void *graph_map,
> int fd,
>
> g
On Thu, Mar 21, 2019 at 1:03 AM Todd Zullinger wrote:
>
> Hi,
>
> Duy Nguyen wrote:
> > You probably want to drop the comment block about repository setup
> > inside list_cmds_by_config() too.
>
> You're right, of course. Thanks Duy. :)
>
> That's t
On Thu, Mar 21, 2019 at 12:49 PM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > I did something stupid today and got
> >
> > $ git commit -a --fixup= @^
> > fatal: Paths with -a does not make sense.
> >
> > which didn't make any sense (at least for the first few seconds).
>
On Thu, Mar 21, 2019 at 6:00 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, Mar 20 2019, Nguyễn Thái Ngọc Duy wrote:
>
> > [...]And the '40' change is self explanatory.
>
> Let me make an attempt at being dense anyway...
>
> > - else if (v > 40)
> > - v = 40;
> > +
On Wed, Mar 20, 2019 at 8:53 PM Elijah Newren wrote:
> So, I think we do need something (eventually at least). Would you
> prefer we dropped this patch from Duy and instead made 'checkout -m'
> abort when the index is dirty?
I have no problem with this. Still scratching my head wondering if
t720
On Tue, Mar 19, 2019 at 2:10 AM Elijah Newren wrote:
>
> On Sun, Mar 17, 2019 at 7:03 PM Junio C Hamano wrote:
> >
> > Elijah Newren writes:
> >
> > > I don't see why even makes sense to use with --orphan;
> > > you should error if both are given, IMO. The point of --orphan is to
> > > create
On Wed, Mar 20, 2019 at 7:41 AM Junio C Hamano wrote:
>
> Phillip Wood writes:
>
> > Thanks for doing this, one minor comment - I try to use
> > phillip.w...@dunelm.org.uk for git as it wont change if I change my
> > email provider.
>
> You mean something like this?
I think he meant fixing the R
On Wed, Mar 20, 2019 at 10:57 AM C.J. Jameson wrote:
> --m parent-number::
> ---mainline parent-number::
> +-m [parent-number]::
Careful with this. Optional argument with a short option means the
"stuck" form which is known to cause confusion [1].
Try "git revert -mX HEAD" and "git revert -m X H
On Wed, Mar 20, 2019 at 12:06 PM Jeff King wrote:
>
> On Tue, Mar 19, 2019 at 11:18:26PM +, Thomas Gummerer wrote:
>
> > From a quick search I couldn't find where 'git diff' actually parses
> > the '-v' argument, but I wonder if we should actually disallow it, in
> > case we want to use it for
On Wed, Mar 20, 2019 at 2:04 AM Phillip Wood wrote:
> It would perhaps be better to pass around the_index rather than
> the_repository
Not by a large margin. For sequencer.c most operations require more
than just the index and passing 'struct repository *' around has been
the norm. And as
On Wed, Mar 20, 2019 at 8:19 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> >> I think "checkout -m " with a dirty index should refuse
> >> to run; there is nothing to "continue" after such a failure, so I am
> >> not sure what you m
On Wed, Mar 20, 2019 at 7:24 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > If you have staged changes in path A and perform 'checkout
> > --merge' (which could result in conflicts in a totally unrelated path
> > B), changes in A will be gone. Which is unexpected. We are suppose
On Mon, Mar 18, 2019 at 11:15 PM Ævar Arnfjörð Bjarmason
wrote:
>
> 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 wor
On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
wrote:
>
> Hi everyone,
>
> There are now ideas, micro-projects and organization application pages
> for GSoC 2019 on https://git.github.io/
>
> It would be nice to have a few more project ideas.
> https://git.github.io/SoC-2019-Ideas/ currently list
On Mon, Mar 18, 2019 at 11:54 AM Junio C Hamano wrote:
> I often find "git reset --hard " after a
It still bugs me that I need to use this to abort some in-progress
operation. There's "git X --abort" but I would need to find out what X
is first. I would like "git abort" or something (and "git con
On Mon, Mar 18, 2019 at 9:03 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > I don't see why even makes sense to use with --orphan;
> > you should error if both are given, IMO. The point of --orphan is to
> > create some entirely new history. So, I'd expect "git switch --orphan
> > "
On Mon, Mar 18, 2019 at 1:16 AM Todd Zullinger wrote:
>
> From: Jeff King
>
> Normally code that is checking config before we've decided to do
> setup_git_directory() would use read_early_config(), which uses
> discover_git_directory() to tentatively see if we're in a repo,
> and if so to add it
On Mon, Mar 18, 2019 at 10:58 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > One-way merge is supposed to take stat info from the index and
> > everything else from the given tree. This implies stage 0 because trees
> > can't have non-zero stages. The add_entry(.., old, ...) cal
On Sun, Mar 17, 2019 at 8:41 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Sun, Mar 17 2019, Denton Liu wrote:
>
> > The documentation used to consider
> >
> > git diff
> >
> > and
> >
> > git diff ..
> >
> > to be equal counterparts. However, rev-list-ish commands also use the
> > .. n
On Sun, Mar 17, 2019 at 6:09 PM Denton Liu wrote:
>
> The documentation used to consider
>
> git diff
>
> and
>
> git diff ..
>
> to be equal counterparts. However, rev-list-ish commands also use the
> .. notation, but in a logically conflicting manner which
> was confusing for s
Poking this thread before it goes completely dead...
On Sat, Mar 2, 2019 at 12:34 AM Todd Zullinger wrote:
>
> The completion.commands config var must be set in either the system-wide
> or global config file. The completion script does not read a local
> repository config.
After the last discus
On Sun, Mar 17, 2019 at 7:49 PM Nguyễn Thái Ngọc Duy wrote:
>
> Thanks for all the comments from v3 (and before), I didn't expect
> feedback from so many people. v4 fixes most of them, but still leaves
> a couple for v5.
>
> - -C remains because people seem to need it
>
> - --recreate vs --force-c
On Thu, Mar 14, 2019 at 1:36 AM Eckhard Maaß
wrote:
> And while at it - what should happen, if:
>
> - there is a tag named example
> - no local branch example
> - a branch at origin/example
>
> ... and we switch then? Right now it just gives "cannot find branch",
> should there be more information
On Fri, Mar 15, 2019 at 9:31 PM Robert P. J. Day wrote:
> also, i think "man git-clone" could really use a set of examples for
> shallow cloning. i'd offer to write it but i'm still figuring it out.
Cool. I'll give you a quick introduction to help with those examples :D
Side note: there's also
On Fri, Mar 15, 2019 at 8:19 PM Robert P. J. Day wrote:
> this is the first time i've played with this feature, so i'm still
> working my way through the man page, trying to figure out the various
> valid combinations for shallow cloning.
>
> i notice that the SYNOPSIS for "man git-clone" does
On Fri, Mar 15, 2019 at 7:17 PM Robert P. J. Day wrote:
>
>
> probably doing something idiotic but i'm enumerating variations of
> shallow cloning, and tried the following:
>
> $ git clone --shallow-exclude=master https://github.com/django/django.git
> Cloning into 'django'...
> fatal: the remot
On Thu, Mar 14, 2019 at 7:35 PM Ævar Arnfjörð Bjarmason
wrote:
>
> During reflog expiry, the cmd_reflog_expire() function first iterates
> over all reflogs in logs/*, and then one-by-one acquires the lock for
> each one to expire its reflog by getting a *.lock file on the
> corresponding loose ref
On Fri, Mar 15, 2019 at 5:24 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Mar 15 2019, Duy Nguyen wrote:
>
> > On Thu, Mar 14, 2019 at 7:35 PM Ævar Arnfjörð Bjarmason
> > wrote:
> >> @@ -127,6 +140,10 @@ static void gc_config(void)
> >>
On Thu, Mar 14, 2019 at 7:35 PM Ævar Arnfjörð Bjarmason
wrote:
> @@ -127,6 +140,10 @@ static void gc_config(void)
> pack_refs = git_config_bool("gc.packrefs", value);
> }
>
> + if (gc_config_is_timestamp_never("gc.reflogexpire") &&
> + gc_config_is_t
On Thu, Mar 14, 2019 at 7:35 PM Ævar Arnfjörð Bjarmason
wrote:
>
> When gc.reflogExpire and gc.reflogExpireUnreachable are set to "never"
> and --stale-fix isn't in effect (covered by the first part of the "if"
> statement being modified here) we can exit early without pointlessly
> looping over a
On Thu, Mar 14, 2019 at 7:34 PM Ævar Arnfjörð Bjarmason
wrote:
>
> There's been a lot of changing of the hardcoded "40" values to
> the_hash_algo->hexsz, but we've so far missed this one where we
> hardcoded 38 for the loose object file length.
Wow. Good catch.
> diff --git a/builtin/gc.c b/buil
On Fri, Mar 15, 2019 at 3:19 PM Eric Sunshine wrote:
>
> On Wed, Mar 13, 2019 at 2:36 PM Eckhard Maaß
> wrote:
> > On Fri, Mar 08, 2019 at 04:57:48PM +0700, Nguyễn Thái Ngọc Duy wrote:
> > > Similar to automatic detach, this behavior could be confusing because
> > > it can sometimes create a new
On Thu, Mar 14, 2019 at 7:06 PM Johannes Schindelin
wrote:
> If this is truly something we ("we" as in "engaged Git developers") want,
> I can set aside some time to work on that. I had originally planned on
> exactly that, i.e. supporting PRs on git/git, but I got rather strong
> indications that
On Thu, Mar 14, 2019 at 9:10 PM Johannes Schindelin
wrote:
> In any case, before we get better tooling to work around these issues, I
> still think it makes a ton of sense to encourage proper separation of
> concerns: to keep patches that introduce regression tests demonstrating a
> breakage separ
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
> > +-f::
> > +--force::
> > + Proceed even if the index or the working tree differs from
> > + HEAD. Both the index and working tree are restored to match
> > + the switching target. This is used to throw away local
> > + changes
On Thu, Mar 14, 2019 at 6:02 PM Phillip Wood wrote:
>
> On 14/03/2019 09:17, Duy Nguyen wrote:
> > On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote:
> >>>> Again, not much of a datapoint, but I do use --orphan periodically.
> >>>> The idea
On Tue, Mar 12, 2019 at 01:28:35PM -0400, Eric Sunshine wrote:
> > > Again, not much of a datapoint, but I do use --orphan periodically.
> > > The idea of "fixing" the behavior so that --orphan starts with a clean
> > > slate is certainly appealing (since it matches how I've used orphan
> > > branc
On Thu, Mar 14, 2019 at 5:17 AM Johannes Schindelin
wrote:
>
> Hi Duy,
>
> On Wed, 13 Mar 2019, Duy Nguyen wrote:
>
> > On Wed, Mar 13, 2019 at 4:13 PM Johannes Schindelin
> > wrote:
> > > Duy, have you thought about making use of the CI builds? You could ca
On Thu, Mar 14, 2019 at 5:58 AM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > On Fri, Mar 8, 2019 at 5:17 PM Nguyễn Thái Ngọc Duy
> > wrote:
> >> - --index has a different meaning in git-apply. I don't have a good
> >> suggestion except &qu
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
> > +-m::
> > +--merge::
> > + If you have local modifications to one or more files that are
> > + different between the current branch and the branch to which
> > + you are switching, the command refuses to switch branches in
> > +
On Tue, Mar 12, 2019 at 12:54 AM Elijah Newren wrote:
> > +--progress::
> > +--no-progress::
> > + Progress status is reported on the standard error stream
> > + by default when it is attached to a terminal, unless `--quiet`
> > + is specified. This flag enables progress reportin
On Sun, Mar 10, 2019 at 1:52 AM Elijah Newren wrote:
> > + /*
> > +* NEEDSWORK: if --worktree is not specified, we
> > +* should save stat info of checked out files in the
> > +* index to avoid the next (potentially costly)
> > +
On Wed, Mar 13, 2019 at 4:13 PM Johannes Schindelin
wrote:
> Duy, have you thought about making use of the CI builds? You could catch
> those bugs before they hit the Git mailing list...
Using Azure? No.
--
Duy
On Wed, Mar 13, 2019 at 12:26 AM Andreas Schwab wrote:
>
> On Mär 12 2019, Junio C Hamano wrote:
>
> > I however think it may be worth making sure that our docs do not
> > encourage "diff A..B" and teach "diff A B" when comparing two
> > endpoints. That can be done without changing anything in t
On Wed, Mar 13, 2019 at 6:30 AM Thomas Gummerer wrote:
>
> Add a definition for what overlay means in the context of git, to
> clarify the recently introduced overlay-mode in git checkout.
>
> Helped-by: Elijah Newren
> Signed-off-by: Thomas Gummerer
> ---
>
> v2 addresses Elijah's comments (tha
On Tue, Mar 12, 2019 at 3:51 AM Phillip Wood wrote:
> > then it'd make sense to use --recreate instead. But if you
> > think some might adopt a workflow where they just use -C without first
> > trying -c ("create this branch, and I don't care if I made it before
> > just create it here"), then --
On Tue, Mar 12, 2019 at 12:25 AM Elijah Newren wrote:
>
> On Mon, Mar 11, 2019 at 4:47 AM Duy Nguyen wrote:
> >
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > wrote:
> > >
> > > Hi Duy
> > >
> > > On 08/03/2019 09:57, Nguyễ
On Tue, Mar 12, 2019 at 12:03 AM Phillip Wood wrote:
>
> Hi Duy
>
> On 11/03/2019 11:47, Duy Nguyen wrote:
> > On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood
> > wrote:
> >>
> >>
> >> Hi Duy
> >>
> >> On 08/03/2019 09:57, Nguyễn
On Tue, Mar 12, 2019 at 5:18 AM Sergio Durigan Junior
wrote:
> This works without problems most of the time (well, usually there are
> conflicts and all, but that's a burden I have to carry). However,
> sometimes I notice that git fails with:
>
> # git rebase origin/master
> ...
> Applying:
On Tue, Mar 12, 2019 at 5:02 PM Duy Nguyen wrote:
> We have to analyze case by case. It may turn out that there are many
s/are/aren't/
> opportunity to utilize multi threads. I think checkout is definitely a
> good candidate. For "git diff" and "git log" may
On Mon, Mar 11, 2019 at 09:18:47PM -0300, Matheus Tavares Bernardino wrote:
> I've been thinking on how I could implement a test to estimate the
> lock contention but had no success until now. I wanted to try
> mutrace[2] but couldn't install it; I tried valgrind's drd but it
> didn't seem to repor
On Mon, Mar 11, 2019 at 10:22 PM Duy Nguyen wrote:
>
> On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren wrote:
> >
> > On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy
> > wrote:
> > >
> > > Completion for restore is straightforward. We could still
On Sun, Mar 10, 2019 at 2:17 AM Elijah Newren wrote:
>
> On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
> >
> > Completion for restore is straightforward. We could still do better
> > though by give the list of just tracked files instead of all present
> > ones. But let's leave it for
On Mon, Mar 11, 2019 at 9:12 PM Randall S. Becker
wrote:
>
> > -Original Message-
> > From: git-ow...@vger.kernel.org On Behalf
> > Of Elijah Newren
> > Sent: March 9, 2019 14:38
> > To: Nguyễn Thái Ngọc Duy
> > Cc: Git Mailing List ; Junio C Hamano
> >
> > Subject: Re: [PATCH v1 11/11]
On Mon, Mar 11, 2019 at 2:32 AM Eckhard Maaß
wrote:
>
> On Thu, Nov 29, 2018 at 10:58:46PM +0100, Nguyễn Thái Ngọc Duy wrote:
> > + if (!opts->implicit_detach &&
> > + !opts->new_branch &&
> > + !opts->new_branch_force &&
> > + new_branch_info->name &&
> > + !ne
On Mon, Mar 11, 2019 at 10:48 AM Jeff King wrote:
> And AFAIK there is no good way to
> modify the submodule-provided content as part of the build. Why do we
> even have the submodule again? ;P
Because of dogfooding of course. This is an interesting use case
though. I wonder if people often want
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood wrote:
>
>
> Hi Duy
>
> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> > "git checkout" doing too many things is a source of confusion for many
> > users (and it even bites old timers sometimes). To remedy that, the
> > command will be split into tw
On Sat, Mar 9, 2019 at 7:35 PM Martin Ågren wrote:
> @@ -285,7 +285,7 @@ Note that this option uses the no overlay mode by default
> (see also
The part not shown here is
Using `--recurse-submodules` will update the content of all initialized
submodules according to the commit recorded i
On Mon, Mar 11, 2019 at 1:36 PM Junio C Hamano wrote:
> while (...)
> ; /* try again ... */
>
> This "strip all .lock repeatedly" made me stop and think a bit; this
> will never make the component empty, as the only way for this loop
> to make it empty is if
On Mon, Mar 11, 2019 at 1:20 PM Junio C Hamano wrote:
>
> Eric Sunshine writes:
>
> >> case 2:
> >> + if (last == '.') { /* Refname contains "..". */
> >> + if (sanitized)
> >> + sanitized->l
On Fri, Mar 8, 2019 at 5:17 PM Nguyễn Thái Ngọc Duy wrote:
> - --index has a different meaning in git-apply. I don't have a good
> suggestion except "yeah we have two different worlds now, the old
> and the new one"
I will rename --index to --staged to avoid this. It is already used as
synony
On Sat, Mar 9, 2019 at 5:50 PM Kevin Daudt wrote:
> I know this has come up on the git mailing list more often, but I cannot
> find a relevant thread at this moment.
The last discussion is probably this one
https://public-inbox.org/git/87wolzo7a1@evledraar.gmail.com/
--
Duy
On Sat, Mar 9, 2019 at 1:01 AM Elijah Newren wrote:
>
> Thanks for working on this; overall looks really good. I've got a few
> comments here and there on the wording and combinations of options...
>
> On Fri, Mar 8, 2019 at 2:17 AM Nguyễn Thái Ngọc Duy wrote:
> > +SYNOPSIS
>
> It might be worth
On Sat, Mar 9, 2019 at 12:49 AM Ramsay Jones
wrote:
>
>
>
> On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
> [snip]
> > Range-diff dựa trên v2:
> > -: -- > 1: 949f3dd4fd git-checkout.txt: spell out --no-option
> > 1: 8358b9ca36 = 2: 1ddbbae3e2 git-checkout.txt: fix one syntax lin
Junio, it seems 2/2 is stuck in an endless discussion. But 1/2 is good
regardless, maybe pick it up now and let 2/2 come later whenever it's
ready?
On Wed, Feb 20, 2019 at 11:16 PM Michal Suchanek wrote:
>
> Git runs a stat loop to find a worktree name that's available and then does
> mkdir on th
On Thu, Mar 7, 2019 at 9:45 PM Phillip Wood wrote:
> > [1] note that ref listing still works sometimes. For example, if you
> > have .git/worktrees/foo/refs/rewritten/bar AND the directory
> > .git/worktrees/refs/rewritten,
>
> should that be .git/refs/rewritten? (and below)
Yes.
--
Du
On Thu, Mar 7, 2019 at 7:34 PM Philip Oakley wrote:
>
> On 06/03/2019 09:44, Duy Nguyen wrote:
> > On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano wrote:
> >> * tg/checkout-no-overlay (2019-02-04) 9 commits
> >>(merged to 'next' on 2019-02-04 at 9968bcf4
On Thu, Mar 7, 2019 at 4:46 PM Duy Nguyen wrote:
>
> On Thu, Mar 7, 2019 at 4:38 PM Phillip Wood wrote:
> >
> > On 06/03/2019 15:57, Phillip Wood wrote:
> > > When it is run in a worktree 'git for-each-ref' only seems to show refs
> > > under refs
On Thu, Mar 7, 2019 at 4:38 PM Phillip Wood wrote:
>
> On 06/03/2019 15:57, Phillip Wood wrote:
> > When it is run in a worktree 'git for-each-ref' only seems to show refs
> > under refs/rewritten if that directory also exists under $GIT_COMMON_DIR
> > even though they are local to the worktree.
>
On Thu, Mar 7, 2019 at 6:21 AM Junio C Hamano wrote:
> The change to this main function looks quite straight-forward. I am
> kind of surprised that a very low hanging fruit like this had survived
> without getting hit by parseopt a lot earlier ;-)
There are more (I guess we tag #leftovers nowada
bove we can guesstimate how much gain there is. If threads in
git-grep for example often have to wait for grep_mutex, then in the
best case scenario when you make pack access thread safe, lock
contention goes down to near zero.
> On Tue, Mar 5, 2019 at 9:57 AM Duy Nguyen wrote:
> >
&g
On Wed, Mar 6, 2019 at 8:34 AM Junio C Hamano wrote:
> * tg/checkout-no-overlay (2019-02-04) 9 commits
> (merged to 'next' on 2019-02-04 at 9968bcf4fb)
> + revert "checkout: introduce checkout.overlayMode config"
> (merged to 'next' on 2019-01-18 at 1e2a79ba5c)
> + checkout: introduce checko
On Wed, Mar 6, 2019 at 11:49 AM Jeff King wrote:
>
> On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote:
>
> > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
> > wrote:
> > >
> > > Hi everyone,
> > >
> > > There are now ideas, mi
On Tue, Mar 5, 2019 at 10:42 PM Eric Sunshine wrote:
>
> On Tue, Mar 5, 2019 at 7:32 AM Nguyễn Thái Ngọc Duy wrote:
> > diff --git a/diff.c b/diff.c
> > @@ -5299,6 +5299,8 @@ static void prep_parse_options(struct diff_options
> > *options)
> > + OPT_BOOL(0, "quiet", &options->flags
On Tue, Mar 5, 2019 at 11:51 AM Jeff King wrote:
> > processing power from multiple cores, but about _not_ blocking. I
> > think one example use case here is parallel checkout. While one thread
> > is blocked by pack access code for whatever reason, the others can
> > still continue doing other st
On Tue, Mar 5, 2019 at 7:04 PM Duy Nguyen wrote:
> Not sure if it's too late now. Anyway this could be something fun to
> do: support C-based tests in our test suite.
>
> ...
>
> I'm pretty sure I had some fun with this idea and made some prototype
> but I couldn&#x
On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
wrote:
>
> Hi everyone,
>
> There are now ideas, micro-projects and organization application pages
> for GSoC 2019 on https://git.github.io/
>
> It would be nice to have a few more project ideas.
Not sure if it's too late now. Anyway this could be s
201 - 300 of 4016 matches
Mail list logo
