Michael Haggerty mhag...@alum.mit.edu writes:
But it also changes almost 600 *other* tests from succeed even in the
presence of symlinks to never tested in the presence of symlinks, and
I think that is surrendering more ground than necessary.
Ouch. I did not know have 600+ tests that cares
I'm still working on a re-roll of my rebase-range series, but I think
these three are quite unrelated and shouldn't be held up by that other
series.
Junio, thanks for all the help with explaining revision walking. It
was a little blurry for a long time, but at least I feel more
comfortable with
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two
Cherry-picking commits out of order (w.r.t. commit time stamp) doesn't
currently work. Add a test case to demonstrate it.
Signed-off-by: Martin von Zweigbergk martinv...@gmail.com
---
t/t3508-cherry-pick-many-commits.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git
When giving multiple individual revisions to cherry-pick or revert, as
in 'git cherry-pick A B' or 'git revert B A', one would expect them to
be picked/reverted in the order given on the command line. They are
instead ordered by their commit timestamp -- in chronological order
for cherry-pick and
Junio C Hamano gits...@pobox.com writes:
Greg KH gre...@linuxfoundation.org writes:
In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
is a bit odd.
If I go to look to see what release it was in, I normally do:
$ git describe --contains
Hi,
I have a repo accessed through //server/share/foo/repo (Using msysgit).
.git/objects/info/alternates contains '../../../bare/objects'
Running 'git status' (or almost any other action) gives the following output:
error: object directory /server/share/foo/bare/objects does not exist;
check
Martin von Zweigbergk martinv...@gmail.com writes:
Btw2, I'm migrating my email to martinv...@gmail.com (not y...@google.com
;-) which saves a few keystrokes and matches some of my other
accounts, so these patches will be the first ones from the new
address.
Please send in something like
On Tue, Aug 28, 2012 at 09:19:53PM +0200, Hallvard Breien Furuseth wrote:
Oswald Buddenhagen wrote:
(...)so the second approach is the bare aggregator repo which adds
all other repos as remotes, and the other repos link back via
alternates. problems:
- to actually share objects, one
On 08/29/2012 08:06 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
But it also changes almost 600 *other* tests from succeed even in the
presence of symlinks to never tested in the presence of symlinks, and
I think that is surrendering more ground than necessary.
Hi all,
I am using a repository that has a sub module which is being committed
to frequently by myself as well as others. Because of the heavy
concurrent development I need to do a lot of rebasing. Since the sub
module commit hashes referenced by the parent repository can become
dangling as
On Tue, Aug 28, 2012 at 04:39:11PM -0700, Junio C Hamano wrote:
git rev-list --committer=torva...@linux-foundation.org \
--max-parents=2 --min-parents=2 --parents v3.5..v3.6-rc2 RL
cmd='
while read result parent1 parent2
do
$GIT merge-base $parent1 $parent2
This can provide better algorithmic complexity for some of
the date-sorted commit list uses, among other things.
The queue is stored as a heap, allowing O(log) insertion and
top-element removal, and O(1) peeking at the top element.
Current commit lists are sorted linked lists, giving O(1)
peeking
On Wed, Aug 29, 2012 at 3:45 AM, Junio C Hamano gits...@pobox.com wrote:
+ /* Easy mode-independent incompatible checks */
if (opts.force_detach (opts.new_branch || opts.new_orphan_branch))
die(_(--detach cannot be used with -b/-B/--orphan));
Did you catch --detach -B
Jeff King p...@peff.net writes:
The merge-base functions internally keep a commit lists and
insert by date, which causes a linear search of the commit
list for each insertion. Let's use a priority queue instead.
Unfortunately, from my experiments, this didn't actually
cause any speedup.
Am 29.08.2012 11:55, schrieb Stijn Souffriau:
I am using a repository that has a sub module which is being committed to
frequently by myself as well as others. Because of the heavy concurrent
development I need to do a lot of rebasing. Since the sub module commit
hashes referenced by the
On Wed, Aug 29, 2012 at 09:36:43AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
The merge-base functions internally keep a commit lists and
insert by date, which causes a linear search of the commit
list for each insertion. Let's use a priority queue instead.
On Wed, Aug 29, 2012 at 04:53:32PM -0400, Jeff King wrote:
Thanks. This seems to break t6010-merge-base.sh for me, though...
Interesting. It works fine here, even under --valgrind. Did you apply
the patches directly on top of 1251cc7?
Hmm, this does seem to break t6024 for me, though.
On Wed, Aug 29, 2012 at 04:55:25PM -0400, Jeff King wrote:
On Wed, Aug 29, 2012 at 04:53:32PM -0400, Jeff King wrote:
Thanks. This seems to break t6010-merge-base.sh for me, though...
Interesting. It works fine here, even under --valgrind. Did you apply
the patches directly on top
On Wed, Aug 29, 2012 at 05:00:32PM -0400, Jeff King wrote:
Hmm, this does seem to break t6024 for me, though.
Probably because:
/* Clean up the result to remove stale ones */
- free_commit_list(list);
- list = result; result = NULL;
- while (list) {
- struct
Hi,
I am getting this error every time I pull. All the following have been
executed, but failed to remove this warning:
git prune
git prune --expire now
git gc
git gc --aggressive
What should I do?
Thanks, D.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
So here is an attempt to teach name-rev a mode that tries to base
its name on oldest tag that can reach the commit. It needs the
reset_revision_walk() call recently added to the revision traversal
API, and applies to bcc0a3e (v1.7.11-rc0~111^2~2) or newer.
Note that this can benefit from
Instead of naming a rev after a tip that is topologically closest,
use the tip that is the oldest one among those which contain the
rev.
The semantics name-rev --weight would give is closer to what
people expect from describe --contains.
Note that this is fairly expensive (see NEEDSWORK comment
Just spell it struct rev_name; it makes it more clear what is
going on.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/name-rev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 1b37458..8af2cfa 100644
---
In preparation for the later changes, restructure the logic a little
bit to separate how the code decides to use the new tip for naming
a particular commit, and what happens based on the decision.
Also re-indent and correct style of this function while we are at it.
Signed-off-by: Junio C Hamano
Jeff King p...@peff.net writes:
+while (result.nr)
+commit_list_append(queue_pop(result), tail);
+queue_clear(result);
+queue_clear(list);
+return ret;
I forgot to to port the STALE flag handling here.
Figures.. Thanks.
--
To unsubscribe from this list: send
Junio C Hamano gits...@pobox.com writes:
Note that this is fairly expensive (see NEEDSWORK comment in the
code).
And this is with the notes-cache.
(priming the cache from scratch)
$ rm .git/refs/notes/name-rev-weight
$ /usr/bin/time ../git.git/git-name-rev --weight --tags
On Wed, Aug 29, 2012 at 04:37:06PM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Note that this is fairly expensive (see NEEDSWORK comment in the
code).
And this is with the notes-cache.
[...]
+static int get_tip_weight(struct commit *commit)
+{
+ struct
Greg KH noticed that the commit 0136db586c that was merged to the
mainline back in v3.5-rc1 days was merged again as part of a
different branch to the mainline before v3.6-rc1.
git describe --contains gives the commit a name based on the newer
v3.6-rc1 tag, which was surprising.
This is because
Just spell it struct rev_name; it makes it more clear what is
going on.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/name-rev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index 1b37458..8af2cfa 100644
---
In preparation for later changes, restructure the logic a little bit
to separate how the code decides to use the new tip for naming a
particular commit, and what happens based on the decision.
Also re-indent and correct style of this function while we are at it.
Signed-off-by: Junio C Hamano
Instead of naming a rev after a tip that is topologically closest,
use the tip that is the oldest one among those which contain the
rev.
The semantics name-rev --weight would give us is closer to what
people expect from describe --contains.
Note that this is fairly expensive to compute; a later
With the weight assigned to tip of each ref, we can give more
intuitive results from name-rev that is more suitable to answer
what is the oldest tag that contains this commit? However, this
number is very expensive to compute.
Use the notes-cache mechanism to cache this value. The result
And this is the logical conclusion of the series, to
allow 0136db586c in the kernel history to be described
as v3.5-rc1~83^2~81^2~76, not as v3.6-rc1~59^2~56^2~76.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/describe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff
Jeff King p...@peff.net writes:
OK. I didn't think too hard about it, so I'll trust you that it is not
easy. I wonder if using the generation number would be another way of
defining oldest that would be easier to calculate.
Go back to my illustration to Greg and think about the implication
of
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
OK. I didn't think too hard about it, so I'll trust you that it is not
easy. I wonder if using the generation number would be another way of
defining oldest that would be easier to calculate.
Go back to my
On 08/29/2012 06:33 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
On 08/29/2012 08:06 AM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
It is in fact the whole approach that I object to.
...
What exactly is broken in CEILING?
CEILING is
Michael Haggerty mhag...@alum.mit.edu writes:
By the way, is the use of realpath(3) permissible in git code?
GIT_CEILING_DIRECTORIES handling could be fixed relatively easily by
using this function to canonicalize pathnames before comparison.
As long as we can add a compat/realpath.c (perhaps
38 matches
Mail list logo
