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