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