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).
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
often
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 p...@peff.net
---
There is also
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)
Am 01.07.2013 18:46, schrieb Junio C Hamano:
Stefan Näwe stefan.na...@atlas-elektronik.com 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
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
+ then
+
Am 7/2/2013 0:50, schrieb Alexey Shumkin:
On Mon, Jul 01, 2013 at 09:00:55AM +0200, Johannes Sixt wrote:
Am 6/26/2013 12:19, schrieb Alexey Shumkin:
test_expect_success 'setup complex body' '
git config i18n.commitencoding iso8859-1
echo change2 foo git commit -a -F commit-msg
On Tue, Jul 2, 2013 at 2:24 AM, Jeff King p...@peff.net wrote:
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
Hi,
for my Linux-kernel build-script I am searching for a reliable check
of getting the ***latest*** version.
This could be 'v3.x.y-stable' or 'v3.x.y-rcX'.
'git tag' seems to be fast, but not reliable.
'git log --oneline' is slow, but does the job.
For getting v3.x.y-stable this seems to
Hello,
Sorry for the late reply.
Junio C Hamano gits...@pobox.com writes:
Junio C Hamano gits...@pobox.com writes:
You should use ${var:+if_set_to_nonempty_use_this} here.
...
So munging it manually with sloppy sed script is simply wrong.
Perhaps something like this on top of your patch
Merge strategy and its options can be specified in `git rebase`,
but with `--interactive`, they were completely ignored.
Signed-off-by: Arnaud Fontaine ar...@debian.org
---
git-rebase--interactive.sh| 21 -
t/t3404-rebase-interactive.sh | 11 +++
2 files changed,
On Mon, Jul 1, 2013 at 2:39 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com 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
@@
On 07/01/2013 09:54 PM, Miklos Vajna wrote:
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 vmik...@suse.cz
---
On Mon,
Sedat Dilek wrote:
for my Linux-kernel build-script I am searching for a reliable check
of getting the ***latest*** version.
$ git describe HEAD
If you want a sorted list of tags,
$ git for-each-ref --sort=taggerdate --format=%(refname:short) refs/tags
Are you looking for something else?
On Mon, Jul 1, 2013 at 2:50 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
Accept multiple patch files rather than only one. For example:
% git contacts feature/*.patch
Signed-off-by: Eric Sunshine sunsh...@sunshineco.com
@@ -93,6 +96,7 @@ sub
On 2013-05-24 01:23, Alois Mahdal wrote:
[...]
When I use `git log --follow file` all is OK, but once I add
`--reverse` to it, it no longer follows the file beyond renames.
This makes it hard to query for when the file was really added,
which I was trying to achieve with
$ git -1
On Mon, Jul 1, 2013 at 1:00 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
No attempt is made to answer Junio's v9 review[5], as I lack sufficient
insight with '-C' options to be able to respond properly.
I just wanted to see if we want to allow the
-ref --sort=taggerdate --format=%(refname:short)
refs/tags | grep ^'next-[0-9]*' | tail -1
next-20130702
Another question if I may ask:
Sometimes I need to bisect a previous Linux-Next version.
What I am doing is to have the latest Linux-v3.x.y(-rcX) as stable base.
$ git checkout upstream
$ git
On 07/01/2013 11:58 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
Alois Mahdal wrote:
This [has been reported][1] to this list about half a year ago
but with no response so I'm not even sure if it's been
acknowledged as bug.
Yes, this is a bug. However, it is not at all easy to fix; so I would
recommend that you contribute a documentation patch/ failing
On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:
Hello!
This [has been reported][1] to this list about half a year ago
but with no response so I'm not even sure if it's been
acknowledged as bug.
[1]: http://marc.info/?l=gitm=135215709307126q=raw
When I use `git log
On 07/02/2013 05:02 AM, Martin Fick wrote:
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
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
On Fri, May 24, 2013 at 01:23:24AM +0200, Alois Mahdal wrote:
Hello!
This [has been reported][1] to this list about half a year ago
but with no response so I'm not even sure if it's been
acknowledged as bug.
[1]:
Lukas Fleischer g...@cryptocrack.de writes:
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
[...]
$ git log --oneline --follow builtin/clone.c | wc -l
125
$ git log --oneline --follow --reverse builtin/clone.c | wc -l
3
I just wanted to point out that it works
On 02/07/13 04:48, Junio C Hamano wrote:
Chris Packham judge.pack...@gmail.com writes:
+!*)
+command=$(expr $update_module : '!\(.*\)')
command=${command#!}
Thanks, expr was my attempt to avoid using a ${command:1} bash-ism. v3
on
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
On Tue, Jul 02, 2013 at 11:51:42AM +0200, Thomas Rast wrote:
Lukas Fleischer g...@cryptocrack.de writes:
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
[...]
$ git log --oneline --follow builtin/clone.c | wc -l
125
$ git log --oneline --follow --reverse
:
$ git merge next-20130628
In the process, next-20130628 hasn't changed: you can still use it as a
bisect endpoint.
If I have all -next tags merged-in, I will get always today's 'next-20130702'.
Due to my poor git skillz I do this manually for git-bisect sessions.
*scratches head*
Can you
can also fetch all tags:
$ git fetch --tags
and decide what to do with them later:
$ git merge next-20130628
In the process, next-20130628 hasn't changed: you can still use it as a
bisect endpoint.
If I have all -next tags merged-in, I will get always today's
'next-20130702'.
Due
Am 5/24/2013 1:23, schrieb Alois Mahdal:
...query for when the file was really added,
which I was trying to achieve with
$ git -1 --reverse --follow several_times_renamed_file
Assuming you meant 'git log -1 ...' or similar. It won't do what you think
it would do because:
* -1 is a
On Mon, Jul 1, 2013 at 11:56 PM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net writes:
On Tue, May 21, 2013 at 5:35 PM, Junio C Hamano gits...@pobox.com wrote:
... I think we can go either way, and the above I think this is
being rerolld was primarily keeping the
Check us out at!
http://www.apollobayrealestate.com.au/onlinegirls.html
--
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
Check us out at!
http://www.apollobayrealestate.com.au/onlinegirls.html
--
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
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 vmik...@suse.cz
---
builtin/merge.c | 55
There are often parent pages logically above the gitweb projects
list, e.g. home pages of the organization and department that host
the gitweb server. This change allows you to include links to those
pages in gitweb's breadcrumb trail.
Signed-off-by: Tony Finch d...@dotat.at
---
Kyle McKay mack...@gmail.com writes:
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 the ssh scp form, optional leading '/'
3) Optional trailing .git
Andreas.
--
Andreas Schwab,
Am 02.07.2013 12:12, schrieb Chris Packham:
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
On Tuesday, July 02, 2013 03:24:14 am Michael Haggerty
wrote:
git rev-list HEAD | for nn in $(seq 0 100) ; do for c
in $(seq 0 1) ; do read sha ; echo $sha
refs/c/$nn/$c$nn ; done ; done .git/packed-refs
I believe this generates a packed-refs file that is not
sorted
Fredrik Gustafsson iv...@iveqy.com writes:
This was actually a bit tricky. When I changed
git clone $depth
to
git clone $depth
git clone dies with the error too many arguments.
... when $depth is empty.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7
Signed-off-by: Michal Sojka sojk...@fel.cvut.cz
---
contrib/emacs/git-blame.el | 17 +
1 file changed, 17 insertions(+)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 573f408..5c8933e 100644
--- a/contrib/emacs/git-blame.el
+++
Hi all,
following are a few fixes and enhancements to Emacs' git-blame-mode
(contrib/emacs/git-blame.el).
Michal Sojka (4):
git-blame.el: Fix buffer local declaration
git-blame.el: Make all line prefixes to have the same length
git-blame.el: Allow displaying author/commit times
git-blame-cache was declared buffer-local two times and
git-blame-idle-timer is global. The intended meaning was probably to make
git-blame-idle-timer buffer-local.
Signed-off-by: Michal Sojka sojk...@fel.cvut.cz
---
contrib/emacs/git-blame.el | 2 +-
1 file changed, 1 insertion(+), 1
Now, the format resembles more the default format of `git blame`.
Signed-off-by: Michal Sojka sojk...@fel.cvut.cz
---
contrib/emacs/git-blame.el | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/emacs/git-blame.el b/contrib/emacs/git-blame.el
index 5c8933e..74b1486
Without this patch, the beginning of git-blame.el in emacs buffer looks
like this (note the Messige-ID line):
b52ba1 jna...@gmail.com:;; Authors:David Kågedal dav...@lysator.liu.se
b52ba1 jna...@gmail.com:;; Created:31 Jan 2007
28389d dav...@lysator.liu.se:;; Message-ID:
On Tuesday, July 02, 2013 12:11:49 am Jeff King wrote:
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
Sending again because the first one bounced.
Am 02.07.2013 03:39, schrieb Fredrik Gustafsson:
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
On Mon, Jul 1, 2013 at 10:01 PM, Jeff King p...@peff.net wrote:
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,
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. 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
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
While I wasn't paying much attention to this, I vaguely recall that
people pointed out that using a fresh clone every time may not be
what you want to do in the first place, and I happen to agree with
them (and that is why I am not very
Eric Sunshine sunsh...@sunshineco.com writes:
The author name and email can be grabbed from the blame output
without doing this (and the result may be more robust), but you
would need to read from the log message anyway, so I think this is
OK.
Note that the names and emails in blame output
Michael Haggerty mhag...@alum.mit.edu writes:
You allow --no-ff-only but ignore it, which I think is incorrect. In
git merge --ff-only --no-ff-only [...]
, the --no-ff-only should presumably cancel the effect of the previous
--ff-only (i.e., be equivalent to --ff).
Ideally, if we were
Michael Haggerty mhag...@alum.mit.edu writes:
I have a logistical question: git-multimail doesn't have its own mailing
list, and GitHub doesn't offer one. I was thinking about setting up a
Google group, but a few people at GitMerge suggested that I instead
direct discussion of git-multimail
Fredrik Gustafsson iv...@iveqy.com writes:
git clone dies with the error too many arguments. This was solved with
changing
depth=$5
to
depth=$5
which I don't understand since variable assignment doesn't expand $5 and
therefore
should not be needed, AFAIK. Any comments on this?
A red
On Tue, Jul 2, 2013 at 2:32 PM, Junio C Hamano gits...@pobox.com wrote:
Eric Sunshine sunsh...@sunshineco.com writes:
The author name and email can be grabbed from the blame output
without doing this (and the result may be more robust), but you
would need to read from the log message anyway,
Thomas Rast tr...@inf.ethz.ch writes:
Lukas Fleischer g...@cryptocrack.de writes:
On Tue, Jul 02, 2013 at 10:19:36AM +0100, John Keeping wrote:
[...]
$ git log --oneline --follow builtin/clone.c | wc -l
125
$ git log --oneline --follow --reverse builtin/clone.c | wc -l
3
Hi,
I figured that we should quickly read through git-multimail and give
it an on-list review. Hopefully, it'll educate the list about what
this is, and help improve the script itself.
Sources: https://github.com/mhagger/git-multimail
git_multimail.py wrote:
#! /usr/bin/env python2
Do all
Alexey Shumkin alex.crez...@gmail.com writes:
v8 of this patch series includes the following changes against v7:
Oops, isn't this already in 'next'? In that case, please feed
incremental updates on top of the patches that are already queued as
improvements and fixes.
Thanks.
--
To unsubscribe
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to do this currently, is it planned, or
would it be deemed useful
On Tue, Jul 02, 2013 at 12:37:13PM -0700, Ed Hutchins wrote:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there any way to
Ed Hutchins e...@demeterr.com writes:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example).
Hmm. I think the current thinking so
Miklos Vajna vmik...@suse.cz writes:
if (fast_forward == FF_ONLY)
fast_forward = FF_ALLOW;
Do we really want --no-ff-only? I would rather just disable it, see the
updated patch.
Sounds sane.
I'm no options guru, but I think it would be possible to implement --ff
and --no-ff
On Tue, Jul 2, 2013 at 9:37 PM, Ed Hutchins e...@demeterr.com wrote:
I realize that branch names are ephemeral repo-specific things, but it
would be really useful to be able to determine what branch a commit
was authored from (as a hint to ancestry graph layout tools, for
example). Is there
I'm not sure I follow how it could be actively harmful? I would think
the author branch
nomenclature (as opposed to just calling it branch) along with clear
documentation
that these values are just captures of the particular state the commit
was authored
from would more than assuage any potential
When using git fetch --prune, git will remove any branches from
remotes/origin/ that have inconsistent case in folder names.
This issue has been verified in versions 1.7.10.2, 1.7.11.1 and 1.8.3.2.
I've described the reproduction steps here as I carried them out, and
listed the plaforms I used
On Wed, Jul 03, 2013 at 12:53:39AM +0530, Ramkumar Ramachandra wrote:
class CommandError(Exception):
def __init__(self, cmd, retcode):
self.cmd = cmd
self.retcode = retcode
Exception.__init__(
self,
'Command %s failed with retcode
Consider these two scenarios.
1. If you are collaborating with others and you have arranged with
the participants to rewind a shared branch, you would do
something like this:
$ git fetch origin branch
... fetch everything so that we won't lose anything ...
$ git
Am 02.07.2013 20:08, schrieb Fredrik Gustafsson:
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. This is useful when the
submodule(s) are huge and you're not really interested in anything but
the latest commit.
Tests are
On Fri, Jun 28, 2013 at 03:41:34PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Here, git pull . branch1 is merely saying I want to integrate
the work on my current branch with that of branch1 without saying
how that integration wants to happen.
The change that
John Keeping wrote:
I have to say that I don't think this is a particularly useful review,
you seem to have skipped huge portions of the code and spent a lot of
time making us read your thought process rather than providing
constructive feedback. What feedback there is mostly seems to be
Add the --depth option to the add and update commands of git submodule,
which is then passed on to the clone command. 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 some indention adjustments were made to
Ramkumar Ramachandra artag...@gmail.com writes:
def get(self, name, default=''):
try:
values = self._split(read_git_output(
['config', '--get', '--null', '%s.%s' % (self.section,
name)],
env=self.env, keepends=True,
From: Benoit Person benoit.per...@ensimag.fr
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the
From: Benoit Person benoit.per...@ensimag.fr
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki
From: Benoit Person benoit.per...@ensimag.fr
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to
From: Benoit Person benoit.per...@ensimag.fr
The #7 issue on git-mediawiki's issue tracker [1] states that the ability to
preview content without pushing would be a nice thing to have.
changes from v6:
- Rewrite of bin-wrapper/git in 3/7
- Update wrap-for-bin.sh and make bin-wrappers
From: Benoit Person benoit.per...@ensimag.fr
For now, bin-wrappers (based on wrap-for-bin.sh) redefine some
environnement variables (like $GITPERLLIB). If we want to chain to
those scripts and define one of those variables before, our changes
will be overwritten.
This patch simply makes the
From: Benoit Person benoit.per...@ensimag.fr
Until now, if git-remote-mediawiki was not installed, the test suite
copied it to the toplevel directory. This solution pollutes the
directory with untracked files. Plus, we would need to copy the new
git-mw.perl file to test it too.
Signed-off-by:
From: Benoit Person benoit.per...@ensimag.fr
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the
From: Benoit Person benoit.per...@ensimag.fr
Currently, the mw-to-git project contains only a remote helper
(git-remote-mediawiki.perl). To improve the user experience while
working with mediawiki remotes, new tools, designed for such cases,
should be created. To achieve this goal, the project
On Tue, Jul 2, 2013 at 10:57 PM, Junio C Hamano gits...@pobox.com wrote:
[...]
(2) Add --compare-and-swap=dst:expect parameters, e.g.
$ git push --cas=master:deadbabecafe --cas=next:cafebabe :
This removes the reservation I expressed against (1) above
(i.e. we are doing
benoit.per...@ensimag.fr writes:
From: Benoit Person benoit.per...@ensimag.fr
Currently, the mw-to-git project contains only a remote helper
(git-remote-mediawiki.perl). To improve the user experience while
working with mediawiki remotes, new tools, designed for such cases,
should be
benoit.per...@ensimag.fr writes:
From: Benoit Person benoit.per...@ensimag.fr
For now, bin-wrappers (based on wrap-for-bin.sh) redefine some
environnement variables (like $GITPERLLIB). If we want to chain to
those scripts and define one of those variables before, our changes
will be
benoit.per...@ensimag.fr writes:
+GIT_ROOT_DIR=../../..
+GIT_EXEC_PATH=$(cd $(dirname $0) cd ${GIT_ROOT_DIR} pwd)
+
+GITPERLLIB=$GIT_EXEC_PATH'/contrib/mw-to-git:'$GITPERLLIB
The same comment on ':' applies here.
+PATH=$GIT_EXEC_PATH'/contrib/mw-to-git:'$PATH
But not to this, as PATH is
Do we want to add that ':' unconditionally? Could GITPERLLIB be
empty?
For now, GITPERLLIB is only used in that kind of statements:
use lib (split(/:/, $ENV{GITPERLLIB} || ... ));
The trailing ':' does not really matter, split will ignore it.
With the current codebase, I think it's nicer to
On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann jens.lehm...@web.de wrote:
Am 02.07.2013 12:12, schrieb Chris Packham:
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -159,7 +159,9 @@ update::
This will make the submodules HEAD be detached unless `--rebase`
From: Brandon Casey draf...@gmail.com
When pushing, each ref in the local repository must be paired with a
ref advertised by the remote server. Currently, this is performed by
first applying the refspec to the local ref to transform the local ref
into the name of the remote ref, and then
86 matches
Mail list logo
