[git-users] Re: Importing Subversion vendor-branches to Git
Dear Thomas, thank you very much for your reply! I know it was a long post, and I very much appreciate your having worked through it. Am 2012-10-07 23:42, schrieb Thomas Ferris Nicolaisen: It is indeed a large post and hard to read out the question(s) in there. In the middle part, you describe some complications with the live/pristine branches, but you also write that you have already solved this problem? I find the connection with the first and the last part a bit unclear. You're right, I'm very sorry about it. I guess it's the result of me being still in the learning process... there are things that I felt that I had to circumscribe, in lack of knowing the proper, short, unambiguous term. I tried to outline what I did and what want well so far: a) For the vendor branches I found the special-case solution described at http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/ b) Using that, all conversions of my websites worked well, requiring grafting in one case. Practical use of these conversions works perfectly as well. So the websites stuff is completely done and out of the picture. You might get more replies if you try to isolate a smaller example, and ask simpler questions one at a time. Yes, I'll complete this answer to you first, and then in a new, separate post will re-phrase my question in a smaller example, later today. I'm not quite sure how the external libraries are versioned in relation to your core project (with the trunk/branches/tag structure). Before I go on to think about how one could do lots of sub-tree merging and filter-branching to get these external libraries into your repository, I want to ask if you really want to do this. Including the sources of 3rd party libraries is exactly what git-submodules are intended for, and even before I do this I would consider if it is possible to get away with rather some binary dependency declaration in the build-tool instead (this might not be fitting for your project, but it's worth considering). Even if you do your own modifications of lua or the other libraries, it is still worth tracking them in their own repositories, and then load them in using submodules. Some aspects about our external libraries in ExtLibs: Binary dependencies would only work in a subset of our use cases: Obviously, we don't need our own copy of zlib under Linux, but we do under Windows. With some of the libraries (e.g. wxWidgets) we sometimes have specific needs to the exact version that is used, and occasionally make small changes in the libraries themselves. It's rare, but when done it's also crucial, such as bug-fixes, feature patches, customizations, etc. For our repository users, all this should be as carefree as possible, if possible we'd like to continue to provide them with everything that they need with a single git clone ... All the libraries in ExtLibs are lightweight and small in size, so performance or bandwidth is not an issue. Our use of vendor branches was of course born long years ago, in the Subversion days when most libraries where not available as Git repositories: Occasionally drop .tar.gz archives of their latest public release into our vendor branches, then merge them to master in order to not overwrite our customizations. Using submodules, we would not want to depend on the Git repositories of the library vendors, so we had to create our own ExtLibs Git repository. That, in turn, would be managed via .tar.gz drop-ins as before. From what I've read about submodules, they seem to come with inherent problems that I'd rather try to avoid, e.g. as described at http://git-scm.com/book/en/Git-Tools-Submodules (the book by Loeliger and that by Haenel express similar concerns). A case where I can see how submodules would be useful is for example if Autodesk made their Autodesk FBX SDK available as a Git repository. This library is so huge that we'd not want to have it in our main repository, plus there are legal restrictions that don't allow us to do so. Also, we'd never like to modify anything in there. To my understanding, this would be a perfect case for submodules. In summary, even though I fear that my understanding of submodules is incomplete, *subtrees* seem to be a better solution to the problem. (And I had hoped to avoid even those, in the spirit of the happygiraffe.net blog post, i.e. having a branch named vendor that has nothing but the ExtLibs directory with the .tar.gz drops of the libraries.) With this in consideration, what is the first thing you need to solve? You write that you haven't been able to convert with all the merges intact. Is this point crucial to complete the conversion? To my understanding, yes: Merging later (using grafts and filter-branch) would change the SHA-1 sums of all child commits, essentially making any public clone of the repository incompatible (or at least require everyone to rebase), would it? Also, one of
[git-users] [Short edition] Importing Subversion vendor-branches to Git
Hi all, as pointed out by Thomas, my original description of our problem and question was too verbose and cluttered, so here is another attempt that is shorter and more to the point: We have a Subversion repository with this layout: cafu/ trunk/ branches/ tags/ vendor/ Essentially, this is Subversion standard layout, plus a vendor branch. In greater detail, unfolding the trunk/ and vendor/ directories, the structure is: cafu/ trunk/ .../ # All the project directories. ExtLibs/ # External libraries. lua/ wxWidgets/ zlib/ branches/ tags/ vendor/ lua/ wxWidgets/ zlib/ In Subversion, we used to use the vendor branch strategy to update the external libraries: If a new version of zlib was released, we dropped its .tar.gz into vendor/zlib/ (adding/deleting files as necessary), then merged vendor/zlib/ to trunk/ExtLibs/zlib/. (As a detail, observe how vendor/ maps to ExtLibs/, not to trunk/. That is, after a new zlib/ was committed to vendor/zlib/, we could also have merged the whole vendor/ to trunk/ExtLibs/, but - obviously and unfortunately - not vendor/ to trunk/, because vendor/ is missing the intermediate ExtLibs/ directory.) We can convert the above repository to Git like this: git svn init svn://thubi-cfs/Project/cafu -s Project cd Project git config --add svn-remote.svn.fetch vendor:refs/remotes/vendor git svn fetch The second to last line causes it to import vendor/ just like any other branch. This works, BUT: a) vendor/ gets imported as an independent series of commits with a separate root. At no point is it branched from or merged back to the main series of commits, as would be expected after e.g. a zlib/ update. b) Worse, vendor/ obviously cannot be merged, because its relative position is wrong: it matches trunk/ExtLibs/, not trunk/. c) If the repository structure was like vendor/ ExtLibs/ # extra layer to make vendor/ match trunk/ lua/ wxWidgets/ zlib/ then b) would not be an issue, but from our experience with similar cases, git-svn would *still* not see the proper branch and merge points. (This was also the case with our website.) In this case, we could however use grafting and filter-branch to fix the issue. I'm sorry that this still a long description, but I don't know how to make it shorter while preserving the necessary details (and the attempt at clarity). The question is, how can we best import the main project below cafu/, so that it also has the proper branches from and merges to vendor/ ? Many thanks and best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: [Short edition] Importing Subversion vendor-branches to Git
Hi Thomas, Am 09.10.2012 09:35, schrieb Thomas Ferris Nicolaisen: So, if you want to make an upgrade of for example lua, you first download and unzip it into /vendor/ExtLibs/lua/, make some adaptions, and then merge it into trunk and any other branch where you want to perform the upgrade. Is this correct? Yes, this is correct: In /vendor/ExtLibs/lua/ (or currently in fact in vendor/lua/) the newer version overwrites the old one (no custom adaptions here!, all code in vendor is pristine, 1:1, as it was obtained from the vendor). The subsequent merge to trunk/ExtLibs/lua/ makes sure that the old version that is there is updated to the new version while trunk-local customizations/adaptions are preserved. As a thought-experiment: Set aside the git-svn conversion issues for a moment, and imagine, how would this event (a lua upgrade) be done in the optimal Git repository structure? Exactly analogous to http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/ In the words of my example: Have a branch named vendor that contains only the ExtLibs/ directory (so that its structure matches that of branch master). (In opposite words, other project directories that are in master as siblings of ExtLibs/, are not in branch vendor). A lua upgrade would checkout branch vendor, update lua as before (overwrite fashion, pristine), and commit. Check out trunk, then merge in vendor. As you see it's very straightforward and simple. :-) I'm honestly a bit surprised that this kind of question doesn't occur more often, considering (or assuming) that many other projects that convert from SVN to Git have vendor branches, too. Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: [Short edition] Importing Subversion vendor-branches to Git
Hi Thomas, Am 2012-10-09 12:35, schrieb Thomas Ferris Nicolaisen: A branch in Git is uusally a branch of *what is the main contents of the repository*, not some arbitrary content. As I said above, submodules were invented for this purpose, to avoid filling up your own repositories with things that don't really belong there. Hmmm... I understand what you say, but regarding convention / purpose / philosophy, I'm still confused: In http://happygiraffe.net/blog/2008/02/07/vendor-branches-in-git/, would you say that his upstream branch has some arbitrary content? I see that this is a generic use of branches, unlike the way in which branches are normally used, but to me this looks like a clever, straightforward, and above all a very simple technique that needs no extras. Personally, for these reasons, I find it very appealing. (Especially as our external libraries are all lightweight and considered closely related to the main project.) Submodules, in contrast, are described as problematic in each book that I've read so far (and there are many internet resources in the same spirit), and seem mostly suited, as you say, for things that don't belong there. As I mentioned in my previous post (http://article.gmane.org/gmane.comp.version-control.git.user/3493), I can see how submodules are a natural fit for a library that is huge in size, has an incompatible license or otherwise restricted distribution terms compared to the core project, and/or that we don't ever intend to modify. I'm happy to stand corrected, but at the moment, the happygiraffe.net approach looks a lot simpler and more attractive than submodules to me. That said, I imagine that your model should work. It's like having permanent feature-branches, which are never updated with the development in master. Well, yes, it's a shift in perspective, different from what branches are usually used for. One way to see it is that vendor is the true master (as in the basis, or the source), and the usual master is just a branch of it. ;-) Still feels very natural and in no way like misuse of branches to me. My personal favorite term, instead of vendor, is pristine branch, but that's maybe because I'm not a native English speaker. ;-) So, I imagine the following. You first clone the *cafu* repository. Inside *cafu* you get subdirectories like ExtLibs/lua, ExtLibs/zlib and so on. You then clone each of the vendor repositories, Why each? I could as well clone vendor as a whole, couldn't I? and transform them into having the structure you want. See the man page for filter-branch, there's an example for /To move the whole tree into a subdirectory/. Ahh!! Thank you very much! That was the crucial step that I was missing before! [...] Is this a line of thought you have tried out in practice? I didn't try it before, because I didn't know how to move a whole tree into a subdirectory. But I'll try now, and report how it went. With the hand-work involved, it will probably take me a few days to finish, though. A thousand thanks for your help! Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: [Short edition] Importing Subversion vendor-branches to Git
Am 2012-10-10 08:02, schrieb Thomas Ferris Nicolaisen: One repo should have one versioning scheme. Think about tagging. You want to identify versions of lua 1.0, 1.1, and so on. If you keep a lot of products in one vendor repo, it will be filled with tags of different versioning schemes like lua-1.0, zlib-5.3 and so on. This works as well, of course, but it doesn't feel clean. Separation of concerns and all that. Well, I use tags not only strictly for versioning, but also for attaching generic labels to commits. That is, in the *vendor* branch, my tags (in the verbose form) simply express something like: From this commit on, we use (or rather 'start using') lua 5.2. Next commit tag in vendor branch might maybe express: From this commit on, we use (or rather 'start using') wxwidgets 2.9.12. That's all. No tag is expected to give an exhaustive list of the version of everything. :-) Thanks for your help, I'm currently working on implementing it! Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Re: [Short edition] Importing Subversion vendor-branches to Git
Hi Damien, Am 2012-10-10 01:10, schrieb Damien Robert: if I have understood your problem correctly, it looks like the git subtree script could help you a lot. [...] Unfortunately, the above proposition will only help you track vendor branches after you have done the conversion, but not in the conversion itself. For that it looks like you'll have to use graft (personally I would use git filter-branch to rewrite the commits), and I don't know how easily scriptable this will be. Yes, when I started familiarizing with Git, subtrees looked like the proper and natural solution to the problem. In fact, if I could start with an empty repository, from scratch, I'd most likely use subtrees for what used to be vendor branches in Subversion. However, having to convert an existing repository from Subversion, where I ultimatively need grafting to reproduce the proper branching structure, the conversion reduces to the question: Can I combine grafting with the subtree merging strategy? That is, when I write the .git/info/grafts file, can I have some of the merges be done with the subtree strategy? The beauty of the approach described in the blog post mentioned in my previous post is that although a bit unusual, it is also very generic, and so it avoids all the subtleties both of submodules and subtrees. (It even works with Mercurial, if a conversion was ever required or desired. ;-) ) If I know how to make grafting use the subtree strategy, I'd use subtree's though, so I'd be very happy to learn if this is possible. Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] [solved] Re: Importing Subversion vendor-branches to Git
Hi all, thanks to the great help of Thomas and Damien, I've been able to complete our conversion from Subversion to Git successfully. For possible future readers (including myself, in case I cannot remember the next time ;-) ), I've written down all the steps and considerations that comprise my solution: If you want to skip all the prose and have a short read, directly jump to: http://www.cafu.de/forum/viewtopic.php?p=5393#p5393 I wrote my entire story in two parts, quasi as a postmortem of the conversion. In case you care for the details, they're at: http://www.cafu.de/forum/viewtopic.php?f=14t=1090 http://www.cafu.de/forum/viewtopic.php?f=14t=1092 Many thanks for everyones help! Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Problem with moving everything into a subdirectory; merge conflicts
Hi all, we have a repository with essentially this commit graph: o---o---o---...---o---o---D -- develop / / / o---o---o---o---...---M -- master As shown, we occasionally merge master into develop, but never vice-versa. (We create our releases off the develop branch, not master.) Now we have found a need to reorganize our files and directories, moving everything into a new subdirectory www, for example like this: # Git version is 1.7.11.msysgit.1 on Windows 7. # At the top of the working tree: mkdir www/ git mv forum/ www/ git mv images/ www/ git mv templates/ www/ git mv index.php www/ ... git commit -m Moved everything into www/. This is easy, but the problem is that we eventually have to do this *both* in develop *and* in master, in order to be able to do future merges from master into develop as before. The question is how? I tried the above move-and-commit commands first at commit M, yielding new commit N, then to merge this into develop in order to obtain E: o---o---o---...---o---o---D ---E-- develop / / // o---o---o---o---...---M ---N -- master but this yields plenty of merge conflicts, probably because D has several files in various directories that M doesn't have, and several files with small changes as well. So I deleted E again (reset develop back to D), repeated the above move-and-commit commands at D in order to mimic things in the develop branch, obtaining F, and *then* tried to merge master into develop to obtain G: o---o---o---...---o---o---D ---F ---G -- develop / / / / o---o---o---o---...---M ---N ---´ -- master To my surprise, this caused conflicts for quasi every of the affected 11000 files as well. Unfortunately I didn't keep a copy of the exact messages, but essentially the reported conflict was that the file has been renamed on one side, and has been renamed on the other side as well. What can we do? Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
[git-users] Re: Problem with moving everything into a subdirectory; merge conflicts
Hi Philip, Am 2013-01-06 18:21, schrieb Philip Oakley: Your issue [my mistake] is that the (gits's) merge process is a three way merge, so you have the two commits F and N to merge, but git will also locate the merge-base at M (which has the old directory structure), and compares the diffs between them [M-F] and [M-N] (AFAIKI), so you will get these hundreds (thousands) of renames on that basis, and a great difficulty in (git) trying to decide what to do. Thank you very much for that explanation, it helps me a lot with understanding this! So I'm thinking that it would be useful to have a merge commit, if possible, immediately before the two flag day change commits, and then adjust the level of rename detection (--rename-threshold) on the subsequent merge. (can't remember the default threshold) I had this (a helper merge commit), indeed not strictly immediately before the flag day change commit, but close enough so that I should have recognized if the affected files from the few intermediate commits (between the last merge commit and D) were involved in or responsible for the conflicts. However, it rather looked as if a main source of trouble were a large number of index.html sentinel files: As they all have the exact same contents, it seemed that the rename detection started to associate files at completely different, unrelated paths with each other. Also you could simply try an Ours/Theirs strategy (as appropriate) which would stop git trying to do more than it needs to, given that you will already have carefully made the two tree 'compatible' ;-) which will establish a new merge base for future merges. Ah!! :-) I really should have thought of trying this myself. Using git merge -s ours master worked quickly and without any problems, and created the new merge commit G just as expected. However, I'm unsure if this is the proper solution: Of course, logically I expected that commits F and G have the same tree (as G's only purpose is to serve as a new merge basis), even if G was created with the default merge strategy. The ours strategy does exactly that (refer to same tree in G) quasi on the direct route, per definition. But I wonder if this argument is enough? That is, do I understand correctly that if I had used the default merge strategy, and somehow solved all the conflicts (so that none of the files had been changed from F), the result would have technically been exactly the same? Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
[git-users] Re: Problem with moving everything into a subdirectory; merge conflicts
Hi Philip, Am 2013-01-08 00:02, schrieb Philip Oakley: That is, do I understand correctly that if I had used the default merge strategy, and somehow solved all the conflicts (so that none of the files had been changed from F), the result would have technically been exactly the same? Obviously/hopefully your solution to any conflicts would have ended up being an ours choice anyway... Given that you already had a recent merge before the restructuring I would expect that it would be exactl;y the same! Ok, things seem to work very well: I'm not ready yet to test if *future* commits on the two branches, and future merges among them, will work as expected, but it looks as if everything worked out exactly as hoped. :-) Philip, thank you very much for your help! Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
[git-users] Re: git merge: error: The following untracked working tree files would be overwritten by merge
Hi John, Am 2013-01-11 14:15, schrieb John McKown: I'm not knowledgeable enough to answer your question. I do wonder why you are not tracking the files in obsolete/ . If you truly don't want to track them, then I _think_ that it might be well to add the line: obsolete/ to your .gitignore file. Thanks for your reply, but this is not the case here: 0. In my example, directory obsolete/ was initially not in any repository, neither in a local nor the central upstream repository, nor in any working tree. 1. I started on computer A, where inside a working tree I initially created the directory obsolete/ and its contents. 2. Then I sent (per SFTP, no Git involved) the complete directory obsolete/ to computer B, into the working tree *there*, because I wanted to test something there before actually committing it on A. (Yes, there are facilities in Git that allow for alternative, more elegant solutions for such cases, but this time, this was what I had to do.) 3. On B, things worked out as expected, so I went back to A, added obsolete/ to the repository (git add obsolete/, git commit), and pushed the new commit upstream (to the central repository, on computer C). 4. Back on A (actually, all this was done via SSH logins to A and B...), I ran git fetch to obtain the new commit from the central repository C, then the git status that you've seen in my original mail. 5. The final git merge origin/master --ff-only failed. Although I saw solutions to the problem, it seems to me that Subversion works better in such cases, and thus I posted here. ;-) Best regards, Carsten On Fri, Jan 11, 2013 at 4:38 AM, Carsten Fuchs carsten.fuchs-sdyparl0...@public.gmane.org wrote: Hi all, in my repo, I'm doing this: $ git status # On branch master # Your branch is behind 'origin/master' by 2 commits, and can be fast-forwarded. # # Untracked files: # (use git add file... to include in what will be committed) # # obsolete/ nothing added to commit but untracked files present (use git add to track) $ git merge origin/master --ff-only Updating f419d57..2da6052 error: The following untracked working tree files would be overwritten by merge: obsolete/e107/Readme.txt obsolete/e107/article.php obsolete/e107/backend.php [...] Well, I seem to understand the problem, and the solution seems to be simple as well: renaming the obsolete/ directory is enough. But why does Git find a problem here at all? Compare with what Subversion did in an analogous case: When I ran svn update and the update brought new files for which there already was an untracked copy in the working directory, Subversion: - started to consider the file as tracked, - but left the file in the working-copy alone. As a result, a subsequent svn status might a) no longer show the file at all, if the foreign copy in the working directory happened to be the same as the one brought by the svn update, or b) flag the file as modified, if different from the one that svn update would have created in its place. So my real question is, why does Git not do something analogous? (Afaics, update the HEAD, update the Index, but leave the working-copy edition alone?) I searched for this beforehand, and most advice involves either stashing, or with git reset --hard the loss of the untracked files. Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de -- -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
[git-users] Re: git merge: error: The following untracked working tree files would be overwritten by merge
Hi again, Am 11.01.2013 11:38, schrieb Carsten Fuchs: [...] So my real question is, why does Git not do something analogous? (Afaics, update the HEAD, update the Index, but leave the working-copy edition alone?) I searched for this beforehand, and most advice involves either stashing, or with git reset --hard the loss of the untracked files. Anyone? Best regards, Carsten -- Cafu - the open-source Game and Graphics Engine for multiplayer, cross-platform, real-time 3D Action Learn more at http://www.cafu.de --
[git-users] Re: CRLF will be replaced by LF warning
Hi Alexandru, thanks for your reply! Am 2013-04-06 11:55, schrieb Alexandru Pătrănescu: Even if you work on windows, I suggest using core.autocrlf = input, Well, unfortunately, it doesn't help: d:\Dev\Cafu git diff [...] warning: CRLF will be replaced by LF in Libs/TypeSys.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in Libs/TypeSys.hpp. The file will have its original line endings in your working directory. d:\Dev\Cafu git config core.autocrlf false d:\Dev\Cafu git config core.autocrlf input d:\Dev\Cafu git config core.autocrlf input d:\Dev\Cafu git diff [...] warning: CRLF will be replaced by LF in Libs/TypeSys.cpp. The file will have its original line endings in your working directory. warning: CRLF will be replaced by LF in Libs/TypeSys.hpp. The file will have its original line endings in your working directory. More importantly, it seems that core.autocrlf should not affect files covered by the .gitattributes settings at all (if I understood the .gitattributes man page and http://timclem.wordpress.com/2012/03/01/mind-the-end-of-your-line/ correctly). So I still need help with this problem. Best regards, Carsten -- Dipl.-Inf. Carsten Fuchs Carsten Fuchs Software Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany Internet: http://www.cafu.de | E-Mail: i...@cafu.de Cafu - the open-source game and graphics engine for multiplayer 3D action -- 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/groups/opt_out.
[git-users] Re: CRLF will be replaced by LF warning
The problem described in my original message seems to stem from the fact that the line endings are not written as CRLF in the working directory. Please consider these simple steps to see the problem: d:\Dev git --version git version 1.8.0.msysgit.0 d:\Dev git config -l core.symlinks=false core.autocrlf=false color.diff=auto color.status=auto color.branch=auto color.interactive=true pack.packsizelimit=2g help.format=html http.sslcainfo=/bin/curl-ca-bundle.crt sendemail.smtpserver=/bin/msmtp.exe diff.astextplain.textconv=astextplain rebase.autosquash=true user.name=Carsten Fuchs user.email=carsten.fu...@cafu.de core.editor='C:/Program Files (x86)/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin d:\Dev git clone g...@bitbucket.org:cafu/cafu.git Cafu-Test Cloning into 'Cafu-Test'... remote: Counting objects: 30588, done. remote: Compressing objects: 100% (11282/11282), done. remote: Total 30588 (delta 20466), reused 28950 (delta 19084) Receiving objects: 100% (30588/30588), 92.42 MiB | 422 KiB/s, done. Resolving deltas: 100% (20466/20466), done. Checking out files: 100% (9263/9263), done. d:\Dev cd Cafu-Test d:\Dev\Cafu-Test type .gitattributes *.h text *.hpp text *.c text *.cpp text *.txt text When you now look at any of the .h, .hpp, ... files declared as text in .gitattributes, they all have LF instead of the expected CRLF line endings. (Note that core.eol is not set.) Why? Any help would very much be appreciated! Best regards, Carsten -- Dipl.-Inf. Carsten Fuchs Carsten Fuchs Software Industriegebiet 3, c/o Rofu, 55768 Hoppstädten-Weiersbach, Germany Internet: http://www.cafu.de | E-Mail: i...@cafu.de Cafu - the open-source game and graphics engine for multiplayer 3D action -- 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/groups/opt_out.
[git-users] Re: CRLF will be replaced by LF warning
Am 2013-04-10 21:11, schrieb Carsten Fuchs: The problem described in my original message seems to stem from the fact that the line endings are not written as CRLF in the working directory. Please consider these simple steps to see the problem: [...] Can someone help me? Can someone reproduce this problem? (For completeness, I also posted this problem at the msysGit list, the thread is at https://groups.google.com/d/msg/msysgit/5ABaIl_7uE0/YyB3agKUrNIJ, but there as here, there were no replies so far...) Best regards, Carsten -- 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/groups/opt_out.
[git-users] Re: CRLF will be replaced by LF warning
Hi Rupert, Am 2013-04-14 13:37, schrieb rupert THURNER: we have a unix - linux - windows 7 environment, and we never needed .gitattributes. but, i used to get the error message regularly when the text files contain crlf line endings and use core.autocrlf = input. Thanks for your reply! I also posted my question at the msysgit list, and got very kind help there, also covering the root cause of the problem. See http://thread.gmane.org/gmane.comp.version-control.msysgit/18241 for details. Best regards, Carsten -- 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/groups/opt_out.
[git-users] Re: Multiple backup strategy & S3
Hi Kai,
Am 2016-01-08 um 05:18 schrieb Kai Hendry:
Thanks what {aws s3,s3cmd} sync does but it has a problem of trumping data.
Maybe http://www.boarvcs.org/ is an option for you?
Best regards,
Carsten
--
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 status --> Out of memory, realloc failed
Anyone please? Best regards, Carsten Am 2017-02-12 um 11:49 schrieb Carsten: Dear Git group, I use Git at a web hosting service, where my user has a memory limit of 768 MB: (uiserver):p7715773:~$ uname -a Linux infongp-de15 3.14.0-ui16322-uiabi1-infong-amd64 #1 SMP Debian 3.14.79-2~ui80+4 (2016-11-17) x86_64 GNU/Linux (uiserver):p7715773:~$ git --version git version 2.1.4 The problem is that `git status` fails with an out of memory error: (uiserver):p7715773:~/cafu$ git status fatal: Out of memory, realloc failed fatal: recursion detected in die handler I talked to their support and their suggestion was to set a couple of memory constraints and to run `git gc`. This seemed to work well – but `git status` still fails: (uiserver):p7715773:~/cafu$ cat ~/.gitconfig [color] ui = auto [user] name = Carsten Fuchs email = carsten.fu...@cafu.de [core] editor = nano pager = less -M -FRXS packedgitwindowsize = 30m packedgitlimit = 40m [i18n] commitEncoding = ISO-8859-1 [pack] threads = 1 windowMemory = 10m packSizeLimit = 20m deltaCacheSize = 30m (uiserver):p7715773:~/cafu$ git gc Zähle Objekte: 44293, Fertig. Komprimiere Objekte: 100% (24534/24534), Fertig. Schreibe Objekte: 100% (44293/44293), Fertig. Total 44293 (delta 17560), reused 41828 (delta 16708) (uiserver):p7715773:~/cafu$ git status fatal: Out of memory, realloc failed fatal: recursion detected in die handler Well, their next response was that they have no solution for me – except, unsurprisingly, coaxing me into a more expensive hosting package. I've read the Git man page about `git config`, but was not able to come up with anything to improve the situation. Any ideas what I could do to reduce the memory consumption of `git status`? Best regards, Carsten -- 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.
