[PATCH] git-completion.bash: Add completion for stash list
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
[PATCH] git-completion.bash: Add completion for stash list
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
Re: [PATCH] git-completion.bash: Add completion for stash list
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
Bug - Dirty submodule differences between OSX/Ubuntu
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
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: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.2(2)
On Thu, Oct 5, 2017 at 3:22 PM, Lars Schneider wrote: > >> On 05 Oct 2017, at 22:02, Johannes Schindelin >> 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
Re: [ANNOUNCE] Git for Windows 2.14.2(3)
Johannes, On Thu, Oct 12, 2017 at 5:53 PM, Johannes Schindelin 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: [ANNOUNCE] Git for Windows 2.14.2(3)
Johannes, On Mon, Oct 16, 2017 at 5:57 AM, Johannes Schindelin 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 >> > 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
git question from a newbie
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: git question from a newbie
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.
RE: git question from a newbie
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.
How to delete files and directories from git commit history?
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
Use of new .gitattributes working-tree-encoding attribute across different platform types
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
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
Re: Use of new .gitattributes working-tree-encoding attribute across different platform types
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
"git checkout" resets modified files
"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: On a personal note
On Thu, Sep 3, 2015 at 5:00 AM, Johannes Schindelin 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
[PATCH] environment: enable core.preloadindex by default
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 --- 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
Re: [PATCH] environment: enable core.preloadindex by default
On Mon, Jun 2, 2014 at 3:01 PM, Karsten Blees 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
Re: [PATCH 1/2] userdiff: support C# async methods and correct C# keywords
On Thu, Jun 5, 2014 at 5:59 PM, Junio C Hamano wrote: > Sup Yut Sum 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 1/2] userdiff: support C# async methods and correct C# keywords
On Fri, Jun 6, 2014 at 12:34 PM, Junio C Hamano wrote: > Steve Hoelzer 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
How to convert SVN tags to git tags?
After converting from SVN to git using git svn init + git svn fetch, my SVN tags appear as remote branches in git. I find many suggestions to convert these to git tags by calling git tag -a but this gives something like this C4 | V T -> C3 -> C2 | V C1 that is, I still have a branch with only 1 commit C3 and I have a tag T pointing to that commit. Also, T will have a current timestamp. I'd prefer to get C4 | V T -> C2 | V C1 where T takes the commit message and date from C3. How can I achieve that? Steve
How do I get rid of unneeded objects?
After deleting a branch or amending a commit I still have orphaned objects in the repository: $ mkdir repo; cd repo $ git init $ date > foo; git add foo; git commit -mmsg1 $ date > foo; git add foo; git commit -mmsg2 $ git checkout -b branch-1 HEAD^ Switched to a new branch 'branch-1' $ git commit --allow-empty -mbranch-1 [branch-1 84cfad2] branch-1 $ git log --oneline 84cfad2 branch-1 09fdcb1 msg1 $ find .git/objects/ -type f | sort | nl 1 .git/objects/09/fdcb1cb7d5642874bd642ce5685ac0bebd116c 2 .git/objects/41/d9ceb271c5e72f8a94a38dc4852ab501566bd1 3 .git/objects/4f/c6596065dd08ebc62ce0728e2407d58dbde7e1 4 .git/objects/5f/c4d7af12460d774be720f8761da0be2595404d 5 .git/objects/84/cfad2cea2ae3f7a67530d5c596853f656e68d9 6 .git/objects/a1/5faea60776cd537c4ef527f08caff48ff6c86b 7 .git/objects/c8/c0278da7cf96d86c5881f3884b5015deee7113 These objects are 2 files, 2 trees, and 3 commits. If now delete the branch again, I'd like to have the unneeded commit deleted, but: $ git checkout master Switched to branch 'master' $ git branch -D branch-1 Deleted branch branch-1 (was 84cfad2). $ git reflog expire --all $ git prune $ find .git/objects/ -type f | sort | nl 1 .git/objects/09/fdcb1cb7d5642874bd642ce5685ac0bebd116c 2 .git/objects/41/d9ceb271c5e72f8a94a38dc4852ab501566bd1 3 .git/objects/4f/c6596065dd08ebc62ce0728e2407d58dbde7e1 4 .git/objects/5f/c4d7af12460d774be720f8761da0be2595404d 5 .git/objects/84/cfad2cea2ae3f7a67530d5c596853f656e68d9 <-- [1] 6 .git/objects/a1/5faea60776cd537c4ef527f08caff48ff6c86b 7 .git/objects/c8/c0278da7cf96d86c5881f3884b5015deee7113 Why is [1] not deleted? It seems reflog still knows about the deleted branch, and probably this is the reason git keeps the referenced commit: $ git reflog c8c0278 HEAD@{0}: checkout: moving from branch-1 to master 84cfad2 HEAD@{1}: commit: branch-1 09fdcb1 HEAD@{2}: checkout: moving from master to branch-1 c8c0278 HEAD@{3}: commit: msg2 09fdcb1 HEAD@{4}: commit (initial): msg1 Also, git gc, mentioned in the man page for git-reflog does not help. And I see similar things when amending a commit, where the old commit object is kept. How can one get rid of this? Steve
Why does git cvsimport create a branch named origin?
After converting my CVS repositories from CVS to git using git cvsimport -a -m -A authors repo I see that two branches, master and origin are created: $ cd repo $ git branch * master origin What is the branch origin for? Should I delete it? Steve
Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues
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
Re: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues
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
sending changesets from the middle of a git tree
Just to confirm a recent answer to questions on lkml ... 1) There is no way to send a particular changeset from the "middle" of a set from one tree to another, without exporting it as a patch or rebuilding a new git tree. I have two changesets that, after testing last week, I now consider more important to send upstream than the few earlier and later changesets. If I export those two changesets as patches, and send them on. presumably I lose the changset comments etc. and then when the upstream tree is merged back, it might look a little odd in the changeset history. 2) There is no way to update the comment field of a changeset after it goes in (e.g. to add a bugzilla bug number for a bug that was opened just after the fix went in). 3) There is no way to do a test commit of an individual changeset against a specified tree (to make sure it would still merge cleanly, automatically). Are there easier ways to do any of these? - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues
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