patchAdd function to checkout a branch in git.el

One can now:
- checkout an existing branch with M-x git-change-branch
- create and checkout a new branch with C-u M-x git-change-branch
- do all this from the Git menu
---
It could also be interesting to add some  key biding for those

Also one might want to update the *git-status* buffer after checkout,
but this is not done by this patch
 contrib/emacs/git.el |   45 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 45 insertions(+), 0 deletions(-)

On 2008-02-13 16:53:12 +0100, =?utf-8?q?R=C3=A9mi=20Vanicat?= wrote:

Why the prefix? Wouldn't it be easier to just have one "switch branch" prompt that would tab complete existing branch names, and

  * if the user enters the name of an existing branch, just switch to
    it;

  * if the user enters a name that's not the name of an existing
    branch, ask for confirmation, and then create the new branch and
    switch to it.

On 2008-02-13 17:30:02 +0100, Karl Hasselström wrote:

Reading your code a bit more carefully, I realize that my suggestion doesn't give you the opportunity to base the new branch on anything but HEAD. So change the second bullet to

  * if the user enters a name that's not the name of an existing
    branch, display a prompt like this

      Creating new branch "foo". Where should it start?

    Tab complete on existing tags and branches, but accept any
    committish. Create the new branch and switch to it.

This bit of UI could obviously be reused to make create-branch and create-tag commands that don't switch the current branch.

M-x git-change-branch checkout branch, and ask for confirmation if a new one is to be created One could also use a new submenu in the Git menu for this. --- Karl Hasselström <kha@treskal.com> writes:

I didn't think of the other way, that seem simpler. Here is a corrected patch

Mmm seem cool, but I have no time for now. Patch are welcome, otherwise I might look at it this weekend or next week.

Also one might want to do detached head checkout, it wont work for now, but should not be very hard to do.

Karl Hasselström <kha@treskal.com> writes:

It still doesn't allow to detach HEAD at arbitrary tag/committish, as far as I can see.

I believe the interface should be designed more carefully. Here are some thoughts/suggestions:

1. Let `git-checkout' switch HEAD. It will never create new branches but
   will be able to detach HEAD. Use tab-completion on branch names and
   maybe tags (maybe by inserting tags/ into completion list, and
   switching completion list to tags after tags/ is enterd by user), but
   allow any commitish. Ideally, it will also revert Emacs buffers for
   which working copy files are changed during checkout.

2. Let `git-create-branch' create new branches. It will prompt for a branch
   name, then prompt for starting point with default set to HEAD, and
   create the branch. As it doesn't switch HEAD, it won't touch working
   files.

3. Let `git-branch' create new branch at HEAD and switch to it. This
   will be just a short-cut for common and simple case. Note that this
   will never change working files as newly created branch will match
   HEAD.

4. Reserve C-u prefix for ability to provide arbitrary options to
   underlying GIT commands. For example, it's useful to be able to give
   -m or -f option to "git checkout"; or --track or -f to "git branch".

The "create new branch at arbitrary point and then switch to it" will then be a two-step operation: either "

((git-create-branch <name> <point>) (git-checkout <name>)

or

((git-checkout <point>) (git-branch <name>))

but that is IMHO reasonable trade-off for interface simplicity, though yet another function could be defined to do it in one step.

-- Sergei.

On 2008-02-13 21:23:52 +0300, Sergei Organov wrote:

It wouldn't be hard. Just try to interpret the string supplied by the user as a committish: if successful, check it out; if not, create a new branch by that name. Of course, this makes it impossible to create a branch with the same name as an existing committish, but that's probably OK.

Yes, having different commands that do one job each and do it well isn't a bad idea either. I like my idea more, but obviously whoever writes the code gets to decide ...

Karl Hasselström <kha@treskal.com> writes:

Too much AI for a function, at least to my taste.

I'd say it's probably even desirable. Whatever implementation, I'd at least check for such a collision and ask for confirmation, provided it's not very time-consuming.

Yes, sure. I just wanted to point to alternative approach. Or maybe I'll get the time to implement it myself, though I'm more interested in git-merge and git-[fetch|pull]-[merge|rebase] implementation, so that git.el support at least some of real workflows without resorting to plain GIT commands.

-- Sergei.

I've a new version, in the form of a patch series that follow: first I add some function for asking user commitish then some code for checkouting commitish and branching, mostly following the idea of Sergei, then some code for merging.

I've look to add rebase, but when thinking about how to do about conflict and continued rebasing, I feel lazy, and didn't try. As someone a good idea for the interface?

---
 contrib/emacs/git.el |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

Rémi Vanicat <vanicat@debian.org> writes:

git-run-command-buffer isn't really what you want to use here, look at how other functions that use a temp-buffer do it. Also that alist thing is ugly, there are better ways of finding the current branch if we need it. Besides, you probably want to use git-for-each-ref instead of git-branch, git-branch is a bit too porcelainish IMO.

M-x git-checkout ask for a commitish, and checkout it as in
  git checkout commitish --
  key binding: "C"
M-x git-branch ask for the name of a new branch, create it and
checkout it as in
  git checkout -b name
  key binding: "b"
M-x git-create-branch ask for a new branchname, a startpoint (a
commitish) and create a new branch as in
  git branch branchname startpoint
  key binding "B"
A menu is also available for just switching branch
---
The main problem that I still see, is the error message when one try
to checkout a branch/tag... that doesn't exist: it is a cryptic error
message... 

 contrib/emacs/git.el |   42 ++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 42 insertions(+), 0 deletions(-)

Rémi Vanicat <vanicat@debian.org> writes:

My idea was to put commands that act on commits instead of files on the C-c prefix, for instance amend-commit is on C-c C-a, I have a preliminary cherry-pick implementation that I put on C-C C-p, then we could have git-checkout on C-c C-o, git-branch on C-c C-b, git-merge on C-c C-m. Otherwise we'll soon run out of single letter bindings.

Also for more complex operations like git-create-branch we may want another prefix, as there would probably be more branch manipulations commands. For instance something like "B C" for create-branch, "B D" for delete-branch, "B M" for move-branch etc.

M-x git-merge will ask for an commitish, and merge with it. A new submenu is also available for merging with local and remote branch. --- The problem here, which is similar to the one that exist now when one merge from outside Emacs, is that in case of conflict, Emacs doesn't look to the index, and so, when one commit the resolved conflict, one might forget to select all file that should be selected for the commit to be what is needed.

This problem could be even worse with rebasing, as rebasing is a more destructive action than merging.

 contrib/emacs/git.el |   22 +++++++++++++++++++++-
 1 files changed, 21 insertions(+), 1 deletions(-)

<vanicat@debian.org> writes:

s/git-change-branch/git-checkout/? I mean is there any reason it is called differently from GIT's "git checkout"?

Besides, I also think that prefix is not a good idea for this kind of stuff (see my other reply in this thread).

Why? Isn't it as simple as calling (git-refresh-status) at the end of git-change-branch?

s/branch/branches/

s/branchs/branches/

-- Sergei.