On Sat, Sep 21, 2013 at 1:33 AM, David Aguilar <dav...@gmail.com> wrote: > Felipe Contreras <felipe.contre...@gmail.com> wrote: >>I know 'git ci' is perfectly fine shortcut to 'git commit'. >> >>Either way, it doesn't matter. Even if we agree that /etc/gitconfig.d >>is what we want, or we add an /usr/share/git/config, Junio is not >>going to apply any patch, even if it's what most users want. > > Please stop making personal attacks that add nothing to your argument. No one > cares. Let it be.
There are no personal attacks here. A personal attack would be 'X is a moron', or 'X doesn't know what he is talking about', I don't see any of that. This is a fact, do you see anybody besides you and me commenting about the subject? More specifically, do you see Junio making any comment? > Let's move this in a more constructive direction then, no? > > How about working on documenting the new aliases and add a knob to the > Makefile so that we can choose whether or not to install the stock config? Sure, but document these aliases where? If you mean document them in the man page of each command (e.g. git commit, alias: ci), then sure, that's fine by me. Adding a know to the Makefile I think doesn't make sense, because a packager would do. % make NO_DEFAULT_CONFIG=y install Which is not very different from: % make install % rm -f $DESTDIR/etc/gitconfig > I'm not trying to fight this patch -- the idea is nice. Most users and > distros probably won't change stock aliases, so your energy may be better > spent getting consensus on what the stock aliases could be. Thanks for stating so, unfortunately, I don't think it really matters because this is a change, and the Git project is not welcome to change. > Would it not be better to have these aliases, plus/minus one or two, then > none at all? Yes, but you don't see anybody advocating for that at all, do you? > ... > Yes I know about .rpmsave files. For rpm, it'll refuse to upgrade Git since > this new file will conflict with an existing package. In your case, yes, not in the normal case, where /etc/gitconfig is not provided by a package. > That's easier to deal with because the config package can then be > independently modified to install its file to eg git.d/foo.conf in the > directory include example. That would then allow the upgrade, and at no > point did the intended config ever get lost. It might be easier to deal with, but it would still require an intervention. > Puppet users, for example, may end up with rpmsave turds on their systems, > though. When you are managing lots of machines this can be very annoying -- > that's why I mentioned it. Don't bother arguing this point any further. It's > boring. It can be very annoying, but your /etc/gitconfig.d solution doesn't help in that regard. Either way, the move from 'git-foo' to 'git foo' was very annoying as well, but we all agreed it was the right thing to do (most of us), fortunately in this case I think the people that have a /etc/gitconfig are significantly less. > ... > In summary -- makefile knob, please, and at least mention the stock aliases > somewhere in the docs so that the users can know to read /etc/gitconfig if > they want to know more. Who knows, maybe it will get applied, but it > definitively won't if all you do is whine about it. It won't get applied, I'll do the modifications, and you'll see. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
