* [PATCH] Fix gcc-4 warning in accept() call
From: Pavel Roskin @ 2005-09-29 21:05 UTC (permalink / raw)
To: git
Fix gcc-4 warning in accept() call
gcc-4 warns about sign mismatch in pointers. Third argument in accept()
is socklen_t, which is unsigned. Since Linus doesn't like socklen_t
(see commit 7fa090844f7d1624c7d1ffc621aae6aec84a1110), let's use
unsigned int.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -459,7 +459,7 @@ static int serve(int port)
if (FD_ISSET(sockfd, &fds)) {
struct sockaddr_storage ss;
- int sslen = sizeof(ss);
+ unsigned int sslen = sizeof(ss);
int incoming = accept(sockfd, (struct sockaddr *)&ss, &sslen);
if (incoming < 0) {
switch (errno) {
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Junio C Hamano @ 2005-09-29 21:04 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <433C4B6D.6030701@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> Nope. It intentionally includes the manual rsync because clone/pull
> doesn't seem to grab tags. Or at least last time I checked...
clone does (or should), fetch (and hence pull) does not
automatically. Running the following one-liner every once in a
while would sync your set of tags with Linus:
git fetch origin `git-ls-remote --tags origin | sed -ne 's|^.*refs/tags/|tag |p'`
^ permalink raw reply
* [PATCH] Make logerror() and loginfo() static
From: Pavel Roskin @ 2005-09-29 20:53 UTC (permalink / raw)
To: git
Make logerror() and loginfo() static
logerror() and loginfo() in daemon.c are never declared and never called
from other files, therefore they should be declared static. Found by
sparse.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/daemon.c b/daemon.c
--- a/daemon.c
+++ b/daemon.c
@@ -57,7 +57,7 @@ static void logreport(int priority, cons
write(2, buf, buflen);
}
-void logerror(const char *err, ...)
+static void logerror(const char *err, ...)
{
va_list params;
va_start(params, err);
@@ -65,7 +65,7 @@ void logerror(const char *err, ...)
va_end(params);
}
-void loginfo(const char *err, ...)
+static void loginfo(const char *err, ...)
{
va_list params;
if (!verbose)
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Support SPARSE in Makefile, better SPARSE_FLAGS
From: Pavel Roskin @ 2005-09-29 20:46 UTC (permalink / raw)
To: git
Support SPARSE in Makefile, better SPARSE_FLAGS
This patch makes it possible to use some other program instead of sparse
(e.g. a wrapper around sparse). It also provides a better default for
SPARSE_FLAGS. __BIG_ENDIAN__ should not be needed.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -66,8 +66,9 @@ INSTALL = install
RPMBUILD = rpmbuild
# sparse is architecture-neutral, which means that we need to tell it
-# explicitly what architecture to check for. Fix this up for yours..
-SPARSE_FLAGS = -D__BIG_ENDIAN__ -D__powerpc__
+# explicitly what architecture to check for.
+SPARSE = sparse
+SPARSE_FLAGS = -D__$(shell uname -i)__
@@ -335,7 +336,7 @@ test-delta: test-delta.c diff-delta.o pa
$(CC) $(ALL_CFLAGS) -o $@ $^
check:
- for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
+ for i in *.c; do $(SPARSE) $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Jeff Garzik @ 2005-09-29 20:15 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <20050929200252.GA31516@redhat.com>
Dave Jones wrote:
> You wrote..
>
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ rsync -a --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
> .git/
>
> Could be just..
>
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ git pull
>
> Likewise, in the next section, git pull doesn't need an argument
> if pulling from the repo it cloned.
Nope. It intentionally includes the manual rsync because clone/pull
doesn't seem to grab tags. Or at least last time I checked...
Jeff
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Dave Jones @ 2005-09-29 20:11 UTC (permalink / raw)
To: Anton Altaparmakov; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <Pine.LNX.4.60.0509292106080.17860@hermes-1.csi.cam.ac.uk>
On Thu, Sep 29, 2005 at 09:07:29PM +0100, Anton Altaparmakov wrote:
> > $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> > $ cd linux-2.6
> > $ rsync -a --verbose --stats --progress \
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
> > .git/
> >
> > Could be just..
> >
> > $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> > $ cd linux-2.6
> > $ git pull
>
> That is not actually the same. "git pull" for example will not download
> Linus' tags whilst the rsync would get everything.
Ah. I didn't know this. Thanks.
Hmm, it'd be nice to have a shorthand 'not have to type the url, pull everything'.
Something like 'git pull all'.
Dave
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Anton Altaparmakov @ 2005-09-29 20:07 UTC (permalink / raw)
To: Dave Jones; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <20050929200252.GA31516@redhat.com>
On Thu, 29 Sep 2005, Dave Jones wrote:
> On Thu, Sep 29, 2005 at 07:03:05AM -0400, Jeff Garzik wrote:
> > Just updated my KHGtG to include the latest goodies available in
> > git-core, the Linux kernel standard SCM tool:
> >
> > http://linux.yyz.us/git-howto.html
> >
> > Several changes in git-core have made working with git a lot easier, so
> > be sure to re-familiarize yourself with the development process.
> >
> > Comments, corrections, and notes of omission welcome. This document
> > mainly reflects my typical day-to-day git activities, and may not be
> > very applicable outside of kernel work.
>
> You wrote..
>
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ rsync -a --verbose --stats --progress \
> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
> .git/
>
> Could be just..
>
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ git pull
That is not actually the same. "git pull" for example will not download
Linus' tags whilst the rsync would get everything.
> Likewise, in the next section, git pull doesn't need an argument
> if pulling from the repo it cloned.
Now that is definitely correct. (-:
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Dave Jones @ 2005-09-29 20:02 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <433BC9E9.6050907@pobox.com>
On Thu, Sep 29, 2005 at 07:03:05AM -0400, Jeff Garzik wrote:
>
> Just updated my KHGtG to include the latest goodies available in
> git-core, the Linux kernel standard SCM tool:
>
> http://linux.yyz.us/git-howto.html
>
> Several changes in git-core have made working with git a lot easier, so
> be sure to re-familiarize yourself with the development process.
>
> Comments, corrections, and notes of omission welcome. This document
> mainly reflects my typical day-to-day git activities, and may not be
> very applicable outside of kernel work.
You wrote..
$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ rsync -a --verbose --stats --progress \
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
.git/
Could be just..
$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ git pull
Likewise, in the next section, git pull doesn't need an argument
if pulling from the repo it cloned.
Dave
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Oliver Neukum @ 2005-09-29 19:38 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <1128022473.14595.6.camel@cashmere.sps.mot.com>
Am Donnerstag, 29. September 2005 21:34 schrieb Jon Loeliger:
> On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
>
> > Unfortunately, following the instructions to the letter produces this:
> > oliver@oenone:~/linux-2.6> git checkout
> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
>
> Yeah. See if you still have a .git/HEADS that symlinks
> to a valid place or not...?
oliver@oenone:~/linux-2.6> ls -la .git/
insgesamt 14
drwxrwxr-x 6 oliver users 224 2005-09-29 21:06 .
drwxr-xr-x 3 oliver users 72 2005-09-29 20:45 ..
-rw-rw-r-- 1 oliver users 19 2005-05-02 01:02 description
lrwxrwxrwx 1 oliver users 17 2005-09-29 21:06 HEAD -> refs/heads/master
-rw------- 1 oliver users 32 2005-09-29 21:06 index
drwxrwxr-x 2 oliver users 104 2005-09-11 21:41 info
drwxr-xr-x 260 oliver users 6240 2005-09-29 19:05 objects
drwxrwxr-x 4 oliver users 96 2005-05-02 02:15 refs
drwxr-xr-x 2 oliver users 72 2005-09-29 21:05 remotes
oliver@oenone:~/linux-2.6> ls -la .git/refs/
insgesamt 1
drwxrwxr-x 4 oliver users 96 2005-05-02 02:15 .
drwxrwxr-x 6 oliver users 224 2005-09-29 21:06 ..
drwxrwxr-x 2 oliver users 72 2005-09-29 19:05 heads
drwxrwxr-x 2 oliver users 600 2005-09-20 05:02 tags
oliver@oenone:~/linux-2.6> ls -la .git/refs/heads/
insgesamt 4
drwxrwxr-x 2 oliver users 72 2005-09-29 19:05 .
drwxrwxr-x 4 oliver users 96 2005-05-02 02:15 ..
-rw-rw-r-- 1 oliver users 41 2005-09-29 19:05 master
oliver@oenone:~/linux-2.6> cat .git/refs/heads/master
aa55a08687059aa169d10a313c41f238c2070488
Regards
Oliver
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Jon Loeliger @ 2005-09-29 19:34 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <200509292108.11092.oliver@neukum.org>
On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
> Unfortunately, following the instructions to the letter produces this:
> oliver@oenone:~/linux-2.6> git checkout
> usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
Yeah. See if you still have a .git/HEADS that symlinks
to a valid place or not...?
jdl
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Johannes Schindelin @ 2005-09-29 19:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0509292058020.8413@wgmdd8.biozentrum.uni-wuerzburg.de>
Hi,
On Thu, 29 Sep 2005, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
>
> > On Thu, 29 Sep 2005, Johannes Schindelin wrote:
> > >
> > > With this patch, instead of blindly asking for every remote ref,
> > > fetch-pack first looks in the local repository if that ref is
> > > already there.
> >
> > No. This is WRONG.
Following up on the "I'd rather download twice than have a corrupt
repository":
Wouldn't it make much more sense to add a flag which repairs an incomplete
fetch? After all, not every day you fsck up a fetch, right? So, be nice to
the server, the network and all the rest, in most cases, and be not so
nice if you know something went wrong and you want to fix it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Johannes Schindelin @ 2005-09-29 19:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0509291120170.3308@g5.osdl.org>
Hi,
On Thu, 29 Sep 2005, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Johannes Schindelin wrote:
> >
> > With this patch, instead of blindly asking for every remote ref, fetch-pack
> > first looks in the local repository if that ref is already there.
>
> No. This is WRONG.
Actually, this is not wrong. The patch is wrong. Here's why:
> The "fetch" semantics are simple: we only write out new refs _after_ we've
> fetched all the objects that point to them. That means that while we
> cannot trust a "oh, I already have this commit, let's skip it", we _can_
> trust "oh, I already have these refs, let's skip them".
What the commit message should suggest was: if a local ref is identical to
the remote ref, do not "want" it. But of course, I got it all wrong. BTW
this patch is not to annoy you, but to ease the burden on the server for
git-daemon. (Many a developer begins the day by fetching the latest and
greatest).
The correct way to go about it would be to check that
$(git-rev-list <remote_ref> $(git-rev-parse --all | sed "s/^/^/"))
is empty. However, I am lazy, and in most cases, it is sufficient to check
if the remote ref is identical to a local ref. So here goes another try:
[PATCH] fetch-pack should not ask for a ref which is already there
With this patch, instead of blindly asking for every remote ref, fetch-pack
first looks in the local repository if that ref is already a local ref.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
fetch-pack.c | 72 ++++++++++++++++++++++++++++++++++++++++++----------------
1 files changed, 52 insertions(+), 20 deletions(-)
edfbae3927434270c35dfcad417e7d202e509e90
diff --git a/fetch-pack.c b/fetch-pack.c
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -9,6 +9,22 @@ static const char fetch_pack_usage[] =
"git-fetch-pack [-q] [-v] [--exec=upload-pack] [host:]directory <refs>...";
static const char *exec = "git-upload-pack";
+static int has_ref_flag;
+static const unsigned char *has_ref_sha1;
+
+static int has_ref_helper(const char *path, const unsigned char *sha1) {
+ if(!memcmp(sha1, has_ref_sha1, 20))
+ has_ref_flag = 1;
+ return has_ref_flag;
+}
+
+static int has_ref(const unsigned char *sha1) {
+ has_ref_sha1 = sha1;
+ has_ref_flag = 0;
+ for_each_ref(has_ref_helper);
+ return has_ref_flag;
+}
+
static int find_common(int fd[2], unsigned char *result_sha1,
struct ref *refs)
{
@@ -16,20 +32,27 @@ static int find_common(int fd[2], unsign
int count = 0, flushes = 0, retval;
FILE *revs;
- revs = popen("git-rev-list $(git-rev-parse --all)", "r");
- if (!revs)
- die("unable to run 'git-rev-list'");
-
while (refs) {
unsigned char *remote = refs->old_sha1;
- if (verbose)
- fprintf(stderr,
- "want %s (%s)\n", sha1_to_hex(remote),
- refs->name);
- packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ if(!has_ref(remote)) {
+ if (verbose)
+ fprintf(stderr,
+ "want %s (%s)\n", sha1_to_hex(remote),
+ refs->name);
+ packet_write(fd[1], "want %s\n", sha1_to_hex(remote));
+ count++;
+ }
refs = refs->next;
}
packet_flush(fd[1]);
+
+ if(count==0)
+ return 1;
+
+ revs = popen("git-rev-list $(git-rev-parse --all)", "r");
+ if (!revs)
+ die("unable to run 'git-rev-list'");
+
flushes = 1;
retval = -1;
while (fgets(line, sizeof(line), revs) != NULL) {
@@ -74,7 +97,7 @@ static int find_common(int fd[2], unsign
return retval;
}
-static int fetch_pack(int fd[2], int nr_match, char **match)
+static struct ref *fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
unsigned char sha1[20];
@@ -86,7 +109,10 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
- if (find_common(fd, sha1, ref) < 0)
+ status = find_common(fd, sha1, ref);
+ if(status > 0)
+ return ref;
+ if(status < 0)
fprintf(stderr, "warning: no common commits\n");
pid = fork();
if (pid < 0)
@@ -109,12 +135,7 @@ static int fetch_pack(int fd[2], int nr_
int code = WEXITSTATUS(status);
if (code)
die("git-unpack-objects died with error code %d", code);
- while (ref) {
- printf("%s %s\n",
- sha1_to_hex(ref->old_sha1), ref->name);
- ref = ref->next;
- }
- return 0;
+ return ref;
}
if (WIFSIGNALED(status)) {
int sig = WTERMSIG(status);
@@ -125,10 +146,11 @@ static int fetch_pack(int fd[2], int nr_
int main(int argc, char **argv)
{
- int i, ret, nr_heads;
+ int i, nr_heads;
char *dest = NULL, **heads;
int fd[2];
pid_t pid;
+ struct ref *ref;
nr_heads = 0;
heads = NULL;
@@ -160,9 +182,19 @@ int main(int argc, char **argv)
pid = git_connect(fd, dest, exec);
if (pid < 0)
return 1;
- ret = fetch_pack(fd, nr_heads, heads);
+ ref = fetch_pack(fd, nr_heads, heads);
+ if(!ref)
+ return 1;
+
+ while (ref) {
+ printf("%s %s\n",
+ sha1_to_hex(ref->old_sha1), ref->name);
+ ref = ref->next;
+ }
+
close(fd[0]);
close(fd[1]);
finish_connect(pid);
- return ret;
+
+ return 0;
}
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Oliver Neukum @ 2005-09-29 19:08 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <433BC9E9.6050907@pobox.com>
Am Donnerstag, 29. September 2005 13:03 schrieb Jeff Garzik:
>
> Just updated my KHGtG to include the latest goodies available in
> git-core, the Linux kernel standard SCM tool:
>
> http://linux.yyz.us/git-howto.html
>
> Several changes in git-core have made working with git a lot easier, so
> be sure to re-familiarize yourself with the development process.
>
> Comments, corrections, and notes of omission welcome. This document
> mainly reflects my typical day-to-day git activities, and may not be
> very applicable outside of kernel work.
Unfortunately, following the instructions to the letter produces this:
oliver@oenone:~/linux-2.6> git checkout
usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
Regards
Oliver
^ permalink raw reply
* Re: [PATCH] fetch-pack should not ask for a ref which is already there
From: Linus Torvalds @ 2005-09-29 18:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0509290149230.19126@wgmdd8.biozentrum.uni-wuerzburg.de>
On Thu, 29 Sep 2005, Johannes Schindelin wrote:
>
> With this patch, instead of blindly asking for every remote ref, fetch-pack
> first looks in the local repository if that ref is already there.
No. This is WRONG.
It may seem like a sane thing to do, but it is very very horribly broken.
The fact is, if an earlier fetch was interrupted, or if you've used things
like rsync, you may have disconnected objects in your object store. The
fact that you have a particular commit object is _not_ a guarantee that
you have everything that leads up to it.
The "fetch" semantics are simple: we only write out new refs _after_ we've
fetched all the objects that point to them. That means that while we
cannot trust a "oh, I already have this commit, let's skip it", we _can_
trust "oh, I already have these refs, let's skip them".
So please do _not_ add logic like this to git-fetch. I'd _much_ rather
fetch some objects twice than end up with a corrupt repository.
Linus
^ permalink raw reply
* Re: Pull from one branch to another?
From: Tony Luck @ 2005-09-29 17:52 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Git Mailing List
In-Reply-To: <433B84BD.8030003@pobox.com>
On 9/28/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> $ git checkout -f sky2
...
> $ git checkout -f upstream
...
> $ git checkout -f ALL
Those "-f" arguments to git checkout shouldn't be needed, and may
eventually cause a problem. The "-f" option doesn't quite work as
"forcibly" as you might think it does because it ignores the index, and
so doesn't do what you[1] expect with files that exist in the previously
checked out tree, and not in the new tree ... it won't delete them, so
there's a small risk that with the wrong git operation you may
accidentally add them to the new branch.
In the sequence you described a simple "git checkout" should do the
right thing ... and will be faster too.
-Tony
[1] well what *I* expected, and was part of a snafu I made earlier
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-09-29 17:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0509291043580.20717@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 28 Sep 2005, H. Peter Anvin wrote:
>
>>Another funny which I haven't been able to figure out yet is that 'gitk'
>>scrunches all its output up into a few pixels at the top of the window.
>
> See my mail about rootless X11. I went about working around that
> particular Tk bug by specifying the dimensions of the panes explicitely.
> However, I was not especially happy with my workaround, since it did not
> reproduce the layout exactly after a restart. Maybe you can figure it out
> how to do that.
>
It looks like this isn't a rootless *X* thing; it looks like the wish
that is included with Cygwin actually opens native Win32 windows; even
when run from inside a rooted X session it still opens an external
window. I also tried using the wish from the latest ActiveState
distribution; it exhibits the same problem although with slightly
different geometries.
-hpa
^ permalink raw reply
* [PATCH] Old curl does not know about CURLOPT_SSLKEY
From: Johannes Schindelin @ 2005-09-29 16:19 UTC (permalink / raw)
To: git
... so try to set it only in later versions.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
http-fetch.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
d1d3438564c8407b916aa374fbac89a5aa902eb1
diff --git a/http-fetch.c b/http-fetch.c
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -529,9 +529,11 @@ int main(int argc, char **argv)
if ((ssl_cert = getenv("GIT_SSL_CERT")) != NULL) {
curl_easy_setopt(curl, CURLOPT_SSLCERT, ssl_cert);
}
+#if LIBCURL_VERSION_NUM >= 0x070902
if ((ssl_key = getenv("GIT_SSL_KEY")) != NULL) {
curl_easy_setopt(curl, CURLOPT_SSLKEY, ssl_key);
}
+#endif
#if LIBCURL_VERSION_NUM >= 0x070908
if ((ssl_capath = getenv("GIT_SSL_CAPATH")) != NULL) {
curl_easy_setopt(curl, CURLOPT_CAPATH, ssl_capath);
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: David Leimbach @ 2005-09-29 16:13 UTC (permalink / raw)
To: Alberto Patino; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <4489a22a050929090358badd29@mail.gmail.com>
On 9/29/05, Alberto Patino <pato.lukaz@gmail.com> wrote:
> On 9/29/05, David Leimbach <leimy2k@gmail.com> wrote:
> > On 9/29/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> > >
> > > Just updated my KHGtG to include the latest goodies available in
> > > git-core, the Linux kernel standard SCM tool:
> > >
> > > http://linux.yyz.us/git-howto.html
> >
> > Can you update the date on that page to reflect your latest updates?
> > - Dave
>
> The KHGtG page is updated to September 29, 2005.
>
>
Awesome! Thanks. :-) I'm looking at cogito and darcs-git for working
with v9fs and other goodies.
Dave
^ permalink raw reply
* Re: First cut at git port to Cygwin
From: H. Peter Anvin @ 2005-09-29 16:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0509291043580.20717@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 28 Sep 2005, H. Peter Anvin wrote:
>
>>Another funny which I haven't been able to figure out yet is that 'gitk'
>>scrunches all its output up into a few pixels at the top of the window.
>
> See my mail about rootless X11. I went about working around that
> particular Tk bug by specifying the dimensions of the panes explicitely.
> However, I was not especially happy with my workaround, since it did not
> reproduce the layout exactly after a restart. Maybe you can figure it out
> how to do that.
>
Unlikely, since I'm a complete Tcl/Tk illiterate.
-hpa
^ permalink raw reply
* Re: [PATCH] Use git-update-ref in scripts.
From: Linus Torvalds @ 2005-09-29 16:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfyrprqr6.fsf@assigned-by-dhcp.cox.net>
On Wed, 28 Sep 2005, Junio C Hamano wrote:
>
> Hopefully that would be rectified when git-daemon goes on-line,
> now I've merged updates from HPA ;-).
Yes, the git-daemon will help. However, it won't fix the lag from
master.kernel.org to the slaves, so I'd probably still have to re-write
things if there are mirror delays..
Linus
^ permalink raw reply
* Re: Edit log message after commit
From: Yasushi SHOJI @ 2005-09-29 16:05 UTC (permalink / raw)
To: Kevin Leung; +Cc: git
In-Reply-To: <dhg5vl$9ac$1@sea.gmane.org>
At Thu, 29 Sep 2005 15:45:49 +0800,
Kevin Leung wrote:
>
> But as Tony has pointed out. I would have needed to redo all the
> subsequent commits if I was to change non-HEAD commit message. What
> is the proper way of doing that? Is it the same as
> Documentation/howto/revert-branch-rebase.txt ?
as pointed out by others, if the tree is already public, do revert.
otherwise, use git-cherry-pick and git-rebase might help. but it
might not be a good idea. (don't know)
to illustrate this, create the following tree
c
|
b
|
a
|
initial
git-init-db
echo hello > hello.c
git-update-index --add hello.c
git-commit -v -m 'initial'
echo a >> hello.c
git-commit -a -m 'add a'
echo b >> hello.c
git-commit -a -m 'add b'
echo c >> hello.c
git-commit -a -m 'add c'
say, you want to edit the commit message for 'add a'.
first, create new branch at where you wanna change the message
git checkout -b temp HEAD^^^ # hmm... HEAD^3 doesn't work
cherry pick the 'add a' commit but don't commit yet
git-cherry-pick -n master^^
commit the change with reediting the original commit log
git commit --reedit master^^
rebase the _master_ to temp
git-checkout master
git-rebase temp
I'm pretty sure that there is better way to do it and these should be
easy to be scripted.
my two cents,
--
yashi
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: Alberto Patino @ 2005-09-29 16:03 UTC (permalink / raw)
To: David Leimbach; +Cc: Jeff Garzik, Linux Kernel, Git Mailing List
In-Reply-To: <3e1162e605092908187e181936@mail.gmail.com>
On 9/29/05, David Leimbach <leimy2k@gmail.com> wrote:
> On 9/29/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> > Just updated my KHGtG to include the latest goodies available in
> > git-core, the Linux kernel standard SCM tool:
> >
> > http://linux.yyz.us/git-howto.html
>
> Can you update the date on that page to reflect your latest updates?
> - Dave
The KHGtG page is updated to September 29, 2005.
--
Don't be evil!!!
^ permalink raw reply
* Re: [howto] Kernel hacker's guide to git, updated
From: David Leimbach @ 2005-09-29 15:18 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Linux Kernel, Git Mailing List
In-Reply-To: <433BC9E9.6050907@pobox.com>
On 9/29/05, Jeff Garzik <jgarzik@pobox.com> wrote:
>
> Just updated my KHGtG to include the latest goodies available in
> git-core, the Linux kernel standard SCM tool:
>
> http://linux.yyz.us/git-howto.html
Can you update the date on that page to reflect your latest updates?
I was digging around with git yesterday and had a few surprises...
like checking out the kernel and being told I modified a bunch of
files I never touched.
- Dave
^ permalink raw reply
* Re: [PATCH] Use git-update-ref in scripts.
From: Linus Torvalds @ 2005-09-29 15:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vk6h1rr9l.fsf@assigned-by-dhcp.cox.net>
On Wed, 28 Sep 2005, Junio C Hamano wrote:
>
> Hmph. That sort of makes sense but to make the unconditional
> simple case really fast it should use read-tree -m -u which
> _would_ smudge if things do not go well, which implies you need
> savestate before that which would make it slower -- wouldn't it?
Yeah, we'd have to do something like this.. (untested, surprise, surprise)
NOTE! Even if you don't take this, I noticed what looks like a missing
"continue" in the "--head" case. That just can't work without it, afaik.
Not that I know what "--head" is supposed to do..
Linus
---
diff --git a/read-tree.c b/read-tree.c
--- a/read-tree.c
+++ b/read-tree.c
@@ -13,6 +13,8 @@
static int merge = 0;
static int update = 0;
static int index_only = 0;
+static int nontrivial_merge = 0;
+static int trivial_merges_only = 0;
static int head_idx = -1;
static int merge_size = 0;
@@ -275,6 +277,9 @@ static int unpack_trees(merge_fn_t fn)
if (unpack_trees_rec(posns, len, "", fn, &indpos))
return -1;
+ if (trivial_merges_only && nontrivial_merge)
+ die("Merge requires file-level merging");
+
check_updates(active_cache, active_nr);
return 0;
}
@@ -460,6 +465,8 @@ static int threeway_merge(struct cache_e
verify_uptodate(index);
}
+ nontrivial_merge = 1;
+
/* #2, #3, #4, #6, #7, #9, #11. */
count = 0;
if (!head_match || !remote_match) {
@@ -629,9 +636,15 @@ int main(int argc, char **argv)
continue;
}
+ if (!strcmp(arg, "--trivial")) {
+ trivial_merges_only = 1;
+ continue;
+ }
+
if (!strcmp(arg, "--head")) {
head_idx = stage - 1;
fn = threeway_merge;
+ continue;
}
/* "-m" stands for "merge", meaning we start in stage 1 */
^ permalink raw reply
* Re: Really happy with cogito for inhouse teamwork, now that I've figured out cg-clone...
From: Josef Weidendorfer @ 2005-09-29 15:15 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f905092822587f5414d4@mail.gmail.com>
On Thursday 29 September 2005 07:58, Martin Langhoff wrote:
> Doing the checkout the 'right' way:
> $ cg-clone git+ssh://locke.catalyst.net.nz/var/git/project.git#branchname
> localdirname
>
> Work cycle:
> # work work work
> $ cg-commit
> $ cg-update
> $ cg-push
Yes, this works very well here, too.
And it works officially since cg-push allows to push on a
non-master remote head (based on git's advanced push allowing mapping of
different head names on local and remote side).
[Before, I used a hack in cg-clone: with e.g. cloning remote head "rem",
symlink local master to a local "rem". This was working quite fine, too]
The following is equally fine (smaller work per commit, with lot more commits
relative to the pushing to the central rep - gives more documentation
on the development history):
# work
$ cg-commit
# work
$ cg-commit
# work
$ cg-commit
$ cg-update
$ cg-push
Aditionally, we have in the central repository a head per developer,
to publish experimental/instable work, and they are regularly merged
back into the central master.
The key to simplicity is here, to have one clone for every remote head.
Introducing Git/Cogito to other people this way almost needs no tutorial at
all.
This is complemented by an automated mail to a project mailing list
via use of the update-hook in the central repository, so that every
developer is kept up-to-date on work of others. The mail is
formatted to include URLs for every commit to a matching
gitweb interface. Was really easy to setup and quite handy.
Josef
^ 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