{"thread":{"id":"10247","subject":"yet another workflow question...","startedAt":"2007-10-11T14:11:58Z","lastAt":"2007-10-12T07:25:57Z","messageCount":9,"participants":["Patrick Doyle","David Kastrup","Johannes Sixt","Wincent Colaiuta","Steffen Prohaska","Andy Parkins","Andreas Ericsson","Jing Xue"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"55468","messageId":"e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com","threadId":"10247","inReplyTo":null,"subject":"yet another workflow question...","fromName":"Patrick Doyle","fromEmail":"wpdster@gmail.com","sentAt":"2007-10-11T14:11:58Z","receivedAt":"2007-10-11T14:11:58Z","isPatch":false,"sender":{"key":"wpdster@gmail.com","avatar":null},"body":"Sorry for cluttering up the list with yet another very basic workflow\nquestion, but I'm still struggling with finding an answer to the\nburning question, \"What can git do for me?\" (So far, I have come to\nthe conclusion that, for my simple, single developer, branchless,\nlinear projects, there's not much that git can do for me that any\nother SCM could do for me. It appears to have been designed to solve\nproblems for which I have absolutely no appreciation whatsoever. :-))\n\nAnyway, on to basic newbie quesion #107...\n\nI've been working on my project and I realize that I have 3-4 files\nmodified with two orthogonal sets of changes. (I didn't realize this\nuntil I said to myself -- \"Self, I should really check in these files\nbefore I go too much further down this path\".) So I start \"git\ndiff\"-ing the files and I find that most files have differences\nrelated to only one change or the other, but one file has differences\nrelated to both changes.\n\nWhat do others do in this situation?\na) Not allow themselves to get into this situation in the first place\nby careful planning?\n\nb) Copy the file to \"file.bothchanges\", edit out one set of changes,\ncommit that with one log message, edit back in the other set of\nchanges, edit in the other set of changes, commit that with another\nlog message?\n\nc) Use some sort of automation to do option (b) for them?\n\nd) Something else?\n\n--wpd\n"},{"id":"55469","messageId":"86lka9spjq.fsf@lola.quinscape.zz","threadId":"10247","inReplyTo":"e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com","subject":"Re: yet another workflow question...","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-10-11T14:18:17Z","receivedAt":"2007-10-11T14:18:17Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"Patrick Doyle\" writes:\n\n> Sorry for cluttering up the list with yet another very basic workflow\n> question, but I'm still struggling with finding an answer to the\n> burning question, \"What can git do for me?\" (So far, I have come to\n> the conclusion that, for my simple, single developer, branchless,\n> linear projects, there's not much that git can do for me that any\n> other SCM could do for me. It appears to have been designed to solve\n> problems for which I have absolutely no appreciation whatsoever. :-))\n>\n> Anyway, on to basic newbie quesion #107...\n>\n> I've been working on my project and I realize that I have 3-4 files\n> modified with two orthogonal sets of changes. (I didn't realize this\n> until I said to myself -- \"Self, I should really check in these files\n> before I go too much further down this path\".) So I start \"git\n> diff\"-ing the files and I find that most files have differences\n> related to only one change or the other, but one file has differences\n> related to both changes.\n>\n> What do others do in this situation?\n> a) Not allow themselves to get into this situation in the first place\n> by careful planning?\n>\n> b) Copy the file to \"file.bothchanges\", edit out one set of changes,\n> commit that with one log message, edit back in the other set of\n> changes, edit in the other set of changes, commit that with another\n> log message?\n>\n> c) Use some sort of automation to do option (b) for them?\n>\n> d) Something else?\n\ngit-add -i\n\n-- \nDavid Kastrup\n"},{"id":"55470","messageId":"470E3545.4060005@viscovery.net","threadId":"10247","inReplyTo":"e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com","subject":"Re: yet another workflow question...","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2007-10-11T14:37:57Z","receivedAt":"2007-10-11T14:37:57Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Patrick Doyle schrieb:\n> I've been working on my project and I realize that I have 3-4 files\n> modified with two orthogonal sets of changes. (I didn't realize this\n> until I said to myself -- \"Self, I should really check in these files\n> before I go too much further down this path\".) So I start \"git\n> diff\"-ing the files and I find that most files have differences\n> related to only one change or the other, but one file has differences\n> related to both changes.\n> \n> What do others do in this situation?\n> a) Not allow themselves to get into this situation in the first place\n> by careful planning?\n> \n> b) Copy the file to \"file.bothchanges\", edit out one set of changes,\n> commit that with one log message, edit back in the other set of\n> changes, edit in the other set of changes, commit that with another\n> log message?\n> \n> c) Use some sort of automation to do option (b) for them?\n> \n> d) Something else?\n\nUse git-gui.\n\nStage the files relevant for the first change. In the file where you have an \noverlap with the second change, you can right-click in the diff pane and \nselect \"Stage Hunk for Commit\" on the hunk relevant for the first change.[*]\n\nCommit with a message.\n\nStage the remaining changes and commit again.\n\nAt this point, I usually check out HEAD~1, i.e. the state *without* the \nsecond change, and compile and test to make sure I have a bisectable history.\n\n[*] Of course, this works only if the changes are not in the same hunk. If \nthere are at least 3 unmodified lines between the changes, you can choose \n\"Less context\" until they are in separate hunks.\n\n-- Hannes\n"},{"id":"55471","messageId":"00CC9676-C6D8-4E9E-ABE3-A6238810B536@wincent.com","threadId":"10247","inReplyTo":"e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com","subject":"Re: yet another workflow question...","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2007-10-11T14:39:01Z","receivedAt":"2007-10-11T14:39:01Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 11/10/2007, a las 16:11, Patrick Doyle escribió:\n\n> Sorry for cluttering up the list with yet another very basic workflow\n> question, but I'm still struggling with finding an answer to the\n> burning question, \"What can git do for me?\" (So far, I have come to\n> the conclusion that, for my simple, single developer, branchless,\n> linear projects, there's not much that git can do for me that any\n> other SCM could do for me. It appears to have been designed to solve\n> problems for which I have absolutely no appreciation whatsoever. :-))\n\nEven with the workflow you describe, Git brings some nice benefits:\n\n1. Faster than anything else out there\n2. You can work offline (even if you have an \"always on\" net \nconnection, think about the times when it goes down)\n3. You can easily amend mistakes in your last commit (git-commit -- \namend)\n4. You can easily stash away work in progress and go off on a tangent \n(git-stash)\n5. You get nice colorized diff and log output for free\n6. Great visualization tools included for free (gitk, git-gui etc)\n\nAnd those are just a few off the top of my head. The more you work \nwith Git, the more benefits you will discover, even if you're not \ntrying to do anything fancy with it. And although you are currently \nusing branchless development, you may find with time that you start \nusing things like topic branches simply because Git makes it so darn \neasy to do so, and the benefit is that you'll keep your history much \ncleaner and easier to understand when you go back to look at it later \non.\n\nCheers,\nWincent\n"},{"id":"55472","messageId":"E16F512D-21F4-4E01-888C-967603F63AD8@zib.de","threadId":"10247","inReplyTo":"86lka9spjq.fsf@lola.quinscape.zz","subject":"Re: yet another workflow question...","fromName":"Steffen Prohaska","fromEmail":"prohaska@zib.de","sentAt":"2007-10-11T14:44:34Z","receivedAt":"2007-10-11T14:44:34Z","isPatch":false,"sender":{"key":"prohaska@zib.de","avatar":"https://avatars.githubusercontent.com/u/217580?v=4"},"body":"\nOn Oct 11, 2007, at 4:18 PM, David Kastrup wrote:\n\n> \"Patrick Doyle\" writes:\n>\n>> Sorry for cluttering up the list with yet another very basic workflow\n>> question, but I'm still struggling with finding an answer to the\n>> burning question, \"What can git do for me?\" (So far, I have come to\n>> the conclusion that, for my simple, single developer, branchless,\n>> linear projects, there's not much that git can do for me that any\n>> other SCM could do for me. It appears to have been designed to solve\n>> problems for which I have absolutely no appreciation whatsoever. :-))\n>>\n>> Anyway, on to basic newbie quesion #107...\n>>\n>> I've been working on my project and I realize that I have 3-4 files\n>> modified with two orthogonal sets of changes. (I didn't realize this\n>> until I said to myself -- \"Self, I should really check in these files\n>> before I go too much further down this path\".) So I start \"git\n>> diff\"-ing the files and I find that most files have differences\n>> related to only one change or the other, but one file has differences\n>> related to both changes.\n>>\n>> What do others do in this situation?\n>> a) Not allow themselves to get into this situation in the first place\n>> by careful planning?\n>>\n>> b) Copy the file to \"file.bothchanges\", edit out one set of changes,\n>> commit that with one log message, edit back in the other set of\n>> changes, edit in the other set of changes, commit that with another\n>> log message?\n>>\n>> c) Use some sort of automation to do option (b) for them?\n>>\n>> d) Something else?\n>\n> git-add -i\n\ngit-gui, right click on change.\n\n From the user manual:\n\n\"\"\"\nYou can also use git-gui(1) to create commits, view changes in the \nindex and the working tree files, and individually select diff hunks \nfor inclusion in the index (by right-clicking on the diff hunk and \nchoosing \"Stage Hunk For Commit\").\n\"\"\"\n\n\tSteffen\n"},{"id":"55477","messageId":"200710111610.55364.andyparkins@gmail.com","threadId":"10247","inReplyTo":"e2a1d0aa0710110711m77ca967bmd1d5ffd5d3099aab@mail.gmail.com","subject":"Re: yet another workflow question...","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-11T15:10:54Z","receivedAt":"2007-10-11T15:10:54Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 October 11, Patrick Doyle wrote:\n\n> burning question, \"What can git do for me?\" (So far, I have come to\n> the conclusion that, for my simple, single developer, branchless,\n> linear projects, there's not much that git can do for me that any\n> other SCM could do for me. It appears to have been designed to solve\n\nHere's a few things that are relevant to a simple, single, branchless, linear \ndeveloper:\n\n - Fast. Git wipes the floor with everything else, so much so that the SCM\n becomes a tool in itself, not just a recorder of history. I keep my own\n simple projects in git just as much as my complicated, branchy, team-based\n projects just to get the following tools fast:\n git-diff\n git-status\n git-commit\n git-log\n\n - Small. In every project I've converted from SVN to git, the diskspace\n usage has gone down. SVN peppers the working tree with .svn directories,\n each of which contains a pristine copy of the last checked in version of\n all the working files. On top of that is the repository disk space itself.\n\n Git on the other hand keeps one .git directory at the top of the tree and\n that stores the _entire_ repository. It is, in my experience, smaller than\n the working tree. That means that git uses less diskspace than svn does\n for a single checkout to store everything it needs.\n\n - Useful. The following are so good, that even if you weren't doing any \n revision tracking you'd still want to use them:\n git-grep\n git-diff\n\n - Backup. Backing up subversion repositories requires that you write\n yourself a script that uses svnadmin dump. With git I just write a couple\n of lines in my .git/config and then git-push produces a highly compact\n backup whenever I want. Even better, if a disaster happens it's easy to\n pull stuff out of that backup without any additional operations.\n\n - Mobility. This one is a bit distributed, but I hope you'll let me have it. \n I often do work on my desktop at home, my desktop at work and my laptop. \n By setting my remotes up correctly in git it's really easy to walk to\n another system and pick up exactly where I left off from the other\n computer. More importantly though, when you accidentally make changes in\n two places, there is no danger of data loss.\n\nEven if you aren't doing complicated stuff, git is the way to go. I can't \ncount the number of ways it's made me more productive and enhanced the code I \nwrite and the documentation of its development. If I never worked on another \ngroup project again I would still use git all day every day.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"55485","messageId":"470E5D32.7060306@op5.se","threadId":"10247","inReplyTo":"200710111610.55364.andyparkins@gmail.com","subject":"Re: yet another workflow question...","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-10-11T17:28:18Z","receivedAt":"2007-10-11T17:28:18Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Andy Parkins wrote:\n> On Thursday 2007 October 11, Patrick Doyle wrote:\n> \n>> burning question, \"What can git do for me?\" (So far, I have come to\n>> the conclusion that, for my simple, single developer, branchless,\n>> linear projects, there's not much that git can do for me that any\n>> other SCM could do for me. It appears to have been designed to solve\n> \n> Here's a few things that are relevant to a simple, single, branchless, linear \n> developer:\n> \n> - Fast. Git wipes the floor with everything else, so much so that the SCM\n> becomes a tool in itself, not just a recorder of history. I keep my own\n> simple projects in git just as much as my complicated, branchy, team-based\n> projects just to get the following tools fast:\n> git-diff\n> git-status\n> git-commit\n> git-log\n> \n> - Small. In every project I've converted from SVN to git, the diskspace\n> usage has gone down. SVN peppers the working tree with .svn directories,\n> each of which contains a pristine copy of the last checked in version of\n> all the working files. On top of that is the repository disk space itself.\n> \n> Git on the other hand keeps one .git directory at the top of the tree and\n> that stores the _entire_ repository. It is, in my experience, smaller than\n> the working tree. That means that git uses less diskspace than svn does\n> for a single checkout to store everything it needs.\n> \n> - Useful. The following are so good, that even if you weren't doing any \n> revision tracking you'd still want to use them:\n> git-grep\n> git-diff\n> \n> - Backup. Backing up subversion repositories requires that you write\n> yourself a script that uses svnadmin dump. With git I just write a couple\n> of lines in my .git/config and then git-push produces a highly compact\n> backup whenever I want. Even better, if a disaster happens it's easy to\n> pull stuff out of that backup without any additional operations.\n> \n> - Mobility. This one is a bit distributed, but I hope you'll let me have it. \n> I often do work on my desktop at home, my desktop at work and my laptop. \n> By setting my remotes up correctly in git it's really easy to walk to\n> another system and pick up exactly where I left off from the other\n> computer. More importantly though, when you accidentally make changes in\n> two places, there is no danger of data loss.\n> \n> Even if you aren't doing complicated stuff, git is the way to go. I can't \n> count the number of ways it's made me more productive and enhanced the code I \n> write and the documentation of its development. If I never worked on another \n> group project again I would still use git all day every day.\n> \n\nI'm amazed nobody has mentioned git-bisect yet. Recently, I had an enormous amount\nof benefit from it, so I'll just add it here as a success-story in case any OSS\nsupport company comes along and wants to peddle git.\n\n\nAs it happens, I have a daemon that does some fairly clever scheduling. Somewhere\nin a recent change, I had introduced a very subtle bug that made the latency times\nfor when the actions were actually happening diverge from 0s. I know I get a\nlatency spike just when I fire the daemon up, but it's supposed to normalize after\n10 or so minutes and converge on zero-latency. Instead it was slowly increasing,\nbut the effects weren't really visible until after about 2 hours.\n\ngit bisect to the rescue. Since I didn't feel terribly inclined to walk over to\nmy computer every two hours to recompile, wipe logs and start the daemon all over\nagain, I hacked up a script to do it for me. The script also checked the latency\nfigures and re-ran git-bisect as necessary.\n\n22 hours (or 7 bisects) later, git had, with a little help from my script, shown\nme exactly the commit that introduced the latency issue. During the time, I was\nenjoying a walk in the sun, dinner with my girlfriend and a good nights sleep.\n\nLife is good when you have the proper tools.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"55501","messageId":"20071011164019.3n4l3rayckck8c4w@intranet.digizenstudio.com","threadId":"10247","inReplyTo":"200710111610.55364.andyparkins@gmail.com","subject":"Re: yet another workflow question...","fromName":"Jing Xue","fromEmail":"jingxue@digizenstudio.com","sentAt":"2007-10-11T20:40:19Z","receivedAt":"2007-10-11T20:40:19Z","isPatch":false,"sender":{"key":"jingxue@digizenstudio.com","avatar":null},"body":"\nQuoting Andy Parkins :\n\n> - Mobility. This one is a bit distributed, but I hope you'll let \n> me have it.\n> I often do work on my desktop at home, my desktop at work and my laptop.\n> By setting my remotes up correctly in git it's really easy to walk to\n> another system and pick up exactly where I left off from the other\n> computer. More importantly though, when you accidentally make changes in\n> two places, there is no danger of data loss.\n\nTo extend on this point, after picking up the randomly checked-in save \npoint on another computer, the save point itself can be easily \ngit-reset'ed. So there won't be commits like \"it's utter broken but i \ngot to go home\" polluting the history. I find that extremely handy.\n\nCheers.\n-- \nJing Xue\n"},{"id":"55529","messageId":"200710120825.58235.andyparkins@gmail.com","threadId":"10247","inReplyTo":"20071011164019.3n4l3rayckck8c4w@intranet.digizenstudio.com","subject":"Re: yet another workflow question...","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-10-12T07:25:57Z","receivedAt":"2007-10-12T07:25:57Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Thursday 2007 October 11, Jing Xue wrote:\n> Quoting Andy Parkins :\n> > - Mobility. This one is a bit distributed, but I hope you'll let\n> > me have it.\n> > I often do work on my desktop at home, my desktop at work and my\n> > laptop. By setting my remotes up correctly in git it's really easy to\n> > walk to another system and pick up exactly where I left off from the\n> > other computer. More importantly though, when you accidentally make\n> > changes in two places, there is no danger of data loss.\n>\n> To extend on this point, after picking up the randomly checked-in save\n> point on another computer, the save point itself can be easily\n> git-reset'ed. So there won't be commits like \"it's utter broken but i\n> got to go home\" polluting the history. I find that extremely handy.\n\nAbsolutely; in fact I've had times when I've done things like this:\n\n git merge laptop-branch\n git merge home-branch\n git reset HEAD^^\n\nThat is to say, I'm not interested in documenting the merges, I just want to \nbring a set of changes from different places together ready for some proper \ncommits, which of course can be done really easily with git add -i.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"}]}