* Re: Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Matthieu Moy @ 2013-01-20 11:24 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: davvid, git
In-Reply-To: <310504838.1116553.1358607676116.JavaMail.ngmail@webmail10.arcor-online.net>
Thomas Ackermann <th.acker@arcor.de> writes:
> The whole point of my patch is to use 'Git' consistently when
> we are talking about the system and not the individual command.
I like the idea. "git" should obviously remain lower-case when talking
about the command, but deserves a capital when talking about the
software independantly of whether it's called from command-line. Just
like I type "firefox" in a shell to launch a program called "Firefox"
(or even "Mozilla Firefox").
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: How to setup bash completion for alias of git command
From: Jonathan Nieder @ 2013-01-20 11:14 UTC (permalink / raw)
To: Ping Yin
Cc: git mailing list, Felipe Contreras, Manlio Perillo, Marc Khouzam,
SZEDER Gábor
In-Reply-To: <CACSwcnQu8Rx83mcGYR6NGzEhoreNR6DfiK876LF7pa9PGm30JA@mail.gmail.com>
Hi Ping,
Ping Yin wrote:
> Following setup works for me in ubuntu (10.04,11.04) for a long time
>
> alias gtlg='git log'
> complete -o default -o nospace -F _git_log gtlg
>
> However, in debian (testing, wheezy), it doesn't work
>
> $ gtlg or<TAB>
> gtlg or-bash: [: 1: unary operator expected
> -bash: [: 1: unary operator expected
Yes, I can reproduce this. "git bisect" tells me it was introduced
by v1.7.6-rc0~65^2~4 (completion: remove unnecessary
_get_comp_words_by_ref() invocations, 2011-04-28). Since then, Felipe
has done work to make reusing subcommand completion easy again, so you
can do
__git_complete gtlg _git_log
One complication: on some systems, including Ubuntu 13.04, git's bash
completion script is installed to
/usr/share/bash-completion/completions/git
and sourced on the fly when completing commands starting with "git"
instead of right away from /etc/bash_completion. On these systems,
the "__git_complete" function would not be usable right away from
your .bashrc file. I think we should fix this, for example by moving
the function to a separate
$(git --exec-path)/git-bashrc-functions
library.
Thanks for reporting,
Jonathan
^ permalink raw reply
* [PATCH v2] INSTALL: git-p4 doesn't support Python 3
From: John Keeping @ 2013-01-20 11:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pete Wyckoff
git-p4 supports Python 2.6 and later versions of Python 2. Since Python
2.8 will never exist [1], it is most concise to just list the supported
versions.
[1] http://www.python.org/dev/peps/pep-0404/
Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: Pete Wyckoff <pw@padd.com>
---
Since v1:
- Fixed a typo in the commit message.
INSTALL | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/INSTALL b/INSTALL
index 28f34bd..c456d1c 100644
--- a/INSTALL
+++ b/INSTALL
@@ -131,7 +131,7 @@ Issues of note:
use English. Under autoconf the configure script will do this
automatically if it can't find libintl on the system.
- - Python version 2.6 or later is needed to use the git-p4
+ - Python version 2.6 or 2.7 is needed to use the git-p4
interface to Perforce.
- Some platform specific issues are dealt with Makefile rules,
--
1.8.1.353.gc992d5a.dirty
^ permalink raw reply related
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jonathan Nieder @ 2013-01-20 11:06 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Ramsay Jones, Mark Levedahl, Alex Riesen, Junio C Hamano,
Jason Pyeron, git, Stephen & Linda Smith, Eric Blake, msysGit
In-Reply-To: <50FBCB95.6020201@web.de>
Torsten Bögershausen wrote:
> I wonder, if if we can go one step further:
>
> Replace
> #ifdef WIN32 /* Both MinGW and MSVC */
[...]
> with
> #if defined(_MSC_VER)
I thought Git for Windows was built using mingw, which doesn't define
_MSC_VER?
Puzzled,
Jonathan
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
^ permalink raw reply
* Re: [PATCH] INSTALL: git-p4 doesn't support Python 3
From: John Keeping @ 2013-01-20 10:59 UTC (permalink / raw)
To: David Aguilar; +Cc: git, Pete Wyckoff
In-Reply-To: <CAJDDKr6VD0vnL8x4bgJWLQZNQKR4vQrvJaL5_tdF_9znAW2XAA@mail.gmail.com>
On Sat, Jan 19, 2013 at 05:31:35PM -0800, David Aguilar wrote:
> On Sat, Jan 19, 2013 at 4:01 AM, John Keeping <john@keeping.me.uk> wrote:
>> Since Pyhton
>> 2.8 will never exist [1]
>
> Tiny typo: Python misspelled as Pyhton
Thanks. v2 on its way.
John
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Torsten Bögershausen @ 2013-01-20 10:48 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramsay Jones, Mark Levedahl, Alex Riesen, Junio C Hamano,
Jason Pyeron, git, Torsten Bögershausen,
Stephen & Linda Smith, Eric Blake, msysGit
In-Reply-To: <20130120101007.GD16339@elie.Belkin>
On 20.01.13 11:10, Jonathan Nieder wrote:
> Ramsay Jones wrote:
>
>> --- a/git-compat-util.h
>> +++ b/git-compat-util.h
>> @@ -85,12 +85,6 @@
>> #define _NETBSD_SOURCE 1
>> #define _SGI_SOURCE 1
>>
>> -#ifdef WIN32 /* Both MinGW and MSVC */
>> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
>> -#include <winsock2.h>
>> -#include <windows.h>
>> -#endif
>
> So, do I understand correctly that the above conditional should be
> something like
>
> #if defined(WIN32) && !defined(__CYGWIN__)
>
> to allow dropping the CYGWIN_V15_WIN32API setting?
>
> "defined(WIN32)" is used throughout git to mean "win32 and not
> cygwin", so if I understand correctly we would either need to do
>
> #if defined(WIN32) && defined(__CYGWIN__)
> # undef WIN32
> #endif
>
> or define a new GIT_WIN32 (name is just a placeholder) macro to use
> consistently in its stead.
>
> Thanks for investigating.
> Jonathan
I wonder, if if we can go one step further:
Replace
#ifdef WIN32 /* Both MinGW and MSVC */
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
#endif
with
#if defined(_MSC_VER)
#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
#include <winsock2.h>
#include <windows.h>
#endif
Any thougths from msysGit ?
/Torsten
^ permalink raw reply
* Re: Version 1.8.1 does not compile on Cygwin 1.7.14
From: Jonathan Nieder @ 2013-01-20 10:10 UTC (permalink / raw)
To: Ramsay Jones
Cc: Mark Levedahl, Alex Riesen, Junio C Hamano, Jason Pyeron, git,
Torsten Bögershausen, Stephen & Linda Smith, Eric Blake
In-Reply-To: <50F5A435.5090408@ramsay1.demon.co.uk>
Ramsay Jones wrote:
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -85,12 +85,6 @@
> #define _NETBSD_SOURCE 1
> #define _SGI_SOURCE 1
>
> -#ifdef WIN32 /* Both MinGW and MSVC */
> -#define WIN32_LEAN_AND_MEAN /* stops windows.h including winsock.h */
> -#include <winsock2.h>
> -#include <windows.h>
> -#endif
So, do I understand correctly that the above conditional should be
something like
#if defined(WIN32) && !defined(__CYGWIN__)
to allow dropping the CYGWIN_V15_WIN32API setting?
"defined(WIN32)" is used throughout git to mean "win32 and not
cygwin", so if I understand correctly we would either need to do
#if defined(WIN32) && defined(__CYGWIN__)
# undef WIN32
#endif
or define a new GIT_WIN32 (name is just a placeholder) macro to use
consistently in its stead.
Thanks for investigating.
Jonathan
^ permalink raw reply
* Aw: [PATCH 0/2] GIT, Git, git
From: Thomas Ackermann @ 2013-01-20 8:38 UTC (permalink / raw)
To: th.acker, git
>
> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
> (as can be seen in the corresponding release note where 'GIT' was
> changed to 'Git' in the header line).
>
> Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
> Git system. So change every occurrence of 'GIT" and 'git' to 'Git'
> whenever Git as a system is referred to (but don't do this change
> in the release notes because they constitute a history orthogonal
> to the history versioned by Git).
>
> [PATCH 1/2] Change old system name 'GIT' to 'Git'
> [PATCH 2/2] Change 'git' to 'Git' whenever the whole system is referred to
>
My second patch somehow got lost in the mailing system (I suspect
due to its size of >300kB). I will wait for some more comments
and then do a reroll thereby splitting the second patch in smaller
parts ...
---
Thomas
^ permalink raw reply
* Re: [PATCH] INSTALL: git-p4 doesn't support Python 3
From: David Aguilar @ 2013-01-20 1:31 UTC (permalink / raw)
To: John Keeping; +Cc: git, Pete Wyckoff
In-Reply-To: <20130119120158.GH31172@serenity.lan>
On Sat, Jan 19, 2013 at 4:01 AM, John Keeping <john@keeping.me.uk> wrote:
> Since Pyhton
> 2.8 will never exist [1]
Tiny typo: Python misspelled as Pyhton
--
David
^ permalink raw reply
* Re: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: David Aguilar @ 2013-01-20 0:47 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <310504838.1116553.1358607676116.JavaMail.ngmail@webmail10.arcor-online.net>
On Sat, Jan 19, 2013 at 7:01 AM, Thomas Ackermann <th.acker@arcor.de> wrote:
>
>>
>> What about GITweb?
>>
> You are right; I missed that because I grepped only for 'GIT' as a whole word.
> 'gitweb' and 'GITweb' should be changed to 'Gitweb'.
>
>>
>> IMO some of these look nicer when everything is lowercase.
>> e.g. "standard git committer ident format".
>>
> IMHO what seems nicer here is the spelling we are all accustomed to.
> The whole point of my patch is to use 'Git' consistently when
> we are talking about the system and not the individual command.
>
>>
>> $ git grep 'git repositor' | wc -l
>> 226
>>
>> These changes touch, for example, git-clone.txt to make it
>> say: "Make a 'bare' Git repository". Why not lowercase?
>>
> When you also apply my second patch you only get 17 occurences of "git repository"
> which I missed to change to 'Git repository' ...
>
> Thanks for looking into this!
Thank *you* for tackling these last 226 and listening to my silly opinions.
The end result will be much nicer all around.
--
David
^ permalink raw reply
* Re: [PATCH 0/2] GIT, Git, git
From: Jonathan Nieder @ 2013-01-19 22:31 UTC (permalink / raw)
To: Thomas Ackermann; +Cc: git
In-Reply-To: <732444561.1327663.1358589465467.JavaMail.ngmail@webmail24.arcor-online.net>
Hi Thomas,
Thomas Ackermann wrote:
> Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
> (as can be seen in the corresponding release note where 'GIT' was
> changed to 'Git' in the header line).
>
> Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
> Git system. So change every occurrence of 'GIT" and 'git' to 'Git'
> whenever Git as a system is referred to (but don't do this change
> in the release notes because they constitute a history orthogonal
> to the history versioned by Git).
I don't have any opinion about the subject at hand, except that making
a consistent convention and documenting it somewhere to avoid future
churn sounds like a fine idea.
Instead, I'm writing for a procedural nitpick ;-): please move the
above rationale to one of the commit messages, so it gets recorded
somewhere that future readers can easily find it.
Hope that helps,
Jonathan
^ permalink raw reply
* Re: [RFC] git rm -u
From: Eric James Michael Ritz @ 2013-01-19 22:01 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Tomas Carnecky
In-Reply-To: <20130119214921.GE4009@elie.Belkin>
On 01/19/2013 04:49 PM, Jonathan Nieder wrote:
> Eric James Michael Ritz wrote:
>
>> When I came to my senses and realized that does not work I began to
>> wonder if `git rm -u` should exist. If any deleted, tracked files
>> are not part of the index to commit then `git rm -u` would add that
>> change to the index.
>
> I like it. If you have time to write such a patch, I'll be happy to
> read it.
Thank you for the offer Jonathan. I must go ahead and apologize for
my rusty ability with C; I haven’t needed to use the language in
years. But I will familiarize myself with the Git source and try to
put a patch (or series of patches) together over the next week or two.
--
ejmr
南無妙法蓮華經
^ permalink raw reply
* Re: [RFC] git rm -u
From: Eric James Michael Ritz @ 2013-01-19 21:56 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: Tomas Carnecky, git
In-Reply-To: <CALWbr2zhxkZEGWc5iN-8MivzV7viEdfwV_Q-iH0xSUWkwnSmyQ@mail.gmail.com>
On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
> I think `git add -u` would be closer. It would stage removal of
> files, but would not stage untracked files. It would stage other
> type of changes though.
On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
> Does `git add -A` do what you want?
Thank you Tomas and Antoine. Both of these commands do what I want:
stage deleted files on the index. But does the idea of a `git rm -u`
still sound useful since these commands also stage changes besides
deleted files?
--
ejmr
南無妙法蓮華經
^ permalink raw reply
* Re: [RFC] git rm -u
From: Antoine Pelisse @ 2013-01-19 21:49 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: Eric James Michael Ritz, git
In-Reply-To: <1358632037-ner-2564@calvin>
I think `git add -u` would be closer. It would stage removal of files,
but would not stage untracked files.
It would stage other type of changes though.
On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
<tomas.carnecky@gmail.com> wrote:
> On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz <lobbyjones@gmail.com> wrote:
>> Hello everyone,
>>
>> I am thinking about implementing a feature but I would appreciate any
>> feedback before I begin, because more experienced Git developers and
>> users may see some major problem that I do not.
>>
>> Earlier today I deleted a file from a repository. I deleted it
>> normally, not by using `git rm`. So when I looked at `git status` on
>> my terminal it told me about the file no longer being there. In my
>> sleepy state of mind I ran `git rm -u` without thinking about. I did
>> this because I have a habit of using `git add -u`. I know `git rm`
>> does not support that option, but I tried it anyways without thinking
>> about it.
>>
>> When I came to my senses and realized that does not work I began to
>> wonder if `git rm -u` should exist. If any deleted, tracked files are
>> not part of the index to commit then `git rm -u` would add that change
>> to the index. This would save users the effort of having to type out
>> `git rm <filename>`, and could be useful when a user is deleting
>> multiple files.
>>
>> Does this sound like a reasonable, useful feature to Git? Or is there
>> already a way to accomplish this which I have missed out of ignorance?
>> Any thoughts and feedback would be greatly appreciated.
>
> Does `git add -A` do what you want?
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [RFC] git rm -u
From: Jonathan Nieder @ 2013-01-19 21:49 UTC (permalink / raw)
To: Eric James Michael Ritz; +Cc: git, Tomas Carnecky
In-Reply-To: <50FB1196.2090309@gmail.com>
Eric James Michael Ritz wrote:
> When I came to my senses and realized that does not work I began to
> wonder if `git rm -u` should exist. If any deleted, tracked files are
> not part of the index to commit then `git rm -u` would add that change
> to the index.
I like it. If you have time to write such a patch, I'll be happy to
read it.
Thanks,
Jonathan
^ permalink raw reply
* Re: [RFC] git rm -u
From: Tomas Carnecky @ 2013-01-19 21:47 UTC (permalink / raw)
To: Eric James Michael Ritz, git
In-Reply-To: <50FB1196.2090309@gmail.com>
On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz <lobbyjones@gmail.com> wrote:
> Hello everyone,
>
> I am thinking about implementing a feature but I would appreciate any
> feedback before I begin, because more experienced Git developers and
> users may see some major problem that I do not.
>
> Earlier today I deleted a file from a repository. I deleted it
> normally, not by using `git rm`. So when I looked at `git status` on
> my terminal it told me about the file no longer being there. In my
> sleepy state of mind I ran `git rm -u` without thinking about. I did
> this because I have a habit of using `git add -u`. I know `git rm`
> does not support that option, but I tried it anyways without thinking
> about it.
>
> When I came to my senses and realized that does not work I began to
> wonder if `git rm -u` should exist. If any deleted, tracked files are
> not part of the index to commit then `git rm -u` would add that change
> to the index. This would save users the effort of having to type out
> `git rm <filename>`, and could be useful when a user is deleting
> multiple files.
>
> Does this sound like a reasonable, useful feature to Git? Or is there
> already a way to accomplish this which I have missed out of ignorance?
> Any thoughts and feedback would be greatly appreciated.
Does `git add -A` do what you want?
^ permalink raw reply
* [RFC] git rm -u
From: Eric James Michael Ritz @ 2013-01-19 21:35 UTC (permalink / raw)
To: git
Hello everyone,
I am thinking about implementing a feature but I would appreciate any
feedback before I begin, because more experienced Git developers and
users may see some major problem that I do not.
Earlier today I deleted a file from a repository. I deleted it
normally, not by using `git rm`. So when I looked at `git status` on
my terminal it told me about the file no longer being there. In my
sleepy state of mind I ran `git rm -u` without thinking about. I did
this because I have a habit of using `git add -u`. I know `git rm`
does not support that option, but I tried it anyways without thinking
about it.
When I came to my senses and realized that does not work I began to
wonder if `git rm -u` should exist. If any deleted, tracked files are
not part of the index to commit then `git rm -u` would add that change
to the index. This would save users the effort of having to type out
`git rm <filename>`, and could be useful when a user is deleting
multiple files.
Does this sound like a reasonable, useful feature to Git? Or is there
already a way to accomplish this which I have missed out of ignorance?
Any thoughts and feedback would be greatly appreciated.
--
ejmr
南無妙法蓮華經
^ permalink raw reply
* Re: tar-tree.c dereferencing pointer to incomplete type
From: Jonathan Nieder @ 2013-01-19 21:28 UTC (permalink / raw)
To: git; +Cc: 白い熊, Duy Nguyen, Rene Scharfe
In-Reply-To: <CAPy7p-5vZKzznSny97BZMWHxHPJupO3in7tvjyFOTxBYzw5D4Q@mail.gmail.com>
白い熊 wrote:
> On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
>> Moved it and compiles fine. In fact I moved it back now, so it should
>> be finding it again and it still builds fine, no trace of the prior
>> error. I'm dumbfounded! But at least it compiles...
>
> OK, figured it out. It was indeed the wrong tar.h, the one that was
> making it bomb was the kernel headers tar.h from the Android source.
> That explains it quite well.
Hm. Is there anything to do to make our headers specified with -I
take precedence over unrelated system headers when processing
'#include "foo.h"' directives?
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v3] am: invoke perl's strftime in C locale
From: Dmitry V. Levin @ 2013-01-19 20:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Antoine Pelisse, git
In-Reply-To: <7vehhiqlcx.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1600 bytes --]
On Fri, Jan 18, 2013 at 12:36:46PM -0800, Junio C Hamano wrote:
> "Dmitry V. Levin" <ldv@altlinux.org> writes:
>
> > This fixes "hg" patch format support for locales other than C and en_*.
> > Before the change, git-am was making "Date:" line from hg changeset
> > metadata according to the current locale, and this line was rejected
> > later with "invalid date format" diagnostics because localized date
> > strings are not supported.
> >
> > Reported-by: Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
> > Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
> > ---
> >
> > v3: alternative implementation using setlocale(LC_TIME, "C")
> >
> > git-am.sh | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/git-am.sh b/git-am.sh
> > index c682d34..8677d8c 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -334,7 +334,8 @@ split_patches () {
> > # Since we cannot guarantee that the commit message is in
> > # git-friendly format, we put no Subject: line and just consume
> > # all of the message as the body
> > - perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
> > + perl -M'POSIX qw(strftime :locale_h)' -ne '
> > + BEGIN { setlocale(LC_TIME, "C"); $subject = 0 }
>
> I still haven't convinced myself that this is an improvement over
> the simple "LC_ALL=C LANG=C perl ..." approach.
Personally I prefer 2nd edition that is simpler and does the right thing
(not that LC_ALL=C is necessary and sufficient, you neither need to add
things like LANG=C nor can relax it to LC_TIME=C).
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
From: Torsten Bögershausen @ 2013-01-19 19:36 UTC (permalink / raw)
To: Torsten Bögershausen; +Cc: git
In-Reply-To: <201301190819.29767.tboegi@web.de>
On 19.01.13 08:19, Torsten Bögershausen wrote:
> The test case "add (with different case)" indicates a
> known breakage when run on a case sensitive file system.
>
> The test is invalid for case sensitive file system,
> check the precondition CASE_INSENSITIVE_FS before running it.
Sorry,
this should have been:
> The test case "add (with different case)" indicates a
> known breakage when run on a case insensitive file system.
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-19 19:16 UTC (permalink / raw)
To: Duy Nguyen; +Cc: git, spearce, mfick
In-Reply-To: <CACsJy8C4qx0P621imj5B+HdoJkow0_jaGLVDRvdCDw3YRnK98g@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> Should the client side learn how to list hidden refs too? I'm thinking
> of an extreme case where upload-pack advertises nothing (or maybe just
> refs/heads/master) and it's up to the client to ask for the ref
> selection it's interested in. upload-pack may need more updates to do
> that, I think.
What you are talking about is a different goal.
Look at this as a mechanism for the repository owner to control the
clutter in what is shown to the intended audience of what s/he
publishes in the repository. Network bandwidth reduction of
advertisement is a side effect of clutter reduction, and not
necessarily the primary goal.
It lets me as the repository owner to say "do not list them to make
these discoverable"; letting the client side learn defeats the whole
point of this mechanism.
For example, if you mirror-clone from either of my repositories from
GitHub:
git clone --mirror git://github.com/git/git/
git clone --mirror git://github.com/gitster/git/
you will see stuff that does not belong to the project; objects that
are only reachable from refs/pull/* are not something I approved to
be placed in my repository; I as the project owner do not want to
give these objects to a cloner as if they are part of my project.
The server side can hide refs/pull/ and refs/pull-request-tags/ so
that clones (and ls-remote) will not see clutter, and nobody gets
hurt.
These refs are there only to support GitHub "pull requests"; the
advertisement of them to ls-remote and appearance of them in mirror
clones are undesirable side effects of how GitHub happened to
implement the feature. GitHub has its way to notify of these pull
requests, and it makes these pull requests discoverable out of band
without involving Git.
Ability to say "git fetch origin $SHA1" (or "git fetch origin
pull/1") is the only thing lacking, in order to get rid of these
clutter. The patches do the "get rid of clutter" part by letting
you hide these refs from ls-remote and clone; allowing "fetch by tip
SHA1" needs to come latter.
Another example. If you run ls-remote against the above two
repositories, you will notice that the latter has tons more
branches. The former are to publish only the primary integration
branches, while the latter are to show individual topics.
I wish I didn't have to do this if I could.
We have periodical "What's cooking" postings that let interested
parties learn topics out-of-band. If I can hide refs/heads/??/*
from normal users' clones while actually keeping individual topics
there at the same place, I do not have to push into two places.
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Jeff King @ 2013-01-19 16:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On Fri, Jan 18, 2013 at 04:37:04PM -0800, Junio C Hamano wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
Would you want to do the same thing on receive-pack? It could benefit
from the same reduction in network cost (although it tends to be invoked
less frequently than upload-pack).
At GitHub, we have a similar patch (we even call it hiderefs), but we do
it only for receive-pack. In our case, it is not about network traffic,
but rather that we provide a set of read-only refs in the refs/pull
hierarchy. These are generated upstream by the creation of pull
requests, and we reject any updates to them via the git protocol using a
pre-receive hook.
However, if a client without these refs uses "git push --mirror", it
will attempt to delete them (which will fail). Meaning that a mirror
push will always report failure, because it will always fail to push the
refs/pull deletions.
I don't know much about Gerrit's inner workings. Are refs/changes also
read-only?
-Peff
^ permalink raw reply
* Re: [PATCH v3] am: invoke perl's strftime in C locale
From: Jeff King @ 2013-01-19 16:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dmitry V. Levin, Antoine Pelisse, git
In-Reply-To: <7vehhiqlcx.fsf@alter.siamese.dyndns.org>
On Fri, Jan 18, 2013 at 12:36:46PM -0800, Junio C Hamano wrote:
> > diff --git a/git-am.sh b/git-am.sh
> > index c682d34..8677d8c 100755
> > --- a/git-am.sh
> > +++ b/git-am.sh
> > @@ -334,7 +334,8 @@ split_patches () {
> > # Since we cannot guarantee that the commit message is in
> > # git-friendly format, we put no Subject: line and just consume
> > # all of the message as the body
> > - perl -M'POSIX qw(strftime)' -ne 'BEGIN { $subject = 0 }
> > + perl -M'POSIX qw(strftime :locale_h)' -ne '
> > + BEGIN { setlocale(LC_TIME, "C"); $subject = 0 }
>
> I still haven't convinced myself that this is an improvement over
> the simple "LC_ALL=C LANG=C perl ..." approach.
Yeah, I was the one who brought it up, but I think I was probably being
too nit-picky. It almost certainly doesn't matter, and the alternatives
are just as likely to cause problems.
> I am tempted to use the previous one that puts the whole process
> under LC_ALL=C instead, unless I hear a "we already depend on that
> elsewhere, look at $that_code".
I'm fine with that.
-Peff
^ permalink raw reply
* Aw: Re: [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Thomas Ackermann @ 2013-01-19 15:01 UTC (permalink / raw)
To: davvid, th.acker; +Cc: git
In-Reply-To: <CAJDDKr5_AWFF6MR2Kwt5FzA0vaSE-wx8xFO3xcRnKZ168hXBrg@mail.gmail.com>
>
> What about GITweb?
>
You are right; I missed that because I grepped only for 'GIT' as a whole word.
'gitweb' and 'GITweb' should be changed to 'Gitweb'.
>
> IMO some of these look nicer when everything is lowercase.
> e.g. "standard git committer ident format".
>
IMHO what seems nicer here is the spelling we are all accustomed to.
The whole point of my patch is to use 'Git' consistently when
we are talking about the system and not the individual command.
>
> $ git grep 'git repositor' | wc -l
> 226
>
> These changes touch, for example, git-clone.txt to make it
> say: "Make a 'bare' Git repository". Why not lowercase?
>
When you also apply my second patch you only get 17 occurences of "git repository"
which I missed to change to 'Git repository' ...
Thanks for looking into this!
---
Thomas
^ permalink raw reply
* Re: tar-tree.c dereferencing pointer to incomplete type
From: 白い熊 @ 2013-01-19 14:37 UTC (permalink / raw)
To: git
In-Reply-To: <CAPy7p-7V6y4hfLrYYi_3zGkzGTw2BeF5wh3zPYzumrp+Pbqr+Q@mail.gmail.com>
On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 <ShiroiKuma@shiroikuma.org> wrote:
> Thank you, this must've been it, as it was finding tar.h from glibc.
>
> Moved it and compiles fine. In fact I moved it back now, so it should
> be finding it again and it still builds fine, no trace of the prior
> error. I'm dumbfounded! But at least it compiles...
OK, figured it out. It was indeed the wrong tar.h, the one that was
making it bomb was the kernel headers tar.h from the Android source.
That explains it quite well.
All's good now. Thank you :@)
--
白い熊
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox