# Is the entire working copy “at one branch”? 3 messages from 2016-10-28 to 2016-10-31. Participants: Stefan Monov, Alexei Lozovsky. Thread: https://gitlist.dev/t/44391 ## Stefan Monov, 2016-10-28 15:01 Subject: Is the entire working copy “at one branch”? Message-ID: URL: https://gitlist.dev/e/CAJtFkWs4qYCqnbJD%2BzCRCAW3teczb4CdvncvYoMN_VvthJGr%3Dw%40mail.gmail.com ``` This is a very basic question but maybe I just don't know how to phrase my query well enough to find an answer. Let me begin with a SVN example. SVN doesn't have a "current branch" as a property of a working copy, so I'll give the example with revisions instead. Consider a working copy with the dirs `foo` and `bar` in it. In SVN one can `update` foo to an earlier version, but keep `bar` at `HEAD`. Is it possible in an analogical git working copy to checkout one branch in dir `foo` without changing the branch checked out in `bar`? If not, why not? TIA, Stefan Monov ``` ## Alexei Lozovsky, 2016-10-29 09:47 Subject: Re: Is the entire working copy “at one branch”? Message-ID: URL: https://gitlist.dev/e/CALhvvbYE6Tt3eByDVMB3a4t%3Dnm3dScVZSea0Z1SsKVgwFSiQ-w%40mail.gmail.com In-Reply-To: ``` Hi Stefan, Generally with git, your entire working copy will have the same revision (set to current branch, aka HEAD). The idea behind this is that your working copy of a repository should always be in consistent state. You can check out specific files or directories from another revision (mimicking "svn update -r1234 filename"): $ git checkout branch-or-sha-hash -- filename However, SVN tracks the 'revision' thing on per-file basis, while in git this is a property of the working copy. So if you do like above then git will be telling you that the 'filename' has been changed (as it is certainly different from its pristine version in HEAD): $ git status On branch master Changes to be committed: (use "git reset HEAD ..." to unstage) modified: filename So it's generally not recommended to do such a thing. Another thing that you _can do_ in git to mimick SVN is the 'standard layout'. There is a feature called "git worktree" which allows you to have SVN-like directory structure with multiple directories linked to different working copies: $ mkdir my-project $ cd my-project $ git clone my-project-repository master $ mkdir branches $ cd master $ git worktree add -b branch-1 ../branches/branch-1 $ git worktree add -b branch-2 ../branches/branch-2 After that you will have directory structure like this: $ tree my-project my-project ├── branches │ ├── branch-1 │ │ ├── 1 │ │ ├── 2 │ │ └── 3 │ └── branch-2 │ ├── 1 │ ├── 2 │ └── banana └── master ├── 1 └── 2 You can work with these working copies separately, like you would be working with SVN. Commits in 'master' will go to the 'master' branch, commits made in 'branches/branch-1' will go to the 'branch-1' branch. ``` ## Stefan Monov, 2016-10-31 10:41 Subject: Re: Is the entire working copy “at one branch”? Message-ID: URL: https://gitlist.dev/e/CAJtFkWtsG9zRuL%2BBSTG-Wgjo%2BDZJpxobCXK94y-grgN7UTzULA%40mail.gmail.com In-Reply-To: ``` Thanks Alexei! On Sat, Oct 29, 2016 at 12:47 PM, Alexei Lozovsky wrote: > Hi Stefan, > > Generally with git, your entire working copy will have the same > revision (set to current branch, aka HEAD). The idea behind this > is that your working copy of a repository should always be in > consistent state. > > You can check out specific files or directories from another > revision (mimicking "svn update -r1234 filename"): > > $ git checkout branch-or-sha-hash -- filename > > However, SVN tracks the 'revision' thing on per-file basis, while > in git this is a property of the working copy. So if you do like > above then git will be telling you that the 'filename' has been > changed (as it is certainly different from its pristine version > in HEAD): > > $ git status > On branch master > Changes to be committed: > (use "git reset HEAD ..." to unstage) > > modified: filename > > So it's generally not recommended to do such a thing. > > Another thing that you _can do_ in git to mimick SVN is the > 'standard layout'. There is a feature called "git worktree" which > allows you to have SVN-like directory structure with multiple > directories linked to different working copies: > > $ mkdir my-project > $ cd my-project > $ git clone my-project-repository master > $ mkdir branches > $ cd master > $ git worktree add -b branch-1 ../branches/branch-1 > $ git worktree add -b branch-2 ../branches/branch-2 > > After that you will have directory structure like this: > > $ tree my-project > my-project > ├── branches > │ ├── branch-1 > │ │ ├── 1 > │ │ ├── 2 > │ │ └── 3 > │ └── branch-2 > │ ├── 1 > │ ├── 2 > │ └── banana > └── master > ├── 1 > └── 2 > You can work with these working copies separately, like you > would be working with SVN. Commits in 'master' will go to the > 'master' branch, commits made in 'branches/branch-1' will go > to the 'branch-1' branch. ```