's inside git (the source code) is not actually
code that can be built but metadata describing the configuration of a product
that's used to deploy the parameters.
Thanks for reading this request.
Kevin GOSSENT
This message contains information that may be privileged or confidential and
On Fri, Aug 23, 2019 at 10:43:45PM +0200, Albert Vaca Cintora wrote:
> Hi git folks,
>
> Honestly I'm not aware of the reason behind .git being read-only, but
> I'm sure there is one.
>
> However, I'm sure that a large percentage of developers out there will
> agree with me that having to use for
On Thu, Jul 11, 2019 at 03:11:33PM -0500, Robert Morgan wrote:
> subscribe git
You need to send this to majord...@vger.kernel.org. Sending it to the
git mailing list will not do a lot.
Kevin
o stderr is more treated like an additional output stream rather than
only reporting errors to stderr.
Hope this helps, Kevin
>
> --
> Thomas Hruska
> CubicleSoft President
>
> http://cubiclesoft.com/
>
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> [submodule "src/libgp"]
> url = http://github.com/grumpy-irc/libgp
> [submodule "src/libirc"]
> url = http://github.com/grumpy-irc/libirc
> [branch "remote_scripts"]
> remote = origin
> merge = refs/heads/remote_scripts
>
Hello Petr,
What does git config --show-origin remoe.origin.url return?
Kind regards, Kevin
On Tue, Mar 12, 2019 at 01:22:51PM -0400, Robert P. J. Day wrote:
>
> never noticed this before ... when i do a regular "git commit" and
> enter my "vi" edit session and change my mind, i can bail with ":q!",
> regardless of what i've set up as a commit message, and i'll see:
>
> Aborting com
undo the last operation. In my opinion this is
a better way to go then to add confirmations everywhere.
I know this has come up on the git mailing list more often, but I cannot
find a relevant thread at this moment.
Kevin
On Mon, Feb 11, 2019 at 01:26:39AM +, brian m. carlson wrote:
> When serializing UTF-16 (and UTF-32), there are three possible ways to
> write the stream. One can write the data with a BOM in either big-endian
> or little-endian format, or one can write the data without a BOM in
> big-endian fo
#x27;, resulting in an
invalid BOM.
Fix this by using the proper value of 0xff: '\377'.
Signed-off-by: Kevin Daudt
---
I do wonder why this code is using octal values in the first place,
rather than using hex values.
t/t0028-working-tree-encoding.sh | 8
1 file changed, 4 i
On Fri, Feb 08, 2019 at 08:42:19PM +, brian m. carlson wrote:
> On Fri, Feb 08, 2019 at 09:23:36PM +0100, Kevin Daudt wrote:
> > Firstly, the tests expect iconv -t UTF-16 to output a BOM, which it
> > indeed does not do on Alpine. Secondly, git itself also expects the BOM
&g
On Fri, Feb 08, 2019 at 09:50:07AM -0800, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> >> So would you suggest that we just skip this test on Alpine Linux?
> >
> > That's not exactly what I said. If Alpine Linux users are never going to
> > use this functionality and don't care that it'
On Fri, Feb 08, 2019 at 11:45:02AM +, brian m. carlson wrote:
> On Fri, Feb 08, 2019 at 01:04:03AM -0500, Rich Felker wrote:
> [..]
> > In any case, this test seems mainly relevant to Windows users wanting
> > to store source files in UTF-16LE with BOM. This doesn't really make
> > sense to do
, all the other tests fail as well
as they expect the file to be present in the repository.
Any idea how to get around this?
Kevin
ady exists."
>
> Once the branch is created, you can't force its creation, because it is
> already created. Just
>
> git checkout "branch_name"
>
> is sufficient at this point. git is correct to complain that you are trying
> to create a branch that already exists.
git checkout -B exists, which does exactly that: force create a branch
at a new positon if it already exists.
Kind regards, Kevin
ject.
You can find details on how to provide translations here[0]. It looks
from that document that someone started translating the book in Turkish
as well[1].
Kind regards, Kevin
[0]:https://github.com/progit/progit2/blob/master/TRANSLATING.md
[1]:https://github.com/progit/progit2-tr
On Fri, Jan 18, 2019 at 10:40:55PM +, Eric Wong wrote:
> Steve Keller wrote:
> > $ git reflog expire --all
>
> I've never used "git reflog" directly, but I think you need to
> add "--expire=all" to cover all time. "--all" is only for all
> branches, so you need "--expire=" is for a time
ing trivial? is the explanation misleading or inncomplete?
>
> rday
>
> --
>
After selecting 'p', what do you get?
You should see a list of modified files. You can select the files you
want to stage by the listed numbers. After you selected those files, you
press enter, and then you will get the options you'll also see with git
add -p.
Kevin
ield is not the number of extensions, but the number
of index entries.
I'm not sure why you are seeing so many index entries. I've just tested
it myself on the git repository and I got 3419 entries when reading in
network (big-endian) order.
Hope this helps a bit.
Kevin
usr/local/ -name '*mailsplit*'
> /usr/local/share/doc/git-doc/git-mailsplit.txt
> /usr/local/share/doc/git-doc/git-mailsplit.html
> /usr/local/share/man/man1/git-mailsplit.1
> /usr/local/libexec/git-core/git-mailsplit
This is the mailsplit command, and should be executed when running `git
mailsplit`. What does git --exec-dir return?
Kevin
les of the cloned repository to the parent repo, and
basically ignore that it's another repository.
And I guess no one complained because it looked like a feature rather
than a bug.
Kevin
On Mon, Jun 18, 2018 at 01:19:19PM +0200, Heiko Voigt wrote:
Now with cc to the mailing list.
> Hi,
>
> I just discovered that when you have a slash at the end of a nested
> repository, the files contained in the repository get added instead of
> the gitlink.
>
> I found this when I was adding
ite short
window of investigation a long time ago, and I've not looked at it
since. Would like input from someone with more active knowledge.
Kevin
he initial scan when all
parents are relevant and we matched one, the commit became TREESAME as
per the new definition immediately because of the rewrite. This applies
the equivalent rewrite when no relevant parents, consistent with the
general concept, and without changing the TREESAME definition.
Kevin
without naming them
- so name a child of one.
And then we need to think about whether we want it displayed in each of
the other modes for each of those queries...
Kevin
On 24/05/2018 23:26, Kevin Bracey wrote:
On Wed, May 23, 2018 at 07:10:58PM +0200, SZEDER Gábor wrote:
$ git log --oneline master..ba95710a3b -- ci/
ea44c0a594 Merge branch 'bw/protocol-v2' into
jt/partial-clone-proto-v2
In this case, we're hitting a merge commit
now there were quite a few changes later in the series to try to
reconcile the simple and full history, for the cases where the simple
history takes a weird path because of its love of TREESAME parents,
hiding evil merges. But I believe the simple history behaviour was
supposed to remain as-is - take first TREESAME always.
Kevin
he specified "bottom"
commit. It may be that's part of what's happening here.
Kevin
ve.fsck.zeroPaddedFilemode=ignore=warn (or
> =ignore).
[0]https://public-inbox.org/git/alpine.deb.2.21.1.1801042125430...@minint-6bku6qn.europe.corp.microsoft.com/
Hope this helps, Kevin.
is error.
>
> Thanks with Regards,
> Anjali Barodia
Did you remove the hook from the remote repo, or the local repo? Because
this is a hook which runs on the repo you are pushing too. Something
like pre-receive or pre-update is causing this.
Kevin
s they expected. It turned out
they also had a local file/dir called 'pt', which caused git to checkout
that file/dir rather than creating a local branch based on the remote
branch.
Kevin
On Sun, Apr 22, 2018 at 03:01:10PM -0400, Andrew Wolfe wrote:
> Hi Brian,
>
> Not completely sure what you're saying. If the files on master are
> not changed, the changed files' commit timestamps will be older than
> the branch commit timestamps.
>
> However, if I check out master after committ
On Thu, Feb 08, 2018 at 12:27:07PM +0100, Lars Schneider wrote:
>
> > On 08 Feb 2018, at 12:13, Lars Schneider wrote:
> >
> >
> >> On 08 Feb 2018, at 09:50, Jeff King wrote:
> >>
> >> On Wed, Feb 07, 2018 at 11:20:08PM +0100, Lars Schneider wrote:
> >>
> 1. You have $LESS in your enviro
On Tue, Jan 16, 2018 at 12:48:32PM +0100, Andreas Schwab wrote:
> On Jan 15 2018, Michael Giuffrida wrote:
>
> > It doesn't seem like a useful feature -- you wouldn't expect `git
> > fetch --prune` to remove your local branches that you were developing
> > on, right?
>
> Don't mix local and remo
On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote:
> On Tue, Jan 16, 2018 at 10:57:34AM -0800, Junio C Hamano wrote:
> > Duy Nguyen writes:
> >
> > > On Tue, Jan 16, 2018 at 4:43 AM, Keith Smiley wrote:
> > >> So it sounds like either we should deprecate rm, or I should update the
> >
On Tue, Jan 16, 2018 at 08:18:14AM +0100, Christian Couder wrote:
> Using a static buffer in sha1_file_name() is error prone
> and the performance improvements it gives are not needed
> in most of the callers.
>
> So let's get rid of this static buffer and, if necessary
> or helpful, let's use one
On Fri, Dec 29, 2017 at 02:01:00AM +, Keith Smiley wrote:
> From: Keith Smiley
>
> Previously git remote rm did not complete your list of removes as remove
> does.
Your signed-off-by[1] is missing, could you please add that?
[1]:
https://github.com/git/git/blob/master/Documentation/Submitti
objects: 100% (1879/1879), done.
It would be useful to be able to turn off individual warnings during
cloning. Is there something I’m missing in the config? Or, is this
something that could be fixed?
Thanks,
Kevin
--
Kevin A. Mitchell
http://www.kamit.com/
ith that value then? Why does this change improve the
situation?
These are things you can state in your commit message.
Hope this helps, Kevin
> > Up until recently, we encouraged dropping the curly brackets from
> > single-line statements, but apparently that changed. It is
On Fri, Dec 08, 2017 at 10:29:56PM +, Ævar Arnfjörð Bjarmason wrote:
> Here's v2 as promised. Comments per-patch.
>
> sha1dc: remove in favor of using sha1collisiondetection as a submodule
>
> Reword & expand commit message.
Is this commit missing from the mailing list because the e-mail i
On Sat, Dec 09, 2017 at 01:30:14PM +0100, Kevin Daudt wrote:
> On Tue, Dec 05, 2017 at 02:02:50AM -0500, Jeff King wrote:
> > On Tue, Nov 28, 2017 at 09:32:13PM +, Ævar Arnfjörð Bjarmason wrote:
> >
> > > Change the build process so that instead of needing to supply
it would be a lot of hassle for those
projects to get the sha1collisiondetection contents.
That's in my opinion a bigger disadvantage of submodules, commands like
git archive do not support it, making it harder to get self-contained
tarballs.
Perpahs there is a good solution to that problem, but then I'd like to
hear it.
Kevin.
On Sat, Dec 09, 2017 at 09:05:30AM +, Hans Jerry Illikainen wrote:
> Verify the signature of the tip commit when `pull.verifySignatures` is
> true. This option overrides `merge.verifySignatures` on pull, and can
> be disabled with the option `--no-verify-signatures`.
Is there a reason why git
On Sat, Dec 09, 2017 at 09:05:29AM +, Hans Jerry Illikainen wrote:
> Add tests for `pull --verify-signatures` with untrusted, bad and no
> signatures. Previously the only test for `--verify-signatures` was to
> make sure that `pull --rebase --verify-signatures` result in a warning
> (t5520-pul
mp;&
> + git merge --verbose --ff-only side-signed >mergeoutput &&
> + test_i18ngrep "has a good GPG signature" mergeoutput &&
> + git checkout initial
> '
>
> test_expect_success GPG 'merge commit with bad signature without
> verification' '
> - git merge $(cat forged.commit)
> + git merge $(cat forged.commit) &&
> + git checkout initial
> +'
> +
> +test_expect_success GPG 'merge commit with bad signature with
> merge.verifySignatures=false' '
> + test_config merge.verifySignatures false &&
> + git merge $(cat forged.commit) &&
> + git checkout initial
> +'
> +
> +test_expect_success GPG 'merge commit with bad signature with
> merge.verifySignatures=true and --no-verify-signatures' '
> + test_config merge.verifySignatures true &&
> + git merge --no-verify-signatures $(cat forged.commit) &&
> + git checkout initial
> '
>
> test_done
Kevin.
'--' to separate paths from revisions, like this:
'git [...] -- [...]'
There might be good reasons why this is, but I don't consider this to be
actually ambiguous: there is no branch called 'deleted_file.txt' and git
could know that the files exists in the mentioned commit, so it should
be pretty clear what is meant.
Might be worth documenting this.
Kevin
On Wed, Nov 22, 2017 at 06:19:23AM -0500, Robert P. J. Day wrote:
> On Wed, 22 Nov 2017, Junio C Hamano wrote:
>
> > "Robert P. J. Day" writes:
> >
> > > git repo with a file called "Gemfile", so i created a branch called
> > > "Gemfile", and when i ran:
> > >
> > > $ git checkout Gemfile
> > >
On Tue, Nov 21, 2017 at 04:47:42PM -0500, Robert P. J. Day wrote:
> On Tue, 21 Nov 2017, Kevin Daudt wrote:
>
> > On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:
> > > No major changes, just some rewording and showing some variations of
>
On Tue, Nov 21, 2017 at 04:27:59PM -0500, Robert P. J. Day wrote:
> No major changes, just some rewording and showing some variations of
> general Git commands.
>
> Signed-off-by: Robert P. J. Day
>
> ---
>
> diff --git a/Documentation/gitcli.txt b/Documentation/gitcli.txt
> index 9f13266a6..d6
users.
In the #git irc channel we often have to explain what '--' means and
why it's sometimes necessary.
I don't however know a better solution to it more clear.
Kevin
cc: mailinglist
On Thu, Nov 16, 2017 at 9:40 PM, Frank Burkitt wrote:
> Kevin -
>
> Thank you for getting back to me.
>
> The version of Git is 2.15.0
> I used Brew to install it
> I am not getting any segfaults from other apps
> When I do a ‘git init’ I get a Segmentatio
reciated.
Hello Frank,
Could you provide a bit more information?
- What version of git are you using?
- how did you install git,
- Do you also get segfaults outside of the virtualenv?
This sounds perhaps like it's a copattibility issue with a library.
Kind regards, Kevin.
On Mon, Nov 13, 2017 at 08:01:12AM +0530, Kaartic Sivaraam wrote:
> On Sunday 12 November 2017 11:53 PM, Kevin Daudt wrote:
> > On Thu, Nov 02, 2017 at 12:24:07PM +0530, Kaartic Sivaraam wrote:
> > > From: Kaartic Sivaraam
> > >
> > > When trying to rename an
e new branch name
> exists rather than specifying that the branch trying to be renamed
> doesn't exist.
>
> [..]
>
> Note: Thanks to the strbuf API that made it possible to easily construct
> the composite error message strings!
I'm not sure this note adds a lot, since the strbuf API is not that new.
Kevin
it config --expiry-date date.valid2 &&
> + git config --expiry-date date.valid3 &&
> + git config --expiry-date date.valid4
> + } >actual &&
> + test_cmp expect actual &&
> + test_must_fail git config --expi
On Sat, Nov 11, 2017 at 08:26:00AM -0500, Robert P. J. Day wrote:
>
> Current man page for "bisect" is inconsistent explaining the fact that
> "git bisect" takes precisely one bad commit, but one or more good
> commits, so tweak the man page in a few places to make that clear.
>
> rday
>
> Signe
renames turned off.
Thanks,
Kevin
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf
> Of Peter Krefting
> Sent: Friday, November 10, 2017 7:05 AM
> To: Derrick Stolee
> Cc: Jeff King ; Git Mailing List
> Subject: Re: che
On Sun, Nov 05, 2017 at 05:47:47PM +0100, René Scharfe wrote:
> Am 05.11.2017 um 03:56 schrieb Kevin Daudt:
> > On Tue, Oct 31, 2017 at 02:46:49PM +0100, René Scharfe wrote:
> >> Make the function for converting pairs of hexadecimal digits to binary
> >> av
ss, or -1 if
Is it correct to call the result binary? I would say that it's the value
that gets stored. To me, this value does not really have a base.
Kevin
it as a BUG when the prefix argument of normalize_glob_ref starts
with a '/' so that future callers will be aware of this contract.
Signed-off-by: Kevin Daudt
---
refs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/refs.c b/refs.c
index e9ae659ae..6747981d1 100644
--- a/refs.c
+
On Tue, Oct 31, 2017 at 05:33:57PM +0100, Kevin Daudt wrote:
> On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
> > Reduce code duplication by extracting a function for rewriting an
> > existing file.
> >
> > Signed-off-by: Rene Scharfe
&g
Hello Eyjolfur,
git is a version control system, which is mostly content agnostic. It
knows nothing about json or xml, let alone how to convert them.
You might want to use some kind of programming language to do the
conversion.
Could you perhaps explain more why you are asking this question?
Kevin.
On Tue, Oct 31, 2017 at 10:54:21AM +0100, René Scharfe wrote:
> Reduce code duplication by extracting a function for rewriting an
> existing file.
>
> Signed-off-by: Rene Scharfe
> ---
> sequencer.c | 46 +-
> 1 file changed, 17 insertions(+), 29 delet
On Tue, Oct 31, 2017 at 10:58:16AM +0100, René Scharfe wrote:
> Cut off any previous content of the file to be rewritten by passing the
> flag O_TRUNC to open(2) instead of calling ftruncate(2) at the end.
> That's easier and shorter.
>
> Signed-off-by: Rene Scharfe
> ---
> sequencer.c | 4 +---
th or a user of Mediawiki or with the Git
> bridging, and I don't know what page names look like, but I'm pretty
> well convinced from reading both the existing code and this patch that
> the changes to get_mw_namespace_id_for_page() are really just a bug
> fix to that function.
p repos, git
would complain about a certain object missing or corrupt, where it might
be usefull to find out how it's referenced. Not sure though if this
would work in that case, because the repo is already corrupt.
Kevin
uot;);
> + }
> }
> }
>
> diff --git a/sequencer.h b/sequencer.h
> index 6f3d3df82..a907c0947 100644
> --- a/sequencer.h
> +++ b/sequencer.h
> @@ -24,6 +24,7 @@ struct replay_opts {
> int allow_empty;
> int allow_empty_message;
> int keep_redundant_commits;
> + int keep_existing_origin;
> int verbose;
>
> int mainline;
> --
> 2.14.1
>
I'm wondering if it isn't better to detect that there is already an
origin present and not add another one.
Or are there situations where you do want multiple cherry-pick origins?
Kevin
On Tue, Oct 17, 2017 at 03:10:11PM +0200, Johannes Schindelin wrote:
> We meticulously pass the `exclude` flag to the `treat_directory()`
> function so that we can indicate that files in it are excluded rather
> than untracked when recursing.
>
> But we did not yet treat submodules the same way.
>
On Mon, Oct 23, 2017 at 02:52:46PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Kevin Daudt wrote:
>
> > --- a/column.c
> > +++ b/column.c
> > @@ -5,6 +5,7 @@
> > #include "parse-options.h"
> > #include "run-command.h"
> > #
On Sat, Sep 23, 2017 at 07:55:56PM +, Christian Couder wrote:
> It is error prone and tiring to use many long environment
> variables to give parameters to the 'run' script.
>
> Let's make it easy to store some parameters in a config
> file and to pass them to the run script.
>
> The GIT_PERF
On Tue, Oct 17, 2017 at 06:21:22PM +0300, Nikolay Yakimov wrote:
> Hello. After updating to a recent git release (2.14, I believe, but
> possibly earlier), setting GIT_EXEC_PATH to multiple directories
> stopped working. It did work before, and I believe the culprit is
> 'git-sh-setup', which uses
On Tue, Oct 17, 2017 at 11:40:17AM +0900, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> >> + setup_git_directory_gently(&nongit);
> >> +
> >> + if (!nongit)
> >> + malformed = (strbuf_check_branch_ref(&sb, arg) ||
> >&g
On Mon, Oct 16, 2017 at 07:45:46PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> [..]
>
> diff --git a/builtin/check-ref-format.c b/builtin/check-ref-format.c
> index 1e5f9835f0..4e62852089 100644
> --- a/builtin/check-ref-format.c
> +++ b/builtin/check-ref-format.c
> @@ -38,12 +38,2
On Mon, Oct 16, 2017 at 11:49:13PM +, brian m. carlson wrote:
> On Mon, Oct 16, 2017 at 11:15:34AM +0900, Junio C Hamano wrote:
> > With a hope that this might help other reviewers, here is the
> > interdiff between "the previous one merged with v2.15-rc1" and "this
> > round applied on v2.15-r
On Mon, Oct 16, 2017 at 10:55:24AM -0700, Brandon Williams wrote:
> Create protocol.{c,h} and provide functions which future servers and
> clients can use to determine which protocol to use or is being used.
>
> Also introduce the 'GIT_PROTOCOL' environment variable which will be
> used to communi
ce that was the original motivation
for this patch.
Helped-by: Rafael Ascensão
Signed-off-by: Kevin Daudt
---
Changes since v1:
- Remove redundant -p flag in tests
- Explain why git tag is being tested instead of the more obvious git
column
column.c | 3 ++-
t/t7006-pager.sh | 14 ++
On Fri, Oct 13, 2017 at 01:35:22PM -0400, Jeff King wrote:
> On Fri, Oct 13, 2017 at 11:58:12AM +0900, 小川恭史 wrote:
>
> You can also just do:
>
> for i in 1 2 3; do
> git stash drop $i
> done
>
Doesn't stash 2 become stash 1 after the first drop, and the same for 3,
resulting in droppin
On Thu, Oct 05, 2017 at 02:19:15PM +0200, Johannes Schindelin wrote:
> From: J Wyman
> [..]
>
> diff --git a/Documentation/git-for-each-ref.txt
> b/Documentation/git-for-each-ref.txt
> index 39f50bd53eb..22767025850 100644
> --- a/Documentation/git-for-each-ref.txt
> +++ b/Documentation/git-for
On Thu, Oct 12, 2017 at 12:44:59PM +0200, Kevin Daudt wrote:
> On Thu, Oct 12, 2017 at 02:02:17AM -0700, W. Trevor King wrote:
> > Pull has supported these since ea230d8 (pull: add the --gpg-sign
> > option, 2014-02-10). Insert in long-option alphabetical order
> &g
On Thu, Oct 12, 2017 at 02:02:17AM -0700, W. Trevor King wrote:
> Pull has supported these since ea230d8 (pull: add the --gpg-sign
> option, 2014-02-10). Insert in long-option alphabetical order
> following 7c85d274 (Documentation/merge-options.txt: order options in
> alphabetical groups, 2009-10-
lly
This is a known 'breakage' because people have set color.ui to always
(which should not be used anyway).
Kind regards, Kevin
On Wed, Oct 11, 2017 at 08:12:35PM +0200, Martin Ågren wrote:
> On 11 October 2017 at 19:23, Kevin Daudt wrote:
> > finalize_colopts in column.c only checks whether the output is a TTY to
> > determine if columns should be enabled with columns set to auto. Also check
> > i
auto. Also check
if the pager is active.
Helped-by: Rafael Ascensão
Signed-off-by: Kevin Daudt
---
column.c | 3 ++-
t/t7006-pager.sh | 14 ++
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/column.c b/column.c
index ff7bdab1a..ded50337f 100644
--- a/colu
On Tue, Oct 10, 2017 at 07:02:00PM +0200, Martin Ågren wrote:
> On 10 October 2017 at 16:01, Jeff King wrote:
> > On Tue, Oct 10, 2017 at 12:30:49PM +0200, Martin Ågren wrote:
> >> On 9 October 2017 at 23:45, Kevin Daudt wrote:
> >> > Since ff1e72483 (tag: change
> > --mode=auto actual &&
> > test_cmp expected actual
> > '
> > test_done
>
> Makes sense. FWIW, I don't see the flakyness with this.
>
> > All that said, I think I'd just as soon test a real command like "git
> > tag
t to autol. Also check
if the pager is active.
Helped-by: Rafael Ascensão
Signed-off-by: Kevin Daudt
---
This came to light when someone wondered on irc why
column.tag=[auto|always] did not work on Mac OS. Testing it myself, I
found it to work with always, but not with auto.
I could not get the te
the pathname.
So that seems to indicate '*.c' should only match .c files in the
current dir. I'm not sure why that's not the case.
I hope this clears up what's happening a bit, and perhaps can lead to
improvements to the documentation so that it's not so surprising.
Kind regards, Kevin.
ith the color codes. Setting it
to 'auto' would make more sense.
The thread I posted to discusses some changes that might get introduced
to improve the situation though.
Kevin.
[0}:https://public-inbox.org/git/20171003093157.gq7za2fwcqsou...@sigill.intra.peff.net/T/
On Wed, Oct 04, 2017 at 07:10:46AM -0400, rpj...@crashcourse.ca wrote:
>
> couple (admittedly trivial) questions about stashing. first, can i
> clarify that when one stashes content, a stash *always* distinguishes
> between what was staged, and what was unstaged? that is, when one is
> stashing,
ing the value to auto should
fix it (setting it to always does not make much sense in your config
file).
Kevin.
[0}:https://public-inbox.org/git/20171003093157.gq7za2fwcqsou...@sigill.intra.peff.net/T/
On Mon, Oct 02, 2017 at 12:06:38AM +0800, Yubin Ruan wrote:
> 2017-10-01 22:17 GMT+08:00 Kevin Daudt :
> > Forgot to cc the mailing list.
> >
> > On Sun, Oct 01, 2017 at 09:23:23PM +0800, Yubin Ruan wrote:
> >> Suppose that I have such a history of commit locally:
ld look to git like you created F', and someone else
had pushed F and G. It will reject the push, saying you would need to
merge these changes first (but you don't want this, because you are
merging the same changes together).
To solve this, you can use git push --force-with-lease=master or
The last section under description explains that
mode.
Do you feel this distinction needs to be made more clear?
Kevin.
On Mon, Sep 25, 2017 at 04:31:10PM +0900, Sanggyu Nam wrote:
> I’ve found that some subcommands such as git-clone, git-fetch, and
> git-pull support an option named ‘--shallow-since’, as of Git version
> 2.11. This option is documented in the man page of each subcommand. In
> Git 2.14.1, I’ve check
t; git checkout -B branch1-scratch &&
> -
> setup_dirty_mergeable &&
> git checkout -B branch1-scratch initial &&
> test_dirty_mergeable
>
> --
> https://github.com/git/git/pull/403
Why is this empty line unwanted? This kind of whitespace can help
separate logical sections, just like paragraphs would.
Kevin.
From: Junio C Hamano [mailto:gits...@pobox.com]
Sent: Thursday, September 14, 2017 11:00 PM
>
> Kevin Willford writes:
>
> > 1. Does this statement, "I only care about the files in this
> > sparse checkout, and do not concern me with anything else", mean
>
On Fri, Sep 15, 2017 at 08:37:40AM +0200, Kevin Daudt wrote:
> On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Hi there,
> >
> > While bumping Git's version for our Linux dist
On Thu, Sep 14, 2017 at 09:43:12PM -0500, A. Wilcox wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi there,
>
> While bumping Git's version for our Linux distribution to 2.14.1, I've
> run in to a new test failure in t6500-gc.sh. This is the output of
> the failing test with deb
out when there is a merge conflict with a file that is outside
the sparse checkout? Should there not be a conflict because
git shouldn't be trying to merge the file since it is outside the sparse
checkout area? Should the conflicted file get written outside the
sparse checkout so the user can resolve it?
Thanks,
Kevin
> From: Jacob Keller [mailto:jacob.kel...@gmail.com]
> Sent: Tuesday, September 12, 2017 7:39 PM
>
> On Tue, Sep 12, 2017 at 4:30 PM, Kevin Willford wrote:
> >
> > Sorry. It was not in the sparse-checkout file.
> > $ git config core.sparsecheckout true
> > $
On Tue, Sep 12, 2017 at 04:25:36PM +0530, Kaartic Sivaraam wrote:
> It's not possible to 'touch' the cut-line that is shown when the
> user requests a patch in his commit template.
>
Touching something can also mean to disturb or change something, which
is the meaning being used here, so it is no
1 - 100 of 494 matches
Mail list logo
