Am 7/2/2013 1:19, schrieb Alexey Shumkin:
> +commit_msg() {
> + # String "initial. initial" partly in German
> + # (translated with Google Translate),
> + # encoded in UTF-8, used as a commit log message below.
> + msg=$(printf "initial. anf\303\244nglich")
> + if test -n "$1"
> +
Am 01.07.2013 18:46, schrieb Junio C Hamano:
> Stefan Näwe writes:
>
>>> Is there any reason why 'git clone -b' only takes a branch (from
>>> refs/heads/)
>>> or a tag (from refs/tags/) ?
>
> Because they are common enough, and doing the same for an arbitrary
> object is just as easy to do some
When we call find_common to start finding common ancestors
with the remote side of a fetch, the first thing we do is
insert the tip of each ref into our rev_list linked list. We
keep the list sorted the whole time with
commit_list_insert_by_date, which means our insertion ends
up doing O(n^2) times
This helper function was introduced as a prio_queue
comparator to help topological sorting. However, other users
of prio_queue who want to replace commit_list_insert_by_date
will want to use it, too. So let's make it public.
Signed-off-by: Jeff King
---
There is also compare_commits_by_author_dat
We insert the commit pointed to by each ref one-by-one into
the "complete" commit_list using insert_by_date. Because
each insertion is O(n), we end up with O(n^2) behavior.
This typically doesn't matter, because the number of refs is
reasonably small. And even if there are a lot of refs, they
ofte
Here are my patches to deal with Martin's pathological case, split out
for easy reading. I took a few timings to show that the results of the
3rd patch are noticeable even with 50,000 unique refs (which is still a
lot, but something that I could conceive of a busy repo accumulating
over time).
[
On Mon, Jul 01, 2013 at 10:19:51PM -0700, Junio C Hamano wrote:
> > Like the patch below, which is built on top of next (which has Junio's
> > prio_queue implementation), and has both the priority queue fix for
> > rev_list_push and the mark_complete sort-at-the-end fix.
>
> Wow, I saw "160 lines
Jeff King writes:
> On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:
>
>> I replicated your test setup, and the problem is that we have many
>> common objects on both sides during the ref negotiation. So we end up in
>> rev_list_push for each one, which has the same O(n^2) behavior.
>>
One test in t1512 that expects a failure incorrectly passed. The
test prepares a commit whose object name begins with ten "0"s, and
also prepares a tag that points at the commit. The object name of
the tag also begins with ten "0"s. There is no other commit-ish
object in the repository whose nam
The earliest iteration of this test script used a magic string
110282 as the common prefix for ambiguous object names, but the
final edition switched the common prefix to 00 (10 "0"s).
Unfortunately, instances of the original prefix were left in the
comments and a few tests. Replace them
Here is a small two-patch series to break a test that has been
passing by mistake.
Junio C Hamano (2):
t1512: correct leftover constants from earlier edition
get_short_sha1(): correctly disambiguate type-limited abbreviation
sha1_name.c | 2 +-
t/t1512-rev-parse-disa
On Tue, Jul 02, 2013 at 12:41:51AM -0400, Jeff King wrote:
> I replicated your test setup, and the problem is that we have many
> common objects on both sides during the ref negotiation. So we end up in
> rev_list_push for each one, which has the same O(n^2) behavior.
> Switching it to just sort a
On Tue, Jul 02, 2013 at 12:07:58AM -0400, Jeff King wrote:
> And yet another alternative would be to keep the list unsorted during
> the mark_complete calls, and then sort it at the end. Like this:
Amusingly, I seem to have posted the exact same patch last year:
http://article.gmane.org/gmane.
On Mon, Jul 01, 2013 at 09:02:31PM -0600, Martin Fick wrote:
> A simple synthetic test case with 1M refs all pointing to the same
> sha1 seems to be easily handled by git these days. However, in our
> experience with our internal git repo, we still have performance
> issues related to having too
I have often reported problems with git fetch when there are
many refs in a repo, and I have been pleasantly surprised
how many problems I reported were so quickly fixed. :) With
time, others have created various synthetic test cases to
ensure that git can handle many many refs. A simple
synt
When a submodule is clone, clone it width the --depth flag. This is useful
when the submodule(s) are huge and you're not really interested in anything
but the latest commit.
Tests are added and to make --depth work the path for test "setup a submodule
tree" had to be modified. Also did some indent
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin
---
t/t4205-log-pretty-formats.sh | 48 +++
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/t/t4205-log-pretty-forma
One can set an alias
$ git config [--global] alias.lg "log --graph
--pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=local"
to see the log as a pretty tree (like *gitk* but in a terminal).
However, log m
One can set an alias
$ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
-%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
--abbrev-commit --date=local"
to see the log as a pretty tree (like *gitk* but in a terminal).
However, log messages writ
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin
---
t/t6006-rev-list-format.sh | 140 +
1 file changed, 77 insertions(+), 63 deletions(-)
diff --git a/t/t6006-rev-list-format.
v8 of this patch series includes the following changes against v7:
1. [PATCH v8 1/5] t6006 (rev-list-format): don't hardcode SHA-1 in expected
outputs
untouched
2. [PATCH v8 2/5] t7102 (reset): don't hardcode SHA-1 in expected outputs
untouched
3. [PATCH v8 3/5] t4205 (log-pretty-f
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Alexey Shumkin
---
t/t7102-reset.sh | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/t/t7102-reset.sh b/t/t7102-reset.sh
index df82ec9..05dfb27 100755
--- a/t/t
Kyle McKay writes:
> I was not previously aware that URLs not shown on that page were
> accepted, thank you for bringing it to my attention.
>
> Do you feel that it's important to accept these alternate URL versions
> that are not listed on the project page:
>
> 1) Optional trailing '/'
> 2) For
On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
> Am 6/26/2013 12:19, schrieb Alexey Shumkin:
> > One can set an alias
> > $ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
> > -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
> > --abbrev-c
My apologies.
repo.or.cz recently had some updates to support:
1) smart HTTP fetch
2) smart HTTP push (over https)
3) user removal of projects
Along with those updates it started doing more validation on paths.
I believe all the paths listed on http://repo.or.cz/w/alt-git.git are
accepted as
Junio C Hamano writes:
> Has something changed recently at repo.or.cz, accepting pushes over
> ssh, in the past few days? I am getting this:
>
> $ git push -n -v repo.or.cz:srv/git/alt-git.git/
> 403 forbidden
> fatal: Could not read from remote repository.
Seems like repo is being
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
We are in the middle of 5th week now in the 11-week releace cycle
for 1.8.4, and quite a few topics have graduated to 'master'.
Please help ensu
Junio C Hamano writes:
> Has something changed recently at repo.or.cz, accepting pushes over
> ssh, in the past few days? I am getting this:
>
> $ git push -n -v repo.or.cz:srv/git/alt-git.git/
> 403 forbidden
> fatal: Could not read from remote repository.
>
> Please make sure y
It is now in the middle of 5th week of this release cycle [*1*], and
due to the season being summer and with US holidays, I expect that
things will be more quiet than other weeks. It was a good time to
review the recent issues of whats-cooking, and that is what I just
did.
Here is a list of topic
Has something changed recently at repo.or.cz, accepting pushes over
ssh, in the past few days? I am getting this:
$ git push -n -v repo.or.cz:srv/git/alt-git.git/
403 forbidden
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
a
Jens Lehmann writes:
> Am 02.06.2013 20:50, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>
>>> Am 30.05.2013 01:58, schrieb Junio C Hamano:
* jl/submodule-mv (2013-04-23) 5 commits
(merged to 'next' on 2013-04-23 at c04f574)
+ submodule.c: duplicate real_path's return valu
Drew Northup writes:
> On Sun, Jun 2, 2013 at 7:58 PM, Junio C Hamano wrote:
> ...
>> --
>> [Stalled]
> ...
>> * jk/gitweb-utf8 (2013-04-08) 4 commits
>> - gitweb: Fix broken blob action parameters on blob/commitdiff pages
>> - gitweb: Don't appe
John Keeping writes:
> This series addressed Dave Abraham's recent bug report [1] about using
> fast-import's "ls" command with an empty path. I also found a couple of
> other places that do not handle the empty path when it can reasonably be
> interpreted as meaning the root tree object, which
Michael Haggerty writes:
> My understanding is that we are waiting on two things:
>
> 1. Consensus from the community. I would characterize the feedback on
> the mailing list as limited in quantity but strongly positive [1-4] and
> I think that most/all of the wishes for post-receive-email featu
Heiko Voigt writes:
> This is only for review. I will resubmit this once 1.8.3 is out.
Ping?
No need to hurry, but just to make sure this didn't disappear from
everybody's radar.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vge
Johan Herland writes:
> On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano wrote:
>> ... I think we can go either way, and the above "I think this is
>> being rerolld" was primarily keeping the options open.
>
> You're right. No point in setting things prematurely in stone. I'll
> fold jh/shorten-r
Ramsay Jones writes:
> Yes, I will send a v2 (soon-ish, I hope).
Ping?
No need to hurry, but just to make sure this didn't disappear from
everybody's radar.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majo
From: Petr Baudis
"stash save" is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree. When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs
When the working tree walker encounters a directory, it asks the
function treat_directory() if it should descend into it, show it as
an untracked directory, or do something else. When the directory is
the top of the submodule working tree, we used to say "That is an
untracked directory", which was
The second patch is the real thing, but "ls-files --killed" needed
to be taught about submodules to avoid breaking "stash save" in a
repository with submodules, as the new safety uses it to detect what
will need to be killed (i.e. file D/F in the working tree getting
removed because we need to chec
On Mon, Jul 01, 2013 at 02:28:52PM -0700, Junio C Hamano wrote:
> I have no time to dig this down, but I just noticed this by accident:
>
> $ make
> $ cd t
> $ sh ./t7011-skip-worktree-reading.sh -d
> $ cd trash*.t7011*
> $ git reset --hard HEAD
> err
I have no time to dig this down, but I just noticed this by accident:
$ make
$ cd t
$ sh ./t7011-skip-worktree-reading.sh -d
$ cd trash*.t7011*
$ git reset --hard HEAD
error: Entry '1' not uptodate. Cannot merge.
fatal: Could not reset index
Miklos Vajna writes:
> On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
> wrote:
>> If I find the time (unlikely) I might submit a patch to implement these
>> expectations.
>
> Seeing that the --no-ff / --ff-only combo wasn't denied just sort of
> accidently, I agree that it makes mo
On Sat, 22 Jun 2013 23:21:03 +, Junio C Hamano wrote:
...
> Are there examples of other daemon programs outside Git that have
> this particular support to help such inetd implementations?
Unfortunately I only know one server that exclusively uses this
interface, and isn't even capable of runni
This has multiple benefits: with more than one of {"--ff", "--no-ff",
"--ff-only"} respects the last option; also the command-line option to
always take precedence over the config file option.
Signed-off-by: Miklos Vajna
---
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
wrote:
> I
Brian Gernhardt writes:
> OS X's sed only accepts basic regular expressions, which does not
> allow the + quantifier. However '..*' (anything, followed by zero or
> more anything) is the same as '.\+' (one or more anything) and valid
> in any regular expression language.
Thanks for spotting thi
Junio C Hamano writes:
> - If the patch were prepared with a non-standard src/dst-prefix,
>unconditional substr($1, 2) would call blame on a wrong (and
>likely to be nonexistent) path without a useful diagnosis (the
>invocation of "git blame" will likely die with "no such path
>'
On Mon, Jul 1, 2013 at 11:47 AM, Colby Ranger wrote:
>> But I think we are comparing
>> apples to steaks here, Vincent is (rightfully) concerned about process
>> startup performance, whereas our timings were assuming the process was
>> already running.
>>
>
> I did some timing on loading the rever
OS X's sed only accepts basic regular expressions, which does not
allow the + quantifier. However '..*' (anything, followed by zero or
more anything) is the same as '.\+' (one or more anything) and valid
in any regular expression language.
Signed-off-by: Brian Gernhardt
---
t/t4205-log-pretty-f
Junio C Hamano writes:
> while (<$f>) {
> if (/^From ([0-9a-f]{40}) Mon Sep 17 00:00:00 2001$/) {
> # beginning of a patch
> $id = $1;
> }
> next if (!defined $id);
> # inline the body of s
Eric Sunshine writes:
> Accept multiple patch files rather than only one. For example:
>
> % git contacts feature/*.patch
>
> Signed-off-by: Eric Sunshine
> @@ -93,6 +96,7 @@ sub commits_from_patch {
> while (<$f>) {
> if (/^From ($id_rx) /o) {
> $id
> Right, the format and implementation in JGit can do "Counting objects"
> in 87ms for the Linux kernel history.
Actually, that was the timing when I first pushed the change. With the
improvements submitted throughout the year, we can do counting in
50ms, on my same machine.
> But I think we are
Eric Sunshine writes:
> diff --git a/contrib/contacts/git-contacts b/contrib/contacts/git-contacts
> new file mode 100755
> index 000..9007bae
> --- /dev/null
> +++ b/contrib/contacts/git-contacts
> @@ -0,0 +1,121 @@
> +#!/usr/bin/perl
> +
> +# List people who might be interested in a patch.
It would be nice to support more generic specs for the --branch
switch. But it is complicated because the refs have not been fetched
yet during the clone, and so normal refs operations -- which expect to
work on a local repository -- do not work. So, the ref is looked up
locally from a list in exp
Excerpts from Junio C Hamano's message of Mon Jul 01 09:52:05 -0700 2013:
> Wow. How could all of us missed this for a long time?
:-) I don't know, but little is more frustrating than a misleading
diagnostic.
BTW, I didn't expect git-send-email to send those two messages in a
thread. I'll keep
Eric Sunshine writes:
> In this submission, the command name has changed to git-contacts since
> git-related felt too generic. (git-contacts seemed best of several
> possibilities I surveyed: git-people, git-interested, git-mentioned,
> git-blame-us.)
I admit I am pretty bad at naming, but "cont
Andrew Pimlott writes:
> Applies on top of rebase -i patch already accepted. Mostly whitespace
> changes.
Thanks, will queue.
--
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/ma
Andrew Pimlott writes:
> Signed-off-by: Andrew Pimlott
> ---
> t/t7500-commit.sh |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
> index 436b7b6..e166ac8 100755
> --- a/t/t7500-commit.sh
> +++ b/t/t7500-commit.sh
> @@ -13,8 +
Chris Packham writes:
> + !*)
> + command="$(expr "$update_module" : '!\(.*\)')"
command=${command#!}
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo in
Stefan Näwe writes:
>> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
>> or a tag (from refs/tags/) ?
Because they are common enough, and doing the same for an arbitrary
object is just as easy to do something like:
git clone -n
git checkout $an_arb
Miklos Vajna writes:
> OK, so if I get it right, the problem is that users got used to
> that the --ff-only not only means a precondition for the merge,
> but also means "either don't create a merge commit or fail", while
> my patch would change this second behaviour.
It is not just "users got u
Chris Packham writes:
> Subject: Re: [RFC/PATCHv2] submodule: add ability to configure update command
"ability to configure" wants to be rephrased to make it more useful
in the shortlog output to help me update release notes ;-)
Subject: [PATCH] submodule update: allow custom update command
Excerpts from Junio C Hamano's message of Thu Jun 27 13:50:45 -0700 2013:
> Andrew Pimlott writes:
>
> > I should update the function I introduced first. I will re-submit
> > the rebase -i --autosquash patch and wait for acceptance before
> > trying to fix other things.
>
> Thanks.
Applies on
Signed-off-by: Andrew Pimlott
---
t/lib-rebase.sh |2 ++
1 file changed, 2 insertions(+)
diff --git a/t/lib-rebase.sh b/t/lib-rebase.sh
index cfd3409..7f119e2 100644
--- a/t/lib-rebase.sh
+++ b/t/lib-rebase.sh
@@ -17,6 +17,8 @@
# ("squash", "fixup", "edit", or "reword") and the SHA1
Signed-off-by: Andrew Pimlott
---
t/t7500-commit.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
index 436b7b6..e166ac8 100755
--- a/t/t7500-commit.sh
+++ b/t/t7500-commit.sh
@@ -13,8 +13,8 @@ commit_msg_is () {
expect=c
Jens Lindström writes:
> On Fri, Jun 28, 2013 at 8:38 PM, Junio C Hamano wrote:
>
>>> The pack-*.keep files are temporary, and serve no purpose in the
>>> clone.
>>
>> They are not temporary, actually. A user can deliberatey create a
>> "keep" marker after packing with a good set of parameters,
On Mon, Jul 01, 2013 at 08:38:21AM -0700, Junio C Hamano
wrote:
> As to "--no-ff" vs "--ff-only", "--ff-only" has always meant "only
> fast-forward updates are allowed. We do not want to create a merge
> commit with this operation." I do agree with you that the proposed
> patch changes the esta
Michael Haggerty writes:
> So I think that command invocations with more than one of {"--ff",
> "--no-ff", "--ff-only"} should respect the last option listed rather
> than complaining about "cannot combine options".
>
> If I find the time (unlikely) I might submit a patch to implement these
> exp
Hi Michael,
On Mon, Jul 01, 2013 at 04:52:29PM +0200, Michael Haggerty
wrote:
> On 07/01/2013 09:01 AM, Miklos Vajna wrote:
> > 1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
> > 2009-10-29) says this is not allowed, as they contradict each other.
> >
> > However, --ff-only is
On 07/01/2013 09:01 AM, Miklos Vajna wrote:
> 1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
> 2009-10-29) says this is not allowed, as they contradict each other.
>
> However, --ff-only is about asserting the input of the merge, and
> --no-ff is about instructing merge to always
On Fri, Jun 28, 2013 at 8:38 PM, Junio C Hamano wrote:
>> The pack-*.keep files are temporary, and serve no purpose in the
>> clone.
>
> They are not temporary, actually. A user can deliberatey create a
> "keep" marker after packing with a good set of parameters, so that
> the resulting pack will
Users can set submodule.$name.update to '!command' which will cause
'command' to be run instead of checkout/merge/rebase. This allows the
user some finer grained control over how the update is done. The primary
motivation for this was interoperability with stgit however being able
to intercept the
On 01/07/13 03:30, Jens Lehmann wrote:
> Am 29.06.2013 11:11, schrieb Chris Packham:
>> On 28/06/13 22:42, Fredrik Gustafsson wrote:
>>> technically it looks fine to me (except for the lack of tests) but I'm
>>> not sure I follow the use case.
>>>
>>> In your case, you want to run a script to deter
Benoît Person writes:
> Another idea crossed my mind: for now the test suite creates a symlink
> of git-remote-mediawiki in the toplevel if it's not installed. It
> would be better to use the bin-wrapper in the testsuite I think ?
Absolutely. The symlink was a dirty hack waiting for a better sol
brian m. carlson:
int offset = 0;
+ static const unsigned int max_codepoint[] = {
+ 0x7f, 0x7ff, 0x, 0x1f
+ };
Since Unicode is not defined beyond U+10, you can easily make the
last range end at U+10FFF. Doing that, ...
if (code
brian m. carlson:
+ /* Check the value here */
+ if (codepoint >= 0xd800 && codepoint <= 0xdfff)
+ return bad_offset;
if ((x & 0xF800) == 0xD800)
is slightly shorter, albeit a bit more difficult to read.
Please also consider adding some c
Am 28.06.2013 13:59, schrieb Stefan Näwe:
> Hi there!
>
> Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
> or a tag (from refs/tags/) ?
>
> Background: At $dayjob we're using some kind of 'hidden' refs (in
> refs/releases/)
> to communicate between the 'branch inte
1347483 (Teach 'git merge' and 'git pull' the option --ff-only,
2009-10-29) says this is not allowed, as they contradict each other.
However, --ff-only is about asserting the input of the merge, and
--no-ff is about instructing merge to always create a merge commit, i.e.
it makes sense to use thes
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
> One can set an alias
> $ git config alias.lg "log --graph --pretty=format:'%Cred%h%Creset
> -%C(yellow)%d%Creset %s %Cgreen(%cd) %C(bold blue)<%an>%Creset'
> --abbrev-commit --date=local"
>
> to see the log as a pretty tree (like *git
79 matches
Mail list logo
