* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Johannes Schindelin @ 2008-07-23 19:00 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20080723184443.GD5283@blimp.local>
Hi,
On Wed, 23 Jul 2008, Alex Riesen wrote:
> Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > > + 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...
>
> But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
Yes. So check cnt > 0 && best_similarity > 5 says if it is 0, and
cnt > 1 && best_similarity < similarity(...[1]...) says if it is 1.
Ergo: no need to count,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 18:57 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Joshua Jensen, Junio C Hamano, git
In-Reply-To: <32541b130807231133x37083278u1badd82b5c48e57b@mail.gmail.com>
Hi,
On Wed, 23 Jul 2008, Avery Pennarun wrote:
> 1. always CRLF on all platforms (eg. for .bat files)
> 2. always LF on all platforms (eg. for shell scripts and perl scripts)
> 3. just leave it alone no matter what (eg. for binary files)
These are not different, but equal. "Do no harm to the contents of this
file".
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Johannes Sixt @ 2008-07-23 18:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7vmyk8e9p9.fsf@gitster.siamese.dyndns.org>
On Mittwoch, 23. Juli 2008, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
> > On Dienstag, 22. Juli 2008, Johannes Schindelin wrote:
> >> On Mon, 21 Jul 2008, Johannes Sixt wrote:
> >> > The problem was that argv[0] does not have a path in certain cases.
> >>
> >> Note that the same holds true for Linux when calling a program that is
> >> in the PATH:
> >
> > Oh, boy!
> >
> >> I imagine that the proper solution would be to rip out lookup_prog() and
> >> use it for non-Windows Git, too. Unless you want to limit the
> >> usefulness of your patch series to Windows, that is.
> >
> > This certainly goes beyond what I am prepared to do. It is not my itch.
> > The series is already much longer than I wanted, when there is a much
> > simpler solution that solves *my* problem: to set bindir = $(gitexecdir).
>
> If you are living in the Windows world, perhaps you could record the
> installation location in resource somewhere from the installer and look it
> up at runtime? Or is it considered a bad practice?
Well, looking at value of _pgmptr *is* "look it up at runtime"; no resources
or help from the installer are needed.
My rant here is more about that I created a *long* patch series only to find
out that it does not have enough genericity to solve the same problem
(relocatability) on platforms other than Windows - and I don't want to make
it even longer. Windows is special enough that *I* could live with a much
simpler solution even though it is a bit retro.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Wait help.autocorrect deciseconds before running corrected command
From: Alex Riesen @ 2008-07-23 18:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807231756380.8986@racer>
Johannes Schindelin, Wed, Jul 23, 2008 18:57:05 +0200:
> 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?
>
Hate them fancies... :)
^ permalink raw reply
* Re: [PATCH] Add help.autocorrect to enable/disable autocorrecting
From: Alex Riesen @ 2008-07-23 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231743030.8986@racer>
Johannes Schindelin, Wed, Jul 23, 2008 18:44:49 +0200:
> > + 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...
But I do, don't I? AFAICS, I use 0, 1 and >1 (this-these).
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Avery Pennarun @ 2008-07-23 18:33 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <488772BC.80207@workspacewhiz.com>
On 7/23/08, Joshua Jensen <jjensen@workspacewhiz.com> wrote:
> There are certain file formats, such as a Visual Studio .sln file, that
> MUST be CRLF. [...]
It seems like what people really want is some additional file attributes:
1. always CRLF on all platforms (eg. for .bat files)
2. always LF on all platforms (eg. for shell scripts and perl scripts)
3. just leave it alone no matter what (eg. for binary files)
4. convert line endings to LF on checkin, native on checkout (eg. for
most source files)
Where "native" is defined by some config option, but the choice of #1
through #4 is defined by .gitattributes. Thus, the config option
affects only mode #4 (and perhaps the default mode, as it does now).
The current system works for #3. With Dscho's patch, #4 works too. I
think more kinds of per-file attributes are needed in order to get #1
and #2.
Avery
^ permalink raw reply
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Junio C Hamano @ 2008-07-23 18:31 UTC (permalink / raw)
To: Olivier Marin
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <488722F5.9030602@free.fr>
Olivier Marin <dkr+ml.git@free.fr> writes:
> Junio C Hamano a écrit :
>>> diff --git a/git-am.sh b/git-am.sh
>> ...
>>> @@ -202,8 +202,15 @@ then
>> ...
>>> + case "$skip,$abort" in
>>> + t,)
>>> + git rerere clear
>>> + git read-tree --reset -u HEAD HEAD
>>> + orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>>> + git reset HEAD
>>> + git update-ref ORIG_HEAD $orig_head
>>> + ;;
>> ...
> I add reset to unstage paths with no conflict that are left behind.
Does removing the last three lines (1) change the behaviour? (2) break any test?
If the answers are "Yes and No", we would need a few more tests in the
testsuite.
If the answers are "No and naturally no", then let's remove the last three
lines in the hunk.
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Junio C Hamano @ 2008-07-23 18:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, git
In-Reply-To: <20080723081333.GA15243@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
> ...
>> If we started the process of diagnosing and fixing these issues earlier,
>> and had plausible code to address the issue already in 'next' before the
>> current -rc cycle started, the topic would have been an obvious candidate
>> for the coming release and I'd further say it would be even worth delaying
>> the release for a few weeks if it takes more time. But I have to say it
>> is too late for 1.6.0 now if we are just noticing and starting the
>> discussion.
>
> Well given that we now use submodules at work, and that git is
> nowadays somewhere in the top 5 of my most consciously (as opposed to
> the compiler that I rarely call by hand) used software suites (among my
> editor, my MUA, my shell and my tiling WM), I'm very much interested in
> tackling some things about what is (not) done with submodules yet.
Surely the effort is appreciated.
>> This comment goes to the issue Pierre raised last night as well.
>
> You mean the git checkout issue?
Oh, no; that misuse of parse_opt() that forgot KEEP_DASHDASH one was not
what I had in mind. I meant to say that your "switch branches between an
old pre-submodule rev and a new one that has a submodule at where a blob
or directory used to be" issue with a good explanation material was a good
starting point for submodule improvements for the next cycle.
I'd like the release schedule not too heavily based on "per feature", but
more time-based.
^ permalink raw reply
* Re: [PATCH 5/9] Allow the built-in exec path to be relative to the command invocation path
From: Junio C Hamano @ 2008-07-23 18:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1216667998-8879-6-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> If $(gitexecdir) is relative, it is interpreted relative to the command's
> invocation path, which usually is $(bindir).
>
> The Makefile rules were written with the assumption that $(gitexecdir) is
> an absolute path. We introduce a separate variable that names the
> (absolute) installation directory.
> ...
> +ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
> +gitexec_instdir = $(bindir)/$(gitexecdir)
> +else
Can we please have a brief comment in the Makefile near we define mandir,
infodir, gitexecdir and friends about this "relative to $(bindir)"
business?
Perhaps like:
Makefile | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 23f2185..8fa8f9a 100644
--- a/Makefile
+++ b/Makefile
@@ -171,6 +171,12 @@ ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
prefix = $(HOME)
+
+# Among these variables, gitexecdir and/or template_dir can be
+# specified as a relative path ../some/where/else; this is interpreted
+# as relative to $(bindir) and "git" at runtime figures out where they
+# are based on the path to the executable. This can help installing the
+# suite in a relocatable way.
bindir = $(prefix)/bin
mandir = $(prefix)/share/man
infodir = $(prefix)/share/info
Note that I just listed two variables out of thin air without studying;
you might be making other variables capable of relative path, in which
case they should also be listed there.
^ permalink raw reply related
* Re: [PATCH 0/9] Make gitexecdir relative to $(bindir) on Windows
From: Junio C Hamano @ 2008-07-23 18:28 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <200807222131.32828.johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> On Dienstag, 22. Juli 2008, Johannes Schindelin wrote:
>> Hi,
>>
>> On Mon, 21 Jul 2008, Johannes Sixt wrote:
>> > The problem was that argv[0] does not have a path in certain cases.
>>
>> Note that the same holds true for Linux when calling a program that is in
>> the PATH:
>
> Oh, boy!
>
>> I imagine that the proper solution would be to rip out lookup_prog() and
>> use it for non-Windows Git, too. Unless you want to limit the usefulness
>> of your patch series to Windows, that is.
>
> This certainly goes beyond what I am prepared to do. It is not my itch. The
> series is already much longer than I wanted, when there is a much simpler
> solution that solves *my* problem: to set bindir = $(gitexecdir).
If you are living in the Windows world, perhaps you could record the
installation location in resource somewhere from the installer and look it
up at runtime? Or is it considered a bad practice?
^ permalink raw reply
* 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
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