Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

[Steve Hoelzer]

On Fri, Nov 2, 2018 at 11:43 AM Johannes Sixt  wrote:
>
> Am 02.11.18 um 15:47 schrieb Steve Hoelzer:
> > On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt  wrote:
> >>
> >> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
> >>> @@ -614,7 +618,7 @@ restart:
> >>>
> >>>  if (!rc && orig_timeout && timeout != INFTIM)
> >>>{
> >>> -  elapsed = GetTickCount() - start;
> >>> +  elapsed = (DWORD)(GetTickCount64() - start);
> >>
> >> AFAICS, this subtraction in the old code is the correct way to take
> >> account of wrap-arounds in the tick count. The new code truncates the 64
> >> bit difference to 32 bits; the result is exactly identical to a
> >> difference computed from truncated 32 bit values, which is what we had
> >> in the old code.
> >>
> >> IOW, there is no change in behavior. The statement "avoid wrap-around
> >> issues" in the subject line is not correct. The patch's only effect is
> >> that it removes Warning C28159.
> >>
> >> What is really needed is that all quantities in the calculations are
> >> promoted to ULONGLONG. Unless, of course, we agree that a timeout of
> >> more than 49 days cannot happen ;)
> >
> > Yep, correct on all counts. I'm in favor of changing the commit message to
> > only say that this patch removes Warning C28159.
>
> How about this fixup instead?
>
>  8< 
> squash! poll: use GetTickCount64() to avoid wrap-around issues
>
> The value of timeout starts as an int value, and for this reason it
> cannot overflow unsigned long long aka ULONGLONG. The unsigned version
> of this initial value is available in orig_timeout. The difference
> (orig_timeout - elapsed) cannot wrap around because it is protected by
> a conditional (as can be seen in the patch text). Hence, the ULONGLONG
> difference can only have values that are smaller than the initial
> timeout value and truncation to int cannot overflow.
>
> Signed-off-by: Johannes Sixt 
> ---
>  compat/poll/poll.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/compat/poll/poll.c b/compat/poll/poll.c
> index 4abbfcb6a4..4459408c7d 100644
> --- a/compat/poll/poll.c
> +++ b/compat/poll/poll.c
> @@ -452,7 +452,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
>static HANDLE hEvent;
>WSANETWORKEVENTS ev;
>HANDLE h, handle_array[FD_SETSIZE + 2];
> -  DWORD ret, wait_timeout, nhandles, elapsed, orig_timeout = 0;
> +  DWORD ret, wait_timeout, nhandles, orig_timeout = 0;
>ULONGLONG start = 0;
>fd_set rfds, wfds, xfds;
>BOOL poll_again;
> @@ -618,8 +618,8 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
>
>if (!rc && orig_timeout && timeout != INFTIM)
>  {
> -  elapsed = (DWORD)(GetTickCount64() - start);
> -  timeout = elapsed >= orig_timeout ? 0 : orig_timeout - elapsed;
> +  ULONGLONG elapsed = GetTickCount64() - start;
> +  timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - elapsed);
>  }
>
>if (!rc && timeout)
> --
> 2.19.1.406.g1aa3f475f3

I like it. This still removes the warning and avoids overflow issues.

Steve

Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

[Steve Hoelzer]

On Thu, Nov 1, 2018 at 5:22 AM Johannes Sixt  wrote:
>
> Am 31.10.18 um 22:11 schrieb Steve Hoelzer via GitGitGadget:
> > From: Steve Hoelzer 
> >
> >  From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
> > 'GetTickCount64' instead of 'GetTickCount'.
> >
> > Reason: GetTickCount() overflows roughly every 49 days. Code that does
> > not take that into account can loop indefinitely. GetTickCount64()
> > operates on 64 bit values and does not have that problem.
> >
> > Note: this patch has been carried in Git for Windows for almost two
> > years, but with a fallback for Windows XP, as the GetTickCount64()
> > function is only available on Windows Vista and later. However, in the
> > meantime we require Vista or later, hence we can drop that fallback.
> >
> > Signed-off-by: Steve Hoelzer 
> > Signed-off-by: Johannes Schindelin 
> > ---
> >   compat/poll/poll.c | 10 +++---
> >   1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/compat/poll/poll.c b/compat/poll/poll.c
> > index ad5dcde439..4abbfcb6a4 100644
> > --- a/compat/poll/poll.c
> > +++ b/compat/poll/poll.c
> > @@ -18,6 +18,9 @@
> >  You should have received a copy of the GNU General Public License along
> >  with this program; if not, see <http://www.gnu.org/licenses/>.  */
> >
> > +/* To bump the minimum Windows version to Windows Vista */
> > +#include "git-compat-util.h"
> > +
> >   /* Tell gcc not to warn about the (nfd < 0) tests, below.  */
> >   #if (__GNUC__ == 4 && 3 <= __GNUC_MINOR__) || 4 < __GNUC__
> >   # pragma GCC diagnostic ignored "-Wtype-limits"
> > @@ -449,7 +452,8 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
> > static HANDLE hEvent;
> > WSANETWORKEVENTS ev;
> > HANDLE h, handle_array[FD_SETSIZE + 2];
> > -  DWORD ret, wait_timeout, nhandles, start = 0, elapsed, orig_timeout = 0;
> > +  DWORD ret, wait_timeout, nhandles, elapsed, orig_timeout = 0;
> > +  ULONGLONG start = 0;
> > fd_set rfds, wfds, xfds;
> > BOOL poll_again;
> > MSG msg;
> > @@ -465,7 +469,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
> > if (timeout != INFTIM)
> >   {
> > orig_timeout = timeout;
> > -  start = GetTickCount();
> > +  start = GetTickCount64();
> >   }
> >
> > if (!hEvent)
> > @@ -614,7 +618,7 @@ restart:
> >
> > if (!rc && orig_timeout && timeout != INFTIM)
> >   {
> > -  elapsed = GetTickCount() - start;
> > +  elapsed = (DWORD)(GetTickCount64() - start);
>
> AFAICS, this subtraction in the old code is the correct way to take
> account of wrap-arounds in the tick count. The new code truncates the 64
> bit difference to 32 bits; the result is exactly identical to a
> difference computed from truncated 32 bit values, which is what we had
> in the old code.
>
> IOW, there is no change in behavior. The statement "avoid wrap-around
> issues" in the subject line is not correct. The patch's only effect is
> that it removes Warning C28159.
>
> What is really needed is that all quantities in the calculations are
> promoted to ULONGLONG. Unless, of course, we agree that a timeout of
> more than 49 days cannot happen ;)

Yep, correct on all counts. I'm in favor of changing the commit message to
only say that this patch removes Warning C28159.

Steve

[PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

[Steve Hoelzer via GitGitGadget]

From: Steve Hoelzer 

>From Visual Studio 2015 Code Analysis: Warning C28159 Consider using
'GetTickCount64' instead of 'GetTickCount'.

Reason: GetTickCount() overflows roughly every 49 days. Code that does
not take that into account can loop indefinitely. GetTickCount64()
operates on 64 bit values and does not have that problem.

Note: this patch has been carried in Git for Windows for almost two
years, but with a fallback for Windows XP, as the GetTickCount64()
function is only available on Windows Vista and later. However, in the
meantime we require Vista or later, hence we can drop that fallback.

Signed-off-by: Steve Hoelzer 
Signed-off-by: Johannes Schindelin 
---
 compat/poll/poll.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/compat/poll/poll.c b/compat/poll/poll.c
index ad5dcde439..4abbfcb6a4 100644
--- a/compat/poll/poll.c
+++ b/compat/poll/poll.c
@@ -18,6 +18,9 @@
You should have received a copy of the GNU General Public License along
with this program; if not, see <http://www.gnu.org/licenses/>.  */
 
+/* To bump the minimum Windows version to Windows Vista */
+#include "git-compat-util.h"
+
 /* Tell gcc not to warn about the (nfd < 0) tests, below.  */
 #if (__GNUC__ == 4 && 3 <= __GNUC_MINOR__) || 4 < __GNUC__
 # pragma GCC diagnostic ignored "-Wtype-limits"
@@ -449,7 +452,8 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
   static HANDLE hEvent;
   WSANETWORKEVENTS ev;
   HANDLE h, handle_array[FD_SETSIZE + 2];
-  DWORD ret, wait_timeout, nhandles, start = 0, elapsed, orig_timeout = 0;
+  DWORD ret, wait_timeout, nhandles, elapsed, orig_timeout = 0;
+  ULONGLONG start = 0;
   fd_set rfds, wfds, xfds;
   BOOL poll_again;
   MSG msg;
@@ -465,7 +469,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
   if (timeout != INFTIM)
 {
   orig_timeout = timeout;
-  start = GetTickCount();
+  start = GetTickCount64();
 }
 
   if (!hEvent)
@@ -614,7 +618,7 @@ restart:
 
   if (!rc && orig_timeout && timeout != INFTIM)
 {
-  elapsed = GetTickCount() - start;
+  elapsed = (DWORD)(GetTickCount64() - start);
   timeout = elapsed >= orig_timeout ? 0 : orig_timeout - elapsed;
 }
 
-- 
gitgitgadget

Re: [PATCH] git-completion.bash: Add completion for stash list

[steve]

On 2018-10-07 2:08 am, Junio C Hamano wrote:

Steve  writes:


Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list` 
command:


  --name-status --oneline --patch-with-stat

Signed-off-by: Steven Fernandez 
---

This is my first patch to the project so please be excuse any process
errors.
Although, I've tried my best to follow the guidelines in
Documentation/SubmittingPatches but I'm not sure if I missed anything.


Thanks.  Will queue with manual fix-ups, but since you asked, here
are the things I'll be fixing up manually, which you may want to
avoid next time.



Thanks for accepting the patchset and the manual fixes. Thanks a lot 
also

for taking the time to explain the mistakes to avoid.

cheers,
Steve

[PATCH] git-completion.bash: Add completion for stash list

[Steve]

Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list` command:

  --name-status --oneline --patch-with-stat

Signed-off-by: Steven Fernandez 
---

This is my first patch to the project so please be excuse any process
errors.
Although, I've tried my best to follow the guidelines in
Documentation/SubmittingPatches but I'm not sure if I missed anything.

 contrib/completion/git-completion.bash | 3 +++
 1 file changed, 3 insertions(+)

diff --git contrib/completion/git-completion.bash
contrib/completion/git-completion.bash
index d63d2dffd..06ec6ca11 100644
--- contrib/completion/git-completion.bash
+++ contrib/completion/git-completion.bash
@@ -2567,6 +2567,9 @@ _git_stash ()
drop,--*)
__gitcomp "--quiet"
;;
+   list,--*)
+   __gitcomp "--name-status --oneline --patch-
with-stat"
+   ;;
show,--*|branch,--*)
;;
branch,*)
-- 
2.17.1

[PATCH] git-completion.bash: Add completion for stash list

[Steve]

Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list` command:

  --name-status --oneline --patch-with-stat

Signed-off-by: Steven Fernandez 
---

This is my first patch to the project so please be excuse any process errors. I
think my mail client messed up the line wrapping in my last mail. Hopefully this
one's better. Although, I've tried my best to follow the guidelines in
Documentation/SubmittingPatches but I'm not sure if I missed anything.

 contrib/completion/git-completion.bash | 3 +++
 1 file changed, 3 insertions(+)

diff --git contrib/completion/git-completion.bash 
contrib/completion/git-completion.bash
index d63d2dffd..06ec6ca11 100644
--- contrib/completion/git-completion.bash
+++ contrib/completion/git-completion.bash
@@ -2567,6 +2567,9 @@ _git_stash ()
drop,--*)
__gitcomp "--quiet"
;;
+   list,--*)
+   __gitcomp "--name-status --oneline --patch-with-stat"
+   ;;
show,--*|branch,--*)
;;
branch,*)
-- 
2.17.1

Re: Use of new .gitattributes working-tree-encoding attribute across different platform types

[Steve Groeger]

Lars, 

I think this proposed solution may resolve my issue.
 
 
  
 
Thanks
 Steve Groeger
 Java Runtimes Development
 IBM Hursley
 IBM United Kingdom Ltd
 Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
 Fax (44) 1962 816800
 Lotus Notes: Steve Groeger/UK/IBM
 Internet: groe...@uk.ibm.com  
   
 
Unless stated otherwise above:
 IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 
 

-Lars Schneider  wrote: -
To: Jeff King 
From: Lars Schneider 
Date: 06/28/2018 18:21
Cc: "brian m. carlson" , Steve Groeger 
, git@vger.kernel.org
Subject: Re: Use of new .gitattributes working-tree-encoding attribute across 
different platform types


> On Jun 28, 2018, at 4:34 PM, Jeff King  wrote:
> 
> On Thu, Jun 28, 2018 at 02:44:47AM +, brian m. carlson wrote:
> 
>> On Wed, Jun 27, 2018 at 07:54:52AM +, Steve Groeger wrote:
>>> We have common code that is supposed to be usable across different 
>>> platforms and hence different file encodings. With the full support of the 
>>> working-tree-encoding in the latest version of git on all platforms, how do 
>>> we have files converted to different encodings on different platforms?
>>> I could not find anything that would allow us to say 'if platform = z/OS 
>>> then encoding=EBCDIC else encoding=ASCII'.   Is there a way this can be 
>>> done?
>> 
>> I don't believe there is such functionality.  Git doesn't have
>> attributes that are conditional on the platform in that sort of way.
>> You could use a smudge/clean filter and adjust the filter for the
>> platform you're on, which might meet your needs.
> 
> We do have prior art in the line-ending code, though. There the
> attributes say either that a file needs a specific line-ending type
> (which is relatively rare), or that it should follow the system type,
> which is then set separately in the config.
> 
> I have the impression that the working-tree-encoding stuff was made to
> handle the first case, but not the second. It doesn't seem like an
> outrageous thing to eventually add.
> 
> (Though I agree that clean/smudge filters would work, and can even
> implement the existing working-tree-encoding feature, albeit less
> efficiently and conveniently).

Thanks for the suggestion Peff! 
How about this:

1) We allow users to set the encoding "auto". Example:

*.txt working-tree-encoding=auto

2) We define a new variable `core.autoencoding`. By default the value is 
UTF-8 (== no re-encoding) but user can set to any value in their Git config. 
Example:

git config --global core.autoencoding UTF-16

All files marked with the value "auto" will use the encoding defined in
`core.autoencoding`.

Would that work?

@steve: Would that fix your problem?

- Lars
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Use of new .gitattributes working-tree-encoding attribute across different platform types

[Steve Groeger]

Hi, 

Sorry for incomplete post earlier. Here is the full post:


In the latest version of git a new attribute has been added, 
working-tree-encoding. The release notes states: 

'The new "working-tree-encoding" attribute can ask Git to convert the
   contents to the specified encoding when checking out to the working
   tree (and the other way around when checking in).'
 We have been using this attribute on our z/OS systems using a version of git 
from Rocket software to convert files to EBCDIC for quite a while now. On other 
platforms (Linux, AIX etc) git ignored this attribute and therefore left the 
files in ASCII.

We have common code that is supposed to be usable across different platforms 
and hence different file encodings. With the full support of the 
working-tree-encoding in the latest version of git on all platforms, how do we 
have files converted to different encodings on different platforms?
I could not find anything that would allow us to say 'if platform = z/OS then 
encoding=EBCDIC else encoding=ASCII'.   Is there a way this can be done?
 
 
  
 
Thanks
 Steve Groeger
 Java Runtimes Development
 IBM Hursley
 IBM United Kingdom Ltd
 Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
 Fax (44) 1962 816800
 Lotus Notes: Steve Groeger/UK/IBM
 Internet: groe...@uk.ibm.com  
   
 
Unless stated otherwise above:
 IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

Use of new .gitattributes working-tree-encoding attribute across different platform types

[Steve Groeger]

I could not find anything that would allow us to say 'if platform = z/OS then 
encoding=EBCDIC else encoding=ASCII'.   Is there a way this can be done? 
 
Thanks
 Steve Groeger
 Java Runtimes Development
 IBM Hursley
 IBM United Kingdom Ltd
 Tel: (44) 1962 816911 Mobex: 279990 Mobile: 07718 517 129
 Fax (44) 1962 816800
 Lotus Notes: Steve Groeger/UK/IBM
 Internet: groe...@uk.ibm.com  
   
 
Unless stated otherwise above:
 IBM United Kingdom Limited - Registered in England and Wales with number 
741598.
 Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU 
 
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

How to delete files and directories from git commit history?

[Steve Litt]

Hi all,

I have git 2.17.1 running on Void Linux 64 bit running the Linux
4.16.9_1 kernel, not available to the public in any way (yet). I have a
repository in my project's working directory, and push to a bare
repository on the hard disk.

My project (call it myproject) had a directory (call it docs/propdir)
that was unnecessary for the project, and I've decided I don't want to
offer the files in that directory as free software. So I need to delete
docs/propdir from all commits in the repository. I did the following,
while in my working repository's myproject directory:

git filter-branch --tree-filter 'rm -rf docs/propdir' HEAD

After that command, I could git clone the working repo and then git
checkout to a commit stage that used to have the directory and files,
and they're not there. So far, so good.

But then I view all filenames from that directory that have ever been
in the project, as follows:

git cat-file --buffer --batch-all-objects \
 --batch-check='%(objecttype) %(objectname)' \
 | grep ^c | cut -d " "  -f 2 \
 | xargs -n 1 git ls-tree -r | sort | uniq \
 | grep propdir

The preceding command lists directory docs/propdir and all the files
it's ever contained. This makes me uneasy because if the filenames are
still there, I wonder if there's a route to get the files with a git
command. Second, I'd prefer that when my repo is exposed to the public,
people not know this directory and these files ever existed.

What command do I do to remove all mention of doc/propdir and its
files from my git history?

Thanks,

SteveT

Steve Litt 
June 2018 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28

RE: git question from a newbie

[Heinz, Steve]

Bryan

Thank you.  I didn't realize that when you set up a remote repository, it is 
just a folder.  I thought the fact that I had it setup as a website, was going 
to handle what I needed.
It wasn't until your email that I realized I had to use some type of client.  I 
installed Bonobo as the remote repository and bam it worked!

You are right that the info on Windows is a bit sparse.  I learned a lot and 
want to thank you again.

Steve Heinz


Steve Heinz | Lead Programmer Analyst, Information Technology
AAA Northeast | 1415 Kellum Place | Garden City, NY 11530
X8042 | T 516-535-2581 | F 516-873-2211
she...@aaanortheast.com | AAA.com


 It Pays to Belong.


-Original Message-
From: Bryan Turner 
Sent: Tuesday, June 05, 2018 6:29 PM
To: Heinz, Steve 
Cc: Git Users 
Subject: Re: git question from a newbie

On Tue, Jun 5, 2018 at 2:33 PM Heinz, Steve  wrote:
>
> Hi.
>
> I am new to Git and have read quite a few articles on it.
> I am planning on setting up a remote repository on a windows 2012 R2 server 
> and will access it via HTTPS.
> I am setting up a local repository on my desk top (others in my group will do 
> the same).
> On "server1":  I install Git and create a repository "repos".
> On "server1":  I create a dummy webpage "default.htm" and place it in the 
> repo folder.
> On "server1":  I create a web application in IIS pointing to Git
> On Server1":   change permissions so IIS_User  has access to the folders.
> On "server1":  inside the "repos" folder and right click and choose "bash 
> here"
> On "server1":   $ git init  -bare(it's really 2 hyphens)


This might create a _repository_, but it's not going to set up any Git hosting 
processing for it. You might be able to clone using the fallback to the "dumb" 
HTTP protocol (though I doubt it, with the steps you've shown) , but you won't 
be able to push.

You need handlers for git-http-backend which handle info/refs and other 
requests that are related to the Git HTTP wire protocol.[1]

Documentation for setting up Git's HTTP protocol via Apache are pretty easy to 
find[2], but IIS instructions are a bit more sparse. I don't know of any good 
ones off the top of my head. But that's your issue; your IIS setup isn't really 
a valid Git remote; it's just a Git repository with contents visible via HTTP.

[1] 
https://github.com/git/git/blob/master/Documentation/technical/http-protocol.txt
[2] 
https://github.com/git/git/blob/master/Documentation/howto/setup-git-server-over-http.txt

Bryan
The information contained in this email message is intended only for the 
private and confidential use of the recipient(s) named above, unless the sender 
expressly agrees otherwise. In no event shall AAA Northeast or any of its 
affiliates accept any responsibility for the loss, use or misuse of any 
information including confidential information, which is sent to AAA Northeast 
or its affiliates via email, or email attachment. AAA Northeast does not 
guarantee the accuracy of any email or email attachment. If the reader of this 
message is not the intended recipient and/or you have received this email in 
error, you must take no action based on the information in this email and you 
are hereby notified that any dissemination, misuse or copying or disclosure of 
this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by email and delete the 
original message.

RE: git question from a newbie

[Heinz, Steve]

Randall

Thank you, I tried it but that didn't work either.  I did find out what my 
issue was.  I need some type of client that would be setup to listen for the 
requests.

Steve


-Original Message-
From: Randall S. Becker 
Sent: Tuesday, June 05, 2018 6:19 PM
To: Heinz, Steve ; git@vger.kernel.org
Subject: RE: git question from a newbie

On June 5, 2018 5:24 PM, Steve Heinz wrote:
> I am new to Git and have read quite a few articles on it.
> I am planning on setting up a remote repository on a windows 2012 R2
server
> and will access it via HTTPS.
> I am setting up a local repository on my desk top (others in my group
> will
do
> the same).
> On "server1":  I install Git and create a repository "repos".
> On "server1":  I create a dummy webpage "default.htm" and place it in
> the repo folder.
> On "server1":  I create a web application in IIS pointing to Git
> On Server1":   change permissions so IIS_User  has access to the folders.
> On "server1":  inside the "repos" folder and right click and choose
> "bash here"
> On "server1":   $ git init  -bare(it's really 2 hyphens)
>
> On Desktop:  open Chrome and type in URL to make sure we can access it
> https://xyz/repos/default.htm
>   ** make sure you have access, no certificate issues or firewall
issues.  The
> pages shows up fine
>
> On Desktop:  install Git and create repository "repos".
> On Desktop:  right click in "repos" folder and choose "bash here"
> On Desktop:  $ git init
> On Desktop : add a folder "testProject" under the "repos" folder and
> add some files to the folder
> On Desktop:  $ git add . (will add files and folder to
working tree)
> On Desktop   $ git status   (shows it recognizes the filed
were added)
> On Desktop   $ git commit -m "test project commit"   (will stage
changes)
> On Desktop   $ git push https://xyz.domainname.com/repos master
>
> ** this is the error I get,  I have tried many different things.  I am
sure I am
> doing something stupid
> ** I have tried a bunch of variations but I always get the same error.
> It
looks
> like some type of network/permission
> ** thing but everything seems OK.
>Fatal: repository 'https://xyz.domainname.com/repos/' not found
>
> *** this is where I get the error trying to push staged items to the
remote
> repository.
> *** I have tried to clone the empty remote repository still same error
> *** I checked port 443 is opened and being used for https
> *** tried to set origin to https://xyz.domainname.com/repos; and then $git
> push origin master   (same error)
> *** I tried passing credentials to the remote server as well

Missing glue - git remote

git remote add origin https://xyz.domainname.com/repos

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442  UNIX developer since 
approximately 421664400
-- In my real life, I talk too much.



The information contained in this email message is intended only for the 
private and confidential use of the recipient(s) named above, unless the sender 
expressly agrees otherwise. In no event shall AAA Northeast or any of its 
affiliates accept any responsibility for the loss, use or misuse of any 
information including confidential information, which is sent to AAA Northeast 
or its affiliates via email, or email attachment. AAA Northeast does not 
guarantee the accuracy of any email or email attachment. If the reader of this 
message is not the intended recipient and/or you have received this email in 
error, you must take no action based on the information in this email and you 
are hereby notified that any dissemination, misuse or copying or disclosure of 
this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by email and delete the 
original message.

git question from a newbie

[Heinz, Steve]

Hi.

I am new to Git and have read quite a few articles on it.
I am planning on setting up a remote repository on a windows 2012 R2 server and 
will access it via HTTPS.
I am setting up a local repository on my desk top (others in my group will do 
the same).
On "server1":  I install Git and create a repository "repos".
On "server1":  I create a dummy webpage "default.htm" and place it in the repo 
folder.
On "server1":  I create a web application in IIS pointing to Git
On Server1":   change permissions so IIS_User  has access to the folders.
On "server1":  inside the "repos" folder and right click and choose "bash here"
On "server1":   $ git init  -bare(it's really 2 hyphens)

On Desktop:  open Chrome and type in URL to make sure we can access it
https://xyz/repos/default.htm
  ** make sure you have access, no certificate issues or firewall issues.  
The pages shows up fine

On Desktop:  install Git and create repository "repos".
On Desktop:  right click in "repos" folder and choose "bash here"
On Desktop:  $ git init
On Desktop : add a folder "testProject" under the "repos" folder and add some 
files to the folder
On Desktop:  $ git add . (will add files and folder to working 
tree)
On Desktop   $ git status   (shows it recognizes the filed were 
added)
On Desktop   $ git commit -m "test project commit"   (will stage 
changes)
On Desktop   $ git push https://xyz.domainname.com/repos master

** this is the error I get,  I have tried many different things.  I am sure I 
am doing something stupid
** I have tried a bunch of variations but I always get the same error.  It 
looks like some type of network/permission
** thing but everything seems OK.
   Fatal: repository 'https://xyz.domainname.com/repos/' not found

*** this is where I get the error trying to push staged items to the remote 
repository.
*** I have tried to clone the empty remote repository still same error
*** I checked port 443 is opened and being used for https
*** tried to set origin to https://xyz.domainname.com/repos; and then $git push 
origin master   (same error)
*** I tried passing credentials to the remote server as well


Any ideas would be greatly appreciated.
Thanks
Steve



The information contained in this email message is intended only for the 
private and confidential use of the recipient(s) named above, unless the sender 
expressly agrees otherwise. In no event shall AAA Northeast or any of its 
affiliates accept any responsibility for the loss, use or misuse of any 
information including confidential information, which is sent to AAA Northeast 
or its affiliates via email, or email attachment. AAA Northeast does not 
guarantee the accuracy of any email or email attachment. If the reader of this 
message is not the intended recipient and/or you have received this email in 
error, you must take no action based on the information in this email and you 
are hereby notified that any dissemination, misuse or copying or disclosure of 
this communication is strictly prohibited. If you have received this 
communication in error, please notify us immediately by email and delete the 
original message.

Re: [ANNOUNCE] Git for Windows 2.14.2(3)

[Steve Hoelzer]

Johannes,

On Mon, Oct 16, 2017 at 5:57 AM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hi Steve,
>
> On Sun, 15 Oct 2017, Johannes Schindelin wrote:
>
>> On Fri, 13 Oct 2017, Steve Hoelzer wrote:
>>
>> > On Thu, Oct 12, 2017 at 5:53 PM, Johannes Schindelin
>> > <johannes.schinde...@gmx.de> wrote:
>> > >
>> > > It is my pleasure to announce that Git for Windows 2.14.2(3) is
>> > > available from:
>> > >
>> > > https://git-for-windows.github.io/
>> > >
>> > > Changes since Git for Windows v2.14.2(2) (October 5th 2017)
>> > >
>> > > New Features
>> > >
>> > >   * Comes with Git LFS v2.3.3.
>> >
>> > I just ran "git update" and afterward "git version" reported
>> > 2.14.2(3), but "git lfs version" still said 2.3.2.
>> >
>> > I also uninstalled/reinstalled Git for Windows and LFS is still 2.3.2.
>>
>> Ah bummer. I forgot to actually update it in the VM where I build the
>> releases :-(
>>
>> Will work on it tomorrow.
>
> I'll actually use this opportunity to revamp a part of Git for Windows'
> release engineering process to try to prevent similar things from
> happening in the future.
>
> Also, cURL v7.56.1 is slated to be released in exactly one week, and I
> have some important installer work to do this week, so I'll just defer the
> new Git for Windows version tentatively to Monday, 23rd.
>
> Git LFS users can always install Git LFS v2.3.3 specifically in the
> meantime, or use Git for Windows' snapshot versions
> (https://wingit.blob.core.windows.net/files/index.html).

Sounds like a good plan.

I think I have successfully updated to LFS 2.3.3 by copying the new
git-lfs.exe into C:\Program Files\Git\mingw64\bin. Is that right way
to do it?

Thanks,
Steve

Re: [ANNOUNCE] Git for Windows 2.14.2(3)

[Steve Hoelzer]

Johannes,

On Thu, Oct 12, 2017 at 5:53 PM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Dear Git users,
>
> It is my pleasure to announce that Git for Windows 2.14.2(3) is available 
> from:
>
> https://git-for-windows.github.io/
>
> Changes since Git for Windows v2.14.2(2) (October 5th 2017)
>
> New Features
>
>   * Comes with Git LFS v2.3.3.

I just ran "git update" and afterward "git version" reported
2.14.2(3), but "git lfs version" still said 2.3.2.

I also uninstalled/reinstalled Git for Windows and LFS is still 2.3.2.

Steve

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.2(2)

[Steve Hoelzer]

On Thu, Oct 5, 2017 at 3:22 PM, Lars Schneider <larsxschnei...@gmail.com> wrote:
>
>> On 05 Oct 2017, at 22:02, Johannes Schindelin <johannes.schinde...@gmx.de> 
>> wrote:
>>
>> Dear Git users,
>>
>> It is my pleasure to announce that Git for Windows 2.14.2(2) is available 
>> from:
>>
>>   https://git-for-windows.github.io/
>>
>> Changes since Git for Windows v2.14.2 (September 26th 2017)
>>
>> New Features
>>
>>  * Comes with BusyBox v1.28.0pre.16467.b4c390e17.
>>  * Comes with Git LFS v2.3.2.
>
> Just a heads-up:
> Git LFS 2.3.2 contains a bug in the `git lfs clone` and `git lfs pull` calls:
> https://github.com/git-lfs/git-lfs/issues/2649
>
> I expect 2.3.3 to be out soonish.

It's out now.

Steve

Bug - Dirty submodule differences between OSX/Ubuntu

[Steve Kallestad]

Referencing: https://gitlab.com/python-mode-devs/python-mode/issues/36

I reported a bug because when adding the python-mode repo as a
submodule in my project, it shows as "dirty".

The maintainers of that module reported back that my bug cannot be reproduced.

I upgraded my local install to 2.13.2 on OSX El Capitan.

I tried to re-create the issue, and did so successfully.

I created a docker container using ubuntu:latest as the base,
installed git and tried to recreate the issue.

git on ubuntu does not show the submodule as dirty.

I upgraded ubuntu's git to 2.13.2 and git still does not show the
submodule as dirty.

Here is how to reproduce this problem:

mkdir test
cd test
git init
git submodule add https://gitlab.com/python-mode-devs/python-mode.git
python-mode.el
git commit -m 'initial commit'
git status

On ubuntu:
On branch master
nothing to commit, working tree clean

On OSX:
On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)
  (commit or discard the untracked or modified content in submodules)

modified:   python-mode.el (modified content)

no changes added to commit (use "git add" and/or "git commit -a")

---
change into the submodule directory and run status
cd python-mode.el
git status

On ubuntu:
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

On OSX:
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

deleted:EXTENSIONS

no changes added to commit (use "git add" and/or "git commit -a")

---
This is a bug because the upstream repo maintainers cannot fix the
problem if they cannot see it.  dirty/clean reporting  should be the
consistent across all operating systems.

Re: [PATCH] rebase -i: reread the todo list if `exec` touched it

[Steve Hicks]

On Wed, Apr 26, 2017 at 12:17 PM, Johannes Schindelin
 wrote:
> From: Stephen Hicks 
>
> In the scripted version of the interactive rebase, there was no internal
> representation of the todo list; it was re-read before every command.
> That allowed the hack that an `exec` command could append (or even
> completely rewrite) the todo list.
>
> This hack was broken by the partial conversion of the interactive rebase
> to C, and this patch reinstates it.
>
> We also add a small test to verify that this fix does not regress in the
> future.
>
> Signed-off-by: Stephen Hicks 
> Signed-off-by: Johannes Schindelin 

Thanks for shepherding this through, Johannes!

For context on this "hack", I have a script [1] that allows passing
multiple branches at once (or all branches beneath a given root).  It
rewrites the todo file with some extra operations, like "branch",
"push", and "pop", allows editing the modified todo, and then rewrites
back to exec's.  The "branch" operation, in particular, appends an
"exec git checkout $branch; git reset --hard $commit" to the end of
the todo, so that no branches are moved until after all rebases are
successful.  I've found this multi-branch rebase workflow to be very
productive, and have been missing it the last few months, so I'm
looking forward to it working again soon.

[1] https://github.com/shicks/git-ir

Re: On a personal note

[Steve Hoelzer]

On Thu, Sep 3, 2015 at 5:00 AM, Johannes Schindelin
<johannes.schinde...@gmx.de> wrote:
> Hey all,
>
> yes, it is true: since mid-August I am working for Microsoft. Over a
> year ago, I got into contact with the Visual Studio Online group at
> Microsoft, of which I am now a happy member. A large part of my mission
> is to improve the experience of Git for Windows. This is very exciting
> to me: I finally can focus pretty much full time on something that I
> could only address in my spare time previously.

This is great news for GfW users like me and git in general.
Congratulations, Johannes!

Steve
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git checkout resets modified files

[Steve Heyns]

git checkout resets modified files

Version git  2.5.0,

Description:
I was automating a process that would pull and switch to another
branch when I stumbled across this. I have not been able to emulate
this from command line but using go (or I imagine other languages are
similar) if you execute a command like

exec.Command(git,checkout,)

A checkout with the branch parameter but the branch parameter is empty.

The result is git resets the the repository, modified files are reset
back to original state without warning.

I would expect the behavior should be the same as a git checkout command

Has anyone else seen something like this ? For myself the solution was
to simply suppress passing in the revision as a third argument if the
revision was empty. But this does appear to be an off behavior.

Thanks
Nz
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] userdiff: support C# async methods and correct C# keywords

[Steve Hoelzer]

On Fri, Jun 6, 2014 at 12:34 PM, Junio C Hamano gits...@pobox.com wrote:
 Steve Hoelzer shoel...@gmail.com writes:

 instanceof() is listed as keywords, but there is no such thing (it is
 in Java, though); in C# we use typeof(), 'is', and 'as for similar
 purposes

 You would need to balance the quotes around as ;-)

Indeed. Doh.

 But reading the patch again after noticing that you have () after
 typeof but not after is/as, I am not sure if the change proposed
 here is even correct for the latter two.  I do not speal c-sharp, so
 I asked http://msdn.microsoft.com/en-us/library/cscsdfbt.aspx for
 some examples and here are what I found:

 Type t = typeof(ExampleClass)
 Base b = derived as Base;
 if (obj is MyObject) ...

 Unlike the control-flow keywords (e.g. do/while/for/...), do they
 typically appear at the beginning of lines?

No, I would never expect to see 'is' or 'as' at the beginning of a line.

 Isn't the purpose of these !^[ \t]* patterns to reject lines that
 begin with the language keywords that do not start functions, so
 listing a keyword that does not usually appear at the beginning of
 line looks like a churn that is not useful.

Not sure about the purpose of those lines, but I think you're correct.

Steve

 diff --git a/userdiff.c b/userdiff.c
 index fad52d6..96eda6c 100644
 --- a/userdiff.c
 +++ b/userdiff.c
 @@ -134,9 +134,9 @@ PATTERNS(cpp,
|[-+*/%^|=!]=|--|\\+\\+|=?|=?||\\|\\||::|-\\*?|\\.\\*),
  PATTERNS(csharp,
/* Keywords */
 -  !^[ 
 \t]*(do|while|for|if|else|instanceof|new|return|switch|case|throw|catch|using)\n
 +  !^[ 
 \t]*(do|while|for|foreach|if|else|typeof|is|as|new|return|switch|case|default|throw|try|catch|using)\n
/* Methods and constructors */
 -  ^[ 
 \t]*(((static|public|internal|private|protected|new|virtual|sealed|override|unsafe)[
  \t]+)*[][@.~_[:alnum:]]+[ \t]+[@._[:alnum:]]+[ \t]*\\(.*\\))[ \t]*$\n
 +  ^[ 
 \t]*(((static|public|internal|private|protected|new|virtual|sealed|override|unsafe|async)[
  \t]+)*[][@.~_[:alnum:]]+[ \t]+[@._[:alnum:]]+[ \t]*\\(.*\\))[ \t]*$\n
/* Properties */
^[ 
 \t]*(((static|public|internal|private|protected|new|virtual|sealed|override|unsafe)[
  \t]+)*[][@.~_[:alnum:]]+[ \t]+[@._[:alnum:]]+)[ \t]*$\n
/* Type definitions */
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] userdiff: support C# async methods and correct C# keywords

[Steve Hoelzer]

On Thu, Jun 5, 2014 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
 Sup Yut Sum ch3co...@gmail.com writes:

 async is in C# 5.0
 foreach is in C# 1.0

 instanceof is in Java. The similar keywords are typeof, is, as in C# 1.0

 This one made me read it twice, until I realized you meant

 instanceof() is listed as keywords, but there is no such thing
 (it is in Java, though); in C# we use typeof() for similar
 purposes

The original email was a bit hard to parse. Junio's clarification left
out the C# keywords 'is' and 'as'. I suggest phrasing it like this:

instanceof() is listed as keywords, but there is no such thing (it is
in Java, though); in C# we use typeof(), 'is', and 'as for similar
purposes
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] environment: enable core.preloadindex by default

[Steve Hoelzer]

On Mon, Jun 2, 2014 at 3:01 PM, Karsten Blees karsten.bl...@gmail.com wrote:
 Git for Windows users may want to try core.fscache=true as well [1]. This 
 eliminates the UAC penalties for repositories located on the Windows system 
 drive [2].

 [1] https://github.com/msysgit/git/pull/94
 [2] https://code.google.com/p/msysgit/issues/detail?id=320

Thanks for the tip! I didn't know about fscache, but I'll definitely
give it a try. Is there a reason it is not turned on by default in Git
for Windows?

Steve
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] environment: enable core.preloadindex by default

[Steve Hoelzer]

There is consensus that the default should change because it will
benefit nearly all users (some just a little, but some a lot).
See [1] and replies.

[1]: 
http://git.661346.n2.nabble.com/git-status-takes-30-seconds-on-Windows-7-Why-tp7580816p7580853.html

Signed-off-by: Steve Hoelzer shoel...@gmail.com
---
 Documentation/config.txt | 4 ++--
 environment.c| 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1932e9b..4b3d965 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -613,9 +613,9 @@ core.preloadindex::
 +
 This can speed up operations like 'git diff' and 'git status' especially
 on filesystems like NFS that have weak caching semantics and thus
-relatively high IO latencies.  With this set to 'true', Git will do the
+relatively high IO latencies.  When enabled, Git will do the
 index comparison to the filesystem data in parallel, allowing
-overlapping IO's.
+overlapping IO's.  Defaults to true.

 core.createObject::
  You can set this to 'link', in which case a hardlink followed by
diff --git a/environment.c b/environment.c
index 5c4815d..1c686c9 100644
--- a/environment.c
+++ b/environment.c
@@ -71,7 +71,7 @@ unsigned long pack_size_limit_cfg;
 char comment_line_char = '#';

 /* Parallel index stat data preload? */
-int core_preload_index = 0;
+int core_preload_index = 1;

 /* This is set by setup_git_dir_gently() and/or git_default_config() */
 char *git_work_tree_cfg;
-- 
1.9.0.msysgit.0
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html