Re: Version control support call for help
- From: Kai Willadsen <kai willadsen gmail com>
- To: Louis des Landes <louis obsidian com au>
- Cc: meld-list <meld-list gnome org>
- Subject: Re: Version control support call for help
- Date: Wed, 29 May 2013 06:12:56 +1000
On 28 May 2013 18:30, Louis des Landes <louis obsidian com au> wrote:
Having a browse through at the moment.
Some quick questions:
* get_commit_message_prefill - you use a file (.git/MERGE_MSG) which only
exists when git has just done a merge? Bazaar doesn't have an equivalent
here, although I guess we could check if there's a pending merge and put
some text in manually, but I feel this is the wrong choice.
I don't know what the right choice is here, but it's going to be a
VC-by-VC thing. This was added so that *if* there is a pre-filled
commit message, then we pick it up. In other words, if, when you went
to git commit from the command line, there would have already been a
commit message waiting for you to edit, then we try to use that. For
reference, this was added to fix
https://bugzilla.gnome.org/show_bug.cgi?id=699400.
* Should the various commit/diff/update/add/remove/revert methods use the
existing <method>_command (diff_command etc) methods? There seems to be some
duplication here, but I'm guessing it's a WIP.
Yeah, there's duplication because until a couple of weekends ago we
needed the blah_command functions for sensitivity setting. Any
duplicates of those can now be removed as long as the module
implements update_actions_for_paths().
<snip>
Happy to take this conversation off list if it's more convenient (github
comments perhaps?)
I'm happy to go where ever, but why don't we keep it here for now, so
that if anyone else wants to put their hand up then we have records of
stuff. (I try to keep the github mirror up-to-date, but Gnome git is
still the canonical reference for development.) Having said that, if
you want to comment on specific pieces of code on github, then I can
see how that makes sense.
For reference, my priorities right now are to try and mash our VC
handling into somewhat better shape, clean up, and release a new
stable series. This would be the last GTK+ 2 release series, and we'd
then *finally* start moving to GTK 3 (and accompanying migrations) and
breaking things.
cheers,
Kai
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]