Michael Haggerty 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 lift one from
gli
On 08/29/2012 06:33 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> On 08/29/2012 08:06 AM, Junio C Hamano wrote:
>>> Michael Haggerty writes:
>>
>> It is in fact the whole approach that I object to.
>> ...
>>> What exactly is broken in CEILING?
>>
>> CEILING is used in setup_git_direc
Junio C Hamano writes:
> Jeff King 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
Jeff King 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 "TONS!"
Jeff King writes:
> When you wrote "oldest" here, I thought that meant you would do a
> comparison on the taggerdate. But reading the implementation, you really
> mean "topologically oldest".
>
> I wonder, though, if the former would be sufficient for most people.
Even without clock skew, timest
On Wed, Aug 29, 2012 at 08:53:49PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I wonder if you can
> > define the weight as a recursive function of the parents.
>
> I do not think we can. A merge Z between X (that has N commits
> behind it) and Y (that has M commits behind it) has a
Jeff King writes:
> I wonder if you can
> define the weight as a recursive function of the parents.
I do not think we can. A merge Z between X (that has N commits
behind it) and Y (that has M commits behind it) has at most N+M+1
commits behind it (counting itself), but we cannot tell how many
a
On Wed, Aug 29, 2012 at 02:17:24PM -0700, Junio C Hamano wrote:
> 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.
When you wrote "oldest" here, I thought that meant you would do a
comparison on the tagger
We are almost there...
Signed-off-by: Junio C Hamano
---
Documentation/git-name-rev.txt | 14 --
t/t6039-name-rev.sh| 62 ++
2 files changed, 73 insertions(+), 3 deletions(-)
create mode 100755 t/t6039-name-rev.sh
diff --git a/Documen
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
---
builtin/describe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/d
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
b
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 lat
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
-
Just spell it "struct rev_name"; it makes it more clear what is
going on.
Signed-off-by: Junio C Hamano
---
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
--- a/builtin/name-rev.c
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
On Wed, Aug 29, 2012 at 04:37:06PM -0700, Junio C Hamano wrote:
> Junio C Hamano 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 strb
Junio C Hamano 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 0136db586c
0136db
Jeff King 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
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 Haman
Just spell it "struct rev_name"; it makes it more clear what is
going on.
Signed-off-by: Junio C Hamano
---
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
--- a/builtin/name-rev.c
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 comme
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 cachin
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 mes
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) {
> > -
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 directl
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 09:36:43AM -0700, Junio C Hamano wrote:
> Jeff King 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.
> >
> > Unfortunat
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 29.08.12 08:43, Orgad and Raizel Shaneh wrote:
> 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
Nguyễn Thái Ngọc Duy writes:
> + if (opts.patch_mode || opts.pathspec)
> + return cmd_checkout_entry(&opts, &new);
> + else
> + return cmd_switch(&opts, &new);
> }
Yeah, patch_mode is really part of checking out paths, so separating
the actions into two makes se
Nguyễn Thái Ngọc Duy writes:
> I'm not entirely sure about this chunk
>
> +if (opts->track != BRANCH_TRACK_UNSPECIFIED) {
> +if (opts->new_orphan_branch)
> +die(_("%s cannot be used with %s"), "--orphan", "-t");
> +if (opts->force_detach)
> +
On Tue, Aug 28, 2012 at 11:36:46PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Greg KH 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:
> >>$ g
Emmanuel Michon writes:
> I believe UNIX recommends some rules in the «less is more» spirit when
> designing command line applications [basically listed here:
> http://en.wikipedia.org/wiki/Unix_philosophy].
That is exactly why our plumbing layer of commands (e.g. "git
diff-tree", "git rev-list"
Dan Johnson writes:
> Perhaps I am missing something from an earlier discussion, but it is
http://thread.gmane.org/gmane.comp.version-control.git/203259/focus=203344
> not obvious to me why this is an option to the no-walk behavior and
> not something like --sorted/--unsorted as a separate op
On Wed, Aug 29, 2012 at 2:15 AM, Martin von Zweigbergk
wrote:
> 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 '
Emmanuel Michon writes:
> Isn't the design principle superior to the wishes of the masses?
Only when you are living an ideal fantasy land.
--
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.k
We have the "mailmap" mechanism to unify entries for a person with
multiple e-mail addresses into one "Name ", but it seems
that the .mailmap file hasn't been keeping up to the changes in the
real world.
Does any of you contributors who has commits in my tree want to
update how you appear in "shor
Jeff King 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.
>
> Signed-
Michael Haggerty writes:
> On 08/29/2012 08:06 AM, Junio C Hamano wrote:
>> Michael Haggerty writes:
>
> It is in fact the whole approach that I object to.
> ...
>> What exactly is broken in CEILING?
>
> CEILING is used in setup_git_directory_gently_1() when trying to find
> the GIT_DIR appropri
Hello,
I'm risking myself on this mailing list after looking for some advise on
IRC. Basically I know about this previous attempt
http://marc.info/?l=git&m=122955045415845&w=2 but my request has little
to do with emacs.
I believe UNIX recommends some rules in the «less is more» spirit when
design
Oswald Buddenhagen writes:
> On Tue, Aug 28, 2012 at 09:19:53PM +0200, Hallvard Breien Furuseth wrote:
> ...
>> Junio's proposal partially fixes that: It pushes refs/* instead of
>> refs/heads/*, to refs/remotes//. However...
>>
> i did exacty that. the tags are *still* not populated - git just
checkout operates in three different modes. On top of that it tries to
be smart by guessing the branch name for switching. This results in
messy option handling code. This patch reorders it so that
- cmd_checkout() is responsible for parsing, preparing input and
determinining mode
- Code of
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 68 --
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 3e3f086..78abaeb 100644
--- a/builtin/checkout.c
+++ b/builtin/che
This struct contains various switches to system and it feels somewhat
safer to have the compiler reassure us that nowhere else changes it.
One field that is changed, writeout_error, is split out and passed as
another argument.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 37
On Wed, Aug 29, 2012 at 3:45 AM, Junio C Hamano 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" com
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.
Signed-off-by: Jeff King
---
I'd probabl
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 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 $pare
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 a
On 08/29/2012 08:06 AM, Junio C Hamano wrote:
> Michael Haggerty 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.
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 obj
51 matches
Mail list logo
