Re: [git-users] That's really weird, there is no issue tracking for git, I want to report a bug, git can not check-out files with invalid Windows path.
On Thu, 15 May 2014 02:32:32 +0800 罗勇刚(Yonggang Luo) luoyongg...@gmail.com wrote: I report to here because it's not a problem of msysgit, I was ask git do the following things: when commit newly added files, check the filename if its can be used under multiple environment. such as | for example is illegal under Windows. This requirement has no sense: Git can potentially work on an unbounded number of filesystems so there's no sensible way to implement such a check in Git itself. Another thing to consider is that if a developer knows up front that their code will ever be worked with on systems having only, say, POSIX-compliant filesystems (which only prohibit NUL and '/' in the pathnames of the files they store), they might as well decide to use | Cause posix is not the only things in the world, we should accept exist of other things. Please stop thinking about POSIX. What I mean is that hard-coding a list of prohibited characters has two problems: * There might potentially exist (or come into existence at any time) filesystems which run on already existing OSes, and which have their own requirements for file names, different from those of POSIX and Windows filesystems. So the task of blacklisting characters for pathnames is principally insoluble. * Those who don't need/want to deal with the legacy crap carried over from CP/M to recent versions of Windows must not be handicapped. Please note that while I prefer POSIX approach to filesystems more than that of Windows, I think that allowing all the lower part of the ASCII chart, except NUL, to occur in them is idiotic. So it's not like I'm some soft of POSIX zealot or Windows hater. To me, all this means that the best solution to the problem is policy. If your project wants to be portable, use portable filenames; otherwise do whatever you want with them. What exactly is a portable filename might be decided on a project-by-project basis. On the other hand, what *might* work (and, IMO, is possibly worth bringing up with the Git devs) is some *user-configurable* knobs. Consider two imaginary Git configuration settings: * core.pathInvalidCharacters Could be assigned a string of characters to be considered invalid when checking the pathname of the destination file when an operation such as `git add` or `git mv` is run. The default value is \000. * core.pathMaxLength Maximum length of the relative pathname (as stored in Git index). Could help cope with Windows limit of 260 characters per pathname. This won't be exactly bullet-proof (because the user is still able to check the project out under a directory having an insanely long name like C:\Documents and Setting\Karl Marx\My Documents\My Projects \My Pet Project but still... -- 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] worlds slowest git repo- what to do?
I assert based on one piece of evidence ( a post from a facebook dev) that I now have the worlds biggest and slowest git repository, and I am not a happy guy. I used to have the worlds biggest CVS repository, but CVS can't handle multi-G sized files. So I moved the repo to git, because we are using that for our new projects. goal: keep 150 G of files (mostly binary) from tiny sized to over 8G in a version-control system. problem: git is absurdly slow, think hours, on fast hardware. question: any suggestions beyond these- http://git-annex.branchable.com/ https://github.com/jedbrown/git-fat https://github.com/schacon/git-media http://code.google.com/p/boar/ subversion ? 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.
Re: [git-users] worlds slowest git repo- what to do?
On Thu, May 15, 2014 at 10:22:14AM -0700, John Fisher wrote: I assert based on one piece of evidence ( a post from a facebook dev) that I now have the worlds biggest and slowest git repository, and I am not a happy guy. I used to have the worlds biggest CVS repository, but CVS can't handle multi-G sized files. So I moved the repo to git, because we are using that for our new projects. goal: keep 150 G of files (mostly binary) from tiny sized to over 8G in a version-control system. problem: git is absurdly slow, think hours, on fast hardware. question: any suggestions beyond these- http://git-annex.branchable.com/ https://github.com/jedbrown/git-fat https://github.com/schacon/git-media http://code.google.com/p/boar/ subversion ? I think the general consensus is that git is for version control of source, i.e. text. In general putting large binary files into a DVCS is a bad idea since every clone will control ALL versions of ALL files. That makes for a lot of used space! Maybe a backup is what you actually need: https://github.com/bup/bup Then take another look at git-annex and how it can be used as a client to bup. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous pgpVmruxaeMqb.pgp Description: PGP signature
[git-users] Which version of .gitattributes does git checkout use?
Hi all, My question is this: if the .gitattributes file differs between branches, which one will git checkout use if you switch from branch1 to branch2? Will it use the one in the working directory before checkout, i.e., the one that was on branch1? In that case, if the .gitattributes file on branch2 contains rules specific to files on branch2, git will fail to apply those rules. Or does git read the .gitattributes file directly from the to-be-checked-out commit in the repository, so that it can always apply that .gitattributes file to a commit that it is part of? Same question for .gitignore. Regards, Sander -- 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] worlds slowest git repo- what to do?
Thanks Philip, Magnus, Sam. There's no question that I have an outlier problem. But others must have similar, for instance master video files. I need both remote archiving/retrieval and version control. FYI we are archiving compressed Linux disk images for VMs and hypervisors. We are hardware-software makers and manufacturing blasts the disk images directly onto SSD drives. The rest of the repo is a varied mix of far smaller binaries and text files. running on a fast desktop it can take thousands of seconds to perform a status or commit, completely pegging one or more procs. On 05/15/2014 12:06 PM, Philip Oakley wrote: From: John Fisher fishook2...@gmail.com I assert based on one piece of evidence ( a post from a facebook dev) that I now have the worlds biggest and slowest git repository, ... At the moment some of the developers are looking to speed up some of the code on very large repos, though I think they are looking at code repos, rather than large file repos. They were looking for large repos to test some of the code upon ;-) I've copied the Git list should they want to make any suggestions. -- Philip -- 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: Bare repository
On Thursday, May 15, 2014 9:36:41 PM UTC+2, Alain wrote: Hi, Can someone explain me the bare repository functioning ? i mean i understood the big picture...that it is used if several people work together in the same company or on the same floor and may change the same file where other CVS use locks, Git use Bare repository. but what i do not understand is if only 1 person manage the bare repository (setting access right to this repository) on local disk, how can he prevent other people to modify, stage and push changes to it ? Moreover, the bare repository is not for only 1 file... :( A Git repository can and usually does contain many files. It also very often has a lot of collaborators that contribute with changes. They do so by each keeping their own local non-bare repositories A bare repository is typically used as a central place for collaboration. Usually a group of collaborators (think, a team of developers) shares one or more repositories (roughly one repository per product or project). Each team member keeps a local clone of the central repository, a local non-bare working repository. While a bare repository only contains the database with the entire history of the repository, a non-bare repository also has a work tree, which is all the latest files checked out and ready to work on. Physically, they'll look like this. Here's a bare repository (since Git is file-based, it's actually just a folder): foo.git/ config refs/ objects/ In there you'll find packed together copies of all the files that were ever part of the repository, and the current state as it is right now. Here is the same repository, but this time as non-bare: foo/ .git/ config refs/ objects/ README.txt src/ test/ The .git folder is basically the same folder as the non-bare foo.git, it just has a different name and is placed inside a working repository. You need one of these if you actually want to edit the files and commit changes. A bare repository, on the other hand, is nice for keeping backups, or sharing changes. I would like to understand the mechanism. How people can pull/push (having non bare clone) to it, and the person managing the bare repository will manage the pushes/pulls to define what is going or not ? i'm lost with it. Well, it's a bit hard to explain in writing. But imagine this: A team of developers share a central bare repository where they all push and pull from in order to get the latest code from each other. The usual style of management goes like this: * Everyone can push to the central repository when they wish. There is no manager. * If someone else pushes before you do, you have to pull and sync up with their changes before you are allowed to push. * Before you start making changes locally, you'll usually pull and sync up just to make sure you have the latest changes from the others * Once you're done making your local changes, you'll usually pull and sync up again before you push. As above, you're not even allowed to push before you've done so. So, that's the quick explanation I had time for now. I tried explaining something similar in a talk not so long ago: http://youtu.be/U8TkIxJp-w8?t=39m10s - maybe you'll find that useful. You could also start reading one of the many great books out there about Git. Depends on how you like to learn, I guess :) -- 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] Re: git rewrite history for multi module project
Unfrotuantly it is not working the way described, but maybe I'm doing something wrong:(, here goes -created two git repos, mainproject and project1 - created a project1/subproject1/readme, did some dummy commits to readme - to simulate svn move, I copied project1 under mainproject,and removed mainproject/project1/.git directory obviously, then committed as the first commit in the new repo - removed the contents of project1/ and committed that as last commit in old repo - comitted a second commit in the new repo with dummy changes to readme - Now in order not to mess with this installation, I created a new project that fetched both projects - Created a graft point with second commit first commit last commit from old repo - and called git filter-branch --tag-name-filter cat -- --all - it rewrote the new repo branch, but it didn't create second commit as the merge commit, it still can not recognize the moved files, also with follow any ideas? On Wednesday, May 14, 2014 10:22:44 PM UTC+2, Thomas Ferris Nicolaisen wrote: On Wednesday, May 14, 2014 9:19:37 PM UTC+2, Moataz Elmasry wrote: Aha that would be exactly what I'm looking for, how can one define the first commit in mainrepo as a merge commit of several repositories. Only using graft point with one child and several parents does not allow me to follow a file history from main project through the older projects Hm, let's say that the first commit in the mainRepo is abc123. It's basically just a commit where a thousand files are added. You then do the grafting. The commit abc123 is then rewritten to not only be thousand addeded files, but also a thousand removed files, as the files are being moved from their old-structure location. Git doesn't track any renames, it does rename detection upon inspection. Simply explained, if in a commit a file is removed, and another file is added which looks very similar, Git will consider this a rename in the moment you run git log. Of course it doesn't work perfectly in all cases, and I assume that graft points is one of these. Before you make any conclusions, make sure to finalize the grafts as explained herehttp://thomasrast.ch/git/git-svn-conversion.html (good read for anyone doing grafting): git filter-branch --tag-name-filter cat -- --all Also keep in mind that you have to use git log *--follow* to view the history of a file across renames. -- 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] Which version of .gitattributes does git checkout use?
On Thu, May 15, 2014 at 12:21:35PM -0700, Sander Voerman wrote: Hi all, My question is this: if the .gitattributes file differs between branches, which one will git checkout use if you switch from branch1 to branch2? Will it use the one in the working directory before checkout, i.e., the one that was on branch1? In that case, if the .gitattributes file on branch2 contains rules specific to files on branch2, git will fail to apply those rules. Or does git read the .gitattributes file directly from the to-be-checked-out commit in the repository, so that it can always apply that .gitattributes file to a commit that it is part of? Same question for .gitignore. That ought to be rather easy to test with an experiment. Please let us know what you find, I'm curious too :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus The results point out the fragility of programmer expertise: advanced programmers have strong expectations about what programs should look like, and when those expectations are violated--in seemingly innocuous ways--their performance drops drastically. -- Elliot Soloway and Kate Ehrlich pgpPcMZe234Rq.pgp Description: PGP signature
Re: [git-users] Git tags and information as file header
On Thu, May 15, 2014 at 01:21:26PM -0700, Alain wrote: Hi, i would like to know if it is possible (and if yes, how to do it) to retrieve for example tag information or file version from GIT in order to automatically generate/append a file header to each file in order to allow traceability. I mean i would like to have for example: /* * Filename : filename_from_git_repo * version : file_version_from_git_repo * author: author_name_from_git_repo * date: last_modification_date_from_git_repo * ... */ it would be great for php, css, html or any other file... http://stackoverflow.com/questions/11534655/git-keyword-substitution-like-those-in-subversion I personally think that the lack of keyword substitution is a good thing. I've so far, during my 15 years in software development *never* seen a worthwhile use of VCS keyword substitution. - filname: only useful if I have short memory and am using an editor that doesn't display the name of the currently open file - version: doesn't make sense in git, would it be the hash? what does that tell me? - author: who's the author? the person that added the file to git? all people who have made a change to the file? the person making the latest change? who? and how does that help me as a developer? - date: what use is it to me to know that the file was last changed 2 days ago? All that information is interesting to have, but it's already available in the git repo, why have it in each file too? I'd be very interested in hearing your use case for having that info in the file. I'd love to be convinced that all those other VCSs haven't wasted effort on implementing a rather useless feature :) /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Heuristic is an algorithm in a clown suit. It’s less predictable, it’s more fun, and it comes without a 30-day, money-back guarantee. -- Steve McConnell, Code Complete pgpq8mYolp37J.pgp Description: PGP signature
Re: [git-users] Which version of .gitattributes does git checkout use?
- Original Message - From: Sander Voerman To: git-users@googlegroups.com Sent: Thursday, May 15, 2014 8:21 PM Subject: [git-users] Which version of .gitattributes does git checkout use? Hi all, My question is this: if the .gitattributes file differs between branches, which one will git checkout use if you switch from branch1 to branch2? Will it use the one in the working directory before checkout, i.e., the one that was on branch1? In that case, if the .gitattributes file on branch2 contains rules specific to files on branch2, git will fail to apply those rules. Or does git read the .gitattributes file directly from the to-be-checked-out commit in the repository, so that it can always apply that .gitattributes file to a commit that it is part of? Same question for .gitignore. Regards, Sander -- The man page suggests what happens under checkout During checkout process, .gitattributes in the index is used and then the file in the working tree is used as a fall-back. Philip -- 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] Re: git rewrite history for multi module project
On Thursday, May 15, 2014 11:02:35 PM UTC+2, Moataz Elmasry wrote: - removed the contents of project1/ and committed that as last commit in old repo Why this? Try again, and this time leave this step out. -- 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 tags and information as file header
On 15/05/2014 22:48, Magnus Therning wrote: - version: doesn't make sense in git, would it be the hash? what does that tell me? I find an identifier useful when investigating problems and wanting to confirm what files are involved. -- 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 tags and information as file header
On Thursday, May 15, 2014 11:48:17 PM UTC+2, Magnus Therning wrote: I'd be very interested in hearing your use case for having that info in the file. I'd love to be convinced that all those other VCSs haven't wasted effort on implementing a rather useless feature :) This is not my problem, but I'll bite :) We have a live environment where we very often have to hot deploy single files between releases. These small hot-deployments go mostly unmanaged, so it's good to have these keywords in the files so we can quickly recognize hot-fixes (has this file been patched on this server yet?) . (based on a true story from SVN times) -- 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 tags and information as file header
On Thu, May 15, 2014 at 11:21:25PM +0100, Andy Hardy wrote: On 15/05/2014 22:48, Magnus Therning wrote: - version: doesn't make sense in git, would it be the hash? what does that tell me? I find an identifier useful when investigating problems and wanting to confirm what files are involved. What kind of identifier? What kind of problems and where? Is the file in a clone or in a deployment, i.e. you can't rely on a VCS to tell you what you have? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus As long as there are ill-defined goals, bizarre bugs, and unrealistic schedules, there will be Real Programmers willing to jump in and Solve The Problem, saving the documentation for later. Long live Fortran! -- Ed Post pgpI5N2cvIGUl.pgp Description: PGP signature
