How to keep uncommitted work in a git clone

David Bariod davidriod at googlemail.com
Fri Nov 4 03:10:35 PDT 2016


On Fri, Nov 4, 2016 at 10:20 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk>
wrote:

> Hi,
>
> On 04/11/16 09:16, David Bariod wrote:
>
>>
>>
>> On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones <jonesc at hep.phy.cam.ac.uk
>> <mailto:jonesc at hep.phy.cam.ac.uk>> wrote:
>>
>>
>>
>>     On 04/11/16 05:39, David Bariod wrote:
>>
>>         Hello,
>>
>>         Personnally, I would just commit such change. It is cheap, can be
>>         reworked later and be ketp safe in a private remote repository
>>         in case
>>         of disaster.
>>         With git there are no reason to not commit event not ready yet
>>         change set.
>>
>>
>>     I would not do this, as you then might end up with a lot of
>>     intermediary commits in the history. better I think to work on
>>     independent projects on independent branches.
>>
>>
>> Then you can do a git rebase -i to clean up when you want to publish
>> your final state.
>>
>
> Still, if you have independent pieces of work in progress, its still
> better IMHO to separate them into branches. The policy of not working on
> the master with git is not my idea, its a widely held piece of (good)
> advice, for various reasons.
>

Yes, using different branch is definitely a good idea

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20161104/feebf19b/attachment-0001.html>


More information about the macports-dev mailing list