* Re: [PATCH 6/7] walk $PATH to generate list of commands for "help -a"
From: Scott Parish @ 2007-10-28 11:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodejv9gt.fsf@gitster.siamese.dyndns.org>
On Sun, Oct 28, 2007 at 03:07:14AM -0700, Junio C Hamano wrote:
> Scott Parish <sRp@srparish.net> writes:
>
> > 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.
> >> ...
> > 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?
>
> "git" binary will be found as /usr/bin/git while git-foo will be
> found as /usr/libexec/git/git-foo in such an installation that
> takes advantage of $(gitexecdir). And /usr/libexec/git/git will
> not exist. Using existence of /usr/bin/git (I am referring to
> your 'first directory on $PATH that contains the "git" binary'
> above) as the cue for the location of "main commands" is wrong.
Thanks for the clarification, that would be a problem. I've modified
the patch to list the main commands from git_exec_path(); i have
mixed feelings, but curious what you think.
sRp
--
Scott Parish
http://srparish.net/
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Peter Baumann @ 2007-10-28 11:14 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710280400v523e2130nd3286a88a4920a9c@mail.gmail.com>
On Sun, Oct 28, 2007 at 07:00:54PM +0800, Yin Ping wrote:
> On 10/28/07, Yin Ping <pkufranky@gmail.com> wrote:
>
> > When I type
> > gtlg --topo-order --pretty=oneline --abbrev-commit e92ea624 -p
> Sorry, my fault. gtlg is an alias for git-log
>
> > franky
> >
>
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
^ permalink raw reply
* Re: How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-28 11:00 UTC (permalink / raw)
To: git
In-Reply-To: <46dff0320710280357u23927960hd204760b3d664ce2@mail.gmail.com>
On 10/28/07, Yin Ping <pkufranky@gmail.com> wrote:
> When I type
> gtlg --topo-order --pretty=oneline --abbrev-commit e92ea624 -p
Sorry, my fault. gtlg is an alias for git-log
> franky
>
--
franky
^ permalink raw reply
* How to merge git://repo.or.cz/git-gui into git.git
From: Yin Ping @ 2007-10-28 10:57 UTC (permalink / raw)
To: git
I'm reading code of git.
When I type
gtlg --topo-order --pretty=oneline --abbrev-commit e92ea624 -p
in directory git cloned from git.git, I get
e92ea62... Merge branch 'master' of git://repo.or.cz/git-gui
c80d25d... git-gui: Correct 'git gui blame' in a subdirectory
diff --git a/git-gui.sh b/git-gui.sh
index 743b7d4..fa30ccc 100755
--- a/git-gui.sh
+++ b/git-gui.sh
...
git-gui.sh is in the git-gui directory but we see a/git-gui.sh here
other than a/git-gui/git-gui.sh.
And in git://repo.or.cz/git-gui, I see git-gui.sh in the top directory
I just wonder how does this happen and how to merge
git://repo.or.cz/git-gui into git.git this way?
--
franky
^ permalink raw reply
* Re: [RFH] gcc constant expression warning...
From: Florian Weimer @ 2007-10-28 10:21 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7dnvd6w.fsf@gitster.siamese.dyndns.org>
* Junio C. Hamano:
> 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);
x and y must be unsigned for this test to work (signed overflow is
undefined).
^ permalink raw reply
* Re: Many gits are offline this week
From: Mike Hommey @ 2007-10-28 10:07 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
On Thu, Oct 04, 2007 at 06:27:05PM -0700, Randal L. Schwartz wrote:
> >>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Not that it's hard to find, but just for the record, Randal's talk can
be viewed on http://video.google.com/videoplay?docid=1251251453592758541
Mike
^ permalink raw reply
* [PATCH] git.el: Run git-gc --auto after commits.
From: Alexandre Julliard @ 2007-10-28 10:07 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index e5ee8ce..e147da0 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -796,6 +796,7 @@ Return the list of files that haven't been handled."
(with-current-buffer buffer (erase-buffer))
(dolist (info files) (git-set-fileinfo-state info 'uptodate))
(git-call-process-env nil nil "rerere")
+ (git-call-process-env nil nil "gc" "--auto")
(git-refresh-files)
(git-refresh-ewoc-hf git-status)
(message "Committed %s." commit)
--
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: Junio C Hamano @ 2007-10-28 10:07 UTC (permalink / raw)
To: Scott Parish; +Cc: git
In-Reply-To: <20071028094530.GA7749@srparish.net>
Scott Parish <sRp@srparish.net> writes:
> 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.
>> ...
> 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?
"git" binary will be found as /usr/bin/git while git-foo will be
found as /usr/libexec/git/git-foo in such an installation that
takes advantage of $(gitexecdir). And /usr/libexec/git/git will
not exist. Using existence of /usr/bin/git (I am referring to
your 'first directory on $PATH that contains the "git" binary'
above) as the cue for the location of "main commands" is wrong.
> When i email the changes, should i keep emailing the whole
> patch series, or just the few patches that have changed?
It's up to you. Obviously, if you are replacing 2 patches out
of 100-patch series, you would not want to resend the whole
thing, though ;-)
^ permalink raw reply
* [PATCH] git.el: Refresh only the changed file marks when marking/unmarking all.
From: Alexandre Julliard @ 2007-10-28 10:06 UTC (permalink / raw)
To: git
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 0e5091c..e5ee8ce 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -842,7 +842,8 @@ Return the list of files that haven't been handled."
"Mark all files."
(interactive)
(unless git-status (error "Not in git-status buffer."))
- (ewoc-map (lambda (info) (setf (git-fileinfo->marked info) t) t) git-status)
+ (ewoc-map (lambda (info) (unless (git-fileinfo->marked info)
+ (setf (git-fileinfo->marked info) t))) git-status)
; move back to goal column after invalidate
(when goal-column (move-to-column goal-column)))
@@ -850,7 +851,9 @@ Return the list of files that haven't been handled."
"Unmark all files."
(interactive)
(unless git-status (error "Not in git-status buffer."))
- (ewoc-map (lambda (info) (setf (git-fileinfo->marked info) nil) t) git-status)
+ (ewoc-map (lambda (info) (when (git-fileinfo->marked info)
+ (setf (git-fileinfo->marked info) nil)
+ t)) git-status)
; move back to goal column after invalidate
(when goal-column (move-to-column goal-column)))
--
1.5.3.4.404.g5a866
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [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
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