* "remote add -f --mirror" fails when the stash is non-empty
From: Björn Steinbrink @ 2008-07-31 21:50 UTC (permalink / raw)
To: git
Hi,
when there are stashed changes in a repo, creating a mirror with "remote
add -f --mirror" fails, because it is missing the objects that are on
the stash.
$ git remote add -f --mirror or ~/src/git
Updating or
remote: Counting objects: 80150, done.
remote: Compressing objects: 100% (21254/21254), done.
remote: Total 80150 (delta 57481), reused 80146 (delta 57477)
Receiving objects: 100% (80150/80150), 21.21 MiB | 16028 KiB/s, done.
Resolving deltas: 100% (57481/57481), done.
From /home/doener/src/git
* [new branch] master -> master
* [new branch] rebase -> rebase
* [new branch] origin/HEAD -> origin/HEAD
* [new branch] origin/html -> origin/html
* [new branch] origin/maint -> origin/maint
* [new branch] origin/man -> origin/man
* [new branch] origin/master -> origin/master
* [new branch] origin/next -> origin/next
* [new branch] origin/pu -> origin/pu
* [new branch] origin/todo -> origin/todo
error: unable to find 9e5c2066d7d2bdca937a11b45a7ed8354c637bc9
fatal: object 9e5c2066d7d2bdca937a11b45a7ed8354c637bc9 not found
error: Could not fetch or
In ~/src/git:
$ git rev-parse stash
9e5c2066d7d2bdca937a11b45a7ed8354c637bc9
No idea if that is a recent breakage, as I learned about the --mirror
option recently and most of the time my stash is empty anyway.
Björn
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-07-31 21:40 UTC (permalink / raw)
To: Craig L. Ching; +Cc: sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311253140.3277@nehalem.linux-foundation.org>
On Thu, 31 Jul 2008, Linus Torvalds wrote:
>
> Sure, if you want to keep the build tree around, you would probably not
> use branches.
Side note: it's often faster to recompile, if your project has a good
build system.
For example, for the kernel, I can literally rebuild my whole kernel
(which is just what I use on _that_ machine) in about 16 seconds. This is
_not_ using ccache or anything else - it's rebuilding the whole tree with
-j16.
It turns out that using multiple build trees would actually slow things
down, because then the source code wouldn't fit in memory any more. If I
have to actually read the source code from the disk, my nice 16-second
compile goes up to a minute or more.
Now, the thing you should take away from this is:
- kernel people have cool toys, and CPU's that are faster than what you
have. Nyaah, nyaah.
- disk is slow. REALLY slow. If you can share most of a single source
tree and thus keep it in memory, you're ahead.
- even large projects can have a fast build cycle if your build chain
doesn't suck. The kernel is larger than most, but a _lot_ of build
systems don't parallelize or use horribly inefficient tools, so they
take much longer to build.
The last part is the thing that people often stumble on. For example, I
can literally compile the kernel a hell of a lot faster than I can do
"make doc" on the git tree! Even just trying a "make -j16" when building
the git documentation is really really really painful. I suspect I'd need
a ton more memory for that horror.
So if your workflow involves xml (I think the doc build for git is all
xsltproc - along with asciidoc written in python or something), you're
screwed. But in the kernel we've actually cared pretty deeply about build
times, and as a result it's actually very pleasant to switch branches and
just rebuild. Even if some core header file has changed, it's _still_ ok
if you've got enough CPU.
(I just tested - I can do a "make doc" for git in just under a minute from
a clean tree. Ouch. That really is three times longer than my kernel
build - as long as I brought the kernel and compiler into memory first ;)
Linus
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Sverre Rabbelier @ 2008-07-31 21:51 UTC (permalink / raw)
To: cte; +Cc: Dmitry Potapov, git
In-Reply-To: <ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com>
On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
> Using output from the command line utilities as an API has its own set
> of problems. For instance, check out some of the difficulties that
> gitk and qgit have had to deal with:
> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
I beg to differ. If I skimmed the topic correctly, the problems there
were not related to having to parse git's output, but due to the fact
that '--topo-order' is a post-processing operation, which takes long.
Do read the recent discussion between Linus and Roman about that.
> Digging into
> the git internals and reusing its core functions will always be more
> powerful and flexible than parsing command line output.
Sure, but is it worth it? What do you need in your GUI that you cannot
get from the plumbing?
> Of course, it
> is not always easy; git wasn't written to be easily compiled into a
> library and reused (graceful error handling and memory management are
> problematic). But I think the right thing to do is to work towards
> making the awesome git internals easier to use for other developers so
> great tools can continue to be built on top of git.
I do agree with that, libification of git would be really nice.
Especially since that'd mean that integrating it into other languages
(by means of wrappers), such as Python or Ruby, becomes a lot easier.
>> There is, use the plumbing, forward compatibility is 95% assured. With
>> the exception of major releases, for which any plumbing
>> output/behavior changes will be announced in the changelog, usually
>> including an explanation on how to change your code to match.
>
> 95% assured != correct, IMO :)
Why not? Junio has a very good reputation of keeping git backwards
compatible. The 95% is of course not an actual figure but an
expression meant to indicate "statement is true, minus a few rare case
exceptions".
>> In short, use the forc-... errr, plumbing ;).
>>
>> --
>> Cheers,
>>
>> Sverre Rabbelier
>>
It's ok to remove text that you do not respond to, including signatures :P.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Shawn O. Pearce @ 2008-07-31 21:58 UTC (permalink / raw)
To: sverre; +Cc: cte, Dmitry Potapov, git
In-Reply-To: <bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com>
Sverre Rabbelier <alturin@gmail.com> wrote:
> On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
> > Using output from the command line utilities as an API has its own set
> > of problems. For instance, check out some of the difficulties that
> > gitk and qgit have had to deal with:
> > http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
>
> I beg to differ. If I skimmed the topic correctly, the problems there
> were not related to having to parse git's output, but due to the fact
> that '--topo-order' is a post-processing operation, which takes long.
> Do read the recent discussion between Linus and Roman about that.
And actually if you try to use topo-order internally in C you still
have to wait for the post-processing. Which is going to cause your
UI to lock up because it is single-threaded as both Git and your UI
toolkit are probably single threaded. At least by forking out to
git-rev-list your UI can respond while the computation is happening
in a background process.
> Especially since that'd mean that integrating it into other languages
> (by means of wrappers), such as Python or Ruby, becomes a lot easier.
I'm going to be shot for saying this, but both Python and Ruby
have implementations that run on the JVM. So does Git. Want
to use Git and Python? Use JGit and Jython. :)
> >> There is, use the plumbing, forward compatibility is 95% assured. With
> >> the exception of major releases, for which any plumbing
> >> output/behavior changes will be announced in the changelog, usually
> >> including an explanation on how to change your code to match.
> >
> > 95% assured != correct, IMO :)
>
> Why not? Junio has a very good reputation of keeping git backwards
> compatible. The 95% is of course not an actual figure but an
> expression meant to indicate "statement is true, minus a few rare case
> exceptions".
Too many people have scripts based upon plumbing to make incompatible
changes. We'd have all of our users screaming. Remember many Git
users are programmers themselves, they will make small home-grown
scripts based upon Git plumbing to simplify their workflow and
everyday tasks. They use plumbing precisely because they can trust
it won't change or break on them.
--
Shawn.
^ permalink raw reply
* [PATCH RFC] Do not override LESS
From: Anders Melchiorsen @ 2008-07-31 22:00 UTC (permalink / raw)
To: git; +Cc: Anders Melchiorsen
Passing options to "less" with the LESS environment variable can
interfere with existing environment variables. There are at least two
problems, as the following examples show:
1. Alice is using git with colors. Now she decides to set LESS=i for
some reason. Suddenly, git displays codes in place of colors. Alice
likes codes, but she liked colors better!
2. Bob sets GIT_PAGER="less -RS", but does not set LESS. Git sets
LESS=FRSX before calling $GIT_PAGER. Now Bob wonders why his pager is
not always paging, when he explicitly tried to clear the F option.
Maybe Mallory has been messing with something?
By passing the options on the command line instead, both of these
situations are handled.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
There are at least two issues with this change:
A. Now /bin/sh will be executed all the time with the default pager. If
this is perceived as a performance problem, I can make a special case.
B. This will make existing setups with PAGER="less" behave differently.
They can, of course, be fixed with GIT_PAGER="less -FRSX".
I think that neither 1, 2, A or B are big problems. Nevertheless, I think
this change makes things "more correct", so I hereby offer it for discussion.
diff --git a/pager.c b/pager.c
index 6b5c9e4..232d6ed 100644
--- a/pager.c
+++ b/pager.c
@@ -60,7 +60,7 @@ void setup_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = "less -FRSX";
else if (!*pager || !strcmp(pager, "cat"))
return;
@@ -90,7 +90,6 @@ void setup_pager(void)
close(fd[0]);
close(fd[1]);
- setenv("LESS", "FRSX", 0);
run_pager(pager);
die("unable to execute pager '%s'", pager);
exit(255);
--
1.5.6.4
^ permalink raw reply related
* [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-07-31 22:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vhca6zcuy.fsf@gitster.siamese.dyndns.org>
This one makes it incremental. It is not relative to v2 but on top of
'master'.
The idea and the logic to find what parents to rewrite is the same as the
previous one, but this one works incrementally as much as possible. When
you have this topology, where commits with capital letters are the ones
that change the paths you are interested in:
A---M---o---C---D---o
/ /
---o---B
(1) we can tell that the rightmost one 'o' is not we want to show, without
digging any further than D;
(2) we can show D after inspecting C without digging any further. C is
the sole parent of D, and C itself is an interesting one, so D's
parent will stay to be C and not its ancestor.
(3) before showing C, we need to know what the rewritten parent of it
would be; we need to dig down to M and notice that it has two parents
that simplify to a different commit (both A and B touch the path we
are interested in), so M simplifies to itself and it becomes the
parent of C. IOW, we need to dig no further than A and B in order to
show C.
$ time sh -c 'git log --pretty=oneline --abbrev-commit \
--simplify-merges --parents \
-- kernel/printk.c | head -n 1'
5dfb66b... 1d9b9f6... c9272c4... Merge branch 'for-linus' of git://git.o-hand.com/linux-mfd
real 0m0.344s
user 0m0.324s
sys 0m0.020s
The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
it is much more expensive than the non-incremental one (v2), and about
three times more expensive than non-limiting --full-history for explaining
the history of kernel/printk.c. There must be opportunity to further
optimize this, but I'd stop here for now, as you keep saying this is hard,
and if I continue thinking about this any longer my head would explode ;-)
---
revision.c | 106 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
revision.h | 1 +
2 files changed, 103 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 3897fec..9554a70 100644
--- a/revision.c
+++ b/revision.c
@@ -1045,6 +1045,10 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
} else if (!strcmp(arg, "--topo-order")) {
revs->lifo = 1;
revs->topo_order = 1;
+ } else if (!strcmp(arg, "--simplify-merges")) {
+ revs->simplify_merges = 1;
+ revs->rewrite_parents = 1;
+ revs->simplify_history = 0;
} else if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
@@ -1450,9 +1454,10 @@ static enum rewrite_result rewrite_one(struct rev_info *revs, struct commit **pp
}
}
-static void remove_duplicate_parents(struct commit *commit)
+static int remove_duplicate_parents(struct commit *commit)
{
struct commit_list **pp, *p;
+ int surviving_parents;
/* Examine existing parents while marking ones we have seen... */
pp = &commit->parents;
@@ -1465,9 +1470,13 @@ static void remove_duplicate_parents(struct commit *commit)
parent->object.flags |= TMP_MARK;
pp = &p->next;
}
- /* ... and clear the temporary mark */
- for (p = commit->parents; p; p = p->next)
+ /* count them while clearing the temporary mark */
+ surviving_parents = 0;
+ for (p = commit->parents; p; p = p->next) {
p->item->object.flags &= ~TMP_MARK;
+ surviving_parents++;
+ }
+ return surviving_parents;
}
static int rewrite_parents(struct rev_info *revs, struct commit *commit)
@@ -1536,6 +1545,89 @@ enum commit_action simplify_commit(struct rev_info *revs, struct commit *commit)
return commit_show;
}
+static void simplify_merges(struct rev_info *revs, struct commit *commit)
+{
+ struct commit_list *work = NULL;
+
+ commit_list_insert(commit, &work);
+ while (!commit->util && work) {
+ struct commit *c;
+ struct commit_list *p;
+ int cnt;
+
+ c = pop_commit(&work);
+ if (c->util)
+ continue;
+ if ((c->object.flags & UNINTERESTING) || !c->parents) {
+ c->util = c;
+ continue;
+ }
+
+ /*
+ * Do we know what commit all of the parents of this
+ * should be rewritten to? Otherwise we are not ready
+ * to rewrite this one yet.
+ */
+ for (cnt = 0, p = c->parents; p; p = p->next) {
+ if (!p->item->util) {
+ if (!cnt)
+ commit_list_insert(c, &work);
+ commit_list_insert(p->item, &work);
+ cnt++;
+ }
+ }
+ if (cnt)
+ continue;
+
+ /*
+ * Rewrite the list of parents.
+ */
+ for (p = c->parents; p; p = p->next)
+ p->item = p->item->util;
+ cnt = remove_duplicate_parents(c);
+
+ /*
+ * It is possible that this is a merge and one side
+ * branch does not have any commit that touches the
+ * given paths; in such a case, the immediate parents
+ * will be rewritten to different commits if we do not
+ * reduce such a false merge of fast-forward parents.
+ *
+ * o----X X: the commit we are looking at;
+ * / / o: a commit that touches the paths;
+ * ---o----'
+ *
+ * Further reduce the parents by removing redundant
+ * parents.
+ */
+ if (1 < cnt) {
+ struct commit_list *h = reduce_heads(c->parents);
+ cnt = commit_list_count(h);
+ free_commit_list(c->parents);
+ c->parents = h;
+ }
+
+ /*
+ * A commit simplifies to itself if it is a root, if
+ * it is UNINTERESTING, if it touches the given paths,
+ * or if it is a merge and its parents simplifies to
+ * more than one commits (the first two cases are
+ * already handled at the beginning of this function).
+ *
+ * Otherwise, it simplifies to what its sole parent
+ * simplifies to.
+ */
+ if (!cnt ||
+ (c->object.flags & UNINTERESTING) ||
+ !(c->object.flags & TREESAME) ||
+ (1 < cnt))
+ c->util = c;
+ else
+ c->util = c->parents->item->util;
+ }
+ free_commit_list(work);
+}
+
static struct commit *get_revision_1(struct rev_info *revs)
{
if (!revs->commits)
@@ -1570,8 +1662,14 @@ static struct commit *get_revision_1(struct rev_info *revs)
case commit_error:
return NULL;
default:
- return commit;
+ break;
+ }
+ if (revs->simplify_merges && !commit->util) {
+ simplify_merges(revs, commit);
+ if (commit->util != commit)
+ continue;
}
+ return commit;
} while (revs->commits);
return NULL;
}
diff --git a/revision.h b/revision.h
index f64e8ce..dfa06b5 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,7 @@ struct rev_info {
simplify_history:1,
lifo:1,
topo_order:1,
+ simplify_merges:1,
tag_objects:1,
tree_objects:1,
blob_objects:1,
^ permalink raw reply related
* Re: linking libgit.a in C++ projects
From: Sverre Rabbelier @ 2008-07-31 22:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: cte, Dmitry Potapov, git
In-Reply-To: <20080731215818.GD24631@spearce.org>
On Thu, Jul 31, 2008 at 23:58, Shawn O. Pearce <spearce@spearce.org> wrote:
> And actually if you try to use topo-order internally in C you still
> have to wait for the post-processing.....
Aye, that's what I was reffering to, thanks for clarifying :).
>> Especially since that'd mean that integrating it into other languages
>> (by means of wrappers), such as Python or Ruby, becomes a lot easier.
>
> I'm going to be shot for saying this, but both Python and Ruby
> have implementations that run on the JVM. So does Git. Want
> to use Git and Python? Use JGit and Jython. :)
Heheh, nice plug :P, but thanks but no thanks. I'd rather have
something more native than "JGit + Jython", two levels of 'emulation'
can't be good!
> Too many people have scripts based upon plumbing to make incompatible
> changes.....
Exactly! :)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Dmitry Potapov @ 2008-07-31 22:23 UTC (permalink / raw)
To: cte; +Cc: sverre, git
In-Reply-To: <ac9f0f090807311444lb2f02e6ud76463b359184fbd@mail.gmail.com>
On Fri, Aug 1, 2008 at 1:44 AM, cte <cestreich@gmail.com> wrote:
>
> Using output from the command line utilities as an API has its own set
> of problems. For instance, check out some of the difficulties that
> gitk and qgit have had to deal with:
> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
There is no problem with parsing. If you want to receive the output
in the specific order, Git has to read everything first, and that
is *slow*. So, --topo-order is convenient but slow, and it is slow
not because it is piping data, but because it takes some time to
read the whole history.
> Digging into
> the git internals and reusing its core functions will always be more
> powerful and flexible than parsing command line output.
"Flexible" is not a synonym of the word "useful". For instance, using
core functions will not help you to overcome the aforementioned problem.
Drawing a graph is NOT what git core functions about. You have to do
that in your GUI, and to do that when revisions are given to you in
arbitrary order is not easy. Yet, it is something what good GUI should
be capable to handle, because otherwise the response time will be bad.
Dmitry
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-07-31 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vabfxyacx.fsf_-_@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
> it is much more expensive than the non-incremental one (v2), and about
> three times more expensive than non-limiting --full-history for explaining
> the history of kernel/printk.c.
Hmm? Why is that, exactly? Does it walk over the same commit over and over
and over again or something?
Can you combine --simplify-merges and --topo-order to get a fast version
again (since --topo-order will force a non-incrmental walk)?
I have this suspicion (gut feel only, not anything else to back it up)
that for any complex global history, you'll always end up having a lot of
merges "live" and have a hard time getting a lot of early output.
That may be why you get a fairly big delay before even the first commit:
> $ time sh -c 'git log --pretty=oneline --abbrev-commit \
> --simplify-merges --parents \
> -- kernel/printk.c | head -n 1'
> 5dfb66b... 1d9b9f6... c9272c4... Merge branch 'for-linus' of git://git.o-hand.com/linux-mfd
>
> real 0m0.344s
> user 0m0.324s
> sys 0m0.020s
>From your previous email:
$ git rev-list --parents --full-history --topo-order HEAD -- kernel/printk.c
3.75user 0.47system 0:04.22elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
so that's less than 10% of the whole time, but it's still a _lot_ slower
than the
$ git rev-list --parents --full-history HEAD -- kernel/printk.c | head -n 200
0.16user 0.02system 0:00.18elapsed 103%CPU (0avgtext+0avgdata 0maxresident)k
and that was the first 200 commits, not just the first one. I bet you got
the first one in about a tenth of that time - so I'm guessing 0.016s (also
based on my own testing - it's below 0.01s here, but I'm willing to bet my
machine is faster than yours is).
So getting the first one with "--simplify-merges" was really a _lot_
slower.
That said, I'm a huge beliver in the incremental approach - it just looks
like this is potentially "just barely incremental" in practice.
Of course, with a more linear history than the kernel, your approach
probably works better.
Linus
^ permalink raw reply
* [PATCH] git svn: should not display zombie externals
From: Eddy Petrișor @ 2008-07-31 22:33 UTC (permalink / raw)
To: git
during the history of a repo a svn:external could be added and later
removed; such externals shouldn't be displayed since only the current
state is relevant
I have encountered the broken behaviour on a git-svn repo with the svn
origin a repo served via https (git 1:1.5.6-1~bpo40+1 from Debian Etch
backports.) I hope this bug doesn't have to do with the svn repo being
served via https.
Signed-off-by: Eddy Petrișor <eddy.petrisor@gmail.com>
---
t/t9101-git-svn-props.sh | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index f420796..e5ab748 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -211,7 +211,28 @@ EOF
test_expect_success 'test proplist' "
git-svn proplist . | cmp - prop.expect &&
- git-svn proplist nested/directory/.keep | cmp - prop2.expect
+ git-svn proplist nested/directory/.keep | cmp - prop2.expect &&
+ cd ..
+ "
+
+test_expect_success 'show external' "
+ cd test_wc &&
+ svn propset svn:externals 'zombie file:///fake/external' . &&
+ svn ci -m 'added a fake svn:external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q 'zombie'
+ "
+
+test_expect_success 'remove external' "
+ cd test_wc &&
+ svn propdel svn:externals . &&
+ svn ci -m 'deleted the fake external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q -v 'zombie'
"
test_done
--
1.5.6.3
^ permalink raw reply related
* Re: [PATCH v2] revision traversal: show full history with merge simplification
From: Linus Torvalds @ 2008-07-31 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <7vd4kuzcst.fsf@gitster.siamese.dyndns.org>
On Thu, 31 Jul 2008, Junio C Hamano wrote:
>
> If you look at the output from the "kernel/printk.c" with this patch, you
> would notice that there still are somewhat meaningless merges shown in the
> history (e.g. scroll down to 185a257f2f73bcd89050ad02da5bedbc28fc43fa).
They're not really meaningless.
Yes, they are pointless for the end result, but once you start showing
that whole pointless branch they very much are needed for a complete view
of the "shape" of history. The merges are real points on that branch where
printk changed because it got updates from mainlines.
So either you should have the full simplification (which only shows stuff
that is really meaningful for the end result), or you need for those
"pointless" merges to remain (because you show the changes that happened
on side branches).
I obviously believe that the full simplification is what you most often
want, but the --post-simplify thing does make sense.
(And yes, I agree that the name should be something else, and that
--simplify-merges makes more sense. The "post-simplify" thing is an
implementation issue, and doesn't describe what the effect is. And with
your incremental one, even that isn't true).
Linus
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-07-31 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807311513020.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Junio C Hamano wrote:
>>
>> The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
>> it is much more expensive than the non-incremental one (v2), and about
>> three times more expensive than non-limiting --full-history for explaining
>> the history of kernel/printk.c.
>
> Hmm? Why is that, exactly? Does it walk over the same commit over and over
> and over again or something?
>
> Can you combine --simplify-merges and --topo-order to get a fast version
> again (since --topo-order will force a non-incrmental walk)?
Heh, nice try to make my head explode ;-) Not today, no, really, no...
^ permalink raw reply
* [PATCH] git svn: should not display zombie externals
From: Eddy Petrișor @ 2008-07-31 22:37 UTC (permalink / raw)
To: git
In-Reply-To: <48923DAF.7070900@gmail.com>
during the history of a repo a svn:external could be added and later
removed; such externals shouldn't be displayed since only the current
state is relevant
I have encountered the broken behaviour on a git-svn repo with the svn
origin a repo served via https (git 1:1.5.6-1~bpo40+1 from Debian Etch
backports.) I hope this bug doesn't have to do with the svn repo being
served via https.
Signed-off-by: Eddy Petrișor <eddy.petrisor@gmail.com>
---
t/t9101-git-svn-props.sh | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/t/t9101-git-svn-props.sh b/t/t9101-git-svn-props.sh
index f420796..e5ab748 100755
--- a/t/t9101-git-svn-props.sh
+++ b/t/t9101-git-svn-props.sh
@@ -211,7 +211,28 @@ EOF
test_expect_success 'test proplist' "
git-svn proplist . | cmp - prop.expect &&
- git-svn proplist nested/directory/.keep | cmp - prop2.expect
+ git-svn proplist nested/directory/.keep | cmp - prop2.expect &&
+ cd ..
+ "
+
+test_expect_success 'show external' "
+ cd test_wc &&
+ svn propset svn:externals 'zombie file:///fake/external' . &&
+ svn ci -m 'added a fake svn:external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q 'zombie'
+ "
+
+test_expect_success 'remove external' "
+ cd test_wc &&
+ svn propdel svn:externals . &&
+ svn ci -m 'deleted the fake external' &&
+ cd .. &&
+ git-svn fetch &&
+ git-merge git-svn &&
+ git-svn show-externals | grep -q -v 'zombie'
"
test_done
--
1.5.6.3
This one is properly formated (the previous one was a copy/paste from the output of the console).
^ permalink raw reply related
* Re: markdown 2 man, was Re: Git Community Book
From: Junio C Hamano @ 2008-08-01 0:45 UTC (permalink / raw)
To: Abdelrazak Younes
Cc: Stephan Beyer, git, Johannes Schindelin, Julian Phillips,
Scott Chacon, Petr Baudis
In-Reply-To: <4891CD34.1070308@lyx.org>
Abdelrazak Younes <younes@lyx.org> writes:
> I just had a look at the user manual and, well unless you have a
> special emacs mode or whatever that can automate the markup tag
> insertion, I wonder how can anybody think that writing with this
> markup language is easier than within LyX, really (genuine question,
> not sarcasm).
How greppable and "log -p"-able is the documentation written in LyX?
* Where in the documentation do I have to change the description of
"--parents" option?
* When did the description of "--cc" for diff families last changed, by
whom and why?
Eas of doing these is mostly why we chose AsciiDoc to begin with. Any
alternative you are going to suggest should not make these two things
impossible or very harder to do.
^ permalink raw reply
* What's in git.git (Jul 2008, #09; Thu, 31)
From: Junio C Hamano @ 2008-08-01 1:02 UTC (permalink / raw)
To: git
Some git-gui updates for 1.6.0 are included, and then many minor fixes.
Perhaps -rc2 this weekend.
* The 'master' branch has these since the last announcement.
Abhijit Menon-Sen (5):
git-gui: Look for gitk in $PATH, not $LIBEXEC/git-core
Clarify that "git log x.c y.h" lists commits that touch either file
`git submodule add` now requires a <path>
Make it clear that push can take multiple refspecs
Make the DESCRIPTION match <x>... items in the SYNOPSIS
Alex Riesen (1):
Make use of stat.ctime configurable
Alexander Gavrilov (7):
Fix pre-commit hooks under MinGW/MSYS
Add options to control the search for copies in blame.
Kill the blame back-end on window close.
Add a menu item to invoke full copy detection in blame.
git-gui: Fix the Remote menu separator.
git-gui: Preserve scroll position on reshow_diff.
Support copy and rename detection in fast-export.
Anders Melchiorsen (2):
Documentation: fix diff.external example
Advertise the ability to abort a commit
Björn Steinbrink (1):
rev-parse: Add support for the ^! and ^@ syntax
Brian Gernhardt (1):
Documentation: Remove mentions of git-svnimport.
Cesar Eduardo Barros (2):
Documentation/git-submodule.txt: fix doubled word
Documentation/git-rev-parse.txt: update for new git-describe output
format
Christian Couder (2):
merge-base: die with an error message if not passed a commit ref
documentation: user-manual: update "using-bisect" section
Jakub Narebski (1):
gitweb: More about how gitweb gets 'owner' of repository
Jeff King (2):
init: handle empty "template" parameter
Compact commit template message
Johannes Schindelin (1):
Avoid chdir() in list_commands_in_dir()
Johannes Sixt (2):
git-gui: Fix "Stage/Unstage Line" with one line of context.
git-gui: "Stage Line": Treat independent changes in adjacent lines better
Jonathan Nieder (1):
t6030 (bisect): work around Mac OS X "ls"
Junio C Hamano (11):
make sure parsed wildcard refspec ends with slash
GIT 1.6.0-rc1
Allow building without any git installed
Allow installing in the traditional way
ls-tree documentation: enhance notes on subdirectory and pathspec
behaviour
Documentation: clarify what is shown in "git-ls-files -s" output
t7001: fix "git mv" test
Teach gitlinks to ie_modified() and ce_modified_check_fs()
Fix merge name generation in "merge in C"
Fix test-parse-options "integer" test
Teach --find-copies-harder to "git blame"
Kevin Ballard (1):
format-patch: Produce better output with --inline or --attach
Lars Hjemli (3):
builtin-branch: remove duplicated code
builtin-branch: factor out merge_filter matching
builtin-branch: fix -v for --[no-]merged
Lee Marlow (1):
bash completion: Add completion for 'git help'
Olivier Marin (1):
builtin-verify-tag: fix -v option parsing
Petr Baudis (2):
git-mv: Remove dead code branch
git-mv: Keep moved index entries inact
Pierre Habouzit (1):
Allow "non-option" revision options in parse_option-enabled commands
Shawn O. Pearce (3):
git-gui: Correct 'Visualize Branches' on Mac OS X to start gitk
fsck: Don't require tmp_obj_ file names are 14 bytes in length
git-gui: Fix gitk search in $PATH to work on Windows
Steffen Prohaska (5):
Refactor, adding prepare_git_cmd(const char **argv)
run-command (Windows): Run dashless "git <cmd>"
git-gui: Correct installation of library to be $prefix/share
git-gui (Windows): Switch to relative discovery of oguilib
git-gui (Windows): Change wrapper to execdir 'libexec/git-core'
Thomas Rast (1):
bash completion: Add long options for 'git describe'
Todd Zullinger (1):
Replace uses of "git-var" with "git var"
^ permalink raw reply
* What's cooking in git.git (Jul 2008, #11; Thu, 31)
From: Junio C Hamano @ 2008-08-01 1:03 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc2 (Aug 3)
- 1.6.0-rc3 (Aug 10)
----------------------------------------------------------------
[New Topics]
* rs/archive-parse-options (Fri Jul 25 12:41:26 2008 +0200) 1 commit
+ archive: allow --exec and --remote without equal sign
None of the following is for 1.6.0.
* mv/merge-custom (Thu Jul 31 00:38:07 2008 +0200) 5 commits
+ builtin-help: always load_command_list() in cmd_help()
+ Add a second testcase for handling invalid strategies in git-merge
+ Add a new test for using a custom merge strategy
+ builtin-merge: allow using a custom strategy
+ builtin-help: make some internal functions available to other
builtins
* cc/merge-base-many (Sun Jul 27 13:47:22 2008 -0700) 4 commits
- git-merge-octopus: use (merge-base A (merge B C D E...)) for
stepwise merge
+ merge-base-many: add trivial tests based on the documentation
+ documentation: merge-base: explain "git merge-base" with more than
2 args
+ merge-base: teach "git merge-base" to drive underlying
merge_bases_many()
* jc/simplify-merges (Thu Jul 31 01:17:41 2008 -0700) 1 commit
. revision traversal: show full history with merge simplification
"log --full-history" is with too much clutter, "log" itself is too cleverer
than some people, and here is the middle level of merge simplification.
----------------------------------------------------------------
[On Hold and/or Cooking]
None of the following is for 1.6.0.
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
+ Documentation: Improve documentation for git-imap-send(1)
+ imap-send.c: more style fixes
+ imap-send.c: style fixes
+ git-imap-send: Support SSL
+ git-imap-send: Allow the program to be run from subdirectories of
a git tree
Some people seem to prefer having this feature available also with gnutls.
Such an enhancement can be done in-tree on top of this series if they are
so inclined.
* cc/bisect (Fri Jul 25 05:36:37 2008 +0200) 2 commits
- bisect: only check merge bases when needed
- bisect: test merge base if good rev is not an ancestor of bad rev
* jc/add-addremove (Tue Jul 22 22:30:40 2008 -0700) 2 commits
+ builtin-add.c: optimize -A option and "git add ."
+ builtin-add.c: restructure the code for maintainability
* jk/pager-swap (Tue Jul 22 03:14:12 2008 -0400) 2 commits
+ spawn pager via run_command interface
+ run-command: add pre-exec callback
This changes the parent-child relationship between the pager and the git
process. We used to make pager the parent which meant that the exit
status from git is lost from the caller.
* ph/enable-threaded (Mon Jul 21 11:23:43 2008 +0200) 1 commit
+ Enable threaded delta search on *BSD and Linux.
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
This would be the right thing to do for command line use, but gitk will be
hit due to tcl/tk's limitation, so I am holding this back for now.
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-08-01 1:17 UTC (permalink / raw)
To: sverre; +Cc: Dmitry Potapov, git
In-Reply-To: <bd6139dc0807311451t763aa07bsf9474fce4073babd@mail.gmail.com>
> On Thu, Jul 31, 2008 at 23:44, cte <cestreich@gmail.com> wrote:
>> Using output from the command line utilities as an API has its own set
>> of problems. For instance, check out some of the difficulties that
>> gitk and qgit have had to deal with:
>> http://kerneltrap.org/mailarchive/git/2007/11/2/379067.
>
> I beg to differ. If I skimmed the topic correctly, the problems there
> were not related to having to parse git's output, but due to the fact
> that '--topo-order' is a post-processing operation, which takes long.
> Do read the recent discussion between Linus and Roman about that.
Didn't mean to imply that somehow it is no longer a post-processing op if you
aren't using git plumbing. The discussion shows, however, that if gitk
was actually
doing the revision traversals, then it would be able to trigger events
that update the
gui whenever it wanted, which would have allowed it to implement the
early output
feature without changing any of the git source. Instead, git-log had
to be altered to
address gitk's needs, and an option was added that users don't
typically use. This is
not exactly what I would consider spartan programming
(http://www.codinghorror.com/blog/archives/001148.html),
plus there are already too many options to remember! Anyways, I
suppose it is pointless
to argue about which approach is better, because both have trade-offs,
and the correct
path depends on your use case.
>>> There is, use the plumbing, forward compatibility is 95% assured. With
>>> the exception of major releases, for which any plumbing
>>> output/behavior changes will be announced in the changelog, usually
>>> including an explanation on how to change your code to match.
>>
>> 95% assured != correct, IMO :)
>
> Why not? Junio has a very good reputation of keeping git backwards
> compatible. The 95% is of course not an actual figure but an
> expression meant to indicate "statement is true, minus a few rare case
> exceptions".
Definitely not questioning his ability to maintain backwards
compatibility; it was
merely an observation about your strange definition of correct. In school, when
I completed 95% of a proof, it was never marked as "correct", and I
was told that I hadn't actually proven anything. Those damn teachers :)
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: Linus Torvalds @ 2008-08-01 1:54 UTC (permalink / raw)
To: cte; +Cc: sverre, Dmitry Potapov, git
In-Reply-To: <ac9f0f090807311817n551f53a5mb1270e6f4b2a058e@mail.gmail.com>
On Thu, 31 Jul 2008, cte wrote:
>
> Instead, git-log had to be altered to address gitk's needs, and an
> option was added that users don't typically use.
Actually, no.
I ended up doing a hack to add "git log --early-output", and some quick
hacks to make git use it. But I'm happy to say that gitk doesn't use it
any more. Gitk just parses the normal git log output, although obviously
it ends up needing enough data to be able to fill in the gaps (ie it uses
the "--parents" flag to get the rewritten parenthood info and the merges
to keep it together).
So yeah, we have some options that enable output that simply doesn't make
_sense_ to humans, but does when you are post-processing it (git has
always had those, since it very much was about scripting from day one),
but no, at least gitk doesn't use any really odd ones.
It literally does
git log --no-color -z --pretty=raw --parents --boundary
(plus the args the user gave it). The --no-color turns off color if it's
enabled by default.
The -z makes it the git log output a bit easier to parse by using a NUL
character between commits.
The --pretty=raw is just to give the full/raw commit info - like giving
the timestamps in the native raw format that is much easier to parse than
any human-readable format.
The --parents I already mentioned - it is what makes you able to stitch
the commits together (and it's useful for other things too: any scripts
that look for merges will tend to use it, for example)
And the --boundary is to show the commits that aren't part of the actual
selected set in gray.
It's all pretty generic, in other words. The -z option is purely for
machine parsing, the others _can_ actually be useful even for humans (eg,
--boundary together with --left-right and --pretty=oneline actually is
very readable if you are used to that format).
So it's very true that git in general is geared towards scripting (and
we've often added things to make it even more so), but no, your particular
complaint isn't true. gitk doesn't do anything really strange.
Linus
^ permalink raw reply
* stgit and rm a file
From: Jon Smirl @ 2008-08-01 2:02 UTC (permalink / raw)
To: Git Mailing List
Make a new patch, git rm a file, refresh. It won't pick up the rm. Do
something else besides just a rm and it will pick up the rm. Is it
already fixed in the much anticipated refresh rewrite?
jonsmirl@terra:~/fs$ stg --version
Stacked GIT 0.14.3.173.g2e37
git version 1.6.0.rc0
Python version 2.5.2 (r252:60911, Apr 21 2008, 11:17:30)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)]
jonsmirl@terra:~/fs$
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: linking libgit.a in C++ projects
From: cte @ 2008-08-01 2:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sverre, Dmitry Potapov, git
In-Reply-To: <alpine.LFD.1.10.0807311840240.3277@nehalem.linux-foundation.org>
> So it's very true that git in general is geared towards scripting (and
> we've often added things to make it even more so), but no, your particular
> complaint isn't true. gitk doesn't do anything really strange.
Yeah, I guess that's why I like using git so much; a few piped
commands and a script or two, and you can do some pretty rad stuff.
^ permalink raw reply
* email address handling
From: Andrew Morton @ 2008-08-01 2:40 UTC (permalink / raw)
To: git
A minor thing.
Commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2 is displayed thusly:
commit 76ecb4f2d7ea5c3aac8970b9529775316507c6d2
Author: Zhang, Rui <rui.zhang@intel.com>
Date: Thu Apr 10 16:20:23 2008 +0800
ACPI: update thermal temperature
but that isn't a valid email address. Because it contains a comma it
must be quoted: "Zhang, Rui".
I assume that something in the git toolchain removed his quotes, and
that was arguably incorrect.
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Dmitry Torokhov @ 2008-08-01 2:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <alpine.LFD.1.10.0807311426090.3277@nehalem.linux-foundation.org>
On Thu, Jul 31, 2008 at 02:40:55PM -0700, Linus Torvalds wrote:
>
>
> On Thu, 31 Jul 2008, Linus Torvalds wrote:
> >
> > Sure, if you want to keep the build tree around, you would probably not
> > use branches.
>
> Side note: it's often faster to recompile, if your project has a good
> build system.
>
> For example, for the kernel, I can literally rebuild my whole kernel
> (which is just what I use on _that_ machine) in about 16 seconds. This is
> _not_ using ccache or anything else - it's rebuilding the whole tree with
> -j16.
>
Is it after make mrproper (wow)? Or is it when your branches are
"recent"? Because for me (and well, I dont have that beefy boxes as you
do) swithing between "for-linus" and "next" that based off a revision in
vicinity of 2.6.xx-rc1 and "work" which tracks the tip of your tree
takes time to rebuild.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3-wip] revision traversal: show full history with merge simplification
From: Junio C Hamano @ 2008-08-01 3:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Roman Zippel, Martin Langhoff, Tim Harper, git
In-Reply-To: <alpine.LFD.1.10.0807311513020.3277@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 31 Jul 2008, Junio C Hamano wrote:
>>
>> The same query with 's/| head -n 1/>/dev/null' is more expensive. In fact
>> it is much more expensive than the non-incremental one (v2), and about
>> three times more expensive than non-limiting --full-history for explaining
>> the history of kernel/printk.c.
>
> Hmm? Why is that, exactly? Does it walk over the same commit over and over
> and over again or something?
It was even worse than that.
The output from v3 is incorrect, as the place the new call is hooked into
knows only that the commit in question is not UNINTERESTING, but hasn't
inspected its parents, but the simplification logic needs to dig into the
parent chain deep enough, which it does not do correctly using the proper
simplification logic (i.e. add_parents_to_list()).
^ permalink raw reply
* Re: Monotone workflow compared to Git workflow ( was RE: Git vs Monotone)
From: Linus Torvalds @ 2008-08-01 3:02 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Craig L. Ching, sverre, Git Mailinglist
In-Reply-To: <20080801025024.GA18529@anvil.corenet.prv>
On Thu, 31 Jul 2008, Dmitry Torokhov wrote:
> > For example, for the kernel, I can literally rebuild my whole kernel
> > (which is just what I use on _that_ machine) in about 16 seconds. This is
> > _not_ using ccache or anything else - it's rebuilding the whole tree with
> > -j16.
>
> Is it after make mrproper (wow)?
Yeah. It's after doing
git clean -dqfx
make oldconfig
where I tend to use "git clean -dqfx" instead of "make mrproper" these
days.
Note that my "oldconfig" really only does the things I need, so this is
_not_ a "allmodconfig" or anything like that. That would take much longer.
It only has the drivers I use, and the stuff I actually need (it's not a
embedded kernel in any way, but it's definitely pared down config exactly
because I like being able to rebuild my kernels without wasting time on
thousands of drivers that I can't use anyway).
Other people can do the "does it compile?" testing. Not worth my time, I
feel ;)
> Because for me (and well, I dont have that beefy boxes as you do)
> swithing between "for-linus" and "next" that based off a revision in
> vicinity of 2.6.xx-rc1 and "work" which tracks the tip of your tree
> takes time to rebuild.
Well, the difference really is the beefy box. And the fact that I hate
modules, and I hate building stuff that I don't actually need.
I literally turn off CONFIG_MODULES entirely.
Linus
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-01 3:23 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git, Eric Wong
In-Reply-To: <20080731104529.GE7008@dpotapov.dyndns.org>
> It does not look to be true. I did the following test:
...
> which means that the autocrlf conversion is done for temporary
> files created by perl. (I tested it on Linux and Windows/Cygwin).
>
> In any case, I believe the right solution should be adding a
> new option to git-hash-object to disable any conversion.
My bad, I did not append full thoughts. git-hash-object DOES autocrlf
convertion but it cant do it correctly. All it can do - is to autodetect
text files. My setup has .git/info/attributes file where all files but .cpp
and .h are binary. While .cpp and .h are text files. In this case
git-hash-object do not know the real file name as far as git-svn use
temporary files.
I dont think that disabling convertion is a good way. I really want to convert
my files. Possible solution is to pass two file names to git-hash-object: the
real file with content and the proposed file name in the working directory.
In this case git-hash-object will be able to make correct convertion.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox