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 

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?


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" <> 
>> >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 you 
> start doing anything, you may do:
>     git tag latest-broken *<sha1 of latest/broken version commit>*
> ...and:
>     git tag last-working *<sha1 of last working version commit>*
> That way you`ll have two tags you can always come back to, "latest-broken" 
> and "last-working", in case you mess up something with your branches.
> Even when things "go wrong", losing stuff with Git is not easy (it`s 
> pretty hard, actually), but it might be easier to explain to you what to do 
> if you have these two tags, than without them :)
> That said, seeing you`re not sure when/what to use a branch for, and 
> looking at the list of basic commands you`re familiar with, please do let 
> us know if things like "head", "rebase", "amend", "cherry-pick", "bisect" 
> are too much for you at the moment, so hopefully some more detailed, step 
> by step help could be provided.
> Regards, Buga

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 
For more options, visit

Reply via email to