[kwlug-disc] Advanced(?) Git usage question
unsolicited at swiz.ca
Wed Apr 9 19:37:32 EDT 2014
This would drive everyone nuts, this approach. But John has more
experience in revision control in a multi-party/person development
environment than I.
With this approach, everyone with a bug in release could not know if
their bug is impacted by your bug. So do they now all start doing as
suggested and each willy nilly (locally?) start creating branches? Chaos.
I would have thought go back to release where bug introduced. Fix there.
Perhaps with creating a branch, but probably not depending upon extent
of code in fix. At the least, bug fix -> .1 at that level? Maybe not.
Perhaps just rebuild - but would a mere rebuild cause later releases to
pick up and include such change, or only upon a release version number
It would then be, I would think, your responsibility to burp that up to
every other release based upon the .0 that was. Or the group's (per its
policies)? i.e. Each other release now based out of .1, not .0.
Then once burped to top, those others with bugs could know that their
bug is not dependent upon or caused by your bug.
In a group environment, where everyone is working on their own bugs /
features ... this is why acetaminophen was invented?
In any case, I would think group policies / procedures would prevail.
On 14-04-09 04:14 PM, John Johnson wrote:
> On 2014-04-09 15:44, Adam Glauser wrote:
>> It seems like an awful lot of work for a very minor bugfix, ...
> IMO For the administration angle, The "awful lot of work" has no
> relation to the complexity or the severity of the bugfix. It is an evil,
> maybe even a necessary evil from a 'best practices' point of view.
> Having said the above, an alternate approach would be to take a branch
> now of the release candidate, fix the bug in that branch and migrate the
> patch back to the mater and the feature branch. What I call the "rewind"
> approach, i.e. rewinding to the commit before A, lets call it commit
> A-1, is a valid approach, but you may have to migrate many more changes
> made since A-1, A and B, etc. back to that branch.
> IMO Focusing on only the current bug and its bugfix is less risky.
> FWIW: This is from a Git newbie, having just started with Git, working
> with two local repositories one of which is branched as a result of a
> kwlug-disc mailing list
> kwlug-disc at kwlug.org
More information about the kwlug-disc