{"thread":{"id":"1843","subject":"Re: Newbie falls at first hurdle","startedAt":"2005-09-18T01:35:03Z","lastAt":"2007-01-13T21:47:42Z","messageCount":13,"participants":["Horst von Brand","Martin Langhoff","Alan Chandler","Junio C Hamano","Linus Torvalds","Sven Verdoolaege","Horst H. von Brand","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"8768","messageId":"200509180135.j8I1Z34n023252@inti.inf.utfsm.cl","threadId":"1843","inReplyTo":"alan@chandlerfamily.org.uk","subject":"Re: Newbie falls at first hurdle","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-18T01:35:03Z","receivedAt":"2005-09-18T01:35:03Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Alan Chandler wrote:\n\n[...]\n\n> I have already got a working directory (or rather a directory hierarchy)\n> of an application with files (combination of html and java), and I need\n> to start applying some control to it. The Tutorial unfortunately does\n> not cover this case. Nevertheless I have proceeded.\n\nThe easiest way of doing this is using cogito (near where you found\ngit). It automates some tasks using git as backendq, in this case it would\nonly need:\n\n cg-init\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8774","messageId":"46a038f9050918035436352f71@mail.gmail.com","threadId":"1843","inReplyTo":"200509180135.j8I1Z34n023252@inti.inf.utfsm.cl","subject":"Re: Newbie falls at first hurdle","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-18T10:54:10Z","receivedAt":"2005-09-18T10:54:10Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/18/05, Horst von Brand wrote:\n> The easiest way of doing this is using cogito (near where you found\n> git). It automates some tasks using git as backendq, in this case it would\n> only need:\n> \n> cg-init\n\n+1 -- I work with a small team and we are migrating to cogito/git.\nThere's still a few things we have to call git utilities for (change\nbranch, for instance) but for \"intuitive\" usage, cogito is the cat's\nwhiskers.\n\ncheers,\n\n\nmartin\n"},{"id":"8776","messageId":"200509181347.11403.alan@chandlerfamily.org.uk","threadId":"1843","inReplyTo":"46a038f9050918035436352f71@mail.gmail.com","subject":"Re: Newbie falls at first hurdle","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2005-09-18T12:47:11Z","receivedAt":"2005-09-18T12:47:11Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Sunday 18 Sep 2005 11:54, Martin Langhoff wrote:\n> On 9/18/05, Horst von Brand wrote:\n> > The easiest way of doing this is using cogito (near where you found\n> > git). It automates some tasks using git as backendq, in this case it\n> > would only need:\n> >\n> > cg-init\n>\n> +1 -- I work with a small team and we are migrating to cogito/git.\n> There's still a few things we have to call git utilities for (change\n> branch, for instance) but for \"intuitive\" usage, cogito is the cat's\n> whiskers.\n\nYes - I had increasingly believed that with all the scripts being generated \nwith git that cogito was becoming irrelevant. However experience of the last \nday has shown me that is far from the case.\n\nI really like cg-commit where it lists the files its going to commit for you, \nand where if you delete the line it doesn't. If I've been doing a bit too \nmany things at once it helps commit in small chunks\n\nSeems cogito branch handling only really deals with linking to others. I have \nended up also using git branch and git checkout -f to keep lots of little \nlocal branches in my repository.\n\nStill struggling with how to cherry pick parts a previous update (between \npossibly two other branches) and apply them to a current branch - all the \ntutorials assume you want it all, and I can't really understand what the \ncherry pick commands do from their manuals.\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"8785","messageId":"7vek7m5m0z.fsf@assigned-by-dhcp.cox.net","threadId":"1843","inReplyTo":"200509181347.11403.alan@chandlerfamily.org.uk","subject":"Re: Newbie falls at first hurdle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T17:22:04Z","receivedAt":"2005-09-18T17:22:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Chandler writes:\n\n> Yes - I had increasingly believed that with all the scripts being generated \n> with git that cogito was becoming irrelevant.\n\nThat is not going to happen.\n\nThe point of git barebone Porcelain (or Porcelainish commands)\nis to give minimally usable UI on top of Plumbing tools for\npeople who like to get their hands dirty, and sometimes to\ndemonstrate how to take advantage of new core features before\nPorcelains start using them. It is not about competing with\nreal Porcelains.\n\n> Still struggling with how to cherry pick parts a previous\n> update (between possibly two other branches) and apply them to\n> a current branch - all the tutorials assume you want it all,\n> and I can't really understand what the cherry pick commands do\n> from their manuals.\n\nAn example to pick a couple of commits from one branch to another.\n\n $ git show-branch master pu\n * [mister] Improve the safety check used in fetch.c\n ! [pu] Merge branch 'nuker' of .; branch 'merge' of .\n --\n + [pu] Merge branch 'nuker' of .; branch 'merge' of .\n + [pu^3] Use git-merge instead of git-resolve in git-pull.\n + [pu^2] Add two options to diffcore.\n + [pu^2~1] Diff cleanup.\n + [pu^2~2] Retire rev-tree.\n + [pu^2~3] Retire git-export.\n ++ [mister] Improve the safety check used in fetch.c\n\nLet's cherry-pick two commits from pu branch:\n\n $ git cherry-pick pu^3 ; git cherry-pick pu^2~2\n\nThen the result looks like this:\n\n $ git show-branch mister pu\n * [mister] Retire rev-tree.\n ! [pu] Merge branch 'nuker' of .; branch 'merge' of .\n --\n + [pu] Merge branch 'nuker' of .; branch 'merge' of .\n + [pu^3] Use git-merge instead of git-resolve in git-pull.\n + [pu^2] Add two options to diffcore.\n + [pu^2~1] Diff cleanup.\n + [pu^2~2] Retire rev-tree.\n + [pu^2~3] Retire git-export.\n + [mister] Retire rev-tree.\n + [mister~1] Use git-merge instead of git-resolve in git-pull.\n ++ [pu~1] Improve the safety check used in fetch.c\n\nNote that new two commits are _not_ the same commit objects you\ncherry picked from the pu branch. They are new commits that\nintroduce changes equivalent to them.\n"},{"id":"8792","messageId":"Pine.LNX.4.58.0509181033520.26803@g5.osdl.org","threadId":"1843","inReplyTo":"7vek7m5m0z.fsf@assigned-by-dhcp.cox.net","subject":"Re: Newbie falls at first hurdle","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-18T17:40:06Z","receivedAt":"2005-09-18T17:40:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 18 Sep 2005, Junio C Hamano wrote:\n> \n> An example to pick a couple of commits from one branch to another.\n\nYour examples scare even me.\n\nHow about you add this to the tutorial as an \"advanced usage\" example, and \nexplain everything that was done in terms of what the \"stupid usage\" \nexamples earlier in the tutorial did.\n\nIn other words, you'd have to explain what \"pu^2~3\" means.\n\nAnd octopus merges, for that matter. I don't think the tutorial ever \nexplains those.\n\n\t\tLinus\n"},{"id":"8794","messageId":"7vzmqa2reb.fsf@assigned-by-dhcp.cox.net","threadId":"1843","inReplyTo":"Pine.LNX.4.58.0509181033520.26803@g5.osdl.org","subject":"Re: Newbie falls at first hurdle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T17:54:20Z","receivedAt":"2005-09-18T17:54:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> In other words, you'd have to explain what \"pu^2~3\" means.\n>\n> And octopus merges, for that matter. I don't think the tutorial ever \n> explains those.\n\nSorry, my excuses are (1) I just did a quick example from a tree\nI had handy -- my live tree; (2) as long as the user knows the\ncommit show-branch labeled with the cryptic \"pu^2~3\" is the one\ns/he wants, it does not matter much what that label exactly\nmeans.\n\nBut of course you are right.\n"},{"id":"8800","messageId":"46a038f90509181206643bce7@mail.gmail.com","threadId":"1843","inReplyTo":"200509181347.11403.alan@chandlerfamily.org.uk","subject":"Re: Newbie falls at first hurdle","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-18T19:06:39Z","receivedAt":"2005-09-18T19:06:39Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/19/05, Alan Chandler wrote:\n> Still struggling with how to cherry pick parts a previous update (between\n> possibly two other branches) and apply them to a current branch - all the\n> tutorials assume you want it all, and I can't really understand what the\n> cherry pick commands do from their manuals.\n\nForget the cherry pick commands -- here's a usable, easy strategy.\n\ngit-checkout the \"source\" branch, create a temporary directory to hold\nthe patches, and call\n\n git-format-patch --mbox -o patchdir destbranch\n\nThis will create one file per patch in the destination directory. Feel\nfree to delete patches you don't want, and edit the patches you've got\nthere. Then switch to the destination branch, and use git-applymbox to\nmerge them in.\n\nIf you do this repeatedly, git-format-patch will not reexport patches\nyou've merged to the destination branch already (if they merged\ncleanly unchanged)... or at least that's the theory ;)\n\nThe only limitation I've found in this strategy is that it doesn't\ndeal with binary objects. I'm lost as to what to do in those cases.\n\ncheers,\n\n\nmartin\n"},{"id":"8802","messageId":"200509182011.10689.alan@chandlerfamily.org.uk","threadId":"1843","inReplyTo":"7vek7m5m0z.fsf@assigned-by-dhcp.cox.net","subject":"Re: Newbie falls at first hurdle","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2005-09-18T19:11:10Z","receivedAt":"2005-09-18T19:11:10Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Sunday 18 Sep 2005 18:22, Junio C Hamano wrote:\n> Alan Chandler writes:\n\n> > Still struggling with how to cherry pick parts a previous\n> > update (between possibly two other branches) and apply them to\n> > a current branch - all the tutorials assume you want it all,\n> > and I can't really understand what the cherry pick commands do\n> > from their manuals.\n>\n> An example to pick a couple of commits from one branch to another.\n\nI understood your example (on the assumption I don't really care what pu^2~2 \nactually means as its copied from a list) and that is a new piece of useful \ninformation that I didn't have before, (and which I would have used several \ntimes this afternoon had I known) but its not exactly what I meant.\n\nBefore using git I had made a lot of unrelated changes to my working \ndirectory, some of which were bad. The only way to get a snapshot before I \nmade it bad (trying to hack a combination CSS and dynamically created html to \nget it to do what I want - mind breaking:-( ) was to go back to the previous \ndays backup of the whole working directory. \n\nIt was this mess I had got myself into that kicked me into getting into git, \nrather than waiting for the 1.0 release, which had been my previous plan.\n\nI effectively loaded both my current code and the day before's backup into git \nas two separate branches.\n\nWhat I was then trying to do, via various attempts with git diff -p was to \nextract small chunks of updates (ie limit scope over a few files). Edit the \nresult to limit the diff to cover a small update and then apply it to a my \ncurrent stuff to slowly undo some of the mess that I had made. \n\nBeing new to git, meant reading man pages all the time - which was making it \nslow progress (and which wasn't helped by realising I had an old version of \nthe man pages installed part way through :-( ). In the end it was easier to \nmanually retrace my steps by typing in the changes I needed.\n\n-- \nAlan Chandler\nhttp://www.chandlerfamily.org.uk\n"},{"id":"8804","messageId":"7vfys22l3k.fsf@assigned-by-dhcp.cox.net","threadId":"1843","inReplyTo":"200509182011.10689.alan@chandlerfamily.org.uk","subject":"Re: Newbie falls at first hurdle","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-18T20:10:23Z","receivedAt":"2005-09-18T20:10:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alan Chandler writes:\n\n> I effectively loaded both my current code and the day before's\n> backup into git as two separate branches.\n>\n> What I was then trying to do, via various attempts with git diff -p was to \n> extract small chunks of updates (ie limit scope over a few files). Edit the \n> result to limit the diff to cover a small update and then apply it to a my \n> current stuff to slowly undo some of the mess that I had made. \n\nAh, what you have to work with are only date-based snapshots of\nvarious states (i.e. the separation between one snapshot and\nanother does not necessarily have much to do with a single set\nof logically isolated changes).\n\nI end up doing that myself, although the situation I'd be in\ntend to be one logical change spread over multiple commits (the\nother way around from your case where one diff contains many\nlogically unrelated chagnes). I run git-diff-tree -p between\nstates to obtain a set of N diffs, look them over and hand edit\nthem to collect related things together and separate independent\nthings separate to create a different set of M diffs. then\ncreate a temporary branch that is reset to the state before\nthose N diffs and use applymbox to apply M diffs. This is\nessentially what Martin suggested.\n\nIn your case, each diff you have contains unrelated changes and\nyou have to move things around. It's a pain but I am afraid\nthere are not any SCM can do much to help you.\n"},{"id":"8891","messageId":"20050919190947.GF15165MdfPADPa@greensroom.kotnet.org","threadId":"1843","inReplyTo":"200509182011.10689.alan@chandlerfamily.org.uk","subject":"Re: Newbie falls at first hurdle","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-09-19T19:09:47Z","receivedAt":"2005-09-19T19:09:47Z","isPatch":false,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Sun, Sep 18, 2005 at 08:11:10PM +0100, Alan Chandler wrote:\n> What I was then trying to do, via various attempts with git diff -p was to \n> extract small chunks of updates (ie limit scope over a few files). Edit the \n> result to limit the diff to cover a small update and then apply it to a my \n> current stuff to slowly undo some of the mess that I had made. \n\nYoy may find my changes to dirdiff useful if you do things like that.\n(http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary)\nI've basically changed it to allow \"merging\" (i.e., commiting) to a branch.\n\nYou'd start it like this\n\ngirdiff master .\n\nThen you loop through the files with differences, for each\nfile selecting the changes you want to copy and selecting\nMerge/\"update master\".\nThen you fill in a commit message and select File/Commit\nfrom the commit message window.\n\nOnly lightly tested so far.\nRediff'ing doesn't work yet, so you'll have to restart\ngirdiff after each commit for now.\n\nskimo\n"},{"id":"9648","messageId":"200510032139.j93Ld6xg026499@laptop11.inf.utfsm.cl","threadId":"1843","inReplyTo":"alan@chandlerfamily.org.uk","subject":"Re: What to expect after 0.99.8","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-10-03T21:39:06Z","receivedAt":"2005-10-03T21:39:06Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Alan Chandler wrote:\n> On Monday 03 Oct 2005 01:14, Junio C Hamano wrote:\n> ...\n> >\n> > Technical (heavier)\n> > -------------------\n> ...\n> > * Look at libified GNU diff CVS seems to use, or libxdiff.\n\n> I did wonder today in response to a discussion at work about version control \n> of documentation, whether git could in some way understand OpenDocument \n> format and allow some form of merging of concurrent changes to the same \n> document. I am not sure if just unzipping the files and applying standard \n> merge strategies the resultant xml would be good enough.\n\nA student of mine worked on layering SCM under a code design tool that uses\nXML as its representation of the project it is working on. He started with\nCVS, and ended up grafting a problem-specific merge strategy on top. The\nstandard merge from CVS just messed everything up. Dunno if this is very\nrelevant for OASIS, but I suspect you'd see the same.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"31655","messageId":"200701132141.l0DLfWkG010141@laptop13.inf.utfsm.cl","threadId":"1843","inReplyTo":"alan@chandlerfamily.org.uk","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-13T21:41:32Z","receivedAt":"2007-01-13T21:41:32Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Alan Chandler wrote:\n\n[...]\n\n> My (albeit limited) experience with using git is at home coding a java \n> application for my web site using eclipse. During the application \n> development when I am initially coding the application, or when I am \n> doing a major update that adds new pages to my site then I have to \n> remember to git add files. My immediate instinct is do do commands of \n> the form\n> \n> git add \n> Javasource/uk/org/chandlerfamily/appname/tapestry/pages/subdir/xxx.java\n> \n> and\n> git add Webcontent/subdir/xxx.html\n> \n> which even with bash completion is a pain to enter.\n> \n> (although that is probably harder than it needs to be - can't I just do \n> git add . ?)\n\nThat's different...\n\n> I don't know whether we have had the debate here - if we have done it \n> would have been in the very very early days, but subject to \n> the .gitignore rules what would be the implications of a git commit -a \n> that automatically adds any files within the directory (and \n> subdirectories) in which it is issued.\n\nPlease don't. It would add e.g. the .class and .o and all ~ files, and all\nother junk you have lying around (test cases, test run output, ...). It\nisn't /that/ much more work after creating a new file to record its\nexistence...\n\n> I am (at the moment - but I am good at changing my mind) in the side of \n> giit add for both adding new paths and updating content. This is \n> purely pragmatic - don't have to remember which one I am trying to do.\n\nMe too. It's just a bit weird to use it to register the fact that a file is\ngone.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"31657","messageId":"20070113214742.GA17887@spearce.org","threadId":"1843","inReplyTo":"200701132141.l0DLfWkG010141@laptop13.inf.utfsm.cl","subject":"Re: Importing from tarballs; add, rm, update-index?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-01-13T21:47:42Z","receivedAt":"2007-01-13T21:47:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Horst H. von Brand\" wrote:\n> Please don't. It would add e.g. the .class and .o and all ~ files, and all\n> other junk you have lying around (test cases, test run output, ...). It\n> isn't /that/ much more work after creating a new file to record its\n> existence...\n\n echo \\*.class >>.gitignore\n echo \\*.o >>.gitignore\n git add .gitignore\n\ndoesn't work for some reason?\n \n-- \nShawn.\n"}]}