* Re: Suggestion: drop 'g' in git-describe suffix
From: Johannes Schindelin @ 2006-11-02 10:59 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <4549CE2A.3010808@xs4all.nl>
Hi,
On Thu, 2 Nov 2006, Han-Wen Nienhuys wrote:
> [lilydev@haring git]$ git describe
> v1.4.3.3-g1e1f76e
> [lilydev@haring git]$ git show g1e1f76e
You'd want to do
git show v1.4.3.3-g1e1f76e
Hth,
^ permalink raw reply
* Re: git and "dumb protocols"
From: Petr Baudis @ 2006-11-02 11:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0611021155500.1670@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Dear diary, on Thu, Nov 02, 2006 at 11:57:16AM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Thu, 2 Nov 2006, Petr Baudis wrote:
>
> > If you already have SSH access to the server, why not compile Git
> > there and install it to your $HOME, though?
>
> Could be a number of reasons:
>
> - no compiler
> - quota issues
good points.
> - missing support for that particular platform
If not with conjunction with the following ("- time constraints"), it
would be superb to add support for that particular platform. :^)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Petr Baudis @ 2006-11-02 11:03 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: hanwen, git
In-Reply-To: <4549CA6B.4090909@shadowen.org>
Dear diary, on Thu, Nov 02, 2006 at 11:37:31AM CET, I got a letter
where Andy Whitcroft <apw@shadowen.org> said that...
> The g prefix on the sha1 _fragment_ it to indicate that it is in fact
> a truncated sha1, not a complete one.
I think it's rather to indicate that it is a sha1 at all.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: weird strncmp usage?
From: Petr Baudis @ 2006-11-02 11:04 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: hanwen, git
In-Reply-To: <45494D84.2060402@shadowen.org>
Dear diary, on Thu, Nov 02, 2006 at 02:44:36AM CET, I got a letter
where Andy Whitcroft <apw@shadowen.org> said that...
> Han-Wen Nienhuys wrote:
> >
> > Hi,
> >
> > the git source seems full of calls similar to
> >
> > strncmp (x, "constant string", 15)
> >
> > is there a reason not to use something like
> >
> > int
> > strxmp (char const *x, char const *y)
> > {
> > return strncmp (x, y, strlen (y));
> > }
> >
> > everywhere?
>
> If you are doing these a _lot_ then there is a significant additional
> cost to using strlen on a constant string.
>
> That said if you know its constant you can also use sizeof("foo") and
> that is done at compile time. Something like:
>
> #define strxcmp(x, y) strncmp((x), (y), sizeof((y))
At least in the #define, reasonable compilers should optimize out
strlen("foo"). Hopefully as well if you would make strxmp() inlinable
though I'm not so sure there.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: how to pass ssh options to git?
From: Dennis Stosberg @ 2006-11-02 11:06 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Matthieu Moy, git
In-Reply-To: <20061102093153.GF7468@mellanox.co.il>
Michael S. Tsirkin wrote:
> I know, problem is I want to use different options at different times.
> I could use -F configfile ssh option, but how to pass *that* to git?
You can set the path of the ssh executable to use with the GIT_SSH
environment variable. Create a shell script like
#!/bin/sh
exec ssh --your-options-- $*
and make GIT_SSH point to it.
Regards,
^ permalink raw reply
* [PATCH 1/4] Remove uneccessarily similar printf() from print_ref_list()
From: Andy Parkins @ 2006-11-02 11:10 UTC (permalink / raw)
To: git
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index e028a53..368b68e 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -103,6 +103,7 @@ static int ref_cmp(const void *r1, const
static void print_ref_list(int remote_only)
{
int i;
+ char c;
if (remote_only)
for_each_remote_ref(append_ref, NULL);
@@ -112,10 +113,11 @@ static void print_ref_list(int remote_on
qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
for (i = 0; i < ref_index; i++) {
+ c = ' ';
if (!strcmp(ref_list[i], head))
- printf("* %s\n", ref_list[i]);
- else
- printf(" %s\n", ref_list[i]);
+ c = '*';
+
+ printf("%c %s\n", c, ref_list[i]);
}
}
--
1.4.3.2
^ permalink raw reply related
* [PATCH 2/4] Rename remote_only to display_mode
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 368b68e..85b7007 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -100,12 +100,12 @@ static int ref_cmp(const void *r1, const
return strcmp(*(char **)r1, *(char **)r2);
}
-static void print_ref_list(int remote_only)
+static void print_ref_list(int display_mode)
{
int i;
char c;
- if (remote_only)
+ if (display_mode)
for_each_remote_ref(append_ref, NULL);
else
for_each_branch_ref(append_ref, NULL);
@@ -160,7 +160,7 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, remote_only = 0;
+ int delete = 0, force_delete = 0, force_create = 0, display_mode = 0;
int reflog = 0;
int i;
@@ -189,7 +189,7 @@ int cmd_branch(int argc, const char **ar
continue;
}
if (!strcmp(arg, "-r")) {
- remote_only = 1;
+ display_mode = 1;
continue;
}
if (!strcmp(arg, "-l")) {
@@ -209,7 +209,7 @@ int cmd_branch(int argc, const char **ar
if (delete)
delete_branches(argc - i, argv + i, force_delete);
else if (i == argc)
- print_ref_list(remote_only);
+ print_ref_list(display_mode);
else if (i == argc - 1)
create_branch(argv[i], head, force_create, reflog);
else if (i == argc - 2)
--
1.4.3.2
^ permalink raw reply related
* [PATCH 3/4] Default to displaying /all/ non-tag refs, not just locals
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
Adds support for display_mode == 2; which shows all non-tag refs. I've set
display_mode = 2 by default so it's easily reverted if needed - or if a switch
for the old mode is wanted it can be easily added
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 32 +++++++++++++++++++++++++-------
1 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 85b7007..b88413a 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -104,20 +104,38 @@ static void print_ref_list(int display_m
{
int i;
char c;
+ char *p;
- if (display_mode)
- for_each_remote_ref(append_ref, NULL);
- else
- for_each_branch_ref(append_ref, NULL);
+ switch (display_mode) {
+ case 0:
+ for_each_branch_ref(append_ref, NULL);
+ break;
+ case 1:
+ for_each_remote_ref(append_ref, NULL);
+ break;
+ case 2:
+ for_each_ref(append_ref, NULL);
+ break;
+ }
qsort(ref_list, ref_index, sizeof(char *), ref_cmp);
for (i = 0; i < ref_index; i++) {
+ p = ref_list[i];
+ if (display_mode == 2) {
+ if (!strncmp( p, "refs/", 5 ))
+ p += 5;
+ if (!strncmp( p, "tags/", 5 ))
+ continue;
+ if (!strncmp( p, "heads/", 6 ))
+ p += 6;
+ }
+
c = ' ';
- if (!strcmp(ref_list[i], head))
+ if (!strcmp(p, head))
c = '*';
- printf("%c %s\n", c, ref_list[i]);
+ printf("%c %s\n", c, p);
}
}
@@ -160,7 +178,7 @@ static void create_branch(const char *na
int cmd_branch(int argc, const char **argv, const char *prefix)
{
- int delete = 0, force_delete = 0, force_create = 0, display_mode = 0;
+ int delete = 0, force_delete = 0, force_create = 0, display_mode = 2;
int reflog = 0;
int i;
--
1.4.3.2
^ permalink raw reply related
* [PATCH 4/4] Show the branch type after the branch name for remotes
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
In-Reply-To: <bec6ab7849e3fcacac23cca44a0ba93282af5fca.1162465753.git.andyparkins@gmail.com>
Instead of prefixing the remote branches with "remotes/" suffix them with
"[read only]"
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-branch.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index b88413a..6736882 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -105,6 +105,7 @@ static void print_ref_list(int display_m
int i;
char c;
char *p;
+ const char *suffix;
switch (display_mode) {
case 0:
@@ -122,6 +123,7 @@ static void print_ref_list(int display_m
for (i = 0; i < ref_index; i++) {
p = ref_list[i];
+ suffix = "";
if (display_mode == 2) {
if (!strncmp( p, "refs/", 5 ))
p += 5;
@@ -129,13 +131,17 @@ static void print_ref_list(int display_m
continue;
if (!strncmp( p, "heads/", 6 ))
p += 6;
+ if (!strncmp( p, "remotes/", 8 )) {
+ suffix = " [read only]";
+ p += 8;
+ }
}
c = ' ';
if (!strcmp(p, head))
c = '*';
- printf("%c %s\n", c, p);
+ printf("%c %s%s\n", c, p, suffix);
}
}
--
1.4.3.2
^ permalink raw reply related
* [PATCH] git-clone documentation didn't mention --origin as equivalent of -o
From: Andy Parkins @ 2006-11-02 11:11 UTC (permalink / raw)
To: git
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-clone.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f973c64..e22a036 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -75,6 +75,7 @@ OPTIONS
this option is used, neither the `origin` branch nor the
default `remotes/origin` file is created.
+--origin::
-o <name>::
Instead of using the branch name 'origin' to keep track
of the upstream repository, use <name> instead. Note
--
1.4.3.2
^ permalink raw reply related
* [PATCH] Improve git-prune -n output
From: Andy Parkins @ 2006-11-02 11:12 UTC (permalink / raw)
To: git
prune_object() in show_only mode would previously just show the path to the
object that would be deleted. The path the object is stored in shouldn't be
shown to users, they only know about sha1 identifiers so show that instead.
Further, the sha1 alone isn't that useful for examining what is going to be
deleted. This patch also adds the object type to the output, which makes it
easy to pick out, say, the commits and use git-show to display them.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
builtin-prune.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/builtin-prune.c b/builtin-prune.c
index d853902..286a94c 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -16,8 +16,14 @@ static struct rev_info revs;
static int prune_object(char *path, const char *filename, const unsigned char *sha1)
{
+ char buf[20];
+ const char *type;
+
if (show_only) {
- printf("would prune %s/%s\n", path, filename);
+ type = buf;
+ if (sha1_object_info(sha1, type, NULL))
+ type = "unknown";
+ printf("%s %s\n", sha1_to_hex(sha1), type );
return 0;
}
unlink(mkpath("%s/%s", path, filename));
--
1.4.3.2
^ permalink raw reply related
* Re: Suggestion: drop 'g' in git-describe suffix
From: Santi Béjar @ 2006-11-02 11:12 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <4549CE2A.3010808@xs4all.nl>
On 11/2/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
> Andy Whitcroft escreveu:
> > Han-Wen Nienhuys wrote:
> >>
> >> tag+sha1
> >>
> >> to separate the tag and the committish.
> >
> > Well there is a non-alphabet character in there, a minus (-). The g
> > prefix on the sha1 _fragment_ it to indicate that it is in fact a
> > truncated sha1, not a complete one.
I think it is there to indicate it is a git commit sha1.
>
> is this policy documented somewhere? None of the tools understand it.
>
> [lilydev@haring git]$ git describe
> v1.4.3.3-g1e1f76e
> [lilydev@haring git]$ git show g1e1f76e
> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in
> the working tree.
> Use '--' to separate paths from revisions
>
Use the complete output of describe:
$ git show v1.4.3.3-g1e1f76e
or the abbrev sha1:
$ git show 1e1f76e
> My suggestion is to use
>
> v1.4.3.3+1e1f76e
My suggestion is to use:
v1.4.3.3-git1e1f76e
to make clear that it is a git revision version.
One problem I see with this scheme (either 'g', 'git' of '+') is that
it does not provide an increasing version number, even for
fast-forwarding commits. Then it is not useful as a package version
number (deb or rpm). I've already seen deb packages with
version+git20061010. One possibility could be to add the number of
commits between the tag and the commit as:
v1.4.3.3-git12g1e1f76e
to provide a weak ordering for fast-forwarding commits. What do you thing?
^ permalink raw reply
* [PATCH] Minor grammar fixes for git-diff-index.txt
From: Andy Parkins @ 2006-11-02 11:12 UTC (permalink / raw)
To: git
"what you are going to commit is" doesn't need the "is" and does need a comma.
"can trivially see" is an unecessary split infinitive and "easily" is a more
appropriate adverb.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-diff-index.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-diff-index.txt b/Documentation/git-diff-index.txt
index 9cd43f1..2df581c 100644
--- a/Documentation/git-diff-index.txt
+++ b/Documentation/git-diff-index.txt
@@ -54,7 +54,7 @@ If '--cached' is specified, it allows yo
For example, let's say that you have worked on your working directory, updated
some files in the index and are ready to commit. You want to see exactly
-*what* you are going to commit is without having to write a new tree
+*what* you are going to commit, without having to write a new tree
object and compare it that way, and to do that, you just do
git-diff-index --cached HEAD
@@ -68,7 +68,7 @@ matches my working directory. But doing
-100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 commit.c
+100644 blob 4161aecc6700a2eb579e842af0b7f22b98443f74 git-commit.c
-You can trivially see that the above is a rename.
+You can see easily that the above is a rename.
In fact, "git-diff-index --cached" *should* always be entirely equivalent to
actually doing a "git-write-tree" and comparing that. Except this one is much
--
1.4.3.2
^ permalink raw reply related
* [PATCH] Added description for reversing git-update-index using --index-info
From: Andy Parkins @ 2006-11-02 11:13 UTC (permalink / raw)
To: git
I wanted to restore a single file from HEAD back to the index; Shawn Pearce
gave me the answer. git-ls-tree piped to git-update-index --index-info.
This patch adds that answer to the git-update-index documentation.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
Documentation/git-update-index.txt | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index 41bb7e1..5adf717 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -215,6 +215,24 @@ for that path. After the above, we woul
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
------------
+One particular use of --index-info is to reverse the effect of
+"git-update-index frotz":
+
+------------
+git ls-tree HEAD frotz | git update-index --index-info
+------------
+
+This makes the index hold the file frotz from HEAD rather than from the
+working copy. Similarly:
+
+------------
+git ls-tree -r HEAD | git update-index --index-info
+------------
+
+Will undo everything except "git add" from the index, as
+"git-ls-tree -r" lists everything in the last commit.
+
+
Using "assume unchanged" bit
----------------------------
--
1.4.3.2
^ permalink raw reply related
* Re: Suggestion: drop 'g' in git-describe suffix
From: Andy Whitcroft @ 2006-11-02 11:12 UTC (permalink / raw)
To: hanwen; +Cc: Git Mailing List
In-Reply-To: <4549CE2A.3010808@xs4all.nl>
Han-Wen Nienhuys wrote:
> Andy Whitcroft escreveu:
>> Han-Wen Nienhuys wrote:
>>> Andy Whitcroft escreveu:
>>>>> or some other non-hex character.
>>>> g is not a hex digit, hex is 0-f ??
>>>>
>>> Yes of course; silly me. Still I think it would be clearer if it used a
>>> non-alphabet char, eg.
>>>
>>> tag+sha1
>>>
>>> to separate the tag and the committish.
>>
>> Well there is a non-alphabet character in there, a minus (-). The g
>> prefix on the sha1 _fragment_ it to indicate that it is in fact a
>> truncated sha1, not a complete one.
>
> is this policy documented somewhere? None of the tools understand it.
>
> [lilydev@haring git]$ git describe
> v1.4.3.3-g1e1f76e
> [lilydev@haring git]$ git show g1e1f76e
> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in
> the working tree.
> Use '--' to separate paths from revisions
>
> My suggestion is to use
>
> v1.4.3.3+1e1f76e
>
> here.
The 'whole' thing is valid as an object reference:
apw@pinky$ git describe
v1.4.3.3-g8cf249b
apw@pinky$ git show v1.4.3.3-g8cf249b
commit 8cf249b755c257ea19100b888ac612e601cdf96b
Merge: 15c3ffb... fa438a2...
[...]
^ permalink raw reply
* [PATCH] pack-refs: Store the full name of the ref even when packing only tags.
From: Alexandre Julliard @ 2006-11-02 11:13 UTC (permalink / raw)
To: git
Using for_each_tag_ref() to enumerate tags is wrong since it removes
the refs/tags/ prefix, we need to always use for_each_ref() and filter
out non-tag references in the callback.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
builtin-pack-refs.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/builtin-pack-refs.c b/builtin-pack-refs.c
index 1087657..042d271 100644
--- a/builtin-pack-refs.c
+++ b/builtin-pack-refs.c
@@ -12,6 +12,7 @@ struct ref_to_prune {
struct pack_refs_cb_data {
int prune;
+ int all;
struct ref_to_prune *ref_to_prune;
FILE *refs_file;
};
@@ -29,6 +30,8 @@ static int handle_one_ref(const char *pa
{
struct pack_refs_cb_data *cb = cb_data;
+ if (!cb->all && strncmp(path, "refs/tags/", 10))
+ return 0;
/* Do not pack the symbolic refs */
if (!(flags & REF_ISSYMREF))
fprintf(cb->refs_file, "%s %s\n", sha1_to_hex(sha1), path);
@@ -68,7 +71,6 @@ int cmd_pack_refs(int argc, const char *
{
int fd, i;
struct pack_refs_cb_data cbdata;
- int (*iterate_ref)(each_ref_fn, void *) = for_each_tag_ref;
memset(&cbdata, 0, sizeof(cbdata));
@@ -79,7 +81,7 @@ int cmd_pack_refs(int argc, const char *
continue;
}
if (!strcmp(arg, "--all")) {
- iterate_ref = for_each_ref;
+ cbdata.all = 1;
continue;
}
/* perhaps other parameters later... */
@@ -93,7 +95,7 @@ int cmd_pack_refs(int argc, const char *
if (!cbdata.refs_file)
die("unable to create ref-pack file structure (%s)",
strerror(errno));
- iterate_ref(handle_one_ref, &cbdata);
+ for_each_ref(handle_one_ref, &cbdata);
fflush(cbdata.refs_file);
fsync(fd);
fclose(cbdata.refs_file);
--
1.4.3.3.gac1f
--
Alexandre Julliard
^ permalink raw reply related
* Re: Rebasing part of a branch
From: Jakub Narebski @ 2006-11-02 11:15 UTC (permalink / raw)
To: git
In-Reply-To: <200611021045.25423.andyparkins@gmail.com>
Andy Parkins wrote:
> Hello,
>
> Is there a way to rebase part of a branch? For example
>
> H---I---J topicB
> /
> E---F---G topicA
> /
> A---B---C---D master
>
> And I want:
>
> H---I---J topicB
> /
> | E---F---G topicA
> |/
> A---B---C---D master
We have
git-rebase [--merge] [--onto <newbase>] <upstream> [<branch>]
Try then
$ git rebase --onto master topicA topicB
(if you checked out topicB, you don't need last topicB in git-rebase).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to pass ssh options to git?
From: Nicolas Vilz 'niv' @ 2006-11-02 11:18 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Matthieu Moy, git
In-Reply-To: <20061102093153.GF7468@mellanox.co.il>
Michael S. Tsirkin wrote:
> Quoting r. Matthieu Moy <Matthieu.Moy@imag.fr>:
>> Subject: Re: how to pass ssh options to git?
>>
>> "Michael S. Tsirkin" <mst@mellanox.co.il> writes:
>>
>>> How is it possible to pass ssh options to git?
>>> for example, I use these options to log into some machine:
>>> ssh -i <private> -o HostKeyAlias=<alias> -p <port> -l <user> <address>
>> Not answering the question, but this can go to ~/.ssh/config :
>>
>> Host *.domain.net
>> User some_user
>> IdentityFile ~/.ssh/foobar
>>
>
> I know, problem is I want to use different options at different times.
> I could use -F configfile ssh option, but how to pass *that* to git?
you can setup different host-entries as kind of virtual hosts in your
hosts-section. that is what i do
host blah1.domain.net
hostname www.domain.net
user blah1
IdentityFile .ssh/blah
Port 523434
host blah2.domain.net
hostname www.domain.net
user blah1
IdentityFile .ssh/blah
Port 22
The first host-section i use in an environment, where i cannot get
through port 22.
Sincerly
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Andy Whitcroft @ 2006-11-02 11:21 UTC (permalink / raw)
To: Santi Béjar; +Cc: hanwen, git
In-Reply-To: <8aa486160611020312v42047716t6a13e6fa16eeae8@mail.gmail.com>
Santi Béjar wrote:
> On 11/2/06, Han-Wen Nienhuys <hanwen@xs4all.nl> wrote:
>> Andy Whitcroft escreveu:
>> > Han-Wen Nienhuys wrote:
>> >>
>> >> tag+sha1
>> >>
>> >> to separate the tag and the committish.
>> >
>> > Well there is a non-alphabet character in there, a minus (-). The g
>> > prefix on the sha1 _fragment_ it to indicate that it is in fact a
>> > truncated sha1, not a complete one.
>
> I think it is there to indicate it is a git commit sha1.
>
>>
>> is this policy documented somewhere? None of the tools understand it.
>>
>> [lilydev@haring git]$ git describe
>> v1.4.3.3-g1e1f76e
>> [lilydev@haring git]$ git show g1e1f76e
>> fatal: ambiguous argument 'g1e1f76e': unknown revision or path not in
>> the working tree.
>> Use '--' to separate paths from revisions
>>
>
> Use the complete output of describe:
> $ git show v1.4.3.3-g1e1f76e
>
> or the abbrev sha1:
> $ git show 1e1f76e
>
>> My suggestion is to use
>>
>> v1.4.3.3+1e1f76e
>
> My suggestion is to use:
>
> v1.4.3.3-git1e1f76e
>
> to make clear that it is a git revision version.
>
> One problem I see with this scheme (either 'g', 'git' of '+') is that
> it does not provide an increasing version number, even for
> fast-forwarding commits. Then it is not useful as a package version
> number (deb or rpm). I've already seen deb packages with
> version+git20061010. One possibility could be to add the number of
> commits between the tag and the commit as:
>
> v1.4.3.3-git12g1e1f76e
>
> to provide a weak ordering for fast-forwarding commits. What do you thing?
I think you'll restart the 1.2.3.4 versioning is better 'debate' again!
Surly if things are being pushed into a .deb or .rpm we should be using
a real release version. We should be tagging that. If the project is
not providing release number, there is nothing stopping you from tagging
them yourself in your copy of the repository and using your tag. you
could use like 'unofficial-N' where N increments in the way you want.
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Han-Wen Nienhuys @ 2006-11-02 11:23 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8aa486160611020312v42047716t6a13e6fa16eeae8@mail.gmail.com>
Santi Béjar escreveu:
> One problem I see with this scheme (either 'g', 'git' of '+') is that
> it does not provide an increasing version number, even for
> fast-forwarding commits. Then it is not useful as a package version
> number (deb or rpm). I've already seen deb packages with
> version+git20061010. One possibility could be to add the number of
> commits between the tag and the commit as:
>
> v1.4.3.3-git12g1e1f76e
>
> to provide a weak ordering for fast-forwarding commits. What do you thing?
Is that number well defined if you merge branches in between?
I'd prefer
v1.4.3.3+git-12-1e1f76e
or similar. Pasting together words without separator is bad for readability.
--
^ permalink raw reply
* Re: [PATCH] Bash snippet to show branch and patch in bash prompt
From: Catalin Marinas @ 2006-11-02 11:24 UTC (permalink / raw)
To: Eran Tromer; +Cc: Robin Rosenberg, git
In-Reply-To: <45461429.4020108@tromer.org>
Eran Tromer <git2eran@tromer.org> wrote:
> Corresponding modified version:
Thanks for your comments. I included them in the patch.
--
^ permalink raw reply
* Re: how to pass ssh options to git?
From: Michael S. Tsirkin @ 2006-11-02 11:27 UTC (permalink / raw)
To: Dennis Stosberg; +Cc: Matthieu Moy, git
In-Reply-To: <20061102110639.G523a966f@leonov.stosberg.net>
Quoting r. Dennis Stosberg <dennis@stosberg.net>:
> Subject: Re: how to pass ssh options to git?
>
> Michael S. Tsirkin wrote:
>
> > I know, problem is I want to use different options at different times.
> > I could use -F configfile ssh option, but how to pass *that* to git?
>
> You can set the path of the ssh executable to use with the GIT_SSH
> environment variable. Create a shell script like
>
> #!/bin/sh
> exec ssh --your-options-- $*
>
> and make GIT_SSH point to it.
Thanks, I'll try that.
BTW, just grep for GIT_SSH gets me some more:
GIT_SSH_UPLOAD, GIT_SSH_PUSH, GIT_SSH_PULL, GIT_SSH_FETCH.
None of which appear to be documented.
--
^ permalink raw reply
* Re: [PATCH] Allow hand-editing of patches before sending
From: Karl Hasselström @ 2006-11-02 11:36 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0611020232x1e343bbco9451c8183c84d68@mail.gmail.com>
On 2006-11-02 10:32:46 +0000, Catalin Marinas wrote:
> On 01/11/06, Karl Hasselström <kha@treskal.com> wrote:
>
> > This adds a new flag to 'stg mail', allowing the user to hand-edit
> > each patch e-mail before it is sent, just like it is currently
> > possible to edit the cover message.
>
> Applied it but with some conflicts since you have some other patches
> which I haven't merged yet (like QP encoding). I'll try to have a
> look at this QP encoding this week. The main problem is that Gnus
> shows plenty of "=20" instead of new lines and 'stg import' cannot
> cope with them.
That Gnus shows =20 suggests that I haven't got the QP encoding 100%
right. I haven't had time to look at that yet, and it looks like you
may beat me to it.
--
Karl Hasselström, kha@treskal.com
^ permalink raw reply
* Re: Minor documentation problems
From: Petr Baudis @ 2006-11-02 11:41 UTC (permalink / raw)
To: git; +Cc: jnareb
In-Reply-To: <vpqmz7a1694.fsf@ecrins.imag.fr>
Hi,
Dear diary, on Thu, Nov 02, 2006 at 11:40:23AM CET, I got a letter
where Matthieu Moy <Matthieu.Moy@imag.fr> said that...
> I found minor problems with the doc, which deserve to be fixed:
>
> * http://www.kernel.org/pub/software/scm/cogito/docs/cg-commit.1.html
> Mentions .git/config, but not ~/.gitconfig (which is indeed _the_
> place where I think most people want to set their name and email).
thanks for pointing this out, further releases will mention both.
> Side note: it can be interesting to have a command to do this.
> For example, bzr has "bzr whoami 'me <myself@myisp.com>'", which
> avoids having to learn the config file syntax.
Yes, you are certainly not the first to wish this, I'm seriously
thinking about introducing cg-admin-config for setting the most common
configuration variables.
Moreover, I'm more and more thinking about removing the fallback on
guessing based on /etc/passwd and hostname. _Many_ people were and will
be burnt by it, and I think it's more sane to require the user to
confirm once what the valid credentials are (at _that_ point it's ok to
guess, but the user has to confirm it) than let them unconsciously do
200 commits with completely bogus author lines.
What do the Git people think? Perhaps we could introduce GIT_NO_GUESS
environment variable which will prevent var.c from guessing?
> * RSS link on the wiki:
> The URL
> http://git.or.cz/gitwiki/RecentChanges?action=rss_rc&ddiffs=1&unique=1
> seems to be working as an RSS feed for changes, but it's not linked
> to by http://git.or.cz/gitwiki/RecentChanges. Usually, there's an
> RSS icon, and an HTML <link rel="alternate" ...> to help finding it.
Fixed, thanks.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
^ permalink raw reply
* Re: git and "dumb protocols"
From: Matthieu Moy @ 2006-11-02 12:04 UTC (permalink / raw)
To: git
In-Reply-To: <20061102104848.GH20017@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> yes, you can push using HTTP DAV - just push to an HTTP URL; make sure
> you have git-http-push compiled, it is sometimes not compiled because it
> unfortunately adds dependencies on couple of more libraries.
That's great. I don't need this right now, but having worked behind a
firewall + proxy, I know how appreciable it is to push with DAV ;-).
> I think a patch that would add support for pushing over sftp or some
> other dumb protocol would be welcome. One problem is with proper locking
> of ref updates (not sure how well would sftp cope with that), another is
> that you will need to do git-update-server-info's job on the server
> side.
It should be possible (but not implemented AAUI) also to generate the
additional info of git-update-server-info on the client, isn't it?
> If you already have SSH access to the server, why not compile Git
> there and install it to your $HOME, though?
I'll probably do, but my concern is broader than that. I like the
ability to use almost any webhosting service for my revision control.
GNU Arch was quite good at that, bzr is also (doesn't support webdav
very well yet, but read-only-HTTP, sftp and ftp are there), so I'd
like git to do the same.
And yes, there are tons of reasons not to install git on the server.
In particular, the fact that I'm not root there, and too lazy to do
more than "aptitude install git" with pleasure ;-).
--
^ 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