Michael Haggerty mhag...@alum.mit.edu writes:
die() with an error message if the argument is not a non-negative
integer. This change tightens up parsing: '+' and '-', leading
whitespace, and trailing junk are all disallowed now.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
Michael Haggerty mhag...@alum.mit.edu writes:
This tightens up the parsing a bit:
* Leading whitespace is no longer allowed
* '+' and '-' are no longer allowed
It also removes the need to check separately that max_count is
non-negative.
Hmmm, on the surface this sound nice, but I am not
Thanks all .. I will have a look. But could I just set this up on my laptop and
checking this works on system first before installing one of Git on server
Sent from my iPhone
On 18 Mar 2015, at 22:28, Doug Kelly dougk@gmail.com wrote:
On Wed, Mar 18, 2015 at 2:53 PM, Randall S. Becker
Dear Invited Author,
Have you uploaded your invited paper for our conferences in Barcelona, Spain
7-9 April 2015? If not, kindly, upload now your INVITED paper via www. inase.
org until
March 20, 2015.
We have collaboration with 36 Journals, all with Impact Factor from ISI
(Thomson Reuters)
Jeff King p...@peff.net writes:
I wonder how much of the boilerplate in the parse_* functions could be
factored out to use a uintmax_t, with the caller just providing the
range. That would make it easier to add new types like off_t, and
possibly even constrained types (e.g., an integer from 0
Junio C Hamano gits...@pobox.com writes:
Ah, wait.
I suspect that it all cancels out.
...
Now, as you mentioned, there _may_ be codepaths that uses the same
definition of what's in the index as what diff-cache used to take
before your patches, and they may be broken by removing the
Michael Haggerty mhag...@alum.mit.edu writes:
Here were my thoughts:
* I wanted to change the interface to look less like
strtol()/strtoul(), so it seemed appropriate to make the names
more dissimilar.
One reason I prefer the names in the compat-util is that it makes it
clear that what
Michael Haggerty mhag...@alum.mit.edu writes:
* It allows leading whitespace.
This might be blessing in disguise. Our friends on MacOS may be
relying on that
git cmd --abbrev=$(wc -c foo)
to work as expected, even though their wc gives leading spaces,
for example.
* It allows arbitrary
Jeff King p...@peff.net writes:
I wondered if we could do away with the radix entirely. Wouldn't we be
asking for base 10 most of the time? Of course, your first few patches
show octal parsing, but I wonder if we should actually have a separate
parse_mode() for that, since that seems to be
Kevin Daudt m...@ikke.info writes:
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Because this is not
Hi,
the Git for Windows team just released the first maintenance release of
the Windows-specific installers for git 1.9.5.
It can be downloaded from the usual place [1] and I also attached some
(although non-gpg-signed) SHA sums [2].
New Features
- Comes with Git 1.9.5 plus Windows-specific
On Wed, Mar 18, 2015 at 02:05:09PM +0530, Sundararajan R wrote:
The failure case which occurs on teaching git is taught the '-' shorthand
is when there exists no branch pointed to by '@{-1}'. But, if there is a file
named - in the working tree, the user can be unambiguously assumed to be
From: Junio C Hamano gits...@pobox.com
Sent: Tuesday, March 17, 2015 6:33 PM
Christian Couder christian.cou...@gmail.com writes:
On Mon, Mar 16, 2015 at 10:05 PM, Junio C Hamano gits...@pobox.com
wrote:
However, you can say git bisect bad rev (and git bisect good
rev for that matter) on a
On Thu, Mar 19, 2015 at 02:15:19PM -0700, Junio C Hamano wrote:
Trevor Saunders tbsau...@tbsaunde.org writes:
On one hand it seems kind of user hostile to just toss out any changes
in the submodule that are uncommitted, on the other for any other path
it would seem weird to have git
Hi,
I've noticed that the 'submodule.$name.url' config parameter from the
main repository is ignored when a submodule needs to be updated, the
submodule's 'remote.origin.url' is used instead. Is there any way to
customize the submodule url for both the initial clone and for
updates?
--
Dmitry
--
On Wed, Mar 18, 2015 at 9:58 PM, John Keeping j...@keeping.me.uk wrote:
On Wed, Mar 18, 2015 at 09:41:59PM +0700, Duy Nguyen wrote:
On Wed, Mar 18, 2015 at 9:33 PM, Duy Nguyen pclo...@gmail.com wrote:
If not, I made some mistake in analyzing this and we'll start again.
I did make one
On Wed, Mar 18, 2015 at 10:14 PM, Graham Hay grahamr...@gmail.com wrote:
Got there eventually!
$ git verify-pack --verbose bar.pack
e13e21a1f49704ed35ddc3b15b6111a5f9b34702 commit 220 152 12
03691863451ef9db6c69493da1fa556f9338a01d commit 334 227 164
... snip ...
chain length = 50: 2
When using the git-p4.py script, I found that if I used a client spec when
cloning out a perforce repository, and then using a git-p4.py rebase, that
the rebase command would be using the current perforce client spec,
instead of the one used when doing the initial clone. My proposed patch
causes
Sundararajan R venit, vidit, dixit 19.03.2015 12:22:
Hi all,
I am a Computer Science sophomore at IIT Kanpur. I am interested in
contributing to git in GSoC 2015. I have been using git for the past one year
and am pretty comfortable with its commands which is what made me think about
Hi all,
I am a Computer Science sophomore at IIT Kanpur. I am interested in
contributing to git in GSoC 2015. I have been using git for the past one year
and am pretty comfortable with its commands which is what made me think about
contributing to git. I have attempted the microproject “adding
On Thu, Mar 19, 2015 at 9:32 PM, Jeff King p...@peff.net wrote:
On Thu, Mar 19, 2015 at 09:16:52PM -0400, Eric Sunshine wrote:
--- /dev/null
+++ b/t/t5312-prune-corruption.sh
@@ -0,0 +1,104 @@
+# we do not want to count on running pack-refs to
+# actually pack it, as it is perfectly
On Thu, Mar 19, 2015 at 09:16:52PM -0400, Eric Sunshine wrote:
--- /dev/null
+++ b/t/t5312-prune-corruption.sh
@@ -0,0 +1,104 @@
+# we do not want to count on running pack-refs to
+# actually pack it, as it is perfectly reasonable to
+# skip processing a broken ref
So today I had a shocking moment while I was doing my cherry-pick,
after I performed all the pre-checkin duties (the usual build the
code, run the test to make sure the cherry-pick infact works), I found
out that my original commit was already cherry-picked, then I found
out someone in engineering
On 03/19/2015 08:24 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
Now that we have ref_transaction_*, I think if git-fetch fed all of the
deletes (along with the updates) into a single transaction, we would get
the same optimization for free. Maybe that is even part
On Thu, Mar 19, 2015 at 10:25:32PM -0400, Jeff King wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..02a03d5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -524,6 +524,21 @@ test_eval_ () {
test_run_ () {
test_cleanup=:
expecting_failure=$2
+
+ if
On Tue, Mar 17, 2015 at 3:28 AM, Jeff King p...@peff.net wrote:
When we are doing a destructive operation like git prune,
we want to be extra careful that the set of reachable tips
we compute is valid. If there is any corruption or oddity,
we are better off aborting the operation and letting
On Tue, Mar 17, 2015 at 3:31 AM, Jeff King p...@peff.net wrote:
When we delete a ref, we have to rewrite the entire
packed-refs file. We take this opportunity to curate the
packed-refs file and drop any entries that are crufty or
broken.
Dropping broken entries (e.g., with bogus names, or
On Thu, Mar 19, 2015 at 09:37:12PM -0400, Eric Sunshine wrote:
Thanks. I notice that a large number of broken -chains are on
here-docs. I really wish you could put the on the EOF line at the
end of the here-doc. I understand _why_ that this not the case, but
mentally it is where I want
On Fri, Mar 20, 2015 at 12:03:43AM +0100, Thomas Braun wrote:
Hi,
the Git for Windows team just released the first maintenance release of
the Windows-specific installers for git 1.9.5.
is it expected that there is no corresponding release on
https://github.com/git-for-windows/git/releases ?
[+cc Jonathan, whose patch I apparently subconsciously copied]
On Thu, Mar 19, 2015 at 10:08:51PM -0400, Jeff King wrote:
diff --git a/t/test-lib.sh b/t/test-lib.sh
index c096778..02a03d5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -524,6 +524,21 @@ test_eval_ () {
test_run_ () {
rev-list --bisect is used by git bisect, but never together with
--first-parent. Because rev-list --bisect together with --first-parent
is not handled currently, and even leads to segfaults, refuse to use
both options together.
Because this is not supported, it makes little sense to use git log
Hi, I was expecting that sparse checkout could be used to avoid the
checking out, by git, of files which have colons in their name into the
worktree when on Windows.
Yue Lin Ho reported on the Msygit list [1] that he had a repo where
there was already committed a file with a colon in it's
On Thu, Mar 19, 2015 at 03:49:08PM +0100, Michael Haggerty wrote:
For pruning, we can't use a ref_transaction as it is currently
implemented because it would fail if any of the reference deletions
failed. But in this case I think if any deletions fail, we would prefer
to emit a warning but
Duy Nguyen pclo...@gmail.com writes:
On Mon, Mar 16, 2015 at 8:18 PM, Mike Hommey m...@glandium.org wrote:
On Mon, Mar 16, 2015 at 05:13:25PM +0700, Duy Nguyen wrote:
On Mon, Mar 16, 2015 at 3:05 PM, Mike Hommey m...@glandium.org wrote:
Hi,
git-verify-pack's man page says the following
Jeff King p...@peff.net writes:
+test_expect_success 'create history with missing tip commit' '
+ test_tick git commit --allow-empty -m one
+ recoverable=$(git rev-parse HEAD)
+ git cat-file commit $recoverable saved
+ test_tick git commit --allow-empty -m two
+
Jeff King p...@peff.net writes:
diff --git a/refs.c b/refs.c
index e23542b..7f0e7be 100644
--- a/refs.c
+++ b/refs.c
@@ -1934,6 +1934,11 @@ static int do_for_each_ref(struct ref_cache *refs,
const char *base,
data.fn = fn;
data.cb_data = cb_data;
+ if (ref_paranoia
Michael J Gruber drmi...@warpmail.net writes:
Do we have a merge driver or something for the l10n files?
I haven't heard of any, but given that these can be added back by
running xgettext and the result will have the up-to-date line
numbers, it wouldn't be wrong to define a script that roughly
I want to use a custom url for both initial submodule clone and
submodule update. Git submodule man page states that if I run 'git
submodule init' and then change the 'submodule.$name.url' in the main
repository config, git will use this url instead of url in
.gitmodules. Git does use the custom
On Thu, Mar 19, 2015 at 4:27 AM, Dmitry Neverov
dmitry.neve...@gmail.com wrote:
Hi,
I've noticed that the 'submodule.$name.url' config parameter from the
main repository is ignored when a submodule needs to be updated, the
submodule's 'remote.origin.url' is used instead. Is there any way to
Eric Sunshine sunsh...@sunshineco.com writes:
I also tend to favor adding failure tests which are flipped to
success when appropriate, however, as this is an entirely new
feature, this approach may be unsuitable (and perhaps overkill).
I can buy the overkill, but not unsuitable. Even for new
SZEDER Gábor sze...@ira.uka.de writes:
Possible solutions to avoid this issue are:
- Strip the current working directory from $PATH temporarily while we run
'git help -a' to get all the available commands. Care must be taken,
because '.' can appear at the very beginning, end, or in the
Jeff King p...@peff.net writes:
...
And there we stop. We don't pass the refs list out of that function
(which, as an aside, is probably a leak). Instead, we depend on the list
of heads we already knew in the to_fetch array. That comes from
processing the earlier list of refs returned from
Do we have a merge driver or something for the l10n files?
I'm trying to rebase an older branch on top of origin/next. My topic
branch has changes to git.pot (the old glossary command idea), and
rebasing produces a lot of conflicts due to simple line number changes
in the comments. (The de.po in
On 03/06/2015 11:59 PM, Jeff King wrote:
On Fri, Mar 06, 2015 at 05:48:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
The --prune option to fetch added in v1.6.5-8-gf360d84 seems to be
around 20-30x slower than the equivalent operation with git remote
prune. I'm wondering if I'm missing
On Thu, Mar 19, 2015 at 10:41:50AM -0700, Junio C Hamano wrote:
Just to make sure we do not keep this hanging forever and eventually
forget it, I'm planning to queue this.
Thanks for following up. A few minor nits (and maybe a more serious
problem) on the explanation in the commit message:
Jeff King p...@peff.net writes:
- The only caller of everything_local(), do_fetch_pack(), returns
this list of ref, whose element has bogus new_sha1 values, to its
caller. It does not look at the elements and acts on them.
I'm not sure what the final sentence means. Should it be It
Michael Haggerty mhag...@alum.mit.edu writes:
Now that we have ref_transaction_*, I think if git-fetch fed all of the
deletes (along with the updates) into a single transaction, we would get
the same optimization for free. Maybe that is even part of some of the
pending ref_transaction work
Graham Hay grahamr...@gmail.com writes:
We have a fairly large repo (~2.4GB), mainly due to binary resources
(for an ios app). I know this can generally be a problem, but I have a
specific question.
If I cut a branch, and edit a few (non-binary) files, and push, what
should be uploaded? I
Trevor Saunders tbsau...@tbsaunde.org writes:
If a user does git checkout HEAD -- path/to/submodule they'd expect the
submodule to be checked out to the commit that submodule is at in HEAD.
Hmmm.
Is it a good idea to do that unconditionally by hard-coding the
behaviour like this patch does?
On Thu, Mar 19, 2015 at 11:53:10AM -0700, Junio C Hamano wrote:
Trevor Saunders tbsau...@tbsaunde.org writes:
If a user does git checkout HEAD -- path/to/submodule they'd expect the
submodule to be checked out to the commit that submodule is at in HEAD.
Hmmm.
Is it a good idea to do
On Thu, Mar 19, 2015 at 12:01:26PM -0700, Junio C Hamano wrote:
I'm working up a few patches in that area, which I'll send out in a few
minutes. Once that is done, then I think the explanation you give above
would be correct.
If a follow-up is coming then I'd just drop this one. Thanks.
On Mon, Mar 16, 2015 at 6:15 PM, Jeff King p...@peff.net wrote:
On Mon, Mar 09, 2015 at 09:37:25PM -0400, Stephen Morton wrote:
3. Not sure how long this part takes. It takes 1/3 - 1/2 of the time
when straced, but I think it's much less, as little as 10s when not
straced.
It then reads a
If the server supports allow_tip_sha1_in_want, then
fetch-pack's filter_refs function tries to check whether a
ref is a request for a straight sha1 by running:
if (get_sha1_hex(ref-name, ref-old_sha1))
...
I.e., we are using get_sha1_hex to ask is this ref name a
sha1?. If it is
If the server supports allow_tip_sha1_in_want, we add any
unmatched raw-sha1 entries in our sought list of refs to
the list of refs we will ask the other side for. We do so by
inserting the original struct ref directly into our list,
rather than making a copy. This has several problems.
The most
When fetch_refs_via_pack calls fetch_pack(), we pass a
list of refs to fetch, and the function returns either a
copy of that list, with the fetched items filled in, or
NULL. We check the return value to see whether the fetch was
successful, but do not otherwise look at the copy, and
simply leak it
On Thu, Mar 19, 2015 at 01:13:13PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
diff --git a/refs.c b/refs.c
index e23542b..7f0e7be 100644
--- a/refs.c
+++ b/refs.c
@@ -1934,6 +1934,11 @@ static int do_for_each_ref(struct ref_cache *refs,
const char *base,
On Thu, Mar 19, 2015 at 07:14:52AM +, Bharat Suvarna wrote:
Thanks all .. I will have a look. But could I just set this up on my laptop
and checking this works on system first before installing one of Git on server
Sure, that's no problem. Git happily runs just locally on your own
Jeff King p...@peff.net writes:
A safer check may be to pack and then make it missing, I guess, but
I do not know if the difference matters.
Yeah, I considered that. The trouble is that we are relying on the
earlier setup that made the object go missing. We cannot pack the refs
in the setup
On Thu, Mar 19, 2015 at 12:24:21PM -0700, Junio C Hamano wrote:
For pruning, we can't use a ref_transaction as it is currently
implemented because it would fail if any of the reference deletions
failed. But in this case I think if any deletions fail, we would prefer
to emit a warning but
In everything_local(), we used to assign the current ref's value
found in ref-old_sha1 to ref-new_sha1 when we already have all the
necessary objects to complete the history leading to that
commit. This copying was broken at 49bb805e (Do not ask for
objects known to be complete., 2005-10-19) and
On Thu, Mar 19, 2015 at 01:04:16PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+test_expect_success 'create history with missing tip commit' '
+ test_tick git commit --allow-empty -m one
+ recoverable=$(git rev-parse HEAD)
+ git cat-file commit $recoverable
On Thu, Mar 19, 2015 at 04:31:36PM -0400, Stephen Morton wrote:
Hmm. The push process must feed the set of object boundaries to
pack-objects so it knows what to pack (i.e., what we want to send, and
what the other side has).
120,000 is an awfully large number of objects to be pass
Jeff King p...@peff.net writes:
I wonder if the thinking in the original was that it was our
responsibility here to make sure that ref-old_sha1 was filled in.
I am reasonably sure that is the (perhaps mistaken) reasoning behind
the use of old_sha1 as the second parameter to get_sha1_hex().
Sorry, my bad. I thought 'git submodule sync' changes only
'submodule.$name.url' in main repository config, but it also changes
the 'remote.origin.url' in submodule's config. I indeed ran 'git
submodule sync', that's why the default url was used even though
'submodule.$name.url' had a different
Jeff King p...@peff.net writes:
+ if (ref_paranoia 0)
+ ref_paranoia = git_env_bool(GIT_REF_PARANOIA, 0);
+ if (ref_paranoia)
+ data.flags |= DO_FOR_EACH_INCLUDE_BROKEN;
I am not a big fan of proliferation of interfaces based on
environment variables, but
On Thu, Mar 19, 2015 at 02:23:25PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
A safer check may be to pack and then make it missing, I guess, but
I do not know if the difference matters.
Yeah, I considered that. The trouble is that we are relying on the
earlier
Jeff King p...@peff.net writes:
So I'm inclined to leave it (we do confirm with the rev-parse call at
the end of the setup that our packed-refs file is working) unless you
feel strongly. If you do, I'd rather go the route of sticking each
corruption in its own separate sub-repo.
No, I don't
On Thu, Mar 19, 2015 at 02:31:39PM -0700, Junio C Hamano wrote:
We do have to have this variable cross some process boundaries. Only
repack knows whether to turn on paranoia, but pack-objects is the
one that must act on it.
Or is there something else I'm missing?
In general, I do not
On Thu, Mar 19, 2015 at 02:49:37PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
So I'm inclined to leave it (we do confirm with the rev-parse call at
the end of the setup that our packed-refs file is working) unless you
feel strongly. If you do, I'd rather go the route of
On Wed, Mar 18, 2015 at 3:26 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Mar 18, 2015 at 3:04 AM, Paul Tan pyoka...@gmail.com wrote:
t0302 now tests git-credential-store's support for the XDG user-specific
configuration file $XDG_CONFIG_HOME/git/credentials. Specifically:
---
On Wed, Mar 18, 2015 at 6:04 PM, Doug Kelly dougk@gmail.com wrote:
On Wed, Mar 18, 2015 at 3:20 AM, Chris Packham judge.pack...@gmail.com
wrote:
My $0.02 based on $dayjob
(disclaimer I've never used subtree)
On Wed, Mar 18, 2015 at 11:14 AM, Robert Dailey
rcdailey.li...@gmail.com
On Thu, Mar 19, 2015 at 12:28:09PM +, Sam Bishop wrote:
When using the git-p4.py script, I found that if I used a client spec when
cloning out a perforce repository, and then using a git-p4.py rebase, that
the rebase command would be using the current perforce client spec,
instead of the
When repositories are organized in a hierarchial directory tree
it is convenient if gitweb project categories can be set
automatically based on their parent directory, so that users
do not have to set the same information twice.
Signed-off-by: Tony Finch d...@dotat.at
---
When $projects_list_category_is_directory is turned on, project
categories can be useful as project filters, so with that setting
gitweb now makes the category headings into project_filter links
(like the breadcrumbs).
Signed-off-by: Tony Finch d...@dotat.at
---
gitweb/gitweb.perl | 14
Previously gitweb would ignore partial PATH_INFO. For example,
it would produce a project list for the top URL
https://www.example.org/projects/
and a project summary for
https://www.example.org/projects/git/git.git
but if you tried to list just the git-related projects with
Previously when a project filter was active, the only simple way
to clear it was by clicking the home link in the breadcrumbs, which
is not very obvious.
This change adds another home link under the search box which clears
both project filter and search, next to the existing link that
clears the
Signed-off-by: Tony Finch d...@dotat.at
---
Documentation/gitweb.conf.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/gitweb.conf.txt b/Documentation/gitweb.conf.txt
index ebe7a6c..29f1e06 100644
--- a/Documentation/gitweb.conf.txt
+++
77 matches
Mail list logo
