>Corentin BOMPARD writes:
>
>> Add the --set-upstream option to git pull/fetch
>> which lets the user set the upstream configuration
>> for the current branch.
>
> I think it is a good idea to mention what you exactly mean by "the
> upstream configuration" here.
>
> Do you mean the "branch..merg
When "git branch -D " is run, Git usually first checks if that
branch is currently checked out. But this check is not performed if the
Git directory of that repository is not at "/.git", which is the
case if that repository is a submodule that has its Git directory stored
as "super/.git/modules/",
"Junio C Hamano via vger.kernel.org" writes:
> > 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
> > the sequencer state is
On Fri, Apr 19, 2019 at 4:24 AM Jeff King wrote:
>
> On Thu, Apr 18, 2019 at 05:14:08PM -0400, Jeff King wrote:
>
> > Just so we don't forget about it, I wrote this fix up as a patch. And in
> > fact it led to a few other cleanups. I think the first one is definitely
> > worth doing now, even if t
"CHIGOT, CLEMENT" writes:
> Declare FILENO_IS_A_MACRO on AIX
>
> On AIX, fileno(fp) is a macro and need to use the work around already made
> for BSD's.
>
> Signed-off-by: Clément Chigot
> ---
> config.mak.uname | 1 +
> 1 file changed, 1 insertion(+)
I do not have an AIX box, so I'll take t
Jeff King writes:
> When we parse an on-disk untracked cache, we have two pointers, "data"
> and "next". As we parse, we point "next" to the end of an element, and
> then later update "data" to match.
>
> But we actually don't need two pointers. Each parsing step can just
> update "data" directly
Add the --set-upstream option to git pull/fetch
which lets the user set the upstream configuration
(branch..merge and
branch..remote) for the current branch.
For example a typical use-case like
git clone http://example.com/my-public-fork
git remote add main http://example.com/project-mai
This tutorial covers how to add a new command to Git and, in the
process, everything from cloning git/git to getting reviewed on the
mailing list. It's meant for new contributors to go through
interactively, learning the techniques generally used by the git/git
development community.
Signed-off-by
Vadym Kochan writes:
>> Some libc implementations have function called gettext() that
>> can be linked via -lc without -lintl, but these are mere stubs
>> and do not do useful i18n. On these systems, if a program that
>> calls gettext() is built _with_ "#include ", the
>> lin
Hi Junio,
On Fri, Apr 19, 2019 at 01:56:48PM +0900, Junio C Hamano wrote:
> Vadym Kochan writes:
>
> >> Some libc implementations have function called gettext() that
> >> can be linked via -lc without -lintl, but these are mere stubs
> >> and do not do useful i18n. On these systems,
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> -u::
>> --set-upstream::
>> For every branch that is up to date or successfully pushed, add
>> upstream (tracking) reference, used by argument-less
>> linkgit:git-pull[1] and other commands. For more information,
>> see `bran
Matthieu Moy writes:
> -u::
> --set-upstream::
> For every branch that is up to date or successfully pushed, add
> upstream (tracking) reference, used by argument-less
> linkgit:git-pull[1] and other commands. For more information,
> see `branch..merge` in linkgit:git-conf
Hi Junio,
On Mon, Apr 15, 2019 at 03:29:24PM -0700, Denton Liu wrote:
> Before, when we had the following graph,
>
> A---B---C (master)
> \
>D (side)
>
> running 'git rebase --onto master... master side' would result in D
> being always rebased, no matter what. Howeve
Hello,
Giuseppe Crinò writes:
> On Thu, Apr 18, 2019 at 7:32 PM Jakub Narebski wrote:
>> Well, what about limiting changes and rewriting only to the commits
>> being rewritten by [interactive] rebase? I mean that we would rewrite
>> "revert 01a9fe8" only if:
>>
>> a.) the commit with this mess
Phillip Wood writes:
> From: Phillip Wood
>
> commit b3a5d5a80c ("trace2:data: add subverb for rebase", 2019-02-22)
> mistakenly marked the subverb names for translation and unnecessarily
> NULL terminated the array.
>
> Signed-off-by: Phillip Wood
> ---
> builtin/rebase.c | 15 +++
We're working on Windows machines and have been experiencing issues with the
current implementation of Git with config setting "core.ignorecase = true"
(which is the default on Windows machines and repositories created on Windows
machines):
Renaming files in a repository by only changing thei
Vadim Kochan writes:
>> I think
>>
>> autoconf: #include when checking for gettext()
>>
>> is probably a better title.
>>
>> Together with your originally proposed log message, which we now
>> know explains why this inclusion makes a difference sufficiently to
>> be understandable by a
On Fri, Apr 19, 2019 at 04:18:25PM +0700, Duy Nguyen wrote:
> > I also wondered if we could just accept the cost of calloc() here and
> > use FLEX_ALLOC to simplify things. That resulted in the patch below, but
> > I didn't include it with the initial 3, because I think it's too
> > subtle/gross f
On Fri, Apr 19, 2019 at 10:57:33AM -0700, Phil Hord wrote:
> "Junio C Hamano via vger.kernel.org" writes:
>
> > > 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
Duy Nguyen writes:
> So an alternative is simply outsource the ambiguity decision back to
> git-clone. If the same situation appears again elsewhere, we'll need
> to sit back and fix it for real. But this way we don't potentially
> introduce any new traps.
Sounds like a sensibly safe approach.
git-reset could be used in three different ways:
- move HEAD to somewhere, optionally (not) update worktree/index
- "move" HEAD to HEAD, mainly to update worktree/index
- just update the index from some tree-ish
The second case is frankly a (neat) corner case of the first one. But it
makes it imp
Jeff King writes:
> - len = strlen((const char *)data);
> - next = data + len + 1;
> - if (next > rd->end)
> + eos = memchr(data, '\0', end - data);
> + if (!eos || eos == end)
> return -1;
> + len = eos - data;
> + next = eos + 1;
Yup, much nicer.
> -
On Fri, Apr 19, 2019 at 1:30 AM Jonathan Tan wrote:
>
> > You actually didn't spell out the problem with "git branch -D", or at
> > least the consequence (i.e. the submodule branch is deleted even if
> > it's checked out).
>
> Thanks - I'll do that in the commit message.
Another minor nit (becaus
On 2019.04.13 01:34, Jeff King wrote:
> On Fri, Apr 12, 2019 at 03:38:47PM -0700, Josh Steadmon wrote:
>
> > > > Thank you for catching this. I haven't yet figured out the cause. I will
> > > > look into this more tomorrow and then send a V4 once I've fixed it.
> > >
> > > I'm concerned that this
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> When building with certain build options, some commands are excluded
> from the build. For example, `git-credential-cache` is skipped when
> building with `NO_UNIX_SOCKETS`.
>
> Let's not build or package documentatio
For partial clones, doing a full connectivity check is wasteful; we skip
promisor objects (which, for a partial clone, is all known objects), and
enumerating them all to exclude them from the connectivity check can
take a significant amount of time on large repos.
At most, we want to make sure tha
We have a serious performance problem with one of our large repos. The repo is
our internal version of the android platform/manifest project. Our repo after
running a clean "repack -A -d -F" is close to 8G in size, has over 700K refs,
and it has over 8M objects. The repo takes around 40min to cl
This is to report a bug in the docs, or at least suggest an improvement.
The update-ref documentation says that --create-reflog can only be
passed when providing a new ref to create and doesn't say it can also
be used with --stdin:
'git update-ref' [-m ] [--no-deref] (-d [] |
[--create-reflog]
On 4/18/2019 4:08 PM, Jeff King wrote:
> On Thu, Apr 18, 2019 at 03:49:53PM -0400, Jeff King wrote:
>> I dunno. I guess it does not hurt to at least to at least make sure this
>> code is running in the normal suite. I don't think that will find the
>> more interesting regressions, but at least save
On Fri, Apr 19, 2019 at 09:01:50PM -0400, Derrick Stolee wrote:
> > +test_expect_success 'trivial prune with bitmaps enabled' '
> > + git repack -adb &&
> > + blob=$(echo bitmap-unreachable-blob | git hash-object -w --stdin) &&
> > + git prune --expire=now &&
> > + git cat-file -e HEAD &&
On Fri, Apr 19, 2019 at 03:47:22PM -0600, Martin Fick wrote:
> I have been thinking about this problem, and I suspect that this compute time
> is actually spent doing SHA1 calculations, is that possible? Some basic back
> of the envelope math and scripting seems to show that the repo may actuall
Ah, yes. Thanks for the reminder, Peff. Found my original patch:
http://git.661346.n2.nabble.com/PATCHv2-git-status-show-short-sequencer-state-tc7569767.html#a7570756
I seem to recall that my next iteration of it ran into many conflicts
in wt_status.c, and that file seemed like it might be head
32 matches
Mail list logo
