Re: [PATCH v3] build: add default aliases
Junio C Hamano wrote: > Felipe Contreras writes: > > > Junio C Hamano wrote: > >> Jeff King writes: > >> > >> > It seems[1] that some > >> > people define "ci" as "commit -a", and some people define "st" as > >> > "status -s" or even "status -sb". > >> > >> These option variants aside. > >> > >> Just like thinking that committing must be the same as publishing, > >> it is a cvs/svn induced braindamage to think that "checking in" must > >> be the same as "committing". The former is a sign of not > >> understanding the "distributed", the latter "the index". > >> > >> In a world with both check-in and commit as two words usable to > >> denote possibly different concepts, it may make sense to say "you > >> check-in the current status of the working tree files into the > >> index, in order to make commits out of it later". > > > > Yet a wide amount of users do use 'ci' to mean 'commit', so basically they > > are > > just wrong. So you are saying they are just ignorant. > > I am sick of seeing my word twisted, especially when they were not > even addressed to you (see the message's primary recipients list). When you send messages to a public mailing list, even if not addressed to that mailing list, is with the expectation that other people in that mailing list will reply. When you say something is a sign of not understanding, that means ignorance, and there's nothing bad about that, we are all ignorant about many things. > Those who want to type "git ci" due to their familiarity with "svn > ci" are not wrong; they can do so if they choose. I never suggested they were wrong, you suggested they were ignorant. And this is being used by you as reason *not* to use ci as an alias for commit by default. > > Now, if you are commenting on the aliases, that would mean you are not > > against > > the idea of aliaes per se, but more about values of those aliases. So if we > > agreed on the right values, you would welcome this patch. > > > > Is that correct? > > No. > > I agree with the issue the message I was replying to raised. The > alias mechanism is a way to help users to define their own > convenient short-cut. If you want to say "git ci" to mean "git > commit" (and not "git commit -a" or something else), define it for > your own use, and stop there, without getting in the way of other > people. A set of default aliases doesn't get in the way of other people either. That's why all VCS tools have them, and none of them have a problem. > That is why I see an attempt to add hard-coded set of aliases as a move in > the wrong direction. They are not hard-coded, they are configurable. > A set of hard-coded alias that _officially_ declares that "checkin" > is an equivalent to "commit" has another issue. No. Nobody said anything about check-in, it's ci, which could be CommIt. And you are conveniently ignoring all the other possible aliases for commit. > It will close the door for us to later add "git checkin" that may mean > something different from "git commit", and that is another reason why I do > not agree with the patch under discussion in this thread. A "checkin" that is > an operation that checks-in the current contents to the index is one example > of an action other than committing that the word may make sense for, because > "git checkout README.txt" is about checking out of the index, its logical > opposite "checkin" could be about checking into the index. Nobody said anything about a check-in. This is a red herring. Absolultely nothing you have said in this second half has anything to do with the question I asked. I asked specifically about the idea of aliases, independently of their actual values, and all you have done is argue against the value of a single alias: ci. -- 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: [PATCH v3] build: add default aliases
Felipe Contreras writes: > Junio C Hamano wrote: >> Jeff King writes: >> >> > It seems[1] that some >> > people define "ci" as "commit -a", and some people define "st" as >> > "status -s" or even "status -sb". >> >> These option variants aside. >> >> Just like thinking that committing must be the same as publishing, >> it is a cvs/svn induced braindamage to think that "checking in" must >> be the same as "committing". The former is a sign of not >> understanding the "distributed", the latter "the index". >> >> In a world with both check-in and commit as two words usable to >> denote possibly different concepts, it may make sense to say "you >> check-in the current status of the working tree files into the >> index, in order to make commits out of it later". > > Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are > just wrong. So you are saying they are just ignorant. I am sick of seeing my word twisted, especially when they were not even addressed to you (see the message's primary recipients list). Those who want to type "git ci" due to their familiarity with "svn ci" are not wrong; they can do so if they choose. Let's try again (see below). > Now, if you are commenting on the aliases, that would mean you are not against > the idea of aliaes per se, but more about values of those aliases. So if we > agreed on the right values, you would welcome this patch. > > Is that correct? No. I agree with the issue the message I was replying to raised. The alias mechanism is a way to help users to define their own convenient short-cut. If you want to say "git ci" to mean "git commit" (and not "git commit -a" or something else), define it for your own use, and stop there, without getting in the way of other people. That is why I see an attempt to add hard-coded set of aliases as a move in the wrong direction. A set of hard-coded alias that _officially_ declares that "checkin" is an equivalent to "commit" has another issue. It will close the door for us to later add "git checkin" that may mean something different from "git commit", and that is another reason why I do not agree with the patch under discussion in this thread. A "checkin" that is an operation that checks-in the current contents to the index is one example of an action other than committing that the word may make sense for, because "git checkout README.txt" is about checking out of the index, its logical opposite "checkin" could be about checking into the index. -- 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: [PATCH v3] build: add default aliases
Junio C Hamano wrote: > Jeff King writes: > > > It seems[1] that some > > people define "ci" as "commit -a", and some people define "st" as > > "status -s" or even "status -sb". > > These option variants aside. > > Just like thinking that committing must be the same as publishing, > it is a cvs/svn induced braindamage to think that "checking in" must > be the same as "committing". The former is a sign of not > understanding the "distributed", the latter "the index". > > In a world with both check-in and commit as two words usable to > denote possibly different concepts, it may make sense to say "you > check-in the current status of the working tree files into the > index, in order to make commits out of it later". Yet a wide amount of users do use 'ci' to mean 'commit', so basically they are just wrong. So you are saying they are just ignorant. Personally I don't care if it's 'ci', or 'co', or 'cm', or 'ct'. I just want/need a shortcut, then I can train my fingers to type that. If you have a better alias than 'ci', then by all means, throw away your suggestion. Now, if you are commenting on the aliases, that would mean you are not against the idea of aliaes per se, but more about values of those aliases. So if we agreed on the right values, you would welcome this patch. Is that correct? -- 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: [PATCH v3] build: add default aliases
Jeff King writes: > It seems[1] that some > people define "ci" as "commit -a", and some people define "st" as > "status -s" or even "status -sb". These option variants aside. Just like thinking that committing must be the same as publishing, it is a cvs/svn induced braindamage to think that "checking in" must be the same as "committing". The former is a sign of not understanding the "distributed", the latter "the index". In a world with both check-in and commit as two words usable to denote possibly different concepts, it may make sense to say "you check-in the current status of the working tree files into the index, in order to make commits out of it later". -- 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: [PATCH v3] build: add default aliases
On Tue, Oct 1, 2013 at 2:33 AM, Jonathan Nieder wrote: > Michael Haggerty wrote: > >> That being said, independent of aliases, there are many other config >> settings that can affect commands that might be used in documentation or >> scripts, and which also could be the source of errors for the non-vigilent. > > Yep, this is a problem, too (I'm looking at you, "git push"). We try > to avoid this problem or balance it against convenience by being > careful when adding new configuration, but sometimes we slip up. I think the problem is we start pushing too much on the porcelain front and forget about plumbing. "git push" is for human, but I don't think there's an equivalent for scripts. "git branch --list" vs "git for-each-ref" is a good example. -- Duy -- 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: [PATCH v3] build: add default aliases
Michael Haggerty wrote: > That being said, independent of aliases, there are many other config > settings that can affect commands that might be used in documentation or > scripts, and which also could be the source of errors for the non-vigilent. Yep, this is a problem, too (I'm looking at you, "git push"). We try to avoid this problem or balance it against convenience by being careful when adding new configuration, but sometimes we slip up. Thanks for your thoughtfulness. Sincerely, 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: [PATCH v3] build: add default aliases
On Sat, Sep 28, 2013 at 10:18 PM, Michael Haggerty wrote: > On 09/29/2013 12:41 AM, Felipe Contreras wrote: >> On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder wrote: On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: > For now simply add a few common aliases. > > co = checkout > ci = commit > rb = rebase > st = status [...] >> >>> But making 'ci' a synonym of another command by default while still >>> keeping its definition configurable would be doing people a >>> disservice, I fear. >> >> And I and many (most) users disagree. >> >>> As long as 'ci' works out of the box, it will >>> start showing up in examples and used in suggestions over IRC, etc, >>> which is great. > > ...and in scripts. > >> It might, or... >> >>> Unfortunately that means that anyone who has 'ci' >>> defined to mean something different can no longer use those examples, >>> that advice from IRC, and so on. So in the world where 'ci' is a >>> synonym for 'commit' by default, while people still *can* redefine >>> 'ci' to include whatever options they like (e.g., "-a"), actually >>> carrying out such a personal customization is asking for trouble. >> >> Precisely for this reason it might not. If people know aliases can be >> different in different machines, they would avoid them in >> documentation which is meant for all machines. > > My experience contradicts your prediction. I have 'ci'/'co' aliases in > my own configuration. But even though I am aware of the fact that other > people might not have the same aliases, I have on multiple occasions > used them in documentation and/or scripts meant for other people. The > muscle memory is just too strong. If you are already making that error, then this patch wouldn't make it any worst. In fact, it would make the situation better. If previously you had 10 persons complaining about the "ci" command not working, now 9 of them wouldn't complain because "git ci" does actually work, even if you have aliased it to something slightly different, like "commit -v". Instead, you would have 1 person complaining, because he has a different alias, which makes the command fail somehow. In reality, that 1 person might not even exist. The solution before and after my patch is the same; avoid the 'ci'/'co' aliases. > My error was discovered by other people who didn't have those aliases. And after this patch it still will. > If *most* people had the same aliases as I did, and others had defined > their own slightly different ones, then the scripts would have subtly > malfunctioned for the latter set of users and I would have had trouble > reproducing the errors. Doubtful. But a warning that a default alias is being used, or simply showing the actual command in the standard output would fix the problem. It certainly looks like you are not even looking for solutions for the hypothetical problems you put forward. > So, even though I think such aliases are a great convenience factor, I > am -0 on including pre-defined but overrideable aliases and -1 on > including pre-defined and non-overrideable aliases. And still, somehow every other VCS out there manages default aliases just fine, and Mercurial even allows overriding commands. How do you explain that the world hasn't ended for 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: [PATCH v3] build: add default aliases
On 09/29/2013 12:41 AM, Felipe Contreras wrote: > On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder wrote: >>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: For now simply add a few common aliases. co = checkout ci = commit rb = rebase st = status >>> >>> [...] > >> But making 'ci' a synonym of another command by default while still >> keeping its definition configurable would be doing people a >> disservice, I fear. > > And I and many (most) users disagree. > >> As long as 'ci' works out of the box, it will >> start showing up in examples and used in suggestions over IRC, etc, >> which is great. ...and in scripts. > It might, or... > >> Unfortunately that means that anyone who has 'ci' >> defined to mean something different can no longer use those examples, >> that advice from IRC, and so on. So in the world where 'ci' is a >> synonym for 'commit' by default, while people still *can* redefine >> 'ci' to include whatever options they like (e.g., "-a"), actually >> carrying out such a personal customization is asking for trouble. > > Precisely for this reason it might not. If people know aliases can be > different in different machines, they would avoid them in > documentation which is meant for all machines. My experience contradicts your prediction. I have 'ci'/'co' aliases in my own configuration. But even though I am aware of the fact that other people might not have the same aliases, I have on multiple occasions used them in documentation and/or scripts meant for other people. The muscle memory is just too strong. My error was discovered by other people who didn't have those aliases. If *most* people had the same aliases as I did, and others had defined their own slightly different ones, then the scripts would have subtly malfunctioned for the latter set of users and I would have had trouble reproducing the errors. That being said, independent of aliases, there are many other config settings that can affect commands that might be used in documentation or scripts, and which also could be the source of errors for the non-vigilent. So, even though I think such aliases are a great convenience factor, I am -0 on including pre-defined but overrideable aliases and -1 on including pre-defined and non-overrideable aliases. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.com/ -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 1:39 PM, Jonathan Nieder wrote: > Jeff King wrote: >> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: > >>> For now simply add a few common aliases. >>> >>> co = checkout >>> ci = commit >>> rb = rebase >>> st = status >> >> Are these the best definitions of those shortcuts? It seems[1] that some >> people define "ci" as "commit -a", and some people define "st" as >> "status -s" or even "status -sb". > > I feel bad about having waited for 4 rounds of this patch to say this, > but the basic change (providing "co", "ci", etc. as aliases by > default) does not look well thought through. To you. > It would be a different story if this were a patch to update > documentation to suggest adding such aliases at the same time as > telling Git what your name is. The user manual doesn't explain how to > set up aliases at all yet, and that should be fixed. That's a completely different subject. > But making 'ci' a synonym of another command by default while still > keeping its definition configurable would be doing people a > disservice, I fear. And I and many (most) users disagree. > As long as 'ci' works out of the box, it will > start showing up in examples and used in suggestions over IRC, etc, > which is great. It might, or... > Unfortunately that means that anyone who has 'ci' > defined to mean something different can no longer use those examples, > that advice from IRC, and so on. So in the world where 'ci' is a > synonym for 'commit' by default, while people still *can* redefine > 'ci' to include whatever options they like (e.g., "-a"), actually > carrying out such a personal customization is asking for trouble. Precisely for this reason it might not. If people know aliases can be different in different machines, they would avoid them in documentation which is meant for all machines. If you truly want to be pedantic, you could add a warning if the default alias is not used, and this warning gets silenced if the user configures the alias manually. > Incidentally, that is also the reason git already doesn't allow > aliases to override built-in commands such as "git commit", even > though it would be convenient to some to not have to remember to add > "-a" each time. As consolation we have been able to say "But you can > take the even shorter-and-sweeter 'git ci' and make it mean whatever > you want". Now we should take that avenue away for people? Who is taking away that avenue? Certainly not this patch. > Bad idea. Only if you assume your hypothesis is a fact, which is not, and even if you do, it's still not. > Hope that helps, The project? No, it doesn't. Virtually every VCS out there has default aliases, and Git somehow cannot manage to get them done. And BTW, look what I can do in mercurial: .hgrc --- [alias] status = status --all --- OMG! The world is going to end! No, it's not, it's no problem. What you think is so clearly a bad idea, seems to be doing just fine in Mercurial. -- 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: [PATCH v3] build: add default aliases
On Wed, Sep 25, 2013 at 11:05 AM, Matthieu Moy wrote: > Felipe Contreras writes: > >> Last time I checked nothing has changed, the default remains >> push.default=matching. > > LOL. I'd take that as an admission that you don't have any examples of important changes in the past two years, at least. -- 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: [PATCH v3] build: add default aliases
Felipe Contreras writes: > Last time I checked nothing has changed, the default remains > push.default=matching. LOL. -- 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: [PATCH v3] build: add default aliases
On Wed, Sep 25, 2013 at 10:13 AM, Matthieu Moy wrote: > Felipe Contreras writes: > >> On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy >> wrote: >>> Felipe Contreras writes: >>> But let me help you; you can't mention one, because there isn't any. >>> >>> Or because you didn't really look. Read the release notes of every Git >>> release these days, there's a big section about ongoing backward >>> incompatible changes. >> >> I said *important* changes from the common user's point of view. > > Call me fool, but I do consider the default behavior of "git push" as > something important, indeed. Last time I checked nothing has changed, the default remains push.default=matching. -- 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: [PATCH v3] build: add default aliases
Felipe Contreras writes: > On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy > wrote: >> Felipe Contreras writes: >> >>> But let me help you; you can't mention one, because there isn't any. >> >> Or because you didn't really look. Read the release notes of every Git >> release these days, there's a big section about ongoing backward >> incompatible changes. > > I said *important* changes from the common user's point of view. Call me fool, but I do consider the default behavior of "git push" as something important, indeed. -- 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: [PATCH v3] build: add default aliases
On Wed, Sep 25, 2013 at 9:55 AM, Matthieu Moy wrote: > Felipe Contreras writes: > >> But let me help you; you can't mention one, because there isn't any. > > Or because you didn't really look. Read the release notes of every Git > release these days, there's a big section about ongoing backward > incompatible changes. I said *important* changes from the common user's point of view. -- 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: [PATCH v3] build: add default aliases
Felipe Contreras writes: > But let me help you; you can't mention one, because there isn't any. Or because you didn't really look. Read the release notes of every Git release these days, there's a big section about ongoing backward incompatible changes. -- 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: [PATCH v3] build: add default aliases
n On Wed, Sep 25, 2013 at 8:33 AM, John Szakmeister wrote: > On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras > wrote: >> On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister >> wrote: > [snip] >>> There's nothing objective about "Nobody every (sic) agrees changes are >>> good". If it were true, no changes would get in. >> >> It is true, where by "changes" I mean "changes from common user's >> point of view", actually, a tiny amount of then do sneak in, so let me >> be precise: "Virtually nobody ever agrees important changes from the >> common user's point of view are good". >> >> So now that I'm being clear, do tell, name one important change in Git >> from the user's point of view that happened in the last two years. > > Credential helpers. That's not a change, that's a new feature, and it could hardly be called important. By change I mean something that was one way before, and it's a different way now. But let me help you; you can't mention one, because there isn't any. >>> Also, you don't know that any of those changes would benefit "99% of >>> all users". It's a guess or an estimate but it's not based on >>> anything concrete. It might be a good guess--and in this case, I >>> think it is--but it's not a concrete fact. Don't make it sound like >>> it is. >> >> Sure, it's not a concrete fact, but the actual probability most likely >> follows a beta distribution with alpha=15 and beta=1. Is that more >> precise for you? > > It's not about precision, it's that you don't have any actual facts to > stand on but you speak like you do. Then when someone questions it, > you accuse them of being against fixes for the user. I wish you'd > stop it and do something more constructive to help move things along. I have as many facts as you or anybody does. If I cannot use the claim that 99% (or any overwhelming number) of users would benefit, then nobody can make the claim that X amount of users would be affected negatively, because the actual number can be close to or equal to 0. But one claim is more likely than the other. As for doing something more constructive to help move things along, what you don't get is that there is nothing to do to move things along. I send the patches, the patches are good, the patches should be applied. That's what any decently run project would do, concentrate on the technical side. Do you think if I hold hands with the people involved and we all sing Kumbaya things would move along? Well it shouldn't, if the patches are good the patches are good. What should move things along is the technical merits of the patch. If you don't agree my comment is accurate, that's one thing, but labeling it as an attack is another. >>> >>> Don't turn it around. A number of your patches and emails poke at the >>> community of the Git project and you know it. It's simply not helping >>> the situation. >> >> Show me a patch that "pokes" at the community. All my patches have >> technical descriptions, and help improve Git. > > You're filtering what I said again. Take a look at the first message > is this thread. > > I'll agree the patches themselves have been free of this, but the > cover letters--which I consider to be part of the patch--and ensuing > conversation has not. If you need another example, look at the cover > letter for your transport helper patches. I don't consider the cover letter part of the patch. And the conversation is irrelevant, all the users care about is the code. Not introducing a good feature for users because a developer said a nasty word (which I haven't) in the cover letter of the patch series is ridiculous. I would admit I was wrong if an /etc/gitconfig is indeed shipped by default, and agree that the Git project is indeed welcome to change, but that's not going to happen. >>> >>> And there it is again. Predicting the future now? Objectively and >>> accurately? Please stop. >> >> Yes I am. Feel free to go back to this mail and tell me I was wrong >> when they do what I said they won't. > > I have no need for that, and I'm done talking to you about any of this. Doesn't matter, because it's not going to happen. -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 10:35 AM, Felipe Contreras wrote: > On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister > wrote: [snip] >> There's nothing objective about "Nobody every (sic) agrees changes are >> good". If it were true, no changes would get in. > > It is true, where by "changes" I mean "changes from common user's > point of view", actually, a tiny amount of then do sneak in, so let me > be precise: "Virtually nobody ever agrees important changes from the > common user's point of view are good". > > So now that I'm being clear, do tell, name one important change in Git > from the user's point of view that happened in the last two years. Credential helpers. >> Also, you don't know that any of those changes would benefit "99% of >> all users". It's a guess or an estimate but it's not based on >> anything concrete. It might be a good guess--and in this case, I >> think it is--but it's not a concrete fact. Don't make it sound like >> it is. > > Sure, it's not a concrete fact, but the actual probability most likely > follows a beta distribution with alpha=15 and beta=1. Is that more > precise for you? It's not about precision, it's that you don't have any actual facts to stand on but you speak like you do. Then when someone questions it, you accuse them of being against fixes for the user. I wish you'd stop it and do something more constructive to help move things along. >>> If you don't agree my comment is accurate, that's one thing, but >>> labeling it as an attack is another. >> >> Don't turn it around. A number of your patches and emails poke at the >> community of the Git project and you know it. It's simply not helping >> the situation. > > Show me a patch that "pokes" at the community. All my patches have > technical descriptions, and help improve Git. You're filtering what I said again. Take a look at the first message is this thread. I'll agree the patches themselves have been free of this, but the cover letters--which I consider to be part of the patch--and ensuing conversation has not. If you need another example, look at the cover letter for your transport helper patches. None of this is news to you. [snip] >>> I would admit I was wrong if an /etc/gitconfig is indeed shipped by >>> default, and agree that the Git project is indeed welcome to change, >>> but that's not going to happen. >> >> And there it is again. Predicting the future now? Objectively and >> accurately? Please stop. > > Yes I am. Feel free to go back to this mail and tell me I was wrong > when they do what I said they won't. I have no need for that, and I'm done talking to you about any of this. -John -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 2:39 PM, Jonathan Nieder wrote: > Jeff King wrote: >> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: > >>> For now simply add a few common aliases. >>> >>> co = checkout >>> ci = commit >>> rb = rebase >>> st = status >> >> Are these the best definitions of those shortcuts? It seems[1] that some >> people define "ci" as "commit -a", and some people define "st" as >> "status -s" or even "status -sb". > > I feel bad about having waited for 4 rounds of this patch to say this, > but the basic change (providing "co", "ci", etc. as aliases by > default) does not look well thought through. > > It would be a different story if this were a patch to update > documentation to suggest adding such aliases at the same time as > telling Git what your name is. The user manual doesn't explain how to > set up aliases at all yet, and that should be fixed. Yes, better documentation around aliases would be a good idea. > But making 'ci' a synonym of another command by default while still > keeping its definition configurable would be doing people a > disservice, I fear. As long as 'ci' works out of the box, it will > start showing up in examples and used in suggestions over IRC, etc, > which is great. Unfortunately that means that anyone who has 'ci' > defined to mean something different can no longer use those examples, > that advice from IRC, and so on. So in the world where 'ci' is a > synonym for 'commit' by default, while people still *can* redefine > 'ci' to include whatever options they like (e.g., "-a"), actually > carrying out such a personal customization is asking for trouble. I'm not sure I agree. Yes, if someone has configured their shortcut differently, they may not be able to use the example exactly. OTOH, shells have aliases, and while there are sometimes problems, I think most people overcome them. I don't see the situation being very different here. FWIW, I'm not overly convinced one way or another. What I can say is, in the circles I run in, I can only think of one person has gone without setting up aliases to commit (ci), status (st), and checkout (co). The full names are simply to long for day-to-day usage. -John -- 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: [PATCH v3] build: add default aliases
Jeff King wrote: > On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: >> For now simply add a few common aliases. >> >> co = checkout >> ci = commit >> rb = rebase >> st = status > > Are these the best definitions of those shortcuts? It seems[1] that some > people define "ci" as "commit -a", and some people define "st" as > "status -s" or even "status -sb". I feel bad about having waited for 4 rounds of this patch to say this, but the basic change (providing "co", "ci", etc. as aliases by default) does not look well thought through. It would be a different story if this were a patch to update documentation to suggest adding such aliases at the same time as telling Git what your name is. The user manual doesn't explain how to set up aliases at all yet, and that should be fixed. But making 'ci' a synonym of another command by default while still keeping its definition configurable would be doing people a disservice, I fear. As long as 'ci' works out of the box, it will start showing up in examples and used in suggestions over IRC, etc, which is great. Unfortunately that means that anyone who has 'ci' defined to mean something different can no longer use those examples, that advice from IRC, and so on. So in the world where 'ci' is a synonym for 'commit' by default, while people still *can* redefine 'ci' to include whatever options they like (e.g., "-a"), actually carrying out such a personal customization is asking for trouble. Incidentally, that is also the reason git already doesn't allow aliases to override built-in commands such as "git commit", even though it would be convenient to some to not have to remember to add "-a" each time. As consolation we have been able to say "But you can take the even shorter-and-sweeter 'git ci' and make it mean whatever you want". Now we should take that avenue away for people? Bad idea. 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: [PATCH v3] build: add default aliases
The subject line needs to be updated. On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: > For now simply add a few common aliases. > > co = checkout > ci = commit > rb = rebase > st = status > > Signed-off-by: Felipe Contreras > --- [...] > diff --git a/alias.c b/alias.c > index eb9f08b..d6bad69 100644 > --- a/alias.c > +++ b/alias.c > @@ -14,11 +14,28 @@ static int alias_lookup_cb(const char *k, const char *v, > void *cb) > return 0; > } > > +static struct { > + const char *key; > + const char *val; > +} default_aliases[] = { > + { "co", "checkout" }, > + { "ci", "checkout" }, > + { "rb", "rebase" }, > + { "st", "status" }, > +}; > + > char *alias_lookup(const char *alias) > { > + int i; > alias_key = alias; > alias_val = NULL; > git_config(alias_lookup_cb, NULL); > + if (alias_val) > + return alias_val; > + for (i = 0; i < ARRAY_SIZE(default_aliases); i++) { > + if (!strcmp(alias, default_aliases[i].key)) > + return xstrdup(default_aliases[i].val); > + } > return alias_val; > } Aliases implemented this way don't work the same way as "normal" aliases do: $ # which aliases do I have? $ ./bin-wrappers/git config --get-regexp "alias\..*" $ # no aliases at all $ # does completion work? $ ./bin-wrappers/git co ma mailmap.c mailmap.h mailmap.o match-trees.c match-trees.o $ # no refs completion $ # let's see a real alias $ git config alias.co checkout $ ./bin-wrappers/git config --get-regexp "alias\..*" alias.co checkout $ ./bin-wrappers/git co ma maintmaster $ # as expected Best, Gábor -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister wrote: > On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras > wrote: >> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister >> wrote: >>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras >>> wrote: For now simply add a few common aliases. co = checkout ci = commit rb = rebase st = status Signed-off-by: Felipe Contreras --- I still think we should ship a default /etc/gitconfig, but the project needs to agree it's a good change, and nobody every agrees changes are good. So this is the minimal change that achieves the desired result. >>> >>> I wish you would stop attacking the project every time you send a >>> patch--it's simply not productive and it's certainly not getting you >>> any closer to a resolution. >> >> I'm not attacking the project, I'm making an objective claim, and I >> can back it up with several instances of evidence where 99% of the >> users would benefit from a change, yet it does not move forward. > > There's nothing objective about "Nobody every (sic) agrees changes are > good". If it were true, no changes would get in. It is true, where by "changes" I mean "changes from common user's point of view", actually, a tiny amount of then do sneak in, so let me be precise: "Virtually nobody ever agrees important changes from the common user's point of view are good". So now that I'm being clear, do tell, name one important change in Git from the user's point of view that happened in the last two years. > Also, you don't know that any of those changes would benefit "99% of > all users". It's a guess or an estimate but it's not based on > anything concrete. It might be a good guess--and in this case, I > think it is--but it's not a concrete fact. Don't make it sound like > it is. Sure, it's not a concrete fact, but the actual probability most likely follows a beta distribution with alpha=15 and beta=1. Is that more precise for you? >> If you don't agree my comment is accurate, that's one thing, but >> labeling it as an attack is another. > > Don't turn it around. A number of your patches and emails poke at the > community of the Git project and you know it. It's simply not helping > the situation. Show me a patch that "pokes" at the community. All my patches have technical descriptions, and help improve Git. > Your clearly a bright and motivated individual--which makes it all the > more frustrating that you don't approach this differently. I even > agree with your motivations for Git: I'd like to see less shell and > perl involved and to see Git run faster on Windows. But I wish you'd > stop with the jabs. Don't worry, I'll stop the "jabs" (which are really objective observations which are not particularly flattering for the project, but true, and serious problems that need to be fixed) as soon when I leave the project, which I'll do once it's clear my patches are going nowhere without any valid justification, and we are right on track for that. >> I would admit I was wrong if an /etc/gitconfig is indeed shipped by >> default, and agree that the Git project is indeed welcome to change, >> but that's not going to happen. > > And there it is again. Predicting the future now? Objectively and > accurately? Please stop. Yes I am. Feel free to go back to this mail and tell me I was wrong when they do what I said they won't. -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras wrote: > On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister > wrote: >> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras >> wrote: >>> For now simply add a few common aliases. >>> >>> co = checkout >>> ci = commit >>> rb = rebase >>> st = status >>> >>> Signed-off-by: Felipe Contreras >>> --- >>> >>> I still think we should ship a default /etc/gitconfig, but the project >>> needs to >>> agree it's a good change, and nobody every agrees changes are good. So this >>> is >>> the minimal change that achieves the desired result. >> >> I wish you would stop attacking the project every time you send a >> patch--it's simply not productive and it's certainly not getting you >> any closer to a resolution. > > I'm not attacking the project, I'm making an objective claim, and I > can back it up with several instances of evidence where 99% of the > users would benefit from a change, yet it does not move forward. There's nothing objective about "Nobody every (sic) agrees changes are good". If it were true, no changes would get in. Also, you don't know that any of those changes would benefit "99% of all users". It's a guess or an estimate but it's not based on anything concrete. It might be a good guess--and in this case, I think it is--but it's not a concrete fact. Don't make it sound like it is. > If you don't agree my comment is accurate, that's one thing, but > labeling it as an attack is another. Don't turn it around. A number of your patches and emails poke at the community of the Git project and you know it. It's simply not helping the situation. Your clearly a bright and motivated individual--which makes it all the more frustrating that you don't approach this differently. I even agree with your motivations for Git: I'd like to see less shell and perl involved and to see Git run faster on Windows. But I wish you'd stop with the jabs. > I would admit I was wrong if an /etc/gitconfig is indeed shipped by > default, and agree that the Git project is indeed welcome to change, > but that's not going to happen. And there it is again. Predicting the future now? Objectively and accurately? Please stop. -John -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister wrote: > On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras > wrote: >> For now simply add a few common aliases. >> >> co = checkout >> ci = commit >> rb = rebase >> st = status >> >> Signed-off-by: Felipe Contreras >> --- >> >> I still think we should ship a default /etc/gitconfig, but the project needs >> to >> agree it's a good change, and nobody every agrees changes are good. So this >> is >> the minimal change that achieves the desired result. > > I wish you would stop attacking the project every time you send a > patch--it's simply not productive and it's certainly not getting you > any closer to a resolution. I'm not attacking the project, I'm making an objective claim, and I can back it up with several instances of evidence where 99% of the users would benefit from a change, yet it does not move forward. If you don't agree my comment is accurate, that's one thing, but labeling it as an attack is another. I would admit I was wrong if an /etc/gitconfig is indeed shipped by default, and agree that the Git project is indeed welcome to change, but that's not going to happen. -- 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: [PATCH v3] build: add default aliases
On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras wrote: > For now simply add a few common aliases. > > co = checkout > ci = commit > rb = rebase > st = status > > Signed-off-by: Felipe Contreras > --- > > I still think we should ship a default /etc/gitconfig, but the project needs > to > agree it's a good change, and nobody every agrees changes are good. So this is > the minimal change that achieves the desired result. I wish you would stop attacking the project every time you send a patch--it's simply not productive and it's certainly not getting you any closer to a resolution. That said, I think the idea of having some default aliases is good, and these match what several other version control systems have already. FWIW, I alias st to "status -sb", but I'm not convinced it's a good default. I think the safe thing to do is to just alias it to status--like you did here--and let folks override it, if they want something more. -John -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 1:46 AM, Jeff King wrote: > On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote: > >> > People who have different aliases for >> > the same terms are unaffected on existing boxes, but slightly hindered >> > on new boxes as the aliases do something else. >> >> Less hindered than in the current situation. > > I do not agree, but I've already explained my reasoning. I think we > must agree to disagree on this. > >> cvs ci = cvs commit >> cvs co = cvs checkout >> >> svn ci = svn commit >> svn co = svn checkout >> >> hg ci = hg commit >> hg co = hg checkout >> >> And somehow you think this is not natural and sensible? >> >> git ci = git commit >> git co = git checkout >> >> I think it's as clear as day. > > If it is natural, sensible, and as clear as day, then why do people > alias the commands to something besides what you show? For the same reason people would do alias.commit='commit -a' if it was possible. [1] http://article.gmane.org/gmane.comp.version-control.git/147517 -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote: > > People who have different aliases for > > the same terms are unaffected on existing boxes, but slightly hindered > > on new boxes as the aliases do something else. > > Less hindered than in the current situation. I do not agree, but I've already explained my reasoning. I think we must agree to disagree on this. > cvs ci = cvs commit > cvs co = cvs checkout > > svn ci = svn commit > svn co = svn checkout > > hg ci = hg commit > hg co = hg checkout > > And somehow you think this is not natural and sensible? > > git ci = git commit > git co = git checkout > > I think it's as clear as day. If it is natural, sensible, and as clear as day, then why do people alias the commands to something besides what you show? -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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 1:18 AM, Jeff King wrote: > On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote: > >> Anyway, if you are so worried about this hypothetical user not >> noticing that 'git ci' didn't commit all the files, we could ma ci to >> 'git commit -v' so we are being straightforward to the user as to what >> is being committed. > > I do not think that is a useful suggestion, as the output of "commit -v" > is typically too long for unsuspecting people to check carefully, and is > redundant with the filename summary we already put in the commit > template. And neither is shown with "-m", anyway. I agree it's a > minority of cases where somebody will make a bogus commit because of it, > though. > > But let's take a step back for a moment. What was the goal of the patch? > Who are we trying to help? People who already have identical aliases are > not helped on existing boxes; they already have them. They might be > helped on new boxes, where they will not have to copy over their custom > aliases (but they would probably end up wanting to copy the rest of > their config and aliases anyway). They probably will want that, but they won't be forced to by typing failing commands, they could do it later at their pleasure. > People who have different aliases for > the same terms are unaffected on existing boxes, but slightly hindered > on new boxes as the aliases do something else. Less hindered than in the current situation. > People with no matching aliases now get these aliases. What do they > expect them to do? Do they expect "commit" or "commit -a"? Do they > expect "status" or "status -s" or "status -sb"? Are we trying for > consistency across git installations, or consistency with similar > aliases in systems like cvs (in which case, would that argue for "commit > -a")? Do people who have not bothered to configure the aliases even > care? cvs ci = cvs commit cvs co = cvs checkout svn ci = svn commit svn co = svn checkout hg ci = hg commit hg co = hg checkout And somehow you think this is not natural and sensible? git ci = git commit git co = git checkout I think it's as clear as day. -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote: > Anyway, if you are so worried about this hypothetical user not > noticing that 'git ci' didn't commit all the files, we could ma ci to > 'git commit -v' so we are being straightforward to the user as to what > is being committed. I do not think that is a useful suggestion, as the output of "commit -v" is typically too long for unsuspecting people to check carefully, and is redundant with the filename summary we already put in the commit template. And neither is shown with "-m", anyway. I agree it's a minority of cases where somebody will make a bogus commit because of it, though. But let's take a step back for a moment. What was the goal of the patch? Who are we trying to help? People who already have identical aliases are not helped on existing boxes; they already have them. They might be helped on new boxes, where they will not have to copy over their custom aliases (but they would probably end up wanting to copy the rest of their config and aliases anyway). People who have different aliases for the same terms are unaffected on existing boxes, but slightly hindered on new boxes as the aliases do something else. People with no matching aliases now get these aliases. What do they expect them to do? Do they expect "commit" or "commit -a"? Do they expect "status" or "status -s" or "status -sb"? Are we trying for consistency across git installations, or consistency with similar aliases in systems like cvs (in which case, would that argue for "commit -a")? Do people who have not bothered to configure the aliases even care? My original question was: are these the best definitions of those shortcuts? I have not seen any answer to that. -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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 12:37 AM, Jeff King wrote: > On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote: > >> > You are making things more consistent for people who already define >> > those aliases in the same way (they are available everywhere, even if >> > they have not moved their config to a new installation), but less so for >> > people who define them differently. Rather than get an obvious: >> > >> > git: 'co' is not a git command. See 'git --help'. >> > >> > the result will be subtly different (especially so in the case of >> > "commit" versus "commit -a"). >> >> Before: >> >> # machine A: git ci >> git: 'ca' is not a git command. See 'git --help'. >> >> # machine B: git ci >> commits >> >> After: >> >> # machine A: git ci >> no changes added to commit (use "git add" and/or "git commit -a") >> >> # machine B: git ci >> commits > > That is the output if there are no files to commit. What about while > resolving a merge, or after using "git add" on a path? In that case we > create a commit, but it is subtly different than what the user intended. It might be different, but it might not. Anyway, if you are so worried about this hypothetical user not noticing that 'git ci' didn't commit all the files, we could ma ci to 'git commit -v' so we are being straightforward to the user as to what is being committed. -- 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: [PATCH v3] build: add default aliases
On Tue, Sep 24, 2013 at 12:32:46AM -0500, Felipe Contreras wrote: > > You are making things more consistent for people who already define > > those aliases in the same way (they are available everywhere, even if > > they have not moved their config to a new installation), but less so for > > people who define them differently. Rather than get an obvious: > > > > git: 'co' is not a git command. See 'git --help'. > > > > the result will be subtly different (especially so in the case of > > "commit" versus "commit -a"). > > Before: > > # machine A: git ci > git: 'ca' is not a git command. See 'git --help'. > > # machine B: git ci > commits > > After: > > # machine A: git ci > no changes added to commit (use "git add" and/or "git commit -a") > > # machine B: git ci > commits That is the output if there are no files to commit. What about while resolving a merge, or after using "git add" on a path? In that case we create a commit, but it is subtly different than what the user intended. I think for the merge case, it is probably OK, as the "surprise" should always go in the safe direction (user expects "commit -a", gets "commit", and commit balks). But the other omits intended files from the commit. -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: [PATCH v3] build: add default aliases
On Mon, Sep 23, 2013 at 11:53 PM, Jeff King wrote: > On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: > >> For now simply add a few common aliases. >> >> co = checkout >> ci = commit >> rb = rebase >> st = status > > Are these the best definitions of those shortcuts? It seems[1] that some > people define "ci" as "commit -a", and some people define "st" as > "status -s" or even "status -sb". > > You are making things more consistent for people who already define > those aliases in the same way (they are available everywhere, even if > they have not moved their config to a new installation), but less so for > people who define them differently. Rather than get an obvious: > > git: 'co' is not a git command. See 'git --help'. > > the result will be subtly different (especially so in the case of > "commit" versus "commit -a"). Before: # machine A: git ci git: 'ca' is not a git command. See 'git --help'. # machine B: git ci commits After: # machine A: git ci no changes added to commit (use "git add" and/or "git commit -a") # machine B: git ci commits The "after" part is much more consistent, at least several commands have a higher chance of doing what the user actually wants, at worst they would do something close to what the user wants. -- 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: [PATCH v3] build: add default aliases
On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote: > For now simply add a few common aliases. > > co = checkout > ci = commit > rb = rebase > st = status Are these the best definitions of those shortcuts? It seems[1] that some people define "ci" as "commit -a", and some people define "st" as "status -s" or even "status -sb". You are making things more consistent for people who already define those aliases in the same way (they are available everywhere, even if they have not moved their config to a new installation), but less so for people who define them differently. Rather than get an obvious: git: 'co' is not a git command. See 'git --help'. the result will be subtly different (especially so in the case of "commit" versus "commit -a"). -Peff [1] https://github.com/search?q=%22ci+%3D+commit+-a%22+path%3A.gitconfig&type=Code https://github.com/search?q=%22st+%3D+status+-s%22&type=Code https://github.com/search?q=%22st+%3D+status+-sb%22&type=Code -- 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
[PATCH v3] build: add default aliases
For now simply add a few common aliases. co = checkout ci = commit rb = rebase st = status Signed-off-by: Felipe Contreras --- I still think we should ship a default /etc/gitconfig, but the project needs to agree it's a good change, and nobody every agrees changes are good. So this is the minimal change that achieves the desired result. Documentation/git-checkout.txt | 5 + Documentation/git-commit.txt | 5 + Documentation/git-rebase.txt | 5 + Documentation/git-status.txt | 5 + alias.c| 17 + 5 files changed, 37 insertions(+) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index ca118ac..7597813 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -14,6 +14,11 @@ SYNOPSIS 'git checkout' [-f|--ours|--theirs|-m|--conflict=