* [PATCH] git.el: Fix typo in git-update-saved-file error handling.
From: Alexandre Julliard @ 2007-10-28 10:05 UTC (permalink / raw)
To: git
Spotted by Matthieu Lemerre.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8cfbdd7..0e5091c 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1353,7 +1353,7 @@ Commands:
"Update the corresponding git-status buffer when a file is saved.
Meant to be used in `after-save-hook'."
(let* ((file (expand-file-name buffer-file-name))
- (dir (condition-case nil (git-get-top-dir (file-name-directory file))))
+ (dir (condition-case nil (git-get-top-dir (file-name-directory file)) (error nil)))
(buffer (and dir (git-find-status-buffer dir))))
(when buffer
(with-current-buffer buffer
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] git.el: Fix typo in "Reverted file" message.
From: Alexandre Julliard @ 2007-10-28 10:05 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 4286d16..8cfbdd7 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -955,7 +955,7 @@ Return the list of files that haven't been handled."
(when modified
(apply #'git-call-process-env nil nil "checkout" "HEAD" modified))
(git-update-status-files (append added modified) 'uptodate)
- (git-success-message "Reverted" files))))
+ (git-success-message "Reverted" (git-get-filenames files)))))
(defun git-resolve-file ()
"Resolve conflicts in marked file(s)."
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH 6/7] walk $PATH to generate list of commands for "help -a"
From: Scott Parish @ 2007-10-28 9:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl3vzrs5.fsf@gitster.siamese.dyndns.org>
On Sat, Oct 27, 2007 at 11:18:02PM -0700, Junio C Hamano wrote:
> > We walk all the paths in $PATH collecting the names of "git-*"
> > commands. To help distinguish between the main git commands
> > and commands picked up elsewhere (probably extensions) we
> > print them seperately. The main commands are the ones that
> > are found in the first directory in $PATH that contains the
> > "git" binary.
>
> This is not right. $(gitexecdir) in Makefile is designed to
> allow distros to move git-* commands out of the primary user
> $PATH directories and install only "git" wrapper in /usr/bin.
> "Use the directory 'git' is in" rule breaks this.
>
> The "main commands" should be the first of argv_exec_path,
> EXEC_PATH_ENVIRONMENT or builtin_exec_path.
This is after we've already prepended the above three paths (if
they're specified) to $PATH, so yes, generally they should be in
one of those directories, but more generally, it will be in one of
the directories in $PATH.
Its not clear to me what exactly you're looking for me to change,
just the wording i'm using in my comment? Or are you refering to
the approach?
When i email the changes, should i keep emailing the whole
patch series, or just the few patches that have changed?
Thanks
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Steffen Prohaska @ 2007-10-28 8:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071028080654.GS14735@spearce.org>
On Oct 28, 2007, at 9:06 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>> On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
>>> Steffen Prohaska <prohaska@zib.de> writes:
>>>> @@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv,
>>>> const char *prefix)
>>>> {
>>>> int i, as_is = 0, verify = 0;
>>>> unsigned char sha1[20];
>>>> + char* real_name = 0;
>>>
>>> Pointer sign '*' in git sources go next to the name not the
>>> type, as:
>>>
>>> char *real_name = NULL;
>>
>> I know and I tried hard to follow this convention, although
>> I think its the wrong choice ;)
>
> Oh, hmm...
>
> char* a, b;
>
> What's the type of b? If you said "char*" you're wrong.
I know. Obviously, you need a combination of conventions.
- '*' is part of the type; put it there.
- Only define a single variable per statement.
My combined rule avoids your question. I typically use C++,
which make the second rule easier to follow, because you
defer defining variables until you really need them. There's
no need to save space at the start of the function block by
defining several variables in a single line.
> Git's style of putting the * next to the name makes it far easier to
> spot these sort of typing problems. At least that's my take on it.
Let's stop this discussion here. I'm not proposing to change the
rules. I'll follow the git coding conventions when submitting
patches to git, even if it's sometimes hard for me. I already packed
as much as possible in my editor configuration. Unfortunately,
I can't teach vim to always place the '*' correctly. At least I
don't know how to do this.
Steffen
^ permalink raw reply
* [RFH] gcc constant expression warning...
From: Junio C Hamano @ 2007-10-28 8:46 UTC (permalink / raw)
To: git
With the recent gcc, we get:
sha1_file.c: In check_packed_git_:
sha1_file.c:527: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is always false
sha1_file.c:527: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is always false
when compiling with
-O2 -Werror -Wall -Wold-style-definition \
-ansi -pedantic -std=c99 -Wdeclaration-after-statement
The offending lines are:
if (idx_size != min_size) {
/* make sure we can deal with large pack offsets */
off_t x = 0x7fffffffUL, y = 0xffffffffUL;
if (x > (x + 1) || y > (y + 1)) {
munmap(idx_map, idx_size);
^ permalink raw reply
* Re: [PATCH 1/8] push: change push to fail if short ref name does not exist
From: Steffen Prohaska @ 2007-10-28 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vabq3wvd6.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> You can use a branch's shortname to push it. Push used to create
>> the branch on the remote side if it did not yet exist. If you
>> specified the wrong branch accidentally it was created. A safety
>> valve that pushes only existing branches may help to avoid
>> errors.
>
> I do not agree with this change.
>
> If you misspelled the branch name (by the way, it is not a
> "shortname", but what follows refs/heads/ is _the_ name of the
> branch)
True. Is "short refname" the correct wording?
> "frotz" as "frtoz", and if a branch with the misspelled
> name did _not_ exist locally, it would fail, with or without
> this change, which is a good thing.
>
> But if you named "nitfol" that exists locally when you meant to
> push "frotz" out, if "nitfol" remotely existed, we will push
> that anyway by mistake, even with this change. It will prevent
> the push only when "nitfol" did not happen to exist at the
> remote side.
My proposed change is more defensive than the current
implementation. It allows distinguishing between "push existing
branch" and "create new branch on the remote side", which I
believe is a good thing. The current implementation uses
the same command line in both cases.
Daniel suggested that git push should print a recommendation
what full ref to use. This would make it easy to correct
the command. Ot you could use the '--create' flag to make
your intention explicit.
If we take the "push origin HEAD" patch, the existence check is
even more important. If you're on the wrong branch and push HEAD
you may be surprised if a new branch is created. This can be
avoided by requiring either a full ref or the '--create' flag.
> Earlier there was a discussion to introduce an optional
> configuration that makes "git push" without any parameter to
> push only the current branch out, in order to help people who
> work with shared remote central repository. That might be a
> better alternative to avoid pushing out wrong branch by
> mistake. That approach would also make your 8/8 unnecessary.
I didn't have the impression that the discussion went in
this direction. There were quite a few people who just said
"git push" is the counter-part of "git fetch". Therefore
"git push" pushes _all_ branches. Period.
With "git push HEAD" 5/8 you could now push only the current branch
(its existence would be verified if 1/8 is also accepted).
8/8 solves a different issue, too. I never advance local branches if
I do not intend to push them. Therefore I can always say "git push"
without any argument. It does always the right thing for me; except
for the annoying error messages that are avoided by 8/8. With 8/8
I can push several local branches while ignoring the ones that I'm
not interested in.
Steffen
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Junio C Hamano @ 2007-10-28 8:24 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <79CE31EE-0975-48EB-8B3E-FC9D6A8EB3E4@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> So the idea of --symbolic is really to return the argv as is?
> No change whatsoever allowed. Why would someone need this?
> Is it only for convenience when writing shell code?
rev-parse _is_ for convenience for writing shell scripts, to
sift various parameters into "rev-list arguments" and "non
rev-list arguments".
^ permalink raw reply
* Re: [PATCH 8/8] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-10-28 8:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfxzvwvde.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> git push reports errors if a remote ref is not a strict subset
>> of a local ref. The push wouldn't be a fast-forward and is
>> therefore refused. This is in general a good idea.
>
>> This commit teaches git push to be quiet if the local is a strict
>> subset of the remote and no refspec is explicitly specified on
>> the command line. If the --verbose flag is used a "note:" is
>> printed for each ignored branch.
>
> What happens to the summary reporting after such a push? Does
> it say "branch foo was not pushed because you did not touch it
> since you fetched and it is already stale with respect to the
> remote side which has updates since then"?
It says nothing, it's quiet, as promised in the commit message ;)
That's the point of this patch.
But I see your point. Maybe it should say something like
"ignored 2 branches, which are strict subsets of remote."
"use --verbose for details."
?
> How does this interact with the "pretend we have fetched
> immediately after we pushed by updating the corresponding remote
> tracking branch" logic?
I doesn't change a remote tracking branch. I'll add a test
confirming this.
Steffen
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Shawn O. Pearce @ 2007-10-28 8:06 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git
In-Reply-To: <79CE31EE-0975-48EB-8B3E-FC9D6A8EB3E4@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> >Steffen Prohaska <prohaska@zib.de> writes:
> >>@@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv,
> >>const char *prefix)
> >> {
> >> int i, as_is = 0, verify = 0;
> >> unsigned char sha1[20];
> >>+ char* real_name = 0;
> >
> >Pointer sign '*' in git sources go next to the name not the
> >type, as:
> >
> > char *real_name = NULL;
>
> I know and I tried hard to follow this convention, although
> I think its the wrong choice ;)
Oh, hmm...
char* a, b;
What's the type of b? If you said "char*" you're wrong.
Git's style of putting the * next to the name makes it far easier to
spot these sort of typing problems. At least that's my take on it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name
From: Steffen Prohaska @ 2007-10-28 8:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwst7wvdr.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> This teaches "push <remote> HEAD" to resolve HEAD on the local
>> side to its real ref name, e.g. refs/heads/master, and then
>> use the real ref name on the remote side to search a matching
>> remote ref.
>
> This probably is a good idea.
I'll think about Daniel's suggestion of implementing it
differently.
>> + if (real_name) {
>> + free(real_name);
>> + }
>
> Excess and unnecessary brace pair.
When are excess and unnecessary braces acceptable?
Is
if (something) {
printf("text %d"
"more text %d"
"and even more %d\n"
, a, b, c);
}
ok? Or should I avoid braces there, too?
Steffen
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Steffen Prohaska @ 2007-10-28 7:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3avvy9yc.fsf@gitster.siamese.dyndns.org>
On Oct 28, 2007, at 8:28 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> "git rev-parse --symbolic" used to return the ref name as it was
>> specified on the command line. This is changed to returning the
>> full matched ref name, i.e. "git rev-parse --symbolic master"
>> now typically returns "refs/heads/master".
>
> This is to expose "dwim_ref" logic, so it might be a good idea
> to introduce a new option --dwim-ref for this purpose.
>
> git rev-parse --symbolic master^2
>
> is designed to give "master^2" or fail if "master" is not a
> merge.
So the idea of --symbolic is really to return the argv as is?
No change whatsoever allowed. Why would someone need this?
Is it only for convenience when writing shell code?
> Similarly, you would diagnose a failure if somebody asks
> to show
>
> git rev-parse --dwim-ref master~4
>
> instead of giving "refs/heads/master~4".
What I proposed is to teach git rev-parse to return a full
symbolic ref name. Maybe
git rev-parse --full-symbolic
git rev-parse --full-ref
But honestly, I don't care that much about this patch. Maybe
we just put it aside?
>> +static void show_rev(int type, const unsigned char *sha1, const
>> char *name, const char* real_name)
>> @@ -131,7 +133,7 @@ static void show_default(void)
>>
>> def = NULL;
>> if (!get_sha1(s, sha1)) {
>> - show_rev(NORMAL, sha1, s);
>> + show_rev(NORMAL, sha1, s, 0);
>
> A null pointer constant in git sources is spelled "NULL" not "0".
Ok. I'll fix this in all patches.
>> @@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv,
>> const char *prefix)
>> {
>> int i, as_is = 0, verify = 0;
>> unsigned char sha1[20];
>> + char* real_name = 0;
>
> Pointer sign '*' in git sources go next to the name not the
> type, as:
>
> char *real_name = NULL;
I know and I tried hard to follow this convention, although
I think its the wrong choice ;)
Steffen
^ permalink raw reply
* Re: New features in gitk
From: Steffen Prohaska @ 2007-10-28 7:36 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, git
In-Reply-To: <18212.13862.637991.30536@cargo.ozlabs.ibm.com>
On Oct 28, 2007, at 8:11 AM, Paul Mackerras wrote:
> Linus Torvalds writes:
>
>> However, that crazy green bar chasing back-and-forth int he "reading"
>> phase is really quite visually distracting. Maybe it looks better in
>> Tk8.5, but it does look pretty annoying in the version I have. Can
>> you
>> tone that down a bit?
I have the same impression.
> Yeah. Actually what I'd like is to know how many commits git log is
> going to give me, so that I can do a normal progress bar whose length
> is proportional to commits_read / total_commits.
Can you use something like a rotating wheel, if the total size
of the task is unknown.
Or if you know an upper bound on the number of expected commits,
you could use this as total_commits. And adjust the upper
bound if more information becomes available.
Or you just print the number of commits already read and the
user is happy because something is changing.
Steffen
^ permalink raw reply
* Re: [PATCH 1/8] push: change push to fail if short ref name does not exist
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038081211-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> You can use a branch's shortname to push it. Push used to create
> the branch on the remote side if it did not yet exist. If you
> specified the wrong branch accidentally it was created. A safety
> valve that pushes only existing branches may help to avoid
> errors.
I do not agree with this change.
If you misspelled the branch name (by the way, it is not a
"shortname", but what follows refs/heads/ is _the_ name of the
branch) "frotz" as "frtoz", and if a branch with the misspelled
name did _not_ exist locally, it would fail, with or without
this change, which is a good thing.
But if you named "nitfol" that exists locally when you meant to
push "frotz" out, if "nitfol" remotely existed, we will push
that anyway by mistake, even with this change. It will prevent
the push only when "nitfol" did not happen to exist at the
remote side.
Earlier there was a discussion to introduce an optional
configuration that makes "git push" without any parameter to
push only the current branch out, in order to help people who
work with shared remote central repository. That might be a
better alternative to avoid pushing out wrong branch by
mistake. That approach would also make your 8/8 unnecessary.
^ permalink raw reply
* Re: [PATCH 8/8] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038083335-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> git push reports errors if a remote ref is not a strict subset
> of a local ref. The push wouldn't be a fast-forward and is
> therefore refused. This is in general a good idea.
> This commit teaches git push to be quiet if the local is a strict
> subset of the remote and no refspec is explicitly specified on
> the command line. If the --verbose flag is used a "note:" is
> printed for each ignored branch.
What happens to the summary reporting after such a push? Does
it say "branch foo was not pushed because you did not touch it
since you fetched and it is already stale with respect to the
remote side which has updates since then"?
How does this interact with the "pretend we have fetched
immediately after we pushed by updating the corresponding remote
tracking branch" logic?
^ permalink raw reply
* Re: [PATCH 7/8] push: use same rules as git-rev-parse to resolve refspecs
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038083116-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> This commit changes the rules for resolving refspecs to match the
> rules for resolving refs in rev-parse. git-rev-parse uses clear rules
> to resolve a short ref to its full name, which are well documented.
> The rules for resolving refspecs documented in git-send-pack were
> less strict and harder to understand. This commit replaces them by
> the rules of git-rev-parse.
>
> The unified rules are easier to understand and better resolve ambiguous
> cases. You can now push from a repository containing several branches
> ending on the same short name.
>
> Note, this breaks existing setups. For example "master" will no longer
> resolve to "origin/master".
It may "break" but I think it is a good change.
^ permalink raw reply
* Re: [PATCH 6/8] add ref_cmp_full_short() comparing full ref name with a short name
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038084130-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> diff --git a/sha1_name.c b/sha1_name.c
> index b820909..2a1e093 100644
> --- a/sha1_name.c
> +++ b/sha1_name.c
> @@ -249,6 +249,20 @@ static const char *ref_fmt[] = {
> NULL
> };
>
> +int ref_cmp_full_short(const char *full_name, const char *short_name)
> +{
> + const char **p;
> + const int short_name_len = strlen(short_name);
> +
> + for (p = ref_fmt; *p; p++) {
> + if (strcmp(full_name, mkpath(*p, short_name_len, short_name)) == 0) {
We usually say "!strcmp()" instead for readability.
^ permalink raw reply
* Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038084055-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> This teaches "push <remote> HEAD" to resolve HEAD on the local
> side to its real ref name, e.g. refs/heads/master, and then
> use the real ref name on the remote side to search a matching
> remote ref.
This probably is a good idea.
> + if (real_name) {
> + free(real_name);
> + }
Excess and unnecessary brace pair.
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038083369-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> "git rev-parse --symbolic" used to return the ref name as it was
> specified on the command line. This is changed to returning the
> full matched ref name, i.e. "git rev-parse --symbolic master"
> now typically returns "refs/heads/master".
This is to expose "dwim_ref" logic, so it might be a good idea
to introduce a new option --dwim-ref for this purpose.
git rev-parse --symbolic master^2
is designed to give "master^2" or fail if "master" is not a
merge. Similarly, you would diagnose a failure if somebody asks
to show
git rev-parse --dwim-ref master~4
instead of giving "refs/heads/master~4".
> +static void show_rev(int type, const unsigned char *sha1, const char *name, const char* real_name)
> @@ -131,7 +133,7 @@ static void show_default(void)
>
> def = NULL;
> if (!get_sha1(s, sha1)) {
> - show_rev(NORMAL, sha1, s);
> + show_rev(NORMAL, sha1, s, 0);
A null pointer constant in git sources is spelled "NULL" not "0".
> @@ -213,6 +215,7 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
> {
> int i, as_is = 0, verify = 0;
> unsigned char sha1[20];
> + char* real_name = 0;
Pointer sign '*' in git sources go next to the name not the
type, as:
char *real_name = NULL;
^ permalink raw reply
* Re: [PATCH 3/8] add get_sha1_with_real_ref() returning full name of ref on demand
From: Junio C Hamano @ 2007-10-28 7:28 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1193503808519-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> The new function can be used by "git rev-parse" to print the full
> name of the matched ref and can be used by "git send-pack" to expand
> a local ref to its full name.
"can be"? "will be used to implement git rev-parse --some-option"?
> +static int get_sha1_1(const char *name, int len, unsigned char *sha1, char **real_ref);
>
> static int get_parent(const char *name, int len,
> unsigned char *result, int idx)
> {
> unsigned char sha1[20];
> - int ret = get_sha1_1(name, len, sha1);
> + int ret = get_sha1_1(name, len, sha1, /*real_ref=*/ 0);
A null pointer constant in git sources is spelled as "NULL", not "0".
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-10-28 7:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0710272229430.30120@woody.linux-foundation.org>
Linus Torvalds writes:
> However, that crazy green bar chasing back-and-forth int he "reading"
> phase is really quite visually distracting. Maybe it looks better in
> Tk8.5, but it does look pretty annoying in the version I have. Can you
> tone that down a bit?
Yeah. Actually what I'd like is to know how many commits git log is
going to give me, so that I can do a normal progress bar whose length
is proportional to commits_read / total_commits. With --topo-order
(or --date-order) it has to get to the last commit before it outputs
the first commit, doesn't it? So could it print the total number of
commits on a line by itself at the start of its output? (Presumably
it would need a --commit-count flag to enable that behaviour.)
Other than that, I could slow the progress bar down, or do a bar of
moving diagonal stripes, or something.
Paul.
^ permalink raw reply
* Re: [PATCH 5/7] use only the $PATH for exec'ing git commands
From: Adam Roben @ 2007-10-28 6:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott R Parish, git
In-Reply-To: <7vlk9nzrrv.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Scott R Parish <srp@srparish.net> writes:
>
>
>> diff --git a/exec_cmd.c b/exec_cmd.c
>> index 8b681d0..c228dbf 100644
>> --- a/exec_cmd.c
>> +++ b/exec_cmd.c
>> @@ -29,85 +29,68 @@ const char *git_exec_path(void)
>> return builtin_exec_path;
>> }
>>
>> +static void add_path(struct strbuf *out, const char *path)
>> +{
>> + if (path && strlen(path)) {
>>
>
> I wonder if s/strlen(path)/*path/ micro-optimization is worth
> doing. Ideally, if built-in strlen() is used, the compiler
> should be clever enough to notice it, though...
>
You could always just check path[0] instead of calling strlen.
-Adam
^ permalink raw reply
* Re: [PATCH 6/7] walk $PATH to generate list of commands for "help -a"
From: Junio C Hamano @ 2007-10-28 6:18 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193474215-6728-6-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> Git had previously been using the $PATH for scripts--a previous
> patch moved exec'ed commands to also use the $PATH. For consistancy
> "help -a" should also use the $PATH.
s/consistancy/consistency/
> We walk all the paths in $PATH collecting the names of "git-*"
> commands. To help distinguish between the main git commands
> and commands picked up elsewhere (probably extensions) we
> print them seperately. The main commands are the ones that
> are found in the first directory in $PATH that contains the
> "git" binary.
This is not right. $(gitexecdir) in Makefile is designed to
allow distros to move git-* commands out of the primary user
$PATH directories and install only "git" wrapper in /usr/bin.
"Use the directory 'git' is in" rule breaks this.
The "main commands" should be the first of argv_exec_path,
EXEC_PATH_ENVIRONMENT or builtin_exec_path.
> diff --git a/help.c b/help.c
> index ce3d795..ee4fce0 100644
> --- a/help.c
> +++ b/help.c
> @@ -64,7 +69,42 @@ static int cmdname_compare(const void *a_, const void *b_)
> ...
> +static void subtract_cmds(struct cmdnames *a, struct cmdnames *b) {
> + int ai, aj, bi;
> +
> + ai = aj = bi = 0;
> + while (ai < a->cnt && bi < b->cnt) {
> + if (0 > strcmp(a->names[ai]->name, b->names[bi]->name))
> + a->names[aj++] = a->names[ai++];
> + else if (0 > strcmp(a->names[ai]->name, b->names[bi]->name))
> + bi++;
> + else
> + ai++, bi++;
In general, xxxcmp(a, b) is designed to return the same sign as
"a - b" (subtract b from a, using an appropriate definition of
"subtract" in the domain of a and b). It is a good habit to
write:
strcmp(a, b) < 0 strcmp(a, b) > 0
because these give the same sign as
a < b a > b
and makes your program easier to read.
> @@ -122,18 +168,66 @@ static void list_commands(const char *exec_path)
> if (has_extension(de->d_name, ".exe"))
> entlen -= 4;
>
> + if (has_extension(de->d_name, ".perl") ||
> + has_extension(de->d_name, ".sh"))
> + continue;
> +
This needs a good justification.
If you have "." on PATH, and you run ./git in a freshly built
source directory, "git relink.perl" would try to run
./git-relink.perl.
I do not think excluding these is necessary nor is a good idea.
> +static void list_commands()
> +{
ANSI. "static void list_commands(void)".
> + path = paths = xstrdup(env_path);
> + while ((char *)1 != path) {
> + if ((colon = strchr(path, ':')))
> + *colon = 0;
> +
> + len = list_commands_in_dir(path);
> + longest = MAX(longest, len);
> +
> + path = colon + 1;
> + }
I know that on modern architectures bit representation of
(char*) NULL is the same as integer 0 of the same size as a
pointer, and adding 1 to it would yield (char *)1, but the above
feels _dirty_.
while (1) {
...
if (!colon)
break;
path = colon + 1;
}
^ permalink raw reply
* Re: [PATCH 5/7] use only the $PATH for exec'ing git commands
From: Junio C Hamano @ 2007-10-28 6:18 UTC (permalink / raw)
To: Scott R Parish; +Cc: git
In-Reply-To: <1193474215-6728-5-git-send-email-srp@srparish.net>
Scott R Parish <srp@srparish.net> writes:
> diff --git a/exec_cmd.c b/exec_cmd.c
> index 8b681d0..c228dbf 100644
> --- a/exec_cmd.c
> +++ b/exec_cmd.c
> @@ -29,85 +29,68 @@ const char *git_exec_path(void)
> return builtin_exec_path;
> }
>
> +static void add_path(struct strbuf *out, const char *path)
> +{
> + if (path && strlen(path)) {
I wonder if s/strlen(path)/*path/ micro-optimization is worth
doing. Ideally, if built-in strlen() is used, the compiler
should be clever enough to notice it, though...
^ permalink raw reply
* Re: New features in gitk
From: Linus Torvalds @ 2007-10-28 5:34 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18211.59478.188419.397886@cargo.ozlabs.ibm.com>
On Sun, 28 Oct 2007, 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:
*Huge* improvements. It is now really nice to start up gitk even on the
full kernel history.
However, that crazy green bar chasing back-and-forth int he "reading"
phase is really quite visually distracting. Maybe it looks better in
Tk8.5, but it does look pretty annoying in the version I have. Can you
tone that down a bit?
But this has both the layout performance improvements and the fixes to
only show selected files in the diff view by default, so I hope this gets
merged into standard git soon..
Linus
^ permalink raw reply
* Re: tags disappear
From: Shawn O. Pearce @ 2007-10-28 5:05 UTC (permalink / raw)
To: James; +Cc: git
In-Reply-To: <C7372F7E-F29E-4E40-AE96-7AC8CB0EE0CE@nc.rr.com>
James <jtp@nc.rr.com> wrote:
> Sorry for the dumb question. Hoping someone can lead me in the right
> direction.
>
> I use git in a pretty basic setup. One branch, I'm the only user,
> etc. When I set up a tag (with a command like "git tag v1.1.6"), and
> then push the changes to the server, the tag doesn't remain when I
> clone the tree somewhere else.
>
> Can anyone explain why, and possibly how to keep tags on a push/clone?
You need to push the tag to the server with:
git push server tag v1.1.6
But you should make such takes annotated with "git tag -a" so they
are proper objects in their own right, rather than just refs pointing
at commits.
--
Shawn.
^ 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