* Re: q: faster way to integrate/merge lots of topic branches?
From: Linus Torvalds @ 2008-07-23 18:12 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, Git Mailing List, Lars Hjemli
In-Reply-To: <alpine.LFD.1.10.0807231100310.4754@woody.linux-foundation.org>
On Wed, 23 Jul 2008, Linus Torvalds wrote:
>
> But I'll look if there's a way to cut it down from 9s. I suspect it has to
> traverse the whole history to make 100% sure that something isn't merged,
> but even that should be faster than 9s.
Heh. It should be trivially doable _much_ faster, but the has_commit()
logic really relies on re-doing the "in_merge_base()" thing over and over
again (clearing the bits), instead of just populating the object list with
a "already seen" bit and lettign that expand over time.
So using "git branch --no-merged" does avoid re-parsing the commits over
and over again (which is a pretty big win), but the way the code is
written it does end up traversing the commit list fully for every single
branch. That's quite horrible.
Lars added to Cc list in the hope that he'll be embarrassed enough about
the performance to try to fix it ;)
Linus
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Joshua Jensen @ 2008-07-23 18:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807231817460.8986@racer>
----- Original Message -----
From: Johannes Schindelin
Date: 7/23/2008 11:22 AM
> On msys we do that. A few users decided they know better and switched it
> off. Me for example. But I wouldn't do something as stupid as editing a
> file with an editor that tries to be helpful and adds CR/LFs.
>
There are certain file formats, such as a Visual Studio .sln file, that
MUST be CRLF. When a .sln file is not CRLF, Visual Studio refuses to
read it. I want to be able to set into the committed .gitattributes
file the list of files that must be translated to the proper format
regardless of the autocrlf setting. An example is below:
*.bat crlf
*.def crlf
*.dsp crlf
*.dsw crlf
*.rc crlf
*.sln crlf
*.vcproj crlf
*.vcp crlf
*.vcw crlf
I'm not sure your patch was intended to accomplish the forced crlf
settings above, but certainly, this functionality would be useful, if
not critical.
Thanks.
Josh
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Linus Torvalds @ 2008-07-23 18:04 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <20080723140441.GA9537@elte.hu>
Ahh, missed that somebody already suggested it.
On Wed, 23 Jul 2008, Ingo Molnar wrote:
>
> hm, it's very slow:
>
> $ time git branch --no-merged
> [...]
>
> real 0m9.177s
> user 0m9.027s
> sys 0m0.129s
>
> when running it on tip/master:
>
> http://people.redhat.com/mingo/tip.git/README
We can probably speed it up, but more importantly, even if we don't, it's
slow _once_.
It's worth taking a 9s hit, if that means that you can then skip half of
the merges entirely, and thus win half of the 53s cost.
But I'll look if there's a way to cut it down from 9s. I suspect it has to
traverse the whole history to make 100% sure that something isn't merged,
but even that should be faster than 9s.
Linus
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Linus Torvalds @ 2008-07-23 17:59 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080723130518.GA17462@elte.hu>
On Wed, 23 Jul 2008, Ingo Molnar wrote:
>
> I've got the following, possibly stupid question: is there a way to
> merge a healthy number of topic branches into the master branch in a
> quicker way, when most of the branches are already merged up?
>
> Right now i've got something like this scripted up:
>
> for B in $(git-branch | cut -c3- ); do git-merge $B; done
>
> It takes a lot of time to run on even a 3.45GHz box:
>
> real 0m53.228s
> user 0m41.134s
> sys 0m11.405s
This is almost certainly because a lot of your branches are a long way
back in the history, and just parsing the commit history is old.
For example, doing a no-op merge of something old like v2.6.24 (which is
obviously already merged) takes half a second for me:
[torvalds@woody linux]$ time git merge v2.6.24
Already up-to-date.
real 0m0.546s
user 0m0.488s
sys 0m0.008s
and it gets worse the further back in history you go (going back to 2.6.14
takes a second and a half - plus any IO needed, of course).
And just about _all_ of it is literally just unpacking the commits as you
start going backwards from the current point, eg:
[torvalds@woody linux]$ time ~/git/git merge v2.6.14
Already up-to-date.
real 0m1.540s
vs
[torvalds@woody linux]$ time git rev-list ..v2.6.14
real 0m1.407s
(The merge loop isn't quite as optimized as the regular revision
traversal, so you see it being slower, but you can still see that it's
roughly in the same class).
The merge gets a bit more expensive still if you have enabled merge
summaries (because now it traverses the lists twice - once for merge
bases, once for logs), but that's still a secondary effect (ie it adds
another 10% or so to the cost, but the base cost is still very much about
the parsing of the commits).
In fact, the two top entries in a profile look roughly like:
102161 70.2727 libz.so.1.2.3 libz.so.1.2.3 (no symbols)
7685 5.2862 git git find_pack_entry_one
...
ie 70% of the time is just purely unpacking the data, and another 5% is
just finding it. We could perhaps improve on it, but not a whole lot.
Now, quite frankly, I don't think that times on the order of one second
are worth worrying about for _regular_ merges, and the whole (and only)
reason you see this as a performance problem is that you're basically
automating it over a ton of branches, with most of them being old and
already merged.
But that also points to a solution: instead of trying to merge them one at
a time, and doing the costly revision traversal over and over and over
again, do the costly thing _once_, and then you can just filter out the
branches that aren't interesting.
So instead of doing
for B in $(git-branch | cut -c3- ); do git-merge $B; done
the obvious optimization is to add "--no-merged" to the "git branch" call.
That itself is expensive (ie doing "git branch --no-merged" will have to
traverse at least as far back as the oldest branch), so that phase will be
AT LEAST as expensive as one of the merges (and probably quite a bit more:
I suspect "--no-merged" isn't very heavily optimized), but if a lot of
your branches are already fully merged, it will do all that work _once_,
and then avoid it for the merges themselves.
So the _trivial_ solution is to just change it to
for B in $(git branch --no-merged | cut -c3- ); do git-merge $B; done
and that may already fix it in practice for you, bringing the cost down by
a factor of two or more, depending on the exact pattern (of course, it
could also make the cost go _up_ - if it turns out that none of the
branches are merged).
Other solutions exist, but they get much uglier. Octopus merges are more
efficient, for example, for all the same reasons - it keeps the commit
traversal in a single process, and thus avoids having to re-parse the
whole history down to the common base. But they have other problems, of
course.
Linus
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Junio C Hamano @ 2008-07-23 17:59 UTC (permalink / raw)
To: Ingo Molnar; +Cc: SZEDER Gábor, git
In-Reply-To: <20080723140441.GA9537@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * SZEDER Gábor <szeder@ira.uka.de> wrote:
>
>> you cound use 'git branch --no-merged' to list only those branches
>> that have not been merged into your current HEAD.
>
> hm, it's very slow:
Yeah, --no-merged and --merged were done in a quite naïve way.
The patch needs to be cleaned up by splitting it into multiple steps:
(1) discard everything outside refs/heads and refs/remotes in append_ref();
why do we even have code to deal with refs/tags to begin with???
(2) change ref_item->sha1 to ref_item->commit (and make has_commit() take
struct commit);
(3) teach merge_filter code not to do has_commit() for each ref, but use
revision traversal machinery to compute everything in parallel and in
one traversal.
but other than that, this seems to pass the tests, and is obviously
correct ;-)
With an artificial repository that has "master" and 1000 test-$i branches
where they were created by "git branch test-$i master~$i":
(with patch)
$ /usr/bin/time git-branch --no-merged master >/dev/null
0.12user 0.02system 0:00.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1588minor)pagefaults 0swaps
$ /usr/bin/time git-branch --no-merged test-200 >/dev/null
0.15user 0.03system 0:00.18elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1711minor)pagefaults 0swaps
(without patch)
$ /usr/bin/time git-branch --no-merged master >/dev/null
0.69user 0.03system 0:00.72elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2229minor)pagefaults 0swaps
$ /usr/bin/time git-branch --no-merged test-200 >/dev/null
0.58user 0.03system 0:00.61elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2248minor)pagefaults 0swaps
---
builtin-branch.c | 68 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index b885bd1..788e70a 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -13,6 +13,8 @@
#include "remote.h"
#include "parse-options.h"
#include "branch.h"
+#include "diff.h"
+#include "revision.h"
static const char * const builtin_branch_usage[] = {
"git branch [options] [-r | -a] [--merged | --no-merged]",
@@ -181,25 +183,21 @@ static int delete_branches(int argc, const char **argv, int force, int kinds)
struct ref_item {
char *name;
unsigned int kind;
- unsigned char sha1[20];
+ struct commit *commit;
};
struct ref_list {
+ struct rev_info revs;
int index, alloc, maxwidth;
struct ref_item *list;
struct commit_list *with_commit;
int kinds;
};
-static int has_commit(const unsigned char *sha1, struct commit_list *with_commit)
+static int has_commit(struct commit *commit, struct commit_list *with_commit)
{
- struct commit *commit;
-
if (!with_commit)
return 1;
- commit = lookup_commit_reference_gently(sha1, 1);
- if (!commit)
- return 0;
while (with_commit) {
struct commit *other;
@@ -215,6 +213,7 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
{
struct ref_list *ref_list = (struct ref_list*)(cb_data);
struct ref_item *newitem;
+ struct commit *commit;
int kind = REF_UNKNOWN_TYPE;
int len;
static struct commit_list branch;
@@ -226,13 +225,15 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
} else if (!prefixcmp(refname, "refs/remotes/")) {
kind = REF_REMOTE_BRANCH;
refname += 13;
- } else if (!prefixcmp(refname, "refs/tags/")) {
- kind = REF_TAG;
- refname += 10;
- }
+ } else
+ return 0;
+
+ commit = lookup_commit_reference_gently(sha1, 1);
+ if (!commit)
+ return error("branch '%s' does not point at a commit", refname);
/* Filter with with_commit if specified */
- if (!has_commit(sha1, ref_list->with_commit))
+ if (!has_commit(commit, ref_list->with_commit))
return 0;
/* Don't add types the caller doesn't want */
@@ -243,30 +244,25 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags,
branch.item = lookup_commit_reference_gently(sha1, 1);
if (!branch.item)
die("Unable to lookup tip of branch %s", refname);
- if (merge_filter == SHOW_NOT_MERGED &&
- has_commit(merge_filter_ref, &branch))
- return 0;
- if (merge_filter == SHOW_MERGED &&
- !has_commit(merge_filter_ref, &branch))
- return 0;
+ add_pending_object(&ref_list->revs,
+ (struct object *)branch.item, refname);
}
/* Resize buffer */
if (ref_list->index >= ref_list->alloc) {
ref_list->alloc = alloc_nr(ref_list->alloc);
ref_list->list = xrealloc(ref_list->list,
- ref_list->alloc * sizeof(struct ref_item));
+ ref_list->alloc * sizeof(struct ref_item));
}
/* Record the new item */
newitem = &(ref_list->list[ref_list->index++]);
newitem->name = xstrdup(refname);
newitem->kind = kind;
- hashcpy(newitem->sha1, sha1);
+ newitem->commit = commit;
len = strlen(newitem->name);
if (len > ref_list->maxwidth)
ref_list->maxwidth = len;
-
return 0;
}
@@ -309,7 +305,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
{
char c;
int color;
- struct commit *commit;
+ struct commit *commit = item->commit;
+
+ if (merge_filter != NO_FILTER) {
+ int is_merged = !!(item->commit->object.flags & UNINTERESTING);
+ if (is_merged != (merge_filter == SHOW_MERGED))
+ return;
+ }
switch (item->kind) {
case REF_LOCAL_BRANCH:
@@ -337,7 +339,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
strbuf_init(&subject, 0);
stat[0] = '\0';
- commit = lookup_commit(item->sha1);
+ commit = item->commit;
if (commit && !parse_commit(commit)) {
pretty_print_commit(CMIT_FMT_ONELINE, commit,
&subject, 0, NULL, NULL, 0, 0);
@@ -350,7 +352,7 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose,
printf("%c %s%-*s%s %s %s%s\n", c, branch_get_color(color),
maxwidth, item->name,
branch_get_color(COLOR_BRANCH_RESET),
- find_unique_abbrev(item->sha1, abbrev),
+ find_unique_abbrev(item->commit->object.sha1, abbrev),
stat, sub);
strbuf_release(&subject);
} else {
@@ -363,22 +365,34 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str
{
int i;
struct ref_list ref_list;
+ struct commit *head_commit = lookup_commit_reference_gently(head_sha1, 1);
memset(&ref_list, 0, sizeof(ref_list));
ref_list.kinds = kinds;
ref_list.with_commit = with_commit;
+ if (merge_filter != NO_FILTER)
+ init_revisions(&ref_list.revs, NULL);
for_each_ref(append_ref, &ref_list);
+ if (merge_filter != NO_FILTER) {
+ struct commit *filter;
+ filter = lookup_commit_reference_gently(merge_filter_ref, 0);
+ filter->object.flags |= UNINTERESTING;
+ add_pending_object(&ref_list.revs,
+ (struct object *) filter, "");
+ ref_list.revs.limited = 1;
+ prepare_revision_walk(&ref_list.revs);
+ }
qsort(ref_list.list, ref_list.index, sizeof(struct ref_item), ref_cmp);
detached = (detached && (kinds & REF_LOCAL_BRANCH));
- if (detached && has_commit(head_sha1, with_commit)) {
+ if (detached && head_commit && has_commit(head_commit, with_commit)) {
struct ref_item item;
item.name = xstrdup("(no branch)");
item.kind = REF_LOCAL_BRANCH;
- hashcpy(item.sha1, head_sha1);
+ item.commit = head_commit;
if (strlen(item.name) > ref_list.maxwidth)
- ref_list.maxwidth = strlen(item.name);
+ ref_list.maxwidth = strlen(item.name);
print_ref_item(&item, ref_list.maxwidth, verbose, abbrev, 1);
free(item.name);
}
^ permalink raw reply related
* Re: git merge after git cherry-pick?
From: Jakub Narebski @ 2008-07-23 17:56 UTC (permalink / raw)
To: Peter Valdemar Mørch ; +Cc: git
In-Reply-To: <48876709.3090504@sneakemail.com>
"Peter Valdemar Mørch (Lists)" <4ux6as402@sneakemail.com> writes:
> On a branch, b, made off of master, I've made the commits b1, b2, b3
> and b4.
>
> Back on master, I need commit b1 and b3 immediately. So I:
>
> $ git checkout master
> $ git cherry-pick "b1's SHA"
> $ git cherry-pick "b3's SHA"
>
> Now, both b and master contain b1 and b3. How do I now create a log of
> "what remains to be merged from b to master", i.e. only b2 and b4?
You can use "git cherry master b" command (or just "git cherry master"
if you are on branch 'b') to check which commits (based on patch id)
on branch 'b are already present on branch 'master'.
Alternatively you can use "git log --left-right master...b" to check
which comits are on which branch, although I think it wouldn't mark
duplicated commits.
> And how do I merge b2 and b4 to master, so master's log shows b1,
> b3, b2 and b4 and doesn't show b1 and b3 twice, which is what I get
> if I:
>
> $ git merge b
>
> after the cherry-picks above. Also I noticed, that if I merge master
> into b (to keep up-to-date with master) b1 and b3 are also mentioned
> twice.
You can instead of merging branch 'b' into master rebase it on top of
master.
This would create instead of the following history (for merge):
---*---b1'---b3'--------------M <-- master
\ /
\-b1----b2----b3----b4-/ <-- b
the following
---*---b1'---b3'---b1'---b4' <-- master, b
.
..b1....b2....b3....b4 <.. b@{1} (reflog)
[cut]
HTH
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git merge after git cherry-pick?
From: SZEDER Gábor @ 2008-07-23 17:56 UTC (permalink / raw)
To: Peter Valdemar Mørch (Lists); +Cc: git
In-Reply-To: <48876709.3090504@sneakemail.com>
On Wed, Jul 23, 2008 at 07:14:49PM +0200, "Peter Valdemar Mørch (Lists)" wrote:
> On a branch, b, made off of master, I've made the commits b1, b2, b3 and
> b4.
>
> Back on master, I need commit b1 and b3 immediately. So I:
>
> $ git checkout master
> $ git cherry-pick "b1's SHA"
> $ git cherry-pick "b3's SHA"
>
> Now, both b and master contain b1 and b3. How do I now create a log of
> "what remains to be merged from b to master", i.e. only b2 and b4? And
> how do I merge b2 and b4 to master, so master's log shows b1, b3, b2 and
> b4 and doesn't show b1 and b3 twice, which is what I get if I:
>
> $ git merge b
>
> after the cherry-picks above. Also I noticed, that if I merge master
> into b (to keep up-to-date with master) b1 and b3 are also mentioned
> twice.
You could use 'git rebase' for that.
e.g. now the history of your master and b branches look like this:
o---X---b1'---b3'---Y master
\
b1---b2---b3---b4 b
The command 'git rebase master b' will then turn this history into the
following:
o---X---b1'---b3'---Y master
\
b2---b4 b
After this 'git merge b' will do what you would like it to do.
Regards,
Gábor
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 17:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej5kfs0w.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 23 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, if you want to avoid CRs to _enter_ the repository, when you
> > have a lot of binary files tracked, you _do_ want to force all
> > repositories to crlf=input.
>
> If you are on a sane system, you do not even want to pay the price of
> conversion. Only people on systems with CRLF line endings should pay
> the price (because your aim is to convert on such systems). Are we
> throwing that out of the window when the project decides to use
> gitattributes?
Well, if you do not want that, why do you set crlf in the gitattributes to
begin with?
> How about setting autocrlf automatically on mingw/msys/cygwin versions,
> perhaps via templates or a patch to init-db? Would that, combined with
> user education, be a viable alternative?
On msys we do that. A few users decided they know better and switched it
off. Me for example. But I wouldn't do something as stupid as editing a
file with an editor that tries to be helpful and adds CR/LFs.
However, Cygwin? No, they don't. I don't see them change it, either.
The _only_ way we could do that is by setting auto_crlf in environment,
depending on the platform.
HOWEVER: as you can see from the git-svn post this morning, there are
known issues with autocrlf.
We also had much fun (not!) with a lot of users who were really happy to
insult us for the change to set autocrlf to true by default (via
/etc/gitconfig) in msysGit.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Alex Riesen @ 2008-07-23 17:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0807231128090.2830@eeepc-johanness>
Johannes Schindelin, Wed, Jul 23, 2008 11:53:27 +0200:
> > 19. How do you publish/propagate your changes?
> > (zero or more: multiple choice)
> > - push, pull request, format-patch + email, bundle, other
>
> git svn
>
a converter using fast-import/fast-export/plumbing
^ permalink raw reply
* [PATCH] bash: add '--abort' to 'git am' options
From: SZEDER Gábor @ 2008-07-23 17:15 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, Git Mailing List, SZEDER Gábor
We have 'git am --abort' since commit 3e5057a8, but no completion
support for it.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 8b1426a..3a99c40 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -489,7 +489,7 @@ _git_am ()
{
local cur="${COMP_WORDS[COMP_CWORD]}" dir="$(__gitdir)"
if [ -d "$dir"/rebase-apply ]; then
- __gitcomp "--skip --resolved"
+ __gitcomp "--skip --resolved --abort"
return
fi
case "$cur" in
--
1.6.0.rc0.36.g3c05
^ permalink raw reply related
* git merge after git cherry-pick?
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-23 17:14 UTC (permalink / raw)
To: git
Hi,
Still being a newbie...
On a branch, b, made off of master, I've made the commits b1, b2, b3 and
b4.
Back on master, I need commit b1 and b3 immediately. So I:
$ git checkout master
$ git cherry-pick "b1's SHA"
$ git cherry-pick "b3's SHA"
Now, both b and master contain b1 and b3. How do I now create a log of
"what remains to be merged from b to master", i.e. only b2 and b4? And
how do I merge b2 and b4 to master, so master's log shows b1, b3, b2 and
b4 and doesn't show b1 and b3 twice, which is what I get if I:
$ git merge b
after the cherry-picks above. Also I noticed, that if I merge master
into b (to keep up-to-date with master) b1 and b3 are also mentioned twice.
I did notice that cherry-pick created new SHA1 IDs for the commits for
b1 and b3 on master (as indeed man cherry-pick also says). Maybe
cherry-pick is not the right tool for the job. Is there another way to
"copy"/"merge" only b1 and b3 (but not b2 and b4) from b into master
maintaining merge history and avoiding them being mentioned twice later?
At the time of writing b1-b4, I did not know that b1 and b3 would be
needed separately, so I didn't put (b1 and b3) and (b2 and b4) on
separate branches. I did notice though, that they weren't an intricate
part of "the new feature". Is it required that I then do the work in
separate branches?
I hope this is possible as I'm thrilled with git!
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* [PATCH] documentation: 'git am --abort' also invokes 'git rerere clear'
From: SZEDER Gábor @ 2008-07-23 17:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, SZEDER Gábor
Other git commands invoking 'git rerere clear' are mentioned there,
except this.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
Documentation/git-rerere.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-rerere.txt b/Documentation/git-rerere.txt
index beebd53..5246565 100644
--- a/Documentation/git-rerere.txt
+++ b/Documentation/git-rerere.txt
@@ -37,8 +37,8 @@ its working state.
'clear'::
This resets the metadata used by rerere if a merge resolution is to be
-is aborted. Calling 'git-am --skip' or 'git-rebase [--skip|--abort]'
-will automatically invoke this command.
+is aborted. Calling 'git-am [--skip|--abort]' or 'git-rebase
+[--skip|--abort]' will automatically invoke this command.
'diff'::
--
1.6.0.rc0.36.g3c05
^ permalink raw reply related
* Gitweb; ordering of fork list on summary page (was Vanilla gitweb vs repo.or.cz)
From: Mike Ralphson @ 2008-07-23 17:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
2008/7/13 Petr Baudis <pasky@suse.cz>:
> Then, there is the http://repo.or.cz/w/git/gitweb.git repository,
> which was my old attempt at maintaining gitweb actively. Unfortunately,
> this didn't quite work out because of my general lack of time and
> dedication.
Notwithstanding the above, I've pushed a little 'fix' to the mob branch:
http://repo.or.cz/w/git/gitweb.git?a=commitdiff;h=3e8f6e9125071a7e17c88efb69c1780d775025bc
The list of forks on the summary page was unsorted, this just makes
them sorted by age, which seems a fair way to decide which forks are
shown before the list size cut-off (15) kicks in.
s/noheader/no_header was just to make it obvious what the parameter
affects, so all the code can be found with one grep, and s/undef/'age'
just shows the intent, although that parameter isn't what actually
controls the sort order. Or, I guess, the sorting could be refactored
out of the header generation code.
Mike
^ permalink raw reply
* Re: git-svn - failed to clone repository
From: SZEDER Gábor @ 2008-07-23 17:08 UTC (permalink / raw)
To: Derek Fawcus; +Cc: git
In-Reply-To: <20080723160659.GB6705@cisco.com>
On Wed, Jul 23, 2008 at 05:06:59PM +0100, Derek Fawcus wrote:
> I tried to create a clone of an svn repository, and it gave
> up part way through with the following error:
>
> Incomplete data: Delta source ended unexpectedly at /usr/bin/git-svn line 3858
>
> Looking at the source, this is the call '$reporter->finish-report($pool)'
> near the end of gs_do_update.
>
> This is using git 1.5.6 from the etch backports repository.
>
> The repository in question was cocotron, the command being:
>
> git svn clone http://cocotron.googlecode.com/svn -t tags -b branches -T trunk
It might not help you, but with svn version 1.4.6 (r28521) (from
Ubuntu 8.04) and current git master the above command has just
finished successfully.
Gábor
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Junio C Hamano @ 2008-07-23 17:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807230203350.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> However, if you want to avoid CRs to _enter_ the repository, when you have
> a lot of binary files tracked, you _do_ want to force all repositories to
> crlf=input.
If you are on a sane system, you do not even want to pay the price of
conversion. Only people on systems with CRLF line endings should pay the
price (because your aim is to convert on such systems). Are we throwing
that out of the window when the project decides to use gitattributes?
How about setting autocrlf automatically on mingw/msys/cygwin versions,
perhaps via templates or a patch to init-db? Would that, combined with
user education, be a viable alternative?
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Stephan Beyer @ 2008-07-23 17:01 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Johannes Schindelin, Jakub Narebski, git
In-Reply-To: <20080723145455.GS2925@dpotapov.dyndns.org>
Hi,
Dmitry Potapov wrote:
> On Wed, Jul 23, 2008 at 11:53:27AM +0200, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> > > 11. Why did you choose Git? (if you use Git)
> > > What do you like about using Git?
> > > (free form, not to be tabulated)
> >
> > Again, to avoid hassles with free-form:
> >
> > Mandatory: work, mandatory: open source project I am participating
> > in, speed, scalability, It's What Linus Uses, Other.
>
> If we move away from free-form, it should be much more choices here.
>
> - Ability to work offline
> - Cryptographic authentication of history.
> - Distributed development (pull/push from/to more than one remote repo)
> - Easy to extend functionality through scripting
> - Efficient storage model
> - Elegant design
> - Fast
> - Good community support
> - Rewriting patches before publishing (git rebase, commit --amend)
> - Scalability (Efficient handling of large projects)
> - Strong support for non-linear development
> - Support of wide range of protocols for synchronization.
> ...
Heh, I can imagine git users reading that survey and thinking
"What? Git allows me to rewrite patches before publishing?
And it provides cryptographic integrity? Sounds good. *click*"
Nevertheless, the list is fine ;)
Perhaps also: "Good reputation".
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Johannes Schindelin @ 2008-07-23 16:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <20080723164614.GB5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Because exactly the file mode (the executable bit) is the reason for
> checking ctime.
But ctime is broken on Windows. Because ctime is supposed to change
whenever the _inode_ changes.
You have to admit that saying "I ignore the ctime because the executable
bit is broken" must leave the reader puzzled.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Johannes Schindelin @ 2008-07-23 16:57 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20080723164109.GA5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> + if (autocorrect > 0) {
> + fprintf(stderr, "in %0.1f seconds automatically...\n",
> + (float)autocorrect/10.0);
> + poll(NULL, 0, autocorrect * 100);
> + }
What? No countdown? No fancy sounds when the time ran up?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-07-23 16:55 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0807230921m114f5ae0ybfec4917432d6dc7@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1185 bytes --]
Hi,
On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> >
> > > So in short, sparse prefix will be stored in config,
> > > core.sparsecheckout.
> >
> > Do you really think the prefix should be stored anywhere else than the
> > index?
> >
> > With core.sparseCheckout you have to introduce a _sh*tload_ of config
> > loaders.
> >
> > And with core.sparseCheckout you are at the whim of the user, since
> > .git/config is _supposed_ to be user-editable.
> >
> > From a logical point of view, I'd say that the sparse prefix has
> > nothing to do with the "configuration" of the local repository.
>
> Well, whatever place. I chose .git/config because I did not want to
> introduce a new config place. But then how about .git/sparsecheckout?
No, I did mean the index. This is an attribute of the index: either it is
sparsely checked out or not. You can even have multiple indices
(switching between them by setting GIT_INDEX_FILE) which have different
prefixes.
Ciao,
Dscho "who seems to recall that the first series was much less intrusive"
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Stephan Beyer @ 2008-07-23 16:47 UTC (permalink / raw)
To: Olivier Marin
Cc: Junio C Hamano, Theodore Tso, Nanako Shiraishi,
Johannes Schindelin, René Scharfe, Joe Fiorini, git,
Jari Aalto
In-Reply-To: <48874617.3010108@free.fr>
Hi,
Olivier Marin wrote:
> > The reason of my question was that I *blindly* incorporated the change into
> > sequencer to make it able to work on a dirty working tree and thus to be
> > able to migrate am onto it without losing the ability to apply patches
> > on a dirty working tree....
>
> Are you talking about your seq-proto-dev3 branch?
Right, and your suggested changes are right, too, and I've incorporated
them yesterday (with an --allow-dirty option) but I hadn't commited them...
(Hence, not pushed.)
> > Now, because t4151 does not pass, I am wondering what's the best thing
> > I could do...
Well, that was solved...
The problem was that the additional "HEAD" (that made t4151 work), resulted
in untracked files in some test cases of sequencer and rebase-i. Those made
merges fail, because these merges would overwrite these files. So the
merges failed, and the test cases failed.
I've solved this with the trick that the "HEAD" argument is only added if
--allow-dirty is set (and git-am uses --allow-dirty of course).
This is perhaps not the cleanest way but seemed to be far more better
than forcing overwrites on merges (checkouts, etc.).
> Ah, you should change "Applying 6" with "Applying \"6\"" in t4151-am-abort.sh
> too.
I btw wondered if the quotes are useful in original am.
Well, I've just sent a patch adding a colon (instead of quotes). Let's
see ;)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH] git-am: Add colon before the subject that is printed out as being applied
From: Stephan Beyer @ 2008-07-23 16:46 UTC (permalink / raw)
To: git; +Cc: Jeff King, Junio C Hamano, Linus Torvalds, Stephan Beyer
git-am output can be confusing, because the subject of the applied
patch can look like the rest of a sentence starting with "Applying".
The added colon should make this clearer.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,
Linus added single quotes to applypatch in 610968199,
writing:
Add quotes around the subject line that we print out as being applied.
My brain just flipped when it tried to read the "Applying" as part
of the explanation of the patch, and the sentence didn't make any
sense. The quotes make it clear what's going on.
I think he is right ;)
Of course, it's debatable whether
Applying: foo
or
Applying "foo"
or
Applying 'foo'
may be the best. I don't really care :)
The main reason I chose the colon variant is because the change in t4151
is less ugly.
Another reason: thinking of "ambiguous" subjects:
- Applying "Remove "string" from foo.c"
- Applying 'Remove 'string' from foo.sh'
- Applying: foo.c: Remove "string"
Regards,
Stephan
git-am.sh | 2 +-
t/t4151-am-abort.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 7864b5f..f4abd9d 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -456,7 +456,7 @@ do
stop_here $this
fi
- printf 'Applying %s\n' "$FIRSTLINE"
+ printf 'Applying: %s\n' "$FIRSTLINE"
case "$resolved" in
'')
diff --git a/t/t4151-am-abort.sh b/t/t4151-am-abort.sh
index 249093b..f45ab0a 100755
--- a/t/t4151-am-abort.sh
+++ b/t/t4151-am-abort.sh
@@ -43,7 +43,7 @@ do
test_expect_success "am$with3 --skip continue after failed am$with3" '
test_must_fail git-am$with3 --skip >output &&
- test "$(grep "^Applying" output)" = "Applying 6" &&
+ test "$(grep "^Applying" output)" = "Applying: 6" &&
test_cmp file-2-expect file-2 &&
test ! -f .git/rr-cache/MERGE_RR
'
--
1.6.0.rc0.102.ga1791
^ permalink raw reply related
* Re: [PATCH] Build configuration to skip ctime for modification test
From: Alex Riesen @ 2008-07-23 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <7vr69lihkt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Wed, Jul 23, 2008 02:12:50 +0200:
> >> Otherwise, if you really want to tell at compile time,I think for clarity
> >> you have to introduce another #define, since NO_TRUSTABLE_FILEMODE
> >> definitely says something different than CTIME_IS_USELESS.
> >
> > I had that at first (NO_DEPENDABLE_CTIME, than IGNORE_CTIME), than
> > deemed it excessive.
>
> Why is it excessive? My initial reaction was "what does trustable
> filemode nor trust_executable_bit has anything to do with ctime". Please
> explain.
Because exactly the file mode (the executable bit) is the reason for
checking ctime. Otherwise there is no point: Git doesn't save any
other data which when changed cause a ctime update. And exactly the
file mode is completely broken on that cygwin thing. Which is
precisely pointed by NO_TRUSTABLE_FILEMODE. Hence - just it.
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 16:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080722222510.GA4474@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Tue, Jul 22, 2008 23:44:50 +0200:
> > However, I think that the intention of this patch is too much DWIMery,
> > which might be good for me (just like my "git add remote" patch), but
> > not for the general audience.
>
> Mustn't be good for all
You meant "needn't"? It is good for me ;-)
> And thanks for sharing.
You're welcome.
> + n = 1;
> + while (n < main_cmds.cnt &&
> + best_similarity == similarity(main_cmds.names[n]->name))
> + ++n;
Mini-nit: you never ask for the value of n, only if it is 1 or larger. So
you do not need to count...
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-23 16:43 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Johannes Schindelin, git
In-Reply-To: <200807231508.42334.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
>> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>>
>> Some people prefer to stay anonymous, so I think email is out.
>>
>> > 04. Which programming languages you are proficient with?
>> > (The choices include programming languages used by git)
>> > (zero or more: multiple choice)
>> > - C, shell, Perl, Python, Tcl/Tk
>> > + (should we include other languages, like C++, Java, PHP,
>> > Ruby,...?)
>>
>> Yes, I think this should be a long list.
>
> I'd rather not have a "laundry list" of languages. I have put C++
> because QGit uses it, Java because of egit/jgit, PHP for web
> interfaces, Ruby because of GitHub and because of Ruby comminity
> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
> JavaScript here. What other languages should be considered?
I refrained saying this in my initial response, but my initial reaction
was "Why are you even asking this?".
Yes, "getting to know you" demographics are customary done in surveys, and
you kept it to the minimum which is also good, but I do not think this
particular question is very interesting. For one thing, the question
assumes the participant is a programmer, and we are giving an impression
that we are interested in better programmers. Do we *still* require users
to be a programmer to use git? I do not think so. Having to answer "none
of these" to this question would make you feel unnecessarily bad, even if
you are not a programmer and you know at the intellectual level that it is
not your flaw not to be proficient in any.
Asking about geographic location and preferred human languages might help
to gauge what l10n are desired for GUIs, but even there, don't forget that
we are no company. We do not research markets and translate messages to
missing languages, however popular, before being asked. That's not how we
operate. So the result of these questions will be mainly to satisfy our
curiosity, nothing more.
"What kind of content do you track" might also be an equally interesting
question. It also falls into the curiosity department, though.
> I'm not sure about having multiple choice vs. free-form question here.
> Multiple choice is easier to analyze, especially if one would want
> histogram of replies...
And when you expect very many respondents, (1) you cannot afford to
free-form; and (2) statistics over multiple choices, as long as choices
are well seeded, will give you a good enough overview picture.
> Again: free form has some hassles, but so does coming up with good
> choice of fixed answers in multiple choice question.
You need to do at least one or the other, and I do not think there is any
way to avoid that. Without a good choices, histogram would become useless
(not necessarily because the answer will be dominated by "Other", but the
seeing the choices tends to set the frame of mind when/before somebody
answers the question). With free-form, you will spend the rest of your
life analyzing to get any useful insight.
^ permalink raw reply
* [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Alex Riesen @ 2008-07-23 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vsku1jz4u.fsf@gitster.siamese.dyndns.org>
Suggested by Junio, so he has a chance to hit Ctrl-C.
---
Junio C Hamano, Wed, Jul 23, 2008 01:08:17 +0200:
>
> Please make autocorrect not a binary but optionally the number of
> deciseconds before it continues, so that I have a chance to hit ^C ;-)
on top of the last patch.
Documentation/config.txt | 9 +++++++++
help.c | 7 ++++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e784805..5bf1d0d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -771,6 +771,15 @@ help.format::
Values 'man', 'info', 'web' and 'html' are supported. 'man' is
the default. 'web' and 'html' are the same.
+help.autocorrect::
+ Automatically correct and execute mistyped commands after
+ waiting for the given number of deciseconds (0.1 sec). If more
+ than one command can be deduced from the entered text, nothing
+ will be executed. If the value of this option is negative,
+ the corrected command will be executed immediately. If the
+ value is 0 - the command will be just shown but not executed.
+ This is the default.
+
http.proxy::
Override the HTTP proxy, normally configured using the 'http_proxy'
environment variable (see linkgit:curl[1]). This can be overridden
diff --git a/help.c b/help.c
index 8b25a55..4d52781 100644
--- a/help.c
+++ b/help.c
@@ -271,7 +271,7 @@ static int git_help_config(const char *var, const char *value, void *cb)
if (!prefixcmp(var, "man."))
return add_man_viewer_info(var, value);
if (!strcmp(var, "help.autocorrect"))
- autocorrect = git_config_bool(var,value);
+ autocorrect = git_config_int(var,value);
return git_default_config(var, value, cb);
}
@@ -722,6 +722,11 @@ const char *help_unknown_cmd(const char *cmd)
"which does not exist.\n"
"Continuing under the assumption that you meant '%s'\n",
cmd, main_cmds.names[0]->name);
+ if (autocorrect > 0) {
+ fprintf(stderr, "in %0.1f seconds automatically...\n",
+ (float)autocorrect/10.0);
+ poll(NULL, 0, autocorrect * 100);
+ }
return main_cmds.names[0]->name;
}
--
1.6.0.rc0.50.g9c23
^ permalink raw reply related
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