Re: [git-users] reverting back to earlier version to find a bug
Ross, One extra thing. Have a look at the git.git Sumbitting patches guidelines (https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L44 #L102, etc.) about writing commit messages, and reveiw the suggested patch messages in the git mailing list (https://public-inbox.org/git/?q=) These provide usefl examples. These help greatly in writing short concise messages that you and colleages will find helpful. In the main, thay are a case of: "stop beating around the bush; get to the point; tell the computer what to do, it's an inanimate VCS anyway ;-)" By doing that you will be able to write useful messages quickly. The DVCS you use should help, not hinder, nor waste time (does the main company VCS process feel like a hinderance and a waste of time (rhet)?). It's helped me! Philip - Original Message - From: "Philip Oakley" <philipoak...@iee.org> To: <git-users@googlegroups.com> Sent: Sunday, December 10, 2017 1:09 PM Subject: Re: [git-users] reverting back to earlier version to find a bug Hi Russ, The two matras I see are: "Branches are cheap, very cheap" "Git gives (distibutes) control to You" This means you can branch and commit early and commit often (locally), even when it might 'break the build' if pushed upstream. (make sure you have this capability - some shops can't get out of the dark ages of micro management/control, and want to shame folks for local commits, which is wrong!). You can also use the Git Gui to select lines at a time (it's the same as the `add -p/--patch` but easier to see) to add to a commit, so you can split apart a multi-way change into coherent steps that are individually committed. This means you can easily get back to any step in the development process almost to the minute. Once you have your working code on you locally named feature branch, you can then use the `git rebase` capability to refine your 'rough draft, but working' code into the polished sequence of steps you want to present (it's like preparing homework, but you are in control!). Use the Git Gui to get that overview, and then use it's ability to split the changes int a nice sequence of commits. It works wonders. Philip - Original Message - From: "Russ P" <russ.paie...@gmail.com> To: "Git for human beings" <git-users@googlegroups.com> Sent: Sunday, December 10, 2017 4:32 AM Subject: Re: [git-users] reverting back to earlier version to find a bug Thanks for the help, guys. I will have to think about it a bit. I must admit that I am concerned about "effing things up" if I try to use new git commands for this problem. One thing I have learned from this problem is that I should have committed more often. Since I was doing a fairly extensive redesign, I was thinking that I should hold off on committing until I had verified that everything was working. Now I realize that was a huge mistake. It occurred to me that perhaps there should be some way of having "minor" commits done automatically. I'm sure someone must have thought of this before. Why not have a scheme to do an auto-commit (with no comment) every time you compile successfully? If I had that, I could find the bug fairly easily. How would it be implemented? I suppose it would be done by the build system. I am using Scala and sbt. Could sbt be made to automatically do a commit every time it builds successfully? I don't see why not. Heck, maybe it has that feature already and I just don't know it! And perhaps git could allow for "minor" commits without a comment. At least that would allow someone like me to locate a bug easier. What do you think? --Russ On Saturday, December 9, 2017 at 6:07:08 PM UTC-8, Igor Djordjevic wrote: Hi Russ P, On Sunday, December 10, 2017 at 1:30:18 AM UTC+1, Philip Oakley wrote: From: "Russ P" <russ.p...@gmail.com> >I am working independently on a software project, and I am a novice >git > user, using only a few basic commands (status, diff, add, commit, > checkout, > and log). > > I got myself into a bit of a jam. I did a redesign on part of my > code, and > I introduced a subtle but major bug somewhere. I was doing a few > basic > tests after each small change, but those tests did not catch the bug that > I > had introduced. To make matters worse, I waited too long between commits > (almost a week). Now I have a bug that I can isolate to a particular > commit, but the commit was large, and I cannot pinpoint the bug. > > I've tried many things to no avail. At this point, I think I need to > revert > back to the last working version and then try to add the changes back in > piecemeal until I locate the offending code. However, I am a bit > unsure > about the best way to do that with git. I know how to checkout the > last >
Re: [git-users] reverting back to earlier version to find a bug
Hi Russ, The two matras I see are: "Branches are cheap, very cheap" "Git gives (distibutes) control to You" This means you can branch and commit early and commit often (locally), even when it might 'break the build' if pushed upstream. (make sure you have this capability - some shops can't get out of the dark ages of micro management/control, and want to shame folks for local commits, which is wrong!). You can also use the Git Gui to select lines at a time (it's the same as the `add -p/--patch` but easier to see) to add to a commit, so you can split apart a multi-way change into coherent steps that are individually committed. This means you can easily get back to any step in the development process almost to the minute. Once you have your working code on you locally named feature branch, you can then use the `git rebase` capability to refine your 'rough draft, but working' code into the polished sequence of steps you want to present (it's like preparing homework, but you are in control!). Use the Git Gui to get that overview, and then use it's ability to split the changes int a nice sequence of commits. It works wonders. Philip - Original Message - From: "Russ P" <russ.paie...@gmail.com> To: "Git for human beings" <git-users@googlegroups.com> Sent: Sunday, December 10, 2017 4:32 AM Subject: Re: [git-users] reverting back to earlier version to find a bug Thanks for the help, guys. I will have to think about it a bit. I must admit that I am concerned about "effing things up" if I try to use new git commands for this problem. One thing I have learned from this problem is that I should have committed more often. Since I was doing a fairly extensive redesign, I was thinking that I should hold off on committing until I had verified that everything was working. Now I realize that was a huge mistake. It occurred to me that perhaps there should be some way of having "minor" commits done automatically. I'm sure someone must have thought of this before. Why not have a scheme to do an auto-commit (with no comment) every time you compile successfully? If I had that, I could find the bug fairly easily. How would it be implemented? I suppose it would be done by the build system. I am using Scala and sbt. Could sbt be made to automatically do a commit every time it builds successfully? I don't see why not. Heck, maybe it has that feature already and I just don't know it! And perhaps git could allow for "minor" commits without a comment. At least that would allow someone like me to locate a bug easier. What do you think? --Russ On Saturday, December 9, 2017 at 6:07:08 PM UTC-8, Igor Djordjevic wrote: Hi Russ P, On Sunday, December 10, 2017 at 1:30:18 AM UTC+1, Philip Oakley wrote: From: "Russ P" <russ.p...@gmail.com> >I am working independently on a software project, and I am a novice git > user, using only a few basic commands (status, diff, add, commit, > checkout, > and log). > > I got myself into a bit of a jam. I did a redesign on part of my code, and > I introduced a subtle but major bug somewhere. I was doing a few basic > tests after each small change, but those tests did not catch the bug that > I > had introduced. To make matters worse, I waited too long between commits > (almost a week). Now I have a bug that I can isolate to a particular > commit, but the commit was large, and I cannot pinpoint the bug. > > I've tried many things to no avail. At this point, I think I need to > revert > back to the last working version and then try to add the changes back in > piecemeal until I locate the offending code. However, I am a bit > unsure > about the best way to do that with git. I know how to checkout the > last > working version and then go back to the latest code by checking out > master. > But what will happen if I start making changes to the earlier working > version? Is this something that I should be using a branch for? What > is > the > best strategy? Thanks. > My "off the top of the head" view would be one of: a. create a temp branch at the current branch head, then deliberately 'rebase -i' the sequence including the bad commit onto it's parent commit. Mark the bad commit as 'edit', and after it has been rebased, at the edit, amend that last commit to split it into multiple parts, letting the remainder rebase as normal. You'll now have a temp branch that can be bisected. equivalently: b. create a temp branch at the parent of the bad commit, cherry-pick the bad commit and then amend / patch pick the constituent parts of that commit, now rebase the remaining commits onto that branch. Again you have a bisectable sequence with more fine grain selection within the bad commit. Repeat as needed. Philip already provided good advice - I would just add that, before y
Re: [git-users] reverting back to earlier version to find a bug
On Saturday, December 09, 2017 11:32:32 PM Russ P wrote: > How would it be implemented? I suppose it would be done by the build > system. I am using Scala and sbt. Could sbt be made to automatically do a > commit every time it builds successfully? I don't see why not. Heck, maybe > it has that feature already and I just don't know it! And perhaps git could > allow for "minor" commits without a comment. At least that would allow > someone like me to locate a bug easier. What do you think? As someone who hasn't done much development in the last 20 years, I think it is a great idea. (I do write a lot of text documents, and often fail to make an interim save and later regret it (for any of a number of reasons).) As far as a comment, without having used git extensively or recently (maybe 3-4 years ago), I think some sort of automatic comment would be useful, something like: "20171210, 07:08, nn.nn.n:8" The nn.nn.n:8 meaning the 8th automatic commit (on a compile) after named branch nn.nn.n)" Or something similar for any named commit (not necessarily a branch. I know that some or all of that information is fairly easily available, but, for me, to be able to see it as a comment often seems more convenient. I think it would also be useful to be able to easily force an "interim" auto commit if you've made extensive (or difficult) changes without doing a compilation. "20171210, 07:08, nn.nn.n:8:3" The nn.nn.n:8:3 meaning the 3rd interim commit after the 8th automatic commit (on a compile) after named branch nn.nn.n)" And, in both cases, git could prompt optional for additional comments (to be added after the automatic commit message). -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] reverting back
Hi Hwswman, I don't use SourceTree, but I know how to you do it in command line: if you want to delete forever the changes you have done, you need to get the commit hash of the commit where you want to return (the commit before the mess). For that you can use the command git log to get the hash. With the hash, use the command git reset --hard hash-id to return your project to state, deleting all changes that were done after that commit. If you want only to undo the changes, preserving the mess changes in the history, use the command git revert hash-id. William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Sun, Jul 14, 2013 at 3:07 AM, HWSWMAN ed.pat...@gmail.com wrote: suppose i have a directory with many files .. i commit a good version .. then i make a bunch of changes and i messed something up .. how do i revert back to the old version? will all the files be replaced from the current messed up files to the older good files? i am using SourceTree -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] reverting back
... and git will put back the old files? On Sat, Jul 13, 2013 at 11:55 PM, William Seiti Mizuta william.miz...@gmail.com wrote: Hi Hwswman, I don't use SourceTree, but I know how to you do it in command line: if you want to delete forever the changes you have done, you need to get the commit hash of the commit where you want to return (the commit before the mess). For that you can use the command git log to get the hash. With the hash, use the command git reset --hard hash-id to return your project to state, deleting all changes that were done after that commit. If you want only to undo the changes, preserving the mess changes in the history, use the command git revert hash-id. William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Sun, Jul 14, 2013 at 3:07 AM, HWSWMAN ed.pat...@gmail.com wrote: suppose i have a directory with many files .. i commit a good version .. then i make a bunch of changes and i messed something up .. how do i revert back to the old version? will all the files be replaced from the current messed up files to the older good files? i am using SourceTree -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/hpjOxGit-6g/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] reverting back
I have done a little mistake: with git reset --hard hash-id, you will return to the project state of the commit's hash. With that, all changes that were done after that commit will be lost. with git revert hash-id, you will undo the changes that were done in the commit's hash. So, only one commit will be undone in this case. In both cases, git will change the files t automatically. William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Sun, Jul 14, 2013 at 3:59 AM, Ed Pataky ed.pat...@gmail.com wrote: ... and git will put back the old files? On Sat, Jul 13, 2013 at 11:55 PM, William Seiti Mizuta william.miz...@gmail.com wrote: Hi Hwswman, I don't use SourceTree, but I know how to you do it in command line: if you want to delete forever the changes you have done, you need to get the commit hash of the commit where you want to return (the commit before the mess). For that you can use the command git log to get the hash. With the hash, use the command git reset --hard hash-id to return your project to state, deleting all changes that were done after that commit. If you want only to undo the changes, preserving the mess changes in the history, use the command git revert hash-id. William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Sun, Jul 14, 2013 at 3:07 AM, HWSWMAN ed.pat...@gmail.com wrote: suppose i have a directory with many files .. i commit a good version .. then i make a bunch of changes and i messed something up .. how do i revert back to the old version? will all the files be replaced from the current messed up files to the older good files? i am using SourceTree -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/hpjOxGit-6g/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [git-users] reverting back
awesome thanks On Sun, Jul 14, 2013 at 12:07 AM, William Seiti Mizuta william.miz...@gmail.com wrote: I have done a little mistake: with git reset --hard hash-id, you will return to the project state of the commit's hash. With that, all changes that were done after that commit will be lost. with git revert hash-id, you will undo the changes that were done in the commit's hash. So, only one commit will be undone in this case. In both cases, git will change the files t automatically. William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Sun, Jul 14, 2013 at 3:59 AM, Ed Pataky ed.pat...@gmail.com wrote: ... and git will put back the old files? On Sat, Jul 13, 2013 at 11:55 PM, William Seiti Mizuta william.miz...@gmail.com wrote: Hi Hwswman, I don't use SourceTree, but I know how to you do it in command line: if you want to delete forever the changes you have done, you need to get the commit hash of the commit where you want to return (the commit before the mess). For that you can use the command git log to get the hash. With the hash, use the command git reset --hard hash-id to return your project to state, deleting all changes that were done after that commit. If you want only to undo the changes, preserving the mess changes in the history, use the command git revert hash-id. William Seiti Mizuta @williammizuta Caelum | Ensino e Inovação www.caelum.com.br On Sun, Jul 14, 2013 at 3:07 AM, HWSWMAN ed.pat...@gmail.com wrote: suppose i have a directory with many files .. i commit a good version .. then i make a bunch of changes and i messed something up .. how do i revert back to the old version? will all the files be replaced from the current messed up files to the older good files? i am using SourceTree -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/hpjOxGit-6g/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to a topic in the Google Groups Git for human beings group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/git-users/hpjOxGit-6g/unsubscribe. To unsubscribe from this group and all its topics, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
