daggy fixes should be easier
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.
Changed in bzr: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
tags: | added: check-for-breezy |
-----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' /code.edge. launchpad. net/~mhammond/ bzr/update- r/+merge/ 6980
to 'bzr update' here:
https:/
Mostly it is waiting for someone to champion it, so that we can get it
going again.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkr oYSEACgkQJdeBCY SNAAMd+ QCgpasbjQFVtd2i oPh5J3CkfJpr amQSNeb0ijUHCr4 /W
9NIAnijCGPIrkQz
=sOJY
-----END PGP SIGNATURE-----