Re: [ANN] Pro Git Reedited 2nd Edition
On 8/12/16 6:11 AM, Sitaram Chamarty wrote: At present gitolite is -- AFAIK -- the only "pure server side", "no GUI" solution for access control, and has some interesting features that more "GUI" solutions may not. It is also (again, AFAIK) used by kernel.org, Fedora, Gentoo, and several other open source projects as well as many enterprises. If you're ok with adding that, I'd be happy to supply some text for your consideration. I appreciate your offer and I don't disagree with what you're suggesting, but my goal, for now at least, is to keep the same coverage as upstream. If they add something about Gitolite to their next edition, then I will also. Cordially, Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Pro Git Reedited 2nd Edition
On 7/26/2016 2:15 AM, Manlio Perillo wrote: I have noted a problem when reading the PDF with Chromium: the anchors/links do not work. I see what you mean. I was able to replicate the problem with Acrobat Reader on Windows 10. This seems to happen only with internal links - links to external URLs work fine. I don't know if this is an issue with the conversion to PDF or an issue with Chromium. It's not Chromium. This is going to be tricky to fix. I'm just using the tool chain that Scott and Ben set up. I've found other issues too that will be hard to resolve. Thanks for the report. I guess for now the best thing to do is to use the HTML version. Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?
Another possibility is to set authordate and committerdate to some specified time by the way of appropriate environment variables. To follow up, Jakub's approach works great without requiring any changes to Git. For example, the following test script always produces the same commit ID: export GIT_AUTHOR_DATE=2005-04-07T22:13:13 export GIT_COMMITTER_DATE=2005-04-07T22:13:13 mkdir -p /tmp/test cd /tmp/test rm -rf .git git init echo "Test" > README git add README git commit -m "test" git log As expected, commenting out the 2 export lines results in different commit IDs each time. Case closed. Thanks, Jakub! Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Pro Git Reedited 2nd Edition
Also, I realized one potentially major disadvantage of sharing in Google Drive. This is that the URL will change each time I update the book. Apparently Google is taking away the ability to create a static link at the end of August 2016. I think you can share a folder instead, and this would be stable. Alternatively, when updating the book you could update the link in the GitHub repository description and/or the README for the fork. By the way, I might have just figured out a good way of handling static links with Google Drive. Apparently, when I created the pdf version of Pro Git Reedited 2nd Edition (which I did on a Dropbox folder) I didn't wait long enough for the creation process to complete (I think that was the problem but I'm not 100% sure). Anyway, as a result, the pdf version didn't have any images in it. After fooling around for a while, I was able to create a pdf that did contain the images but I was worried that uploading it to Google Drive would change the URL, as we had discussed. However, the "Manage Versions ..." option on Google Drive let me upload a new version of the file *without* changing the share URL! Assuming I wasn't hallucinating, this will be a great way to update both the pdf and the HTML versions as they change in the future. Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?
On 7/24/2016 11:51 AM, Rodrigo Campos wrote: And what is the problem with that, if you are doing it with instructional purposes? Let's assume that this helps and not confuses later when the commits *do* change. What is the problem you face? A lot of instructional material contains stuff like "Do [xxx] and you'll see [zzz]. If you don't then something went wrong so try to figure out what happened and do it again." Git, as it stands, for good reason doesn't allow this approach. I don't think a Git beginner, when using a version of Git that somehow works the way I proposed, will be confused. The fact that performing the same steps results in the same commit IDs won't be something that they'll care about or even notice. The material can include a callout mentioning the difference between "real" Git and "learners" Git. I mean, for some examples you can use HEAD, HEAD^, HEAD~4, etc. and that always works, no matter the commit id. This will work in some cases, but should come later in a Git book. But, in many cases using relative commit IDs, rather than absolute, will be less clear (I believe). In which cases do you want/need the commit ids to be equal? Can you be more specific? Sure. Take a look at the 2nd or 3rd chapter of Pro Git Reedited, 2nd Edition (or just Pro Git 2nd Edition - it doesn't matter). You see lots of output showing 'git commit' commands and the commit IDs that result. I suspect you'd see the same in almost any book about Git. Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?
On 7/24/2016 11:46 AM, Jakub Narębski wrote: Please try to keep to the 80-character lines. Sorry. Another possibility is to set authordate and committerdate to some specified time by the way of appropriate environment variables. That sounds like a great idea. Assuming it works the way I envision, this wouldn't require any changes to the source code. What I think you don't realize is that "commit" objects are not treated in any way special. Object identifiers of all objects are SHA-1 hash of uncompressed loose representation of said object (type + length + contents). I know this, but I thought that commit object IDs were the only ones that included a date in what gets run through the SHA-1 hash function. If there are others, then you're right - they'd need to be included in this proposal. Well, you could not record dates in commit object, but I think Git considers such objects broken. You mean that Git could, after the fact, detect commit IDs that didn't include a date? If this is true, then your idea of using fixed dates from environment variables would be the only way to do this. IMVHO it would require heavy surgery of Git for little benefit (see the beginning of reply for alternate solutions). Even using your environment variable solution that wouldn't require any code changes? Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Pro Git Reedited 2nd Edition
On 7/24/2016 11:27 AM, Jakub Narębski wrote: In my opinion being able to view it online has its advantages. Even casual reader can check it, and point errors or offer suggestions for improvements. Absolutely. Now that I've finished the editing I'll look into that. I think you can share a folder instead, and this would be stable. Alternatively, when updating the book you could update the link in the GitHub repository description and/or the README for the fork. I'll check your folder idea. If that's correct then that would be an excellent way to do it. I had already thought of updating the README but I'm not sure if this would be sufficient. Well, https://git.github.io/htmldocs/git.html is on GitHub Pages (for a project, that is in https://github.com/git/git.github.io repo that is also used for Git Rev News), and it obviously uses AsciiDoc. I'll check that. You can use Jekyll, or you can just upload HTML, as described in https://help.github.com/articles/creating-project-pages-manually/ (this one is for per-repo GitHub Pages, i.e. using orphan branch gh-pages, not a special named repository like e.g. git.github.io). After each change / release you would need to rebuild HTML version and upload to GitHub pages. This can be automated with hooks. I'll also look into that. These are all great suggestions, which I appreciate. I didn't do any of this for the 1st edition, which, in retrospect, was probably a mistake. BTW. I thought that Pro Git used Markdown, not AsciiDoc? Nope. Asciidoc. See https://medium.com/@chacon/living-the-future-of-technical-writing-2f368bd0a272#.fdhsp0zgj All right. One issue I have after browsing through changes is that description of changes and their granularity is severely lacking. "A few more very minor changes.", "More piddly changes.", "should have included this in last commit" are not good commit messages. You're absolutely right. I probably should have squashed those commits. Those comments aren't really intended for public consumption. Since I made many changes per commit, I really couldn't give an instructive commit message. Now that this edition is done, I plan on following good commit practices in the future. If I find time to comment on changes, I would do that on GitHub, commenting / adding notes on changes there (like the one I posted as demo: https://github.com/nobozo/progit2/commit/43ae203c2ccf1a017153de1b41a8c47eb166dba1#commitcomment-18372006 That would be great. I think I'm setup for that now in my GitHub repo for that book. Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] A Change to Commit IDs Too Ridiculous to Consider?
Those of us who write instructional material about Git all face the same problem. This is that we can't write step by step instructions that show the results of making a commit because users will always see different commit IDs. This is fundamental to the design of Git. Even if the instructional material tells users to use standard author and committer information, (e.g. john@example.com) and shows the text of the file being committed and the commit message to add, the resulting commit ID will differ from reader to reader since the commit will presumably take place at different times. What if it were possible, for instructional purposes only, to somehow tell Git to relax this requirement. By this I mean, the commit date would *not* be included when constructing the commit ID. This would allow tutorials to show exactly what to expect to see when running commands. I realize that questions would remain such as how to turn on this behavior (e.g. command line flags, environment variables) and whether 'git log' (and maybe other commands) should somehow distinguish these mutant commits. There would probably be other issues to consider. Again, this is for instructional purposes only, and only when the committer explicitly chooses to use this option. I'm *not* proposing a general change to Git's behavior. Is such a thing to ridiculous to even consider? Is there a better way to achieve the same result? Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANN] Pro Git Reedited 2nd Edition
On 7/24/2016 10:19 AM, Jakub Narębski wrote: As far as I can see you cannot view it online (without downloading). True. I changed the way the HTML file is generated so that it contains all the images downloading it is as good as viewing it online. I'm not current with the thinking about the merits of online viewing vs. downloading. Is one more accepted than the other? Also, I realized one potentially major disadvantage of sharing in Google Drive. This is that the URL will change each time I update the book. Apparently Google is taking away the ability to create a static link at the end of August 2016. If this book turns out to be popular enough that I have to change it then I'll have to revisit how to share it. Github Pages looks interesting but it isn't clear to me how to put this book there since it's written in Ascidoc. Ah. Could you tell me the summary of those changes? There are too many to summarize. Some are of the type that the proofreader should have caught, and others are my attempt to clarify things. Since I don't claim to be a Git expert it remains to be seen how successful I am. Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANN] Pro Git Reedited 2nd Edition
This an announcement of Pro Git Reedited 2nd Edition, which is a substantial edit of Chacon and Straub's Pro Git 2nd Edition. I spent a lot of time tightening it up and maybe clearing up some explanations. The pdf is downloadable at: https://drive.google.com/open?id=0B-Llso12P94-Ujg5Z1dhWUhhMm8 The complete self-contained HTML is at: https://drive.google.com/file/d/0B-Llso12P94-U3g1aDBRWjk1Sk0 The sources for this book are at: https://github.com/nobozo/progit2 I welcome comments. Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd Difference Between Windows Git and Standard Git
On 5/23/2016 4:12 AM, Johannes Schindelin wrote: What we could do is to make the default config setting platform-dependent, a la CRLF_NATIVE. I imagine that we would want this for core.filemode, core.ignorecase and core.symlinks. What do you think? Would this change have any bad effects when the same repo is shared by both Windows and *nix Git users over Dropbox or a shared filesystem? Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd Difference Between Windows Git and Standard Git
On 5/20/2016 7:19 AM, Torsten Bögershausen wrote: Great question. For all the unexpected files it says the same thing: old mode 100755 new mode 100644 So the solution is to run git config core.filemode false This worked perfectly! I wonder if this should be the default for Git for Windows. Thanks for the quick (and correct) response. Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Odd Difference Between Windows Git and Standard Git
On 5/20/2016 6:19 AM, Torsten Bögershausen wrote: On 20.05.16 03:48, Jon Forrest wrote: I'm running Git version 2.8.2 built from source on Ubuntu 16.04. I'm using a repository that's stored on Dropbox. I'm the only person accessing this repo. Everything works great. For reasons unrelated to Git, I decided to try Git for Windows, so I installed "git version 2.8.2.windows.1" on Windows 10. When I run 'git status' on Ubuntu the list I see is exactly what I expect. However, when I run 'git status' on the same Dropbox repo on Windows, I see what I expect plus I'm told that every .pdf file and some .png files are modified. To bring at least a little light into the story: What does git diff say ? Great question. For all the unexpected files it says the same thing: old mode 100755 new mode 100644 What does git config -l | grep core say ? core.symlinks=false core.autocrlf=true core.fscache=true core.editor=vim core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true And what does git ls-files --eol say? The same thing for all the unexpected files, which is: i/-text w/-text attr/ I'm running the above commands on Windows. The result of the 2nd question on Ubuntu is: core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true and the 3rd (for the expected files) is: i/lfw/lfattr/ Jon -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Odd Difference Between Windows Git and Standard Git
I'm running Git version 2.8.2 built from source on Ubuntu 16.04. I'm using a repository that's stored on Dropbox. I'm the only person accessing this repo. Everything works great. For reasons unrelated to Git, I decided to try Git for Windows, so I installed "git version 2.8.2.windows.1" on Windows 10. When I run 'git status' on Ubuntu the list I see is exactly what I expect. However, when I run 'git status' on the same Dropbox repo on Windows, I see what I expect plus I'm told that every .pdf file and some .png files are modified. I'm guessing that this is caused by some mishandling of binary files. Is this behavior to be expected? If so, is there something I can do to have the output on Windows be the same as on Ubuntu? I'm aware of 'git update-index --assume-unchanged' but this seems harsh. I copied the repo to a non-Dropbox location, just in case it was Dropbox that was causing the problem, but this didn't make any difference. (If you want to try this yourself, try it on the ProGit2 book source on Github). Thanks, Jon Forrest -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANN] Pro Git Reedited - a New Version of the Pro Git Book
When I started learning Git, I spent a fair amount of time reading Pro Git. I found that it was a 2 steps forward, 1 step back experience. By this I mean I’d learn a couple of new things but then I’d either read something I didn’t understand, or else I’d realize that my previous understanding was wrong. But, once I developed a better understanding of Git, I went back to re-read the sections that I didn’t previously understand. I’d almost always think to myself that if only this word or that phrase could be changed slightly, the concept would have been much easier to understand. This happens to me a lot when reading technical books. Given that Scott was generous enough to release Pro Git as a free book with the manuscript sources available at GitHub, I decided to return the favor by doing a complete edit in an attempt to improve the areas I had trouble with and to generally tighten up the text. I’ve fed all these changes back to the maintainer of Pro Git via GitHub pull requests. He’s free to decide what he wants to do with them. Meanwhile, I've published my own version of this book, which I call Pro Git Reedited. The PDF version of Pro Git Reedited is at https://www.dropbox.com/s/4awq55350ef235m/progitreedited.en.pdf and the source code is at https://github.com/nobozo/progitreedited I welcome your feedback. Please send any comments to me at nob...@gmail.com. To make sure I recognize them as comments about this book, please include [PGR] in the subject. Jon Forrest nob...@gmail.com -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
