* Re: git-fetch, was Re: [PATCH] Port git-tag.sh to C.
From: Johannes Schindelin @ 2007-06-13 0:27 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Julian Phillips, Carlos Rica, =?X-UNKNOWN?Q?Kristian_H=F8gsberg?=,
git
In-Reply-To: <Pine.LNX.4.64.0706121953080.5848@iabervon.org>
Hi,
On Tue, 12 Jun 2007, Daniel Barkalow wrote:
> Okay, git://iabervon.org/~barkalow/git.git builtin-fetch.
Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: git-fetch, was Re: [PATCH] Port git-tag.sh to C.
From: Daniel Barkalow @ 2007-06-12 23:55 UTC (permalink / raw)
To: Julian Phillips
Cc: Johannes Schindelin, Carlos Rica,
=?X-UNKNOWN?Q?Kristian_H=F8gsberg?=, git
In-Reply-To: <Pine.LNX.4.64.0706121427410.18585@reaper.quantumfyre.co.uk>
On Tue, 12 Jun 2007, Julian Phillips wrote:
> On Tue, 12 Jun 2007, Johannes Schindelin wrote:
>
> > Hi,
> >
> > On Mon, 11 Jun 2007, Daniel Barkalow wrote:
> >
> > > On Sat, 9 Jun 2007, Carlos Rica wrote:
> > >
> > > > Feel free to choose the script which you need to get replaced first,
> > > > or, depending on your urgency, you could ask me for one of them and I
> > > > would try to concentrate my efforts on it. Why do you started with
> > > > git-tag? For me, it was enough easy to begin with, perhaps you could
> > > > have other reasons.
> > >
> > > Incidentally, I have been working on fetch, based on Julian Phillips's
> > > version. I'm trying to split out the "how do I communicate with remote
> > > repositories" code, and use it for pushing and ls-remote as well as
> > > fetch. I've got a bunch of not-for-official-history development that you
> > > should look at if you try any of the remote-repository-access scripts.
> >
> > How about pushing them onto repo.or.cz as a fork of git.git?
>
> I'd quite like to see these changes too - since I haven't finished the fetch
> work yet, and I don't want to duplicate effort ;)
Okay, git://iabervon.org/~barkalow/git.git builtin-fetch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Problem with a push
From: Martin Langhoff @ 2007-06-12 23:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andy Parkins, git, plexq
In-Reply-To: <7vk5u9hzv9.fsf@assigned-by-dhcp.pobox.com>
On 6/13/07, Junio C Hamano <gitster@pobox.com> wrote:
> - When doing 'matching refs', do it only under refs/heads/.
Yes please ;-)
We've had this conversation about 2 weeks ago -- it's confusing (and
worrying) to see that a git-push tries to push stuff from remotes/ to
the repo...
cheers,
martin
^ permalink raw reply
* Re: [StGIT PATCH 0/2] Fix issues with series deletion
From: Catalin Marinas @ 2007-06-12 22:16 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070609184317.GM6992@nan92-1-81-57-214-146.fbx.proxad.net>
On 09/06/07, Yann Dirson <ydirson@altern.org> wrote:
> Speaking of transactions, did you have a chance to read the proposal I
> posted some time ago ? As stated in another mail, I fear that
> approach does generalize easily to core git - but for lack of a better
> solution, we may want to go this way anyway...
Yes, I managed to read most of it at that time. I'll try to reply to
the individual points in that e-mail. My idea was to store all the
stack state, including patch information, in a single file rather than
having them scattered around (maybe XML, sounds cool :-) but it's not
easily parseable from shell-scripts).
--
Catalin
^ permalink raw reply
* Re: [StGIT PATCH 2/4] Abstract a PatchSet object out of Series.
From: Catalin Marinas @ 2007-06-12 22:09 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070611003330.4736.69293.stgit@gandelf.nowhere.earth>
On 11/06/07, Yann Dirson <ydirson@altern.org> wrote:
> The goal is to move into PatchSet all functionnality that is not
> dependant of Series being a real stack, paving the way for handling
> parallel (hydra) stacks, or any other way to organize patches.
Thanks for the patches. I applied this one as well and I like the
idea. What is your long-term plan with this split?
The HEAD in my repository fails the test suite. Do you have any
additional patches pending (some patches were not applied in order as
I had to manually fix the conflicts). Anyway, please check my
repository for any missing patches.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH 1/3] refactor dir_add_name
From: Jonas Fonseca @ 2007-06-12 21:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7iq9lk76.fsf@assigned-by-dhcp.pobox.com>
Junio C Hamano <gitster@pobox.com> wrote Tue, Jun 12, 2007:
> Anyway, it appears that Jonas picked up your patch to polish up,
> so I won't touch this series until that resurfaces.
My idea was to put the nr, alloc, and entries members into a separate
struct dir_entry_list, which should allow the dir_add_* functions to be
"united" and thus somewhat remove the need for alloc_grow. However,
after spending some time on it, changing dir.nr to dir.entry_list.nr
etc. reduced readability so much that I ended up trying to make other
cleanups and the simplicity of the series was lost.
Anyway, I don't think I can come up with a more polished version without
adding a few cleanup patches along the way. So I think apart from the
amended version of 3/3 I will take back my intension to polish it up.
--
Jonas Fonseca
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Simon Hausmann @ 2007-06-12 21:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070604055600.GE4507@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
On Monday 04 June 2007 07:56:00 Shawn O. Pearce wrote:
> Simon Hausmann <simon@lst.de> wrote:
> > On the topic of git integration with perforce, what are the chances of
> > getting git-p4 ( http://repo.or.cz/w/fast-export.git ) into git's
> > contrib/fast-export area? :)
> >
> > git-p4 can do everything git-p4import can do plus a lot more (it can
> > track multiple branches, it's a hell of a lot faster, it can export back
> > to p4 and it also works on Windows!).
>
> I was sort of hoping we could fold the fast-export Git repository
> on repo.or.cz into core Git at some point. Right now the only
> thing in contrib/fast-export is the import-tars.perl script that
> I maintain in my fastimport repository... ;-)
>
> Like Junio I don't use Perforce, and can't test against it, but
> if you can maintain git-p4 (and I think the history on repo.or.cz
> shows that you do) then it may be a good idea to add it to core Git.
>
> Send a patch to add it. Worst that happens is both Junio and I
> decide not to apply it. Or I apply it, but Junio refuses to pull
> from me afterwards. ;-)
Ok, I'll give it a try :)
I've used git-filter-branch to rewrite the history in fast-export to include
only changes relevant to git-p4 and at the same time move all files into
contrib/fast-import. The result is available as separate branch at
git://repo.or.cz/fast-export.git git-p4
and technically merges fine into git.git's contrib/fast-import directory with
three files (git-p4, git-p4.txt and git-p4.bat for windows convenience).
Please let me know if there's anything missing or if you prefer a different
format or so. I also realized that I haven't really used the 'Signed-off-by'
tags in the past but I'd be happy to adopt it for git inclusion if you prefer
that :)
_If_ one of you decides to pull then my plan is to discontinue the git-p4
branch in the fast-export repository and instead work in a git.git fork on
repo.or.cz (similar to the fastimport repository).
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] builtin-add: simplify (and increase accuracy of) exclude handling
From: Jonas Fonseca @ 2007-06-12 21:42 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20070611155425.GA9316@coredump.intra.peff.net>
From: Jeff King <peff@peff.net>
Previously, the code would always set up the excludes, and then manually
pick through the pathspec we were given, assuming that non-added but
existing paths were just ignored. This was mostly correct, but would
erroneously mark a totally empty directory as 'ignored'.
Instead, we now use the collect_ignored option of dir_struct, which
unambiguously tells us whether a path was ignored. This simplifies the
code, and means empty directories are now just not mentioned at all.
Furthermore, we now conditionally ask dir_struct to respect excludes,
depending on whether the '-f' flag has been set. This means we don't have
to pick through the result, checking for an 'ignored' flag; ignored entries
were either added or not in the first place.
We can safely get rid of the special 'ignored' flags to dir_entry, which
were not used anywhere else.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
builtin-add.c | 69 +++++++++++++++++---------------------------------------
dir.c | 16 +++++++++++-
dir.h | 4 +--
3 files changed, 36 insertions(+), 53 deletions(-)
Jeff King <peff@peff.net> wrote Mon, Jun 11, 2007:
> On Mon, Jun 11, 2007 at 05:01:23PM +0200, Jonas Fonseca wrote:
> > I think you could even get rid of has_ignored with something like this.
>
> Nope, I had originally wanted to do that, but the dir_struct.ignored
> list contains _all_ ignored items, not just those that were originally
> in the pathspec. The prune_ignored call sets uninteresting ones to
> NULL. That function could compact the list and re-set ignored_nr, but
> it doesn't currently do so.
>
> An even more elegant solution would be for read_directory to mark
> whether an ignored file comes from a pathspec, or was found through
> recursion. That would be more efficient, and it would remove the
> prune_ignored thing, which is IMHO a little hack-ish.
OK, I tried to do this, however, I got a bit confused with the intended
behavior. Anyway, it passes the test suite, is silent for empty
directories and will only show exact matches of the pathspec (this was
the confusing part) as ignored items.
diff --git a/builtin-add.c b/builtin-add.c
index 1591171..ad6aca8 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -40,42 +40,29 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
dir->nr = dst - dir->entries;
for (i = 0; i < specs; i++) {
- struct stat st;
- const char *match;
- if (seen[i])
- continue;
-
- match = pathspec[i];
- if (!match[0])
- continue;
-
- /* Existing file? We must have ignored it */
- if (!lstat(match, &st)) {
- struct dir_entry *ent;
-
- ent = dir_add_name(dir, match, strlen(match));
- ent->ignored = 1;
- if (S_ISDIR(st.st_mode))
- ent->ignored_dir = 1;
- continue;
- }
- die("pathspec '%s' did not match any files", match);
+ if(!seen[i] && !file_exists(pathspec[i]))
+ die("pathspec '%s' did not match any files",
+ pathspec[i]);
}
}
-static void fill_directory(struct dir_struct *dir, const char **pathspec)
+static void fill_directory(struct dir_struct *dir, const char **pathspec,
+ int ignored_too)
{
const char *path, *base;
int baselen;
/* Set up the default git porcelain excludes */
memset(dir, 0, sizeof(*dir));
- dir->exclude_per_dir = ".gitignore";
- path = git_path("info/exclude");
- if (!access(path, R_OK))
- add_excludes_from_file(dir, path);
- if (!access(excludes_file, R_OK))
- add_excludes_from_file(dir, excludes_file);
+ if (!ignored_too) {
+ dir->collect_ignored = 1;
+ dir->exclude_per_dir = ".gitignore";
+ path = git_path("info/exclude");
+ if (!access(path, R_OK))
+ add_excludes_from_file(dir, path);
+ if (!access(excludes_file, R_OK))
+ add_excludes_from_file(dir, excludes_file);
+ }
/*
* Calculate common prefix for the pathspec, and
@@ -219,13 +206,11 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
pathspec = get_pathspec(prefix, argv + i);
- fill_directory(&dir, pathspec);
+ fill_directory(&dir, pathspec, ignored_too);
if (show_only) {
const char *sep = "", *eof = "";
for (i = 0; i < dir.nr; i++) {
- if (!ignored_too && dir.entries[i]->ignored)
- continue;
printf("%s%s", sep, dir.entries[i]->name);
sep = " ";
eof = "\n";
@@ -237,25 +222,13 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (read_cache() < 0)
die("index file corrupt");
- if (!ignored_too) {
- int has_ignored = 0;
- for (i = 0; i < dir.nr; i++)
- if (dir.entries[i]->ignored)
- has_ignored = 1;
- if (has_ignored) {
- fprintf(stderr, ignore_warning);
- for (i = 0; i < dir.nr; i++) {
- if (!dir.entries[i]->ignored)
- continue;
- fprintf(stderr, "%s", dir.entries[i]->name);
- if (dir.entries[i]->ignored_dir)
- fprintf(stderr, " (directory)");
- fputc('\n', stderr);
- }
- fprintf(stderr,
- "Use -f if you really want to add them.\n");
- exit(1);
+ if (dir.ignored_nr) {
+ fprintf(stderr, ignore_warning);
+ for (i = 0; i < dir.ignored_nr; i++) {
+ fprintf(stderr, "%s\n", dir.ignored[i]->name);
}
+ fprintf(stderr, "Use -f if you really want to add them.\n");
+ exit(1);
}
for (i = 0; i < dir.nr; i++)
diff --git a/dir.c b/dir.c
index 1ffc1e5..f3a6757 100644
--- a/dir.c
+++ b/dir.c
@@ -275,7 +275,6 @@ static
struct dir_entry *dir_entry_new(const char *pathname, int len) {
struct dir_entry *ent;
ent = xmalloc(sizeof(*ent) + len + 1);
- ent->ignored = ent->ignored_dir = 0;
ent->len = len;
memcpy(ent->name, pathname, len);
ent->name[len] = 0;
@@ -432,6 +431,18 @@ static int simplify_away(const char *path, int pathlen, const struct path_simpli
return 0;
}
+static int in_pathspec(const char *path, int len, const struct path_simplify *simplify)
+{
+ if (simplify) {
+ for (; simplify->path; simplify++) {
+ if (len == simplify->len
+ && !memcmp(path, simplify->path, len))
+ return 1;
+ }
+ }
+ return 0;
+}
+
/*
* Read a directory tree. We currently ignore anything but
* directories, regular files and symlinks. That's because git
@@ -472,7 +483,8 @@ static int read_directory_recursive(struct dir_struct *dir, const char *path, co
continue;
exclude = excluded(dir, fullname);
- if (exclude && dir->collect_ignored)
+ if (exclude && dir->collect_ignored
+ && in_pathspec(fullname, baselen + len, simplify))
dir_add_ignored(dir, fullname, baselen + len);
if (exclude != dir->show_ignored) {
if (!dir->show_ignored || DTYPE(de) != DT_DIR) {
diff --git a/dir.h b/dir.h
index c94f3cb..ec0e8ab 100644
--- a/dir.h
+++ b/dir.h
@@ -13,9 +13,7 @@
struct dir_entry {
- unsigned int ignored : 1;
- unsigned int ignored_dir : 1;
- unsigned int len : 30;
+ unsigned int len;
char name[FLEX_ARRAY]; /* more */
};
--
1.5.2.1.958.g264c-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Frank Lichtenheld, skimo
In-Reply-To: <7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com>
On Tuesday 12 June 2007, Junio C Hamano wrote:
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
> > KDE (superproject)
> > +- kdelibs (subproject)
> > | +- admin (subproject)
> > | +- subdir1
> > | +- ...
> > +- kdebase (subproject)
> > | +- admin (subproject)
> > | +- subdir2
> > | +- ...
> > +- kdenetwork (subproject)
> > | +- admin (subproject)
> > | +- subdir3
> > | +- ...
> > ...
>
> If these three instances of 'admin' are truly the same project
> created in multiple places in the directory hierarchy, what is
> the reason that it is not arranged like this instead?
>
> KDE
> +- admin
> +- kdelibs
> | +- subdir1
> | +- ...
> +- kdebase
> | +- subdir2
> | +- ...
> +- kdenetwork
> | +- subdir3
> | +- ...
> ...
Actually, on the SVN server you have this structure.
KDE applications are put together in groups with
other applications of same kind, e.g. kdenetwork contains
applications for net access.
Now if you want to work on one KDE application e.g. in
kdenetwork, you usually checkout _only_ the kdenetwork
directory. There is no need to have other parts; e.g.
you usually should be able to use the KDE libs from
your distribution - no need to checkout kdelibs.
However, the "admin" directory above contains the build
environment, which has to be checked out so that kdenetwork
is able to build. The applications expect the build tools
to reside in the admin subdirectory.
To checkout admin inside KDE modules such as kdenetwork,
SVN externals are used, which is a primitive form of git
submodules, to automatically checkout the admin directory
on checkout of the KDE module.
So the same admin directory only will be duplicated
multiple times only on the developers side where multiple
KDE modules are checked out.
> When kdelibs/subdir1 needs to access stuff in admin, instead of
> going to ../admin, it could very well go to ../../admin couldn't
> it?
Usually, ../../admin will not exist as explicit checkout on
a developers machine. It would be possible to require this, but
it is much nicer to have each checkout of a KDE module
self-contained, including a copy of admin.
> It makes me wonder if the KDE's layout you quoted is a good
> practice we would want to recommend for other people to follow.
> If not, I doubt it is a good idea to model our important concept
> after that layout to begin with.
In the case of KDE, as far as I remember there is no need to
put _everything_ inside of a the mega supermodule. Every KDE
module (like kdelibs, kdebase, kdenetwork) has its own configure
run and checks dependencies.
What IMHO is an important use case for submodules is to have the
same submodule in multiple different superprojects, as the admin
example shows.
Josef
PS: Above admin example is from KDE3. KDE4 uses an
installed build environment (not really sure).
^ permalink raw reply
* [PATCH] Add a local implementation of hstrerror for the system which do not have it
From: Alex Riesen @ 2007-06-12 21:31 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Randal L. Schwartz
In-Reply-To: <20070612205210.GC2459@steel.home>
The function converts the value of h_errno (last error of name
resolver library, see netdb.h). One of systems which supposedly do
not have the function is SunOS. POSIX does not mandate its presence.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Randal, you seem to have access to a SunOS system. Could you try to
compile your git with NO_IPV6 (if you already applied the previous
fix, which removed superflous calls to hstrerror), and than again
without it (just to be sure)?
Makefile | 5 +++++
compat/hstrerror.c | 21 +++++++++++++++++++++
git-compat-util.h | 5 +++++
3 files changed, 31 insertions(+), 0 deletions(-)
create mode 100644 compat/hstrerror.c
diff --git a/Makefile b/Makefile
index 0f6540c..e054bc7 100644
--- a/Makefile
+++ b/Makefile
@@ -410,6 +410,7 @@ ifeq ($(uname_S),SunOS)
NEEDS_NSL = YesPlease
SHELL_PATH = /bin/bash
NO_STRCASESTR = YesPlease
+ NO_HSTRERROR = YesPlease
ifeq ($(uname_R),5.8)
NEEDS_LIBICONV = YesPlease
NO_UNSETENV = YesPlease
@@ -654,6 +655,10 @@ endif
ifdef NO_PERL_MAKEMAKER
export NO_PERL_MAKEMAKER
endif
+ifdef NO_HSTRERROR
+ COMPAT_CFLAGS += -DNO_HSTRERROR
+ COMPAT_OBJS += compat/hstrerror.o
+endif
ifeq ($(TCLTK_PATH),)
NO_TCLTK=NoThanks
diff --git a/compat/hstrerror.c b/compat/hstrerror.c
new file mode 100644
index 0000000..c59b808
--- /dev/null
+++ b/compat/hstrerror.c
@@ -0,0 +1,21 @@
+#include <string.h>
+#include <stdio.h>
+#include <netdb.h>
+
+const char *githstrerror(int err)
+{
+ static char buffer[32];
+ switch (err)
+ {
+ case HOST_NOT_FOUND:
+ return "Authoritative answer: host not found";
+ case NO_DATA:
+ return "Valid name, no data record of requested type";
+ case NO_RECOVERY:
+ return "Non recoverable errors, FORMERR, REFUSED, NOTIMP";
+ case TRY_AGAIN:
+ return "Non-authoritative \"host not found\", or SERVERFAIL";
+ }
+ sprintf(buffer, "Name resolution error %d", err);
+ return buffer;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index 6bd8987..b2ab3f8 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -167,6 +167,11 @@ extern size_t gitstrlcpy(char *, const char *, size_t);
extern uintmax_t gitstrtoumax(const char *, char **, int);
#endif
+#ifdef NO_HSTRERROR
+#define hstrerror githstrerror
+extern const char *githstrerror(int herror);
+#endif
+
extern void release_pack_memory(size_t, int);
static inline char* xstrdup(const char *str)
--
1.5.2.1.191.gc01a
^ permalink raw reply related
* Re: [PATCH] Edit user manual for grammar
From: Randal L. Schwartz @ 2007-06-12 21:08 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Andy Parkins, git
In-Reply-To: <20070612175421.GA26767@fieldses.org>
>>>>> "J" == J Bruce Fields <bfields@fieldses.org> writes:
J> On Tue, Jun 12, 2007 at 04:43:19PM +0100, Andy Parkins wrote:
>> - "last-resort" is two words, not a conjoined word, it doesn't require
>> the hyphen
J> Right, but when you've got a couple words functioning together to modify
J> a following noun, the hyphen's pretty standard: "rosy-fingered dawn".
J> Is this case an exception? I suspect it's fine either way....
According to <http://www.getitwriteonline.com/archive/042703.htm>, hyphenate
unless it's a "ly" or unless it makes clear sense without it.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* [PATCH] Don't dereference a strdup-returned NULL
From: Jim Meyering @ 2007-06-12 20:59 UTC (permalink / raw)
To: git
There are only a dozen or so uses of strdup in all of git.
Of those, most seem ok, but this one isn't:
Signed-off-by: Jim Meyering <jim@meyering.net>
---
remote.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/remote.c b/remote.c
index 33c8e50..ed62a62 100644
--- a/remote.c
+++ b/remote.c
@@ -542,7 +542,7 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
strcpy(dst_name, pat->dst);
strcat(dst_name, src->name + strlen(pat->src));
} else
- dst_name = strdup(src->name);
+ dst_name = xstrdup(src->name);
dst_peer = find_ref_by_name(dst, dst_name);
if (dst_peer && dst_peer->peer_ref)
/* We're already sending something to this ref. */
--
1.5.2.1.159.g8d11
^ permalink raw reply related
* [PATCH] Do not use h_errno after connect(2): the function does not set it
From: Alex Riesen @ 2007-06-12 20:52 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Junio C Hamano
In-Reply-To: <86ejkh40cr.fsf@blue.stonehenge.com>
Randal L. Schwartz noticed compilation problems on SunOS, which made
me look at the code again. The thing is, h_errno is not used by
connect(2), it is only for functions from netdb.h, like gethostbyname.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
This must fix your link problems (unless you want to use NO_IPV6=1,
where another fix will be posted in a minute).
connect.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/connect.c b/connect.c
index 7fab9c0..a5afd2a 100644
--- a/connect.c
+++ b/connect.c
@@ -224,11 +224,10 @@ static int git_tcp_connect_sock(char *host, int flags)
}
if (connect(sockfd, ai->ai_addr, ai->ai_addrlen) < 0) {
saved_errno = errno;
- fprintf(stderr, "%s[%d: %s]: net=%s, errno=%s\n",
+ fprintf(stderr, "%s[%d: %s]: errno=%s\n",
host,
cnt,
ai_name(ai),
- hstrerror(h_errno),
strerror(saved_errno));
close(sockfd);
sockfd = -1;
@@ -315,11 +314,10 @@ static int git_tcp_connect_sock(char *host, int flags)
if (connect(sockfd, (struct sockaddr *)&sa, sizeof sa) < 0) {
saved_errno = errno;
- fprintf(stderr, "%s[%d: %s]: net=%s, errno=%s\n",
+ fprintf(stderr, "%s[%d: %s]: errno=%s\n",
host,
cnt,
inet_ntoa(*(struct in_addr *)&sa.sin_addr),
- hstrerror(h_errno),
strerror(saved_errno));
close(sockfd);
sockfd = -1;
--
1.5.2.1.191.gc01a
^ permalink raw reply related
* Re: Mail after commit
From: Martin Langhoff @ 2007-06-12 20:35 UTC (permalink / raw)
To: Claudio Scordino; +Cc: git
In-Reply-To: <466EBC7E.8040104@gmail.com>
On 6/13/07, Claudio Scordino <cloud.of.andor@gmail.com> wrote:
> Doesn't exist any way to make it simpler ?
I think most people setup gitweb, and follow its rss feed. Not exacty
the same, I know, but quite useful.
cheers,
martin
^ permalink raw reply
* Re: Problem with a push
From: Jon Loeliger @ 2007-06-12 20:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: plexq, Git List
In-Reply-To: <alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org>
On Mon, 2007-06-11 at 19:40, Linus Torvalds wrote:
> That said, I don't think that's necessarily the right answer in the longer
> run. It's how git people do things, but it's not necessarily the *best*
> way of doing things. I think the better solution in the longer term is to
> simply improve how "git push" works:
>
> - we should probably do the same kinds of .git/config file entries for
> pushing as we do for fetching, and just get rid of the old implicit
> model, and instead have a nice refspec pattern model for what gets
> pushed instead.
Yeah, the other day I was baffled briefly by the fact that
I added a remote to my config using "git remote add ..."
with the intent of using it for pushing to a publishing site.
I forgot that it set up fetch only refs.
Maybe a new "--push" flag to 'git remote add --push ..."
to indicated the intended flow direction for a remote?
> anyway, I think the _proper_ thing to do would be to associate each
> [remote] entry in the config file with a "push" refspec pattern, the way
> we do for "fetch" already.
nod
jdl
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: J. Bruce Fields @ 2007-06-12 20:05 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200706122028.01310.andyparkins@gmail.com>
On Tue, Jun 12, 2007 at 08:27:59PM +0100, Andy Parkins wrote:
> It's certainly common, I don't think that it's correct though.
In cases like this some seem to think it's actually required:
"Use a hyphen to connect two or more words functioning together
as an adjective before a noun."
(From p. 234 of "A Writer's Reference", 3rd ed., Diana Hacker--just what
I happen to have on my shelf.) I suppose it's there to help find the
modified noun when you're constructing modifiers out of multiple words
that aren't necessarily adjectives.
But whatever, I've no real objection to the patch.
> Please don't take "vulgar" to mean disgusting, I meant "common". Sorry
> if that was offensive.
Nah, just curious. "For" seems a little more precise in this case, so
fair enough.
> > What we really need is a complete recovery tutorial to stick in here
> > someplace. (One day git complains about a corrupt pack file. What
> > do you do?) What's been stopping me from doing it, besides time, is
> > no idea how to come up with a good example to work with.
>
> A big magnet on your hard disk? ;-)
Hah. OK, next suggestion....
--b.
^ permalink raw reply
* Re: [BUG] 75d8ff1 fails on SunOS 5.9 (missing hsterror) from ba505322
From: Alex Riesen @ 2007-06-12 20:03 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86ejkh40cr.fsf@blue.stonehenge.com>
Randal L. Schwartz, Tue, Jun 12, 2007 18:13:40 +0200:
> I suspect this broke in ba505322 when connect.c added hsterror().
>
> Yes, bumping to g18bece works fine. So it looks like we need a compat
> hsterror(), or it should be removed or ifdef'ed somehow. Paging Alex Riesen?
Looks like. What have they got instead to clarify what h_errno means?
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: Andy Parkins @ 2007-06-12 19:27 UTC (permalink / raw)
To: git; +Cc: J. Bruce Fields
In-Reply-To: <20070612175421.GA26767@fieldses.org>
On Tuesday 2007, June 12, J. Bruce Fields wrote:
> On Tue, Jun 12, 2007 at 04:43:19PM +0100, Andy Parkins wrote:
> > - "last-resort" is two words, not a conjoined word, it doesn't
> > require the hyphen
>
> Right, but when you've got a couple words functioning together to
> modify a following noun, the hyphen's pretty standard: "rosy-fingered
> dawn". Is this case an exception? I suspect it's fine either way....
It's certainly common, I don't think that it's correct though. The
hyphen's is to form a new word from multiple other words; but often
these days it's just used to join two words that the author wanted
saying faster in his head. The test I always use is if the meaning
remains the same without the hyphen, it wasn't necessary.
Examples:
merry-go-round versus merry go round
editor-in-chief versus editor in chief
Both of the above loose their meaning when they don't have the hyphens.
"last-resort" doesn't need to be compound because separated it still
means "the resort that is last".
I don't say that it is a definitive _wrong_ as the meaning is not lost
nor modified; but I've always viewed English like programming - don't
add unnecessary complication.
> > - "method of" is vulgar, "method for" is nicer
>
> Reference?
Please don't take "vulgar" to mean disgusting, I meant "common". Sorry
if that was offensive.
Preposition selection and use is highly localised. I will happily
accept if you don't agree. Here is the only reference I can find, but
it is certainly not definitive, not entirely about this subject...
http://mb.sparknotes.com/mb.epl?b=2437&m=1259471&t=355765&w=1
However, it does make the case that "of" is possessive, so a "method
of ..." means "a method that belongs to ...", so to my ears "a method
for" seems the better choice.
> What we really need is a complete recovery tutorial to stick in here
> someplace. (One day git complains about a corrupt pack file. What
> do you do?) What's been stopping me from doing it, besides time, is
> no idea how to come up with a good example to work with.
A big magnet on your hard disk? ;-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Junio C Hamano @ 2007-06-12 19:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marco Costalba, Linus Torvalds, Git Mailing List
In-Reply-To: <20070612135303.GT6073@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Marco Costalba <mcostalba@gmail.com> wrote:
>> On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:
>> >
>> > (1) Are you emulating CVS-like "a file has an identity, and we
>> > follow its changes" model? How does it handle file split,
>> > merge, and code movement in general?
>> >
>>
>> It uses 'git rev-list HEAD -- <path>' to get the list of revisions
>> that modified a path,
>
> So apparently yes, qgit is emulating CVS. And yet much better things
> exist (git-blame).
I would not use the word "better", as it depends on what you are
looking for.
>> I really would like to keep it like that because it is the way 'git'
>> works, and I would feel uncomfortable in filtering out git results, it
>> seems quite fragile to me.
>
> Its not "the way git works". Its just one way of looking at the data
> in the object database. And its not as accurate or as interesting
> as what git-blame does.
Again, I would not say "accurate".
The way Marco describes is a perfectly valid way to satisfy
expectations of people migrating from CVS. It's more faithful
reproduction of CVS annotate behaviour. In a sense, git-blame
does too much, but that is exactly why these "accurate and
interesting" behaviours are optional.
>> This means that file splits, merges, renames etc.. are handled as much
>> as they are handled in git. IOW *if* 'git rev-list HEAD -- <path>'
>> returns a list of revisions taking in account all of the above, so it
>> will, automatically, do qgit.
>>
>> BTW _currentlly_ git-rev-list does not do that.
>
> And it may never do it.
Oh, I can guarantee you that git-rev-list will never ever do
that. It is to traverse revisions while simplifying with path
limiters, and path limiters by definition will not look inside
contents. Think of it as asking "Had my project consisted of
only arch/i386 and include/asm-i386 directories, what would the
history be".
However, adding a new option to "git log" so that you can say
'git log --single-follow=$this_file_at_the_tip $branch' is a
separate matter. I think it is a sensible thing to do. But
even if we do that, I think --single-follow should limit itself
to the rename following of "diff -M/-C" style. It is insane to
include another path only because the result did copy&paste only
a handful lines out of during its history.
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Sven Verdoolaege @ 2007-06-12 19:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, Frank Lichtenheld
In-Reply-To: <7vfy4xhu6p.fsf@assigned-by-dhcp.pobox.com>
On Tue, Jun 12, 2007 at 12:03:10PM -0700, Junio C Hamano wrote:
> Johannes Sixt <J.Sixt@eudaptics.com> writes:
>
> > Lars Hjemli wrote:
> >> Multiple checkout paths for a single submodule will bring havoc on
> >> this plan, so I need to ask: what is the use-case for multiple
> >> checkout paths?
> >
> > A use-case is the admin directory in the KDE repository. It has:
> >
> > KDE (superproject)
> > +- kdelibs (subproject)
> > | +- admin (subproject)
> > | +- subdir1
> > | +- ...
> > +- kdebase (subproject)
> > | +- admin (subproject)
> > | +- subdir2
> > | +- ...
> > +- kdenetwork (subproject)
> > | +- admin (subproject)
> > | +- subdir3
> > | +- ...
> > ...
>
> If these three instances of 'admin' are truly the same project
> created in multiple places in the directory hierarchy, what is
> the reason that it is not arranged like this instead?
>
> KDE
> +- admin
> +- kdelibs
> | +- subdir1
> | +- ...
> +- kdebase
> | +- subdir2
> | +- ...
> +- kdenetwork
> | +- subdir3
> | +- ...
> ...
>
> When kdelibs/subdir1 needs to access stuff in admin, instead of
> going to ../admin, it could very well go to ../../admin couldn't
> it?
In Hannes' example, kdelibs and kdebase are subprojects of their own.
Surely, you wouldn't want them to depend on something outside of
the (sub)project.
But even in a similar situation where the different parts do not
exist as separate projects, they may advance at a different pace
and therefore need different revisions of the same subproject.
skimo
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Junio C Hamano @ 2007-06-12 19:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Frank Lichtenheld, skimo
In-Reply-To: <466E7A17.CEB0F196@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Lars Hjemli wrote:
>> Multiple checkout paths for a single submodule will bring havoc on
>> this plan, so I need to ask: what is the use-case for multiple
>> checkout paths?
>
> A use-case is the admin directory in the KDE repository. It has:
>
> KDE (superproject)
> +- kdelibs (subproject)
> | +- admin (subproject)
> | +- subdir1
> | +- ...
> +- kdebase (subproject)
> | +- admin (subproject)
> | +- subdir2
> | +- ...
> +- kdenetwork (subproject)
> | +- admin (subproject)
> | +- subdir3
> | +- ...
> ...
If these three instances of 'admin' are truly the same project
created in multiple places in the directory hierarchy, what is
the reason that it is not arranged like this instead?
KDE
+- admin
+- kdelibs
| +- subdir1
| +- ...
+- kdebase
| +- subdir2
| +- ...
+- kdenetwork
| +- subdir3
| +- ...
...
When kdelibs/subdir1 needs to access stuff in admin, instead of
going to ../admin, it could very well go to ../../admin couldn't
it?
It makes me wonder if the KDE's layout you quoted is a good
practice we would want to recommend for other people to follow.
If not, I doubt it is a good idea to model our important concept
after that layout to begin with.
^ permalink raw reply
* Re: [PATCH] Edit user manual for grammar
From: Andy Parkins @ 2007-06-12 18:55 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <Pine.LNX.4.64.0706121714010.4059@racer.site>
On Tuesday 2007, June 12, Johannes Schindelin wrote:
> You sound like you address somebody personally. However, your "To:"
> only contains the list. Netiquette?
Apols; I made the patch with git-format-patch, which obviously didn't
know who I was replying to.
It was aimed at Steve Hoelzer, as it's his patch I enhanced (and
effectively stole :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: Problem with a push
From: Linus Torvalds @ 2007-06-12 18:46 UTC (permalink / raw)
To: plexq; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706121309260.7703@www.mintpixels.com>
On Tue, 12 Jun 2007, Alex R.M. Turner wrote:
>
> Based on what you've said, it seems like I should be initialising a blank
> repo on machine A, then pushing from machine B to machine A, rather than
> cloning on A from B.
That's generally what you'd do for a central repo, yes.
But:
> At this point would it just be sensible to delete the remote branches on
> machine A?
Yes, in the current environment, the easiest thing to do is to just remove
those branches.
OR, alternatively, just keep them, but on machine B, make your .git/config
file have something like
[remote "origin"]
url = ssh://aturner@svn.mintpixels.com/data/git/mls
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/*:refs/heads/*
which should just make it clear to "git push" than when you push from B to
"origin", you should push everything under "refs/heads" (assuming that's
what you want, of course)-
Linus
^ permalink raw reply
* Re: Problem with a push
From: Alex R.M. Turner @ 2007-06-12 18:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: plexq, git
In-Reply-To: <alpine.LFD.0.98.0706111727240.14121@woody.linux-foundation.org>
On Mon, 11 Jun 2007, Linus Torvalds wrote:
>
>
> On Mon, 11 Jun 2007, Alex R.M. Turner wrote:
> >
> > Cool - that totally makes sense, HEAD is a link to master. so updating
> > HEAD failed because it was already up to date.
>
> Yes. Well, strictly speaking it failed because it _wasn't_ up-to-date
> *before* the push (so "git push" thought it should update it), but it had
> become up-to-date (through the symref link) by the time it was actually
> its turn to be updated.
>
> > The command was simply:
> >
> > git push
>
> Ok, as Junio points out, it's then just the fact that both repositories
> had the same "remote" refs, and then the default of just updating
> everything in common kicks in.
>
> That default used to make sense back when, but it doesn't make sense for
> remotes, since those are generally "local" to each repo.
>
> > This repo was cloned from one on another server (the server I use to
> > backup everything) with a git clone command:
>
> Yeah. Normally you'd (well, _I_ would) only push to bare repositories, and
> normally you wouldn't make those bare repositories have "remotes" entries,
> which is why you're the first to apparently even notice this insanity.
>
> It wasn't your fault, it's simply bad defaults for git behaviour.
>
> The behaviour for "git pull" has improved _immensely_ over the last few
> months, but "git push" still does the same thing it always did, because
> fewer people care about pushing than pulling, and because the old "git
> push" behaviour of just updating all the branches in common actually
> happens to be the right thing when you do *not* make the central
> repository contain remote branches of its own.
>
> > Based on all this, what is the correct way to update my core repo on my
> > server? (I'm sorry - I'm pretty new to git, so I haven't quite cottoned on
> > to some aspects yet).
>
> With the current git model, I would suggest:
>
> - for "central" repositories, use a bare repository, and don't create
> "remotes" branches in that central repository at all.
>
> - for other repositories, don't push into them, just _pull_ into them
> (because that also knows about updating the working tree etc: pushing
> is really meant to be done only into bare and central ones that don't
> actually have any work happening in them, and _cannot_ have any work
> happening in them because they don't even have a working directory
> associated with them)
>
> That said, I don't think that's necessarily the right answer in the longer
> run. It's how git people do things, but it's not necessarily the *best*
> way of doing things. I think the better solution in the longer term is to
> simply improve how "git push" works:
>
> - we should probably do the same kinds of .git/config file entries for
> pushing as we do for fetching, and just get rid of the old implicit
> model, and instead have a nice refspec pattern model for what gets
> pushed instead.
>
> I _think_ the refspec cleanup work by Daniel makes this something we
> can almost already do. Daniel?
>
> - we should also likely have some way to specify what happens when you
> push into a branch that is currently checked out and has a working tree
> associated with it.
>
> This was briefly discussed a few weeks ago, but nobody cared enough, I
> suspect.
>
> anyway, I think the _proper_ thing to do would be to associate each
> [remote] entry in the config file with a "push" refspec pattern, the way
> we do for "fetch" already.
>
> Linux
Just so you don't think I'm completely crazy, I'll explained what caused
this:
I first created a repo on machine B by initializing a blank repo, then
fetching all historic revisions using git-svn from svn. Then I cloned the
repo to machine A using a git clone. Once I had the clone on machine A, I
initialized a new repo on machine B by doing a git clone from the repo on
machine A, so that the remote branches would point to the right place so a
git push would work. I see now that that caused a problem because the
repo on machine A now has remote branches pointing to machine B, which
isn't right because that repo doesn't exist anymore.
Based on what you've said, it seems like I should be initialising a blank
repo on machine A, then pushing from machine B to machine A, rather than
cloning on A from B.
At this point would it just be sensible to delete the remote branches on
machine A?
Alex
^ permalink raw reply
* Re: Let me ask again: How do we import patches from non-git sources?
From: J. Bruce Fields @ 2007-06-12 18:13 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <1181665653.4194.24.camel@zealous.synapsedev.com>
On Tue, Jun 12, 2007 at 09:27:33AM -0700, Marc Singer wrote:
> On Wed, 2007-06-06 at 13:54 -0400, J. Bruce Fields wrote:
> > Based on my notes from the last time I needed to feed a bunch of
> > non-mbox, non-git-produced patches into git-am, the hard part was
> > figuring out how it split a file into separate messages; my notes say:
> >
> > "Finds lines begining with "From " and ending with "hh:mm:ss
> > yyyy". See builtin-mailsplit code for more details."
> >
> > Other than that, I think it just needs and From: and Subject: lines to
> > get author and first-line of the commit. the git-am man page has some
> > documentation of this. It could probably use more.
> >
>
> I'm not sure that I understand your response.
>
> git-am complains that it cannot find an email address, but raw patches
> seldom have these. So, either we could use another command, or it would
> be handy if we could supply the email address to git-am (or some other
> data it needs so that it can split the patch.) I suppose the mistaken
> assumption is that the patch source in an email instead of already being
> a nice clean patch.
I think it's intentional. You need some standard format git-am can use
to split out the patches and find the comments and the authorship
information (for the Author: field on the commit), so why not just use
something like mbox?
And it could provide some fallback for the "Author:" information in the
case where it didn't find that, but we wouldn't want that to be the
default if it meant risking silently losing authorship information. I
suppose an "--author" option to git-am might be convenient sometimes.
But personally I always just add those headers by hand (or with a
script). It's not that hard; I the minimum required is just three
lines, I think:
From git-owner@vger.kernel.org Tue jun 12 11:43:40 2007
From: someone <someone@example.com>
Subject: [PATCH] do something
Do something complicated.
---
diff a/foo b/foo
...
And often I need different authors on different patches anyway, so
git-am --author wouldn't help.
Of course if you've just got one patch to import, you can git-apply and
then commit.
--b.
(PS: Standard practice around here is to leave people on the To: and/or
Cc: lines when you reply, and for me at least that'd be easier.)
^ 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