Ah, yes, a partial-commit is a definite use-case.  The way I handle
that today is I simply leave up the Changes window.  I select the
changes I want to leave behind and select "revert" on them
individually.  Then I click "Ok" on the Save dialog, then "install"
back on the Changes window to reinstall them and continue development
on them.  Clumsy, for sure.

Today Monticello-bf.540 has "Accept" and "Cancel" I propose we add two buttons:

  Refresh List -- re-snapshots the package and redisplays the list
  Accept List -- Commits the changes listed in the list.
  Accept Package -- Commits all changes to the package, whether listed or not.
  Cancel

That way all of the use-cases are integrated together.  How does that sound?


On Fri, May 3, 2013 at 3:50 PM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> A partial commit is useful when you have several unrelated changes in the
> same pakage and you don't want to commit them all.
> A clean and costly process would be to
> - save all changes locally (file out, local package-cache, whatever...)
> - download a fresh and clean up to date image
> - selectively re-install some of the changes in clean image
> - test
> - commit
> An alternative is to partially commit to a local package from the dirty
> image, and load from clean.
> A quick and dirty process is to directly and partially commit to inbox or
> trunk from the dirty image (more dangerous, but for a few lines of changes
> it rocks).
>
>
> 2013/5/3 Chris Muller <asqueaker at gmail.com>
>>
>> What is a partial commit and when/why do I want to do it?
>>
>> On Fri, May 3, 2013 at 6:42 AM, Bert Freudenberg <bert at freudenbergs.de>
>> wrote:
>> > Good point, I'm not sure. Colin? If this is a problem we should
>> > disallow/warn about partial commits from merges.
>> >
>> > - Bert -
>> >
>> > On 2013-05-03, at 13:23, Nicolas Cellier
>> > <nicolas.cellier.aka.nice at gmail.com> wrote:
>> >
>> > A possible side effect with this scenario:
>> >
>> > 1) I merge load trunk package version X
>> > 2) I merge a third-party version Z,
>> > 3) I partially publish version Y without the Z changes.
>> >
>> > Will Z figure in the Y ancestors?
>> > If so, that might be a problem when later trying to merge Z again in
>> > another
>> > image...
>> >
>> > Nicolas
>> >
>> >
>> > 2013/5/3 Bert Freudenberg <bert at freudenbergs.de>
>> >>
>> >>
>> >> On 2013-05-02, at 20:49, Frank Shearar <frank.shearar at gmail.com> wrote:
>> >>
>> >> > On 2 May 2013 19:19, Chris Muller <asqueaker at gmail.com> wrote:
>> >> >> Hmph -- since you were asking for consensus on something, it would
>> >> >> be
>> >> >> nice to have a little more time to respond -- as I did in < 24
>> >> >> hours,
>> >> >> but still apparently too late.
>> >> >>
>> >> >>
>> >> >> didn't get much discussion.  ay we please have more time
>> >> >
>> >> > Sure. In my defence, this was seriously getting in my way... but I
>> >> > guess the response to that is "well keep the change in your image".
>> >> > Ah, well.
>> >> >
>> >> > frank
>> >>
>> >>
>> >> Maybe you should try my "allow partial commits" Monticello mod
>> >> (Monticello-bf.540 in inbox). I have been using it for months now and
>> >> it
>> >> works really well. Back in January I got a few +1s but Chris was
>> >> opposed so
>> >> I did not put it into trunk, yet. I have not found the time to add the
>> >> "do
>> >> yet another snapshot when pressing save" Chris wanted because in my
>> >> workflow
>> >> it's not needed. But perhaps it's good enough? For me it certainly was
>> >> a
>> >> relief keeping some changes to my image while still being able to
>> >> commit
>> >> "clean" packages to trunk.
>> >>
>> >> - Bert -
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> >
>> >
>> >
>>
>
>
>
>