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. 


> 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