Re: [git-users] Git for Windows and .NET?
https://www.nuget.org/packages/Git-Windows-Minimal/ says: Minimal Git for Windows is a reduced sized package designed to support > application integration (like integrated development environments, graph > visualizers, etc.) where full console support (colorization, pagniation, > etc.) is not needed. Additionally, non-critical packages such as Git-Bash, > Git-Gui, PERL, Python, and Tcl are excluded from Minimal Git for Windows to > reduce the package size. Mark Waite On Thu, Apr 4, 2019 at 2:43 PM Michael Powell wrote: > Hello, > > What's the difference, Git-Windows-Minimal versus GitForWindows? In > particular as NuGet packages. I do not see any .NET assemblies there? > It appears to be a self-contained git environment? Or am I missing > something? > > Thanks! > > Cheers, > > Michael W Powell > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Using Jenkins, how to commit and push a code from local workspace (Windows) to Git Branch after every build executed in Jenkins
If doing it from within Pipeline and using an ssh connection to the remote repository, you can use the instructions at: https://stackoverflow.com/questions/44377238/use-ssh-credentials-in-jenkins-pipeline-with-ssh-scp-or-sftp#_=_ If you're using a Freestyle project, there is a "Git Publisher" provided by the git plugin that can allow you to push changes to the repository. You may also find that pushing changes to the remote repository from a Jenkins job is more complicated than you want. Jenkins generally watches a repository for changes and builds on each change. When Jenkins is also used to push changes, then that can cause a never ending cycle of builds where Jenkins detects a change, performs a build, pushes a change from that build, then detects a change and starts again. With Freestyle projects there are (error-prone) techniques to ignore certain commits by author or by text in the commit message. Those same techniques are not universally available in Pipeline. Mark Waite On Tue, Mar 19, 2019 at 8:16 AM Eyal Goren wrote: > You mean how to do it in pipeline? > > On Tue, Mar 19, 2019, 2:46 PM >> Hi Everybody, >> >> Using Jenkins, how to commit and push a code from local workspace >> (Windows) to Git Branch after every build executed in Jenkins >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Thanks! Mark Waite -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] how to check if a new git tag is pushed to a git repo?
Sorry, but I don't have further pointers than those links (and google searches which find things like https://developer.github.com/webhooks/#events which mentions that the create event is notified each time a branch or tag is created) Mark Waite On Sat, Apr 28, 2018 at 5:57 PM Gopichand Nakkala wrote: > Mark: > > Any pointers on how to trigger the hook based on when a new tag is > pushed?I can't find much details on how to do this in the below links > shared? > https://developer.github.com/webhooks/creating/ or > https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html > > On Sat, Apr 28, 2018 at 4:02 PM, Gopichand Nakkala > wrote: > >> Hi >> >> I am trying to find an automatic way to check if any new tag is pushed to >> a git repo or not?what options are there in git to figure this out? >> >> lets say I have the following tags on a git repo, now when a new tag >> "TAG1620R53_REL_16_30_52_7" >> is pushed I want to detect it and trigger a script..how to do that? >> >> git tag --list 'TAG1620R53*' --sort=taggerdate >> >> TAG1620R53_REL_16_30_6 >> >> TAG1620R53_REL_16_30_19_2 >> >> TAG1620R53_REL_16_30_19_4 >> >> TAG1620R53_REL_16_30_27_4 >> >> TAG1620R53_REL_16_30_27_4_CORRECTED >> >> TAG1620R53_REL_16_30_36 >> >> TAG1620R53_REL_16_30_43 >> >> TAG1620R53_REL_16_30_43_2 >> >> TAG1620R53_REL_16_30_47_2 >> >> TAG1620R53_REL_16_30_47_3 >> >> TAG1620R53_REL_16_30_52_3 >> >> TAG1620R53_REL_16_30_52_6 >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Git for human beings" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/git-users/ExFJ07zr62o/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> git-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] how to check if a new git tag is pushed to a git repo?
If you control the git server and have shell access to it, then you can use a "hook" script as described in the git docs at https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks . If you are using a hosted git server (like GitHub, Bitbucket, Assembla, Visual Studio, etc.), investigate the provider's documentation on webhooks. Most provide webhook based notification of changes. For example, https://developer.github.com/webhooks/creating/ or https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html Mark Waite On Sat, Apr 28, 2018 at 5:02 PM Gopichand Nakkala wrote: > Hi > > I am trying to find an automatic way to check if any new tag is pushed to > a git repo or not?what options are there in git to figure this out? > > lets say I have the following tags on a git repo, now when a new tag > "TAG1620R53_REL_16_30_52_7" > is pushed I want to detect it and trigger a script..how to do that? > > git tag --list 'TAG1620R53*' --sort=taggerdate > > TAG1620R53_REL_16_30_6 > > TAG1620R53_REL_16_30_19_2 > > TAG1620R53_REL_16_30_19_4 > > TAG1620R53_REL_16_30_27_4 > > TAG1620R53_REL_16_30_27_4_CORRECTED > > TAG1620R53_REL_16_30_36 > > TAG1620R53_REL_16_30_43 > > TAG1620R53_REL_16_30_43_2 > > TAG1620R53_REL_16_30_47_2 > > TAG1620R53_REL_16_30_47_3 > > TAG1620R53_REL_16_30_52_3 > > TAG1620R53_REL_16_30_52_6 > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Third way to create a bare repository?
On Mon, Feb 12, 2018 at 9:28 AM wrote: > I'm a newbie to git, but from what I've learned so far, I want to have > both a > working git repository and a "bare" git repository for some development I > want > to do. > > I've seen two ways to create a bare repository (iirc, init --bare ... and > clone --bare ...) , and I've had a few problems using those so far. > > I'm wondering if a third way will work--I would propose to copy the entire > contents of my working repository to another directory, then delete all > that > is not under the .git directory, and then rename the .git directory to git. > > That would probably work, but I think there is an easier way to resolve your concern for losing work from your working repository. Create a bare repository cloned from the origin repository $ mkdir -p ~/git/bare $ cd ~/git/bare $ git clone --bare git@server:directory/repo.git Create a working repository cloned from the origin repository (reference the bare repository if the repository is large) $ mkdir -p ~/git $ cd ~/git $ git clone --reference ~/git/bare/repo.git git@server:directory/repo.git Add the bare repository as a remote of the working repository $ cd ~/git/repo $ git remote add bare ~/git/bare/repo.git Make changes in the working repository $ git checkout -b feature-branch $ git commit -m "Your message" your-file Push changes to both the origin repository and the bare repository $ git push origin --set-upstream feature-branch $ git push bare That sequence keeps a separate local git repository in the ~/git/bare/ directory in addition to the origin repository. However, it has the negative that the separate copy is only updated if you "git push bare". I've used the technique with large repositories that I didn't want to clone entirely from the origin after making some major mistake in the working repository. Mark Waite AFAICT, this should work (although maybe I need to completely remove the > .git > directory level and move it to the parent). > > In other words, assume I have: > >.../scite with a work space and a .git directory > > I would plan to copy this to: > >.../back/scite with no workspace but a git directory > > or: > >.../back/scite with no workspace and the content of the git directory > here > (no git subdirectory) > > Comments? > > Am I setting a trap for myself? > > Some background: > > I am paranoid about losing work, and having a hidden directory (.git) > where I > am doing development makes me more paranoid (in the past, I have done > things > like delete directories with hidden subdirectories or files because I > forgot > about the hidden stuff). So, as I develop, after I commit to the > .../scite/.git repository, I plan to push to the .../back/scite repository. > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Cache credentials in my terminal session, not for a user account
Thanks Tim for that introduction to using ssh-agent as a wrapper for a shell command. I had never seen that technique. Very nice! Mark Waite On Thu, Feb 8, 2018 at 1:29 PM Timothy Rice wrote: > Oops, sorry I didn't notice Mark's response before replying :D > > ~ Tim > > > > If you clone over ssh (ssh://username@hostname/repopath or user@hostname > : > > repopath), then you can use a passphrase protected private key for that > ssh > > connection. With a passphrase protected private key, only those who know > > the passphrase can use it. If you want to enter the passphrase only once > > per session, you can use "ssh-agent" to remember the passphrase for the > > duration of a session. > > > > $ eval $(ssh-agent) > > $ ssh-add ~/.ssh/id_rsa > > $ git clone username@hostname:repopath > > > > If you use http, you can refer to > > https://help.github.com/articles/caching-your-github-password-in-git/ > for > > hints on "credential helpers". > > > > Mark Waite > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Cache credentials in my terminal session, not for a user account
On Thu, Feb 8, 2018 at 3:11 AM Maciej Ł wrote: > Hi! How can I cache GIT credentials in scope of a terminal session? My use > case is the following. Me and other developers share a single account on a > remote Linux machine. In a home directory we share a GIT project with > application-specific configuration files. Sometimes we need to pull/push > changes. I don't want to type my username and password every time. I also > don't want to cache my credentials in such a way that other developers > having simultaneous SSH sessions use my credentials to perform GIT > operations. How can I achieve this? > > If you clone over ssh (ssh://username@hostname/repopath or user@hostname: repopath), then you can use a passphrase protected private key for that ssh connection. With a passphrase protected private key, only those who know the passphrase can use it. If you want to enter the passphrase only once per session, you can use "ssh-agent" to remember the passphrase for the duration of a session. $ eval $(ssh-agent) $ ssh-add ~/.ssh/id_rsa $ git clone username@hostname:repopath If you use http, you can refer to https://help.github.com/articles/caching-your-github-password-in-git/ for hints on "credential helpers". Mark Waite Maciej Ł. > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Official documentation about repository size limits for a self hosted server
Git does not have a limitation of 2 GB for each repo. I don't think you'll find official information about the limits on repository size except in the context of specific use cases (like gitweb, GitHub, BitBucket, Gitlab, etc.) At a previous employer, we regularly worked with a repository that was over 10 GB. Performance suffered in various ways, but that was the situation and we worked with it. See https://stackoverflow.com/questions/984707/what-are-the-file-limits-in-git-number-and-size for a good summary and many links to other information sources on large git repositories. Mark Waite On Wed, Dec 27, 2017 at 1:08 AM wrote: > Hello everyone, > > I am trying to find some official information about the limit size of a > repository. As I have read git has a limitation of 2GB for each repo > because if you increment the size it starts to decrease the overall > performance. But this limitation is mainly explained in the web based > servers like GitHub or Bitbucket Cloud. So my main question is if this also > happens *when you use a self hosted server* like Bitbucket Server or > GitHub enterprise. However, what I am trying to find is official > documentation that explains this. > > Greetings > > Antonio > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Where does git on windows store the repositories?
If the repository is a working directory (not bare), then the repository is stored in the ".git" directory. If the repository is bare, then it is stored in the directory itself. Bare repositories typically are used on git servers, rather than on development desktops. Mark Waite On Thu, Oct 26, 2017 at 11:50 AM Greg Quintana wrote: > Where does git on windows store the repositories? > > Thanks > Greg Quintana > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git branch merge strategies
Yes, your simplification expresses what I was trying to achieve. I specifically merged from master to one so that one could be tested with the merge from master. The subsequent merge from one to master was to have master include a commit which shows one merged into it. Same pattern for master to two, then two to master. I assumed (possibly incorrectly) that there would be conflicts to resolve in either merging one or two or both to master. I assumed that resolving the conflicts would be easier if there were incremental steps which represented the merges. If there are no conflicts, then isn't the ultimate simplification to merge both 1 and two to master with a single command? $ git checkout master $ git merge one two That will perform an octopus merge and create a merge which has 3 parents, rather than the more common 2 parents. Mark Waite On Wed, Jul 26, 2017 at 4:26 PM Igor Djordjevic wrote: > Hi Mark, > > > On Tuesday, July 25, 2017 at 2:58:21 PM UTC+2, Mark Waite wrote: >> >> You might consider a series of steps to perform the merge. Some of the >> steps might include: >> >>1. Merge from master to branch one so that the diffs between branch >>one and master are only changes on branch one, test the resulting merge. >>Review and understand the remaining differences between master and branch >>one >>2. Merge from master to branch two so that the diffs between branch >>two and master are only changes on branch two, test the resulting merge. >>Review and understand the remaining differences between master and branch >>two >>3. Merge from branch one to master, test the resulting merge. This >>resolves branch one into master >>4. Merge from master to branch two, test the resulting merge >>5. Merge from branch two to master, test the resulting merge. This >>resolves branch two into master >> >> I`m having some issues following the steps - either I`m missing > something, or they seem unnecessarily complicated...? > > Basically, steps (3) and (5) look like no-operations (fast-forward > merges), once steps (1) and (4) are done. There should be nothing in there > that you can test that you haven`t already tested in steps (1) and (4), > still you propose doing so? > > But then again, for steps (1) and (2) you say to merge from "master" to > branch "one" (or "two"), *"**so that the diffs between branch one and > master are only changes on branch one"* (or two), and that confuses me > the most -- what the diff will show should depends on which side of the > merge you`re looking from, isn`t it? > > So if you merge "master" to "one" and you look from "master": > > $ git checkout one > $ git merge master > # resolve conflicts, test, add, commit merge > $ git diff master one > > ..., indeed, the merge commit will show diff as changes introduced only by > branch "one" - but if you look from perspective of branch "one": > > $ git diff one^ one > > ... diff will show all changes introduced by "master" branch instead > (we`re actually using the second last commit on branch "one" for > comparison, as the last one _is_ the merge commit, thus no difference). > > By default, if we just show the merge commit on branch "one": > > $ git show one > > ... Git produces a "combined" diff, showing changes in comparison to all > merge parents (meaning "master" and "one" in the first case), and it > doesn`t matter which branch you merge into the other, the merge > outcome/result is the same. > > So, unless I`m missing some point, here`re the illustrated steps, for > easier comprehension. Starting situation would look something like this: > > O one > / > ---O---O---O---O---O master > \ > O---O---O---O---O---O---O---O---...---O two > > ... but to make it easier to follow, I`ll simplify it to this: > > O one > / > ---O---O---O master > \ > O two > > > Now, we proceed with the steps you described: > > (*1*) $ git checkout one > $ git merge master > # resolve conflicts, test, add > $ git commit # merge commit M1 > > O---M1 one > / / > ---O---O---O master > \ > O two > > (*2*) $ git checkout two > $ git merge master > # resolve conflicts, test, add > $ git commit # merge commit M2 > > O---M1 one > / / > ---O---O---O master >
Re: [git-users] Git branch merge strategies
You might consider a series of steps to perform the merge. Some of the steps might include: 1. Merge from master to branch one so that the diffs between branch one and master are only changes on branch one, test the resulting merge. Review and understand the remaining differences between master and branch one 2. Merge from master to branch two so that the diffs between branch two and master are only changes on branch two, test the resulting merge. Review and understand the remaining differences between master and branch two 3. Merge from branch one to master, test the resulting merge. This resolves branch one into master 4. Merge from master to branch two, test the resulting merge 5. Merge from branch two to master, test the resulting merge. This resolves branch two into master Mark Waite On Tue, Jul 25, 2017 at 6:38 AM JNickVA wrote: > I have recently been put in charge of a code repository that contains a > MASTER and several branches. My task is to try to merge the root and the > top two most frequently used branches into a new repository. I face two > problems: the branches have not been merged to the root in a long time, and > the root is the code for a production website. I am looking for a useful > strategy for merging the branches into the root, or MASTER, branch. > > *Branch One* > <https://stackoverflow.com/documentation/review/changes/150671#> > This branch is 7 commits ahead, 35 commits behind master. > > >- >*Branch Two* ><https://stackoverflow.com/documentation/review/changes/150671#> ><https://stackoverflow.com/documentation/review/changes/150671#> >This branch is 760 commits ahead, 7 commits behind master. > > >One of the branches I wish to merge to the existing root is 7 commits >ahead, 35 commits behind master. The other branch is 760 commits ahead, 7 >commits behind master. What I'm looking for is a strategy for performing >the merge. There are no meaningful tags on any of the existing branches. > >Thanks > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Keeping Timestamps
On Mon, Jun 5, 2017 at 3:31 PM wrote: > Hi, Is there an option or version of GIT with a database that keeps the > last file stamp of committed files?? > > It depends what you mean by "file stamp". If "file stamp" means a cryptographically strong checksum of the contents of the file, then yes, that is retained in all versions of git. If "file stamp" means the time of the most recent commit, then yes, the time of the most recent commit is recorded in the commit log by all versions of git. If "file stamp" means the names of the files included in the most recent commit, then yes, that is recorded in the commit log by all versions of git. If "file stamp" means that files have their create date or modify date (or other date related attribute) set to the date of the most recent commit on checkout of that file, then no, that is not done in any version of git. Refer to https://stackoverflow.com/questions/2179722/checking-out-old-file-with-original-create-modified-timestamps for more details. Mark Waite > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: staging or no staging in system files?
On Friday, May 5, 2017 at 10:28:38 AM UTC-6, Zero point minus two wrote: > > What are best practices for having a repo that feeds into system > configuration? > > The "etckeeper" program available on some Linux distributions places the git repository in the system configuration directory. In that case, it is not feeding the system configuration, but recording the actual state of the system configuration. I don't see the use case for having a repo which feeds system configuration and which wouldn't be better served by a tool specifically designed for system configuration, like puppet, chef, or ansible. Have you considered those tools for system configuration, since they are specifically designed to configure systems? Mark Waite > The problem is that Git repos are not stable; ie if you mess it up you > would mess up your system if the system files are symlinked to it. > > So you either have to install the files into their final destination or > symlink them from another staging directory which seems a bit pointless. > > It's attractive to just symlink it into the repo directly but just not > very reliable. > > I guess I should let go of the idea of using symlinks even though it is > very convenient. > > It means actual files are all together if you want. > > But having files in a intermediate staging directory creates the problem > of having to push files back into the repo after you edit them. > > Or, you always edit in the repo, but this is weird when you have a staging > directory that is suitable for it. > > Therefore I guess the best choice would be to use direct installation from > the repo into final destinations directly. > > Otherwise you would definitely be tempted to edit them outside of the repo. > > What do you do in such a circumstance? > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] How to improve the Git status performance
Based on the description in the git-status manual page
<https://git-scm.com/docs/git-status>, I don't think that it is performing
any network operations. Changing the location of the server should not
affect the performance of the "git status" command.
The manual page notes that if you have a repository which includes many
files, you can improve the performance of "git status" by not reporting
untracked files ("git status -uno" or "git status --untracked-files=no").
The specific quote is
Because it takes extra work to find untracked files in the filesystem, this
> mode may take some time in a large working tree. Consider enabling
> untracked cache and split index if supported (see git update-index
> --untracked-cache and git update-index --split-index), Otherwise you can
> use no to have git status return more quickly without showing untracked
> files.
Other techniques which can improve the performance of "git status" include:
- Use a local file system on an SSD disc drive for the working directory
rather than a rotating disc
- Use a local file system for the working directory rather than a
network mounted file system
- Reduce the number of files in the working directory by using a sparse
checkout to only checkout the files which are relevant to your work
Mark Waite
On Tuesday, November 22, 2016 at 10:36:29 PM UTC-7, Ravalika wrote:
>
> Thank you
>
> I have tried setting server on the same machine still the git status takes
> more time
>
> real0m25.969s
> user0m10.293s
> sys 0m5.270s
>
> And tried the below flags also
> ignoreStat = true
> fscache = true
> preloadindex = true
> untrackedCache = true
>
> Still the git status takes more time ?
>
> On Thursday, November 17, 2016 at 1:27:43 PM UTC+5:30, Philip Oakley wrote:
>>
>> Git is a DVCS - the first D is the key feature of it's performance.
>>
>> Do have a rethink of the use of a centralised network file server for the
>> user repository. The network delays are killing you.
>>
>> Step one: Decentralise.
>> Step two: Distribute control.
>> Step three: fun and profit (and speed!)
>>
>> Old habits die hard.. Try and get away from them
>>
>> Philip
>>
>> - Original Message -
>> *From:* Ravalika
>> *To:* Git for human beings
>> *Sent:* Thursday, November 17, 2016 5:56 AM
>> *Subject:* [git-users] How to improve the Git status performance
>>
>> Hi All,
>>
>> We are using git-2.10.2 version for version control.
>> It is an centralized server and git status takes too long
>>
>> How to improve the performance of git status
>>
>> Git repo details:
>>
>> Size of the .git folder is 8.9MB
>> Number of commits approx 53838 (git rev-list HEAD --count)
>> Number of branches - 330
>> Number of files - 63883
>> Working tree clone size is 4.3GB
>>
>> time git status shows
>> real 0m23.673s
>> user 0m9.432s
>> sys 0m3.793s
>>
>> then after 5 mins
>> real0m4.864s
>> user0m1.417s
>> sys 0m4.710s
>>
>> And I have experimented following ways but no significant change
>>
>> - - Setting core.ignorestat to true
>>
>> - - Git gc &git clean
>>
>> - - Shallow clone – Reducing number of commits
>>
>> - - Clone only one branch
>>
>> - Git repacking - git repack -ad && git prune
>>
>> - - Cold/warm cache
>>
>> Could you please let me know, what are the other ways to improve the git
>> performance ?
>>
>> Thank you,
>> Renuka
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Git for human beings" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to git-users+...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Large SVN to GIT migration
On Thursday, November 3, 2016 at 10:31:08 AM UTC-6, Kevin Norton wrote: > > Thanks Magnus, > > i will explore subgit, but i think i'm leaning towards simplifying my repo > and trimming un-needed branches and history. > When we did a major transition from a previous source control system to git, it was easiest and simplest to take a snapshot of the tip of the relevant branches from the source repository, then place them into the new git repository. Developers who want to see the history before the transition referred to the earlier repository. Developers who want the history after the transition referred to the git repository. I think that had several benefits: 1. Don't mislead developers to think that the history in git is authoritative for those commits before git was used. The authoritative history is in the original repository 2. Don't clutter the new repository with history that precedes the transition to git 3. Don't spend time trying to create and revise a translation system when the translated result will not be authoritative I'm sure there are business conditions where that is not acceptable (transition from a licensed, proprietary source control system which will be unavailable after the transition), but it worked well for us, and it wasn't too long before searches in the old repository dropped to almost zero. Mark Waite > Kevin > > On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote: >> >> >> Kevin Norton writes: >> >> > i'm in the process of coming up with a strategy to convert a very large >> > project from SVN to GIT. >> > >> > i'm experimented with git svn clone but have some questions. >> > >> > how large is to large. >> > >> > current SVN repo >> > 80K+ revisions. >> > suffers from poor SCM practices >> > current structure in SVN is using cascading hierarchy. Essentially each >> > release branch becomes the trunk (not officially named as trunk) and >> then >> > next release branches to start next development release branch and so >> on, >> > Think of a stairway. >> > Essentially current code sitting in Trunk is extremely old, relevant >> code >> > is at the end of the branching staircase. >> > >> > My first issue i'm trying to sort out. >> > Should i migrate the entire SVN repo into a staging GIT repo and then >> clean >> > up the GIT repo before pushing to eventual network repo for all >> developers. >> > Will it even clone at this size? >> > Or i could clone only the latest release branch and start this as my >> Master >> > in GIT. >> > Questions with this approach are how do i keep it from walking the >> branches >> > back through entire SVN repo? >> > Only way I've seen so far is to specify SVN revision. Is there another >> > approach i'm overlooking. >> > Advantage here is smaller conversion but i'm loosing history or have to >> > maintain a legacy SVN repo for historical. (maybe its not important?) >> > >> > any experience or suggestions with the above are appreciated. >> >> Just bumped into this too >> https://github.com/svn-all-fast-export/svn2git. In particular this >> passage sounds like it could be interesting: >> >> The svn2git repository gets you an application that will do the actual >> conversion. The conversion exists of looping over each and every >> commit in the subversion repository and matching the changes to a >> ruleset after which the changes are applied to a certain path in a git >> repo. >> >> I don't know, but maybe you can come up with rules that'll convert your >> "staircase development" in SVN to a more common "single branch >> development with release branches"? >> >> /M >> >> -- >> Magnus Therning OpenPGP: 0x927912051716CE39 >> email: mag...@therning.org jabber: mag...@therning.org >> twitter: magthe http://therning.org/magnus >> >> We act as though comfort and luxury were the chief requirements of >> life, when all that we need to make us happy is something to be >> enthusiastic about. >> — Albert Einstein >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: using git for system configuration management
Many Linux distributions include etckeeper. It tracks changes in the etc directory with a version control system. It can use git or others. Mark Waite -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] git new bird: Server aborted the SSL handshake
Since it is a public repository, you may be able to clone it with git protocol $ git clone git://github.com/schacon/simplegit-progit Mark Waite On Thursday, September 1, 2016 at 2:12:25 PM UTC-6, Konstantin Khomoutov wrote: > > On Wed, 31 Aug 2016 18:03:47 -0700 (PDT) > chenh...@gmail.com wrote: > > > my try is here: > > $ export GIT_CURL_VERBOSE=1 > > > > $ git clone https://github.com/schacon/simplegit-progit > > > > Cloning into 'simplegit-progit'... > > > > * Couldn't find host github.com in the .netrc file; using defaults > > > > * Trying 192.30.252.129... > > > > * Connected to github.com (192.30.252.129) port 443 (#0) > > > > * Server aborted the SSL handshake > > > > * Closing connection 0 > > > > fatal: unable to access > > 'https://github.com/schacon/simplegit-progit/': Server aborted the > > SSL handshak > > No idea then. > > There are several areas to explore but the fastest is supposedly to use > some king of local HTTP proxy which will take care of TLS connection > establishment. > > You might also want to reach for the main Git list [1]. > > 1. https://gist.github.com/tfnico/4441562 > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git on 2 computers and syn
On Wednesday, June 1, 2016 at 9:26:44 AM UTC-6, Alain wrote: > > Thx Alex, > > regarding structure of Git repository i would like to understand something. > I've read book and watched videos with several "trends / methods" regard > sync several computers together. > > 1st method is to have several git repository (1 per project) > 2nd method is to have 1 main git repository where all projects are inside > it > > i understand that from maintenance point of view method 2 is easier to > maintain but is it the best solution ? a commit or an update would run on > ALL projects inside this repository, so maybe it's time consuming. > > I think that the "best solution" is subjective. It depends on how you'll use the solution and what you'll place in the repository. On one end of the spectrum is the Linux kernel git repository. It is a single repository with over 15 000 000 lines of source code, including multiple years of multi-branch, fast paced development stored in a single repository. Browsing the history of that repository is easy because you can see the entire history. Cloning that repository is slower because it is large. On the other end of the spectrum are many Java projects that use maven (or gradle) and tend to have many very small repositories, each able to build a part of the solution. They clone very quickly, compile very quickly, but are more difficult to navigate the history, since you may be crossing repository boundaries to see the full history. There are some projects that use git submodules. I've not yet found a case where git submodules were a net positive for me. http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/ expresses well what concerns me about git submodules. My personal preference has been more towards a single repository, with careful effort to keep large binary files out of the repository. I'm sure others will view it differently. Mark Waite > On Wed, Jun 1, 2016 at 5:00 PM, Alexandru Pătrănescu > wrote: > >> Hi, >> >> As BitBucket is high available I suggest to keep it as a main central >> repo. >> >> To have sync-ed copy of it you can have repos in any other places. >> Start them with *git clone --mirror * and update >> them once every minute with *git remote update --prune*. >> >> Alex >> >> >> On Wed, Jun 1, 2016 at 5:51 PM, Alain > >> wrote: >> >>> Hi, >>> >>> i use for now BitBucket (from ATlassian) but in order to not depend on >>> internet connection, i would like to be sure both computer (laptop and >>> desktop) always have the same code. >>> >>> As git is a distributed system, i would like to sync not only 1 >>> repository but all repositories at once. >>> >>> Should i install on both computer Gitlab (both computers have Kubuntu >>> 16.04) ? >>> >>> I do not want my repositories to be public or to pay for a Git solution, >>> so i do not use GitHub. >>> Till now i use BitBucket and i use it as Git remote solution, so maybe >>> this is the best solution till now... >>> >>> I'm waiting your answers. >>> >>> thx >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Git for human beings" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to git-users+...@googlegroups.com . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Git for human beings" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to git-users+...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Alain > --- > Windows 7 x64 / Fedora 20 x64 > MySQL 5.6.x > Apache 2.4.7 / OpenSSL 1.0.1c > Tomcat 7.17 > PHP 5.5 > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] I am a newbie
On Saturday, April 30, 2016 at 1:13:29 AM UTC-6, Alekhya Vellanki wrote: > > Thank you for your advice Mr Dale. > > It would be helpful if you could suggest a few projects to me for the > skills that I have. > If you're interested in git and exploring Java, you might consider helping to evaluate pull requests for git plugin or the git client plugin of the Jenkins continuous integration server. Those components are written in Java, but they rely on command line git for the git implementation. That would allow you to explore Java, learn more about git, and possibly help an open source project. Bug reports are at https://issues.jenkins-ci.org/issues/?filter=14040 and https://issues.jenkins-ci.org/issues/?filter=14041 Source code is at https://github.com/jenkinsci/git-client-plugin and https://github.com/jenkinsci/git-plugin Mark Waite > On 30 Apr 2016 00:32, "Dale R. Worley" > > wrote: > >> Alekhya Vellanki > writes: >> > I'd like to start contributing to git. >> > >> > I have absolutely no idea about open source projects contributions. >> > I am also pretty unclear about what bugs,patches etc are. >> > When I tried reading source codes of a few project ideas for GSoc 2016, >> I >> > could hardly understand anything. >> > >> > I am good with C, C++.I am currently learning JAVA, python and shell >> > scripting. >> >> You know that you have a lot to learn. It's better to start with a >> low-profile project where the amount of work that needs to be done is >> larger than the number of volunteers available to do it. Then the other >> people on the project have an incentive to help you learn how to >> contribute effectively. The best choice would be a relatively obscure >> project that you personally care about, or one where you have a friend >> who is already active in the project. >> >> Git is rather the opposite, there are a large number of very experienced >> people who work on it. >> >> Dale >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Git for human beings" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/git-users/N11NrjGax7o/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> git-users+...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: subdir from one big repo as subdir to anouther
On Sunday, April 24, 2016 at 4:58:49 AM UTC-6, wor...@gmail.com wrote: > > In my ovn repository I use the library from another giant repository. This > library is simply a subdirectory of the source code. Not as submodule. > Volume of source code of the huge repository is several gigabytes. The > volume of the source code such I use as library is only 50 kilobytes. How > do I connect this subdirectory from the huge repository to my repository, > and so that does not carry with them these few gigabytes?? > I think you're describing a possible use case for "subtree merge". Refer to https://git-scm.com/book/en/v1/Git-Tools-Subtree-Merging for the description of subtree merge, including its strengths and weaknesses. Mark Waite -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: Objects randomly corrupting
That's an older version of git. If you can't avoid doing that, then you may want to try the most recent version of git, and possibly a 64 bit version of git. Mark Waite On Wednesday, March 9, 2016 at 4:01:01 PM UTC-7, Jerome O'Connor wrote: > > Hi all. > I'm setting up a git repository to help with backing up an archive. The > archive is about 160GB of mostly binary files. I know this isn't the best > use for git, but I'd like to try and get it to work. > The problem I'm getting is that every time I add the files initially, or > then push or clone the directory, I get objects corrupting at random. I > thought it may have been the drives, but testing this on 2 different drives > and 3 different partitions yielded the same results. I also ran a memtest > which didn't pick up any bad RAM. > So what's happened so far: > first init/add/commit, then: > > F:\archived_jobs>git fsck > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 11e4214c0bb2a86605347692bccdebb3be2c4ab6 > error: 11e4214c0bb2a86605347692bccdebb3be2c4ab6: object corrupt or missing > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch ab0314a93ed387193d584f5a49f8cd98d00a75e7 > error: ab0314a93ed387193d584f5a49f8cd98d00a75e7: object corrupt or missing > Checking object directories: 100% (256/256), done. > Checking connectivity: 26094, done. > missing blob ab0314a93ed387193d584f5a49f8cd98d00a75e7 > missing blob 11e4214c0bb2a86605347692bccdebb3be2c4ab6 > > I then moved the .git directory out of the archive and reinitialised and > re-added the repo: > F:\archived_jobs>git fsck > notice: HEAD points to an unborn branch (master) > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 3cdd54f73a2216aea5c67eb94c610472d5410f6d > error: 3cdd54f73a2216aea5c67eb94c610472d5410f6d: object corrupt or missing > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 67f8aa617d3ea57758241399b4d1cf8d051b9f23 > error: 67f8aa617d3ea57758241399b4d1cf8d051b9f23: object corrupt or missing > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 75b9517d49cc538018dba742ac30eb7e5b5b1bd1 > error: 75b9517d49cc538018dba742ac30eb7e5b5b1bd1: object corrupt or missing > Checking object directories: 100% (256/256), done. > notice: No default references > missing blob 75b9517d49cc538018dba742ac30eb7e5b5b1bd1 > missing blob 3cdd54f73a2216aea5c67eb94c610472d5410f6d > missing blob 67f8aa617d3ea57758241399b4d1cf8d051b9f23 > > So corrupt objects again, but DIFFERENT objects. I replace the corrupted > objects with ones from the previous .git directory and git fsck checks out > fine. > I then commit and clone the repo into a bare repo on a different drive, > and run git fsck: > D:\data\repos\archived_jobs>git fsck > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 2da539bdd1e883fe07d0cc7bcab6b2edbaecc9cd > error: 2da539bdd1e883fe07d0cc7bcab6b2edbaecc9cd: object corrupt or missing > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 3dcfdaad5309c2cc22d1c36cb807219802e3cc0e > error: 3dcfdaad5309c2cc22d1c36cb807219802e3cc0e: object corrupt or missing > error: inflate: data stream error (incorrect data check) > error: sha1 mismatch 64671dbf5754312bad99ce73a797aa27243fd734 > error: 64671dbf5754312bad99ce73a797aa27243fd734: object corrupt or missing > Checking object directories: 100% (256/256), done. > Checking connectivity: 26081, done. > missing blob 64671dbf5754312bad99ce73a797aa27243fd734 > missing blob 2da539bdd1e883fe07d0cc7bcab6b2edbaecc9cd > missing blob 3dcfdaad5309c2cc22d1c36cb807219802e3cc0e > > I replace these objects from the initial repo, and fsck gives me no > errors. I then try clone this (using tortoise) to another partition on the > same drive and get: > > git.exe clone --progress -v "D:\data\repos\archived_jobs" > "G:\temp\archived_jobs" > Cloning into 'G:\temp\archived_jobs'... > done. > error: inflate: data stream error (incorrect data check) > error: corrupt loose object 'da8f44c76bb6d08e7a9fd53eb4a594e245e2db8e' > fatal: loose object da8f44c76bb6d08e7a9fd53eb4a594e245e2db8e (stored in > .git/objects/da/8f44c76bb6d08e7a9fd53eb4a594e245e2db8e) is corrupt > warning: Clone succeeded, but checkout failed. > You can inspect what was checked out with 'git status' > and retry the checkout with 'git checkout -f HEAD' > git did not exit cleanly (exit code 128) (4229296 ms @ 9/03/2016 17:26:19) > > so yeah, 4 separate operations, 9 different corrupted objects. Any ideas > what's happening here an
