The other thing to realise with git is commits are a lot cheaper, as in the 
first instance they are only to your local checkout. So if you have a bunch of 
’this commit is just so I can save the current state of this branch and switch 
to another’ commits these can be squashed before you eventually push that 
branch upstream and submit a PR for it, so they never appear in the final 
history. For this reason committing partially completed pieces of work is not 
an issue, as you can finally squash them to a single ‘this implements this’ 
commit before pushing it.

cheers Chris

> On 5 Nov 2016, at 10:34 am, Christopher Jones <jon...@hep.phy.cam.ac.uk> 
> wrote:
> Hi,
> I did the svn->git translation myself at work in the recent past and went 
> through exactly the same things as you are now. Git and Svn are very 
> different in some regards and workflows that worked with svn simply do not 
> with git. The ‘make all changes on master and commit only what I want each 
> time’ is one pattern from svn that does not map well to git. It took me a 
> while to realise it but branches are I am afraid really the best way forward 
> here. It does take a while to get use to but once you do it starts to make 
> more and more sense, and now I would not want to go back. 
> Chris
>> While I understand the benefit in principle of working on separate branches 
>> for separate tasks, this is not how I have been using my MacPorts Subversion 
>> working copy for the past 9 years. I keep most the my modifications I'm 
>> working on in that working copy. If I want to remind myself to include a 
>> change with the next version of curl, I make the change to the curl portfile 
>> and leave it there, so that when "port livecheck curl" next lets me know 
>> there's an update, the change will be there for me, ready to be included 
>> with the update commit.
>> Committing that curl work in progress to a separate branch implies that I 
>> will remember -- later, when livecheck tells me about a curl update -- that 
>> I had other work I wanted to include with that update, and which branch I 
>> had put it on.
>> Even today, I forgot to remove "# $Id$" lines from ports that I committed. 
>> It's not a big deal, but it had been my plan to do so. I would like to 
>> remove the Id lines from all my ports now, and not commit that change, so 
>> that the change is there ready to go when I do make the next commit to those 
>> ports.
>> _______________________________________________
>> macports-dev mailing list
>> macports-dev@lists.macosforge.org <mailto:macports-dev@lists.macosforge.org>
>> https://lists.macosforge.org/mailman/listinfo/macports-dev 
>> <https://lists.macosforge.org/mailman/listinfo/macports-dev>

macports-dev mailing list

Reply via email to