Re: [git-users] git-new-workdir, and updating local workdir
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
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
On 9 Nov 2015 19:22, "Konstantin Khomoutov" wrote: > > 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. 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. Best, Gergely > > 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. -- 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 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
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.
Re: [git-users] git-new-workdir, and updating local workdir
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
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
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
On Mon, 09 Nov 2015 10:01:56 + phillip.l...@newcastle.ac.uk (Phillip Lord) wrote: > I've been using git-new-workdir and am finding it very useful, but am > finding one problem. How do I update a working directory created with > git-new-workdir if the branch it is one is changed in the main > directory. > > For example, say I have: > > ~/src/my-repo > > ~/src/my-repo-branch/master > ~/src/my-repo-branch/feature-branch > > where "master" and "feature-branch" are git-new-workdir'd branches > pointing to ~/src/my-repo. 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. > > 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. Now recall how the whole thing works. If the HEAD in the original work tree is not detached (true in most cases) then it's a symbolic ref meaning it does point to a named branch rather than directly to a commit (using its SHA-1 name). Say, if you have the branch "master" checked out, HEAD contains the name of that branch. So, what then happens when you commit in your original work tree or perform `git pull` which updates the same branch? Among other things, the contents of the index and the work tree itself are updated. That is, the branch pointer points to that new commit, the index contains its contents and the work tree mirrors that. The difference with your other work tree having that branch checked out is that while the HEAD still points to the same branch, the branch pointer points to the new commit but the index and the work tree contain the stale data. So, the first thing to consider is doing `git reset --mixed` or `git reset --hard` BUT MAKE SURE first that you understand the implications of "--hard". The second thing to consider is the sequence of `git read-tree HEAD` and `git checkout-index`. Consider reading [1] to get full understanding of how the data pointed to by HEAD, contained in the index and in the work tree relate to each other. 1. https://git-scm.com/blog/2011/07/11/reset.html -- 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.
[git-users] git-new-workdir, and updating local workdir
I've been using git-new-workdir and am finding it very useful, but am finding one problem. How do I update a working directory created with git-new-workdir if the branch it is one is changed in the main directory. For example, say I have: ~/src/my-repo ~/src/my-repo-branch/master ~/src/my-repo-branch/feature-branch where "master" and "feature-branch" are git-new-workdir'd branches pointing to ~/src/my-repo. 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. Is it possible to get this workdir up to date? 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.