* Re: [PATCH] Allow git-runstatus to limit its scope to a set of files/directories.
From: Johannes Schindelin @ 2007-10-27 18:24 UTC (permalink / raw)
To: Michel Marti; +Cc: git
In-Reply-To: <1193508519-14140-1-git-send-email-mma@objectxp.com>
Hi,
On Sat, 27 Oct 2007, Michel Marti wrote:
> Signed-off-by: Michel Marti <mma@objectxp.com>
> ---
> IMO, the next step should be to tweak git-status/git-commit: I suggest
> introducing a new option '--what-if' to 'git-commit' that behaves like current
> 'git-status [<path>...]' and in return stop 'git-status' from displaying
> '[<path>...]' as "Changes to commit".
I am not sure this is the correct way to go, since "git status" as a "git
commit --dry-run" has worked well so far.
Besides, I would like to see builtin-commit go in as soon as possible, and
this patch would delay that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow git-runstatus to limit its scope to a set of files/directories.
From: Michel Marti @ 2007-10-27 18:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710271922340.4362@racer.site>
Johannes Schindelin wrote:
> On Sat, 27 Oct 2007, Michel Marti wrote:
>
>> Signed-off-by: Michel Marti <mma@objectxp.com>
>> ---
>> IMO, the next step should be to tweak git-status/git-commit: I suggest
>> introducing a new option '--what-if' to 'git-commit' that behaves like current
>> 'git-status [<path>...]' and in return stop 'git-status' from displaying
>> '[<path>...]' as "Changes to commit".
>
> I am not sure this is the correct way to go, since "git status" as a "git
> commit --dry-run" has worked well so far.
Maybe, but current git-status behaviour is somewhat illogical and I'm
pretty sure there are more than a few git-users that were puzzled after
calling "git-status some-dir" for the first time.
> Besides, I would like to see builtin-commit go in as soon as possible, and
> this patch would delay that.
Hmmm, why is that? The patch only touches git-runstatus, invoking
"git-status <path>" will behave as usual.
- Michel
^ permalink raw reply
* Re: recent change in git.git/master broke my repos
From: Daniel Barkalow @ 2007-10-27 20:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Randal L. Schwartz
In-Reply-To: <7vejfhulzn.fsf@gitster.siamese.dyndns.org>
On Fri, 26 Oct 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > On Thu, 25 Oct 2007, Jeff King wrote:
> >
> >> On Thu, Oct 25, 2007 at 07:32:36AM -0700, Randal L. Schwartz wrote:
> >>
> >> > I have echo "ref: refs/remotes/origin/master" >.git/refs/heads/upstream
> >> > so that my daily update script can go:
> >> >
> >> > git-fetch
> >> > if [ repo is on master, and is not dirty ];
> >> > git-merge upstream
> >> > fi
> >> >
> >> > Yesterday that worked.
> >> >
> >> > Today I get a rash of:
> >> >
> >> > fatal: Couldn't find remote ref refs/remotes/origin/master
> >> >
> >> > from my git-fetch.
> >>
> >> Randal and I discussed this a bit on IRC, and it turns out not to be
> >> related to the 'upstream' symref. Instead, he had a broken
> >> branch.master.merge config that pointed to "refs/remotes/origin/master"
> >> (which you can see from his script above doesn't actually get used).
> >>
> >> So presumably the old git-fetch didn't care that the contents of
> >> branch.*.master didn't exist (it's just that nothing got marked for
> >> merging), but the one just merged from the db/fetch-pack topic does.
> >>
> >> Is this behavior change intentional?
> >
> > It's not exactly intentional; it's just that nobody seems to have tested
> > this particular misconfiguration. It should probably report an error
> > (since the configuration is, in fact, broken and potentially misleading),
> > but it probably shouldn't be fatal and certainly shouldn't be so
> > uninformative.
>
> How would we proceed from here, then?
>
> If you had "branch.master.merge = refs/heads/foobar", kept
> running happily, and suddenly the remote stopped carrying that
> foobar branch, you would get a configuration that uses
> nonexistent remote branch name, so this is not purely a
> configuration error on the fetcher's side.
True, although I'd consider that a matter of configuration rot rather than
it being an okay configuration; the user probably still needs to figure
out what happened to it and what to use instead. Maybe we want to output a
message to stderr (although higher than the die() used to be, so that we
can report the reason that it was looking for the missing remote ref).
> Older git used to enumerate remote tracking branches explicitly,
> and one of the remote.origin.fetch entries would have said
> "refs/heads/foobar:refs/remotes/origin/foobar", and that would
> have made git-fetch fail with the error, complaining that such a
> branch does not exist.
>
> You are suggesting that git-fetch should not fail if
> remote.origin.fetch is refs/heads/*:refs/remotes/origin/*
> wildcard, and I think I can agree with that; "git pull" however
> should notice and and exit with an error.
>
> Perhaps something like this?
That looks like what I was going to write when I got to it (although I
would have had the flag inverted, which is less git style, I guess).
Acked-By: Daniel Barkalow <barkalow@iabervon.org>
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: remote#branch
From: Jan Hudec @ 2007-10-27 20:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <Pine.LNX.4.64.0710162228560.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]
On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Oct 2007, Jan Hudec wrote:
>
> > If it is a fragment, than "#" is the only correct separator and should
> > stay that way.
>
> You did not listen, did you? '#' is allowed in ref names. Therefore this
> character really would lock us in to only ever reference _one_ and _only_
> one remote branch at a time. This might have worked for cogito, but it
> does not for git.
>
> So, I say it again, '#' is _out_.
That does not imply it can't separate the ref from the repository...
> > If it is not a true fragment, than we might want to phase it out in
> > favor of something else. But I would strongly prefer staying within
> > characters allowed in URI (as per rfc2396).
>
> If you do that, "http://<xyz-with-branch>" would be ambiguous, wouldn't
> it? This would already reference an HTTP resource, and you could not
> embed refnames into the URL.
... and because of this actually has to. You are right.
> > As for multiple branches, separating them with "," feels logical to me,
> > no matter what separates them from the repository path. On the other
> > hand given that neither ":" nor "@" is allowed in refnames, reusing the
> > same separator would make sense especially if git switched to either of
> > those.
>
> ',' is allowed in ref names, so ',' is out.
Actually since many characters that are allowed in ref name are not allowed
in URL at all, the ref-name has to be url-escaped. Which brings all
characters back in, because they can always be specified escaped.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: merge vs rebase: Is visualization in gitk the only problem?
From: Daniel Barkalow @ 2007-10-27 20:59 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <8E86BDBA-A49A-49BB-8E00-8BF6DD7237E9@zib.de>
On Sat, 27 Oct 2007, Steffen Prohaska wrote:
> There are some discussions going on about merge vs. rebase. The
> suggestions by Dscho is to prefer rebase over merge in a
> CVS-style workflow.
>
> Rebase has definitely benefits but not all of its details
> are obvious at a first glance. Tell a newbie to read the
> git rebase man page and explain what git reabase does and
> you know what I mean. Rebase definitely can help to create a
> cleaner history. But it rewrites history and therefore destroys
> information, for example information about the original code
> base a patch was developed against, or merge conflicts that
> were resolved. You also need to decide when to use rebase and
> when to use merge. So you need to make a choice.
>
> Why not always use git merge?
>
> Is the only problem of git merge that it might create loops
> in the history with potentially long running parallel lines
> that are insufficiently visualized in gitk?
>
> If so, why not improve the visualization?
>
> Or is there any other deficiency of always using merge and
> never using rebase that I don't see?
Not all possible upstream systems support non-linear history. If upstream
is actually svn or cvs, you need to rebase in order for the other system
to be able to represent the result.
I think it's easier for someone from the future trying to figure out the
historical reason for some code to be a certain way if that code isn't
touched by a merge conflict resolution. If there is a conflict, the
resulting content is most directly due to a commit that has no explanation
aside from a note that there was a conflict there; it's somewhat easier to
understand if the code is entirely attributable to the commit that
logically introduces the change. (Although maybe we could make the display
take care of this; linearize the history using the rerere info in the
merge commit, and show that as the history, annotated suitably to indicate
that the blame for some of it falls partially on the merge commit.)
It's also more familiar for many users to be asked to place their changes
after all other committed changes, rather than leaving the ancestry pegged
at the last time they updated before starting to work.
> Obviously you can use git merge only if you want to have _all_
> changes from the other branch. But this is often what you
> want. In a CVS-style workflow you want to merge all changes
> from the shared branch before pushing. Why going through the
> hassel of git rebase?
Unless you've got a series of changes to a section that the upstream also
changed, it's the same amount of resolution, but rebase lets you resolve
logical collections of conflicts (i.e., those due to a single one of your
commits) individually. IIRC, merging my builtin-fetch topic after 1.5.3
had 3 scattered conflicts, and rebasing had 4 conflicts, with no more than
one per commit (so that I could test the resolutions independantly), and
the rebase was easier.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/8] push: change push to fail if short ref name does not exist
From: Daniel Barkalow @ 2007-10-27 21:42 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038081211-git-send-email-prohaska@zib.de>
On Sat, 27 Oct 2007, Steffen Prohaska wrote:
> 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.
>
> This commit changes push to fail if the remote ref does not yet
> exist and the refspec does not start with refs/. Remote refs must
> explicitly be created with their full name.
I agree with the change (and I think it's appropriate for master or next),
but your implementation is a bit too clever for my tastes.
> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> ---
> remote.c | 5 +++--
> t/t5516-fetch-push.sh | 34 ++++++++++++++++++++++++++++++++--
> 2 files changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/remote.c b/remote.c
> index 170015a..ec992c9 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -611,6 +611,7 @@ static int match_explicit(struct ref *src, struct ref *dst,
> struct ref *matched_src, *matched_dst;
>
> const char *dst_value = rs->dst;
> + const char * const orig_dst_value = rs->dst ? rs->dst : rs->src;
"lit_dst_value" would probably be a better description, and it might be
worth handling the rs->dst == NULL case where it's handled for dst_value.
Technically, this variable, when it doesn't match the final value of
dst_value, has a value that dst_value never had.
>
> if (rs->pattern)
> return errs;
> @@ -647,12 +648,12 @@ static int match_explicit(struct ref *src, struct ref *dst,
> case 1:
> break;
> case 0:
> - if (!memcmp(dst_value, "refs/", 5))
> + if (!memcmp(orig_dst_value , "refs/", 5))
> matched_dst = make_linked_ref(dst_value, dst_tail);
This should also be orig_dst_value, too. I know that dst_value and
orig_dst_value must be the same in this case, but it takes a bunch of
analysis to demonstrate that, and it's more intuitive to use the value
you've just checked anyway, and also to have all of case 0 use the
differently-computed destination.
> else
> error("dst refspec %s does not match any "
> "existing ref on the remote and does "
> - "not start with refs/.", dst_value);
> + "not start with refs/.", orig_dst_value);
Maybe the error should provide a hint if dst_value is not the same as
orig_dst_value? (if (!rs->dst) error("Did you mean %s?\n", dst_value);)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 4/8] rev-parse: teach "git rev-parse --symbolic" to print the full ref name
From: Daniel Barkalow @ 2007-10-27 21:53 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038083369-git-send-email-prohaska@zib.de>
On Sat, 27 Oct 2007, Steffen Prohaska wrote:
> "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".
>
> Note, this changes output of an established command. It might
> break existing setups. I checked that it does not break scripts
> in git.git.
I think this makes the --create option to push unnecessary, as interactive
users could use a suggested explicit value (or whatever they actually
meant), while scripts could replace $name with $(git rev-parse --symbolic
$name) as easily as they could add --create, and by more explicit as to
what they're doing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 5/8] push, send-pack: support pushing HEAD to real ref name
From: Daniel Barkalow @ 2007-10-27 22:03 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038084055-git-send-email-prohaska@zib.de>
On Sat, 27 Oct 2007, Steffen Prohaska wrote:
> 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.
I'd prefer this to be in set_refspecs in builtin-push. That way, it only
applies to command-line arguments and matches your description better. (If
you use a symbolic name on the command line, it follows it, and acts
exactly as if you used the name it points to).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 6/8] add ref_cmp_full_short() comparing full ref name with a short name
From: Daniel Barkalow @ 2007-10-27 22:16 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11935038084130-git-send-email-prohaska@zib.de>
On Sat, 27 Oct 2007, Steffen Prohaska wrote:
> ref_cmp_full_short(full_name, short_name) expands short_name according
> to the rules documented in git-rev-parse and compares the expanded
> name with full_name. It reports a match by returning 0.
>
> This function makes the rules for resolving refs to sha1s available
> for string comparison. Before this change, the rules were buried in
> get_sha1*() and dwim_ref().
>
> ref_cmp_full_short() will be used for matching refspecs in git-send-pack.
I think this and ref_matches_abbrev in remote.c should be both be
named to be more explicit as to which sets of rules they implement, and
should agree on order of arguments.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: remote#branch
From: Johannes Schindelin @ 2007-10-27 23:01 UTC (permalink / raw)
To: Jan Hudec; +Cc: Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071027204757.GA3058@efreet.light.src>
Hi,
On Sat, 27 Oct 2007, Jan Hudec wrote:
> On Tue, Oct 16, 2007 at 22:35:25 +0100, Johannes Schindelin wrote:
>
> > ',' is allowed in ref names, so ',' is out.
>
> Actually since many characters that are allowed in ref name are not
> allowed in URL at all, the ref-name has to be url-escaped. Which brings
> all characters back in, because they can always be specified escaped.
No. The URL part of it has to be encoded. But the ref names do _not_.
(If we really want to have a way to specify the remote URL and the
branch(es) we want to fetch _at the same time_.)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add test case for running from a subdirectory with GIT_WORK_TREE
From: Junio C Hamano @ 2007-10-28 0:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <Pine.LNX.4.64.0710271343270.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sat, 27 Oct 2007, Nguyễn Thái Ngọc Duy wrote:
>
>> +mkdir -p work/sub/dir || exit 1
>> +mv .git work
>> +if test "$1" = --normal; then
>> + say "Normal case"
>> +else
>> + say "Worktree case"
>> +fi
>> +test "$1" = --normal || mv work/.git repo.git || exit 1
>> +
>> +test "$1" = --normal || export GIT_DIR=$(pwd)/repo.git
>> +export GIT_CONFIG="$(pwd)"/$GIT_DIR/config
>> +test "$1" = --normal || export GIT_WORK_TREE=$(pwd)/work
>> +
>> +cd work/sub || exit 1
> ...
> Hmm? I would like to see this test case in the official git.git.
Me too ;-) It would help people fix the issues.
^ permalink raw reply
* Re: [PATCH] Remove outdated references to cogito in documentation
From: Junio C Hamano @ 2007-10-28 0:45 UTC (permalink / raw)
To: Dan McGee; +Cc: git
In-Reply-To: <1193504009-30689-1-git-send-email-dpmcgee@gmail.com>
I think this makes sense. NAKs?
^ permalink raw reply
* New features in gitk
From: Paul Mackerras @ 2007-10-28 1:39 UTC (permalink / raw)
To: git
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:
* The find and highlight functions have been combined into a single
function, and there is now a button for finding backwards as well as
a find forwards button. Thus you can now search for commits that
modify certain files or directories, or commits that add/remove a
given string, as well as searching for commits by commit message,
author, committer or headline.
* Combining the find and highlight functions freed up space that is
now used for a progress bar and a status window.
* There is now a font chooser accessible from the edit/preferences
window.
* Gitk now uses a new graph layout algorithm, which means it doesn't
have to generate the whole layout from top to bottom at startup
time, making startup faster. Gitk also uses a new style for drawing
short diagonal line segments that join an existing vertical line,
which is visually clearer when the segment crosses another line.
* Gitk caches the topology information used for the previous/next tag
and branch information, making startup faster.
Tk 8.5 is now in beta, meaning that some distros now have it
packaged. Gitk looks much nicer in Tk8.5 since it supports
anti-aliased fonts, so I strongly suggest that people install and use
Tk8.5 if possible.
Paul.
^ permalink raw reply
* tags disappear
From: James @ 2007-10-28 4:01 UTC (permalink / raw)
To: git
Hi all,
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?
Thanks!
.james
^ 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
* 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: [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: [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: 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: 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 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: [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 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 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 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
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