Re: How to keep uncommitted work in a git clone

[Michael]

Keep in mind that there was one overall design goal of git: Whenever there was 
more than one right way to do something, do the opposite of svn.

That is not a joke or exaggeration. 

Branches in git are dirt cheap -- they consist of creating a 40 byte file.
"git add" to put stuff into git is moderately expensive -- the hash of the file 
needs to be calculated, and a copy of the file made.
"git commit" is cheap -- all the information needed has been calculated and 
updated by git add, except for two hashes on short files (your commit message, 
and the list of hashes already in the cache). (This is slightly simplified, but 
close enough).

On the assumption that curl and libpng are unrelated, my first thought would be 
that they would have different repositories. I.e. -- work done on curl is in 
one place, work done on libpng is in another place. If they are in the same 
repository for administrative purposes, ... (ick) ... then I'd suggest using a 
feature of git that I just recently found: worktrees.

"git worktree" can make a second working directory backed by the same 
repository.

This lets you have one working directory for libpng, and one working directory 
for curl. You can switch between them with a "pushd", and treat them entirely 
separate.

Beyond that? If your model is "one working directory", and one repository?

Then "master" would only contain stuff that you want to publish.

To start work on a curl item:

git checkout master
git checkout -b curl-item-name
.. work work owkr test fix work test happy ...
git commit
git checkout master
git merge curl-item-name

At any time in the "work" cycle, you can just say

git commit -m "Work in progress -- blah blah blah"
git checkout master

git checkout -b libpng-item-name


To see the status of your active branches:
gitk --all


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Christopher Jones]

Hi,

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  
> 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 
>> https://lists.macosforge.org/mailman/listinfo/macports-dev 
>> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Christopher Jones]

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 
> https://lists.macosforge.org/mailman/listinfo/macports-dev 
> 
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Ryan Schmidt]

> On Nov 5, 2016, at 3:07 AM, Mojca Miklavec  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
> 
> 
> # 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
> 
> 
> # 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
> 
> git add net/curl/Portfile
> git commit
> 
> 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.


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Mojca Miklavec]

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


# 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


# 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

git add net/curl/Portfile
git commit

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.

Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Ryan Schmidt]

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.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Michael]

On 2016-11-03, at 10:39 PM, 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.
> 
> Best regards,
> David

I assume that last line should be "to not commit even not ready yet change 
sets".

I agree that you can commit anything.
But only if you follow the rule of not working/committing directly to master.
Leave your junk on a side branch, and put the fixed-up work into master later.


---
Entertaining minecraft videos
http://YouTube.com/keybounce

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[David Bariod]

On Fri, Nov 4, 2016 at 10:20 AM, Chris Jones 
wrote:

> Hi,
>
> On 04/11/16 09:16, David Bariod wrote:
>
>>
>>
>> On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones > > 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
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[David Bariod]

On Fri, Nov 4, 2016 at 9:55 AM, Chris Jones 
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.

David
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Chris Jones]

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.


Chris



Best regards,
David

On Fri, Nov 4, 2016 at 2:56 AM, Ryan Schmidt > wrote:

With Subversion, I was accustomed to keeping changes in my working
copy that I was not ready to commit yet.

Git doesn't let me do that. It complains and tells me to git stash
and later git stash pop.

Well, I tried that. I git stashed, then made changes to curl and
committed them, and later when I tried to git stash pop, my other
changes that I had in my git clone were not restored. I have no idea
where they are now.

I can get these particular changes back from my old Subversion
working copy, but I don't understand how I'm meant to work with git
when I have changes that I'm not ready to commit yet, yet there are
other changes I need to make and commit elsewhere within that same
clone.

___
macports-dev mailing list
macports-dev@lists.macosforge.org

https://lists.macosforge.org/mailman/listinfo/macports-dev





___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Chris Jones]

On 04/11/16 04:18, Sterling Smith wrote:


On Nov 3, 2016, at 7:54PM, Arno Hautala  wrote:


On Thu, Nov 3, 2016 at 9:56 PM, Ryan Schmidt  wrote:


Well, I tried that. I git stashed, then made changes to curl and committed 
them, and later when I tried to git stash pop, my other changes that I had in 
my git clone were not restored. I have no idea where they are now.


There's also another paradigm to adopt which avoids stashing entirely.
Just always work in a branch and feel free to commit even if you're in
the middle of something. In your case, you're working on something
(let's say it's wget), but curl needs to be fixed too. Commit your
incomplete changes on the "wget-update" branch, `git checkout -b
curl-update master` to create and checkout a curl branch, complete
your work there, and then switch back to the "wget-update" branch.

This is my preference.  I tried stash as well once, and had trouble with it.


I would agree.

You should get out of the habit of working on the master branch. Leave 
that pristine and in sync with GitHub. For each separate project you are 
working out create a branch (from the master) and work on that. When you 
are ready you can then push that branch to GitHub and create a pull 
request for it.


Chris



-Sterling
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Joshua Root]

On 2016-11-4 12:56 , Ryan Schmidt wrote:

With Subversion, I was accustomed to keeping changes in my working copy that I 
was not ready to commit yet.

Git doesn't let me do that. It complains and tells me to git stash and later 
git stash pop.

Well, I tried that. I git stashed, then made changes to curl and committed 
them, and later when I tried to git stash pop, my other changes that I had in 
my git clone were not restored. I have no idea where they are now.

I can get these particular changes back from my old Subversion working copy, 
but I don't understand how I'm meant to work with git when I have changes that 
I'm not ready to commit yet, yet there are other changes I need to make and 
commit elsewhere within that same clone.


Using autostash as discussed earlier works well for me:



- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: How to keep uncommitted work in a git clone

[Jeremy Lavergne]

Religiously use `git status`, and perhaps update your shell prompt to
reflect it as well: branch name, unstaged changes, staged changes, etc.
Consider looking on Google for prompts that incorporate functions like
__git_ps1:
GIT_PS1_SHOWDIRTYSTATE="1"
GIT_PS1_SHOWUNTRACKEDFILES="1"
PS1="\h:\W \u$BLUE\$(__git_ps1 \" [%s]\")$DEFAULT\$ "


The current working tree is by default unstaged. You must select what to
stage, or explicitly indicate files during actions. For example, these
are equivalent commands for commits changes to foo.txt (a file already
in the repo):

 1echo "asdf" >> foo.txt
  git add foo.txt
  git commit -m "adding foo"

 2echo "asdf" >> foo.txt
  git commit foo.txt -m "adding foo"


That first form is how you commit only explicit files while leaving more
for a subsequent commit. Same idea for `git add -p` for parts of files.
Once things are staged, leaving off filenames means the actions apply to
the staged changes.



Regarding the stash situation:  The nice thing about git is won't do
anything destructive without you forcing it.

Checkout the stashes and see if you perhaps made a second one?
   git stash list  # (or otherwise `git help stash`)
   git show stash@{0}


So your changes are very likely still there: either as a second stash,
or perhaps conflicting with the new working tree.

git status :-)


On 11/03/2016 09:56 PM, Ryan Schmidt wrote:
> With Subversion, I was accustomed to keeping changes in my working copy that 
> I was not ready to commit yet.
> 
> Git doesn't let me do that. It complains and tells me to git stash and later 
> git stash pop.
> 
> Well, I tried that. I git stashed, then made changes to curl and committed 
> them, and later when I tried to git stash pop, my other changes that I had in 
> my git clone were not restored. I have no idea where they are now.
> 
> I can get these particular changes back from my old Subversion working copy, 
> but I don't understand how I'm meant to work with git when I have changes 
> that I'm not ready to commit yet, yet there are other changes I need to make 
> and commit elsewhere within that same clone.

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev