From: manjian2006 manjian2...@gmail.com
* perl/Git/SVN.pm
Modified according to Eric Wong normalper...@yhbt.net
Hi, I'm interested in this. How much did performance improve by
(and how many revisions is the repository)
Our svn server are built in a LAN,15152 revisions.Not optimized git-svn
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
I already have a local patch that creates a stalenote.txt file, and
includes that in a release-notes(7) man page, but it still leaves
the actual release notes in a separate plain text file, linked from
the man
On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
On 13-12-18 11:04 AM, Marc Branchaud wrote:
Users often find that next and prev do the opposite of what they
expect. For example, next moves to the next match down the list, but
that is almost always backwards in time.
On Tue, Jan 21, 2014 at 07:10:16PM +, Astril Hayato wrote:
Write the gitk config data to $XDG_CONFIG_HOME/git/gitk
($HOME/.config/git/gitk
by default) in line with the XDG specification. This makes it consistent with
git which also follows the spec.
If $HOME/.gitk already exists use
I just noticed that there are exactly four Git manpages with an AUTHOR
section and five with a DOCUMENTATION section:
$ make doc
$ grep -nIE -e '^\.SH DOCUMENTATION|AUTHOR' Documentation/*.[0-9]
Documentation/git-column.1:80:.SH AUTHOR
Documentation/git-for-each-ref.1:272:.SH
Add cross-references between the manpages for git-for-each-ref(1) and
git-show-ref(1).
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
There is a lot of overlap between the functionality of these two
commands. It might be handy to give the user some hints about when to
use one command
On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
These sections are inconsistent with the other manpages and seem
superfluous in a project that has, on the one hand, a public history
and, on the other hand, hundreds of contributors. Would the mentioned
authors
On Wed, Jan 22, 2014 at 12:39 PM, Duy Nguyen pclo...@gmail.com wrote:
On Wed, Jan 22, 2014 at 6:22 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
These sections are inconsistent with the other manpages and seem
superfluous in a project that has, on the one hand, a public history
and, on
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Cheers
Javier Domingo Cansino
[1] Google Code download service change announcement:
Hi,
I want to install git onto my home network - in fact, truth be told,
it's already on my server, but I have some questions as to its
implementation.
First of all, my network. At the 'centre' (practically, if not
logically) is my Mac. I consider this my 'central repository' of
everything.
Hi Michael,
On Wed, 22 Jan 2014, Michael Haggerty wrote:
Would the mentioned authors (CCed) consent to the removal of these
sections?
Fine by me!
Dscho
P.S.: Congrats on your new job!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Jan 22, 2014, at 9:20 AM, John McIntyre joh98@gmail.com wrote:
…
So basically, what I'd like to do is this. I want to write code,
write blg posts, write essays for university, whatever. And I want to
use git to maintain revisions, but where do I store them? Do I make
the Mac my
Thank you for that, Andrew.
I'm going to follow your advice and just set up a test repository,
which won't be a disaster, if it gets damaged or erased.
I backup my /Users/john/Documents from my Mac to /home/john/Documents
on the Linux server. Except for my mail directory, which comes from
On 01/22/2014 12:23 PM, Gordon Freeman wrote:
On 01/22/2014 12:16 PM, Gordon Freeman wrote:
Oh, sorry if i misunderstand you. My english is not so good.
it will be a pleasure if you could explain that.
I did some research about topic branchs, and get a lot of useful info
of workflows on the
Javier Domingo Cansino javier...@gmail.com writes:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Aside from the obvious we won't be able to use something that is no
longer offered? They are
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's wrong with this:
Michael Haggerty mhag...@alum.mit.edu writes:
I just noticed that there are exactly four Git manpages with an AUTHOR
section and five with a DOCUMENTATION section:
$ make doc
$ grep -nIE -e '^\.SH DOCUMENTATION|AUTHOR' Documentation/*.[0-9]
Documentation/git-column.1:80:.SH
Michael Haggerty mhag...@alum.mit.edu writes:
Add cross-references between the manpages for git-for-each-ref(1) and
git-show-ref(1).
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
There is a lot of overlap between the functionality of these two
commands.
Two differences I most
Hello,
I have a RHEL system that I am not the admin of. I needed to install git and
got the source. Everything is okay until I got to this point below. I
downloaded and installed the latest libz (1.2.8) but i installed it under a
local directory under my user name (i.e. /home/ssheikh/local). The
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's
Johannes Sixt j.s...@viscovery.net writes:
[Cc Pat, who added git.rc]
Am 1/22/2014 0:48, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Note that I am merely guessing that short-digit version numbers
are acceptable by now after seeing
Hi,
salmansheikh wrote:
I
downloaded and installed the latest libz (1.2.8) but i installed it under a
local directory under my user name (i.e. /home/ssheikh/local). The problem
is that git only looks in the locations below.
Am 1/22/2014 17:12, schrieb Junio C Hamano:
Johannes Sixt j.s...@viscovery.net writes:
[Cc Pat, who added git.rc]
Am 1/22/2014 0:48, schrieb Junio C Hamano:
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
Note that I am merely guessing that short-digit version numbers
are acceptable by
On Wed, Jan 22, 2014 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down
Johannes Sixt j.s...@viscovery.net writes:
The numbers defined in {FILE,PRODUCT}VERSION statements are intended for
machine consumption and are always 4 positions (if the source contains
fewer, they are padded with zeros). They can be used by installers to
decide whether a file that already
Vicent Martí tan...@gmail.com writes:
Do these consume CPU every time somebody asks for a tarball? That
might be considered wrong depending on the view.
No, our infrastructure caches frequently requested tarballs so they
don't have to be regenerated on the fly.
Thanks. That is certainly
On 01/15/2014 02:10 PM, Robert Hancock wrote:
We have an SVN repository that has a structure for tags (likewise for
branches) like this:
tags/tag1
tags/tag2
tags/tag3/
tags/subdir/tag4
tags/subdir/tag5
The idea is that I want to have git-svn import everything inside subdir
as tags and
Has this patch been released yet?
--
View this message in context:
http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-tp7586671p7602383.html
Sent from the git mailing list archive at Nabble.com.
--
To unsubscribe from this list: send the line unsubscribe
On Wed, Jan 22, 2014 at 3:22 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
I just noticed that there are exactly four Git manpages with an AUTHOR
section and five with a DOCUMENTATION section:
$ make doc
$ grep -nIE -e '^\.SH DOCUMENTATION|AUTHOR' Documentation/*.[0-9]
These quantities can be larger than an int. Use ulong to express
them like the underlying pack-objects does, and also parse them with
the human-friendly unit suffixes.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/repack.c | 12 ++--
1 file changed, 6 insertions(+), 6
We only had code to understand unit suffixes such as g/m/k (as in
2g/400m/8k) in the configuration parser but not in the command line
option parser. git pack-objects worked it around by having a
custom extension to the parse-options API; make it available to
other callers.
The new macro is not
The command line parser was broken when the command was
reimplemented in C in two ways. It incorrectly limited the value
range of window-memory and max-pack-size to int, and also stopped
grokking the unit suffixes like 2g/400m/8k.
These two patches apply on top of 35c14176 (Reword repack
On 2014-01-22 16.59, salmansheikh wrote:
Hello,
I have a RHEL system that I am not the admin of. I needed to install git and
got the source. Everything is okay until I got to this point below. I
downloaded and installed the latest libz (1.2.8) but i installed it under a
local directory
Junio C Hamano gits...@pobox.com writes:
Johannes Sixt j.s...@viscovery.net writes:
...
..., I suggest that we just punt (as per
my patch). That should work out nicely because we can fairly safely assume
that there are no installers around that look at these particular version
numbers.
OK.
On Wed, Jan 22, 2014 at 12:22:23PM +0100, Michael Haggerty wrote:
I just noticed that there are exactly four Git manpages with an AUTHOR
section and five with a DOCUMENTATION section:
These sections are inconsistent with the other manpages and seem
superfluous in a project that has, on the
Paul Mackerras pau...@samba.org writes:
On Tue, Jan 21, 2014 at 10:33:02AM -0500, Marc Branchaud wrote:
On 13-12-18 11:04 AM, Marc Branchaud wrote:
Users often find that next and prev do the opposite of what they
expect. For example, next moves to the next match down the list, but
that
Add test cases that use 'merge-recursive' plumbing with a temporary
index and empty work tree. Populate the index using 'read-tree' and
'update-index --ignore-missing --refresh' to prepare for merge without
actually checking all files out to disk. Verify that each merge
produces its expected
manjian2...@gmail.com wrote:
* perl/Git/SVN.pm
Modified according to Eric Wong normalper...@yhbt.net
Hi, I'm interested in this. How much did performance improve by
(and how many revisions is the repository)
Our svn server are built in a LAN,15152 revisions.Not optimized
git-svn used
Am 20.01.2014 19:25, schrieb Paweł Sikora:
i've noticed that 'git log submodule-dir' and 'git log submodule-dir/'
return different results (module's head changes vs. nothing). is it a bug?
looks like a trailing slash is a problem for git-log.
I think this is a bug, and for example git diff has
On Wed, Jan 22, 2014 at 10:10:18AM -0800, Junio C Hamano wrote:
Vicent Martí tan...@gmail.com writes:
Do these consume CPU every time somebody asks for a tarball? That
might be considered wrong depending on the view.
No, our infrastructure caches frequently requested tarballs so they
On 05.01.2014 14:42, Sebastian Schuberth wrote:
Since 2dce956 is_git_command() is a bit slow as it does file I/O in the
call to list_commands_in_dir(). Avoid the file I/O by adding an early
check for internal commands.
Considering the purpose of the series is it better to say builtin instead
Ken Moffat zarniwh...@ntlworld.com writes:
I note that all of these *are* still available at googlecode for
the moment : https://code.google.com/p/git-core/downloads/list
As I said, Cgc is not the ony download site. The end of
http://git-blame.blogspot.com/p/git-public-repositories.html
On 02.01.2014 22:05, Sebastian Schuberth wrote:
would just leave me wondering I never claimed it was built-in; what's
going on? I think it would be simplest to keep it as
$ git whatever
fatal: cannot handle whatever internally
which at least makes it clear that this is a
From: Linus Torvalds torva...@linux-foundation.org
Date: Wed, 22 Jan 2014 12:32:30 -0800
Subject: [PATCH] Make 'git request-pull' more strict about matching
local/remote branches
The current 'request-pull' will try to find matching commit on the given
remote, and rewrite the please pull line
-Original Message-
Behalf Of Robert Hancock
Sent: Wednesday, January 22, 2014 11:03 AM
Subject: Re: Problem importing from SVN repository with branches/tags at
multiple levels using git-svn
On 01/15/2014 02:10 PM, Robert Hancock wrote:
We have an SVN repository that has a
Got it working but then I had some issues with the perl portions of the
install and I subsequently thought I could eliminate those portions and
tried setting export NO_PERL=1 and that installed everything else...and got
pass this error but when I tried to checkout a git repository as follows, I
On 01/22/2014 12:22 PM, Michael Haggerty wrote:
I just noticed that there are exactly four Git manpages with an AUTHOR
section and five with a DOCUMENTATION section:
$ make doc
$ grep -nIE -e '^\.SH DOCUMENTATION|AUTHOR' Documentation/*.[0-9]
Documentation/git-column.1:80:.SH
Linus Torvalds torva...@linux-foundation.org writes:
This means that git request-pull will never rewrite the ref-name you gave
it. If the local branch name is xyzzy, that is the only branch name
that request-pull will ask the other side to fetch.
If the remote has that branch under a
On Wed, Jan 22, 2014 at 1:46 PM, Junio C Hamano gits...@pobox.com wrote:
The new find local ref code will also complain loudly if you give an
ambiguous refname (eg you have both a tag and a branch with that same
name, and you don't specify heads/name or tags/name).
But this part might be a
On Wed, Jan 22, 2014 at 2:03 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
Any ideas? The hacky way is to do | head -1 to take the first
show-ref output, and then check if you get a different result if you
re-do it using show-ref --tags. But that sounds really excessively
hacky. Is
Linus Torvalds torva...@linux-foundation.org writes:
That may be very helpful if your local tree doesn't match the layout of
the remote branches, but for the common case it's been a recurring
disaster, when request-pull is done against a delayed remote update, and
it rewrites the target
On Wed, Jan 22, 2014 at 2:14 PM, Junio C Hamano gits...@pobox.com wrote:
I looked at 5150.4 and found that what it attempts to do is halfway
sensible.
I agree that it is half-way sensible. The important bit being the HALF part.
The half part is why we have the semantics we have. There's no
Junio C Hamano gits...@pobox.com writes:
... there is no 'for-linus' branch locally, so there is no way for
him to say
git request-pull initial origin for-linus
unless he creates it locally first.
In real life on the kernel list, for-linus may have to be a signed
tag, and pushed
On 22.01.2014 20:58, Junio C Hamano wrote:
The command line parser was broken when the command was
reimplemented in C in two ways. It incorrectly limited the value
range of window-memory and max-pack-size to int, and also stopped
grokking the unit suffixes like 2g/400m/8k.
These two
gits...@pobox.com wrote on Tue, 21 Jan 2014 16:03 -0800:
Pete Wyckoff p...@padd.com writes:
[..]
Patch 03 is a regression fix, found and narrowed down thanks to
much work by Damien Gérard. But it is obscure enough that I'm
not proposing it for a maintenance release.
Thanks.
I am
Since 9d57c4a (git p4: implement view spec wildcards with p4
where, 2013-08-30), all the wildcard types should be supported.
Change must-fail tests to mark that they now pass.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/t9809-git-p4-client-view.sh | 16
1 file changed, 8
There was no test where p4 deleted a file with a wildcard
character. Make sure git p4 applies the wildcard decoding
properly when importing a delete that includes a wildcard.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/t9812-git-p4-wildcards.sh | 27 +++
1 file
Damien Gérard highlights an interesting problem. Some p4
repositories end up with symlinks that have an empty target. It
is not possible to create this with current p4, but they do
indeed exist.
The effect in git p4 is that p4 print on the symlink returns an
empty string, confusing the curret
Commit e9df0f9 (git p4: cygwin p4 client does not mark read-only,
2013-01-26) fixed a problem with test -w on cygwin, but mistakenly
marked the new test as failing. Fix this.
Signed-off-by: Pete Wyckoff p...@padd.com
---
t/t9807-git-p4-submit.sh | 2 +-
1 file changed, 1 insertion(+), 1
The tests use aut...@example.com as the canonical submitter, but
he does not have an entry in the p4 users database. This causes
the generated change description to complain that the git and p4
users disagree. The complaint message is still valid, just isn't
useful in tests. It was introduced
Commit 9d7d446 (git p4: submit files with wildcards, 2012-04-29)
fixed problems with handling files that had p4 wildcard
characters, like @ and *. But it missed one case, that of
RCS keyword scrubbing, which uses p4 fstat to extract type
information. Fix it by calling wildcard_encode() on the
Generating the submit template for p4 uses tempfile.mkstemp(),
which by default puts files in /tmp. For a test that fails,
possibly on purpose, this is not cleaned up. Run with TMPDIR
pointing into the trash directory so the temp files go away
with the test results.
To do this required some
The p4 server can enforce file locking, so that only one user
can edit a file at a time. Git p4 is unable to submit changes
to locked files. Currently it exits poorly. Ideally it would
notice the locked condition and clean up nicely.
Add a bunch of tests that describe the problem, hoping that
When p4 where fails, for whatever reason, the error message tries to
show an undefined variable. This minor bug applies only when using a
client spec, and was introduced recently in 9d57c4a (git p4: implement
view spec wildcards with p4 where, 2013-08-30).
Signed-off-by: Pete Wyckoff
Thomas Rast noticed the docs have a mix of styles when
it comes to options with multiple spellings. Standardize
the couple in git-p4.txt that are odd.
Instead of:
-n, --dry-run::
Do this:
-n::
--dry-run::
See
http://thread.gmane.org/gmane.comp.version-control.git/219936/focus=219945
On Wed, Jan 22, 2014 at 01:04:02PM -0800, Junio C Hamano wrote:
Ken Moffat zarniwh...@ntlworld.com writes:
I note that all of these *are* still available at googlecode for
the moment : https://code.google.com/p/git-core/downloads/list
As I said, Cgc is not the ony download site. The
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
On Thu, Jan 23, 2014 at 3:35 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 20.01.2014 19:25, schrieb Paweł Sikora:
i've noticed that 'git log submodule-dir' and 'git log submodule-dir/'
return different results (module's head changes vs. nothing). is it a bug?
looks like a trailing slash is a
From: Linus Torvalds torva...@linux-foundation.org
Date: Wed, 22 Jan 2014 15:23:48 -0800
Subject: [PATCH] Make request-pull able to take a refspec of form local:remote
This allows a user to say that a local branch has a different name on
the remote server, using the same syntax that git push
On Wed, Jan 22, 2014 at 11:58:05AM -0800, Junio C Hamano wrote:
These quantities can be larger than an int. Use ulong to express
them like the underlying pack-objects does, and also parse them with
the human-friendly unit suffixes.
Hrm. I think that is a valid strategy, but...
- int
On Wed, Jan 22, 2014 at 08:06:42PM -0500, Jeff King wrote:
But I think there is a subtle problem. Here (and elsewhere) we use the
parsed value of 0 as a sentinel. I think that is OK for
--max-pack-size, where 0 is not a reasonable value. But git-repack(1)
says:
--window-memory=0 makes
When we see --max-pack-size, we accidentally propagated
this to pack-objects as --max_pack_size, which does not
work at all.
Signed-off-by: Jeff King p...@peff.net
---
builtin/repack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/repack.c b/builtin/repack.c
index
When we use OPT_STRING to parse an option, we get back a
pointer into the argv array, which should be const char *.
The compiler doesn't notice because it gets passed through a
void * in the option struct.
Signed-off-by: Jeff King p...@peff.net
---
Not a big deal, but just for consistency with
In the original shell version of git-repack, any options
destined for pack-objects were left as strings, and passed
as a whole. Since the C rewrite in commit a1bbc6c (repack:
rewrite the shell script in C, 2013-09-15), we now parse
these values to integers internally, then reformat the
integers
On Wed, Jan 22, 2014 at 08:30:13PM -0500, Jeff King wrote:
- OPT_INTEGER(0, window, window,
+ OPT_STRING(0, window, window, N_(n),
N_(size of the window used for delta
compression)),
By the way, the old code with OPT_INTEGER would always
On Wed, Jan 22, 2014 at 01:27:09PM -0800, salmansheikh wrote:
Got it working but then I had some issues with the perl portions of the
install and I subsequently thought I could eliminate those portions and
tried setting export NO_PERL=1 and that installed everything else...and got
pass this
Hi,
Jeff King wrote:
EWAH is a word-aligned compressed variant of a bitset (i.e. a data
structure that acts as a 0-indexed boolean array for many entries).
I suspect that for some callers it's not word-aligned.
Without the following squashed in, commits 212f2ffb and later fail t5310
on some
On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote:
Two questions: Does regenerating (e.g. if the tarball has dropped
out of the cache) change its sums (md5sum or similar) ? In (beyond)
linuxfromscratch we use md5sums to verify that a tarball has not
changed.
The tarballs we
From: lin zuojian manjian2...@gmail.com
According to profile data, _rev_list and rebuild consume a large
portion of time. Memoize the results of _rev_list and memoize
rebuild internals to avoid subprocess invocation.
When importing 15152 revisions on a LAN, time improved from 10
hours to 3-4
I found git-diff --quiet returns a zero exit status even if there's
a change. The following sequence reproduces the bug:
$ mkdir foo
$ cd foo
$ git init
$ echo a a.txt
$ echo b b.txt
$ git add ?.txt
$ git commit
$ echo b b.txt
$ touch a.txt
$ git diff --quiet; echo $?
manjian2...@gmail.com wrote:
According to profile data, _rev_list and rebuild consume a large
portion of time. Memoize the results of _rev_list and memoize
rebuild internals to avoid subprocess invocation.
When importing 15152 revisions on a LAN, time improved from 10
hours to 3-4 hours.
On Wed, Jan 22, 2014 at 03:58:28PM +0100, Pierre Penninckx wrote:
2013/12/7 Matthew Ogilvie mmogilvi_...@miniinfo.net
Subject: [PATCH 1/4] subtree: support split --rejoin --squash
Allow using --squash with git subtree split --rejoin. It
will still split off (and save to --branch) the
http://git.661346.n2.nabble.com/file/n7602441/nike.jpg
For Nike, that likes a worldwide celebrity. These days, you'll find
innumerable forms of goods manufactured by Nike Provider, on the other hand,
in terms of the most popular kinds, that really should become nike free
damen
From: Johannes Sixt j...@kdbg.org
If the git version number consists of less than three period
separated numbers, then the Windows resource file compilation
issues a syntax error:
$ touch git.rc
$ make V=1 git.res
GIT_VERSION = 1.9.rc0
windres -O coff \
-DMAJOR=1 -DMINOR=9
84 matches
Mail list logo
