[PATCH] build: add default configuration

[PATCH] build: add default configuration

[Felipe Contreras]

For now simply add a few common aliases.

  co = checkout
  ci = commit
  rb = rebase
  st = status

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
 Makefile  | 5 ++++-
 gitconfig | 5 +++++
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gitconfig

diff --git a/Makefile b/Makefile
index 3588ca1..18081bf 100644
--- a/Makefile
+++ b/Makefile
@@ -1010,7 +1010,7 @@ ifndef sysconfdir
 ifeq ($(prefix),/usr)
 sysconfdir = /etc
 else
-sysconfdir = etc
+sysconfdir = $(prefix)/etc
 endif
 endif
 
@@ -1586,6 +1586,7 @@ template_dir_SQ = $(subst ','\'',$(template_dir))
 htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
 prefix_SQ = $(subst ','\'',$(prefix))
 gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
+sysconfdir_SQ = $(subst ','\'',$(sysconfdir))
 
 SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
 PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -2340,6 +2341,8 @@ install: all
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
 	$(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(sysconfdir_SQ)'
+	$(INSTALL) -m 644 gitconfig '$(DESTDIR_SQ)$(ETC_GITCONFIG_SQ)'
 ifndef NO_GETTEXT
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
 	(cd po/build/locale && $(TAR) cf - .) | \
diff --git a/gitconfig b/gitconfig
new file mode 100644
index 0000000..c45d300
--- /dev/null
+++ b/gitconfig
@@ -0,0 +1,5 @@
+[alias]
+	co = checkout
+	ci = commit
+	rb = rebase
+	st = status
-- 
1.8.4-fc

Re: [PATCH] build: add default configuration

[David Aguilar]

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?

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?

 

-----Original Message-----
From: Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: git-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: git-users-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org, "Bráulio Bhavamitra" <brauliobo-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>, Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Tue, 17 Sep 2013 8:23 AM
Subject: [PATCH] build: add default configuration

For now simply add a few common aliases.

  co = checkout
  ci = commit
  rb = rebase
  st = status

Signed-off-by: Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
 Makefile  | 5 ++++-
 gitconfig | 5 +++++
 2 files changed, 9 insertions(+), 1 deletion(-)
 create mode 100644 gitconfig

diff --git a/Makefile b/Makefile
index 3588ca1..18081bf 100644
--- a/Makefile
+++ b/Makefile
@@ -1010,7 +1010,7 @@ ifndef sysconfdir
 ifeq ($(prefix),/usr)
 sysconfdir = /etc
 else
-sysconfdir = etc
+sysconfdir = $(prefix)/etc
 endif
 endif
 
@@ -1586,6 +1586,7 @@ template_dir_SQ = $(subst ','\'',$(template_dir))
 htmldir_relative_SQ = $(subst ','\'',$(htmldir_relative))
 prefix_SQ = $(subst ','\'',$(prefix))
 gitwebdir_SQ = $(subst ','\'',$(gitwebdir))
+sysconfdir_SQ = $(subst ','\'',$(sysconfdir))
 
 SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
 PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
@@ -2340,6 +2341,8 @@ install: all
 	$(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' install
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
 	$(INSTALL) -m 644 mergetools/* '$(DESTDIR_SQ)$(mergetools_instdir_SQ)'
+	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(sysconfdir_SQ)'
+	$(INSTALL) -m 644 gitconfig '$(DESTDIR_SQ)$(ETC_GITCONFIG_SQ)'
 ifndef NO_GETTEXT
 	$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
 	(cd po/build/locale && $(TAR) cf - .) | \
diff --git a/gitconfig b/gitconfig
new file mode 100644
index 0000000..c45d300
--- /dev/null
+++ b/gitconfig
@@ -0,0 +1,5 @@
+[alias]
+	co = checkout
+	ci = commit
+	rb = rebase
+	st = status
-- 
1.8.4-fc

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[Felipe Contreras]

On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[David Aguilar]

>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

Re: [PATCH] build: add default configuration

[Felipe Contreras]

On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[David Aguilar]

Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>wrote:
>>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[Felipe Contreras]

David Aguilar wrote:
> Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >wrote:
> >>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[David Aguilar]

Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>David Aguilar wrote:
>> Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >wrote:
>> >>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[Felipe Contreras]

On Fri, Sep 20, 2013 at 7:44 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>David Aguilar wrote:
>>> Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>> >On Wed, Sep 18, 2013 at 9:30 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> >wrote:
>>> >>>On Wed, Sep 18, 2013 at 1:13 PM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> >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 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.

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.

-- 
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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[David Aguilar]

Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] build: add default configuration

[Felipe Contreras]

On Sat, Sep 21, 2013 at 1:33 AM, David Aguilar <davvid-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Felipe Contreras <felipe.contreras-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.