On Tue, 2014-09-16 at 10:59 +0200, Frank Millman wrote: > "Chris Angelico" <ros...@gmail.com> wrote in message > news:CAPTjJmr5gh8=1zPjG_KdTmA2QgT_5jj=kh=jyvrfv1atl1e...@mail.gmail.com... > > On Tue, Sep 16, 2014 at 6:21 PM, Marko Rauhamaa <ma...@pacujo.net> wrote: > >> "Frank Millman" <fr...@chagford.com>: > >> > >>> You are encouraged to make liberal use of 'branches', > >> > >> Personally, I only use forks, IOW, "git clone". I encourage that > >> practice. Then, there is little need for "git checkout". Instead, I just > >> cd to a different directory. > >> > >> Branches and clones are highly analogous processwise; I would go so far > >> as to say that they are redundant. > > > > But rather than listening to, shall we say, *strange* advice like > > this, Frank, you'll do well to pick up a reliable git tutorial, which > > should explain branches, commits, the working tree, etc, etc, etc. > > > > I don't want to turn this into a full-on Git discussion, so briefly - > > 1. I have read all the 'git' tutorials I can find, but they have not > addressed my question. > 2. Albert's response 'commit or stash files before switching branches' makes > sense, and actually answers my question. > 3. I have sympathy for Marko's position of using clones rather than > branches. I realise it does not follow the 'git' philosophy, but it does > make it more obvious 'where you are', and lessens the chances of shooting > yourself in the foot.
I'm with Chris on this one. I use git extensively (I manage more than just software with it -- I used it as version tracking when I was working on my dissertation, articles I'm writing, script databases, project management, etc.) One of the code git repos I work with every day is ~4 GB for a working repo and ~1.6 GB for a bare one. At any given time, I have ~6 branches I'm working on. To have a separate repo for each branch is madness (especially on a SSD where storage is expensive). A trick I use to avoid ever getting lost inside my git repository is to set up my command-line prompt so it always displays the active branch [1]: swails@batman ~/amber (master) $ git branch amber12-with-patches amber13-with-patches amber14-with-patches amoeba2 amoeba2_diis * master sander-python yorkmaster swails@batman ~/amber (master) $ git checkout sander-python Switched to branch 'sander-python' Your branch is up-to-date with 'origin/sander-python'. swails@batman ~/amber (sander-python) $ Doing everything as branches in the same repository has a number of other advantages as well. Merges don't have to be preceded by a fetch (e.g., a git-pull). You can cherry-pick individual commits between branches. You only have one copy of the git objects. You can use "git diff" or "git difftool" to directly compare specific files or folders between branches or different revisions in diverged history between branches. I wouldn't expect you to know all of this git-magic from the outset, but you will learn it as you need to. Assigning each branch to a new clone severely limits git's capabilities. [2] All the best, Jason [1] See http://jswails.wikidot.com/using-git#toc48 for details of how to do this [2] Technically this isn't true since each repository will know about the branches of the other repositories it pulls from, but cherry-picking, merging, diffing, etc. between a branch and a remote copy of a branch on the same machine is a lot more convoluted than working with everything in the same repo (that and you never accidentally look at an outdated version of a 'local' branch because you forgot to fetch or pull!) -- https://mail.python.org/mailman/listinfo/python-list
