On Sat, Jan 19, 2013 at 4:01 AM, John Keeping wrote:
> Since Pyhton
> 2.8 will never exist [1]
Tiny typo: Python misspelled as Pyhton
--
David
--
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://v
On Sat, Jan 19, 2013 at 7:01 AM, Thomas Ackermann 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.
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 s
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
>> c
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?
Th
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
wrote:
> On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz
> wrote:
>> Hello everyo
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 wr
On Sat, 19 Jan 2013 16:35:18 -0500, Eric James Michael Ritz
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 tod
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 r
白い熊 wrote:
> On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 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
On Fri, Jan 18, 2013 at 12:36:46PM -0800, Junio C Hamano wrote:
> "Dmitry V. Levin" 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
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 shou
Duy Nguyen 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
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
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
>
> 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 he
On Sat, Jan 19, 2013 at 6:26 PM, 白い熊 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
On Sat, Jan 19, 2013 at 5:37 PM, Duy Nguyen wrote:
> There is another tar.h somewhere in your system? Stopping the
> compilation after proprocessing should show if it includes the correct
> tar.h.
Thank you, this must've been it, as it was finding tar.h from glibc.
Moved it and compiles fine. In
j...@keeping.me.uk wrote on Sat, 19 Jan 2013 12:01 +:
> git-p4 supports Python 2.6 and later versions of Python 2. Since Pyhton
> 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 Keepi
Le samedi 19 janvier 2013 08:52:25, Junio C Hamano a écrit :
> (2) instead of being inclusive, collecting all executable in
> GIT_EXEC_PATH that happens to be named "git-", add a mode to
> "git help" that lists those that we know to be standard
> commands that the users may want to
On Sat, Jan 19, 2013 at 8:31 PM, 白い熊 wrote:
> Hello:
>
> I'm building v 1.8.1.1 on Android. The build chokes on the builtins
> phase on tar-tree.c with:
>
> CC builtin/tar-tree.o
> builtin/tar-tree.c: In function 'cmd_get_tar_commit_id':
> builtin/tar-tree.c:93:12: error: dereferencing pointer
Hello:
I'm building v 1.8.1.1 on Android. The build chokes on the builtins
phase on tar-tree.c with:
CC builtin/tar-tree.o
builtin/tar-tree.c: In function 'cmd_get_tar_commit_id':
builtin/tar-tree.c:93:12: error: dereferencing pointer to incomplete type
make: *** [builtin/tar-tree.o] Error 1
git-p4 supports Python 2.6 and later versions of Python 2. Since Pyhton
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
---
INSTALL | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Durham Goode wrote:
> In git 1.8.1, when we do 'git svn fetch' on a large repo, we're seeing a
> seg fault. It's caused by git-svn trying to parse a large yaml file
> (introduced in
> https://github.com/git/git/commit/68f532f4ba888f277637a94b4a49136054df0540
> ) which encounters a perl regex sta
Peter Wu wrote:
> Signed-off-by: Peter Wu
Thanks, Signed-off-by: Eric Wong
Will push.
--
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
Signed-off-by: Nguyễn Thái Ngọc Duy
---
The "git reset" as illustrated in the test case is one case people
may be hit by this. We can also do the same for "uptodate" check, but
I'm not sure how that could happen.
t/t1011-read-tree-sparse-checkout.sh | 3 ++-
t/t2021-checkout-overwrite.sh
On Sat, Jan 19, 2013 at 1:59 AM, Thomas Ackermann wrote:
> @@ -55,7 +55,7 @@ History Viewers
>
> - *gitweb* (shipped with git-core)
>
> - GITweb provides full-fledged web interface for GIT repositories.
> + GITweb provides full-fledged web interface for Git repositories.
What about GITweb
Le samedi 19 janvier 2013 09:02:13, Junio C Hamano a écrit :
> If you run "make" on a branch that adds "git check-ignore", checkout
> an older branch that did not know about the command without "make clean",
> and the run t9902 test, the completion script fails to exclude the
> "check-ignore" comma
Le samedi 19 janvier 2013 06:38:54, Torsten Bögershausen a écrit :
> On 18.01.13 23:23, Jean-Noël AVILA wrote:
> > Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> >> Junio C Hamano writes:
> >>> How about doing something like this and set that variable in the
> >>> test instead?
Signed-off-by: Thomas Ackermann
---
Documentation/asciidoc.conf | 2 +-
Documentation/everyday.txt | 4 ++--
Documentation/git-clone.txt | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Documentation/
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
If you run "make" on a branch that adds "git check-ignore", checkout
an older branch that did not know about the command without "make clean",
and the run t9902 test, the completion script fails to exclude the
"check-ignore" command from candidates to complete "check".
This is because the completi
This header not only declares but also defines the contents of the
array that holds the list of command names and help text. Do not
include it in multiple places to waste text space.
Signed-off-by: Junio C Hamano
---
* This is a real "cleanup" patch.
builtin/help.c | 18 --
h
33 matches
Mail list logo
