{"thread":{"id":"20761","subject":"Using git to track my PhD thesis, couple of questions","startedAt":"2009-08-27T20:34:02Z","lastAt":"2009-08-31T05:47:14Z","messageCount":23,"participants":["seanh","Sverre Rabbelier","Matthieu Moy","Junio C Hamano","demerphq","Paolo Bonzini","Matthias Andree","Jakub Narebski","Avery Pennarun","david@lang.hm","Sam Vilain","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121910","messageId":"20090827203402.GC7168@kisimul","threadId":"20761","inReplyTo":null,"subject":"Using git to track my PhD thesis, couple of questions","fromName":"seanh","fromEmail":"seanh.nospam@gmail.com","sentAt":"2009-08-27T20:34:02Z","receivedAt":"2009-08-27T20:34:02Z","isPatch":false,"sender":{"key":"seanh.nospam@gmail.com","avatar":null},"body":"I'm planning to use git to track my PhD thesis as I work on it and to \nlet my supervisors track it. I've setup a git repository and a gitweb \ninstance showing it. There are a couple of specific requirements.\n\n1. My supervisors don't want to see all the little commits that I make \nday by day. So I'll commit to a dev branch, then whenever I've made \nsignificant progress will merge it into a trunk branch. I want the trunk \nbranch to get all the changes but as one big commit, not inherit all the \nlittle commits like a normal merge would do. I think this is a `git \nmerge --squash`. Btw the help for that command ends quite brilliantly: \n\"(or more in case of an octopus)\".\n\n2. They don't want to look at the latex source but the PDFs built from \nit, which they're going to annotate with their comments. So I need an \neasy way for them to get the PDF of each commit from gitweb without \nhaving to checkout the repo and build it themselves. Normally I \nwouldn't commit the PDF files into the repo because they're compiled \nfiles not source files, but it seems that just building a PDF and \ncommitting it along with each commit to trunk would be by far the \neasiest way to achieve this. But will git store the PDFs efficiently, or \nwill the repo start to get really big?\n\nThanks\n"},{"id":"121911","messageId":"fabb9a1e0908271341o3a558eedq85541e68875ab77f@mail.gmail.com","threadId":"20761","inReplyTo":"20090827203402.GC7168@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-08-27T20:41:04Z","receivedAt":"2009-08-27T20:41:04Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Aug 27, 2009 at 13:34, seanh<seanh.nospam@gmail.com> wrote:\n> 2. They don't want to look at the latex source but the PDFs built from\n> it, which they're going to annotate with their comments. So I need an\n> easy way for them to get the PDF of each commit from gitweb without\n> having to checkout the repo and build it themselves. Normally I\n> wouldn't commit the PDF files into the repo because they're compiled\n> files not source files, but it seems that just building a PDF and\n> committing it along with each commit to trunk would be by far the\n> easiest way to achieve this. But will git store the PDFs efficiently, or\n> will the repo start to get really big?\n\nIf they only care about the pdf anyway, why not have a separate branch\nto which you commit the pdf's instead?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"121913","messageId":"vpqk50pasek.fsf@bauges.imag.fr","threadId":"20761","inReplyTo":"20090827203402.GC7168@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-27T20:55:15Z","receivedAt":"2009-08-27T20:55:15Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"seanh <seanh.nospam@gmail.com> writes:\n\n> I'm planning to use git to track my PhD thesis as I work on it and to \n> let my supervisors track it. I've setup a git repository and a gitweb \n> instance showing it. There are a couple of specific requirements.\n>\n> 1. My supervisors don't want to see all the little commits that I make \n> day by day.\n\nI'm not sure I understand why you want that. From what you say, your\nsupervisors won't be looking at the LaTeX source, so they won't read\nthe diffs for the commits. Instead, they will be looking at regular\nsnapshots in PDF. So, how is that disturbing to keep the intermediate\ncommits ?\n\n> So I'll commit to a dev branch, then whenever I've made \n> significant progress will merge it into a trunk branch. I want the trunk \n> branch to get all the changes but as one big commit, not inherit all the \n> little commits like a normal merge would do. I think this is a `git \n> merge --squash`.\n\nIt is, but this also means _you_ will somehow lose your intermediate\ncommits. Well, you may not really lose them, but after a merge\n--squash, you have two options to continue working: work on top of the\nsquashed commit (and then your ancestry doesn't contain the small\nones), or work on top of your previous branches (and then, you don't\nhave a proper merge tracking, and you'll get spurious conflicts if you\ntry another merge --squash).\n\n> 2. They don't want to look at the latex source but the PDFs built from \n> it, which they're going to annotate with their comments. So I need an \n> easy way for them to get the PDF of each commit from gitweb without \n> having to checkout the repo and build it themselves.\n\nWell, they never need a PDF other than the latest version, will they?\nThen, you don't need Git to send them your PDFs, just upload the PDFs\nsomewhere where your supervisors can grab them periodically, and\nyou're done.\n\nThe issue is when they start modifying the LaTeX files: then you have\nto think of merging, and you'd better do that with a revision control\nsystem.\n\n\nI also used a revision control system to write my Ph.D (Git was born\nafter I started writting, so it wasn't Git yet), and my reviewing\nsystem has been all the more simple: when a chapter is done, send an\nemail with the PDF attached, and \"Hi, chapter $n is done, can you have\na look?\". That just works.\n\n> Normally I wouldn't commit the PDF files into the repo because\n> they're compiled files not source files, but it seems that just\n> building a PDF and committing it along with each commit to trunk\n> would be by far the easiest way to achieve this. But will git store\n> the PDFs efficiently, or will the repo start to get really big?\n\nGit will do delta-compression as it can, but I don't think PDFs will\ndelta-compress very well, so your repository may grow rather quickly,\nyes. If possible, commit the PDFs on a separate branch so that you can\neasily keep your clean history small in disk space, and discard the\nPDFs if needed.\n\n-- \nMatthieu\n"},{"id":"121921","messageId":"7v1vmxq6nw.fsf@alter.siamese.dyndns.org","threadId":"20761","inReplyTo":"20090827203402.GC7168@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-27T21:38:11Z","receivedAt":"2009-08-27T21:38:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"seanh <seanh.nospam@gmail.com> writes:\n\n> I'm planning to use git to track my PhD thesis as I work on it and to \n> let my supervisors track it. I've setup a git repository and a gitweb \n> instance showing it. There are a couple of specific requirements.\n>\n> 1. My supervisors don't want to see all the little commits that I make \n> day by day. So I'll commit to a dev branch, then whenever I've made \n> significant progress will merge it into a trunk branch. I want the trunk \n> branch to get all the changes but as one big commit, not inherit all the \n> little commits like a normal merge would do. I think this is a `git \n> merge --squash`. Btw the help for that command ends quite brilliantly: \n> \"(or more in case of an octopus)\".\n>\n> 2. They don't want to look at the latex source but the PDFs built from \n> it, which they're going to annotate with their comments. So I need an \n> easy way for them to get the PDF of each commit from gitweb without \n> having to checkout the repo and build it themselves. Normally I \n> wouldn't commit the PDF files into the repo because they're compiled \n> files not source files, but it seems that just building a PDF and \n> committing it along with each commit to trunk would be by far the \n> easiest way to achieve this. But will git store the PDFs efficiently, or \n> will the repo start to get really big?\n\nWhat I would do if I were you (and I did something similar recently while\nworking on my book) is something like this:\n\n * Keep your source in git.  Do not worry about the commit granularity.\n   Commit as often as you think makes sense.\n\n * Have a Makefile to build pdf if you have not done so.\n\n * Dedicate a separate directory, for review pupose.  Have a separate git\n   repository there.  If you choose to use an untracked subdirectory\n   'publish' of your source work tree (you do not have to), you would do\n   something like this:\n\n\t$ mkdir publish\n        $ (cd publish && git init)\n\n   Arrange things so that \"git push\" in that repository will propagate its\n   contents to the public repository your advisors will look at.\n\n * Have a 'publish' target in your Makefile, which would roughly do:\n\n\t#!/bin/sh\n\n\tmake pdf &&\n        cp paper.pdf publish/. &&\n\n        this=$(git rev-parse HEAD) &&\n        prev=$(cd publish &&\n               git show -s | sed -ne 's/^ *Changes up to: \\(.*\\)$/\\1/p'\n\t) &&\n\t{\n\t\techo \"Changes up to: $this\"\n                echo\n                case \"$prev\" in\n                '') # initial round\n                        git shortlog ;;\n                ?*)\n                        git shortlog $prev.. ;;\n                esac\n\t} >publish/log &&\n        cd publish &&\n        git add paper.pdf &&\n        git commit -F log &&\n        git push\n\n * Then when you want to submit the current status for review (perhaps you\n   would want this to happen at the end of each day, or every other day,\n   or whatever), type\n\n    $ make publish\n\nThe idea is:\n\n (1) If your source material is not interesting to your advisors at all,\n     there is no point showing, let alone the commit granularity of your\n     work; and\n\n (2) If your advisors want to see PDF and PDF only, then give them that,\n     but as you correctly said, that is a cruft from your source's point\n     of view, so do not mix them together.\n"},{"id":"121931","messageId":"9b18b3110908271521w764684cfg3b009f6960ee5dc4@mail.gmail.com","threadId":"20761","inReplyTo":"20090827203402.GC7168@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-08-27T22:21:42Z","receivedAt":"2009-08-27T22:21:42Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/8/27 seanh <seanh.nospam@gmail.com>:\n> 2. They don't want to look at the latex source but the PDFs built from\n> it, which they're going to annotate with their comments. So I need an\n> easy way for them to get the PDF of each commit from gitweb without\n> having to checkout the repo and build it themselves. Normally I\n> wouldn't commit the PDF files into the repo because they're compiled\n> files not source files, but it seems that just building a PDF and\n> committing it along with each commit to trunk would be by far the\n> easiest way to achieve this. But will git store the PDFs efficiently, or\n> will the repo start to get really big?\n\nAs you can generate the PDF's from the latex then just hack gitweb to\nlet them download it from there.\n\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"121983","messageId":"4A979690.1050601@gnu.org","threadId":"20761","inReplyTo":"vpqk50pasek.fsf@bauges.imag.fr","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-08-28T08:34:24Z","receivedAt":"2009-08-28T08:34:24Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"On 08/27/2009 10:55 PM, Matthieu Moy wrote:\n> seanh<seanh.nospam@gmail.com>  writes:\n>\n>> I'm planning to use git to track my PhD thesis as I work on it and to\n>> let my supervisors track it. I've setup a git repository and a gitweb\n>> instance showing it. There are a couple of specific requirements.\n>>\n>> 1. My supervisors don't want to see all the little commits that I make\n>> day by day.\n>\n> I'm not sure I understand why you want that. From what you say, your\n> supervisors won't be looking at the LaTeX source, so they won't read\n> the diffs for the commits. Instead, they will be looking at regular\n> snapshots in PDF. So, how is that disturbing to keep the intermediate\n> commits ?\n>\n>> So I'll commit to a dev branch, then whenever I've made\n>> significant progress will merge it into a trunk branch. I want the trunk\n>> branch to get all the changes but as one big commit, not inherit all the\n>> little commits like a normal merge would do. I think this is a `git\n>> merge --squash`.\n>\n> It is, but this also means _you_ will somehow lose your intermediate\n> commits. Well, you may not really lose them, but after a merge\n> --squash, you have two options to continue working: work on top of the\n> squashed commit (and then your ancestry doesn't contain the small\n> ones), or work on top of your previous branches (and then, you don't\n> have a proper merge tracking, and you'll get spurious conflicts if you\n> try another merge --squash).\n\nYou can also merge from the master to your working branch after every \nmerge --squash.\n\n    ... work on local ...\n    git commit\n    ... work on local ...\n    git commit\n\n    git checkout master\n    git merge --squash local; git commit -m'day 1'\n    git checkout local\n    git merge master\n\n> I also used a revision control system to write my Ph.D (Git was born\n> after I started writting, so it wasn't Git yet), and my reviewing\n> system has been all the more simple: when a chapter is done, send an\n> email with the PDF attached, and \"Hi, chapter $n is done, can you have\n> a look?\". That just works.\n\nThat's the same I did.  I used git, but only locally.  I never published \nthe repository for my supervisor, she didn't care.\n\n>> Normally I wouldn't commit the PDF files into the repo because\n>> they're compiled files not source files, but it seems that just\n>> building a PDF and committing it along with each commit to trunk\n>> would be by far the easiest way to achieve this. But will git store\n>> the PDFs efficiently, or will the repo start to get really big?\n>\n> Git will do delta-compression as it can, but I don't think PDFs will\n> delta-compress very well, so your repository may grow rather quickly,\n> yes. If possible, commit the PDFs on a separate branch so that you can\n> easily keep your clean history small in disk space, and discard the\n> PDFs if needed.\n\nThat's a good advice.  Remember to delete the branch reflog too if you \nwant to clean the history.\n\nYou can also try \\pdfcompresslevel=0, which would probably make \ndelta-compression behave better at the expense of distributing bigger \nfiles to your supervisor.  If you use hyperref, see this:\n\n    http://www.tug.org/pipermail/pdftex/2003-August/004402.html\n\nBest of all would be to have filters doing/undoing the PDF compression, \nbut I know of no free program doing this.\n\nPaolo\n"},{"id":"121985","messageId":"vpq7hwo8gxd.fsf@bauges.imag.fr","threadId":"20761","inReplyTo":"4A979690.1050601@gnu.org","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-28T08:46:06Z","receivedAt":"2009-08-28T08:46:06Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Paolo Bonzini <bonzini@gnu.org> writes:\n\n> You can also merge from the master to your working branch after every\n> merge --squash.\n\nYes, good point. I didn't think of this, but it works because ...\n\n>    ... work on local ...\n>    git commit\n>    ... work on local ...\n>    git commit\n>\n>    git checkout master\n>    git merge --squash local; git commit -m'day 1'\n\n... this should fast-forward, so get the same tree as in branch\n'local' and ...\n\n>    git checkout local\n>    git merge master\n\n... then this is a merge of two identical trees, so it's trivial.\n\n-- \nMatthieu\n"},{"id":"122001","messageId":"20090828133708.GA11146@kisimul","threadId":"20761","inReplyTo":"vpq7hwo8gxd.fsf@bauges.imag.fr","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"seanh","fromEmail":"seanh.nospam@gmail.com","sentAt":"2009-08-28T13:37:08Z","receivedAt":"2009-08-28T13:37:08Z","isPatch":false,"sender":{"key":"seanh.nospam@gmail.com","avatar":null},"body":"Wow, really helpful responses, thanks a lot.\n\nI think having read all this that I'll do it manually. I'll still use \ngit to track my latex source and will commit to it as often as I like \nand not worry about commit granularity. Whenever I've finished a \nsignificant chunk I'll add a PDF of it to a manually edited web page \nalong with a description of what changed since the last time I added a \nPDF. I can use git log etc to help write the manual changelog. My \nsupervisors can just look at this manually constructed page and if it \ngets too big I'll just archive the oldest PDFs. I can tag the git repo \nat the points where I add a PDF to the web page. I guess this is pretty \nclose to what software projects do with version releases and their \npublic website.\n\nOn Thu, Aug 27, 2009 at 01:41:04PM -0700, Sverre Rabbelier wrote:\n> If they only care about the pdf anyway, why not have a separate branch\n> to which you commit the pdf's instead?\n\nWell I was thinking they'd look at the changelogs with the diffs showing \nexactly what changed in the latex source files, which should be pretty \nself-explanatory, but then when they wanted to read a whole chapter and \nadd comments to it they'd want the PDF not the latex.\n\nI don't really understand the script Junio posted (not literate in sh) \nbut I think it might have something to do with copying changelogs over \nfrom the source repo to a PDFs repo.\n \nOn Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:\n> As you can generate the PDF's from the latex then just hack gitweb to\n> let them download it from there.\n\nUnfortunately gitweb is written in Perl. But I know what you mean, it \nshould in theory be possible for them to click on a 'Get PDF' link for a \nparticular revision that causes the PDF to be built and returned to \ntheir browser.\n\nIn response to Matthieu and Paolo, I'm not sure I understand the git \ninternals involved in the discussion around merge --squash, I had a \nfeeling this would produce a 'merge' that git in some sense would 'not \nknow about', since it sounds complex and I don't understand it I don't \nthink I want to go there.\n\nThanks all\n"},{"id":"122002","messageId":"vpqpragt5bo.fsf@bauges.imag.fr","threadId":"20761","inReplyTo":"20090828133708.GA11146@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-28T13:51:07Z","receivedAt":"2009-08-28T13:51:07Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"seanh <seanh.nospam@gmail.com> writes:\n\n> In response to Matthieu and Paolo, I'm not sure I understand the git \n> internals involved in the discussion around merge --squash, I had a \n> feeling this would produce a 'merge' that git in some sense would 'not \n> know about',\n\nYes, that's it. Git does a merge, and immediately forgets it was a\nmerge. The consequence is when you merge again later, Git will not be\nable to use the merge information to be clever about merging. Somehow,\nGit will be as bad as SVN for merging if you don't know what you're\ndoing ;-).\n\n> since it sounds complex and I don't understand it I don't think I\n> want to go there.\n\nWell, it's fun also to learn Git notions in more details ;-).\n\n-- \nMatthieu\n"},{"id":"122003","messageId":"4A97E1B1.7090107@gmx.de","threadId":"20761","inReplyTo":"vpqpragt5bo.fsf@bauges.imag.fr","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2009-08-28T13:54:57Z","receivedAt":"2009-08-28T13:54:57Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"Matthieu Moy schrieb:\n> seanh <seanh.nospam@gmail.com> writes:\n> \n>> In response to Matthieu and Paolo, I'm not sure I understand the git \n>> internals involved in the discussion around merge --squash, I had a \n>> feeling this would produce a 'merge' that git in some sense would 'not \n>> know about',\n> \n> Yes, that's it. Git does a merge, and immediately forgets it was a\n> merge. The consequence is when you merge again later, Git will not be\n> able to use the merge information to be clever about merging. Somehow,\n> Git will be as bad as SVN for merging if you don't know what you're\n> doing ;-).\n\nTo be fair, SVN versions 1.5 and newer can track merges. If the repository\npredates 1.5, it has to be updated on the server side (see the release notes for\ndetails). It just tracks which revisions have been merged and which not, for\nfurther details, see the svn book. (http://svnbook.red-bean.com/ IIRC)\n"},{"id":"122006","messageId":"m3ocq0km5m.fsf_-_@localhost.localdomain","threadId":"20761","inReplyTo":"4A97E1B1.7090107@gmx.de","subject":"Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-28T15:12:27Z","receivedAt":"2009-08-28T15:12:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Matthias Andree <matthias.andree@gmx.de> writes:\n> Matthieu Moy schrieb:\n>> seanh <seanh.nospam@gmail.com> writes:\n>> \n>>> In response to Matthieu and Paolo, I'm not sure I understand the git \n>>> internals involved in the discussion around merge --squash, I had a \n>>> feeling this would produce a 'merge' that git in some sense would 'not \n>>> know about',\n>> \n>> Yes, that's it. Git does a merge, and immediately forgets it was a\n>> merge. The consequence is when you merge again later, Git will not be\n>> able to use the merge information to be clever about merging. Somehow,\n>> Git will be as bad as SVN for merging if you don't know what you're\n>> doing ;-).\n> \n> To be fair, SVN versions 1.5 and newer can track merges. If the\n> repository predates 1.5, it has to be updated on the server side\n> (see the release notes for details). It just tracks which revisions\n> have been merged and which not, for further details, see the svn\n> book. (http://svnbook.red-bean.com/ IIRC)\n\n>From what I understand (from what I have read, and browsed, and\nlurged, and noticed) is that Subversion 1.5+ does merge tracking, but\nin very different way that in Git:\n\n * the svn:mergeinfo is client-side property; if I understand\n   correctly this would help you in repeated merges, but not anyone\n   other\n\n * svn:mergeinfo contains _per-file_ merge info, so it is much, much\n   more \"chatty\" than Git multiple parents.  This might be more\n   powerfull approach, in the same sense that more advanced merge\n   strategies that 3-way merge were more powerfull -- but 3-way merge\n   is best because it is simple (and either it is simple that 3-way\n   merge is enough, or complicated so manual intervention is required).\n\n * You have to explicitely enable using svn:mergeinfo in log and blame\n\n * The command to merge trunk into branch is different from command to\n   merge branch into trunk.\n\nAlso IIRC there is warning (well, at least there was in Subversion 1.5\nrelease notes) that merge tracking doesn't work entirely correctly in\nthe face of criss-cross merges (multiple merge bases) and renaming\n(although I do hope that they fixed problem with silent corruption if\nthere is rename during merge).\n\n-- \nJakub Narebski\n\nGit User's Survey 2009: http://tinyurl.com/GitSurvey2009\n"},{"id":"122008","messageId":"32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com","threadId":"20761","inReplyTo":"m3ocq0km5m.fsf_-_@localhost.localdomain","subject":"Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-28T15:29:03Z","receivedAt":"2009-08-28T15:29:03Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:\n> From what I understand (from what I have read, and browsed, and\n> lurged, and noticed) is that Subversion 1.5+ does merge tracking, but\n> in very different way that in Git:\n>\n>  * the svn:mergeinfo is client-side property; if I understand\n>   correctly this would help you in repeated merges, but not anyone\n>   other\n\nI don't believe there is such a thing as a \"client-side property\" in\nsvn.  I see someone said this on stackoverflow\n(http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)\nbut I'm pretty sure they were either mistaken or using a different\ndefinition of \"client-side.\"\n\nI think they probably meant that it's the client's responsibility to\nset the property correctly, not the server's, and if your client is\ntoo old any you do a merge, it'll forget to set svn:mergeinfo, causing\nconfusion for everyone.  There's discussion in the svn book\n(http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but\nnothing implies that it's a non-replicated property.  Indeed, I can\nsee no particular reason that anyone would want it to be, for the\nreasons you specify.\n\n>  * svn:mergeinfo contains _per-file_ merge info, so it is much, much\n>   more \"chatty\" than Git multiple parents.  This might be more\n>   powerfull approach, in the same sense that more advanced merge\n>   strategies that 3-way merge were more powerfull -- but 3-way merge\n>   is best because it is simple (and either it is simple that 3-way\n>   merge is enough, or complicated so manual intervention is required).\n\nsvn people really love their cherry-picks and want to keep track of\nwhich things get cherry picked from one branch to another.  This is\nnice (at least for informational purposes) although they go through\nsome probably-unnecessary contortions *after* doing this, including\nsplitting a merge from \"maint\" into \"master\" into two sequential\nmerges, if you've previously cherry-picked a commit from master into\nmaint.  The above svn book link describes this in a bit more detail.\n\nI don't think that behaviour would be much help in any situation I've\never experienced, so I agree with your comment that 3-way merge is\ngenerally better.\n\nTracking cherry picks in git would be really nice *sometimes*, but it\ncreates a tradeoff where you then have to slurp in huge amounts of\nhistory that you might not want.  In svn, this tradeoff doesn't exist,\nsince anything you cherry pick must have already existed on the server\nanyway, and can never go away.\n\n>  * You have to explicitely enable using svn:mergeinfo in log and blame\n\nConversely, in git you can basically disable it using --first-parent,\nwhich is sometimes handy.  (It's handiest if your team has a policy of\nalways using --no-ff when merging into trunk, which makes git act a\nbit more like svn's merge tracking.  I realize this is a bit heretical\nto suggest on the git list, but I appreciate that the option exists\ndespite its heresy :))\n\nHave fun,\n\nAvery\n"},{"id":"122010","messageId":"op.uzdpzqr11e62zd@balu.cs.uni-paderborn.de","threadId":"20761","inReplyTo":"32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com","subject":"Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2009-08-28T15:44:04Z","receivedAt":"2009-08-28T15:44:04Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"Am 28.08.2009, 17:29 Uhr, schrieb Avery Pennarun <apenwarr@gmail.com>:\n\n> I think they probably meant that it's the client's responsibility to\n> set the property correctly, not the server's, and if your client is\n> too old any you do a merge, it'll forget to set svn:mergeinfo, causing\n> confusion for everyone.  There's discussion in the svn book\n> (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but\n> nothing implies that it's a non-replicated property.  Indeed, I can\n> see no particular reason that anyone would want it to be, for the\n> reasons you specify.\n\nIt is replicated, and the common remedy against older clients is to refuse  \ncommits from those clients that do not support mergeinfo. This is done by  \ndefining a repository hook on the server side that validates this. AFAIR  \nsuch a hook example ships with SVN.\n\n-- \nMatthias Andree\n"},{"id":"122011","messageId":"4A97FCC4.5070808@gnu.org","threadId":"20761","inReplyTo":"20090828133708.GA11146@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2009-08-28T15:50:28Z","receivedAt":"2009-08-28T15:50:28Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"On 08/28/2009 03:37 PM, seanh wrote:\n> In response to Matthieu and Paolo, I'm not sure I understand the git\n> internals involved in the discussion around merge --squash, I had a\n> feeling this would produce a 'merge' that git in some sense would 'not\n> know about', since it sounds complex and I don't understand it I don't\n> think I want to go there.\n\nYes, the problem is that git does not track what happens when you do \n\"git merge --squash\", which makes it harder to do merges after some time \n(because of conflicts).\n\nThe solution I gave (and Matthieu explained how it works, even though \nit's very technical) is a way to \"explain\" git what you did.  If you try \nit on a fake example with gitk, you should understand it better.\n\n    mkdir test\n    cd test\n\n    # import\n    git init\n    echo a > test\n    git add a\n    git commit -m1\n\n    # some changes happen in your local \"fine grained\" branch\n    git checkout -b local\n    echo b > test\n    git commit -a -m2\n    echo c >> test\n    git commit -a -m3                                  ##<<<\n\n    # the magic incantation brings those commit to master\n    # (first two commands) and teaches git what happened (last two)\n    git checkout master\n    git merge --squash local; git commit -m'merge 1'   ##<<<\n    git checkout local\n    git merge master                                   ##<<<\n\n    # more local changes\n    sed -i s/b/d/ test\n    git commit -a -m4\n    echo z >> test\n    git commit -a -m5                                  ##<<<\n\n    # the magic incantation, again\n    git checkout master\n    git merge --squash local; git commit -m'merge 1'   ##<<<\n    git checkout local\n    git merge master                                   ##<<<\n\nUse gitk at the points indicated with ##<<<\n\nIt is actually very similar to what you chose to do.  My commits to \nmaster, in practice, are your tags.  You may want to see how gitk's \ngraphs looks in both scenarios, and choose the one that you prefer.\n\nHope this helps!\n\nPaolo\n"},{"id":"122013","messageId":"9b18b3110908280912o271dc095o67bc82b31e91680e@mail.gmail.com","threadId":"20761","inReplyTo":"20090828133708.GA11146@kisimul","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-08-28T16:12:41Z","receivedAt":"2009-08-28T16:12:41Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/8/28 seanh <seanh.nospam@gmail.com>:\n> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:\n>> As you can generate the PDF's from the latex then just hack gitweb to\n>> let them download it from there.\n>\n> Unfortunately gitweb is written in Perl. But I know what you mean, it\n> should in theory be possible for them to click on a 'Get PDF' link for a\n> particular revision that causes the PDF to be built and returned to\n> their browser.\n\nWhat is unfortunate about that? Perl is a duct tape/swiss-army-knife\nof the internet.  Hacking gitweb to generate PDF's on the fly from\nlatex documents should be a fairly trivial hack, even if you aren't a\nPerl hacker.\n\nSee:\n\nhttp://search.cpan.org/~andrewf/LaTeX-Driver-0.08/lib/LaTeX/Driver.pm\n\nfor just one of many Perl modules to interface with with LaTeX.\n\nGood luck.\n\nYves\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"122014","messageId":"200908281819.10135.jnareb@gmail.com","threadId":"20761","inReplyTo":"32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com","subject":"Re: Merging in Subversion 1.5","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2009-08-28T16:19:06Z","receivedAt":"2009-08-28T16:19:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 28 Aug 2009, Avery Pennarun wrote:\n> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:\n\n> > From what I understand (from what I have read, and browsed, and\n> > lurged, and noticed) is that Subversion 1.5+ does merge tracking, but\n> > in very different way that in Git:\n> >\n> >  * the svn:mergeinfo is client-side property; if I understand\n> >   correctly this would help you in repeated merges, but not anyone\n> >   other\n> \n> I don't believe there is such a thing as a \"client-side property\" in\n> svn.\n\nWhat about svn:ignore or svn:mimetype (IIRC) property?\n\n> I see someone said this on stackoverflow \n> (http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)\n> but I'm pretty sure they were either mistaken or using a different\n> definition of \"client-side.\"\n\nI think I got this (wrong?) impression from there.\n\n> >  * svn:mergeinfo contains _per-file_ merge info, so it is much, much\n> >   more \"chatty\" than Git multiple parents.  This might be more\n> >   powerfull approach, in the same sense that more advanced merge\n> >   strategies that 3-way merge were more powerfull -- but 3-way merge\n> >   is best because it is simple (and either it is simple that 3-way\n> >   merge is enough, or complicated so manual intervention is required).\n> \n> svn people really love their cherry-picks and want to keep track of\n> which things get cherry picked from one branch to another.  This is\n> nice (at least for informational purposes) although they go through\n> some probably-unnecessary contortions *after* doing this, including\n> splitting a merge from \"maint\" into \"master\" into two sequential\n> merges, if you've previously cherry-picked a commit from master into\n> maint.  The above svn book link describes this in a bit more detail.\n> \n> I don't think that behaviour would be much help in any situation I've\n> ever experienced, so I agree with your comment that 3-way merge is\n> generally better.\n\nErrr... what I meant here that I have read (on some blog, but either\nI didn't bookmark it, or I can't find the bookmark) that svn:mergeinfo\nis not as simple as listing _revisions_ which are merged (i.e. either\nall parents, or additional parent), but it lists per-file merge \ninformation, and can be quite large.\n \n> >  * You have to explicitely enable using svn:mergeinfo in log and blame\n> \n> Conversely, in git you can basically disable it using --first-parent,\n> which is sometimes handy. [...]\n\nIn git-log.  But in git-blame?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"122016","messageId":"op.uzdr2j0n1e62zd@balu.cs.uni-paderborn.de","threadId":"20761","inReplyTo":"200908281819.10135.jnareb@gmail.com","subject":"Re: Merging in Subversion 1.5","fromName":"Matthias Andree","fromEmail":"matthias.andree@gmx.de","sentAt":"2009-08-28T16:28:57Z","receivedAt":"2009-08-28T16:28:57Z","isPatch":false,"sender":{"key":"matthias.andree@gmx.de","avatar":null},"body":"[culling most of Cc: list]\n\nAm 28.08.2009, 18:19 Uhr, schrieb Jakub Narebski <jnareb@gmail.com>:\n\n> On Fri, 28 Aug 2009, Avery Pennarun wrote:\n>> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:\n>\n>> > From what I understand (from what I have read, and browsed, and\n>> > lurged, and noticed) is that Subversion 1.5+ does merge tracking, but\n>> > in very different way that in Git:\n>> >\n>> >  * the svn:mergeinfo is client-side property; if I understand\n>> >   correctly this would help you in repeated merges, but not anyone\n>> >   other\n>>\n>> I don't believe there is such a thing as a \"client-side property\" in\n>> svn.\n>\n> What about svn:ignore or svn:mimetype (IIRC) property?\n\nAll this is committed to the repository, so there isn't a question of if  \nit's client-side in a sense of \"local to the client/checkout\". Some  \nproperties (such as svn:mergeinfo) require a bit of additional server-side  \nsupport, but that's about it.\n\nOh, and to complicate matters, let me mention revprops (such as  \nsvn:log).   SCNR :^)\n\n-- \nMatthias Andree\n"},{"id":"122017","messageId":"32541b130908280934m67a86837pb53f5effc0f514bd@mail.gmail.com","threadId":"20761","inReplyTo":"200908281819.10135.jnareb@gmail.com","subject":"Re: Merging in Subversion 1.5","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-28T16:34:30Z","receivedAt":"2009-08-28T16:34:30Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Fri, Aug 28, 2009 at 4:19 PM, Jakub Narebski<jnareb@gmail.com> wrote:\n> On Fri, 28 Aug 2009, Avery Pennarun wrote:\n>> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:\n>> >  * You have to explicitely enable using svn:mergeinfo in log and blame\n>>\n>> Conversely, in git you can basically disable it using --first-parent,\n>> which is sometimes handy. [...]\n>\n> In git-log.  But in git-blame?\n\nI don't know about git-blame, as I rarely use it.  If it doesn't\nsupport --first-parent, I imagine it would be easy to add, if it were\nimportant to someone.\n\nAvery\n"},{"id":"122058","messageId":"alpine.DEB.2.00.0908281442050.28411@asgard.lang.hm","threadId":"20761","inReplyTo":"vpqpragt5bo.fsf@bauges.imag.fr","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-08-28T21:42:24Z","receivedAt":"2009-08-28T21:42:24Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 28 Aug 2009, Matthieu Moy wrote:\n\n> seanh <seanh.nospam@gmail.com> writes:\n>\n>> In response to Matthieu and Paolo, I'm not sure I understand the git\n>> internals involved in the discussion around merge --squash, I had a\n>> feeling this would produce a 'merge' that git in some sense would 'not\n>> know about',\n>\n> Yes, that's it. Git does a merge, and immediately forgets it was a\n> merge. The consequence is when you merge again later, Git will not be\n> able to use the merge information to be clever about merging. Somehow,\n> Git will be as bad as SVN for merging if you don't know what you're\n> doing ;-).\n\nI thought that was what rere did?\n\nDavid Lang\n"},{"id":"122059","messageId":"alpine.DEB.2.00.0908281443070.28411@asgard.lang.hm","threadId":"20761","inReplyTo":"9b18b3110908280912o271dc095o67bc82b31e91680e@mail.gmail.com","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-08-28T21:44:29Z","receivedAt":"2009-08-28T21:44:29Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 28 Aug 2009, demerphq wrote:\n\n> 2009/8/28 seanh <seanh.nospam@gmail.com>:\n>> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:\n>>> As you can generate the PDF's from the latex then just hack gitweb to\n>>> let them download it from there.\n>>\n>> Unfortunately gitweb is written in Perl. But I know what you mean, it\n>> should in theory be possible for them to click on a 'Get PDF' link for a\n>> particular revision that causes the PDF to be built and returned to\n>> their browser.\n>\n> What is unfortunate about that? Perl is a duct tape/swiss-army-knife\n> of the internet.  Hacking gitweb to generate PDF's on the fly from\n> latex documents should be a fairly trivial hack, even if you aren't a\n> Perl hacker.\n\nI have a situation where I need to generae pdf's from files that are under \ngit. I have a git repository on by webserver that I push to and have a \ntrigger that regenerates the pdfs any time there is a push.\n\nDavid Lang\n\n> See:\n>\n> http://search.cpan.org/~andrewf/LaTeX-Driver-0.08/lib/LaTeX/Driver.pm\n>\n> for just one of many Perl modules to interface with with LaTeX.\n>\n> Good luck.\n>\n> Yves\n>\n>\n"},{"id":"122062","messageId":"9b18b3110908281516w463522b3pb3562b8f0cb9fb03@mail.gmail.com","threadId":"20761","inReplyTo":"alpine.DEB.2.00.0908281443070.28411@asgard.lang.hm","subject":"Re: Using git to track my PhD thesis, couple of questions","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2009-08-28T22:16:10Z","receivedAt":"2009-08-28T22:16:10Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"2009/8/28  <david@lang.hm>:\n> On Fri, 28 Aug 2009, demerphq wrote:\n>\n>> 2009/8/28 seanh <seanh.nospam@gmail.com>:\n>>>\n>>> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:\n>>>>\n>>>> As you can generate the PDF's from the latex then just hack gitweb to\n>>>> let them download it from there.\n>>>\n>>> Unfortunately gitweb is written in Perl. But I know what you mean, it\n>>> should in theory be possible for them to click on a 'Get PDF' link for a\n>>> particular revision that causes the PDF to be built and returned to\n>>> their browser.\n>>\n>> What is unfortunate about that? Perl is a duct tape/swiss-army-knife\n>> of the internet.  Hacking gitweb to generate PDF's on the fly from\n>> latex documents should be a fairly trivial hack, even if you aren't a\n>> Perl hacker.\n>\n> I have a situation where I need to generae pdf's from files that are under\n> git. I have a git repository on by webserver that I push to and have a\n> trigger that regenerates the pdfs any time there is a push.\n\nActually this discussion makes me think that there is room for a hack\nto gitweb to provide extensible and pluggable renderers of the files\nin a repository. Such a framework would for instance provide for\nsyntax highlighting, PDF generation from latex files, etc.\n\nHypothetically it wouldnt be too hard to do. A Win32 (dare I say)\nregistry of file extensions/shebang lines would be linked into a set\nof renderer plugin's, which in turn would automatically add the\nrequired links to render the file as needed. Quite doable actually.\n\nYves\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"122127","messageId":"1251661316.25764.4.camel@maia.lan","threadId":"20761","inReplyTo":"m3ocq0km5m.fsf_-_@localhost.localdomain","subject":"Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-30T19:41:56Z","receivedAt":"2009-08-30T19:41:56Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:\n>  * svn:mergeinfo contains _per-file_ merge info, so it is much, much\n>    more \"chatty\" than Git multiple parents.\n\nIt can.  But more often, if you're merging complete paths, you will get\ncomplete revision ranges.\n\nSee eg\nhttps://trac.parrot.org/parrot/browser/trunk\n\nNote how trac is also hiding the branches that were subsequently deleted\nfrom the mergeinfo ticket.\n\n>  * The command to merge trunk into branch is different from command to\n>    merge branch into trunk.\n\nThis is a caveat of url-based branches.\n\n> Also IIRC there is warning (well, at least there was in Subversion 1.5\n> release notes) that merge tracking doesn't work entirely correctly in\n> the face of criss-cross merges (multiple merge bases) and renaming\n> (although I do hope that they fixed problem with silent corruption if\n> there is rename during merge).\n\nNot sure about that one.  I also heard - unconfirmed - that things start\nto go awry if you start branching off branches and merging around the\nplace.  But if that happens it's likely a bug rather than a design flaw\n(I think).\n\nSam\n"},{"id":"122165","messageId":"20090831054714.GA6060@dpotapov.dyndns.org","threadId":"20761","inReplyTo":"1251661316.25764.4.camel@maia.lan","subject":"Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2009-08-31T05:47:14Z","receivedAt":"2009-08-31T05:47:14Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Aug 31, 2009 at 07:41:56AM +1200, Sam Vilain wrote:\n> On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:\n> \n> > Also IIRC there is warning (well, at least there was in Subversion 1.5\n> > release notes) that merge tracking doesn't work entirely correctly in\n> > the face of criss-cross merges (multiple merge bases) and renaming\n> > (although I do hope that they fixed problem with silent corruption if\n> > there is rename during merge).\n> \n> Not sure about that one.  I also heard - unconfirmed - that things start\n> to go awry if you start branching off branches and merging around the\n> place.  But if that happens it's likely a bug rather than a design flaw\n> (I think).\n\nSome of the initial issues that existed in SVN 1.5.0 have been resolved,\nbut some others remain. Here is one bug report related to merge:\nhttp://subversion.tigris.org/issues/show_bug.cgi?id=2897\nIt was reported two years ago, but the problem is still not fixed.\nAnd there is a few others (some of them even older but even with less\nprospect of being fixed any time soon):\nhttp://subversion.tigris.org/issues/show_bug.cgi?id=2837\nhttp://subversion.tigris.org/issues/show_bug.cgi?id=2898\nhttp://subversion.tigris.org/issues/show_bug.cgi?id=3056\nhttp://subversion.tigris.org/issues/show_bug.cgi?id=3157\n\nI don't think they would exist for long if they were ease to fix.  Merge\nin Subversion is essence automatic cherry-picking, and it is not easy to\nimplement that in the way it would be reasonably fast and work correctly\nin a general case.\n\nDarcs is probably the best when it comes to cherry-picking but clearly\nit is not a speed demon. In case of Subversion, the problem is worse,\nbecause it has to make decision on a per file basis rather than operate\neach patch as a unit. So, it is even more difficult to implement that\ncorrectly and efficiently.\n\nWhat you can do relatively simple is to handle a of one directional\nmerge, and that was the primary design goal of Subversion merge\ntracking feature.\n\nHere is what Daniel Berlin wrote about it:\n<<<\nThe initial merge tracking implementation was not meant to handle\nrepeated bidirectional merging, at least, as designed.\n\nIt was designed to allow cherry picks, and mainly for maintaining\nfeature branches that were mostly one way merges, with the very\noccasional merge in the other direction and then branch death :).\n\nFor these cases, it works out fine.\n\nFor more complex cyclical merge patterns, you really can't use what\nwe've got. Trying to work around these cases, or build algorithms\nthat handle them, is just going to lead you into 20 years of edge\ncases that made people come up with changeset dags in the first place.\n>>>\nSource: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=892215\n\nSo, I do not think that SVN merge will ever work correctly for those\nedge cases.\n\nBut even if Subversion learns how to handle all those complex cases\ncorrectly, it will still come with some surprises. One of the main\nadvantage of the simple 3-way merge is that it is easy to understand\nand it makes the right thing most of time. Linus provided a really good\nexplanation of it here:\nhttp://thread.gmane.org/gmane.comp.version-control.git/60457/focus=60644\n\n\nDmitry\n"}]}