daggy fixes should be easier

Bug #462671 reported by Per Johansson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Wishlist
Unassigned

Bug Description

Daggy fixes is where you fix a bug close to where it was introduced instead of at the head of the branch. If you develop your fix on a checkout from the head, before remembering it should be a daggy fix, you have to do something like this:

bzr branch -r <bugrevno> mytree myfix
cd myfix
bzr diff ../mytree | patch -p0
bzr commit
cd ../mytree
bzr merge --force ../myfix
bzr commit

just to get a commit with parent set as <bugrevno> and a merge.

All steps except the last one could be done by adding a flag to commit, for example --base.
You could then end up with a pending merge in the local tree without having to create a separate branch juse to apply it.

If you think that is too much abuse of the commit command (it doesn't actually send anything to the repo), I guess a new command could be in order.

Revision history for this message
John A Meinel (jameinel) wrote : Re: [Bug 462671] [NEW] daggy fixes should be easier

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Per Johansson wrote:
> Public bug reported:
>
> Daggy fixes is where you fix a bug close to where it was introduced
> instead of at the head of the branch. If you develop your fix on a
> checkout from the head, before remembering it should be a daggy fix, you
> have to do something like this:
>
> bzr branch -r <bugrevno> mytree myfix
> cd myfix
> bzr diff ../mytree | patch -p0
> bzr commit
> cd ../mytree
> bzr merge --force ../myfix
> bzr commit
>
> just to get a commit with parent set as <bugrevno> and a merge.
>
> All steps except the last one could be done by adding a flag to commit, for example --base.
> You could then end up with a pending merge in the local tree without having to create a separate branch juse to apply it.
>
> If you think that is too much abuse of the commit command (it doesn't
> actually send anything to the repo), I guess a new command could be in
> order.
>
> ** Affects: bzr
> Importance: Undecided
> Status: New
>

commit --base is problematic because we have to figure out how the
current changes apply to the old working tree. Which may have renamed
files, or all sorts of things. So you don't *really* know if the fix
truly applies to the old tree.

However, we would like it to be easier to switch to create a new branch,
or switch your working tree to the old revision.

What about something like:

bzr update -r bugrevno
# hack
# test
bzr commit --local -m "bugfix"
bzr update

at this point, the commit --local + update should give you the same
pending merge, only this time you actually tested that it fixes the bug
back where you wanted it to be applied.

Note that there is a (unfortunately very old) proposal to provide '-r'
to 'bzr update' here:
https://code.edge.launchpad.net/~mhammond/bzr/update-r/+merge/6980

Mostly it is waiting for someone to champion it, so that we can get it
going again.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkroYSEACgkQJdeBCYSNAAMd+QCgpasbjQFVtd2ioPh5J3CkfJpr
9NIAnijCGPIrkQzamQSNeb0ijUHCr4/W
=sOJY
-----END PGP SIGNATURE-----

Revision history for this message
Per Johansson (per.j) wrote :

While updating and doing the testing is the most correct way to do it, it might not be desirable to modify (and thus needing to recompile) hundreds of files for a simple fix. You're right that there might be problems with renamed files etc, but I think it's something that could be weighted in (not that I know much about bazaar internals really).

Since there still would be another commit to actually send the change to the repo, there's plenty of time to check the patch. Likely update -r could be seen as a prerequisite for this feature though.

Martin Pool (mbp)
Changed in bzr:
importance: Undecided → Wishlist
status: New → Confirmed
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.