[git-users] Re: [PATCH] build: add default configuration
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. 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? 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. Would it not be better to have these aliases, plus/minus one or two, then none at all? ... Yes I know about .rpmsave files. For rpm, it'll refuse to upgrade Git since this new file will conflict with an existing 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. 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. ... 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. -- David -- 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.
[git-users] Re: [PATCH] build: add default configuration
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.
[git-users] Re: [PATCH] build: add default configuration
Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com wrote: On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long advertised as the way to do it) You package /etc/gitconfig *outside* the git package? I don't see how that could have been ever advertised as the way to do it. Okay so how exactly are we supposed to do it? Duh, rpm is the right choice for redhat systems. Users don't package /etc/gitconfig outside git. Wrong. Existence proof: me. I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. In that case I take it back -- I dont like that approach. We want consistency, not divergence. This encourages the former. So you think we have more consistency right now? We don't even have a predefined /etc/gitconfig, that creates more inconsistency, as everybody's configs and aliases are very very different. This patch would definitely make things more consistent. We don't need this patch to allow distros to modify aliases. Likewise, allowing the aliases to diverge is less consistent. Do it at a lower level. I also agree with Junio's notes about ci. Something short that can add and remove from the index would be nice. -- David -- 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.
[git-users] Re: [PATCH] build: add default configuration
David Aguilar wrote: Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com wrote: On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long advertised as the way to do it) You package /etc/gitconfig *outside* the git package? I don't see how that could have been ever advertised as the way to do it. Okay so how exactly are we supposed to do it? Duh, rpm is the right choice for redhat systems. The same way kerberos, mariadb, apache, and essentially every other tool that has a configuration file in /etc. Users don't package /etc/gitconfig outside git. Wrong. Existence proof: me. You as a user are not packaging it, it's you as a system adimistrator. Either way, you are 0.0001% of Git's userbase, you are not representative. I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. In that case I take it back -- I dont like that approach. We want consistency, not divergence. This encourages the former. So you think we have more consistency right now? We don't even have a predefined /etc/gitconfig, that creates more inconsistency, as everybody's configs and aliases are very very different. This patch would definitely make things more consistent. We don't need this patch to allow distros to modify aliases. Likewise, allowing the aliases to diverge is less consistent. Do it at a lower level. We already allow the aliases to diverge, we allow it much more. The pach will make the aliases more consistent. I also agree with Junio's notes about ci. Something short that can add and remove from the index would be nice. cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good enough for Git? Yeah, sure. -- 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.
[git-users] Re: [PATCH] build: add default configuration
Felipe Contreras felipe.contre...@gmail.com wrote: David Aguilar wrote: Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com wrote: On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long advertised as the way to do it) You package /etc/gitconfig *outside* the git package? I don't see how that could have been ever advertised as the way to do it. Okay so how exactly are we supposed to do it? Duh, rpm is the right choice for redhat systems. The same way kerberos, mariadb, apache, and essentially every other tool that has a configuration file in /etc. Good point. These tools (apache, for example) allow inclusion of a directory. Users are encouraged to package their stuff inside eg httpd.d/, and the distros ship a neutral config that includes that directory. Your patch does not add this capability, so by your own definition it's incomplete. As-is, the patch is half-baked. If we have a clear upgrade path -- eg move your current configs over to /etc/git.d/your.conf -- then it's a non-issue. As-is, you're asking users to manually deal with the fallout. You're also asking users to modify a package-manager controlled file (after your patch), which IMO is suboptimal. Users don't package /etc/gitconfig outside git. Wrong. Existence proof: me. You as a user are not packaging it, it's you as a system adimistrator. Strawman. I represent at least at least a hundred users, but who cares. It doesn't matter. The patch is incomplete. Either way, you are 0.0001% of Git's userbase, you are not representative. And your point is what exactly? That once proven wrong you move the goalposts? I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. In that case I take it back -- I dont like that approach. We want consistency, not divergence. This encourages the former. So you think we have more consistency right now? We don't even have a predefined /etc/gitconfig, that creates more inconsistency, as everybody's configs and aliases are very very different. This patch would definitely make things more consistent. We don't need this patch to allow distros to modify aliases. Likewise, allowing the aliases to diverge is less consistent. Do it at a lower level. We already allow the aliases to diverge, we allow it much more. The pach will make the aliases more consistent. I also agree with Junio's notes about ci. Something short that can add and remove from the index would be nice. cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good enough for Git? Yeah, sure. IMO this isn't the kind of thing that you or I can decide in isolation. Maybe it is, or maybe the real differences between the ci mental model are enough that it isn't. But you don't actually know the answer. You might think you do, but your guess is just as good/bad/ugly as mine. -- David -- 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.
[git-users] Re: [PATCH] build: add default configuration
On Fri, Sep 20, 2013 at 7:44 PM, David Aguilar dav...@gmail.com wrote: Felipe Contreras felipe.contre...@gmail.com wrote: David Aguilar wrote: Felipe Contreras felipe.contre...@gmail.com wrote: On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com wrote: On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long advertised as the way to do it) You package /etc/gitconfig *outside* the git package? I don't see how that could have been ever advertised as the way to do it. Okay so how exactly are we supposed to do it? Duh, rpm is the right choice for redhat systems. The same way kerberos, mariadb, apache, and essentially every other tool that has a configuration file in /etc. Good point. These tools (apache, for example) allow inclusion of a directory. Wrong. Apache does, but neither does kerberos, nor mariadb, which have a single configuration file, at least on all the systems I've seen. You act as if you have never seen .pacsave/.rpmsave (and so on) files before, they a are pretty common sight when the user modifies the configuration files, and as kerberos and mariadb demonstrate, pretty successful projects can survive with a simple single configuration file. Your patch does not add this capability, so by your own definition it's incomplete. As-is, the patch is half-baked. It's not incomplete, any more than kerberos, mariadb, and countless other programs are. If we have a clear upgrade path -- eg move your current configs over to /etc/git.d/your.conf -- then it's a non-issue. But now you contradict yourself. This patch would force users to resolve the conflicts eventually through .pacsave/.rpmsave, and with your proposal to have directory includes, it would also force manual user intervention by moving the configuration files and resolve the conflict. So why is one manual user intervention so appalling, and the other one so right? Either way, if this patch is so wrong, then clearly the RedHat packaging team would remove /etc/gitconfig from the Git RPM package, and you would be fine, wouldn't you? Or maybe you are afraid that RedHat packaging team would agree that the /etc/gitconfig file provided by Git is fine. As-is, you're asking users to manually deal with the fallout. You're also asking users to modify a package-manager controlled file (after your patch), which IMO is suboptimal. In both cases the user has to manually deal with the fallout. Users don't package /etc/gitconfig outside git. Wrong. Existence proof: me. You as a user are not packaging it, it's you as a system adimistrator. Strawman. I represent at least at least a hundred users, but who cares. It doesn't matter. The patch is incomplete. No you don't, you represent a system administrator, not a user. Either way, you are 0.0001% of Git's userbase, you are not representative. And your point is what exactly? That once proven wrong you move the goalposts? It's called colloquial language. If I say, people don't bark on the street, and then you say here, there's a guy that does bark on the street, and then I say, fine, people don't *NORMALLY* bark on the street, what have we achieved? This is just an exercise in pedanticism. Sane users, under normal circumstances, for the overwhelmingly vast majority of situations, do not package their /etc/gitconfig file. I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. In that case I take it back -- I dont like that approach. We want consistency, not divergence. This encourages the former. So you think we have more consistency right now? We don't even have a predefined /etc/gitconfig, that creates more inconsistency, as everybody's configs and aliases are very very different. This patch would definitely make things more consistent. We don't need this patch to allow distros to modify aliases. Likewise, allowing the aliases to diverge is less consistent. Do it at a lower level. We already allow the aliases to diverge, we allow it much more. The pach will make the aliases more consistent. I also agree with Junio's notes about ci. Something short that can add and remove from the index would be nice. cvs ci, svn ci, hg ci, they all work, but suddenly ci is not good enough for Git? Yeah, sure. IMO this isn't the kind of
[git-users] Re: [PATCH] build: add default configuration
On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Apologies for top post -- anybody have a recommendation for a better app then maildroid? Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. If you mean people that have ~/.gitconfig, then absolutely not, because that one takes precedence. Alternatively, we could have a higher level configuration file (e.g. /usr/share/git/config), but I think that's overkill. I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. -- 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.
[git-users] Re: [PATCH] build: add default configuration
On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long advertised as the way to do it) and asking users to manually fix up thousands of machines is a bad idea. Yes, thousands. We're much past 30,000 cores at the moment. I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. In that case I take it back -- I dont like that approach. We want consistency, not divergence. This encourages the former. -- David -- 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.
[git-users] Re: [PATCH] build: add default configuration
On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar dav...@gmail.com wrote: On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar dav...@gmail.com wrote: Will this not conflict with folks that supply their own gitconfig? You mean people that provide their own ETC_GITCONFIG? If you mean distributions, their packaging would override /etc/gitconfig, if you mean people that have already a /etc/gitconfig, packaging systems usually save the old one so they can solve the conflict manually (e.g. /etc/gitconfig.pacsave). So no, it would not conflict. Yuck. Yes, that one. I package my own /etc/gitconfig (as we have long advertised as the way to do it) You package /etc/gitconfig *outside* the git package? I don't see how that could have been ever advertised as the way to do it. and asking users to manually fix up thousands of machines is a bad idea. Users don't package /etc/gitconfig outside git. I like the idea. Docs? Also, should this not be done in the C side so that we don't waste time reading the config, and also prevent users from overriding these? But we want them to be easily readable, and possibly allow distributions to easily modify them. In that case I take it back -- I dont like that approach. We want consistency, not divergence. This encourages the former. So you think we have more consistency right now? We don't even have a predefined /etc/gitconfig, that creates more inconsistency, as everybody's configs and aliases are very very different. This patch would definitely make things more consistent. -- 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.
