Jed Brown j...@59a2.org writes:
$ git rev-list --count v3.2..master
9651
$ git rev-list --count v3.3..master
6378
$ git describe --tags master
v3.2-9651-ga018267
Is 'master' a descendant of v3.3? I.e. what does
git rev-list master..v3.3
say?
--
To unsubscribe from this list:
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 jrnie...@gmail.com
---
Hi Eric,
Just noticed this by running a tool to sanity-check my
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
kostix+...@007spb.ru wrote:
On Wed, 1 May 2013 14:38:02 -0400
Junio C Hamano gits...@pobox.com 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
On Sun, May 5, 2013 at 6:28 AM, Junio C Hamano gits...@pobox.com wrote:
Johan Herland jo...@herland.net 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
On Sun, May 5, 2013 at 1:55 AM, Johan Herland jo...@herland.net 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
On Fri, May 3, 2013 at 9:06 PM, Jiang Xin worldhello@gmail.com wrote:
2013/5/3 Eric Sunshine sunsh...@sunshineco.com:
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
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 ke...@bracey.fi
---
From: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
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
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.
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
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
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
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
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
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
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
Felipe Contreras felipe.contre...@gmail.com 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).
Felipe Contreras felipe.contre...@gmail.com 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
On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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 jo...@herland.net 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
On Sun, May 5, 2013 at 2:03 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, May 5, 2013 at 1:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
The previous version had an indentation bug
On Sun, May 5, 2013 at 3:58 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com 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
On Sun, May 5, 2013 at 9:02 PM, Junio C Hamano gits...@pobox.com 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
Johan Herland jo...@herland.net 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
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
It's wrong to call get_sha1() if they should be SHA-1s, plus
inefficient.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/fast-export.c | 2 +-
fast-import.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/fast-export.c
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 felipe.contre...@gmail.com
---
builtin/fast-export.c | 7 ++-
1 file changed, 6 insertions(+), 1
El 06/05/2013 00:36, Junio C Hamano gits...@pobox.com escribió:
Johan Herland jo...@herland.net 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
2013/5/6 Santi Béjar sa...@agolina.net:
El 06/05/2013 00:36, Junio C Hamano gits...@pobox.com escribió:
Johan Herland jo...@herland.net 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
31 matches
Mail list logo
