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.


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 
For more options, visit this group at 

Reply via email to