* 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
* 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
* 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
* 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
* 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: 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 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: [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
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