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 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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
