* Re: New features in gitk
From: Jonathan del Strother @ 2007-10-29 8:31 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Paul Mackerras, git
In-Reply-To: <20071029062000.GB4310@artemis.corp>
On 29 Oct 2007, at 06:20, Pierre Habouzit wrote:
> On Sun, Oct 28, 2007 at 11:13:43PM +0000, Paul Mackerras wrote:
>>> * the 'sha1' input field is a major pain in the UI: the cut&paste
>>> interaction is very poor. I don't know why, but it's often
>>> very very
>>> hard to really copy the sha id, probably because it's
>>> selected by
>>> default.
>>
>> It's selected so that the contents are in the cut buffer and you can
>> paste them in an xterm with middle-button. Possibly I need to check
>> that control-C (or command-C under macos) is properly bound to copy.
>
> Well, doing ^C doesn't always copy it (probably a glitch wrt which
> input has the focus), and it certainly doesn't synchronize with the
> cut
> buffer for me. And it doesn't work for anyone at work either. I use
> ion
> with the KDE clipboard manager (klipper -- because I never managed to
> find a clipboard manager that is as good yet, not depending upon KDE),
> and at work most people use KDE, with the same klipper. Maybe it's
> a bad
> interaction, I should try to use it under gnome or so to see if it is.
>
FWIW, I have exactly the same problem under OS X. I've never figured
out a pattern that gives a guaranteed copy - I'll try playing around
today and see what I can find.
Actually, while I'm here, gitk semi-regularly ignores ⌘Q, which
ought to quit on OS X.
^ permalink raw reply
* Re: [PATCH] Speedup scanning for excluded files.
From: Pierre Habouzit @ 2007-10-29 8:02 UTC (permalink / raw)
To: Lars Knoll; +Cc: git
In-Reply-To: <200710290845.26727.lars@trolltech.com>
[-- Attachment #1: Type: text/plain, Size: 830 bytes --]
On Mon, Oct 29, 2007 at 07:45:26AM +0000, Lars Knoll wrote:
> +static int no_wildcard(const char *string)
> +{
> + return !strchr(string, '*') && !strchr(string, '?')
> && !strchr(string, '[') && !strchr(string, '{');
return string[strcspn(string, "*?[{")] == '\0';
is faster as it doesn't scan the string 4 time in the case where there
is no wildcard.
> +}
> +
> void add_exclude(const char *string, const char *base,
> int baselen, struct exclude_list *which)
> {
> struct exclude *x = xmalloc(sizeof (*x));
>
> + x->to_exclude = 1;
You used spaces in here, and in many places of your patch.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Speedup scanning for excluded files.
From: Lars Knoll @ 2007-10-29 7:45 UTC (permalink / raw)
To: git
Try to avoid a lot of work while scanning for excluded files,
by caching some more information when setting up the exclusion
data structure.
Speeds up 'git runstatus' on a repository containing the Qt sources by 30% and
reduces the amount of instructions executed (as measured by valgrind) by a
factor of 2.
---
I did a short timing measurement on the git repository itself, the timings
without and with the patch give:
[lars@dahab git (speedup)]$ time git runstatus > /dev/null
real 0m0.098s
user 0m0.068s
sys 0m0.020s
[lars@dahab git (speedup)]$ time ./git runstatus > /dev/null
real 0m0.033s
user 0m0.012s
sys 0m0.016s
Cheers,
Lars
dir.c | 58 ++++++++++++++++++++++++++++++++++++++++++----------------
dir.h | 7 +++++++
2 files changed, 49 insertions(+), 16 deletions(-)
diff --git a/dir.c b/dir.c
index 4c17d36..7bb5add 100644
--- a/dir.c
+++ b/dir.c
@@ -118,14 +118,32 @@ int match_pathspec(const char **pathspec, const char
*name, int namelen, int pre
return retval;
}
+static int no_wildcard(const char *string)
+{
+ return !strchr(string, '*') && !strchr(string, '?')
&& !strchr(string, '[') && !strchr(string, '{');
+}
+
void add_exclude(const char *string, const char *base,
int baselen, struct exclude_list *which)
{
struct exclude *x = xmalloc(sizeof (*x));
+ x->to_exclude = 1;
+ if (*string == '!') {
+ x->to_exclude = 0;
+ string++;
+ }
x->pattern = string;
+ x->patternlen = strlen(string);
x->base = base;
x->baselen = baselen;
+ x->flags = 0;
+ if (!strchr(string, '/'))
+ x->flags |= EXC_FLAG_NODIR;
+ if (no_wildcard(string))
+ x->flags |= EXC_FLAG_NOWILDCARD;
+ if (*string == '*' && no_wildcard(string+1))
+ x->flags |= EXC_FLAG_ENDSWITH;
if (which->nr == which->alloc) {
which->alloc = alloc_nr(which->alloc);
which->excludes = xrealloc(which->excludes,
@@ -209,7 +227,7 @@ void pop_exclude_per_directory(struct dir_struct *dir, int
stk)
* Return 1 for exclude, 0 for include and -1 for undecided.
*/
static int excluded_1(const char *pathname,
- int pathlen,
+ int pathlen, const char *basename,
struct exclude_list *el)
{
int i;
@@ -218,19 +236,20 @@ static int excluded_1(const char *pathname,
for (i = el->nr - 1; 0 <= i; i--) {
struct exclude *x = el->excludes[i];
const char *exclude = x->pattern;
- int to_exclude = 1;
+ int to_exclude = x->to_exclude;
- if (*exclude == '!') {
- to_exclude = 0;
- exclude++;
- }
-
- if (!strchr(exclude, '/')) {
+ if (x->flags & EXC_FLAG_NODIR) {
/* match basename */
- const char *basename = strrchr(pathname, '/');
- basename = (basename) ? basename+1 : pathname;
- if (fnmatch(exclude, basename, 0) == 0)
- return to_exclude;
+ if (x->flags & EXC_FLAG_NOWILDCARD) {
+ if (!strcmp(exclude, basename))
+ return to_exclude;
+ } else if (x->flags & EXC_FLAG_ENDSWITH) {
+ if (!strcmp(exclude + 1, pathname +
pathlen -x->patternlen + 1))
+ return to_exclude;
+ } else {
+ if (fnmatch(exclude, basename, 0) == 0)
+ return to_exclude;
+ }
}
else {
/* match with FNM_PATHNAME:
@@ -246,10 +265,15 @@ static int excluded_1(const char *pathname,
strncmp(pathname, x->base, baselen))
continue;
- if (fnmatch(exclude, pathname+baselen,
- FNM_PATHNAME) == 0)
+ if (x->flags & EXC_FLAG_NOWILDCARD) {
+ if (!strcmp(exclude, pathname + baselen))
+ return to_exclude;
+ } else {
+ if (fnmatch(exclude, pathname+baselen,
+ FNM_PATHNAME) == 0)
return to_exclude;
- }
+ }
+ }
}
}
return -1; /* undecided */
@@ -259,9 +283,11 @@ int excluded(struct dir_struct *dir, const char
*pathname)
{
int pathlen = strlen(pathname);
int st;
+ const char *basename = strrchr(pathname, '/');
+ basename = (basename) ? basename+1 : pathname;
for (st = EXC_CMDL; st <= EXC_FILE; st++) {
- switch (excluded_1(pathname, pathlen, &dir->exclude_list[st])) {
+ switch (excluded_1(pathname, pathlen, basename, &dir->exclude_list[st])) {
case 0:
return 0;
case 1:
diff --git a/dir.h b/dir.h
index a248a23..4dc3c6e 100644
--- a/dir.h
+++ b/dir.h
@@ -17,13 +17,20 @@ struct dir_entry {
char name[FLEX_ARRAY]; /* more */
};
+#define EXC_FLAG_NODIR 1
+#define EXC_FLAG_NOWILDCARD 2
+#define EXC_FLAG_ENDSWITH 4
+
struct exclude_list {
int nr;
int alloc;
struct exclude {
const char *pattern;
+ int patternlen;
const char *base;
int baselen;
+ int to_exclude;
+ int flags;
} **excludes;
};
--
1.5.3.4.383.gd90a7
^ permalink raw reply related
* Re: [BUG?] git-pull and git-merge don't support option --ff as the document says
From: Lars Hjemli @ 2007-10-29 7:14 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710280936g4b1022fcpab02e72b99afa0f@mail.gmail.com>
On 10/28/07, Yin Ping <pkufranky@gmail.com> wrote:
> Released git version 1.5.3.4
--ff/--no-ff is not part of any released git version; you'll need to
build the 'master' branch of git.git. And they're currently only
supported by git-merge, not git-pull (the same goes for --no-squash).
--
larsh
^ permalink raw reply
* Re: How to remove a specific hunk
From: Miles Bader @ 2007-10-29 7:03 UTC (permalink / raw)
To: Jeff King; +Cc: Andreas Ericsson, Pascal Obry, git
In-Reply-To: <20071026164926.GA21160@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> BTW, since this is inherently a non-git operation, there are other tools
> that some may find friendlier than an editor. Kompare will let you
> unapply differences, for example, and I would be shocked if emacs didn't
> have some tool for this.
M-x diff-mode
<move to bad hunk>
C-u C-c C-a
-Miles
--
Next to fried food, the South has suffered most from oratory.
-- Walter Hines Page
^ permalink raw reply
* [PATCH] core-tutorial: Catch up with current Git
From: Benoit Sigoure @ 2007-10-29 7:00 UTC (permalink / raw)
To: git; +Cc: gitster, Benoit Sigoure
No longer talk about Cogito since it's deprecated. Some scripts (such as
git-reset or git-branch) have undergone builtinification so adjust the text
to reflect this.
Fix a typo in the description of git-show-branch (merges are indicated by a
`-', not by a `.').
git-pull/git-push do not seem to use the dumb git-ssh-fetch/git-ssh-upload
(the text was probably missing a word).
Adjust a link that wasn't rendered properly because it was wrapped.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
I intentionally modified the text the least possible.
Documentation/core-tutorial.txt | 26 ++++++++++----------------
1 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index 6b2590d..d8e78ac 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -553,13 +553,8 @@ can explore on your own.
[NOTE]
Most likely, you are not directly using the core
-git Plumbing commands, but using Porcelain like Cogito on top
-of it. Cogito works a bit differently and you usually do not
-have to run `git-update-index` yourself for changed files (you
-do tell underlying git about additions and removals via
-`cg-add` and `cg-rm` commands). Just before you make a commit
-with `cg-commit`, Cogito figures out which files you modified,
-and runs `git-update-index` on them for you.
+git Plumbing commands, but using Porcelain such as `git-add`, `git-rm'
+and `git-commit'.
Tagging a version
@@ -686,8 +681,8 @@ $ git reset
and in fact a lot of the common git command combinations can be scripted
with the `git xyz` interfaces. You can learn things by just looking
-at what the various git scripts do. For example, `git reset` is the
-above two lines implemented in `git-reset`, but some things like
+at what the various git scripts do. For example, `git reset` used to be
+the above two lines implemented in `git-reset`, but some things like
`git status` and `git commit` are slightly more complex scripts around
the basic git commands.
@@ -805,8 +800,8 @@ you have, you can say
$ git branch
------------
-which is nothing more than a simple script around `ls .git/refs/heads`.
-There will be asterisk in front of the branch you are currently on.
+which used to be nothing more than a simple script around `ls .git/refs/heads`.
+There will be an asterisk in front of the branch you are currently on.
Sometimes you may wish to create a new branch _without_ actually
checking it out and switching to it. If so, just use the command
@@ -952,7 +947,7 @@ the later output lines is used to show commits contained in the
`master` branch, and the second column for the `mybranch`
branch. Three commits are shown along with their log messages.
All of them have non blank characters in the first column (`*`
-shows an ordinary commit on the current branch, `.` is a merge commit), which
+shows an ordinary commit on the current branch, `-` is a merge commit), which
means they are now part of the `master` branch. Only the "Some
work" commit has the plus `+` character in the second column,
because `mybranch` has not been merged to incorporate these
@@ -1086,7 +1081,7 @@ to help dumb transport downloaders.
There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
programs, which are 'commit walkers'; they outlived their
usefulness when git Native and SSH transports were introduced,
-and not used by `git pull` or `git push` scripts.
+and are not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `merge` that
with your current branch.
@@ -1193,7 +1188,7 @@ $ mb=$(git-merge-base HEAD mybranch)
The command writes the commit object name of the common ancestor
to the standard output, so we captured its output to a variable,
-because we will be using it in the next step. BTW, the common
+because we will be using it in the next step. By the way, the common
ancestor commit is the "New day." commit in this case. You can
tell it by:
@@ -1459,8 +1454,7 @@ Although git is a truly distributed system, it is often
convenient to organize your project with an informal hierarchy
of developers. Linux kernel development is run this way. There
is a nice illustration (page 17, "Merges to Mainline") in
-link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf
-[Randy Dunlap's presentation].
+link:http://www.xenotime.net/linux/mentor/linux-mentoring-2006.pdf[Randy Dunlap's presentation].
It should be stressed that this hierarchy is purely *informal*.
There is nothing fundamental in git that enforces the "chain of
--
1.5.3.4.398.g859b
^ permalink raw reply related
* [PATCH] Fix a small memory leak in builtin-add
From: Benoit Sigoure @ 2007-10-29 7:00 UTC (permalink / raw)
To: git; +Cc: gitster, Benoit Sigoure
In-Reply-To: <1193641233-3880-1-git-send-email-tsuna@lrde.epita.fr>
prune_directory and fill_directory allocated one byte per pathspec and never
freed it.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
---
I don't know whether this was intentionnal or not (since it's only a matter of
having small chunks of memory not being reclaimed and I don't think we can
enter these functions twice, so these are not leaks in the sense that the
program will consume more and more memory). But if it was intentionnal,
wouldn't it be better to put a small comment in the code saying so (so that
casual readers like me won't get surprised).
builtin-add.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index f9a6580..b8e6094 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -44,6 +44,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
die("pathspec '%s' did not match any files",
pathspec[i]);
}
+ free(seen);
}
static void fill_directory(struct dir_struct *dir, const char **pathspec,
@@ -135,6 +136,7 @@ static void refresh(int verbose, const char **pathspec)
if (!seen[i])
die("pathspec '%s' did not match any files", pathspec[i]);
}
+ free(seen);
}
static int git_add_config(const char *var, const char *value)
--
1.5.3.4.398.g859b
^ permalink raw reply related
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-29 6:45 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20071028111443.GA29183@xp.machine.xx>
On 10/28/07, Peter Baumann <waste.manager@gmx.de> wrote:
>
> Have a look at the subtree merge strategy [1] and at the following
> explanations how git-gui got initally merged.
>
> -Peter
>
> [1]: http://www.gelato.unsw.edu.au/archives/git/0702/40139.html
> [2]: http://www.gelato.unsw.edu.au/archives/git/0702/39661.html
>
>
When i merged git.git into git-gui with subtree strategy, I found all
histories of git.git merged into histories of git-gui (from 584
history entries to 11985). Is it possible that only histories related
to git-gui subdirectory in git.git(i.e. histories displayed by git-log
git-gui) are merged into?
1. my configuration:
~/git-gui$ git-remote show git
* remote git
URL: git://git.kernel.org/pub/scm/git/git.git
Tracked remote branches
master
~/git-gui$ git-remote show origin
* remote origin
URL: git://repo.or.cz/git-gui
Remote branch(es) merged with 'git pull' while on branch master
master
Tracked remote branches
master
~/git-gui$ gtlg --pretty=oneline --topo-order --first-parent | wc -l
584
2. pull with subtree strategy
~/git-gui$ git-pull -s subtree git master:master
3. after pull, all logs of git comes into git-gui (584->11985)
~/git-gui$ gtlg --pretty=oneline --topo-order | wc -l
11985
4. histories of git can be hiden by --first-parent
gtlg --pretty=oneline --topo-order --first-parent | wc -l
585
--
franky
^ permalink raw reply
* Re: [PATCH] Fix regression in fast-import.c due to strbufs.
From: Pierre Habouzit @ 2007-10-29 6:29 UTC (permalink / raw)
To: Shun Kei Leung
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Git ML
In-Reply-To: <e66701d40710281959q517eabecm87bcf54c7fe47741@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 403 bytes --]
On Mon, Oct 29, 2007 at 02:59:02AM +0000, Shun Kei Leung wrote:
> Hi Pierre,
>
> Thanks. You are the man! It works perfectly now.
Actually, I also was the one breaking it in the first place, but
you're welcome :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: New features in gitk
From: Pierre Habouzit @ 2007-10-29 6:24 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18213.6055.235067.730640@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 698 bytes --]
On dim, oct 28, 2007 at 11:13:43 +0000, Paul Mackerras wrote:
> Pierre Habouzit writes:
>
> > As you seem to be the guy to ask for, I've a couple of requests wrt
> > gitk.
> >
> > * the diff window is quite bad with merge commits, the colorization is
> > rather poor, and the last version you just merged isn't especially
> > better.
>
> That's not a request, that's a grizzle. :)
Right, would have I known a single word of Tcl, I would have provided
patches for that long time ago btw :P
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: New features in gitk
From: Pierre Habouzit @ 2007-10-29 6:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18213.6055.235067.730640@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]
On Sun, Oct 28, 2007 at 11:13:43PM +0000, Paul Mackerras wrote:
> Pierre Habouzit writes:
>
> > As you seem to be the guy to ask for, I've a couple of requests wrt
> > gitk.
> >
> > * the diff window is quite bad with merge commits, the colorization is
> > rather poor, and the last version you just merged isn't especially
> > better.
>
> That's not a request, that's a grizzle. :) What would you like it to
> look like?
I believe that git show/diff has it right: lines with a + should be in
the "added" color, and lines with a '-' in the "removed" one. gitk only
take the first "column" of +/- into account or sth I find awkward at
best, and I often go to the console to see a merge commit because of
that.
> > * the 'sha1' input field is a major pain in the UI: the cut&paste
> > interaction is very poor. I don't know why, but it's often very very
> > hard to really copy the sha id, probably because it's selected by
> > default.
>
> It's selected so that the contents are in the cut buffer and you can
> paste them in an xterm with middle-button. Possibly I need to check
> that control-C (or command-C under macos) is properly bound to copy.
Well, doing ^C doesn't always copy it (probably a glitch wrt which
input has the focus), and it certainly doesn't synchronize with the cut
buffer for me. And it doesn't work for anyone at work either. I use ion
with the KDE clipboard manager (klipper -- because I never managed to
find a clipboard manager that is as good yet, not depending upon KDE),
and at work most people use KDE, with the same klipper. Maybe it's a bad
interaction, I should try to use it under gnome or so to see if it is.
> > * the fact that it remembers the position where it was in the WM when
> > it was closed is really annoying. the WM is supposed to place the
> > window. With at least ion3 and xinerama it often shows up on the
> > wrong screen. Remembering the window size though is fine.
>
> That came in with some changes that make gitk start up correctly under
> windows. I could see about making it set the window position only
> under windows.
That'd be really great.
> > * still wrt the layout, the focus is quite cumbersome. Gitk would be
> > really really really nice to be used only from the keyboard, but
> > because of a very unclear focus policy, it really isn't for me.
> > Maybe it's just me, and I know this may not be 100% helpful, but I
> > never know which part of gitk will receive my keys (history part,
> > diff part, tree, ...).
>
> What focus policy would you like?
Well, what would make sense (to _me_ at least) would be some shortcuts
to move to the history panel (say e.g. using F1), or to the diff view
(using e.g. F2), or in the file list (say F3).
That would hilight with a black 1px line (like it does for other
inputs fields) to say that this is the primary window part that takes
the keyboard inputs atm. And when doing that, if you press 'down' or
'up' it would scroll the adequate panel. It's really confusing that the
keyboard (or hjkl) right now always make the history change.
This way you can make the difference between the keyboard shortcuts
that apply to the focused part of the window (up/down, pgup/pgdown are
IMHO of that kind), and the one that the user (or the default gitk) has
associated to a specific part, no matter if it has the focus. E.g. J/K
(or for emacsish people ^N/^P) could always move the history, that would
make sense.
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFH] gcc constant expression warning...
From: Linus Torvalds @ 2007-10-29 4:37 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Antti-Juhani Kaijanaho, git
In-Reply-To: <alpine.LFD.0.9999.0710282053590.22100@xanadu.home>
On Sun, 28 Oct 2007, Nicolas Pitre wrote:
>
> The test must also make sure off_t isn't signed, since in that case it
> can only hold 31 bits.
Sinc eneither 31 _nor_ 32 bits is really enough, it's perfectly fine to
just check that the size of "off_t" is *bigger* than 4 bytes, which my
pseudo-patch did.
Linus
^ permalink raw reply
* Re: [PATCH] Bisect: add "skip" to the short usage string.
From: David Symonds @ 2007-10-29 4:35 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio Hamano, git
In-Reply-To: <20071029053153.fe400886.chriscool@tuxfamily.org>
On 10/29/07, Christian Couder <chriscool@tuxfamily.org> wrote:
>
> -USAGE='[start|bad|good|next|reset|visualize|replay|log|run]'
> +USAGE='[start|bad|good|next|reset|visualize|replay|log|skip|run]'
> LONG_USAGE='git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
> reset bisect state and start bisection.
"skip" should be closer to the "bad" and "good" options, since it's
most similar to them in that list.
Dave.
^ permalink raw reply
* [PATCH] Bisect: add "skip" to the short usage string.
From: Christian Couder @ 2007-10-29 4:31 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-bisect.sh b/git-bisect.sh
index 180c6c2..f2bae53 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[start|bad|good|next|reset|visualize|replay|log|run]'
+USAGE='[start|bad|good|next|reset|visualize|replay|log|skip|run]'
LONG_USAGE='git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
reset bisect state and start bisection.
git bisect bad [<rev>]
--
1.5.3.4.1406.g1369
^ permalink raw reply related
* [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Scott R Parish @ 2007-10-29 3:30 UTC (permalink / raw)
To: git; +Cc: Scott R Parish
In-Reply-To: <1193474215-6728-6-git-send-email-srp@srparish.net>
Git had previously been using the $PATH for scripts--a previous
patch moved exec'ed commands to also use the $PATH. For consistency
"help -a" should also list commands in the $PATH.
The main commands are still listed from the git_exec_path(), but
the $PATH is walked and other git commands (probably extensions) are
listed.
Signed-off-by: Scott R Parish <srp@srparish.net>
---
help.c | 157 +++++++++++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 120 insertions(+), 37 deletions(-)
diff --git a/help.c b/help.c
index 34ac5db..855aeef 100644
--- a/help.c
+++ b/help.c
@@ -37,24 +37,25 @@ static inline void mput_char(char c, unsigned int num)
putchar(c);
}
-static struct cmdname {
- size_t len;
- char name[1];
-} **cmdname;
-static int cmdname_alloc, cmdname_cnt;
-
-static void add_cmdname(const char *name, int len)
+static struct cmdnames {
+ int alloc;
+ int cnt;
+ struct cmdname {
+ size_t len;
+ char name[1];
+ } **names;
+} main_cmds, other_cmds;
+
+static void add_cmdname(struct cmdnames *cmds, const char *name, int len)
{
- struct cmdname *ent;
- if (cmdname_alloc <= cmdname_cnt) {
- cmdname_alloc = cmdname_alloc + 200;
- cmdname = xrealloc(cmdname, cmdname_alloc * sizeof(*cmdname));
- }
- ent = xmalloc(sizeof(*ent) + len);
+ struct cmdname *ent = xmalloc(sizeof(*ent) + len);
+
ent->len = len;
memcpy(ent->name, name, len);
ent->name[len] = 0;
- cmdname[cmdname_cnt++] = ent;
+
+ ALLOC_GROW(cmds->names, cmds->cnt + 1, cmds->alloc);
+ cmds->names[cmds->cnt++] = ent;
}
static int cmdname_compare(const void *a_, const void *b_)
@@ -64,7 +65,42 @@ static int cmdname_compare(const void *a_, const void *b_)
return strcmp(a->name, b->name);
}
-static void pretty_print_string_list(struct cmdname **cmdname, int longest)
+static void uniq(struct cmdnames *cmds)
+{
+ int i, j;
+
+ if (!cmds->cnt)
+ return;
+
+ for (i = j = 1; i < cmds->cnt; i++)
+ if (strcmp(cmds->names[i]->name, cmds->names[i-1]->name))
+ cmds->names[j++] = cmds->names[i];
+
+ cmds->cnt = j;
+}
+
+static void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes) {
+ int ci, cj, ei;
+ int cmp;
+
+ ci = cj = ei = 0;
+ while (ci < cmds->cnt && ei < excludes->cnt) {
+ cmp = strcmp(cmds->names[ci]->name, excludes->names[ei]->name);
+ if (cmp < 0)
+ cmds->names[cj++] = cmds->names[ci++];
+ else if (cmp == 0)
+ ci++, ei++;
+ else if (cmp > 0)
+ ei++;
+ }
+
+ while (ci < cmds->cnt)
+ cmds->names[cj++] = cmds->names[ci++];
+
+ cmds->cnt = cj;
+}
+
+static void pretty_print_string_list(struct cmdnames *cmds, int longest)
{
int cols = 1, rows;
int space = longest + 1; /* min 1 SP between words */
@@ -73,9 +109,7 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
if (space < max_cols)
cols = max_cols / space;
- rows = (cmdname_cnt + cols - 1) / cols;
-
- qsort(cmdname, cmdname_cnt, sizeof(*cmdname), cmdname_compare);
+ rows = (cmds->cnt + cols - 1) / cols;
for (i = 0; i < rows; i++) {
printf(" ");
@@ -83,28 +117,27 @@ static void pretty_print_string_list(struct cmdname **cmdname, int longest)
for (j = 0; j < cols; j++) {
int n = j * rows + i;
int size = space;
- if (n >= cmdname_cnt)
+ if (n >= cmds->cnt)
break;
- if (j == cols-1 || n + rows >= cmdname_cnt)
+ if (j == cols-1 || n + rows >= cmds->cnt)
size = 1;
- printf("%-*s", size, cmdname[n]->name);
+ printf("%-*s", size, cmds->names[n]->name);
}
putchar('\n');
}
}
-static void list_commands(const char *exec_path)
+static unsigned int list_commands_in_dir(struct cmdnames *cmds,
+ const char *path)
{
unsigned int longest = 0;
const char *prefix = "git-";
int prefix_len = strlen(prefix);
- DIR *dir = opendir(exec_path);
+ DIR *dir = opendir(path);
struct dirent *de;
- if (!dir || chdir(exec_path)) {
- fprintf(stderr, "git: '%s': %s\n", exec_path, strerror(errno));
- exit(1);
- }
+ if (!dir || chdir(path))
+ return 0;
while ((de = readdir(dir)) != NULL) {
struct stat st;
@@ -125,16 +158,68 @@ static void list_commands(const char *exec_path)
if (longest < entlen)
longest = entlen;
- add_cmdname(de->d_name + prefix_len, entlen);
+ add_cmdname(cmds, de->d_name + prefix_len, entlen);
}
closedir(dir);
- printf("git commands available in '%s'\n", exec_path);
- printf("----------------------------");
- mput_char('-', strlen(exec_path));
- putchar('\n');
- pretty_print_string_list(cmdname, longest);
- putchar('\n');
+ return longest;
+}
+
+static void list_commands(void)
+{
+ unsigned int longest = 0;
+ unsigned int len;
+ const char *env_path = getenv("PATH");
+ char *paths, *path, *colon;
+ const char *exec_path = git_exec_path();
+
+ if (exec_path)
+ longest = list_commands_in_dir(&main_cmds, exec_path);
+
+ if (!env_path) {
+ fprintf(stderr, "PATH not set\n");
+ exit(1);
+ }
+
+ path = paths = xstrdup(env_path);
+ while (1) {
+ if ((colon = strchr(path, ':')))
+ *colon = 0;
+
+ len = list_commands_in_dir(&other_cmds, path);
+ if (len > longest)
+ longest = len;
+
+ if (!colon)
+ break;
+ path = colon + 1;
+ }
+ free(paths);
+
+ qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(*main_cmds.names), cmdname_compare);
+ uniq(&main_cmds);
+
+ qsort(other_cmds.names, other_cmds.cnt,
+ sizeof(*other_cmds.names), cmdname_compare);
+ uniq(&other_cmds);
+ exclude_cmds(&other_cmds, &main_cmds);
+
+ if (main_cmds.cnt) {
+ printf("available git commands in '%s'\n", exec_path);
+ printf("----------------------------");
+ mput_char('-', strlen(exec_path));
+ putchar('\n');
+ pretty_print_string_list(&main_cmds, longest);
+ putchar('\n');
+ }
+
+ if (other_cmds.cnt) {
+ printf("git commands available from elsewhere on your $PATH\n");
+ printf("---------------------------------------------------\n");
+ pretty_print_string_list(&other_cmds, longest);
+ putchar('\n');
+ }
}
void list_common_cmds_help(void)
@@ -188,7 +273,6 @@ int cmd_version(int argc, const char **argv, const char *prefix)
int cmd_help(int argc, const char **argv, const char *prefix)
{
const char *help_cmd = argc > 1 ? argv[1] : NULL;
- const char *exec_path = git_exec_path();
if (!help_cmd) {
printf("usage: %s\n\n", git_usage_string);
@@ -198,8 +282,7 @@ int cmd_help(int argc, const char **argv, const char *prefix)
else if (!strcmp(help_cmd, "--all") || !strcmp(help_cmd, "-a")) {
printf("usage: %s\n\n", git_usage_string);
- if(exec_path)
- list_commands(exec_path);
+ list_commands();
exit(0);
}
--
1.5.3.4.401.g19778-dirty
^ permalink raw reply related
* Re: [PATCH] Fix regression in fast-import.c due to strbufs.
From: Shun Kei Leung @ 2007-10-29 2:59 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Junio C Hamano, Johannes Schindelin, Shawn O. Pearce, Git ML
In-Reply-To: <20071026172523.GB5496@artemis.corp>
Hi Pierre,
Thanks. You are the man! It works perfectly now.
Regards,
Kevin
^ permalink raw reply
* Re: [PATCH 6/7] include $PATH in generating list of commands for "help -a"
From: Scott Parish @ 2007-10-29 2:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710281642220.4362@racer.site>
On Sun, Oct 28, 2007 at 04:51:00PM +0000, Johannes Schindelin wrote:
> > +static void subtract_cmds(struct cmdnames *a, struct cmdnames *b) {
>
> Maybe "exclude_cmds()", and choose more suggestive names for the
> parameters?
I was thinking set operations when i named this (hense "a" and "b"),
but i'll try this out.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [RFH] gcc constant expression warning...
From: Stephen Rothwell @ 2007-10-29 2:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Antti-Juhani Kaijanaho, git
In-Reply-To: <alpine.LFD.0.9999.0710282053590.22100@xanadu.home>
[-- Attachment #1: Type: text/plain, Size: 361 bytes --]
On Sun, 28 Oct 2007 20:55:32 -0400 (EDT) Nicolas Pitre <nico@cam.org> wrote:
>
> The test must also make sure off_t isn't signed, since in that case it
> can only hold 31 bits.
Posix says:
"blkcnt_t and off_t shall be signed integer types."
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFH] gcc constant expression warning...
From: Nicolas Pitre @ 2007-10-29 0:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Antti-Juhani Kaijanaho, git
In-Reply-To: <alpine.LFD.0.999.0710281000260.30120@woody.linux-foundation.org>
On Sun, 28 Oct 2007, Linus Torvalds wrote:
>
>
> On Sun, 28 Oct 2007, Antti-Juhani Kaijanaho wrote:
> >
> > A correct fix would be to check for the size of off_t in some other (and
> > defined) manner, but I don't know off_t well enough to suggest one.
>
> In this case, it's trying to make sense that "off_t" can hold more than 32
> bits. So I think that test can just be rewritten as
>
> if (sizeof(off_t) <= 4) {
> munmap(idx_map, idx_size);
> return error("pack too large for current definition of off_t in %s", path);
> }
>
> instead.
The test must also make sure off_t isn't signed, since in that case it
can only hold 31 bits.
Nicolas
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-10-28 23:13 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20071028183216.GA4310@artemis.corp>
Pierre Habouzit writes:
> As you seem to be the guy to ask for, I've a couple of requests wrt
> gitk.
>
> * the diff window is quite bad with merge commits, the colorization is
> rather poor, and the last version you just merged isn't especially
> better.
That's not a request, that's a grizzle. :) What would you like it to
look like?
> * the 'sha1' input field is a major pain in the UI: the cut&paste
> interaction is very poor. I don't know why, but it's often very very
> hard to really copy the sha id, probably because it's selected by
> default.
It's selected so that the contents are in the cut buffer and you can
paste them in an xterm with middle-button. Possibly I need to check
that control-C (or command-C under macos) is properly bound to copy.
> * the fact that it remembers the position where it was in the WM when
> it was closed is really annoying. the WM is supposed to place the
> window. With at least ion3 and xinerama it often shows up on the
> wrong screen. Remembering the window size though is fine.
That came in with some changes that make gitk start up correctly under
windows. I could see about making it set the window position only
under windows.
> * still wrt the layout, the focus is quite cumbersome. Gitk would be
> really really really nice to be used only from the keyboard, but
> because of a very unclear focus policy, it really isn't for me.
> Maybe it's just me, and I know this may not be 100% helpful, but I
> never know which part of gitk will receive my keys (history part,
> diff part, tree, ...).
What focus policy would you like?
Paul.
^ permalink raw reply
* Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name
From: Junio C Hamano @ 2007-10-28 20:58 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <55CCFD12-C10F-46A6-8D65-544231DEBF3F@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 28, 2007, at 5:03 PM, Junio C Hamano wrote:
> ...
>> An alternative, just to let me keep my nicer public image by
>> pretending to be constructive ;-)
>>
>> Introduce a configuration "remote.$name.push_default" whose
>> value can be a list of refs. Teach the push command without
>> refspecs:
>>
>> $ git push
>> $ git push $remote
>>
>> to pretend as if the listed refspecs are given, instead of the
>> traditional "matching branches" behaviour.
>>
>> Then, introduce another option
>>
>> $ git push --matching
>> $ git push --matching $remote
>>
>> to override that configuration, if set, so that the user who
>> usually pushes only the selected branches can use the "matching
>> branches" behaviour when needed.
>>
>> Along with your earlier "git push $remote HEAD" patch, this will
>> allow you to say:
>>
>> [remote "origin"]
>> push_default = HEAD
>>
>> and your
>>
>> $ git push
>>
>> will push only the current branch.
>
> Sounds reasonable; but it is more work. I'm not starting to
> implement this today.
Take your time; nobody is in a hurry.
If somebody usually uses "matching" behaviour, i.e. without
remote.$name.push_default configuration, but wants to push only
the current branch as a one-shot operation, we can obviously use
"git push $remote HEAD". But to be complete, it may make sense
to have another option
$ git push --current
that lets you omit $remote (and default to the value configured
with branch.$name.remote).
^ permalink raw reply
* Re: New features in gitk
From: Mike Hommey @ 2007-10-28 18:38 UTC (permalink / raw)
To: Pierre Habouzit, Paul Mackerras, git
In-Reply-To: <20071028183216.GA4310@artemis.corp>
On Sun, Oct 28, 2007 at 07:32:16PM +0100, Pierre Habouzit wrote:
> On dim, oct 28, 2007 at 01:39:34 +0000, Paul Mackerras wrote:
> > I just pulled the dev branch of gitk into the master branch, so the
> > master branch now has the new features and improvements that I have
> > been working on, namely: [...]
>
> As you seem to be the guy to ask for, I've a couple of requests wrt
> gitk.
(...)
* When running gitk --all, it would be nice if the current branch
was selected, instead of the topmost commit.
Mike
^ permalink raw reply
* Re: New features in gitk
From: Pierre Habouzit @ 2007-10-28 18:32 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18211.59478.188419.397886@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2629 bytes --]
On dim, oct 28, 2007 at 01:39:34 +0000, Paul Mackerras wrote:
> I just pulled the dev branch of gitk into the master branch, so the
> master branch now has the new features and improvements that I have
> been working on, namely: [...]
As you seem to be the guy to ask for, I've a couple of requests wrt
gitk.
* the diff window is quite bad with merge commits, the colorization is
rather poor, and the last version you just merged isn't especially
better.
* the 'sha1' input field is a major pain in the UI: the cut&paste
interaction is very poor. I don't know why, but it's often very very
hard to really copy the sha id, probably because it's selected by
default.
* hjkl in the history list do very very very curious things, whereas I
would expect j/k to do the same as (resp) down/up. Note that in
[Help->Key bindings] it's said it should work that way, but it
doesn't here at least. A way to customize bindings would be much
appreciated (I like vi bindings, and I miss ^U/^D, and ^E/^Y e.g.).
* I really really really miss an option to ignore whitespaces in
diffs, a small checkbox to view the full blown diff, or the one
without spaces changes (-w -b) would be _really_ great.
* the fact that it remembers the position where it was in the WM when
it was closed is really annoying. the WM is supposed to place the
window. With at least ion3 and xinerama it often shows up on the
wrong screen. Remembering the window size though is fine.
* wrt the layout, when the gitk window is resized, the resizing of the
three columns (subjects, commiter, date) is really cumbersome. I
would expect that the subject one would be the sole one to be
resized.
* still wrt the layout, the focus is quite cumbersome. Gitk would be
really really really nice to be used only from the keyboard, but
because of a very unclear focus policy, it really isn't for me.
Maybe it's just me, and I know this may not be 100% helpful, but I
never know which part of gitk will receive my keys (history part,
diff part, tree, ...).
* in the diff [lines of context] input, if you hit "down" it
decrements the number of lines which is okay, but _also_ moves the
selected history line which is not.
This list may sound harsh, I hope not, I love gitk, it's one of the
10 git commands I use the most.
Cheers,
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Miklos Vajna @ 2007-10-28 18:13 UTC (permalink / raw)
To: Yin Ping; +Cc: Peter Baumann, git
In-Reply-To: <46dff0320710280544r7f99ddf7xfd5aa7cefb39a9fe@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 335 bytes --]
On Sun, Oct 28, 2007 at 08:44:44PM +0800, Yin Ping <pkufranky@gmail.com> wrote:
> 3x. I have seen that subtree stategy is introduced in commit 68fa.
> However, I don't find any description in manual of git-merge. Should
> this be added to this manual or any other document?
i think the git-merge manpage should mention it.
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] honor the http.sslVerify option in shell scripts
From: Aurelien Bompard @ 2007-10-28 17:47 UTC (permalink / raw)
To: git, gitster
Signed-off-by: Aurélien Bompard <aurelien@bompard.org>
---
git-clone.sh | 3 ++-
git-ls-remote.sh | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 5e582fe..3bb683d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -28,7 +28,8 @@ get_repo_base() {
) 2>/dev/null
}
-if [ -n "$GIT_SSL_NO_VERIFY" ]; then
+if [ -n "$GIT_SSL_NO_VERIFY" -o \
+ "`git config --bool http.sslVerify`" = false ]; then
curl_extra_args="-k"
fi
diff --git a/git-ls-remote.sh b/git-ls-remote.sh
index d56cf92..3eb18d1 100755
--- a/git-ls-remote.sh
+++ b/git-ls-remote.sh
@@ -54,7 +54,8 @@ tmpdir=$tmp-d
case "$peek_repo" in
http://* | https://* | ftp://* )
- if [ -n "$GIT_SSL_NO_VERIFY" ]; then
+ if [ -n "$GIT_SSL_NO_VERIFY" -o \
+ "`git config --bool http.sslVerify`" = false ]; then
curl_extra_args="-k"
fi
if [ -n "$GIT_CURL_FTP_NO_EPSV" -o \
--
1.5.3.3
^ 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