2013/5/6 Santi Béjar :
> El 06/05/2013 00:36, "Junio C Hamano" escribió:
>>
>> Johan Herland writes:
>>
>> > This would not allow the user to use the relevant $remote_name for $nick,
>> > which I argue might be the more natural name for the user to use, since
>> > it's the same name that is used
El 06/05/2013 00:36, "Junio C Hamano" escribió:
>
> Johan Herland writes:
>
> > This would not allow the user to use the relevant $remote_name for $nick,
> > which I argue might be the more natural name for the user to use, since
> > it's the same name that is used for otherwise interacting with
Hi,
[Jens, sorry for the re-send - trying to convince gmail to send plain text.]
Just ran into a submodules usability situation at $dayjob that might
be worth looking at.
An internal maintainer was going to pull changes in from a project
team into our repository which is arranged into submodules
We don't care about blobs, or any object other than commits, but in
order to find the type of object, we are parsing the whole thing, which
is slow, specially in big repositories with lots of big files.
There's no need for that, we can query the object information with
sha1_object_info();
Before
We don't need the parsed objects at this point, merely the information
that they have marks.
Seems to be three times faster in my setup with lots of objects.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/built
Hi,
Second try, dropped one fix, and address a few comments.
Parsing the marks of an import of the emacs repository moves fast-export to a
crawl. It takes 14 minutes in my setup, after these patches, it takes 1 second.
The important patches are #2 and #3, the rest are niceities.
Felipe Contrera
It's wrong to call get_sha1() if they should be SHA-1s, plus
inefficient.
Signed-off-by: Felipe Contreras
---
builtin/fast-export.c | 2 +-
fast-import.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index d
Johan Herland writes:
> This would not allow the user to use the relevant $remote_name for $nick,
> which I argue might be the more natural name for the user to use, since
> it's the same name that is used for otherwise interacting with the remote.
That is where we differ.
The thing is, when yo
On Sun, May 5, 2013 at 9:02 PM, Junio C Hamano wrote:
> So another issue that remains is the following, I think.
>
> When interpreting $nick/$name, assuming that we can tell where $nick
> for a remote ends and $name for the ref we take from the remote
> begins [*1*], how would we determine which r
On Sun, May 5, 2013 at 3:58 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> So do you want to queue these on top of the "massive" in 'next', not
>>> directly on 'master'?
>>
>> If they apply on master, master. But I'm confused, are the massive
>> changes not going to graduate to master
Felipe Contreras writes:
>> So do you want to queue these on top of the "massive" in 'next', not
>> directly on 'master'?
>
> If they apply on master, master. But I'm confused, are the massive
> changes not going to graduate to master? Because if not, I should
> cherry-pick the safest changes, as
On Sun, May 5, 2013 at 2:03 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
The previous version had an indentation bug (did I mention I hate python?).
A few fixes to be applied on to
Felipe Contreras writes:
> On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> The previous version had an indentation bug (did I mention I hate python?).
>>>
>>> A few fixes to be applied on top of the massive changes already queued.
>>> Nothing
>>> major.
Johan Herland writes:
> I want to extend the same reasoning to remote-tracking refs, i.e.
> "$remote/$name" could be auto-completed into any of
>
> refs/remotes/$remote/$name
> refs/remotes/$remote/tags/$name
> refs/remotes/$remote/heads/$name
>
> without causing ambiguity in the common cas
On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> The previous version had an indentation bug (did I mention I hate python?).
>>
>> A few fixes to be applied on top of the massive changes already queued.
>> Nothing
>> major.
>
> [2/2] may not matter much in th
Felipe Contreras writes:
> The previous version had an indentation bug (did I mention I hate python?).
>
> A few fixes to be applied on top of the massive changes already queued.
> Nothing
> major.
[2/2] may not matter much in the context of my tree (people would
use post 1.8.2 fast-export if t
Felipe Contreras writes:
> I already sent this, but it has had the unfortunate luck of getting stuck with
> a bunch of irrelevant patches in 'next'.
>
> This is not only good enough for 'master', but probably even 'maint'.
Will apply for 1.8.3 (1.8.2.x may follow later). Thanks for a
reminder.
History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.
While this was consistent with the default behaviour, this could be
extremely unhelpful when searching detailed history, and could not be
overridden. For example, if a merge had ignored a chang
Reimplement commit 4b7f53da on top of the new simplify-merges
infrastructure, tightening the condition to only consider root parents;
the original version incorrectly dropped parents that were TREESAME to
anything.
Original log message follows.
The merge simplification rule stated in 6546b59 (rev
Add a BOTTOM flag to commit objects, and use it to define priority for
pruning. Priority commits are those that are !UNINTERESTING or BOTTOM,
and this allows us to identify irrelevant side branches (UNINTERESTING
&& !BOTTOM).
If a merge has priority parents, and it is TREESAME to them, then do
not
When growing the table, take the opportunity to "compact" it by removing
entries with NULL decoration.
Users may have "removed" decorations by passing NULL to
insert_decoration. An object's table entry can't actually be removed
during normal operation, as it would break the linear hash collision
s
In preparation for upcoming TREESAME work, check the result for G.t,
which is dropped in "-s ours" merge L. The default rev-list is empty, as
expected - it follows the first parent path where it never existed.
Unfortunately, --ancestry-path is also empty. Merges H J and L are all
TREESAME to 1 par
torva...@linux-foundation.org wrote on Fri, 26 Apr 2013 13:31 -0700:
> Anyway, I think your patch is good if for no other reason that it
> allows this kind of testing, but at least for my machine, clearly the
> current default of eight threads is actually "good enough". Maybe
> somebody with a very
New version - nothing much changed since v2.2, except the new test
set to illustrate and prove the changes. Not sure about the t6111
numbering - there wasn't space where I really wanted to put it.
And maybe it should be appended to one of the existing tests.
You will note that I'm floundering for
In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.
Signed-off-by: Kevin Bracey
---
Documentation/rev-list-options.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/rev-list-optio
When simplifying an odd merge, such as one that used "-s ours", we may
find ourselves TREESAME to apparently redundant parents. Prevent
simplify_merges() from removing every TREESAME parent; if this would
happen reinstate the first TREESAME parent - the one that the default
log would have followed.
From: Junio C Hamano
Signed-off-by: Junio C Hamano
---
t/t6012-rev-list-simplify.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index dd6dc84..4e55872 100755
--- a/t/t6012-rev-list
Some side branching and odd merging to illustrate various flaws in
revision list scans, particularly when limiting the list.
Many expected failures, which will be gone by the end of the "history
traversal refinements" series.
Signed-off-by: Kevin Bracey
---
t/t6111-rev-list-treesame.sh | 180 ++
On Fri, May 3, 2013 at 9:06 PM, Jiang Xin wrote:
> 2013/5/3 Eric Sunshine :
>> More generally, is this sort of modal edit mode desirable and
>> convenient? Can the edit operation be combined with the top-level
>> prompt? For example:
>>
>> % git clean -i
>> file1 file2 file3
>> file4 file5 f
On Sun, May 5, 2013 at 1:55 AM, Johan Herland wrote:
> When expanding shorthand refs to full ref names (e.g. in dwim_ref()),
> we use the ref_rev_parse_rules list of expansion patterns. This list
> allows "origin" to be expanded into "refs/remotes/origin/HEAD", by
> using the "refs/remotes/%.*s/HE
On Sun, May 5, 2013 at 6:28 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> The "$remote/$branch" syntax can be interpreted in two subtly different
>> ways:
>>
>> 1. A shorthand name for the remote-tracking branch corresponding to a
>> specific $branch from a specific $remote.
>>
>>
Junio C Hamano writes:
> Is 'master' a descendant of v3.3? I.e. what does
>
> git rev-list master..v3.3
>
> say?
Yes, this shows nothing. Although 'master' is a descendant of v3.3, it
is not a --first-parent descendant of anything after v3.0.0.
--
To unsubscribe from this list: send the
Sorry about that - a recent PR that was merged changed the routes that
handled this for some reason. I just added the historical routes back
and they all should work again.
Scott
On Wed, May 1, 2013 at 8:57 PM, Konstantin Khomoutov
wrote:
> On Wed, 1 May 2013 14:38:02 -0400
> Jeff King wrote:
lexgrog(1) relies on the NAME section to find a manpage's subject's
name and description for easy access later using "man -k". Add the
section it expects.
Noticed using lintian.
Signed-off-by: Jonathan Nieder
---
Hi Eric,
Just noticed this by running a tool to sanity-check my build result.
I h
34 matches
Mail list logo
