Re: [git-users] git-new-workdir, and updating local workdir

[Phillip Lord]

Phillip Lord  writes:

> Konstantin Khomoutov  writes:
>
>> On Mon, 09 Nov 2015 17:59:13 +
>> phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:
>>
>> [...]
>>> I was trying something slightly evil
>>> though, which breaks this. I've been using unison to sync
>>> 
>>> ~/src/my-repo
>>> 
>>> between machines.
>> [...]
>>
>> But why?  If you have unison working between those machines, you most
>> probably have SSH working as well, so could just use Git for pushing
>> and fetching.


Just to let you know, I thought on what you have said, and am trying out
an entirely git based workflow which seems to be working now. So, many
thanks for the suggestion.

Phil

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-new-workdir, and updating local workdir

[Konstantin Khomoutov]

On Mon, 9 Nov 2015 22:11:04 +0100
Gergely Polonkai  wrote:

[...]
> > In case you "kind of heard" exchanging histories between non-bare
> > repos is a no-no, I can assure you that's nonsense -- while you
> > obey certain simple rules.  Actually, the single rule: don't try to
> > push to a branch which is checked out.  And this rule is simple to
> > follow: if you have repos A and B, and you want to push branch X
> > from A to B, and B has it checked out then instead fetch X from A
> > while working with B (that is, reverse the operation).  If it's
> > inconvenient, push X to a temporary branch while at A, and then
> > update X from that temp branch when back at B, and delete it.
> 
> Just to give a quick example on this. I'm sometimes lucky and have
> some time at work with my private(ish) projects (privateish, because
> my company also benefits from most of them). At such times I roughly
> do this:
> 
> $ git clone user@home-computer:projects/whatever
> $ cd whatever
> $ work work
> $ git commit -a
> $ git push origin master:work-master
> 
> This latter line creates a work-master branch on my home computer,
> which has master checked out. Then, at home, I roughly do:
> 
> $ git rebase work-master # to get my office changes; if there's only
> one commit, I can do cherry-pick, too
> 
> Now if I was quick and dirty, I do a git reset or an interactive
> rebase to clean up my commits and, if everything looks good, push the
> whole thing to Github or such.

99% the same of what I do in the similar situations.
The remaining 1% is that I'm not afraid to push to a branch with as
dumb a name as "temp" :-)

By the way for those with high aesthetic demands, it's perfectly OK
to use forward slashes in branch names. ;-)
So one could as well "namespace" their branches using '/', like in

git push origin master:work/master

It works no different from your example but the resulting branch name
looks subjectively nicer in the `git branch -a` output.
AFAIK, this approach is used by the Git maintainer: he prefixes the
branches it pulls from various people into his integration repo with
the initials of the full names of those people -- so that when he pulls
a branch "foo" from Joe Random Hacker, it lands in his repo being named
"jrh/foo".

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-new-workdir, and updating local workdir

[Konstantin Khomoutov]

On Mon, 9 Nov 2015 15:08:37 +0300
Konstantin Khomoutov  wrote:

[...]
> > In ~/src/my-repo-branch/master running git log will show the latest
> > commits to master, but the working directory will be out of date.
> > 
> > Is it possible to get this workdir up to date?
> 
> Yes, there are several.
> 
> The basic thing to understand is that `git-new-workdir` creates a
> separate HEAD ref in the new work tree's .git directory.
[...]

Forgot to add, that `git-new-workdir` also creates a separate index
file.  That's the crucial thing to consider.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-new-workdir, and updating local workdir

[Paul Smith]

On Mon, 2015-11-09 at 10:01 +, Phillip Lord wrote:
> Now I pull to "~/src/my-repo" so it updates
> say master (or feature-branch). In ~/src/my-repo-branch/master running
> git log will show the latest commits to master, but the working
> directory will be out of date.

Konstantin gives you excellent details.  However, I follow a simple rule
which lets me avoid these concerns: I never pull in the "real" repo (in
your example, I never pull in "~/src/my-repo").  In fact, I never use
that repo directly at all: I don't even cd to it.  You can/should just
pull in your workdirs.

As long as all your workdir copies of the "real" repo are using
different branches, and you don't mess around with the contents of the
"real" repo yourself, you won't have any issues with new-workdir.

Of course when you're delivering code (for example, into master) then
you need to check out master in one of your workdirs which breaks the
above rules.  I personally only ever use new-workdir for personal
branches, so I never make a new-workdir that is set to master.  I merge
back one of my personal branches in its workdir back to master, then I
*delete* that workdir (if I'm done) or set it back to the personal
branch or check out a new personal branch.  I never let a workdir sit
with "master" checked out.

If you do need to have "master" checked out in more than one workdir
then Konstantin's instructions on how to manage it are spot-on.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-new-workdir, and updating local workdir

[Phillip Lord]

Konstantin Khomoutov  writes:

> On Mon, 09 Nov 2015 17:59:13 +
> phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:
>
> [...]
>> I was trying something slightly evil
>> though, which breaks this. I've been using unison to sync
>> 
>> ~/src/my-repo
>> 
>> between machines.
> [...]
>
> But why?  If you have unison working between those machines, you most
> probably have SSH working as well, so could just use Git for pushing
> and fetching.  In most projects (even those like the Linux kernel) and
> on a fast filesystem (e.g., extN are OK) the time it takes to
> populate/update the work tree is negligible compared to the time it
> takes to transfer the history, so why not just stick to Git? ;-)

It's a good queston, indeed.

The main reason was that I was trying to maintain my existing workflow.
95% of my file synchronisation needs are fulfilled by unison. I unison
git repos around all the time. It all works nicely. And it means I can
change machines without more or less without thinking about it (I unison
before shutdown and after login on the new machine almost reflexively).

I've tried tools like dropbox, for example, for synchronisation or even
IMAP (offline), but then all I end up with is another system that I have
to remember to update before I change machines. So, adding another
technique for syncing isn't high up on my list. Besides which I've been
using unison for well over a decade. I know it and I trust it. Neither
of these things is true with git (not saying git is untrustworthy: more
I don't trust myself to use it properly). So fitting git into a unison
workflow makes more sense to me.

The only place it breaks is for one repo, which is fairly large, with a
lot of small files. The unison scan of the file system is pretty slow.
And git-new-workdir makes things harder still for unison (as my original
question showed), but does mean I can sanely switch between branches
(it's can take 5 minutes otherwise, because the repo is slow to rebuild).

Given that I am having to special case the repo anyway, you may be
correct that the balance is tipping the other way, toward a git solution.


> In case you "kind of heard" exchanging histories between non-bare repos
> is a no-no, I can assure you that's nonsense -- while you obey certain
> simple rules.  Actually, the single rule: don't try to push to a branch
> which is checked out.  And this rule is simple to follow: if you have
> repos A and B, and you want to push branch X from A to B, and B has it
> checked out then instead fetch X from A while working with B (that is,
> reverse the operation).  If it's inconvenient, push X to a temporary
> branch while at A, and then update X from that temp branch when back at
> B, and delete it.

Trying to remember all of that rather exceeds my idea of simple, I am
afraid. I mean, I understand the principle, but remembering what branch
is checked out on what machine is never going to happen.


> If you have a dedicated machine which is always available, you can just
> create a rendez-vouz bare repo there and exchange your histories
> through it -- just like you'd do with github or any other Git hosting.

In practice, this is the way that I would do it. I have an always on VM.
My physical machines are switched on at different times.

> If you still have some doubts / have things to clear up, just ask away.

I will do so.

I have tried the reset (--mixed) and that seemed to work well.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-new-workdir, and updating local workdir

[Phillip Lord]

Paul Smith  writes:

> On Mon, 2015-11-09 at 10:01 +, Phillip Lord wrote:
>> Now I pull to "~/src/my-repo" so it updates
>> say master (or feature-branch). In ~/src/my-repo-branch/master running
>> git log will show the latest commits to master, but the working
>> directory will be out of date.
>
> Konstantin gives you excellent details.  However, I follow a simple rule
> which lets me avoid these concerns: I never pull in the "real" repo (in
> your example, I never pull in "~/src/my-repo").  In fact, I never use
> that repo directly at all: I don't even cd to it.  You can/should just
> pull in your workdirs.


That sounds like a good plan. I was trying something slightly evil
though, which breaks this. I've been using unison to sync

~/src/my-repo

between machines. I've been trying to avoid syncing the workdirs because
scanning all the repo files takes long enough as it is. So long as I
commit everything, then it should work. Except that the workdir needs
updating.

I was worried my clever plan might not be working after all!


> As long as all your workdir copies of the "real" repo are using
> different branches, and you don't mess around with the contents of the
> "real" repo yourself, you won't have any issues with new-workdir.
>
> Of course when you're delivering code (for example, into master) then
> you need to check out master in one of your workdirs which breaks the
> above rules.  I personally only ever use new-workdir for personal
> branches, so I never make a new-workdir that is set to master.  I merge
> back one of my personal branches in its workdir back to master, then I
> *delete* that workdir (if I'm done) or set it back to the personal
> branch or check out a new personal branch.  I never let a workdir sit
> with "master" checked out.
>
> If you do need to have "master" checked out in more than one workdir
> then Konstantin's instructions on how to manage it are spot-on.


I will try them!

Phil

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] git-new-workdir, and updating local workdir

[Konstantin Khomoutov]

On Mon, 09 Nov 2015 17:59:13 +
phillip.l...@newcastle.ac.uk (Phillip Lord) wrote:

[...]
> I was trying something slightly evil
> though, which breaks this. I've been using unison to sync
> 
> ~/src/my-repo
> 
> between machines.
[...]

But why?  If you have unison working between those machines, you most
probably have SSH working as well, so could just use Git for pushing
and fetching.  In most projects (even those like the Linux kernel) and
on a fast filesystem (e.g., extN are OK) the time it takes to
populate/update the work tree is negligible compared to the time it
takes to transfer the history, so why not just stick to Git? ;-)

In case you "kind of heard" exchanging histories between non-bare repos
is a no-no, I can assure you that's nonsense -- while you obey certain
simple rules.  Actually, the single rule: don't try to push to a branch
which is checked out.  And this rule is simple to follow: if you have
repos A and B, and you want to push branch X from A to B, and B has it
checked out then instead fetch X from A while working with B (that is,
reverse the operation).  If it's inconvenient, push X to a temporary
branch while at A, and then update X from that temp branch when back at
B, and delete it.

If you have a dedicated machine which is always available, you can just
create a rendez-vouz bare repo there and exchange your histories
through it -- just like you'd do with github or any other Git hosting.

If you still have some doubts / have things to clear up, just ask away.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.