Re: [git-users] reverting back to earlier version to find a bug

[Philip Oakley]

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" 

To: 
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" 

To: "Git for human beings" 
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" 
>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 

Re: [git-users] reverting back to earlier version to find a bug

[Philip Oakley]

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" 

To: "Git for human beings" 
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" 
>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 **

...and:

git tag last-working **

That way you`ll have two tags you can always come back to, 
"latest-broken"

and 

Re: [git-users] reverting back to earlier version to find a bug

[rhkramer]

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.