On Wed, Dec 12, 2018 at 1:29 AM Johannes Sixt wrote:
> As long as C:\Windows\System32 on my Windows computer contains only
> 64-Bit binaries, I consider the characters "3" and "2" next to each
> other in this order just noise and without any form of information. The
> important part of the name is
On Tue, Dec 11, 2018 at 7:39 AM Johannes Schindelin wrote:
> I have no intention of flaming anybody. That is simply a
> misrepresentation.
you may see yourself "through a glass darkly", but i dont. this language is not
constructive:
> > - pc-windows
> > - pc-win
> > - win
>
> I find all of those
On Mon, Dec 10, 2018 at 2:46 AM Johannes Schindelin wrote:
> please stop dropping me from the Cc: list. Thanks.
i dropped you specifically because i knew you were going to flame like you just
did below. oh well, i guess you cant avoid the inevitable.
> > - pc-windows
> > - pc-win
> > - win
>
> I
On Sat, Dec 8, 2018 at 9:11 AM wrote:
> Changes since V2:
latest patch still fixes original issue - thanks
> - Settled on a better name:
> The common code is in compat/win32/path-utils.c/h
> [...]
> - The "DOS" moniker is still used for 2 reasons:
> Windows inherited the "drive letter" conc
On Fri, Dec 7, 2018 at 11:04 AM wrote:
> The solution is to implement has_dos_drive_prefix(), skip_dos_drive_prefix()
> is_dir_sep(), offset_1st_component() and convert_slashes() for cygwin
> in the same way as it is done in 'Git for Windows' in compat/mingw.[ch]
>
> Instead of duplicating the code
On Mon, Nov 26, 2018 at 11:23 PM Junio C Hamano wrote:
> Sorry, but I do not see the connection to this question and the
> above example. The reason why we strip C: is because the letter
> that comes after that colon determines if we are talking about
> absolute path (in other words, the current d
On Mon, Nov 26, 2018 at 7:16 PM Junio C Hamano wrote:
> I wonder if it makes the rest of the code simpler if we stripped
> things like /cygdrive/c here exactly the sam way as we strip C:
> For that, has_dos_drive_prefix() needs to know /cygdrive/[a-z],
> which may not be a bad thing, I guess. Let'
On Mon, Nov 26, 2018 at 11:32 AM wrote:
> This is the first vesion of a patch.
> Is there a chance that you test it ?
I can confirm that this fixes the issue.
Thank you!
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
>
diff --git a/abspath.c b/abspat
On Sun, Nov 18, 2018 at 11:21 PM Torsten Bögershausen wrote:
> If nothing works,
> it may help to add some fprintf(stderr,...) in the functions used
> by 05b458c104708141d2f:
>
> strip_last_component(),
> get_next_component()
> real_path_internal()
I didnt see any "real_path_internal" in the curre
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 resolve to same path:
git cl
On Sun, Nov 18, 2018 at 11:15 AM Torsten Bögershausen wrote:
> But it may be that we need to pull in more stuff, similar to mingw,
> to get the C: stuff working, see
> "skip_dos_drive_prefix"
>
> And it may even be that we need a special handling for the "\" to be treated
> as "/".
>
> If you imple
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 to
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 into 'C
On Sun, Jan 8, 2017 at 5:54 AM, Johannes Schindelin wrote:
> I am curious: how do you build Git? I ask because I build Git on Windows
> many times a day, and I did not encounter any link problems.
My end goal is to build static native Windows Git via Cygwin and the
mingw64-x86_64-gcc-core package.
This matches up with the targets git-%, git-http-fetch, git-http-push and
git-remote-testsvn. It must be done this way on Windows else lcrypto cannot find
lgdi32 and lws2_32
Signed-off-by: Steven Penny
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b
When environment variable POSIXLY_CORRECT is set, the "input -o output" syntax
is not supported.
http://cygwin.com/ml/cygwin/2017-01/msg00036.html
Signed-off-by: Steven Penny
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
ind
ptions such as "--all" will still work using this method as well.
Signed-off-by: Steven Penny
---
gitk-git/gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 90764e8..64a125d 100755
--- a/gitk-git/gitk
+++ b/gitk-git
dia.org/wiki/Key_&_Peele'
'_Peele' is not recognized as an internal or external command,
operable program or batch file.
An alternative is to use PowerShell. PowerShell is a component of Windows and
will work with both MinGW and Cygwin.
Signed-off-by: Steven Penny
---
Sorry if I am drumming up and old issue here. I have noticed that with
"git rebase -i", if your final line contains a commit and no newline, git
interprets that as "remove this commit please".
I feel that a commit should be removed only if the entire line is removed, that
is the commit hash and ti
I have noticed that
git pull --quiet
is actually only "quiet" if no problems are found
If unmerged error occurs, output is seen on BOTH stdout and stderr
$ git pull -q >/dev/null
Pull is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'gi
21 matches
Mail list logo
