Konstantin Khomoutov <flatw...@users.sourceforge.net> writes:

> On Mon, 09 Nov 2015 17:59:13 +0000
> 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.

Reply via email to