# Re: Newbie falls at first hurdle 13 messages from 2005-09-18 to 2007-01-13. Participants: Horst von Brand, Martin Langhoff, Alan Chandler, Junio C Hamano, Linus Torvalds, Sven Verdoolaege, Horst H. von Brand, Shawn O. Pearce. Thread: https://gitlist.dev/t/1843 ## Horst von Brand, 2005-09-18 01:35 Subject: Re: Newbie falls at first hurdle Message-ID: <200509180135.j8I1Z34n023252@inti.inf.utfsm.cl> URL: https://gitlist.dev/e/200509180135.j8I1Z34n023252%40inti.inf.utfsm.cl In-Reply-To: ``` Alan Chandler wrote: [...] > I have already got a working directory (or rather a directory hierarchy) > of an application with files (combination of html and java), and I need > to start applying some control to it. The Tutorial unfortunately does > not cover this case. Nevertheless I have proceeded. The easiest way of doing this is using cogito (near where you found git). It automates some tasks using git as backendq, in this case it would only need: cg-init -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ``` ## Martin Langhoff, 2005-09-18 10:54 Subject: Re: Newbie falls at first hurdle Message-ID: <46a038f9050918035436352f71@mail.gmail.com> URL: https://gitlist.dev/e/46a038f9050918035436352f71%40mail.gmail.com In-Reply-To: <200509180135.j8I1Z34n023252@inti.inf.utfsm.cl> ``` On 9/18/05, Horst von Brand wrote: > The easiest way of doing this is using cogito (near where you found > git). It automates some tasks using git as backendq, in this case it would > only need: > > cg-init +1 -- I work with a small team and we are migrating to cogito/git. There's still a few things we have to call git utilities for (change branch, for instance) but for "intuitive" usage, cogito is the cat's whiskers. cheers, martin ``` ## Alan Chandler, 2005-09-18 12:47 Subject: Re: Newbie falls at first hurdle Message-ID: <200509181347.11403.alan@chandlerfamily.org.uk> URL: https://gitlist.dev/e/200509181347.11403.alan%40chandlerfamily.org.uk In-Reply-To: <46a038f9050918035436352f71@mail.gmail.com> ``` On Sunday 18 Sep 2005 11:54, Martin Langhoff wrote: > On 9/18/05, Horst von Brand wrote: > > The easiest way of doing this is using cogito (near where you found > > git). It automates some tasks using git as backendq, in this case it > > would only need: > > > > cg-init > > +1 -- I work with a small team and we are migrating to cogito/git. > There's still a few things we have to call git utilities for (change > branch, for instance) but for "intuitive" usage, cogito is the cat's > whiskers. Yes - I had increasingly believed that with all the scripts being generated with git that cogito was becoming irrelevant. However experience of the last day has shown me that is far from the case. I really like cg-commit where it lists the files its going to commit for you, and where if you delete the line it doesn't. If I've been doing a bit too many things at once it helps commit in small chunks Seems cogito branch handling only really deals with linking to others. I have ended up also using git branch and git checkout -f to keep lots of little local branches in my repository. Still struggling with how to cherry pick parts a previous update (between possibly two other branches) and apply them to a current branch - all the tutorials assume you want it all, and I can't really understand what the cherry pick commands do from their manuals. -- Alan Chandler http://www.chandlerfamily.org.uk ``` ## Junio C Hamano, 2005-09-18 17:22 Subject: Re: Newbie falls at first hurdle Message-ID: <7vek7m5m0z.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vek7m5m0z.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200509181347.11403.alan@chandlerfamily.org.uk> ``` Alan Chandler writes: > Yes - I had increasingly believed that with all the scripts being generated > with git that cogito was becoming irrelevant. That is not going to happen. The point of git barebone Porcelain (or Porcelainish commands) is to give minimally usable UI on top of Plumbing tools for people who like to get their hands dirty, and sometimes to demonstrate how to take advantage of new core features before Porcelains start using them. It is not about competing with real Porcelains. > Still struggling with how to cherry pick parts a previous > update (between possibly two other branches) and apply them to > a current branch - all the tutorials assume you want it all, > and I can't really understand what the cherry pick commands do > from their manuals. An example to pick a couple of commits from one branch to another. $ git show-branch master pu * [mister] Improve the safety check used in fetch.c ! [pu] Merge branch 'nuker' of .; branch 'merge' of . -- + [pu] Merge branch 'nuker' of .; branch 'merge' of . + [pu^3] Use git-merge instead of git-resolve in git-pull. + [pu^2] Add two options to diffcore. + [pu^2~1] Diff cleanup. + [pu^2~2] Retire rev-tree. + [pu^2~3] Retire git-export. ++ [mister] Improve the safety check used in fetch.c Let's cherry-pick two commits from pu branch: $ git cherry-pick pu^3 ; git cherry-pick pu^2~2 Then the result looks like this: $ git show-branch mister pu * [mister] Retire rev-tree. ! [pu] Merge branch 'nuker' of .; branch 'merge' of . -- + [pu] Merge branch 'nuker' of .; branch 'merge' of . + [pu^3] Use git-merge instead of git-resolve in git-pull. + [pu^2] Add two options to diffcore. + [pu^2~1] Diff cleanup. + [pu^2~2] Retire rev-tree. + [pu^2~3] Retire git-export. + [mister] Retire rev-tree. + [mister~1] Use git-merge instead of git-resolve in git-pull. ++ [pu~1] Improve the safety check used in fetch.c Note that new two commits are _not_ the same commit objects you cherry picked from the pu branch. They are new commits that introduce changes equivalent to them. ``` ## Linus Torvalds, 2005-09-18 17:40 Subject: Re: Newbie falls at first hurdle Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.58.0509181033520.26803%40g5.osdl.org In-Reply-To: <7vek7m5m0z.fsf@assigned-by-dhcp.cox.net> ``` On Sun, 18 Sep 2005, Junio C Hamano wrote: > > An example to pick a couple of commits from one branch to another. Your examples scare even me. How about you add this to the tutorial as an "advanced usage" example, and explain everything that was done in terms of what the "stupid usage" examples earlier in the tutorial did. In other words, you'd have to explain what "pu^2~3" means. And octopus merges, for that matter. I don't think the tutorial ever explains those. Linus ``` ## Junio C Hamano, 2005-09-18 17:54 Subject: Re: Newbie falls at first hurdle Message-ID: <7vzmqa2reb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vzmqa2reb.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > In other words, you'd have to explain what "pu^2~3" means. > > And octopus merges, for that matter. I don't think the tutorial ever > explains those. Sorry, my excuses are (1) I just did a quick example from a tree I had handy -- my live tree; (2) as long as the user knows the commit show-branch labeled with the cryptic "pu^2~3" is the one s/he wants, it does not matter much what that label exactly means. But of course you are right. ``` ## Martin Langhoff, 2005-09-18 19:06 Subject: Re: Newbie falls at first hurdle Message-ID: <46a038f90509181206643bce7@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90509181206643bce7%40mail.gmail.com In-Reply-To: <200509181347.11403.alan@chandlerfamily.org.uk> ``` On 9/19/05, Alan Chandler wrote: > Still struggling with how to cherry pick parts a previous update (between > possibly two other branches) and apply them to a current branch - all the > tutorials assume you want it all, and I can't really understand what the > cherry pick commands do from their manuals. Forget the cherry pick commands -- here's a usable, easy strategy. git-checkout the "source" branch, create a temporary directory to hold the patches, and call git-format-patch --mbox -o patchdir destbranch This will create one file per patch in the destination directory. Feel free to delete patches you don't want, and edit the patches you've got there. Then switch to the destination branch, and use git-applymbox to merge them in. If you do this repeatedly, git-format-patch will not reexport patches you've merged to the destination branch already (if they merged cleanly unchanged)... or at least that's the theory ;) The only limitation I've found in this strategy is that it doesn't deal with binary objects. I'm lost as to what to do in those cases. cheers, martin ``` ## Alan Chandler, 2005-09-18 19:11 Subject: Re: Newbie falls at first hurdle Message-ID: <200509182011.10689.alan@chandlerfamily.org.uk> URL: https://gitlist.dev/e/200509182011.10689.alan%40chandlerfamily.org.uk In-Reply-To: <7vek7m5m0z.fsf@assigned-by-dhcp.cox.net> ``` On Sunday 18 Sep 2005 18:22, Junio C Hamano wrote: > Alan Chandler writes: > > Still struggling with how to cherry pick parts a previous > > update (between possibly two other branches) and apply them to > > a current branch - all the tutorials assume you want it all, > > and I can't really understand what the cherry pick commands do > > from their manuals. > > An example to pick a couple of commits from one branch to another. I understood your example (on the assumption I don't really care what pu^2~2 actually means as its copied from a list) and that is a new piece of useful information that I didn't have before, (and which I would have used several times this afternoon had I known) but its not exactly what I meant. Before using git I had made a lot of unrelated changes to my working directory, some of which were bad. The only way to get a snapshot before I made it bad (trying to hack a combination CSS and dynamically created html to get it to do what I want - mind breaking:-( ) was to go back to the previous days backup of the whole working directory. It was this mess I had got myself into that kicked me into getting into git, rather than waiting for the 1.0 release, which had been my previous plan. I effectively loaded both my current code and the day before's backup into git as two separate branches. What I was then trying to do, via various attempts with git diff -p was to extract small chunks of updates (ie limit scope over a few files). Edit the result to limit the diff to cover a small update and then apply it to a my current stuff to slowly undo some of the mess that I had made. Being new to git, meant reading man pages all the time - which was making it slow progress (and which wasn't helped by realising I had an old version of the man pages installed part way through :-( ). In the end it was easier to manually retrace my steps by typing in the changes I needed. -- Alan Chandler http://www.chandlerfamily.org.uk ``` ## Junio C Hamano, 2005-09-18 20:10 Subject: Re: Newbie falls at first hurdle Message-ID: <7vfys22l3k.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vfys22l3k.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <200509182011.10689.alan@chandlerfamily.org.uk> ``` Alan Chandler writes: > I effectively loaded both my current code and the day before's > backup into git as two separate branches. > > What I was then trying to do, via various attempts with git diff -p was to > extract small chunks of updates (ie limit scope over a few files). Edit the > result to limit the diff to cover a small update and then apply it to a my > current stuff to slowly undo some of the mess that I had made. Ah, what you have to work with are only date-based snapshots of various states (i.e. the separation between one snapshot and another does not necessarily have much to do with a single set of logically isolated changes). I end up doing that myself, although the situation I'd be in tend to be one logical change spread over multiple commits (the other way around from your case where one diff contains many logically unrelated chagnes). I run git-diff-tree -p between states to obtain a set of N diffs, look them over and hand edit them to collect related things together and separate independent things separate to create a different set of M diffs. then create a temporary branch that is reset to the state before those N diffs and use applymbox to apply M diffs. This is essentially what Martin suggested. In your case, each diff you have contains unrelated changes and you have to move things around. It's a pain but I am afraid there are not any SCM can do much to help you. ``` ## Sven Verdoolaege, 2005-09-19 19:09 Subject: Re: Newbie falls at first hurdle Message-ID: <20050919190947.GF15165MdfPADPa@greensroom.kotnet.org> URL: https://gitlist.dev/e/20050919190947.GF15165MdfPADPa%40greensroom.kotnet.org In-Reply-To: <200509182011.10689.alan@chandlerfamily.org.uk> ``` On Sun, Sep 18, 2005 at 08:11:10PM +0100, Alan Chandler wrote: > What I was then trying to do, via various attempts with git diff -p was to > extract small chunks of updates (ie limit scope over a few files). Edit the > result to limit the diff to cover a small update and then apply it to a my > current stuff to slowly undo some of the mess that I had made. Yoy may find my changes to dirdiff useful if you do things like that. (http://www.liacs.nl/~sverdool/gitweb.cgi?p=dirdiff.git;a=summary) I've basically changed it to allow "merging" (i.e., commiting) to a branch. You'd start it like this girdiff master . Then you loop through the files with differences, for each file selecting the changes you want to copy and selecting Merge/"update master". Then you fill in a commit message and select File/Commit from the commit message window. Only lightly tested so far. Rediff'ing doesn't work yet, so you'll have to restart girdiff after each commit for now. skimo ``` ## Horst von Brand, 2005-10-03 21:39 Subject: Re: What to expect after 0.99.8 Message-ID: <200510032139.j93Ld6xg026499@laptop11.inf.utfsm.cl> URL: https://gitlist.dev/e/200510032139.j93Ld6xg026499%40laptop11.inf.utfsm.cl In-Reply-To: ``` Alan Chandler wrote: > On Monday 03 Oct 2005 01:14, Junio C Hamano wrote: > ... > > > > Technical (heavier) > > ------------------- > ... > > * Look at libified GNU diff CVS seems to use, or libxdiff. > I did wonder today in response to a discussion at work about version control > of documentation, whether git could in some way understand OpenDocument > format and allow some form of merging of concurrent changes to the same > document. I am not sure if just unzipping the files and applying standard > merge strategies the resultant xml would be good enough. A student of mine worked on layering SCM under a code design tool that uses XML as its representation of the project it is working on. He started with CVS, and ended up grafting a problem-specific merge strategy on top. The standard merge from CVS just messed everything up. Dunno if this is very relevant for OASIS, but I suspect you'd see the same. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 ``` ## Horst H. von Brand, 2007-01-13 21:41 Subject: Re: Importing from tarballs; add, rm, update-index? Message-ID: <200701132141.l0DLfWkG010141@laptop13.inf.utfsm.cl> URL: https://gitlist.dev/e/200701132141.l0DLfWkG010141%40laptop13.inf.utfsm.cl In-Reply-To: ``` Alan Chandler wrote: [...] > My (albeit limited) experience with using git is at home coding a java > application for my web site using eclipse. During the application > development when I am initially coding the application, or when I am > doing a major update that adds new pages to my site then I have to > remember to git add files. My immediate instinct is do do commands of > the form > > git add > Javasource/uk/org/chandlerfamily/appname/tapestry/pages/subdir/xxx.java > > and > git add Webcontent/subdir/xxx.html > > which even with bash completion is a pain to enter. > > (although that is probably harder than it needs to be - can't I just do > git add . ?) That's different... > I don't know whether we have had the debate here - if we have done it > would have been in the very very early days, but subject to > the .gitignore rules what would be the implications of a git commit -a > that automatically adds any files within the directory (and > subdirectories) in which it is issued. Please don't. It would add e.g. the .class and .o and all ~ files, and all other junk you have lying around (test cases, test run output, ...). It isn't /that/ much more work after creating a new file to record its existence... > I am (at the moment - but I am good at changing my mind) in the side of > giit add for both adding new paths and updating content. This is > purely pragmatic - don't have to remember which one I am trying to do. Me too. It's just a bit weird to use it to register the fact that a file is gone. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 ``` ## Shawn O. Pearce, 2007-01-13 21:47 Subject: Re: Importing from tarballs; add, rm, update-index? Message-ID: <20070113214742.GA17887@spearce.org> URL: https://gitlist.dev/e/20070113214742.GA17887%40spearce.org In-Reply-To: <200701132141.l0DLfWkG010141@laptop13.inf.utfsm.cl> ``` "Horst H. von Brand" wrote: > Please don't. It would add e.g. the .class and .o and all ~ files, and all > other junk you have lying around (test cases, test run output, ...). It > isn't /that/ much more work after creating a new file to record its > existence... echo \*.class >>.gitignore echo \*.o >>.gitignore git add .gitignore doesn't work for some reason? -- Shawn. ```