Matthieu Moy <[EMAIL PROTECTED]> writes: > Richard Riley <[EMAIL PROTECTED]> writes: > >>>> The comment in dvc-unified.el for dvc-select-branch is not clear. What >>>> does "select" mean, in terms of what happens to the current workspace? >>> [...] >>> Does only metadata change? is the new branch checked out? What files >>> are affected? >> >> Why not try it? Use the git command line or stefan's new functions. > > Git's command line doesn't have a "select" command, and there are > different commands to implement different ways to "select" a branch.
It's checkout. > > The one you probably want is "git checkout branch", which changes both > the metadata (i.e. HEAD now points to "branch") and the working tree > files. Yes. > > But one can also change only the meta-data like in "git reset --soft > some-branch" (that lets HEAD and the current branch point to > "some-branch"), or detach HEAD and let it point to something else, ... > > I believe Stephen's question whas which of these behaviors should > dvc-select-branch chose. To me, it should be the one of "git checkout" > (which other SCMs often call "switch"). Yes. The obvious one (in my opinion that is and it of course subjective). And the same one which other interfaces such as git-gui, magit, emacs-git etc use. > >> All files change that are different in the new branch as far as I can >> see. Which makes sense.It's a branch. It would be pretty useless if you >> changed branch and did not get that new branches files. > > It's not the common case, but it can actually be usefull as a > low-level command for history-editting. I would suggest getting the common core done (branch create, list and select/checkout) and worrying about hard code git specifics later or from the command line. Otherwise the waters get muddied. Most programmers can make do with the basic subset which were missing before but have since been integrated by Stefan. Certainly having no branch was a major omission now improved upon. > > Simple and slightly off-topic, since it's not about switching branch, > but "let the HEAD point to another commit": > > Suppose you've just commited something, and realize you wanted to > split this commit in two distinct ones. In git, you could : > > git reset HEAD^ # let HEAD point to the last but one revision > git add -p # select the changes you want in the first commit > git commit -m "first part" > git add -p > git commit -m "second part" > > (that's more or less the same as "bzr uncommit", and more general than > "hg rollback"). > > Another example: you have a branch called "topic" for which you like > the result, but not the patch serie. You can create another branch > "topic-cleanup", start a few cleaner commits there to "explain" what > you're doing in the branch, and then let the HEAD point to > "topic-cleanup", and the files checked-out be the ones of "topic", and > then commit. The result is that topic-cleanup has the same result as > the initial one, but a different path. > > (This is off course the kind of thing you want to do privately, to > avoid showing your dirty code to the public) > >> Its also why you can not switch to another branch with uncommited >> changes I think. > > The main reason not to do this is that this would require merging, and > distributed DVCS prefer commiting before merging, so that getting back > to a sane situation be easy in case the merge gets you in troubles. -- important and urgent problems of the technology of today are no longer the satisfactions of the primary needs or of archetypal wishes, but the reparation of the evils and damages by the technology of yesterday. ~Dennis Gabor, Innovations: Scientific, Technological and Social, 1970 _______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
