On Mar 4, 7:36 am, vfclists <vfcli...@googlemail.com> wrote: > If still want to work in that way, would this method suffice? > > 1. Copy the files for that branch into a separate folder. > > 2. Do all the editing, testing and compiling in that folder > > 3. After finishing go back to the main repository directory and make > sure the currently checkout branch is the branch I am working on. > > 4. Copy the files I have edited back into the main repo directory, > stage them and commit them. > > Would this be equivalent?
You could do that, but it seems error prone. If you deleted a file while working in your "separate folder", you would have to remember to delete it again once you copied everything back (unless you just delete everything before copying back and rely on "git add --all" to notice the deletions). You can do what it seems like you were originally thinking (one working directory per branch) by using the git-new-workdir 'contrib' script that comes with Git's source. It allows you to have multiple working trees that all use a single repository for storage. The caveat is that things can get confusing if you ever have the same branch checked out in more than one working dir and update the branch (the effect is similar to pushing to a non-bare repository, if you have read about that). Read on though... > On consideration I it looks like treating the main directory as a > remote, creating branches within it, fetching them and editing them > locally would amount to the same. > > Does git allow treating a directory else where on the file system, > such as a network file share as a remote as well? Yes, Git can use fetch from and push to 'remotes' that are actually accessed completely through the filesystem (the repository 'URL' is just the pathname of the other repository). This approach (one repository per branch, and one combined, 'bare' repository) will use more disk space than a single repository plus multiple working trees, but it also prevents the potential problem of one instance changing HEAD 'out from under' another instance (as long as all yours pushes are to the bare repository). Although there is a bit more setup involved (remotes, pushing, fetching, pulling), this is probably the best way to go until you are comfortable with the implications of git-new-workdir. -- Chris -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
