Test scripts checking 'git daemon' stop the daemon with a TERM signal,
and the 'stop_git_daemon' helper checks the daemon's exit status to
make sure that it indeed died because of that signal.
This check is bogus since 03c39b3458 (t/lib-git-daemon: use
test_match_signal, 2016-06-24), for two
hread-safe as chdir() affects a
process as a whole...
The old (and non-thread-save) OS calls chdir()/pwd() had been
replaced by a string operation.
The cygwin layer "knows" that "C:\cygwin" is an absolute path,
but the new string operation does not.
"git clone C
Hi Daniel,
On 16-May-17 6:00 AM, Daniel Ferreira wrote:
This is the second version of a patch series to start porting
git-add--interactive from Perl to C.
Series:
v1:
https://public-inbox.org/git/1494009820-2090-1-git-send-email-bnm...@gmail.com/
Travis CI build: https://travis-ci.org
This may be the most controversial. It demotes the C
> reimplementation of "git rebase" to an experimental opt-in
>feature that can only be enabled by setting rebase.useBuiltIn
>configuration that defaults to false.
>
>cf.
If we don't set rebase.useBuilti
On Mon, Nov 26, 2018 at 08:32:27PM +0530, Chandra Shekhar wrote:
> cess: Resource temporarily unavailable (-1).
> DLL rebasing may be required; see 'rebaseall / rebase --help'.
This <https://github.com/git-for-windows/git/issues/1015> ?
Please do not post screenshots, post text.
cess: Resource temporarily unavailable (-1).
DLL rebasing may be required; see 'rebaseall / rebase --help'.
y: Thomas Gummerer
>
> Thanks.
>
> One thing that bothers me is that this seems to have been rebased on
> 'master', but as long as we are rebasing, the updated series must
> also take into account of the sd/stash-wo-user-name topic, i.e. if
> we are rebasing it, it should be rebase
Unless I hear otherwise in the next 24 hours, I am planning to
merge the following topics to 'master' before cutting -rc2. Please
stop me on any of these topics.
- jc/postpone-rebase-in-c
This may be the most controversial. It demotes the C
reimplementation of "git r
Junio C Hamano writes:
> Ævar Arnfjörð Bjarmason writes:
>
>>> * "git rebase" and "git rebase -i" have been reimplemented in C.
>>
>> Here's another regression in the C version (and rc1),...
>> I wasn't trying to stress test rebase.
t bothers me is that this seems to have been rebased on
'master', but as long as we are rebasing, the updated series must
also take into account of the sd/stash-wo-user-name topic, i.e. if
we are rebasing it, it should be rebased on top of the result of
git checkout -B ps/rebase-in-c master
On 11/23, Paul-Sebastian Ungureanu wrote:
> Hello,
>
> This is the 11th iteration of C git stash. Here are some of the changes,
> based on Thomas's and dscho's suggestions (from mailing list / pull request
> #495):
Thanks for your work on this! I have read through the range-d
On 11/24/18 10:41 AM, Konstantin Khomoutov wrote:
On Sat, Nov 24, 2018 at 05:57:24PM +0300, Konstantin Khomoutov wrote:
On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote:
It seems that git is overwriting my local files on merge if they're in
.gitignore.
[...]
The .gitignore
Ævar Arnfjörð Bjarmason writes:
>> * "git rebase" and "git rebase -i" have been reimplemented in C.
>
> Here's another regression in the C version (and rc1),...
> I wasn't trying to stress test rebase. I was just wanting to rebase a
> history I was ab
On Wed, Nov 21 2018, Junio C Hamano wrote:
> * "git rebase" and "git rebase -i" have been reimplemented in C.
Here's another regression in the C version (and rc1), note: the
sha1collisiondetection is just a stand in for "some repo":
(
rm -rf /
On Sat, Nov 24, 2018 at 05:57:24PM +0300, Konstantin Khomoutov wrote:
> On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote:
>
> > > > It seems that git is overwriting my local files on merge if they're in
> > > > .gitignore.
> [...]
> > &g
On Sat, Nov 24, 2018 at 09:37:06AM -0500, David Mandelberg wrote:
> > > It seems that git is overwriting my local files on merge if they're in
> > > .gitignore.
[...]
> > The .gitignore file is to list "ignored and expendable" class of
> > files; there i
On 11/23/18 11:22 PM, Junio C Hamano wrote:
David Mandelberg writes:
It seems that git is overwriting my local files on merge if they're in
.gitignore. See command transcript below. I searched `git help config`
and Google, but I couldn't find any way to prevent it. Am I missing
something
David Mandelberg writes:
> It seems that git is overwriting my local files on merge if they're in
> .gitignore. See command transcript below. I searched `git help config`
> and Google, but I couldn't find any way to prevent it. Am I missing
> something? (The reason I care about i
Hi,
It seems that git is overwriting my local files on merge if they're in
.gitignore. See command transcript below. I searched `git help config`
and Google, but I couldn't find any way to prevent it. Am I missing
something? (The reason I care about ignored files is that I'm using git
Hi Peff,
On Thu, 22 Nov 2018, Jeff King wrote:
> On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
>
> > So YMMV with git-s. My rule of thumb is: if I want to use this
> > myself only, I'll make it an alias. If I want to ship it (e.g. with Git
> >
This commit introduces tests for `git stash show`
config. It tests all the cases where `stash.showStat`
and `stash.showPatch` are unset or set to true / false.
Signed-off-by: Paul-Sebastian Ungureanu
---
t/t3907-stash-show-config.sh | 83
1 file changed, 83
Hello,
This is the 11th iteration of C git stash. Here are some of the changes,
based on Thomas's and dscho's suggestions (from mailing list / pull request
#495):
- improved memory management. Now, the callers of `do_create_stash()`
are responsible of freeing the parameter they pass in. Moreover
On Sat, Nov 17, 2018 at 11:07:32PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I suspect it would be less confusing if the rewrite were inverted, like:
> >
> > [url "gh:"]
> > rewriteTo = https://github.com
> > rewritePrivate
>
t; CURL Option: OpenSSL
> CRLF Option: CRLFCommitAsIs
> Bash Terminal Option: MinTTY
> Performance Tweaks FSCache: Enabled
> Use Credential Manager: Enabled
> Enable Symlinks: Disabled
> Enable Builtin Rebase: Enabled
> Enable Builtin Stash: Enabled
>
>
>
> When
On Wed, Nov 21, 2018 at 11:28:28AM -0800, Bryan Turner wrote:
> But that test code exists because Bitbucket Server provides a Java API
> [1][2] which allows third-party developers to easily build arbitrary
> Git commands to invoke for their own functionality
On Thu, Nov 22, 2018 at 01:48:53PM +0100, Johannes Schindelin wrote:
> > So it's maybe do-able, but not quite as trivial as one might hope.
>
> A trivial alternative would be to recommend adding a man page for
> 3rd-party git-s.
>
> In other words, as soon as `git-sizer` i
ist
> > for --help.
>
> Yeah, I think this really the only problematic assumption. The rest of
> "-c", "--git-dir", etc, are just manipulating the environment, and that
> gets passed through to sub-invocations of Git (so if I have a script
> which calls git-conf
Hello!
I have very bad news for you.
06/08/2018 - on this day I hacked your operating system and got full access to
your account git@vger.kernel.org
On that day your account git@vger.kernel.org password was: e7d1w8i2n
It is useless to change the password, my malware intercepts it every time
Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Rebase: Enabled
Enable Builtin Stash: Enabled
When starting the git bash two windows pop up instead of one.
One that's "empty" and the other one containing the real git bash.
Thanks,
Stefan
Am 20.11.2018 um 21:56 schrie
it only turns stats off. Since we want to
make the interactive machinery also take over for git-rebase--merge, it
should fully implement the --quiet option.
git-rebase--interactive was already somewhat quieter than
git-rebase--merge and git-rebase--am, possibly because cherry-pick has
just
The git-legacy-rebase.sh script previously had code of the form:
if git_am_opt:
if interactive:
if incompatible_opts:
show_error_about_interactive_and_am_incompatibilities
if rebase-merge:
if incompatible_opts
show_error_about_merge_and_am_incompatibilities
which
On Wed, Nov 21, 2018 at 6:20 AM Jeff King wrote:
>
> On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
>
> > I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> > both Linux and Windows, and the only failures were related to this
> > chang
I think I've got it now; maybe I just needed to sleep on it. It's
happier if I use the whole URL for trunk in the -T parameter.
I'll see how the rest of it plays out, but the `git svn show-ignore
--id=origin/trunk` command is working now.
On Wed, Nov 21, 2018 at 10:45 AM Jamie Jackson wrote
By the way, my goal is to pull in trunk (only) at first, and possibly
pull in certain branches (later) on an as-needed basis. I'll need to
sync the Git repo with SVN for a while, until we permanently switch to
Git (and put SVN in read-only).
On Wed, Nov 21, 2018 at 10:38 AM Jamie Jackson wrote
ICF2008571:eclipse-workspace jjackson$ git svn clone \
> -r 95115:HEAD https://mydomain.com/svn/HUD/onecpd \
> -T trunk \
> --no-metadata \
> -A ~/eclipse-workspace/scraps/git_migration/users.txt \
> hudx-git-migration
ICF2008571:eclipse-workspace jjackson$ cd hud
Here is today's test report.
Thanks,
-Stolee
[1] https://dev.azure.com/git/git/_build/results?buildId=271=logs
---
pu: c4a21f043160e02a25755bbf43e4d2fa0b9766aa
jch: 29ea8ddbcef3ec1c79fffa23cc5751a45344754c
next: 68bc7959f8dc2d629c09be1a52f1b95b977b3a13
master
On Wed, Nov 21, 2018 at 08:37:03AM -0500, Jamie Jackson wrote:
> I'm brand new to svn-git and I'm having a problem right out of the
> gate. I suspect I need a different ID, but I have no clue how to get
> it.
>
> Here's the failed attempt:
> https://gist.githu
Hi everyone,
The 45th edition of Git Rev News is now published:
https://git.github.io/rev_news/2018/11/21/edition-45/
Thanks a lot to the contributors: Elijah Newren, Luca Milanesio,
Derrick Stolee and Johannes Schindelin!
Enjoy,
Christian, Jakub, Markus and Gabriel.
On Tue, Nov 20, 2018 at 03:17:07PM -0800, Bryan Turner wrote:
> I've run 2.20.0-rc0 through the test matrix for Bitbucket Server on
> both Linux and Windows, and the only failures were related to this
> change:
>
> * "git branch -l " used to be a way to ask a reflog
On Wed, Nov 21, 2018 at 02:54:34PM +0100, Marc Gonzalez wrote:
> If I specify the branch to explore, git grep prints a colon instead of
> a slash in the path:
>
> $ git grep arm,coresight-tmc master:Documentation/devicetree
> master:Documentation/devicetree:bindings/ar
Hello,
I'm using an older version of git, so this particular issue might have
already been fixed.
$ git --version
git version 2.17.1
If I specify the branch to explore, git grep prints a colon instead of
a slash in the path:
$ git grep arm,coresight-tmc master:Documentation/devicetree
I'm brand new to svn-git and I'm having a problem right out of the
gate. I suspect I need a different ID, but I have no clue how to get
it.
Here's the failed attempt:
https://gist.github.com/jamiejackson/57e90302802f4990b36dfe28c3c71d13
What am I doing wrong?
Thanks,
Jamie
On Tue, Nov 20, 2018 at 12:57 PM Johannes Schindelin
wrote:
>
> Team,
>
> On Sun, 18 Nov 2018, Junio C Hamano wrote:
>
> > An early preview release Git v2.20.0-rc0 is now available for
> > testing at the usual places. It is comprised of 887 non-merge
> > commits
Team,
On Sun, 18 Nov 2018, Junio C Hamano wrote:
> An early preview release Git v2.20.0-rc0 is now available for
> testing at the usual places. It is comprised of 887 non-merge
> commits since v2.19.0, contributed by 71 people, 23 of which are
> new faces.
The "for Windo
ST_REBASE_USE_BUILTIN=false and it bisects to 4520c2337: Merge branch
> 'ab/rebase-in-c-escape-hatch'.
>
> The issue is that the commit 04519d72 "rebase: validate -C and
> --whitespace= parameters early" introduced the following test that cares
> about error
On Tue, Nov 20, 2018 at 1:55 PM SZEDER Gábor wrote:
>
> On Tue, Nov 20, 2018 at 01:39:40PM +0100, Mathieu Malaterre wrote:
> > Here is a simple setup:
> >
> > cd /tmp
> > mkdir g
> > cd g
> > git init .
> > wget
> > http://central.m
On Tue, Nov 20, 2018 at 01:39:40PM +0100, Mathieu Malaterre wrote:
> Here is a simple setup:
>
> cd /tmp
> mkdir g
> cd g
> git init .
> wget
> http://central.maven.org/maven2/org/apache/xmlgraphics/fop/2.1/fop-2.1.pom
> git add fop-2.1.pom
> git commi
On Tue, Nov 20, 2018 at 4:36 AM Torsten Bögershausen wrote:
> Could you please post a "git diff" of your instrumented code,
> so that I/we can follow the debugging, especially what the printouts mean?
>
> I think we need to understand what is going on in abspath.c
>
On Tue, Nov 20, 2018 at 07:17:46AM -0500, Derrick Stolee wrote:
> > And I think that's a pattern with the delta-island code. What we really
> > care about most is that if we throw a real fork-network repository at
> > it, it produces faster clones with fewer un-reusable deltas. So I think
> > a
Here is a simple setup:
cd /tmp
mkdir g
cd g
git init .
wget
http://central.maven.org/maven2/org/apache/xmlgraphics/fop/2.1/fop-2.1.pom
git add fop-2.1.pom
git commit -m "My First Commit"
git rm fop-2.1.pom
git commit -m "Second Commit"
git format-pat
On 11/20/2018 6:34 AM, Jeff King wrote:
On Mon, Nov 19, 2018 at 10:40:53AM -0500, Derrick Stolee wrote:
Since depth is never incremented, we are not covering this block. Is it
possible to test?
This should be covered by the fix in:
https://public-inbox.org/git/20181120095053.gc22
t 'ent->tree_depth = depth;' line is replaced with the
> oe_set_tree_depth() call in the report.
>
> Since depth is never incremented, we are not covering this block. Is it
> possible to test?
This should be covered by the fix in:
https://public-inbox.org/git/20181120095053.gc22...
_next_component()
>> real_path_internal()
>
> I didnt see any "real_path_internal" in the current codebase - however i added
> some "printf" to the other 2 and got this:
>
> $ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk'
> get_next_com
Hi,
Git v2.20.0-rc0 has been released, and it's time to start new round of git l10n.
This time there are 254 updated messages need to be translated since last
update:
l10n: git.pot: v2.20.0 round 1 (254 new, 27 removed)
Generate po/git.pot from v2.20.0-rc0-23-gbb75be6cb9 for git v2.20.0
y "real_path_internal" in the current codebase - however i added
some "printf" to the other 2 and got this:
$ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk'
get_next_component, next, []
get_next_component, remaining, [C:\cygwin64\tmp\goawk]
Cloning into 'C:\cygwin
lse and it bisects to 4520c2337: Merge
> branch 'ab/rebase-in-c-escape-hatch'.
>
> The issue is that the commit 04519d72 "rebase: validate -C and
> --whitespace= parameters early" introduced the following test
> that cares about error messages:
>
> +test_expect_
hat
cares about error messages:
+test_expect_success 'error out early upon -C or --whitespace=' '
+ test_must_fail git rebase -Cnot-a-number HEAD 2>err &&
+ test_i18ngrep "numerical value" err &&
+ test_must_fail git rebase --whitespace=bad HEAD
d1664e73a: add: speed up cmd_add() by utilizing
read_cache_preload()
> Ben Peart fa655d841: checkout: optimize "git checkout -b
"
These should be hit if you run the test suite with
GIT_TEST_INDEX_THREADS=2. Without that, the indexes for the various
tests are too
On Mon, Nov 19 2018, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>
>>> [...]
>>> builtin/rebase.c
>>> 62c23938fa 55) return env;
>>> [...]
>>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>>> where rebase.useBuiltin is
On 11/19/2018 2:39 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
The coverage report has been using the following:
export GIT_TEST_MULTI_PACK_INDEX=1
export GIT_TEST_COMMIT_GRAPH=1
export GIT_TEST_INDEX_VERION=4
export GIT_TEST_SPLIT_INDEX=yes
export
On Mon, Nov 19 2018, Derrick Stolee wrote:
> On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
>> On Mon, Nov 19 2018, Derrick Stolee wrote:
>>
>>> Here is a test coverage report for the uncovered lines introduced in
>>> v2.20.0-rc0 compared to v2.19.1.
>> Thanks a lot for this.
>>
>>>
On 11/19/2018 1:33 PM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Nov 19 2018, Derrick Stolee wrote:
Here is a test coverage report for the uncovered lines introduced in
v2.20.0-rc0 compared to v2.19.1.
Thanks a lot for this.
[...]
builtin/rebase.c
62c23938fa 55) return env;
[...]
Ævar Arnfjörð
Peart fa655d841: checkout: optimize "git checkout -b
"
These should be hit if you run the test suite with
GIT_TEST_INDEX_THREADS=2. Without that, the indexes for the various
tests are too small to trigger multi-threaded index reads/writes.
From t/README:
GIT_TEST_INDEX_THREAD
Ævar Arnfjörð Bjarmason wrote:
> On Mon, Nov 19 2018, Derrick Stolee wrote:
>> [...]
>> builtin/rebase.c
>> 62c23938fa 55) return env;
>> [...]
>> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special setup
>> where rebase.useBuiltin is off
>
> This one would be covered with
>
e is much bigger problem with this code, which is that
> 108f530385 (pack-objects: move tree_depth into 'struct packing_data',
> 2018-08-16) is totally broken. It works on the trivial repository in the
> test, but try this (especially under valgrind or ASan) on a real
> repository:
>
>
On Mon, Nov 19 2018, Derrick Stolee wrote:
> Here is a test coverage report for the uncovered lines introduced in
> v2.20.0-rc0 compared to v2.19.1.
Thanks a lot for this.
> [...]
> builtin/rebase.c
> 62c23938fa 55) return env;
> [...]
> Ævar Arnfjörð Bjarmason 62c23938f: tests: add a special
other is for optimizing
on-disk packs to serve fetches). Something like:
echo HEAD^ | git pack-objects --revs --thin --delta-islands
would probably exercise it (assuming there's a delta in HEAD^ against
something in HEAD), but you'd need to construct a very specific scenario
if you wanted to
items[i].util;
26c7d06783 help.c 535) aliases[i].category = 1;
26c7d06783 help.c 537) aliases[alias_list.nr].name = NULL;
26c7d06783 help.c 538) print_command_list(aliases, 1, longest);
26c7d06783 help.c 539) free(aliases);
This logic introduces alias help in 'git h
> > one works on a tree, tree_entry_interesting(), which gets :(attr)
> > support in this series.
> >
> > With this, "git grep -- :(attr)" or "git log :(attr)"
> > will not abort with BUG() anymore.
> >
> > But this also reveals an int
On Mon, Nov 19, 2018 at 12:16 PM Ævar Arnfjörð Bjarmason
wrote:
> As an aside, how do you do the inverse of matching for an attribute by
> value? I.e.:
>
> $ git ls-files | wc -l; git ls-files ':(attr:diff=perl)' | wc -l
> 3522
> 65
>
> I'd like something gives
Hi all!
We're observing a strange behavior of git describe. We have a local fork of an
open-source github.com/openbmc/openbmc repository. The local fork has some
extra commits and we merge from upstream on a regular basis. Until today it all
worked fine, the last merge was from upstream commit
or
> described here is the right way to go. E.g. in git.git we have diff=perl
> entries in .gitattributes. It would suck if:
>
> git log ':(attr:diff=perl)'
>
> Would only list commits as far as 20460635a8 (".gitattributes: use the
> "perl" differ fo
this series.
>
> With this, "git grep -- :(attr)" or "git log :(attr)"
> will not abort with BUG() anymore.
>
> But this also reveals an interesting thing: even though we walk on a
> tree, we check attributes from _worktree_ (and optionally fall back to
> the index). Th
, tree_entry_interesting(), which gets :(attr)
>> support in this series.
>>
>> With this, "git grep -- :(attr)" or "git log :(attr)"
>> will not abort with BUG() anymore.
>>
>> But this also reveals an interesting thing: even though we
Hi,
A draft of a new Git Rev News edition is available here:
https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-45.md
Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub
e/c, /cygdrive/d always prefaces the
>> path rather than C:\ or D:\, which won't parse. It is,
>> essentially, a bash environment, including that git completions
>> work properly. Backslash ends up doing what it would in bash.
>
> In short, in your opinion, the original
if you want to do
>> that.
>
> Heavy Cygwin user here. It is used in my environment for
> cross-compilation. Everything should be done using / separators in
> Cygwin, not \. So /cygdrive/c, /cygdrive/d always prefaces the
> path rather than C:\ or D:\, which won't parse. It is,
Here is a test coverage report for the uncovered lines introduced in
v2.20.0-rc0 compared to v2.19.1.
Thanks,
-Stolee
[1] https://dev.azure.com/git/git/_build/results?buildId=263=logs
---
apply.c
eccb5a5f3d 4071) return get_oid_hex(p->old_oid_prefix, oid);
517fe807d6 4776) BUG_ON_OPT_
> -Original Message-
> From: git-ow...@vger.kernel.org On Behalf Of
> Junio C Hamano
> Sent: November 18, 2018 19:07
> To: Torsten Bögershausen
> Cc: Steven Penny ; git@vger.kernel.org
> Subject: Re: Cygwin Git with Windows paths
>
> Torsten Bögershausen wri
Nguyễn Thái Ngọc Duy writes:
> But this also reveals an interesting thing: even though we walk on a
> tree, we check attributes from _worktree_ (and optionally fall back to
> the index). This is how attributes are implemented since forever. I
> think this is not a big deal if we communicate
Torsten Bögershausen writes:
> And it may even be that we need a special handling for the "\" to be treated
> as "/".
I do not do Windows, but is_dir_sep() needs to be tweaked if you
want to do that.
Here is the test coverage report for today.
Thanks,
-Stolee
[1] https://dev.azure.com/git/git/_build/results?buildId=257=logs
---
pu: d02f4432dcda003413023869ebe412f03155f230
jch: af77f5458d76b45843ab70c577a54db24b4ea92f
next: 6e8e63e21ad73680486866b4870b45db87c3d939
master
this series.
>
> With this, "git grep -- :(attr)" or "git log :(attr)"
> will not abort with BUG() anymore.
>
> But this also reveals an interesting thing: even though we walk on a
> tree, we check attributes from _worktree_ (and optionally fall back to
> the index). Th
On Sun, Nov 18, 2018 at 12:28 PM Torsten Bögershausen wrote:
> Thanks for testing.
> It looks as if there is more work to be done then just a simple patch.
>
> My last question for today:
> Does
>
> git clone '/cgdrive/c/my/dir'
>
> work ?
yes - these all work and re
; >
> > And it may even be that we need a special handling for the "\" to be treated
> > as "/".
> >
> > If you implement "skip_dos_drive_prefix" similar to mingw,
> > (rename mingw into cygwin) does
> >
> > git cl
to be treated
> as "/".
>
> If you implement "skip_dos_drive_prefix" similar to mingw,
> (rename mingw into cygwin) does
>
> git clone C:/my/dir/
> work ?
I added this to "compat/cygwin.h":
#define has_dos_drive_prefix(path) \
(isalpha
; >
> > Does the following help ? (fully untested)
>
> that looks promising - but its not getting pulled in where it needs to be.
> perhaps another file need to be modified to utilize that macro?
The macro should be utilized, see git-compat-util.h:
#if defined(__CYGWIN__)
#i
When :(attr) was added, it supported one of the two main pathspec
matching functions, the one that works on a list of paths. The other
one works on a tree, tree_entry_interesting(), which gets :(attr)
support in this series.
With this, "git grep -- :(attr)" or "git log :(attr)&
On Sun, Nov 18, 2018 at 9:41 AM Torsten Bögershausen wrote:
> Thanks for the report
> It seams as if "C:" is not recognized as an absolute path under
> cygwin.
> May be it should ?
>
> Does the following help ? (fully untested)
that looks promising - but its not getting pulled in where it needs
On Sun, Nov 18, 2018 at 07:21:58AM -0800, Steven Penny wrote:
> Cygwin programs can handle Unix form paths:
>
>$ ls /var
>cache lib log run tmp
>
> and also Windows form paths:
>
>$ ls 'C:\cygwin64\var'
>cache lib log run tmp
>
>
Cygwin programs can handle Unix form paths:
$ ls /var
cache lib log run tmp
and also Windows form paths:
$ ls 'C:\cygwin64\var'
cache lib log run tmp
However current Cygwin Git cannot:
$ git clone git://github.com/benhoyt/goawk 'C:\cygwin64\tmp\goawk'
Cloning
Jeff King writes:
> I suspect it would be less confusing if the rewrite were inverted, like:
>
> [url "gh:"]
> rewriteTo = https://github.com
> rewritePrivate
>
> [url "git://github.com"]
> rewriteTo = https://github.com
>
> where th
On Sat, Nov 17, 2018 at 04:46:22PM +0900, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
> >> $ git request-pull HEAD^ git://foo.example.com/example | grep example
> >> ssh://bar.example.com/example
> >>
> >> I think that if
"brian m. carlson" writes:
>> $ git request-pull HEAD^ git://foo.example.com/example | grep example
>> ssh://bar.example.com/example
>>
>> I think that if we use the "principle of least surprise," insteadOf
>> rules shouldn't be applied fo
ssumption. The rest of
"-c", "--git-dir", etc, are just manipulating the environment, and that
gets passed through to sub-invocations of Git (so if I have a script
which calls git-config, it will pick up the "-c" config).
It would be nice if there was a way to ask "is the
On Fri, Nov 16 2018, Michael Haggerty wrote:
> On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
> wrote:
>> [...]
>> A follow-up on this: We should really fix this for other
>> reasons. I.e. compile in some "this is stuff we ourselves think is in
On Fri, Nov 16, 2018 at 11:38 AM Ævar Arnfjörð Bjarmason
wrote:
> [...]
> A follow-up on this: We should really fix this for other
> reasons. I.e. compile in some "this is stuff we ourselves think is in
> git".
>
> There's other manifestations of this, e.g.:
>
&g
Hi Mikhail,
On Mon, 17 Sep 2018, Mikhail Matrosov wrote:
> Please try the following:
>
> mmatrosov@Mikhail-PC:~/test$ git init --bare server
> Initialized empty Git repository in /home/mmatrosov/test/server/
> mmatrosov@Mikhail-PC:~/test$ git clone server local
> C
On Thu, Nov 15, 2018 at 01:28:26PM -0500, Konstantin Ryabitsev wrote:
> Hi, all:
>
> Looks like setting url.insteadOf rules alters the output of
> git-request-pull. I'm not sure that's the intended use of insteadOf,
> which is supposed to replace URLs for local use, not to expose
alternative would be to write out a shell file similar to
> GIT-BUILD-OPTIONS and source that from this thing. I don't know, what
> do you all think?
>
> The idea with 4/5 was to make this symlink mode the default in
> config.mak.uname and have a blacklist of systems like Windows that
&
201 - 300 of 30258 matches
Mail list logo
