Hi Russ P,
On Sunday, December 10, 2017 at 1:30:18 AM UTC+1, Philip Oakley wrote:
>
> From: "Russ P" <[email protected] <javascript:>>
> >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
to [email protected].
For more options, visit https://groups.google.com/d/optout.
