Re: What is missing from Git v2.0
Jeff King wrote: > On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote: > > > > Maybe I was not clear in my response, so let me try again. I do _not_ > > > necessarily agree that we need to move away from the name index. > > > > So you agree that "the index" is a bad name, and you agree "staging area" > > is a > > better name, yet you don't agree we should move away from the term "index"? > > I don't agree that "the index" is a "bad" name, because that implies > some objective level of "bad". > > I do think the name "staging area" is fine, and I think it may even be > better than "index", if we were picking a name out of the blue. > The way you have phrased it seems like you are trying to create a logical > contradiction: A is bad, B is good, therefore we should move from A to B. A _is_ bad, and B _is_ good. That's what I, and many people, have argued, and that's what the vast majority of people have agreed. > But that neglects the cost of moving. And you neglect the benefits of moving. It is very clear that the costs of moving are negligible in comparison to the benefits. But you *always* resist any change, so of course you wouldn't agree on change. And that's why nothing ever changes. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Fri, Apr 25, 2014 at 01:57:59PM -0500, Felipe Contreras wrote: > > Maybe I was not clear in my response, so let me try again. I do _not_ > > necessarily agree that we need to move away from the name index. > > So you agree that "the index" is a bad name, and you agree "staging area" is a > better name, yet you don't agree we should move away from the term "index"? I don't agree that "the index" is a "bad" name, because that implies some objective level of "bad". I do think the name "staging area" is fine, and I think it may even be better than "index", if we were picking a name out of the blue. I am undecided on whether we should move away from the term "index". The way you have phrased it seems like you are trying to create a logical contradiction: A is bad, B is good, therefore we should move from A to B. But that neglects the cost of moving. Frankly, I am not that interested in discussing it with you. I _am_ interested in you not using my name to claim that I believe things I do not. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Jeff King wrote: > On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote: > > > I specifically said everybody agreed to "move away from the name 'index'", I > > didn't say everybody agreed on the "staged area" although the vast majority > > did, and I didn't say anybody agreed on my patches, although some did. > > > > I think I was clear. > > Maybe I was not clear in my response, so let me try again. I do _not_ > necessarily agree that we need to move away from the name index. So you agree that "the index" is a bad name, and you agree "staging area" is a better name, yet you don't agree we should move away from the term "index"? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Fri, Apr 25, 2014 at 01:27:17PM -0500, Felipe Contreras wrote: > I specifically said everybody agreed to "move away from the name 'index'", I > didn't say everybody agreed on the "staged area" although the vast majority > did, and I didn't say anybody agreed on my patches, although some did. > > I think I was clear. Maybe I was not clear in my response, so let me try again. I do _not_ necessarily agree that we need to move away from the name index. I am specifically saying that your "everyone" includes my name explicitly, and that I do not agree with the statement you are attributing to it. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Jeff King wrote: > On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote: > > > When I say literally everbody agreed to move away from the name "index" > > (except > > Junio and another guy) I mean it. I even composed a list: > > > > http://article.gmane.org/gmane.comp.version-control.git/233469 > > > > Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed. > > With reference to my name, your email says: > > Jeff King: > "staging area" makes perfect sense > > But here's that statement in context[1]: > > So the term "staging area" makes perfect sense to me; it is where we > collect changes to make a commit. I am willing to accept that does not > to others (native English speakers or no), and that we may need to > come up with a better term. But I think just calling it "the stage" is > even worse; it loses the concept that it is a place for collecting and > organizing. > > In other words, I was saying that the term makes sense to me, and > primarily comparing favorably to a worse proposal. I am not commenting > at all on a plan to change names, which is what you are claiming above. > > I do think the term "staging area" is fine, but picking a term is only > step one of a plan. The rest is deciding how to make the change, and > whether it is worth it. I remain undecided on the latter bits. Please > don't quote me out of context in a way that implies that I am decided. I specifically said everybody agreed to "move away from the name 'index'", I didn't say everybody agreed on the "staged area" although the vast majority did, and I didn't say anybody agreed on my patches, although some did. I think I was clear. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Fri, Apr 25, 2014 at 12:45:27PM -0500, Felipe Contreras wrote: > When I say literally everbody agreed to move away from the name "index" > (except > Junio and another guy) I mean it. I even composed a list: > > http://article.gmane.org/gmane.comp.version-control.git/233469 > > Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed. With reference to my name, your email says: Jeff King: "staging area" makes perfect sense But here's that statement in context[1]: So the term "staging area" makes perfect sense to me; it is where we collect changes to make a commit. I am willing to accept that does not to others (native English speakers or no), and that we may need to come up with a better term. But I think just calling it "the stage" is even worse; it loses the concept that it is a place for collecting and organizing. In other words, I was saying that the term makes sense to me, and primarily comparing favorably to a worse proposal. I am not commenting at all on a plan to change names, which is what you are claiming above. I do think the term "staging area" is fine, but picking a term is only step one of a plan. The rest is deciding how to make the change, and whether it is worth it. I remain undecided on the latter bits. Please don't quote me out of context in a way that implies that I am decided. -Peff [1] http://article.gmane.org/gmane.comp.version-control.git/168012 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Philippe Vaucher wrote: > >> Yes, of course there should be a list of both positive and negative > >> tradeoffs. But I think the "overloaded" argument can be easily solved > >> by renaming one of the overloads. > > > > And renaming one of a term also has costs, especially if it is one > > that is in use in large amounts of documentation, both in the git man > > pages, and in web pages across the web. > > It's just impossible to change terms and have previous documentation > still be valid. Sure, you can list it in the "cons" section as an > argument, but it's not very convincing in itself because it applies to > pretty much any interface changes. I think the main idea is to > _improve_ the interface, which means rename things so it is more > consistent and so concepts are easier for new comers to grasp. We > could still support old terms for a while and eventually deprecate > them. And that's exactly what I did in my patch series: start introducing the --stage options along the current ones. http://thread.gmane.org/gmane.comp.version-control.git/236127/focus=236128 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Theodore Ts'o wrote: > On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote: > > > > I agree. The "stage area" is a very important concept in git, why not > > talk git commands that refers to it? Then we could add flags like > > --new-files or --deleted-files for better granularity than the current > > --all flag. > > One caution: The term "stage/staged" is already a little overloaded. > We generally use the word "staged" to refer to changes that are in the > index, but the term "stage" as a noun generally refers to referencing > the different versions of a file during a merge operation (cf "git > ls-files --stage"). > > > I think starting by documenting the issues is a good idea, maybe on a > > wiki, and start some draft of a proposed solution that would improve > > in an iterative process. > > And it would be nice if the issues were discussed in a way that acknowledged > that all changes have tradeoffs, both positive and negative, They have been discussed at length: http://thread.gmane.org/gmane.comp.version-control.git/197111 http://thread.gmane.org/gmane.comp.version-control.git/166675 http://thread.gmane.org/gmane.comp.version-control.git/115666 http://thread.gmane.org/gmane.comp.version-control.git/236127 When I say literally everbody agreed to move away from the name "index" (except Junio and another guy) I mean it. I even composed a list: http://article.gmane.org/gmane.comp.version-control.git/233469 Jeff King, Jonathan Nieder, Matthieu Moy, they all agreed. > or for people for whom English might not be the first language. People whom English is not their first language also agreed "index" is a terrible term. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Kastrup wrote: > Jonathan Nieder writes: >> I probably missed a subtlety, but the above comment reminded me of >> some netiquette I think this list is starting to forget. If I have >> misread it, please let me know and skip the rest of this message. [...] >> On the git list, the rule is simple. Feel free to grumble, but make >> sure there is some contribution in the same message. [...] > Uh, Javier was commenting on a number of concrete proposals regarding > the subject line "What is missing from Git v2.0" and quoted Felipe > directly. As you seem to have lost the context, let me requote the > respective portion: I hadn't lost the context, but thanks for a pointer. [...] > = Reject non-fast-forward pulls by default = [...] > The patches were sent, the issues were addressed, people agreed, and > yet nothing happened. > > [3][4] > > [...] > > [3] http://thread.gmane.org/gmane.comp.version-control.git/240030 > [4] http://thread.gmane.org/gmane.comp.version-control.git/235981 Unfortunately Felipe's summary is incomplete. My message was meant as something that could be made into a reference for when similar questions of netiquette come up in the future (as for example they do all the time with Felipe). That meant I didn't give as good advice for your particular case than I should have. For this particular case, my thoughts are: If you believe those patches should be applied, please re-send them with a summary of changes you've made (if any) and your opinion on any unaddressed comments from the review thread. If you believe those patches should not be applied, wouldn't it be better to reply to that thread to help in case someone wants to pick up the patches and fix them? On the other hand if you just want to blow off steam, I guess that's fine too. Just don't expect it to result in any patches being applied, code quality improving, etc. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
>> Yes, of course there should be a list of both positive and negative >> tradeoffs. But I think the "overloaded" argument can be easily solved >> by renaming one of the overloads. > > And renaming one of a term also has costs, especially if it is one > that is in use in large amounts of documentation, both in the git man > pages, and in web pages across the web. It's just impossible to change terms and have previous documentation still be valid. Sure, you can list it in the "cons" section as an argument, but it's not very convincing in itself because it applies to pretty much any interface changes. I think the main idea is to _improve_ the interface, which means rename things so it is more consistent and so concepts are easier for new comers to grasp. We could still support old terms for a while and eventually deprecate them. > www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q I think this comparison is a bit bogus, searching for "git stage" yields more accurate results, we can see the searches are related: http://www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index%2C%20git%20stage&cmpt=q >> Unfortunately yes, I see many people being silly in order to win >> arguments, both in the pro-changes and against-changes side of the >> discussion. I'd be much simpler to simply gather arguments on some >> wiki and eventually do a vote when the list is complete about the >> proposed change. > > Voting is not a good way to do software development. That way lies > people wanting to whip up clueless folks using rhetoric (exhibit one: > Fox News) to "vote" and so it's not necessarily the best way to make > thoughtful decisions. Using hard data, including possibly formal UX > experiments, is a much better way to make such decisions. Interesting, but then who's to say which data is more important than anothers? For example, I consider improving the interface to be more important than having old documentation on blogs/tutorial for a while until people catch up, but maybe you consider old documentation to be more important... who decides what really counts? I guess it's a mix of general consensus and old timers credibility. Anyway, having some data as a list of pros/cons would greatly simplify the debate. Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Jonathan Nieder writes: > Hi, > > David Kastrup wrote: >> Javier Domingo Cansino writes: > >>> = Reject non-fast-forward pulls by default = >>> Not having this introduced yet allows newbie people to use git with >>> just 4 commands, without bothering around with fetch and merge and so. >> >> If you have a gun lying around your house, you should turn the safety >> catch off or the children will not be able to use it without >> instruction. > > I probably missed a subtlety, but the above comment reminded me of > some netiquette I think this list is starting to forget. If I have > misread it, please let me know and skip the rest of this message. > > This is a comment about style, not substance. Like coding style, > discussion style matters as a way of making life easier for > maintainers and new contributors, and different projects have subtly > different practices. > > On the git list, the rule is simple. Feel free to grumble, but make > sure there is some contribution in the same message. For example, > after the confusing gun analogy you can say "How about this patch?" > and people reading can follow up by reviewing that patch and > potentially getting it applied. Uh, Javier was commenting on a number of concrete proposals regarding the subject line "What is missing from Git v2.0" and quoted Felipe directly. As you seem to have lost the context, let me requote the respective portion: From: Felipe Contreras Subject: What is missing from Git v2.0 Newsgroups: gmane.comp.version-control.git To: git@vger.kernel.org Date: Sun, 20 Apr 2014 17:41:05 -0500 (4 days, 17 hours, 12 minutes ago) [...] = Reject non-fast-forward pulls by default = Many new-comers end up making merges by mistake when they pull because they don't understand what is a non-fast-forward and what they should actually be doing. Most people, even Linus Torvalds, agreed that by default `git pull` should fail and guide the user, instead of silently making a merge which might not be what the user wants (even though he doesn't know it), and messing up the project's history, which affects other people. The patches were sent, the issues were addressed, people agreed, and yet nothing happened. [3][4] [...] [3] http://thread.gmane.org/gmane.comp.version-control.git/240030 [4] http://thread.gmane.org/gmane.comp.version-control.git/235981 > "How do I get feedback on design of a new change without wasting a lot > of time coding something that might be a bad idea?" Glad you asked. I didn't. > "What about reminders about known bugs? There's this regression and > it would not be right to release without fixing it but I think it's > fallen through the cracks." Yes, good contribution. > > "What about jokes?" Sure, making people laugh is productive. > > "What about cryptic grumbling?" Sorry, unless you are grumbling to > get input on how to improve git's documentation or code, it's not > enough to be worth sending an email to this list. > > Hope that helps, No need to get condescending if you did not get the joke. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Hi, David Kastrup wrote: > Javier Domingo Cansino writes: >> = Reject non-fast-forward pulls by default = >> Not having this introduced yet allows newbie people to use git with >> just 4 commands, without bothering around with fetch and merge and so. > > If you have a gun lying around your house, you should turn the safety > catch off or the children will not be able to use it without > instruction. I probably missed a subtlety, but the above comment reminded me of some netiquette I think this list is starting to forget. If I have misread it, please let me know and skip the rest of this message. This is a comment about style, not substance. Like coding style, discussion style matters as a way of making life easier for maintainers and new contributors, and different projects have subtly different practices. On the git list, the rule is simple. Feel free to grumble, but make sure there is some contribution in the same message. For example, after the confusing gun analogy you can say "How about this patch?" and people reading can follow up by reviewing that patch and potentially getting it applied. "But what if there's already a patch doing what I want to do?" you might ask. No problem. Link to the patch and say "I think this patch should be revisited", or even better, re-send it with some notes about how previous review comments have been addressed or remain to be addressed. "How do I get feedback on design of a new change without wasting a lot of time coding something that might be a bad idea?" Glad you asked. Sometimes instead of a patch, a better contribution is a detailed explanation of a design to be reviewed and adopted. In this case, do try to be clear about whether you'll have enough time to implement the result or will be relying on others so people know how much time to devote to working out the details. "What about feature requests? I might have an idea for improving git that no one's had before but I don't have a detailed design in mind." Sure, that can be a good contribution. Just treat it as a gift --- don't assume anyone is going to implement it for you if they're not interested. "What about reminders about known bugs? There's this regression and it would not be right to release without fixing it but I think it's fallen through the cracks." Yes, good contribution. "What about jokes?" Sure, making people laugh is productive. "What about cryptic grumbling?" Sorry, unless you are grumbling to get input on how to improve git's documentation or code, it's not enough to be worth sending an email to this list. Hope that helps, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Fri, Apr 25, 2014 at 04:23:43PM +0200, Philippe Vaucher wrote: > > I agree, but I think it's better than "index" tho. That one is heavily > overloaded and easily confused with other meaning in other softwares. There is a big difference between being used in a difference sense than other software --- there is a one-time learning curve after which point people can generally understand that a term in a given context has a single meaning --- and when we have two very easily confused terms (i.e., "stage versus staged") or a single identical term, overloaded within a single context. So I'm much more worried about the git documentation using the same term or two closely related terms in an overloaded fashion, much more than I am with "index" meaning one thing for databases, and another thing for book publishers, and yet another for compilers. > Yes, of course there should be a list of both positive and negative > tradeoffs. But I think the "overloaded" argument can be easily solved > by renaming one of the overloads. And renaming one of a term also has costs, especially if it is one that is in use in large amounts of documentation, both in the git man pages, and in web pages across the web. And my plea for data extends even here. For example, things like this: www.google.com/trends/explore#q=git%20staging%20area%2C%20git%20index&cmpt=q > Unfortunately yes, I see many people being silly in order to win > arguments, both in the pro-changes and against-changes side of the > discussion. I'd be much simpler to simply gather arguments on some > wiki and eventually do a vote when the list is complete about the > proposed change. Voting is not a good way to do software development. That way lies people wanting to whip up clueless folks using rhetoric (exhibit one: Fox News) to "vote" and so it's not necessarily the best way to make thoughtful decisions. Using hard data, including possibly formal UX experiments, is a much better way to make such decisions. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
>> I agree. The "stage area" is a very important concept in git, why not >> talk git commands that refers to it? Then we could add flags like >> --new-files or --deleted-files for better granularity than the current >> --all flag. > > One caution: The term "stage/staged" is already a little overloaded. > We generally use the word "staged" to refer to changes that are in the > index, but the term "stage" as a noun generally refers to referencing > the different versions of a file during a merge operation (cf "git > ls-files --stage"). I agree, but I think it's better than "index" tho. That one is heavily overloaded and easily confused with other meaning in other softwares. >> I think starting by documenting the issues is a good idea, maybe on a >> wiki, and start some draft of a proposed solution that would improve >> in an iterative process. > > And it would be nice if the issues were discussed in a way that > acknowledged that all changes have tradeoffs, both positive and > negative, and to clearly articulate whether the concern is just > someone going "uh, 'index' is a wierd term", but once they learn it, > it's pretty clear, versus a case where there is continuous confusion > due to overloaded meanings, or for people for whom English might not > be the first language. Yes, of course there should be a list of both positive and negative tradeoffs. But I think the "overloaded" argument can be easily solved by renaming one of the overloads. > And most importantly, to avoid rheteroic. In fact, given that strong > use of rhetoric is often used to disguise a weakness of a position > that can't be defended using logic and data, someone who tries to win > arguments using the "last post wins" style of discourse, and a heavy > use of rhetoric, may find that people just simply decide that it's a > better use of their time not to engage and to just kill the entire > thread. Unfortunately yes, I see many people being silly in order to win arguments, both in the pro-changes and against-changes side of the discussion. I'd be much simpler to simply gather arguments on some wiki and eventually do a vote when the list is complete about the proposed change. Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Fri, Apr 25, 2014 at 09:48:53AM +0200, Philippe Vaucher wrote: > > I agree. The "stage area" is a very important concept in git, why not > talk git commands that refers to it? Then we could add flags like > --new-files or --deleted-files for better granularity than the current > --all flag. One caution: The term "stage/staged" is already a little overloaded. We generally use the word "staged" to refer to changes that are in the index, but the term "stage" as a noun generally refers to referencing the different versions of a file during a merge operation (cf "git ls-files --stage"). > I think starting by documenting the issues is a good idea, maybe on a > wiki, and start some draft of a proposed solution that would improve > in an iterative process. And it would be nice if the issues were discussed in a way that acknowledged that all changes have tradeoffs, both positive and negative, and to clearly articulate whether the concern is just someone going "uh, 'index' is a wierd term", but once they learn it, it's pretty clear, versus a case where there is continuous confusion due to overloaded meanings, or for people for whom English might not be the first language. And most importantly, to avoid rheteroic. In fact, given that strong use of rhetoric is often used to disguise a weakness of a position that can't be defended using logic and data, someone who tries to win arguments using the "last post wins" style of discourse, and a heavy use of rhetoric, may find that people just simply decide that it's a better use of their time not to engage and to just kill the entire thread. Regards, - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Philippe Vaucher wrote: > > I think you are on the right track but the solution is not to shrug > > shoulders. > > We should acknowledge there are serious problems with the interface, list > > them, > > and try to fix them. One example is `git add $tracked_file` being wrong, it > > should be `git stage $tracked_file`. > > I agree. The "stage area" is a very important concept in git, why not > talk git commands that refers to it? Then we could add flags like > --new-files or --deleted-files for better granularity than the current > --all flag. Like this: http://thread.gmane.org/gmane.comp.version-control.git/236127 > > The real problem is that the core developers of Git don't acknowledge these > > user-interface issues, according the them the interface doesn't require any > > major changes. Which goes contrary to what most of the world believes. > > I think most people agree with these interfaces issues but it's a hard > problem to solve, so they are reluctant to talk about it because they > fear the can of worm. If someone came with a good solution most people > would be willing to consider it. > > I think starting by documenting the issues is a good idea, maybe on a > wiki, and start some draft of a proposed solution that would improve > in an iterative process. Yes, it would be good to document these issues, but it wouldn't matter if the developers ignore them. For example the move away from the 'index' name was backed up by literally everyone, except Junio, so it doesn't matter if the issue is documented, and there are patches with good solutions, if Junio thinks it's not an issue; it's ignored. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
> I think you are on the right track but the solution is not to shrug shoulders. > We should acknowledge there are serious problems with the interface, list > them, > and try to fix them. One example is `git add $tracked_file` being wrong, it > should be `git stage $tracked_file`. I agree. The "stage area" is a very important concept in git, why not talk git commands that refers to it? Then we could add flags like --new-files or --deleted-files for better granularity than the current --all flag. > The real problem is that the core developers of Git don't acknowledge these > user-interface issues, according the them the interface doesn't require any > major changes. Which goes contrary to what most of the world believes. I think most people agree with these interfaces issues but it's a hard problem to solve, so they are reluctant to talk about it because they fear the can of worm. If someone came with a good solution most people would be willing to consider it. I think starting by documenting the issues is a good idea, maybe on a wiki, and start some draft of a proposed solution that would improve in an iterative process. Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
> > I don't even think we need to query the user to fill out all of the > > fields. We can prepopulate a lot of the fields (name, e-mail address, > > etc.) from OS specific defaults that are available on most systems --- > > specifically, the default values we would use the name and e-mail > > address are not specified in a config file. > > Please don't. Or you end up again with Commiters like sb@localhost, > sbeller@(None) or alike. I mean it's just one question once you setup > a new computer, so I'd really like to see that question and then > answer myself (at university/employer I might put in another email > address than at home anyway, and I'm sure my boxes have no sane > defaults) Yes, try to guess a good default but let the user change it if he wants to, and if he presses enter the default is used. It's not a big deal to have to press enter a few times the first time you use git. That or make a new "git setup" command which interactively sets up your .gitconfig. Philippe -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Javier Domingo Cansino writes: > Felipe's > === > > = Reject non-fast-forward pulls by default = > Not having this introduced yet allows newbie people to use git with > just 4 commands, without bothering around with fetch and merge and so. If you have a gun lying around your house, you should turn the safety catch off or the children will not be able to use it without instruction. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
ty...@mit.edu writes: > On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote: >> > I don't even think we need to query the user to fill out all of the >> > fields. We can prepopulate a lot of the fields (name, e-mail address, >> > etc.) from OS specific defaults that are available on most systems --- >> > specifically, the default values we would use the name and e-mail >> > address are not specified in a config file. >> >> Please don't. Or you end up again with Commiters like sb@localhost, >> sbeller@(None) or alike. I mean it's just one question once you setup >> a new computer, so I'd really like to see that question and then >> answer myself (at university/employer I might put in another email >> address than at home anyway, and I'm sure my boxes have no sane >> defaults) > > But that's no worse than what we have today. It is. Currently, Git displays a very big and scary warning when you use commit and Git had to guess your identity. If you explicitly fill-in the config file with guessed values, then Git will have no way to know if the config values are real or guessed. OTOH, a prompt with a default value (i.e "type 'return' to get the default") would make sense. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Javier Domingo Cansino wrote: > Felipe's > === > > = The publish tracking branch = > I still have problems getting upstream branches correctly configured > as to have this introduced, anyway, I suppose it's optional, so > nothing to add on that. I did so too, until I patch `git branch -v` to be useful. > = Reject non-fast-forward pulls by default = > Not having this introduced yet allows newbie people to use git with > just 4 commands, without bothering around with fetch and merge and so. I don't understand what you are trying to say. There is no change for those people, when the pull fails they would be told to use `git pull --merge` if not sure. > = Use "stage" instead of "index" = > Totally agree with this. > > = Default aliases = > I hate aliases, make scripts more difficult to read and understand. You are assuming that everyone will start to use aliases in scripts, which is not going to happen enough to be a problem. Try to find svn or hg scripts with aliases, let's see how many you find. > Mine > > I have taught (or tried to) a lot of people Git. And this is some of > the stuff I have seen they have difficulties with: > - Remembering the commands, for example, remembering add, commit push > and pull, which I think we can all agree is the most core and simple > combination of Git commands. > - What command comes for what they need. If I want to share > everything, what should I do? > - Most of them, have real difficulties on remembering the flows. There > are too many commands for the start. > > I wouldn't nevertheless suppress any of them, I would rather do a tuto > on-the-go. I think you are on the right track but the solution is not to shrug shoulders. We should acknowledge there are serious problems with the interface, list them, and try to fix them. One example is `git add $tracked_file` being wrong, it should be `git stage $tracked_file`. The real problem is that the core developers of Git don't acknowledge these user-interface issues, according the them the interface doesn't require any major changes. Which goes contrary to what most of the world believes. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe's === = The publish tracking branch = I still have problems getting upstream branches correctly configured as to have this introduced, anyway, I suppose it's optional, so nothing to add on that. By the way, remote branch managing has improved a lot, one of the best things I see for branching and remotes is the "git remote show" command, but I think further work should be done. Help messages FTW! = Reject non-fast-forward pulls by default = Not having this introduced yet allows newbie people to use git with just 4 commands, without bothering around with fetch and merge and so. = Use "stage" instead of "index" = Totally agree with this. = Default aliases = I hate aliases, make scripts more difficult to read and understand. I would instead try to improve knowledge on this feature. I have to agree with David Lang's first message, and The cherry-pick => pick thing would be the only thing I would see with good eyes, just because it's too long and has a dash. Juno's == The idea about ~/.gitconfig seems incredible simple and effective to me. I would however try to keep it simple, and minimize the form. Mine I have taught (or tried to) a lot of people Git. And this is some of the stuff I have seen they have difficulties with: - Remembering the commands, for example, remembering add, commit push and pull, which I think we can all agree is the most core and simple combination of Git commands. - What command comes for what they need. If I want to share everything, what should I do? - Most of them, have real difficulties on remembering the flows. There are too many commands for the start. I wouldn't nevertheless suppress any of them, I would rather do a tuto on-the-go. Here are some ideas I have thought of: == Command Output== At the moment, there are several commands that don't output any help text, and many others, that although they have become more verbose with the years, they aren't too verbose yet. One of the things I most recommend to anyone is to run "git status" just before any command (push, commit, add, etc.) to get sure they are doing what they thing they will. For example, running git add won't tell you what you just added, nor what you could do now. I would put some output there, maybe the git status output or something similar that helps the user to know what just happened. Git status doesn't say much about remotes, and suggesting pushing if a remote is outdated, would be fantastic. Checkout command has decreased verbosity from a previous version, where it stated which branch it came from and to which branch it was switching to. As an extreme thing, I would consider adding a configuration parameter default, core.helptext=True that could switch off all this stuff. ==Running git== This is a very basic idea, and I suppose it isn't too helpful or realistic, but might give someone an idea. I would first make that running git, just git, tell the user the possibilities he has. I don't know of any power user that uses git to remember the commands. At the moment, git[1] just tells many of the commands available, without any classification, maybe classifying them as "commiting" "branching" and "remote" could help a little. Regards, Javier Domingo Cansino [1] git output: javier@frodo:~$ git usage: git [--version] [--help] [-C ] [-c name=value] [--exec-path[=]] [--html-path] [--man-path] [--info-path] [-p|--paginate|--no-pager] [--no-replace-objects] [--bare] [--git-dir=] [--work-tree=] [--namespace=] [] The most commonly used git commands are: addAdd file contents to the index bisect Find by binary search the change that introduced a bug branch List, create, or delete branches checkout Checkout a branch or paths to the working tree clone Clone a repository into a new directory commit Record changes to the repository diff Show changes between commits, commit and working tree, etc fetch Download objects and refs from another repository grep Print lines matching a pattern init Create an empty Git repository or reinitialize an existing one logShow commit logs merge Join two or more development histories together mv Move or rename a file, a directory, or a symlink pull Fetch from and integrate with another repository or a local branch push Update remote refs along with associated objects rebase Forward-port local commits to the updated upstream head reset Reset current HEAD to the specified state rm Remove files from the working tree and from the index show Show various types of objects status Show the working tree status tagCreate, list, delete or verify a tag object signed with GPG 'git help -a' and 'git help -g' lists available subcommands and some concept guides. See 'git help ' or 'git help ' to
Re: What is missing from Git v2.0
On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote: > On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote: > Creating a ~/.gitconfig file if one doesn't already is one I agree > with, and at least on Unix systems, telling them that the config file > lives in ~/.gitconfig, or where ever it might happen to be on other > platforms, is a good one. If it's in some really weird place on > Windows, then sure, we can tell them about "git config -e". But the > point is to let the user look at the default .gitconfig file, where we > can put in comments to help explain what is going on, and perhaps have > links to web pages for more information. I think the idea of a commented gitconfig is a good solution. We could include default aliases commented, so that a new user would just have to uncomment them. That way, he will understand they are aliases and not commands, learn how to tune them to its own needs and it won't annoy anyone because they will be commented by default, ideally with explicit commentaries around them. Furthermore, this could be a good way to show a new user all the possibilities of git, or at least its configuration. Documentation is a good thing when you know what you are looking for, but when you are beginning, you don't know what can be done, and reading a complete and commented example configuration could be a good way to discover it. pgpbPbeQEGNjc.pgp Description: PGP signature
Re: What is missing from Git v2.0
Felipe Contreras writes: > Andreas Krey wrote: >> On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote: >> ... >> > Anyway, if you disagree change one of your frequently used passwords to a >> > chapter of The Lord of the Rings for a day. Let's see if you still think >> > that. >> >> Proving that one extreme isn't the optimum doesn't prove the other is. > > It's called hyperbole, and it's a very common and very effective rhetorical > device. Let us conclude this discussion by declaring you the best rhetor then. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Thu, 24 Apr 2014, Felipe Contreras wrote: David Kastrup wrote: Felipe Contreras writes: David Kastrup wrote: The people having to read and understand scripts written in the expectation of default aliases. Which are imaginary. And I prefer them to stay that way since then one does not need to worry about them. If everybody was afraid of moving because of imaginary fears like you, nothing would get done in this world. Rational people distinguish the imaginary from the real. The exact same thing could be said for your position that typing rebase instead of rb causes a major problem Calm down and stop accusing everyone of sticking their heads in the ground David Lang -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Thu, Apr 24, 2014 at 01:26:33PM -0500, Felipe Contreras wrote: > Jonathan Nieder wrote: > > Stefan Beller wrote: > > > > > I may have missunderstood. > > > > > > So today you cannot commit if you don't provide an email address > > > (usually the first time you try to commit, git asks to "git config > > > --global author.email="), if I remember correctly, so > > > there is definitely a valid (i.e. user approved) email address. > > > > Not true. But you do get a big wall of text when you make your > > first commit without an EMAIL envvar or configured [user] section, > > including > > Only if you don't have a fully qualified hostname. No, we alway warn if the values weren't explicitly provided: $ git config --global --unset user.email $ git commit --allow-empty -m foo [master 1e987ba] foo Committer: Jeff King Your name and email address were configured automatically based on your username and hostname. Please check that they are accurate. You can suppress this message by setting them explicitly: git config --global user.name "Your Name" git config --global user.email y...@example.com After doing this, you may fix the identity used for this commit with: git commit --amend --reset-author but we will consider several sources explicit, like $GIT_COMMITTER_EMAIL, $EMAIL, and of course user.email: $ EMAIL=whate...@example.com git commit --allow-empty -m foo [master e75f17a] foo We die when the values are implicitly derived from the system _and_ they look bogus: $ sudo rm /etc/mailname $ sudo hostname bogus $ git commit --allow-empty -m foo *** Please tell me who you are. Run git config --global user.email "y...@example.com" git config --global user.name "Your Name" to set your account's default identity. Omit --global to set the identity only in this repository. fatal: unable to auto-detect email address (got 'peff@bogus.(none)') -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Theodore Ts'o wrote: > On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote: > > > > There is evidence for the claim that there won't be those problems. You have > > absolutely no evidence there there will. > > It's clear that you've not been able to produce evidence that can > convince most of the people on this thread. Which only proves you don't want to be convinced, no evidence could convince you. > I don't even think we need to query the user to fill out all of the > fields. We can prepopulate a lot of the fields (name, e-mail address, > etc.) from OS specific defaults that are available on most systems --- > specifically, the default values we would use the name and e-mail > address are not specified in a config file. Most systems don't have a configured $EMAIL, so those defautls would be wrong. It's so evident that no evide could convince you that you don't even bothere to answer my question: Why does Mercurial, Bazaar, Subversion, CVS, and pretty much everything uses aliases? Since you are conveniently not answering, I'll answer for you: Because such hypothetical problems wouldn't actually occur in reality with Git, just like they don't occur in other tools. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Andreas Krey wrote: > On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote: > ... > > Anyway, if you disagree change one of your frequently used passwords to a > > chapter of The Lord of the Rings for a day. Let's see if you still think > > that. > > Proving that one extreme isn't the optimum doesn't prove the other is. It's called hyperbole, and it's a very common and very effective rhetorical device. Nobody argued that the extreme opposite was best. My point was that the amount of characters you type _does_ matter, and I think I proved my point. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Kastrup wrote: > Felipe Contreras writes: > > David Kastrup wrote: > >> The people having to read and understand scripts written in the > >> expectation of default aliases. > > > > Which are imaginary. > > And I prefer them to stay that way since then one does not need to worry > about them. If everybody was afraid of moving because of imaginary fears like you, nothing would get done in this world. Rational people distinguish the imaginary from the real. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Jonathan Nieder wrote: > Stefan Beller wrote: > > > I may have missunderstood. > > > > So today you cannot commit if you don't provide an email address > > (usually the first time you try to commit, git asks to "git config > > --global author.email="), if I remember correctly, so > > there is definitely a valid (i.e. user approved) email address. > > Not true. But you do get a big wall of text when you make your > first commit without an EMAIL envvar or configured [user] section, > including Only if you don't have a fully qualified hostname. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Stefan Beller wrote: > I may have missunderstood. > > So today you cannot commit if you don't provide an email address > (usually the first time you try to commit, git asks to "git config > --global author.email="), if I remember correctly, so > there is definitely a valid (i.e. user approved) email address. That's not true, that's only the case if you don't have a fully qualified hostname, like 'localhost', but if you do, like localhost.redhat, then Git assumes your email is user@localhost.redhat, and it's valid. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
tytso@ wrote: > On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote: > > > I don't even think we need to query the user to fill out all of the > > > fields. We can prepopulate a lot of the fields (name, e-mail address, > > > etc.) from OS specific defaults that are available on most systems --- > > > specifically, the default values we would use the name and e-mail > > > address are not specified in a config file. > > > > Please don't. Or you end up again with Commiters like sb@localhost, > > sbeller@(None) or alike. I mean it's just one question once you setup > > a new computer, so I'd really like to see that question and then > > answer myself (at university/employer I might put in another email > > address than at home anyway, and I'm sure my boxes have no sane > > defaults) > > But that's no worse than what we have today. What if we print what > the defaults were, which might help encourage the user to actually run > the "git config -e" command? In addition we shouldn't consider user@host a valid e-mail. In the vast majority of cases it's not. http://article.gmane.org/gmane.comp.version-control.git/232027 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Stefan Beller wrote: > I may have missunderstood. > > So today you cannot commit if you don't provide an email address > (usually the first time you try to commit, git asks to "git config > --global author.email="), if I remember correctly, so > there is definitely a valid (i.e. user approved) email address. Not true. But you do get a big wall of text when you make your first commit without an EMAIL envvar or configured [user] section, including | You can suppress this message by setting them explicitly: | | git config --global user.name "Your Name" | git config --global user.email y...@example.com | | After doing this, you may fix the identity used for this commit with: | | git commit --amend --reset-author Ciao, Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
I may have missunderstood. So today you cannot commit if you don't provide an email address (usually the first time you try to commit, git asks to "git config --global author.email="), if I remember correctly, so there is definitely a valid (i.e. user approved) email address. 2014-04-24 17:47 GMT+02:00 : > On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote: >> > I don't even think we need to query the user to fill out all of the >> > fields. We can prepopulate a lot of the fields (name, e-mail address, >> > etc.) from OS specific defaults that are available on most systems --- >> > specifically, the default values we would use the name and e-mail >> > address are not specified in a config file. >> >> Please don't. Or you end up again with Commiters like sb@localhost, >> sbeller@(None) or alike. I mean it's just one question once you setup >> a new computer, so I'd really like to see that question and then >> answer myself (at university/employer I might put in another email >> address than at home anyway, and I'm sure my boxes have no sane >> defaults) > > But that's no worse than what we have today. What if we print what > the defaults were, which might help encourage the user to actually run > the "git config -e" command? > > - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Thu, Apr 24, 2014 at 05:00:13PM +0200, Stefan Beller wrote: > > I don't even think we need to query the user to fill out all of the > > fields. We can prepopulate a lot of the fields (name, e-mail address, > > etc.) from OS specific defaults that are available on most systems --- > > specifically, the default values we would use the name and e-mail > > address are not specified in a config file. > > Please don't. Or you end up again with Commiters like sb@localhost, > sbeller@(None) or alike. I mean it's just one question once you setup > a new computer, so I'd really like to see that question and then > answer myself (at university/employer I might put in another email > address than at home anyway, and I'm sure my boxes have no sane > defaults) But that's no worse than what we have today. What if we print what the defaults were, which might help encourage the user to actually run the "git config -e" command? - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
> I don't even think we need to query the user to fill out all of the > fields. We can prepopulate a lot of the fields (name, e-mail address, > etc.) from OS specific defaults that are available on most systems --- > specifically, the default values we would use the name and e-mail > address are not specified in a config file. Please don't. Or you end up again with Commiters like sb@localhost, sbeller@(None) or alike. I mean it's just one question once you setup a new computer, so I'd really like to see that question and then answer myself (at university/employer I might put in another email address than at home anyway, and I'm sure my boxes have no sane defaults) 2014-04-24 15:41 GMT+02:00 Theodore Ts'o : > On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote: >> >> There is evidence for the claim that there won't be those problems. You have >> absolutely no evidence there there will. > > Felipe, > > It's clear that you've not been able to produce evidence that can > convince most of the people on this thread. Simply repeating the same > assertions over and over again, in a shrill fashion, is not likely to > convince those of us who that this would not be a good idea for git > v2.0. > > Creating a ~/.gitconfig file if one doesn't already is one I agree > with, and at least on Unix systems, telling them that the config file > lives in ~/.gitconfig, or where ever it might happen to be on other > platforms, is a good one. If it's in some really weird place on > Windows, then sure, we can tell them about "git config -e". But the > point is to let the user look at the default .gitconfig file, where we > can put in comments to help explain what is going on, and perhaps have > links to web pages for more information. > > I don't even think we need to query the user to fill out all of the > fields. We can prepopulate a lot of the fields (name, e-mail address, > etc.) from OS specific defaults that are available on most systems --- > specifically, the default values we would use the name and e-mail > address are not specified in a config file. > > We can just tell the user that we have created a default .gitconfig > file, and tell them how they can take a look at it. > > In the long term, if the worry is how to bridge the gap between > complete newbies, one way of dealing with this is to have a tutorial > mode (off by default, on in the default .gitconfig) which despenses > some helpful hints at certain strategic points (i.e., after five > commits, give a message that introduces git log --oneline, after the > third merge commit is created by the user, give a message which > introduces git log --merge, and so on). The challenge is not strawing > over the line to the point where the hints become as annoying as > "clippy", but that is what UX labs are for, to tune the experience for > completely new users to git. > > Without doing a formal UX experiment, all of us are going to making > assertions without formal evidence --- at best some of us who have > tutored a few newbies might have some anecdates, but remember the old > saying about the plural of anecdote not being data. > > Cheers, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote: > > There is evidence for the claim that there won't be those problems. You have > absolutely no evidence there there will. Felipe, It's clear that you've not been able to produce evidence that can convince most of the people on this thread. Simply repeating the same assertions over and over again, in a shrill fashion, is not likely to convince those of us who that this would not be a good idea for git v2.0. Creating a ~/.gitconfig file if one doesn't already is one I agree with, and at least on Unix systems, telling them that the config file lives in ~/.gitconfig, or where ever it might happen to be on other platforms, is a good one. If it's in some really weird place on Windows, then sure, we can tell them about "git config -e". But the point is to let the user look at the default .gitconfig file, where we can put in comments to help explain what is going on, and perhaps have links to web pages for more information. I don't even think we need to query the user to fill out all of the fields. We can prepopulate a lot of the fields (name, e-mail address, etc.) from OS specific defaults that are available on most systems --- specifically, the default values we would use the name and e-mail address are not specified in a config file. We can just tell the user that we have created a default .gitconfig file, and tell them how they can take a look at it. In the long term, if the worry is how to bridge the gap between complete newbies, one way of dealing with this is to have a tutorial mode (off by default, on in the default .gitconfig) which despenses some helpful hints at certain strategic points (i.e., after five commits, give a message that introduces git log --oneline, after the third merge commit is created by the user, give a message which introduces git log --merge, and so on). The challenge is not strawing over the line to the point where the hints become as annoying as "clippy", but that is what UX labs are for, to tune the experience for completely new users to git. Without doing a formal UX experiment, all of us are going to making assertions without formal evidence --- at best some of us who have tutored a few newbies might have some anecdates, but remember the old saying about the plural of anecdote not being data. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Wed, 23 Apr 2014 22:35:55 +, Felipe Contreras wrote: ... > Anyway, if you disagree change one of your frequently used passwords to a > chapter of The Lord of the Rings for a day. Let's see if you still think that. Proving that one extreme isn't the optimum doesn't prove the other is. Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras writes: > David Kastrup wrote: >> Felipe Contreras writes: >> >> > James Denholm wrote: >> >> Felipe Contreras wrote: >> >> >This is a false dichotomy; there aren't just two kinds >> >> > of Git users. >> >> > >> >> > There is such a category of Git users who are not >> >> > fresh-out-of-the-boat, yet not power users either. >> >> >> >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are >> >> the >> >> two groups (I suggest) are the most immediately relevant - one calls for >> >> change, and the other would be negatively impacted. >> > >> > Nobody would be negatively impacted. Who would be impacted negatively >> > by having default aliases? >> >> The people having to read and understand scripts written in the >> expectation of default aliases. > > Which are imaginary. And I prefer them to stay that way since then one does not need to worry about them. >> > And I have showed they are not problems. >> >> You managed to convince yourself, so feel free to put aliases in >> every Git you use and distribute. > > There is evidence for the claim that there won't be those > problems. You have absolutely no evidence there there will. As I said: you managed to convince yourself and may milk that for all that it's worth. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Kastrup wrote: > Felipe Contreras writes: > > > James Denholm wrote: > >> Felipe Contreras wrote: > >> >This is a false dichotomy; there aren't just two kinds > >> > of Git users. > >> > > >> > There is such a category of Git users who are not > >> > fresh-out-of-the-boat, yet not power users either. > >> > >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the > >> two groups (I suggest) are the most immediately relevant - one calls for > >> change, and the other would be negatively impacted. > > > > Nobody would be negatively impacted. Who would be impacted negatively > > by having default aliases? > > The people having to read and understand scripts written in the > expectation of default aliases. Which are imaginary. > > And I have showed they are not problems. > > You managed to convince yourself, so feel free to put aliases in every > Git you use and distribute. There is evidence for the claim that there won't be those problems. You have absolutely no evidence there there will. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras writes: > James Denholm wrote: >> Felipe Contreras wrote: >> >This is a false dichotomy; there aren't just two kinds >> > of Git users. >> > >> > There is such a category of Git users who are not >> > fresh-out-of-the-boat, yet not power users either. >> >> Oh, I didn't mean to suggest a dichotomy of any kind. However these are the >> two groups (I suggest) are the most immediately relevant - one calls for >> change, and the other would be negatively impacted. > > Nobody would be negatively impacted. Who would be impacted negatively > by having default aliases? The people having to read and understand scripts written in the expectation of default aliases. > And I have showed they are not problems. You managed to convince yourself, so feel free to put aliases in every Git you use and distribute. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
James Denholm wrote: > Felipe Contreras wrote: > >This is a false dichotomy; there aren't just two kinds > > of Git users. > > > > There is such a category of Git users who are not > > fresh-out-of-the-boat, yet not power users either. > > Oh, I didn't mean to suggest a dichotomy of any kind. However these are the > two groups (I suggest) are the most immediately relevant - one calls for > change, and the other would be negatively impacted. Nobody would be negatively impacted. Who would be impacted negatively by having default aliases? > > Unless the aliases are already there by default. > > Others, with knowledge far beyond mine, have pointed out the problems > with this. And I have showed they are not problems. > I'd suggest the argument most relevant to my own statements is how it impacts > the learning proccess, and makes it more likely that users will learn aliases > _as_ commands, which of course is incorrect and potentially harmful. That is an assumption. Why would a user think 'co' is a command? > > And if default aliases were such a bad idea, why do most (all?) version > > control systems out there have them? > > I'm so tempted just to sass and say that it's because they aren't git... > > But on a more serious note, a feature (any feature) being in one vcs doesn't > mean, by default, that it's right for git. How is Git different from any other version control systems? Commands are commands. > The status quo may be a mistake on the part of it's followers. Yes, it might, but it's not. > (And, historically, has been many times - for an transculturally-acceptable > example, consider the rejection of Galileo's astronomical research by the > Vatican of the time.) Yes, I'm perfecly aware that everybody _can_ be wrong, that doesn't mean they _are_. > Just because Mercurial et. all does something doesn't mean git needs to, or > even should. It needs objective consideration, not to just be ushered through > on the basis of tradition. Again, this is a red herring. Nobody argued that Git should do this because others are doing it. You failed to answer the question, so I'm asking it again: If default aliases were such a bad idea, why do most (all?) version control systems out there have them? Your answer seems to be along the lines of: they made a mistake and they are all wrong. Is it? But, surely if it's a mistake on their part you should be able to find people affected by this horrible error. This would validate the arguments that others have put forward; if we do X we will have problem Y. Well, other projects have done X, do they have problem Y? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras wrote: >This is a false dichotomy; there aren't just two kinds > of Git users. > > There is such a category of Git users who are not > fresh-out-of-the-boat, yet not power users either. Oh, I didn't mean to suggest a dichotomy of any kind. However these are the two groups (I suggest) are the most immediately relevant - one calls for change, and the other would be negatively impacted. > Unless the aliases are already there by default. Others, with knowledge far beyond mine, have pointed out the problems with this. I'd suggest the argument most relevant to my own statements is how it impacts the learning proccess, and makes it more likely that users will learn aliases _as_ commands, which of course is incorrect and potentially harmful. > And if default aliases were such a bad idea, why do most (all?) version control systems out there > have them? I'm so tempted just to sass and say that it's because they aren't git... But on a more serious note, a feature (any feature) being in one vcs doesn't mean, by default, that it's right for git. The status quo may be a mistake on the part of it's followers. (And, historically, has been many times - for an transculturally-acceptable example, consider the rejection of Galileo's astronomical research by the Vatican of the time.) Just because Mercurial et. all does something doesn't mean git needs to, or even should. It needs objective consideration, not to just be ushered through on the basis of tradition. -- James Denholm -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras writes: > David Kastrup wrote: > >> Life's hardness is not proportional to the number of typed characters > > It is. Why do you think people set aliases? To make their life harder? > > Anyway, if you disagree change one of your frequently used passwords > to a chapter of The Lord of the Rings for a day. Let's see if you > still think that. See? You made your life easier by typing a lot of hogwash, saving yourself the effort of finding a compelling argument. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
James Denholm wrote: > Felipe Contreras wrote: > > It is when they start to use Git seriously and type them a lot. > > Felipe, I think you refute your own point here, because people _learning_ git > aren't power-users. They might be one day, but not that day. If power-users > are complaining that "commit" is too long, but aren't setting their own > aliases, This is a false dichotomy; there aren't just two kinds of Git users. There is such a category of Git users who are not fresh-out-of-the-boat, yet not power users either. > it's quite possible they just don't know about aliases. Because if they > _did_ know about aliases, they'd set one. Unless the aliases are already there by default. And if default aliases were such a bad idea, why do most (all?) version control systems out there have them? -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras wrote: >>David Lang wrote: >> agreed, of all the things that people complain about regarding learning git, >> the fact that the commands are words instead of cryptic 2 letter >> abberviations is not one of them. >It is when they start to use Git seriously and type them a lot. Felipe, I think you refute your own point here, because people _learning_ git aren't power-users. They might be one day, but not that day. If power-users are complaining that "commit" is too long, but aren't setting their own aliases, it's quite possible they just don't know about aliases. Because if they _did_ know about aliases, they'd set one. Even a shell alias, not nessecarily a git alias. I submit to you (with the backing of all my prior experience contributing to git... Which is too say none) that the problem is not that git has a single, good, obvious and memorable commit command. The problem is that those specific power-users don't know to use aliases. -- James Denholm -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Lang wrote: > On Wed, 23 Apr 2014, Felipe Contreras wrote: > > > David Lang wrote: > >> agreed, of all the things that people complain about regarding learning > >> git, > >> the fact that the commands are words instead of cryptic 2 letter > >> abberviations is not one of them. > > > > It is when they start to use Git seriously and type them a lot. > > If that was such a significant factor, nobody would use Java with it's > horribly > long function names. There are these things called IDE's where people don't end up typing the whole function names. Take a look. > People are far more bothered about all the switches to remember and the > options > for them than they are the fact that they have to type entire words. This is, again, a red herring. The fact that B is more important doesn't mean A shouldn't be done. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Wed, 23 Apr 2014, Felipe Contreras wrote: David Lang wrote: agreed, of all the things that people complain about regarding learning git, the fact that the commands are words instead of cryptic 2 letter abberviations is not one of them. It is when they start to use Git seriously and type them a lot. If that was such a significant factor, nobody would use Java with it's horribly long function names. People are far more bothered about all the switches to remember and the options for them than they are the fact that they have to type entire words. David Lang The complaints tend to be far more about how there are inconsistancies between commands, or they don't understand what's happening. Yes, but you don't see anybody trying to improve those, do you? This is low-hanging fruit we can actually change. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Lang wrote: > agreed, of all the things that people complain about regarding learning git, > the fact that the commands are words instead of cryptic 2 letter > abberviations is not one of them. It is when they start to use Git seriously and type them a lot. > The complaints tend to be far more about how there are inconsistancies > between commands, or they don't understand what's happening. Yes, but you don't see anybody trying to improve those, do you? This is low-hanging fruit we can actually change. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Kastrup wrote: > Felipe Contreras writes: > > > Theodore Ts'o wrote: > > > >> This is especially true for commands which might not be used as often > >> -- e.g., "rebase", and for commands where the meaning of "git commit" > >> without any argument is qualitatively different from what "ci" (for > >> checkin) means in most other source management systems. > > > > ci means commit in Mercurial. > > Does it mean "commit the staging area"? It means "hg commit". > > It would help when the user starts to think "Geez, I seem to be typing > > `git checkout` an awful lot, I wonder if there's a shortcut", which if > > the .gitconfigs out there are any indication, it happens all the time. > > Actually, it happens very rarely if you are talking about _real_ > gitconfigs deployed by projects as compared to _sample_ gitconfigs > demonstrating Git features for _personal_ rather than project-wide use. There's no such thing as gitconfigs deployed by projects, and if there were they would be irrelevant. We are talking about *people* using Git's command line interface, and people have *personal* configs, that's it. And it's only those configs we have access to, and the only sources of information we have to make a guess if users ask the question "Geez, I seem to be typing `git checkout` an awful lot, I wonder if there's a shortcut". > >> And for a command like "rebase" where the user can very easily shoot > >> themselves in the foot to begin with, I'd actually suggest that it's > >> a _good_ thing that they have to type it out in full. > > > > And now you contradict yourself; you actually want to make life harder > > for new users, on purpose. > > Life's hardness is not proportional to the number of typed characters It is. Why do you think people set aliases? To make their life harder? Anyway, if you disagree change one of your frequently used passwords to a chapter of The Lord of the Rings for a day. Let's see if you still think that. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Junio C Hamano wrote: > Junio C Hamano writes: > > > I am not fundamentally opposed. I just do not think it would add > > much value to new people at this point, and it will actively hurt > > if we shoved barely cooked one in 2.0. > > > > A few thinking points that are necessary to be worked out, even > > before we start imagining a plan to introduce them, off the top of > > my head, are these: > > > > * Should we add many random aliases, or should we limit ourselves > >only to a narrow set that everybody can agree on? > > > > * What is the additional cognitive load do we feel comfortable > >burdening with the new users? > > > > * What is the exact mechanism to give these built-in aliases? > > > > Imagine that somebody says "[alias] ci = commit" and a handful of > > vocal people on this list agree that it is a good idea. Many random > > websites start mentioning "git ci -a" in their beginner examples. > > > > Users are led to think "ci" is a command just like "commit" and does > > the same thing and need to learn that only the > > first kind and not the second kind cannot be used to define their > > own alias (and the users need to learn "commit" at that time as > > well). > > A bit further on this point, looking into the future. > > It might help if we added some "introduction" phase to the first > invocation of "git init", "git clone", etc. that is interactively > run on a machine where there is no $HOME/.gitconfig detected, and > help the user populate it with a few selected and uncontroversial > ones. Such a session might go like this: > > $ git init > ... We do not see $HOME/.gitconfig; using Git for the first time? We shouldn't say $HOME/.gitconfig, that's not user friendly, and it might not be accurate. Plus, we might prefer $XDG_CONFIG_HOME/.config/git/config. "There doesn't seem to be a Git user configuration." is enough. > >> Do you want us to add a few sample aliases to your configuration > file? > Y I don't see the point in asking this, just put them, the user can remove them if he doesn't want. > ... Done. You can further tweak $HOME/.gitconfig to suit > ... Git to your taste. Aagain not friendly. `git config --global --edit`. > And it would end up with something like this: > > $ cat $HOME/.gitconfig > [user] > name = <> > email = <> > [alias] > co = checkout > lg = log --oneline > > which can serve as an example the user can then tweak, without > giving any false impression that "co" is any more special than > whatever the user adds as a custom alias. You are assuming the user wanted to "further tweak", most likely he didn't, in which case he wouldn't have seen those aliases. It would be more friendly if the aliases are always there, then we can mention them in the documentation of the relevant commands. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Tue, 22 Apr 2014, Theodore Ts'o wrote: On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote: I am not fundamentally opposed. I just do not think it would add much value to new people at this point, and it will actively hurt if we shoved barely cooked one in 2.0. You are probably biased in that you've used Git far much more than the average user has (or future new users). I think Junio has a really strong point. If the goal is to make life easier for new users, allowing them to save a few keystrokes is probably not the most significant thing we can do. And we have to balance this with the additional cognitive load in remembering how a particular two character alias maps to the "real" command. This is especially true for commands which might not be used as often -- e.g., "rebase", and for commands where the meaning of "git commit" without any argument is qualitatively different from what "ci" (for checkin) means in most other source management systems. So I do think it's worth thinking about this very carefully. For certain, I would **not** recommend using shortcuts in example command sequences. If the user reads "git rebase" or "git cherry-pick" it means a lot more than if they see a series of apparent chicken scratches filled with things like "git rb", "git pi", "git st", etc. In fact, to be fair, you may be getting biased because you're used to using the two character shortcuts, so for you, of *course* "rb" and "pi" and "ci" make a lot of sense. But for someone who is starting from scratch, I really question how much it helps, and how much it might hurt, to see the two character shortcuts or even to have to remember the two character shortcuts. And for a command like "rebase" where the user can very easily shoot themselves in the foot to begin with, I'd actually suggest that it's a _good_ thing that they have to type it out in full. agreed, of all the things that people complain about regarding learning git, the fact that the commands are words instead of cryptic 2 letter abberviations is not one of them. The complaints tend to be far more about how there are inconsistancies between commands, or they don't understand what's happening. Adding a new inconsistancy, or changing words to abbreviations is a further barrier against new users, not an advantage for them. David Lang -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras writes: > Theodore Ts'o wrote: > >> This is especially true for commands which might not be used as often >> -- e.g., "rebase", and for commands where the meaning of "git commit" >> without any argument is qualitatively different from what "ci" (for >> checkin) means in most other source management systems. > > ci means commit in Mercurial. Does it mean "commit the staging area"? >> In fact, to be fair, you may be getting biased because you're used to >> using the two character shortcuts, so for you, of *course* "rb" and >> "pi" and "ci" make a lot of sense. > > I can't be biased to those because I don't use them, mine are one > character shortcuts. Which you created yourself, on your own responsibility. > And if that hypothesis was correct, why does Mercurial, Bazaar, > Subversion, CVS, and pretty much everything uses aliases? And why does > pretty much every .gitconfig has similar aliases? That would imply > that the whole world is biased. Most .profile files define aliases as well. Doing this on the user's initiative is harmless since it will not have its usage leak into scripts intended for use by others. > It would help when the user starts to think "Geez, I seem to be typing > `git checkout` an awful lot, I wonder if there's a shortcut", which if > the .gitconfigs out there are any indication, it happens all the time. Actually, it happens very rarely if you are talking about _real_ gitconfigs deployed by projects as compared to _sample_ gitconfigs demonstrating Git features for _personal_ rather than project-wide use. >> And for a command like "rebase" where the user can very easily shoot >> themselves in the foot to begin with, I'd actually suggest that it's >> a _good_ thing that they have to type it out in full. > > And now you contradict yourself; you actually want to make life harder > for new users, on purpose. Life's hardness is not proportional to the number of typed characters or APL would be the easiest programming language narrowly followed by Perl. Life does not become easier by lowering input redundancy until it becomes hard to tell apart from line noise. Keyboards are highly efficient input devices, or we would not be conversing in whole sentences in technical mailing lists but rather in telegraphy style. -- David Kastrup -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Matthieu Moy writes: > Felipe Contreras writes: > >> Why is not material for v2.0? Because you say so? Are you going to wait >> another >> ten years to introduce this to v3.0? > > There's no need to wait for a 3.0 to introduce this. If these would > be low-priority compared to user-defined aliases, there's no backward > compatibility issue, it can very well be a 2.1, or whatever number comes > after 2.0. I do not think the discussion has analysed the issue deeply enough for us to tell what the final proposal would look like, in order to judge what kind of issues, whether related to backward compatibility or not, are involved. My hunch is that this may not have to wait for a big version bump, but I am not sure about that at this point. Also I do not think 3.0 has to wait for ten years, either. We started discussing incompatible updates for 2.0 in earnest during the v1.8.2 timeframe, which was tagged mid-March 2013 with a release notes with a "B/c notes for 2.0" section, but IIRC the discussion of many of the "let's make things consistent (even if that means we have to break existing users), and devise ways to make the transtion for them as smooth as possible" changes that finally is going to happen in v2.0 have been in the works since the v1.7.x era (tagged late January 2012). While I do not want to rush things late in a cycle (notice how many topics are still cooking in 'next' and will continue to be in preparation for 2.1 right now), I do not think it is warranted to have a panic "3.0 will be ten years out, and we will miss the boat if we do not cram this in some shape into 2.0"---that kind of haste simply is not necessary. Even if we end up having to wait for 3.0, it will happen within two years max, if not earlier. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Theodore Ts'o wrote: > On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote: > > > I am not fundamentally opposed. I just do not think it would add > > > much value to new people at this point, and it will actively hurt > > > if we shoved barely cooked one in 2.0. > > > > You are probably biased in that you've used Git far much more than > > the average user has (or future new users). > > I think Junio has a really strong point. What is that point? > If the goal is to make life easier for new users, allowing them to save a few > keystrokes is probably not the most significant thing we can do. No, but it's *one* thing we can definetly do, and since we are not doing anything else, we might as well do this one thing. > And we have to balance this with the additional cognitive load in remembering > how a particular two character alias maps to the "real" command. What cognitive load? You don't *need* to remember the default aliases; you don't need to use them at all. > This is especially true for commands which might not be used as often -- > e.g., "rebase", and for commands where the meaning of "git commit" without > any argument is qualitatively different from what "ci" (for checkin) means in > most other source management systems. ci means commit in Mercurial. > So I do think it's worth thinking about this very carefully. For > certain, I would **not** recommend using shortcuts in example command > sequences. If the user reads "git rebase" or "git cherry-pick" it > means a lot more than if they see a series of apparent chicken > scratches filled with things like "git rb", "git pi", "git st", etc. Certainly, but that is orthogonal. > In fact, to be fair, you may be getting biased because you're used to > using the two character shortcuts, so for you, of *course* "rb" and > "pi" and "ci" make a lot of sense. I can't be biased to those because I don't use them, mine are one character shortcuts. And if that hypothesis was correct, why does Mercurial, Bazaar, Subversion, CVS, and pretty much everything uses aliases? And why does pretty much every .gitconfig has similar aliases? That would imply that the whole world is biased. > But for someone who is starting from scratch, I really question how much it > helps, and how much it might hurt, to see the two character shortcuts or even > to have to remember the two character shortcuts. Here you are talking from your own bias. It would help when the user starts to think "Geez, I seem to be typing `git checkout` an awful lot, I wonder if there's a shortcut", which if the .gitconfigs out there are any indication, it happens all the time. > And for a command like "rebase" where the user can very easily shoot > themselves in the foot to begin with, I'd actually suggest that it's a _good_ > thing that they have to type it out in full. And now you contradict yourself; you actually want to make life harder for new users, on purpose. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Junio C Hamano writes: > I am not fundamentally opposed. I just do not think it would add > much value to new people at this point, and it will actively hurt > if we shoved barely cooked one in 2.0. > > A few thinking points that are necessary to be worked out, even > before we start imagining a plan to introduce them, off the top of > my head, are these: > > * Should we add many random aliases, or should we limit ourselves >only to a narrow set that everybody can agree on? > > * What is the additional cognitive load do we feel comfortable >burdening with the new users? > > * What is the exact mechanism to give these built-in aliases? > > Imagine that somebody says "[alias] ci = commit" and a handful of > vocal people on this list agree that it is a good idea. Many random > websites start mentioning "git ci -a" in their beginner examples. > > Users are led to think "ci" is a command just like "commit" and does > the same thing and need to learn that only the > first kind and not the second kind cannot be used to define their > own alias (and the users need to learn "commit" at that time as > well). A bit further on this point, looking into the future. It might help if we added some "introduction" phase to the first invocation of "git init", "git clone", etc. that is interactively run on a machine where there is no $HOME/.gitconfig detected, and help the user populate it with a few selected and uncontroversial ones. Such a session might go like this: $ git init ... We do not see $HOME/.gitconfig; using Git for the first time? ... Let us ask a few questions to make your Git life more pleasant. >> What name do you want to appear on your commits? Sebastian Schuberth >> What email address do you want to appear on your commits? sschube...@gmail.com >> You record your commits as ... "Sebastian Schuberth ". >> OK? Y >> Do you want us to add a few sample aliases to your configuration file? Y ... Done. You can further tweak $HOME/.gitconfig to suit ... Git to your taste. And it would end up with something like this: $ cat $HOME/.gitconfig [user] name = <> email = <> [alias] co = checkout lg = log --oneline which can serve as an example the user can then tweak, without giving any false impression that "co" is any more special than whatever the user adds as a custom alias. But the need to make the set minimum and the need to carefully think things through are still there (Ted made a very good point about "rb", which I agree with). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Tue, Apr 22, 2014 at 02:23:18PM -0500, Felipe Contreras wrote: > > I am not fundamentally opposed. I just do not think it would add > > much value to new people at this point, and it will actively hurt > > if we shoved barely cooked one in 2.0. > > You are probably biased in that you've used Git far much more than > the average user has (or future new users). I think Junio has a really strong point. If the goal is to make life easier for new users, allowing them to save a few keystrokes is probably not the most significant thing we can do. And we have to balance this with the additional cognitive load in remembering how a particular two character alias maps to the "real" command. This is especially true for commands which might not be used as often -- e.g., "rebase", and for commands where the meaning of "git commit" without any argument is qualitatively different from what "ci" (for checkin) means in most other source management systems. So I do think it's worth thinking about this very carefully. For certain, I would **not** recommend using shortcuts in example command sequences. If the user reads "git rebase" or "git cherry-pick" it means a lot more than if they see a series of apparent chicken scratches filled with things like "git rb", "git pi", "git st", etc. In fact, to be fair, you may be getting biased because you're used to using the two character shortcuts, so for you, of *course* "rb" and "pi" and "ci" make a lot of sense. But for someone who is starting from scratch, I really question how much it helps, and how much it might hurt, to see the two character shortcuts or even to have to remember the two character shortcuts. And for a command like "rebase" where the user can very easily shoot themselves in the foot to begin with, I'd actually suggest that it's a _good_ thing that they have to type it out in full. - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Matthieu Moy wrote: > Felipe Contreras writes: > > > Why is not material for v2.0? Because you say so? Are you going to wait > > another > > ten years to introduce this to v3.0? > > There's no need to wait for a 3.0 to introduce this. If these would > be low-priority compared to user-defined aliases, there's no backward > compatibility issue, it can very well be a 2.1, or whatever number comes > after 2.0. Can it? I would like Junio to say so. Still, v2.0 is a better time for this. > > This is actually the perfect time to do it. > > Junio has just tagged a -rc for 2.0, so it's clearly too late to start > discussing new features for this particular release. And whose fault is that? I never saw any warning about the -rc tag, and I never saw any discussion about possible features missing in v2.0. Given that the next backward-incompatible release might be in a decade, I would have expected people to have put more thought into v2.0, but I guess the Git project is not really interested in progressive features. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Felipe Contreras writes: > Why is not material for v2.0? Because you say so? Are you going to wait > another > ten years to introduce this to v3.0? There's no need to wait for a 3.0 to introduce this. If these would be low-priority compared to user-defined aliases, there's no backward compatibility issue, it can very well be a 2.1, or whatever number comes after 2.0. > This is actually the perfect time to do it. Junio has just tagged a -rc for 2.0, so it's clearly too late to start discussing new features for this particular release. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Junio C Hamano wrote: > Sebastian Schuberth writes: > > > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote: > > > >>> If we don't standardize this now people will come up with their own > >>> definitions [1] [2] (and many others if you just search GitHub) which > >>> are again likely to differ (slightly), hindering interoperability. > >> > >> I am afraid that that ship has sailed long time ago, though. > > > > That's most likely true, but it does not get better by postponing this > > even more. > > As I already said: > > I think it might be OK to implement them as the lowest priority > fallback alias, so that '[alias] co = "user's definition"' > anywhere in the various configuration locations will override > it. I am a bit hesitant about adding start-up overhead, though. > Also I am not sure if people can agree with (1) a broadly wide > selection of aliases and (2) the actual definitions for them (I > am OK with "co === checkout" myself, but I'd rather not to even > think about my Git wasting cycles parsing extra configuration > items to support "br === branch" at all, for example). > > I am not fundamentally opposed. I just do not think it would add > much value to new people at this point, and it will actively hurt > if we shoved barely cooked one in 2.0. You are probably biased in that you've used Git far much more than the average user has (or future new users). > So even if we agree that it would be a good idea to have some > default fallback aliases, the set of such aliases we ship must be > limited to a set that everybody can agree on, both in the sense that > "adding alias XX is good" and also in the sense that "alias XX must > be defined as YY". > > As you allueded to, the Git userbase is a lot larger than it used to > be back in 2006, one alias, e.g. "[alias] br = branch", that is > reported as either useless or needed to be further tweaked by a > person on this list would mean that we would be either spending > unnecessary start-up cycles (for "useless" case) or adding cognitive > load of having to differente between "branch" and "br" (for "needs > further tweak" case) for thousands of users who would be better off > if we didn't have that specific alias. I think it's reasonable to follow these guidelines: 1) Each default alias should have two characters 2) Each default alias should map to a command without arguments 3) Each default alias be widely used in the wild This set matches the above: co = checkout ci = commit rb = rebase st = status br = branch dt = difftool mt = mergetool You might not like 'br', but there's tons of people already using that alias, so it's not "useless". I can go find links to many examples if you would like. > So while I understand the desire to have a bit more handholding and > am not fundamentally opposed to the desire, I am not optimistic that > an attempt to implement these "aliases" would result in a very > useful addition to the system, even if done after careful thought. The fact that you are not optimistic about it doesn't mean it's impossible. > In any case, this definitely is not a 2.0 material. I agree that it > would be good to start discussing it early (rather than later) if we > ever want to do such a change. Why is not material for v2.0? Because you say so? Are you going to wait another ten years to introduce this to v3.0? This is actually the perfect time to do it. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Sebastian Schuberth writes: > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote: > >>> If we don't standardize this now people will come up with their own >>> definitions [1] [2] (and many others if you just search GitHub) which >>> are again likely to differ (slightly), hindering interoperability. >> >> I am afraid that that ship has sailed long time ago, though. > > That's most likely true, but it does not get better by postponing this > even more. As I already said: I think it might be OK to implement them as the lowest priority fallback alias, so that '[alias] co = "user's definition"' anywhere in the various configuration locations will override it. I am a bit hesitant about adding start-up overhead, though. Also I am not sure if people can agree with (1) a broadly wide selection of aliases and (2) the actual definitions for them (I am OK with "co === checkout" myself, but I'd rather not to even think about my Git wasting cycles parsing extra configuration items to support "br === branch" at all, for example). I am not fundamentally opposed. I just do not think it would add much value to new people at this point, and it will actively hurt if we shoved barely cooked one in 2.0. A few thinking points that are necessary to be worked out, even before we start imagining a plan to introduce them, off the top of my head, are these: * Should we add many random aliases, or should we limit ourselves only to a narrow set that everybody can agree on? * What is the additional cognitive load do we feel comfortable burdening with the new users? * What is the exact mechanism to give these built-in aliases? Imagine that somebody says "[alias] ci = commit" and a handful of vocal people on this list agree that it is a good idea. Many random websites start mentioning "git ci -a" in their beginner examples. Users are led to think "ci" is a command just like "commit" and does the same thing. Some of them want to always commit everything before moving to their next task, and want to alias it further, e.g. "[alias] ci = ci -a"---which would not work. At that point, the users need to learn the distinction between native subcommands (e.g. "commit"), built-in fallback aliases (e.g. "ci") and aliases of their own in their ~/.gitconfig, and need to learn that only the first kind and not the second kind cannot be used to define their own alias (and the users need to learn "commit" at that time as well). That could be solved by making "ci" not a built-in fallback alias, but a new subcommand (then there is no "'foo' in 'git foo' could be a command or a built-in alias and they behave differently" issue), and additionally somehow allowing a native subcommand overriden by end-user alias, but I do not think anybody designed how such an override would work so far. So even if we agree that it would be a good idea to have some default fallback aliases, the set of such aliases we ship must be limited to a set that everybody can agree on, both in the sense that "adding alias XX is good" and also in the sense that "alias XX must be defined as YY". As you allueded to, the Git userbase is a lot larger than it used to be back in 2006, one alias, e.g. "[alias] br = branch", that is reported as either useless or needed to be further tweaked by a person on this list would mean that we would be either spending unnecessary start-up cycles (for "useless" case) or adding cognitive load of having to differente between "branch" and "br" (for "needs further tweak" case) for thousands of users who would be better off if we didn't have that specific alias. So while I understand the desire to have a bit more handholding and am not fundamentally opposed to the desire, I am not optimistic that an attempt to implement these "aliases" would result in a very useful addition to the system, even if done after careful thought. In any case, this definitely is not a 2.0 material. I agree that it would be good to start discussing it early (rather than later) if we ever want to do such a change. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Sebastian Schuberth wrote: > On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras > wrote: > > >> The problem is that between "git rm" and "git mv", if we default "git > >> cp" to mean "cherry-pick" there could easily be user confusion. > >> > >> I'm not sure that cherry-pick is used that often it really needs a two > >> character shortcut. Maybe just "git pick"? > > > > I'm in favor of having both 'git pick', and 'git pi'. > > Please let's stick to one clear default alias for some central > commands, and not introduce ambiguity between aliases. That said, I'd > prefer pick over pi, but still cp would be my personal favorite. I think porcelain commands should eventually change names (and maybe become more friendly) 'git ls-files' => 'git ls', 'git cherry-pick' => 'git pick', and so on. If 'cherry-pick' evolves into 'pick', it would make sense to have the 'pi' alias, and in preparation for that I don't see why a temporary 'pick' alias would hurt. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Sebastian Schuberth wrote: > On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote: > > >> If we don't standardize this now people will come up with their own > >> definitions [1] [2] (and many others if you just search GitHub) which > >> are again likely to differ (slightly), hindering interoperability. > > > > I am afraid that that ship has sailed long time ago, though. > > That's most likely true, but it does not get better by postponing this > even more. I still think there's value in introducing this now, Git > still attracts new developers every day. In fact, I currently see a > leap forwarding in the Windows world towards Git, caused by some > rethinking and structural changes in some big companies. Exactly. If one thinks in terms of years, sure, it might make sense to not change the status quo created by years back. But think about Git in a decade or two, at that point surely you would have wished that you had considered these kinds of changes sooner. Junio at some point suggested to think about features for v1.8.0 as if we were starting from scratch[1]. I'd say if there has every been a time to add default aliases after v1.0 it's certainly v2.0. Our future users who might have not touched Git yet would certainly welcome this. [1] http://article.gmane.org/gmane.comp.version-control.git/165735 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Mon, Apr 21, 2014 at 10:46 PM, Felipe Contreras wrote: >> The problem is that between "git rm" and "git mv", if we default "git >> cp" to mean "cherry-pick" there could easily be user confusion. >> >> I'm not sure that cherry-pick is used that often it really needs a two >> character shortcut. Maybe just "git pick"? > > I'm in favor of having both 'git pick', and 'git pi'. Please let's stick to one clear default alias for some central commands, and not introduce ambiguity between aliases. That said, I'd prefer pick over pi, but still cp would be my personal favorite. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Mon, Apr 21, 2014 at 9:39 PM, Junio C Hamano wrote: >> If we don't standardize this now people will come up with their own >> definitions [1] [2] (and many others if you just search GitHub) which >> are again likely to differ (slightly), hindering interoperability. > > I am afraid that that ship has sailed long time ago, though. That's most likely true, but it does not get better by postponing this even more. I still think there's value in introducing this now, Git still attracts new developers every day. In fact, I currently see a leap forwarding in the Windows world towards Git, caused by some rethinking and structural changes in some big companies. -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
David Aguilar wrote: > On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote: > > = Reject non-fast-forward pulls by default = > > > > Many new-comers end up making merges by mistake when they pull because > > they don't understand what is a non-fast-forward and what they should > > actually be doing. Most people, even Linus Torvalds, agreed that by > > default `git pull` should fail and guide the user, instead of silently > > making a merge which might not be what the user wants (even though he > > doesn't know it), and messing up the project's history, which affects > > other people. > > > > The patches were sent, the issues were addressed, people agreed, and > > yet nothing happened. > > We can currently set pull.ff = only to get this behavior. It is not the same behavior as my patch series, you get: fatal: Not possible to fast-forward, aborting. With that message we certainly cannot make it the default. In my patch series you get: The pull was not fast-forward, please either merge or rebase. If unsure, run 'git pull --merge'. > I would like it if this were the default (but I am biased). I don't know if you followed the discussion, but virtually everyone (including Linus) agreed this should be the default. > > = Use "stage" instead of "index" = > > I'm probably biased about this one too, but I should probably speak up. > > git-cola has used "Staged", "Modified", "Untracked", etc. since > the beginning of time. Sorry 'bout that, but it seemed like the > simplest word to use. > > I often hear users talking about "staging" files. > I'm probably in an echo chamber, but I never really had to > explain "the staging area" since the concept is pretty natural > when interacting with the GUI. Again, virtually everyone (except Junio) agrees. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
brian m. carlson wrote: > On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote: > > BTW, in my experience people tend to stick to predefined aliases instead of > > redefining them to something (completely) different. This means that having > > default aliases will very likely enable one to use the same short commands > > on one's colleague's PC (instead of you running into issues because the same > > alias was defined to a different command). > > > > If we don't standardize this now people will come up with their own > > definitions [1] [2] (and many others if you just search GitHub) which are > > again likely to differ (slightly), hindering interoperability. > > Unfortunately, that's already happened. Some people alias ci to commit, > and some people alias it to commit -a. There is literally no choice you > can make there that will make everyone happy. Of course we can: a) The people that have 'alias.co = git commit' will keep their alias b) The people that have 'alias.co = git commit -a' will keep their alias c) The people that haven't set alias.co, will get the default > If you provide default aliases, people will expect them to work > everywhere, and then be confused when they don't. This argument was already brought up, and already proved to be false. Mercurial allows not only to override the default alias, but to override the core commands, so you can alias 'hg push' to 'hg push --force'. According to your hypothesis people using Mercurial would get confused when basic commands work on certain machines and not others. This is not the case. I challenge you to find a single instance when people got confused because of the configured aliases. > It's much better to let people alias what they want on their own. I > understand the frustration of having to work on others' machines when they > don't have your aliases, because every time I type "git pff"[0] and it fails, > it drives me crazy, but there's just no sane defaults. Yes there are sane defaults. co = checkout ci = commit rb = rebase st = status br = branch dt = difftool mt = mergetool -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Sun, Apr 20, 2014 at 05:41:05PM -0500, Felipe Contreras wrote: > = Reject non-fast-forward pulls by default = > > Many new-comers end up making merges by mistake when they pull because > they don't understand what is a non-fast-forward and what they should > actually be doing. Most people, even Linus Torvalds, agreed that by > default `git pull` should fail and guide the user, instead of silently > making a merge which might not be what the user wants (even though he > doesn't know it), and messing up the project's history, which affects > other people. > > The patches were sent, the issues were addressed, people agreed, and > yet nothing happened. We can currently set pull.ff = only to get this behavior. I would like it if this were the default (but I am biased). > = Use "stage" instead of "index" = I'm probably biased about this one too, but I should probably speak up. git-cola has used "Staged", "Modified", "Untracked", etc. since the beginning of time. Sorry 'bout that, but it seemed like the simplest word to use. I often hear users talking about "staging" files. I'm probably in an echo chamber, but I never really had to explain "the staging area" since the concept is pretty natural when interacting with the GUI. Just my $.02. ciao, -- David -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Mon, Apr 21, 2014 at 09:24:33PM +0200, Sebastian Schuberth wrote: > BTW, in my experience people tend to stick to predefined aliases instead of > redefining them to something (completely) different. This means that having > default aliases will very likely enable one to use the same short commands > on one's colleague's PC (instead of you running into issues because the same > alias was defined to a different command). > > If we don't standardize this now people will come up with their own > definitions [1] [2] (and many others if you just search GitHub) which are > again likely to differ (slightly), hindering interoperability. Unfortunately, that's already happened. Some people alias ci to commit, and some people alias it to commit -a. There is literally no choice you can make there that will make everyone happy. If you provide default aliases, people will expect them to work everywhere, and then be confused when they don't. It's much better to let people alias what they want on their own. I understand the frustration of having to work on others' machines when they don't have your aliases, because every time I type "git pff"[0] and it fails, it drives me crazy, but there's just no sane defaults. [0] Aliased to git pull --ff-only. I probably run this at least twenty times a day. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: What is missing from Git v2.0
Theodore Ts'o wrote: > On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote: > > On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras > > wrote: > > > > > I have these aliases as well, except br => b, and cp => pi. 'br' is > > > probably > > > better, but not sure as 'cp' which can be confusing. > > > > If by confusing you refer to "cp" to copy files, that's actually what > > I like about it: cherry-pick is somewhat like copying commits, thus > > "cp" makes much sense to me. > > The problem is that between "git rm" and "git mv", if we default "git > cp" to mean "cherry-pick" there could easily be user confusion. > > I'm not sure that cherry-pick is used that often it really needs a two > character shortcut. Maybe just "git pick"? I'm in favor of having both 'git pick', and 'git pi'. > Personally, "git branch" and "git checkout" are finger macros that I > type very quickly, so creating two character alias probably wouldn't > save me that much time. But I do appreicate that there are folks for > which such aliases might be useful. I bet I can type 'g b' and 'g co' faster :) -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Mon, Apr 21, 2014 at 09:47:57PM +0200, Sebastian Schuberth wrote: > On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras > wrote: > > > I have these aliases as well, except br => b, and cp => pi. 'br' is probably > > better, but not sure as 'cp' which can be confusing. > > If by confusing you refer to "cp" to copy files, that's actually what > I like about it: cherry-pick is somewhat like copying commits, thus > "cp" makes much sense to me. The problem is that between "git rm" and "git mv", if we default "git cp" to mean "cherry-pick" there could easily be user confusion. I'm not sure that cherry-pick is used that often it really needs a two character shortcut. Maybe just "git pick"? Personally, "git branch" and "git checkout" are finger macros that I type very quickly, so creating two character alias probably wouldn't save me that much time. But I do appreicate that there are folks for which such aliases might be useful. - Ted -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Mon, Apr 21, 2014 at 9:34 PM, Felipe Contreras wrote: > I have these aliases as well, except br => b, and cp => pi. 'br' is probably > better, but not sure as 'cp' which can be confusing. If by confusing you refer to "cp" to copy files, that's actually what I like about it: cherry-pick is somewhat like copying commits, thus "cp" makes much sense to me. > FTR color.ui = true is not needed any more, also hopefully mergetool.prompt = > false wouldn't be either [1]. Thanks! -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Sebastian Schuberth wrote: > On 21.04.2014 00:41, Felipe Contreras wrote: > > > = Default aliases = > > > > Every single version control tool out there has default aliases (e.g. > > co = checkout) except Git. > > > > Every argument against default aliases was basically refuted, yet my > > patches went nowhere. And the users still expect these aliases. > > +1 about having default aliases in general, and I'd also add these: > > br = branch > cp = cherry-pick > dt = difftool > mt = mergetool I have these aliases as well, except br => b, and cp => pi. 'br' is probably better, but not sure as 'cp' which can be confusing. > BTW, in my experience people tend to stick to predefined aliases instead > of redefining them to something (completely) different. This means that > having default aliases will very likely enable one to use the same short > commands on one's colleague's PC (instead of you running into issues > because the same alias was defined to a different command). > > If we don't standardize this now people will come up with their own > definitions [1] [2] (and many others if you just search GitHub) which > are again likely to differ (slightly), hindering interoperability. > > [1] https://github.com/github/msysgit/pull/27 > [2] https://github.com/sschuberth/dev-scripts/blob/master/git/.gitconfig FTR color.ui = true is not needed any more, also hopefully mergetool.prompt = false wouldn't be either [1]. [1] http://article.gmane.org/gmane.comp.version-control.git/246601 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
Sebastian Schuberth writes: >> Every argument against default aliases was basically refuted, yet my >> patches went nowhere. And the users still expect these aliases. > > +1 about having default aliases in general, and I'd also add these: I think it might be OK to implement them as the lowest priority fallback alias, so that '[alias] co = "user's definition"' anywhere in the various configuration locations will override it. I am a bit hesitant about adding start-up overhead, though. Also I am not sure if people can agree with (1) a broadly wide selection of aliases and (2) the actual definitions for them (I am OK with "co === checkout" myself, but I'd rather not to even think about my Git wasting cycles parsing extra configuration items to support "br === branch" at all, for example). If we squat on "co" and other short-and-sweet friends by adding them as built-in aliases (i.e by adding them to git.c:commands[]), the only effect would be to annoy people who have them defined somewhat slightly differently, so that won't fly well. > If we don't standardize this now people will come up with their own > definitions [1] [2] (and many others if you just search GitHub) which > are again likely to differ (slightly), hindering interoperability. I am afraid that that ship has sailed long time ago, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On 21.04.2014 00:41, Felipe Contreras wrote: = Default aliases = Every single version control tool out there has default aliases (e.g. co = checkout) except Git. Every argument against default aliases was basically refuted, yet my patches went nowhere. And the users still expect these aliases. +1 about having default aliases in general, and I'd also add these: br = branch cp = cherry-pick dt = difftool mt = mergetool BTW, in my experience people tend to stick to predefined aliases instead of redefining them to something (completely) different. This means that having default aliases will very likely enable one to use the same short commands on one's colleague's PC (instead of you running into issues because the same alias was defined to a different command). If we don't standardize this now people will come up with their own definitions [1] [2] (and many others if you just search GitHub) which are again likely to differ (slightly), hindering interoperability. [1] https://github.com/github/msysgit/pull/27 [2] https://github.com/sschuberth/dev-scripts/blob/master/git/.gitconfig -- Sebastian Schuberth -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What is missing from Git v2.0
On Sun, Apr 20, 2014 at 5:41 PM, Felipe Contreras wrote: > [3] http://thread.gmane.org/gmane.comp.version-control.git/240030 > [4] http://thread.gmane.org/gmane.comp.version-control.git/235981 Actually: [3] http://thread.gmane.org/gmane.comp.version-control.git/233554 [4] http://thread.gmane.org/gmane.comp.version-control.git/234295 -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html