DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
Hi,
Peter and I just stumbled on the following interpretations of the checkout command.
git checkout origin/frotz -> detaches HEAD git checkout -t origin/frotz -> git checkout -b frotz origin/frotz git checkout frotz -> git checkout -b frotz origin/frotz git checkout -t frotz -> fatal: Missing branch name
I was surprised by the third one, which I was expecting to fail. Apparently it's a DWIM feature introduced in commit 70c9ac2f. I doubt that is what the user was trying to do if they ran that command. If anything, this behavior will serve to confuse them.
I think git checkout -t <remote>/<branch> is short enough for creating a new tracking branch. For something even shorter, we can create an alias. But I'd prefer to keep the already complex checkout command a little simpler.
Regards,
Clemens
Heya,
Quoted 4 lines · Clemens Buchacher
I think git checkout -t <remote>/<branch> is short enough for creating a new tracking branch. For something even shorter, we can create an alias. But I'd prefer to keep the already complex checkout command a little simpler.
You're a little late to the party ;). Did you read the original thread discussing this?
Signature · 3 lines
Cheers, Sverre Rabbelier
Quoted 9 lines · Sverre Rabbelier
Quoted 4 lines · Clemens Buchacher
I think git checkout -t <remote>/<branch> is short enough for creating a new tracking branch. For something even shorter, we can create an alias. But I'd prefer to keep the already complex checkout command a little simpler.
You're a little late to the party ;). Did you read the original thread discussing this?
Well, I just noticed this by accident, it is not documented anywhere, and you cannot expected me to know everything that is going on on the list. Should I not offer my opinion because of that?
I could not make much sense of the thread that came with the patch. The discussion first seems to conclude that it is a bad idea, only to implement it anyway.
Well, I also think it is a bad idea, and I am not surprised to find users confused by it.
Heya,
Quoted 4 lines · Clemens Buchacher
Well, I just noticed this by accident, it is not documented anywhere, and you cannot expected me to know everything that is going on on the list. Should I not offer my opinion because of that?
No, I just meant that because you are late to the party you should first read the original thread, and then perhaps summarize it, like you have done below.
Quoted 3 lines
I could not make much sense of the thread that came with the patch. The discussion first seems to conclude that it is a bad idea, only to implement it anyway.
I think it would be useful here to have some links to relevant posts, or at least to the relevant thread.
Quoted 2 lines
Well, I also think it is a bad idea, and I am not surprised to find users confused by it.
I think it was an idea from the last mentor summit, Peff?
Signature · 3 lines
Cheers, Sverre Rabbelier
Quoted 8 lines · Sverre Rabbelier
Quoted 3 lines · Clemens Buchacher
I could not make much sense of the thread that came with the patch. The discussion first seems to conclude that it is a bad idea, only to implement it anyway.
I think it would be useful here to have some links to relevant posts, or at least to the relevant thread.
The discussion ends with this posting
http://mid.gmane.org/[email protected] , which basically says "we all agree this is bad."
Then Junio changes his mind his mind and posts the patches.
http://mid.gmane.org/[email protected]
Whether the feature has merit or not is suddenly not an issue any more and the discussion veers off in other directions about minor technical details and about the --nodwim/--noguess option, the notion of which I find ridiculous by the way. But it further illustrates how random and anti-DWIM this feature really is.
Quoted 14 lines · Clemens Buchacher
Quoted 8 lines · Sverre Rabbelier
Quoted 3 lines · Clemens Buchacher
I could not make much sense of the thread that came with the patch. The discussion first seems to conclude that it is a bad idea, only to implement it anyway.
I think it would be useful here to have some links to relevant posts, or at least to the relevant thread.
The discussion ends with this posting
http://mid.gmane.org/[email protected] , which basically says "we all agree this is bad."
Quoted 8 lines
Then Junio changes his mind his mind and posts the patches.
http://mid.gmane.org/[email protected]Whether the feature has merit or not is suddenly not an issue any more and the discussion veers off in other directions about minor technical details and about the --nodwim/--noguess option, the notion of which I find ridiculous by the way. But it further illustrates how random and anti-DWIM this feature really is.
Amen.
Nicolas
Quoted 9 lines · Sverre Rabbelier
Quoted 4 lines · Clemens Buchacher
Well, I just noticed this by accident, it is not documented anywhere, and you cannot expected me to know everything that is going on on the list. Should I not offer my opinion because of that?
No, I just meant that because you are late to the party you should first read the original thread, and then perhaps summarize it, like you have done below.
Moreover, the burden for arguing against it is a little higher. It is no longer "I think this is a bad idea" but "I think this is a bad idea, and it is so bad that it is worth changing behavior that users may have become accustomed to".
Quoted 4 lines
Quoted 2 lines
Well, I also think it is a bad idea, and I am not surprised to find users confused by it.
I think it was an idea from the last mentor summit, Peff?
No, I complained about it at the mentor summit, but the idea predates it. I think all of the relevant discussion is on the list.
-Peff
Quoted 4 lines · Jeff King
Moreover, the burden for arguing against it is a little higher. It is no longer "I think this is a bad idea" but "I think this is a bad idea, and it is so bad that it is worth changing behavior that users may have become accustomed to".
I argue that people are more likely to be surprised and confused by this feature rather than being accustomed to it already. I am also waiting to hear from someone who actively uses this feature.
Quoted 9 lines · Clemens Buchacher
Quoted 4 lines · Jeff King
Moreover, the burden for arguing against it is a little higher. It is no longer "I think this is a bad idea" but "I think this is a bad idea, and it is so bad that it is worth changing behavior that users may have become accustomed to".
I argue that people are more likely to be surprised and confused by this feature rather than being accustomed to it already. I am also waiting to hear from someone who actively uses this feature.
I use this feature all the time, and find it very nice and useful.
Moreover, at $DAYJOB, we have a lot of Git newbies (many of them still can't properly juggle remote branches. remote-tracking branches, and local branches with tracking info). They mostly work on local topic branches that tracks corresponding shared topic branches in a central repo. For them, switching to one of these topic branches is simply a matter of 'git checkout <branchname>', without having to care (or know) if you've already created the local branch or not. In this case, Git really does the Right Thing (tm) for us.
In several cases this DWIMmery has prompted people to update from an old Git version, just to get this feature.
...Johan
Signature · 2 lines
Johan Herland, <[email protected]> www.herland.net
Quoted 11 lines · Clemens Buchacher
Quoted 4 lines · Jeff King
Moreover, the burden for arguing against it is a little higher. It is no longer "I think this is a bad idea" but "I think this is a bad idea, and it is so bad that it is worth changing behavior that users may have become accustomed to".
I argue that people are more likely to be surprised and confused by this feature rather than being accustomed to it already. I am also waiting to hear from someone who actively uses this feature.
I am someone that "actively" uses this feature. I will often have repositories that I use on multiple machines, and will forget which remote branches I have local tracking branches for, on which machines.
I'll end up just doing git checkout $random-branch, thinking I'm on
one of the machines where I've already setup the local branch, and find it quite handy that Git _does_ DWIM.
Quoted 7 lines · Jacob Helwig
Quoted 5 lines · Clemens Buchacher
I argue that people are more likely to be surprised and confused by this feature rather than being accustomed to it already. I am also waiting to hear from someone who actively uses this feature.
Quoted 6 lines
I am someone that "actively" uses this feature. I will often have repositories that I use on multiple machines, and will forget which remote branches I have local tracking branches for, on which machines.
I'll end up just doinggit checkout $random-branch, thinking I'm on
one of the machines where I've already setup the local branch, and find it quite handy that Git _does_ DWIM.
I see. But would it be so terrible to have to type "git checkout -t origin/branch" instead?
Also, isn't this more like "foretell what I really want" rather than "do what it means"? Who would guess that "git checkout $branch" means "create $branch tracking <random-remote>/$branch"?
And this is exactly _why_ it can be marginally useful if the foretelling is correct, but all the more confusing if it's not.
Quoted 15 lines · Clemens Buchacher
Quoted 7 lines · Jacob Helwig
Quoted 5 lines · Clemens Buchacher
I argue that people are more likely to be surprised and confused by this feature rather than being accustomed to it already. I am also waiting to hear from someone who actively uses this feature.
Quoted 6 lines
I am someone that "actively" uses this feature. I will often have repositories that I use on multiple machines, and will forget which remote branches I have local tracking branches for, on which machines. I'll end up just doing
git checkout $random-branch, thinking I'm on one of the machines where I've already setup the local branch, and find it quite handy that Git _does_ DWIM.
Quoted 3 lines
I see. But would it be so terrible to have to type "git checkout -t origin/branch" instead?
Given that git checkout branch already exists & works: Yes.
You're talking about removing a feature, so (as already pointed out) there's a fairly high burden of proof to show that it's actually a mis-feature, that is so dangerous/confusing that it _needs_ to be removed.
Quoted 4 lines
Also, isn't this more like "foretell what I really want" rather than "do what it means"? Who would guess that "git checkout $branch" means "create $branch tracking <random-remote>/$branch"?
This is very much "fortell what I really want", which is exactly what DWIM (Do What I Mean) means (as Sverre already pointed out). I'm not guessing that git checkout $branch means git branch -t $branch origin/$branch && git checkout $branch; I'm assuming that git branch -t $branch origin/$branch was already done at some point in the past, and Git is adding that bit in for me, which is what _I_ really meant to do.
Quoted 3 lines
And this is exactly _why_ it can be marginally useful if the foretelling is correct, but all the more confusing if it's not.
Other than "unexpected success", how is the DWIM behavior confusing, given that it says exactly what it's doing when the DWIM behavior is invoked? I'm still not clear what the confusion you're referring to is on this one.
Quoted 9 lines · Jacob Helwig
Quoted 4 lines
And this is exactly _why_ it can be marginally useful if the foretelling is correct, but all the more confusing if it's not.
Other than "unexpected success", how is the DWIM behavior confusing, given that it says exactly what it's doing when the DWIM behavior is invoked? I'm still not clear what the confusion you're referring to is on this one.
I am telling git to checkout a branch. Instead it creates a branch. That is what is confusing to me. Until I found the commit that introduced it, I was sure it must be a bug.
Quoted 8 lines · Clemens Buchacher
Quoted 4 lines
Other than "unexpected success", how is the DWIM behavior confusing, given that it says exactly what it's doing when the DWIM behavior is invoked? I'm still not clear what the confusion you're referring to is on this one.
I am telling git to checkout a branch. Instead it creates a branch. That is what is confusing to me. Until I found the commit that introduced it, I was sure it must be a bug.
I usually see the opposite kind of confusion on #git: someone cloned a repository and wants to work on one of the branches. After all, we tell everyone that clone copies all the history.
So they type "git checkout <that branch>"... and they get a weird error (what's a pathspec, anyway?). OMGWTFBBQ! Not knowing what's going on, they drop by in #git and hear they need to type something much less straightforward than "git checkout <that branch>". They don't really know why, so they probably assume it's because git is just so damn complicated and overengineered.
I have yet to see any newish users complain about the new syntax, by the way. You don't qualify, sorry. ;)
Quoted 6 lines · Jan Krüger
Quoted 3 lines · Clemens Buchacher
I am telling git to checkout a branch. Instead it creates a branch. That is what is confusing to me. Until I found the commit that introduced it, I was sure it must be a bug.
Quoted 6 lines
I usually see the opposite kind of confusion on #git: someone cloned a repository and wants to work on one of the branches. After all, we tell everyone that clone copies all the history.
So they type "git checkout <that branch>"... and they get a weird error (what's a pathspec, anyway?).
I agree, that's a less than perfect error message. So let's improve it. What about "unknown branch or file name"? Possibly also output the most common synopsis?
Quoted 5 lines
OMGWTFBBQ! Not knowing what's going
on, they drop by in #git and hear they need to type something much less straightforward than "git checkout <that branch>". They don't really know why, so they probably assume it's because git is just so damn complicated and overengineered.
Well, but that's how it is. If we want more "global" branches, then we will have to think about how to achieve that. But hiding what we really have is not going to make it easier to understand.
Quoted 2 lines
I have yet to see any newish users complain about the new syntax, by the way. You don't qualify, sorry. ;)
I started this entire thread only because someone on #git was confused by it.
Heya,
Quoted 3 lines · Clemens Buchacher
Also, isn't this more like "foretell what I really want" rather than "do what it means"? Who would guess that "git checkout $branch" means "create $branch tracking <random-remote>/$branch"?
Note that DWIM stands for "Do What I Mean", not "Do What It Means".
Signature · 3 lines
Cheers, Sverre Rabbelier
Quoted 10 lines · Clemens Buchacher
Hi,
Peter and I just stumbled on the following interpretations of the checkout command.
git checkout origin/frotz -> detaches HEAD git checkout -t origin/frotz -> git checkout -b frotz origin/frotz git checkout frotz -> git checkout -b frotz origin/frotz git checkout -t frotz -> fatal: Missing branch name
Quoted 4 lines
I was surprised by the third one, which I was expecting to fail. Apparently it's a DWIM feature introduced in commit
70c9ac2f. I doubt that is what the user was trying to do if they ran that command. If anything, this behavior will serve to confuse them.
As already mentionned, it's obviously a bit late to revert the commit which itroduced this DWIM. I tend to agree that this is confusing, but still, this is very often what the user actually wanted. The original patch was to sugest the user the appropriate command, and I find the motivating example rather convincing:
http://thread.gmane.org/gmane.comp.version-control.git/129587
$ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git $ git checkout next error: pathspec 'next' did not match any file(s) known to git. To create a local branch from the same named remote branch, use git checkout -b next origin/next
The newbie does not immediately understand the difference between local and remote branches, he's been told about the branch "next", and wants to check it out.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 10 lines · Matthieu Moy
$ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git $ git checkout next error: pathspec 'next' did not match any file(s) known to git. To create a local branch from the same named remote branch, use git checkout -b next origin/nextThe newbie does not immediately understand the difference between local and remote branches, he's been told about the branch "next", and wants to check it out.
That is exactly my point. Trying to read the user's mind is not a solution to this problem. The user does not even know what they are doing and will inevitably end up even more confused.
The suggestion above would be perfect. It is an easy and obvious solution, and the user is even educated about their mistake.
Quoted 3 lines · Clemens Buchacher
That is exactly my point. Trying to read the user's mind is not a solution to this problem. The user does not even know what they are doing and will inevitably end up even more confused.
Maybe you just want branch.autosetupmerge = false?
Paolo
Quoted 2 lines · Clemens Buchacher
The suggestion above would be perfect. It is an easy and obvious solution, and the user is even educated about their mistake.
Of course, having been educated as to what's going on, the user would then be annoyed that they had to type all those boilerplate args when git clearly knew what they wanted to do... and that would be the case every time from then on...
I think this DWIM is actually pretty convenient, and very often does reflect what the user intuitively is trying to do when giving such args.
Given that git _does_ tell you what it's doing, and that it's easy enough to delete the new branch if it wasn't really wanted, it seems pretty harmless as well. A campaign to delete this feature seems kind of silly...
-Miles
Signature · 2 lines
I'm beginning to think that life is just one long Yoko Ono album; no rhyme or reason, just a lot of incoherent shrieks and then it's over. --Ian Wolff
Quoted 8 lines · Miles Bader
Quoted 2 lines · Clemens Buchacher
The suggestion above would be perfect. It is an easy and obvious solution, and the user is even educated about their mistake.
Of course, having been educated as to what's going on, the user would then be annoyed that they had to type all those boilerplate args when git clearly knew what they wanted to do... and that would be the case every time from then on...
Why should the user make the same mistake over and over again?
Quoted 7 lines
I think this DWIM is actually pretty convenient, and very often does reflect what the user intuitively is trying to do when giving such args.
Given that git _does_ tell you what it's doing, and that it's easy enough to delete the new branch if it wasn't really wanted, it seems pretty harmless as well. A campaign to delete this feature seems kind of silly...
It may be harmless to users who know what's going on. I can certainly deal with this feature, whether it's there or not.
But this is supposedly a feature which helps users who type "git checkout <branch>" by mistake, when they really wanted to do "git checkout -t <remote>/<branch>". I am certain that most new users who make this mistake will not understand what's going on, even if they read the output.
I believe that it's because of things like this that many users still consider git to be complicated and hard to use. That's what really bothers me.
And it makes me sad that you think it silly to even talk about it. Even if the feature does not end up getting removed I still hope that we will exercise more caution in the future and try to solve the real problem--which appears to be remote branch handling--rather than introducing more strange behavior.
Regards,
Clemens
Quoted 5 lines · Clemens Buchacher
Quoted 3 lines
then be annoyed that they had to type all those boilerplate args when git clearly knew what they wanted to do... and that would be the case every time from then on...
Why should the user make the same mistake over and over again?
What I mean is that every time thereafter that they want that functionality (making a remote branch local), they'll have to type the "long form".
Quoted 1 line
And it makes me sad that you think it silly to even talk about it.
I don't think it's silly to note your concern, I think it's silly to put a fair amount of effort into a campaign for its removal, which is what you are doing. If new points can be made, fair enough, but so far it seems mainly a lot of back and forth stating the same things over and over.
Quoted 3 lines
I believe that it's because of things like this that many users still consider git to be complicated and hard to use. That's what really bothers me.
Why do you think that? I mean, you could be right, but it's certainly conceivable that this feature causes users to consider git _simpler_ to use, because it lets them think about local branches only.
-Miles
Signature · 1 line
Do not taunt Happy Fun Ball.
Quoted 8 lines · Miles Bader
Quoted 2 lines
And it makes me sad that you think it silly to even talk about it.
I don't think it's silly to note your concern, I think it's silly to put a fair amount of effort into a campaign for its removal, which is what you are doing. If new points can be made, fair enough, but so far it seems mainly a lot of back and forth stating the same things over and over.
Since I started this, I feel responsible for responding to people's comments. I do not think I am doing anything wrong. So please forgive me for responding to you as well, even if you think it silly of me.
Quoted 7 lines
Quoted 3 lines
I believe that it's because of things like this that many users still consider git to be complicated and hard to use. That's what really bothers me.
Why do you think that? I mean, you could be right, but it's certainly conceivable that this feature causes users to consider git _simpler_ to use, because it lets them think about local branches only.
Thinking about local branches only is wrong.
Let's assume the user "just wants to check out branch X." Such a use case has been mentioned previously in this thread. So they say "git checkout X", and voila, they get what they wanted.
It did what they meant it to do. Everybody is happy. But not for long.
Because the next time they "just want to check out branch X," they will remember, it's time for "git checkout X." But what's this? This is not what they wanted. It does not have the latest changes on branch X! Didn't they do the same thing they did last time?
No they did not, because last time they _created a branch_. Eventually, if they are lucky, they will learn in #git that they were supposed to "git merge <remote>/X." And they will think "WTF? Why do I have to _merge_? And what's this business about remotes? Why is git is so complicated?"
So all we did was delay the user's confusion, and make it worse, because now the mind model of "local branches only" they have developed, is broken.
Git uses slightly different semantics than other VCSs, especially when it comes to branches. And that often causes users to become confused. But I happen to think that git's branch model is superior, and easy to understand once you unlearn what you know from other VCSs.
But if we try to hide that fact and imitate other VCSs on the surface, that will only make it harder to learn.
Regards,
Clemens
Quoted 12 lines · Clemens Buchacher
Let's assume the user "just wants to check out branch X." Such a use case has been mentioned previously in this thread. So they say "git checkout X", and voila, they get what they wanted.
It did what they meant it to do. Everybody is happy. But not for long.
Because the next time they "just want to check out branch X," they will remember, it's time for "git checkout X." But what's this? This is not what they wanted. It does not have the latest changes on branch X! Didn't they do the same thing they did last time?
Quoted 5 lines
No they did not, because last time they
_createdabranch_. Eventually, if they are lucky, they will learn in #git that they were supposed to "git merge <remote>/X." And they will think "WTF? Why do I have to _merge_? And what's this business about remotes? Why is git is so complicated?"
FWIW, I made this same complaint at the GitTogether, and the response I got is that git does help the user along through the second "checkout". You get something like:
$ git checkout foo Branch private set up to track remote branch foo from origin. Switched to a new branch 'foo'
... time passes ...
$ git checkout foo Switched to branch 'foo' Your branch is behind 'origin/foo' by 5 commits, and can be fast-forwarded.
Now you can certainly argue that a clueless user won't know what to do with those messages, but it is not entirely true that git leaves them without any advice. Perhaps we could lessen the "wtf" moment in your example above by making that advice better.
-Peff
Quoted 10 lines · Jeff King
$ git checkout foo Branch private set up to track remote branch foo from origin. Switched to a new branch 'foo'... time passes ...
$ git checkout foo Switched to branch 'foo' Your branch is behind 'origin/foo' by 5 commits, and can be fast-forwarded.
I see. That really is somewhat reassuring. I still do not like it, but considering the fact that I could not come up with a scenario worse than that, I suppose the feature is not as bad as I made it out to be.
Thanks all for discussing it with me anyways.
Regards,
Clemens
Quoted 2 lines · Clemens Buchacher
Eventually, if they are lucky, they will learn in #git that they were supposed to "git merge <remote>/X."
They don't have to do that, they just have to do "git pull". This concept -- that to get the latest changes, one pulls -- is something people learn very early.
So, in fact it seems quite natural -- you switch to a local branch with "git co branch", and then if git tells you it's not up-to-date, you "git pull". All nice and smooth and simple and standard. The DWIM simply makes the first time less clumsy, and while everybody benefits, beginners probably benefit a bit more.
-Miles
Signature · 1 line
Do not taunt Happy Fun Ball.
Quoted 5 lines · Clemens Buchacher
No they did not, because last time they
_createdabranch_. Eventually, if they are lucky, they will learn in #git that they were supposed to "git merge <remote>/X." And they will think "WTF? Why do I have to _merge_? And what's this business about remotes? Why is git is so complicated?"
I'm confused. Wont they actually be told:
git checkout $foo
git pull
git push
Why would they need to do a git merge $remote/X?
The only reason I can think of is that they are doing cross branch merges, but then they are by default beyond the novice user and can be expected to know various things, and to have read the docs.
Yves
Signature · 1 line
perl -Mre=debug -e "/just|another|perl|hacker/"
Quoted 7 lines · demerphq
Quoted 5 lines · Clemens Buchacher
No they did not, because last time they
_createdabranch_. Eventually, if they are lucky, they will learn in #git that they were supposed to "git merge <remote>/X." And they will think "WTF? Why do I have to _merge_? And what's this business about remotes? Why is git is so complicated?"
Quoted 5 lines
I'm confused. Wont they actually be told:
git checkout $foo
git pull
git push
Right. Just like they learnt clone/push/pull before knowing about remote and tracking branches, because clone did the magic for them when creating the repo.
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 3 lines · Clemens Buchacher
But this is supposedly a feature which helps users who type "git checkout <branch>" by mistake, when they really wanted to do "git checkout -t <remote>/<branch>".
Not sure what's the argument here, but aren't the two commands equivalent? Do you prefer the second syntax "git checkout -t <remote>/<branch>"? It's already a DWIM for "git checkout -b <branch> -t <remote>/<branch>", and I find this one far more confusing:
git checkout <remote>/<branch> => detaches HEAD
git checkout -t <remote>/<branch> => creates a local branch automatically
Signature · 2 lines
Matthieu Moy http://www-verimag.imag.fr/~moy/
Quoted 6 lines · Matthieu Moy
Quoted 3 lines · Clemens Buchacher
But this is supposedly a feature which helps users who type "git checkout <branch>" by mistake, when they really wanted to do "git checkout -t <remote>/<branch>".
Quoted 7 lines
Not sure what's the argument here, but aren't the two commands equivalent? Do you prefer the second syntax "git checkout -t <remote>/<branch>"? It's already a DWIM for "git checkout -b <branch> -t <remote>/<branch>", and I find this one far more confusing:
git checkout <remote>/<branch> => detaches HEAD
git checkout -t <remote>/<branch> => creates a local branch automatically
The intent with -t is clear. It is used only when you create a new branch. Also, you specify the remote branch you're going to create a new branch from.
"git checkout <branch>", on the other hand, will create a branch based on a remote branch, even though you neither asked for a new branch, nor did you specify any remote at all.
Clemens Buchacher <[email protected]> writes:
[...]
Quoted 3 lines
"git checkout <branch>", on the other hand, will create a branch based on a remote branch, even though you neither asked for a new branch, nor did you specify any remote at all.
Provided such a branch doesn't already exist and that only one remote matches. I agree it's magic (and understand why people might not like it) but personally I find it convenient.
Possibly (because it hides the distinction between local and remote branches a little) it would be better opt-in than the default, but I think a reasonable case could be made in both directions.
[...]
Clemens Buchacher venit, vidit, dixit 07.06.2010 21:32:
Quoted 15 lines · Matthieu Moy
Quoted 6 lines
Quoted 3 lines · Clemens Buchacher
But this is supposedly a feature which helps users who type "git checkout <branch>" by mistake, when they really wanted to do "git checkout -t <remote>/<branch>".
Quoted 7 lines
Not sure what's the argument here, but aren't the two commands equivalent? Do you prefer the second syntax "git checkout -t <remote>/<branch>"? It's already a DWIM for "git checkout -b <branch> -t <remote>/<branch>", and I find this one far more confusing:
git checkout <remote>/<branch> => detaches HEAD
git checkout -t <remote>/<branch> => creates a local branch automatically
Quoted 7 lines
The intent with -t is clear. It is used only when you create a new branch. Also, you specify the remote branch you're going to create a new branch from.
"git checkout <branch>", on the other hand, will create a branch based on a remote branch, even though you neither asked for a new branch, nor did you specify any remote at all.
You're making a very important point here:
The existing DWIMery executes *different commands* depending on the circumstances (<branch> existing or not). "checkout" and "checkout -t/-b" really are different commands.
For me, DWIMery is OK in these cases:
- completing refs (<name> may be refs/heads/<name> or refs/tags/<name> etc.)
- Adding options without which the other options don't make sense (independent of the circumstances), such adding "-b" for "-t", or, even doing the DWIMery above since "--track" is requested explicitly.
Changing the command (mode) is something fundamentally different.
[In this specific case, it also keeps the user from learning what's going on, but that's a different issue.]
But I'm afraid it's too late.
Michael
Quoted 24 lines · Michael J Gruber
Clemens Buchacher venit, vidit, dixit 07.06.2010 21:32:
Quoted 15 lines · Matthieu Moy
Quoted 6 lines
Quoted 3 lines · Clemens Buchacher
But this is supposedly a feature which helps users who type "git checkout <branch>" by mistake, when they really wanted to do "git checkout -t <remote>/<branch>".
Quoted 7 lines
Not sure what's the argument here, but aren't the two commands equivalent? Do you prefer the second syntax "git checkout -t <remote>/<branch>"? It's already a DWIM for "git checkout -b <branch> -t <remote>/<branch>", and I find this one far more confusing:
git checkout <remote>/<branch> => detaches HEAD
git checkout -t <remote>/<branch> => creates a local branch automaticallyQuoted 7 lines
The intent with -t is clear. It is used only when you create a new branch. Also, you specify the remote branch you're going to create a new branch from.
"git checkout <branch>", on the other hand, will create a branch based on a remote branch, even though you neither asked for a new branch, nor did you specify any remote at all.
Quoted 5 lines
You're making a very important point here:
The existing DWIMery executes *different commands* depending on the circumstances (<branch> existing or not). "checkout" and "checkout -t/-b" really are different commands.
"checkout a branch" is the command. The rest is just bookkeeping.
Yves
Signature · 1 line
perl -Mre=debug -e "/just|another|perl|hacker/"
demerphq venit, vidit, dixit 08.06.2010 10:18:
Quoted 25 lines · Michael J Gruber
Quoted 24 lines
Clemens Buchacher venit, vidit, dixit 07.06.2010 21:32:
Quoted 22 lines · Matthieu Moy
Quoted 6 lines
Quoted 3 lines · Clemens Buchacher
But this is supposedly a feature which helps users who type "git checkout <branch>" by mistake, when they really wanted to do "git checkout -t <remote>/<branch>".
Quoted 7 lines
Not sure what's the argument here, but aren't the two commands equivalent? Do you prefer the second syntax "git checkout -t <remote>/<branch>"? It's already a DWIM for "git checkout -b <branch> -t <remote>/<branch>", and I find this one far more confusing:
git checkout <remote>/<branch> => detaches HEAD
git checkout -t <remote>/<branch> => creates a local branch automaticallyThe intent with -t is clear. It is used only when you create a new branch. Also, you specify the remote branch you're going to create a new branch from.
"git checkout <branch>", on the other hand, will create a branch based on a remote branch, even though you neither asked for a new branch, nor did you specify any remote at all.
Quoted 7 lines
Quoted 5 lines
You're making a very important point here:
The existing DWIMery executes *different commands* depending on the circumstances (<branch> existing or not). "checkout" and "checkout -t/-b" really are different commands.
"checkout a branch" is the command. The rest is just bookkeeping.
I'm sorry but that is just plain silly.
We have several "commands" which do very different things depending on options, i.e. comprise different commands/command modes - which is why I used the phrase command (mode) in the part you chose to leave out.
One mode is checking out an existing branch.
One mode is creating a new branch and checking it out, i.e. doing a "git branch" followed by a "git checkout" proper.
Current DWIMery switches from the first to the second depending on your existing branches. The only reason this could sneak in is the fact that it is non-destructive, just (over-) eagerly constructive.
Michael