Martin Pool wrote:
> This patch, proposed by Anne Mohsen, allows saving the commit messages
> from uncommit so that they can be reused later. It's currently
> lacking a test, but I believe not everything in bzr-gtk is well tested
> automatically, so perhaps that is not making things worse. Apparently
> it is highly desired so I'm going to both post it and start reviewing
> it myself.
>
> I'm not sure if putting it into the branch config is the ideal
> location but it's probably reasonable.
>
>
I started looking at it a bit. One issue is that it only allows a single
commit to be saved. If you compare that to things like "TSVN" which has
a whole list of items. (Including the one you accidentally failed to
commit because you hit escape thinking you were in Vim :)
There is also some friction because you can only really commit from a
WorkingTree, but it is saving the value in a Branch location. Also, for
things like TBZR, it would be more similar if we had a global cache of
recent commit messages, rather than just the local one.
Then again, being able to do:
bzr uncommit
bzr gcommit
and have it default to the uncommitted message, would really indicate
that it is a local-to-the-tree cache.
There is also a lot of PEP8 issues in the bzr side of things (note that
the bzrlib.uncommit.py.diff is meant as a bzr patch, not as a patch to
bzr-gtk.)
Also, it certainly shouldn't be called "gtk_global_commit_message" if it
is going to be in bzrlib. I think it would be fair to bring something
in, which could then be shared by "bzr uncommit", "bzr-gtk gcommit",
"qbzr qcommit" etc.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Martin Pool wrote:
> This patch, proposed by Anne Mohsen, allows saving the commit messages
> from uncommit so that they can be reused later. It's currently
> lacking a test, but I believe not everything in bzr-gtk is well tested
> automatically, so perhaps that is not making things worse. Apparently
> it is highly desired so I'm going to both post it and start reviewing
> it myself.
>
> I'm not sure if putting it into the branch config is the ideal
> location but it's probably reasonable.
>
>
I started looking at it a bit. One issue is that it only allows a single
commit to be saved. If you compare that to things like "TSVN" which has
a whole list of items. (Including the one you accidentally failed to
commit because you hit escape thinking you were in Vim :)
There is also some friction because you can only really commit from a
WorkingTree, but it is saving the value in a Branch location. Also, for
things like TBZR, it would be more similar if we had a global cache of
recent commit messages, rather than just the local one.
Then again, being able to do:
bzr uncommit
bzr gcommit
and have it default to the uncommitted message, would really indicate
that it is a local-to-the-tree cache.
There is also a lot of PEP8 issues in the bzr side of things (note that uncommit. py.diff is meant as a bzr patch, not as a patch to
the bzrlib.
bzr-gtk.)
Also, it certainly shouldn't be called "gtk_global_ commit_ message" if it
is going to be in bzrlib. I think it would be fair to bring something
in, which could then be shared by "bzr uncommit", "bzr-gtk gcommit",
"qbzr qcommit" etc.
John
=:->
-----BEGIN PGP SIGNATURE----- enigmail. mozdev. org
stPIACgkQJdeBCY SNAANd3gCgwx3PN ImmyTFsS+ j7ROTkU9yC dfx5botBEBf+ 3idgD
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAkj
nWYAn0pnBcraJ45
=hsDR
-----END PGP SIGNATURE-----