How to keep uncommitted work in a git clone

[Ryan Schmidt]

> On Nov 5, 2016, at 3:07 AM, Mojca Miklavec <mojca at macports.org> wrote:
> 
> On 5 November 2016 at 08:39, Ryan Schmidt wrote:
>> On Nov 4, 2016, at 12:39 AM, David Bariod wrote:
>> 
>>> 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.
>> 
>> Coming from a Subversion background, where you commit when you are finished with your work and not before, this reversal is very difficult for me to grasp.
>> 
>> I don't know how to rework a commit later.
>> 
>> I don't know how to, let's say, commit my unfinished work on curl, then make changes to libpng and commit them, and then push only the finished libpng commit and not the unfinished curl commit to upstream.
> 
> # create a new branch for temporary work on curl
> git checkout -b playing-with-curl
> # same as:
> # git branch playing-with-curl && git checkout playing-with-curl
> 
> #add temporary changes
> git add net/curl/Portfile
> git commit
> <enter the commit message>
> 
> # you could (optionally) do your libpng-related work in a branch as well
> # users without commit rights or any developer wanting to submit a pull request
> # for review before committing have to do this anyway;
> # you you do this in master
> git checkout -b fix-for-libpng
> # add and commit changes
> git add graphics/libpng/Portfile
> git add graphics/libpng/file/the-patch-you-just-added.diff
> # review changes
> git diff --cached
> git commit
> <enter the commit message>
> 
> # go to master and pull the latest changes
> git checkout master
> git pull --rebase
> 
> # if you did your work on libpng in master, you are then set
> 
> # else go to your libpng branch and rebase the changes on top of the
> latest master
> git rebase master
> # I don't want to give wrong instructions here, but I suspect that even
> # "git push origin master" works in this case
> 
> 
> Then, when you want to resume your work on curl:
> 
> git checkout playing-with-curl
> <do your stuff>
> git add net/curl/Portfile
> git commit
> <do more stuff>
> git add net/curl/files/some-fix.patch
> git commit
> 
> # at any point you can also do
> git rebase master
> 
> Now you have three or more commits. Check with "git log". You can
> merge them with
> 
> git rebase -i HEAD~3
> 
> This will open a new editor and you have to replace "pick" with "squash". See
>    http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
> or google for other examples.

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.