Howto request: going home in the middle of something?

Howto request: going home in the middle of something?

[Jan Wielemaker]

Hi,

I've somewhere seen it in a mail, but I can't find it anymore. I have a
bare central (public) repository and clones on various machines I work
on. We all know it, you're right in the middle of something and it is
really time to go home. You want to pick up your work at home, but
without pushing to the shared repository.

I'm sure GIT can do this elegantly, but I'm not yet sure how.  I guess
Ideally I want "git stash" at work, transfer the stashed changes to my
other machine and apply them.  How do I do that?

Alternatively, I guess, one can commit at machine A, fetch the commit
from machine A and continue. I'm still too uncertain about the remote
access options to work this out properly, but it also feels less
clean.

How do you deal with this?

	Thanks --- Jan

Re: Howto request: going home in the middle of something?

[Johannes Sixt]

Jan Wielemaker schrieb:
> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
> 
> I'm sure GIT can do this elegantly, but I'm not yet sure how.  I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them.  How do I do that?

One way is to use a bundle:

$ git checkout -b home
$ git bundle create home.bdl origin..home

Then put home.bdl on or USB stick or send by email. At home:

$ git fetch home.bdl home
$ git checkout -b to-be-continued FETCH_HEAD

You better make double sure that the commit "origin" that is used above is 
available at home.

Judge yourself whether this is "elegant".

-- Hannes

Re: Howto request: going home in the middle of something?

[Karl Hasselström]

On 2007-10-18 12:37:50 +0200, Johannes Sixt wrote:

> Jan Wielemaker schrieb:
>
> > I've somewhere seen it in a mail, but I can't find it anymore. I
> > have a bare central (public) repository and clones on various
> > machines I work on. We all know it, you're right in the middle of
> > something and it is really time to go home. You want to pick up
> > your work at home, but without pushing to the shared repository.
> >
> > I'm sure GIT can do this elegantly, but I'm not yet sure how. I
> > guess Ideally I want "git stash" at work, transfer the stashed
> > changes to my other machine and apply them. How do I do that?
>
> One way is to use a bundle:

Another way is to push the unfinished changes to a temp branch, either
at the same central repository if it's acceptable for people to have
temp branches there, or at another repository where temp branches
_are_ permitted. All you need to set up a private repository for
yourself is an ssh account somewhere. Or you could store the
repository on an usb stick.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: Howto request: going home in the middle of something?

[Petr Baudis]

  Hi,

On Thu, Oct 18, 2007 at 11:44:22AM +0200, Jan Wielemaker wrote:
> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
> 
> I'm sure GIT can do this elegantly, but I'm not yet sure how.  I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them.  How do I do that?
> 
> Alternatively, I guess, one can commit at machine A, fetch the commit
> from machine A and continue. I'm still too uncertain about the remote
> access options to work this out properly, but it also feels less
> clean.

  this should be pretty simple assuming SSH access to machine A. Git can
fetch over SSH, so it's merely about telling it that repository X is
available over ssh over there and it'll fetch it home.

  The exact setup depends on whether you want to do this just once or
semi-regularily.  If the former, just

	git pull git+ssh://a.machine.aero/absolute/path

Note that this should fetch only the remote master branch, if I'm not
mistaken.

  If the latter, tell your home repository about your work repository:

	git remote add workrepo git+ssh://a.machine.aero/absolute/path

  Then, you can anytime just

	git fetch workrepo

and it will fetch all the branches from workrepo; whether you want to
use git fetch and git merge or git pull depends on your local
arrangement of branches at home.


  So, basically, when fetching you deal with your work repository
exactly the same way as in the shared repository.

  When pushing, this is not so trivial. Git _allows_ you to just push to
your work repository, but if you push to a branch that is currently
checked out, unexpected things will happen - always avoid that. If you
can fetch from home at work, do. If not, at least push to a branch at
work that can never be checked out and is reserved for that purpose.

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber

Re: Howto request: going home in the middle of something?

[Andy Parkins]

On Thursday 2007 October 18, Jan Wielemaker wrote:

> I've somewhere seen it in a mail, but I can't find it anymore. I have a
> bare central (public) repository and clones on various machines I work
> on. We all know it, you're right in the middle of something and it is
> really time to go home. You want to pick up your work at home, but
> without pushing to the shared repository.
>
> I'm sure GIT can do this elegantly, but I'm not yet sure how.  I guess
> Ideally I want "git stash" at work, transfer the stashed changes to my
> other machine and apply them.  How do I do that?
>
> Alternatively, I guess, one can commit at machine A, fetch the commit
> from machine A and continue. I'm still too uncertain about the remote
> access options to work this out properly, but it also feels less
> clean.
>
> How do you deal with this?

I have two remotes (typically) in my .git/config.  One for the real central 
repository and one for the alternate computer.  The two locations (say home 
and work) list the other as a remote.

So; before I go home I do this:

 git commit -b temp -a -m "Hold for transport home"

Then when I get home I do this:

 git fetch work
 git merge work/temp
 git reset HEAD^
 # code code code
 git commit -b temp -a -m "Hold for transport to work"

When I'm finished at home and want to carry on at work:

 git fetch --force home
 git merge home/temp
 git reset HEAD^
 # start coding for the day

Obviously if you do this repeatedly you'd need to tidy up the left over temp 
branches, or ensure that your remote configurations list "+" in the fetch 
lines.  You can also use pushes instead of fetches if you're that way 
inclined, or you have a connection problem in one direction because of a 
firewall.

It's slightly inelegant but it does ensure that nothing is ever accidentally 
lost by overwriting new with newer, which happened a few times in the days 
when I used rsync for copying the working directory between computers.



Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com

Re: Howto request: going home in the middle of something?

[Jan Wielemaker]

Thanks for the replies.	 I think I can live with something like this

	<work, in the middle of something>
	$ git checkout -b home
	$ git commit
	$ git checkout master
	<arriving at home>
	$ git jan@work:repo fetch home:home	(using ssh)
	$ git checkout home
	<continue editing>
	$ git commit --amend
	$ git checkout master
	$ git merge home
	$ git -d home
	$ git commit
	$ git push
	<arriving at work>
	$ git -d home
	$ git pull

Its still a bit many commands and you have to be aware what you are
doing for quite a while, but it does provide one single clean commit
message, doesn't change the shared repo until all is finished and allows
to abandon all work without leaving traces.

Personally I'd be more happy with

	<work, in the middle of something>
	$ git stash
	<arriving at home>
	$ git stash fetch jan@work{0}	(well, some sensible syntax)
	$ git stash apply
	<continue editing>
	$ git commit
	$ git push
	<arriving at work>
	$ git pull

Its not only shorter, but reduces the risc to make mistakes. I think the
missing fetch to copy the stashed data from work to home is actually
there if you know a bit more about git internals. Right? Ideally, this
could be combined in a little command that will simply move the
uncommitted work from one clone to another, provided you have ssh access
to the machine from which you want to fetch the work.

	--- Jan

On Thursday 18 October 2007 13:27, Petr Baudis wrote:
> On Thu, Oct 18, 2007 at 11:44:22AM +0200, Jan Wielemaker wrote:
> > I've somewhere seen it in a mail, but I can't find it anymore. I have a
> > bare central (public) repository and clones on various machines I work
> > on. We all know it, you're right in the middle of something and it is
> > really time to go home. You want to pick up your work at home, but
> > without pushing to the shared repository.
> >
> > I'm sure GIT can do this elegantly, but I'm not yet sure how.  I guess
> > Ideally I want "git stash" at work, transfer the stashed changes to my
> > other machine and apply them.  How do I do that?
> >
> > Alternatively, I guess, one can commit at machine A, fetch the commit
> > from machine A and continue. I'm still too uncertain about the remote
> > access options to work this out properly, but it also feels less
> > clean.
>
>   this should be pretty simple assuming SSH access to machine A. Git can
> fetch over SSH, so it's merely about telling it that repository X is
> available over ssh over there and it'll fetch it home.
>
>   The exact setup depends on whether you want to do this just once or
> semi-regularily.  If the former, just
>
> 	git pull git+ssh://a.machine.aero/absolute/path
>
> Note that this should fetch only the remote master branch, if I'm not
> mistaken.
>
>   If the latter, tell your home repository about your work repository:
>
> 	git remote add workrepo git+ssh://a.machine.aero/absolute/path
>
>   Then, you can anytime just
>
> 	git fetch workrepo
>
> and it will fetch all the branches from workrepo; whether you want to
> use git fetch and git merge or git pull depends on your local
> arrangement of branches at home.
>
>
>   So, basically, when fetching you deal with your work repository
> exactly the same way as in the shared repository.
>
>   When pushing, this is not so trivial. Git _allows_ you to just push to
> your work repository, but if you push to a branch that is currently
> checked out, unexpected things will happen - always avoid that. If you
> can fetch from home at work, do. If not, at least push to a branch at
> work that can never be checked out and is reserved for that purpose.

Re: Howto request: going home in the middle of something?

[Johannes Schindelin]

Hi,

On Mon, 22 Oct 2007, Jan Wielemaker wrote:

> Thanks for the replies.	 I think I can live with something like this
> 
> 	<work, in the middle of something>
> 	$ git checkout -b home
> 	$ git commit
> 	$ git checkout master
> 	<arriving at home>
> 	$ git jan@work:repo fetch home:home	(using ssh)

You probably meant "git fetch jan@work:repo home:home".

> 	$ git checkout home
> 	<continue editing>
> 	$ git commit --amend
> 	$ git checkout master
> 	$ git merge home
> 	$ git -d home
> 	$ git commit
> 	$ git push
> 	<arriving at work>
> 	$ git -d home
> 	$ git pull
> 
> Its still a bit many commands and you have to be aware what you are
> doing for quite a while, but it does provide one single clean commit
> message, doesn't change the shared repo until all is finished and allows
> to abandon all work without leaving traces.
> 
> Personally I'd be more happy with
> 
> 	<work, in the middle of something>
> 	$ git stash
> 	<arriving at home>
> 	$ git stash fetch jan@work{0}	(well, some sensible syntax)
> 	$ git stash apply
> 	<continue editing>
> 	$ git commit
> 	$ git push
> 	<arriving at work>
> 	$ git pull

Happily, that is already possible:  However, instead of

	git stash fetch jan@work{0}

you should say

	git fetch jan@work stash:stash

This will only fetch the last stash, but that is what you wanted anyway, 
right?

Ciao,
Dscho

P.S.: Since you top-posted, I just ignored the mail you quoted, assuming 
that it was not relevant to your mail.

Re: Howto request: going home in the middle of something?

[Jing Xue]

Quoting Jan Wielemaker <wielemak@science.uva.nl>:

> Thanks for the replies.	 I think I can live with something like this
>
> 	<work, in the middle of something>
> 	$ git checkout -b home
> 	$ git commit
> 	$ git checkout master
> 	<arriving at home>
> 	$ git jan@work:repo fetch home:home	(using ssh)
> 	$ git checkout home
> 	<continue editing>
> 	$ git commit --amend
> 	$ git checkout master
> 	$ git merge home
> 	$ git -d home
> 	$ git commit
> 	$ git push
> 	<arriving at work>
> 	$ git -d home
> 	$ git pull
>
> Its still a bit many commands and you have to be aware what you are
> doing for quite a while, but it does provide one single clean commit
> message, doesn't change the shared repo until all is finished and allows
> to abandon all work without leaving traces.

What does the extra branch gain for us here? That's not a rhetorical  
question, I'm actually curious to learn, because I always just commit,  
switch to another computer, pull, and reset HEAD^.

Thanks.
-- 
Jing Xue

Re: Howto request: going home in the middle of something?

[Jan Wielemaker]

On Tuesday 23 October 2007 19:56:55 Jing Xue wrote:
> Quoting Jan Wielemaker <wielemak@science.uva.nl>:
> > Thanks for the replies.	 I think I can live with something like this
> >
> > 	<work, in the middle of something>
> > 	$ git checkout -b home
> > 	$ git commit
> > 	$ git checkout master
> > 	<arriving at home>
> > 	$ git jan@work:repo fetch home:home	(using ssh)
> > 	$ git checkout home
> > 	<continue editing>
> > 	$ git commit --amend
> > 	$ git checkout master
> > 	$ git merge home
> > 	$ git -d home
> > 	$ git commit
> > 	$ git push
> > 	<arriving at work>
> > 	$ git -d home
> > 	$ git pull
> >
> > Its still a bit many commands and you have to be aware what you are
> > doing for quite a while, but it does provide one single clean commit
> > message, doesn't change the shared repo until all is finished and allows
> > to abandon all work without leaving traces.
>
> What does the extra branch gain for us here? That's not a rhetorical
> question, I'm actually curious to learn, because I always just commit,
> switch to another computer, pull, and reset HEAD^.

I'm just trying to learn. Sofar I like the idea to stash and use
git-fetch to get the stash from the other side. As stash is about
handling current work, it feels as the most appropriate solution
and is a lot shorter.

	Cheers --- Jan

Re: Howto request: going home in the middle of something?

[Matthias Kestenholz]

Hi,

On 23.10.2007, at 19:56, Jing Xue wrote:
> What does the extra branch gain for us here? That's not a  
> rhetorical question, I'm actually curious to learn, because I  
> always just commit, switch to another computer, pull, and reset HEAD^.

If someone tracks the main branch you are working on and fetches
while you are travelling home, he has the WIP commit as a new tip
in his tree.
If he bases further work upon the WIP commit, he'll need to rebase
or merge his changes onto your new tip once you have amended or
replaced the commit. If you are working on the
master branch, you should really avoid rewinding it. Rewinding topic
branches is ok, but a temporary branch is still better to clearly tell
potential fetch-ers that this is only Work in Progress, and not meant
to be published in the current state.

Matthias

-- 
http://spinlock.ch/blog/

Re: Howto request: going home in the middle of something?

[Jing Xue]

On Tue, Oct 23, 2007 at 10:28:46PM +0200, Matthias Kestenholz wrote:
> Hi,

Hi,

> If someone tracks the main branch you are working on and fetches
> while you are travelling home, he has the WIP commit as a new tip
> in his tree.
> If he bases further work upon the WIP commit, he'll need to rebase
> or merge his changes onto your new tip once you have amended or
> replaced the commit. If you are working on the
> master branch, you should really avoid rewinding it. Rewinding topic
> branches is ok, but a temporary branch is still better to clearly tell
> potential fetch-ers that this is only Work in Progress, and not meant
> to be published in the current state.

Good point. Although I guess if some workflow lets you directly hack on a
public branch, it can have lots of other issues beyond just the WIP
being pulled accidentally, no?

Cheers.
-- 
Jing Xue