* [PATCH] fix generation of "humanish" part of source repo
From: Uwe Zeisberger @ 2006-01-20 6:47 UTC (permalink / raw)
To: git
If repo has the form <host>:<path> and <path> doesn't contain a slash, the
cloned repository is named "<host>:<path>", instead of "<path>" only.
Signed-off-by: Uwe Zeisberger <zeisberg@informatik.uni-freiburg.de>
---
git-clone.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
3aa74cf5b61fdd2f75ebda942e839a3ecc1e1f9c
diff --git a/git-clone.sh b/git-clone.sh
index f99e0ad..0504ba4 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -97,7 +97,7 @@ fi
dir="$2"
# Try using "humanish" part of source repo if user didn't specify one
-[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*/||g')
+[ -z "$dir" ] && dir=$(echo "$repo" | sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
[ -e "$dir" ] && $(echo "$dir already exists."; usage)
mkdir -p "$dir" &&
D=$(
--
1.0.8
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=Planck%27s+constant%3D
^ permalink raw reply related
* Re: StGIT: "stg new" vs "stg new --force"
From: Pavel Roskin @ 2006-01-20 6:23 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git, Charles Lever
In-Reply-To: <20060119213838.GA27397@nowhere.earth>
On Thu, 2006-01-19 at 22:38 +0100, Yann Dirson wrote:
> > I believe StGIT should be primarily designed to be used interactively.
>
> I tend to disagree. 3rd-party apps like qgit should be able to let
> the user do the selection, and tell the command-line tool what they
> want to act upon. It may be useful as well if stg gains
> interactivity, but should not become the only way to work with it
> (unix way of life).
In this particular case, the GUI frontend should be able to supply much
more data than the hunk numbers. It would be much safer.
I didn't mean to say that StGIT shouldn't have any options for
non-interactive processing. I meant that whenever adding a feature, we
should try to make it immediately useful without any frontends or
additional software.
> Maybe we could have a "fold" or "refresh" variant that takes its
> output from the output of "stg diff" (or any arbitrary diff on stdin,
> to be friendly with GUI wrappers) filtered by an arbitrary command.
That would be "fold". "refresh" like is saying - this patch should
produce this file. I actually tend to think now that deep refresh would
be confusing and dangerous if there is another patch closer in the stack
working with the same file, even in a separate part of it. stg would
either report conflict with the higher patches use the file with the
higher patches reverted, and neither sounds good to me.
Deep fold of the local changes would be much easier, since no other
patch should have them.
> That command could be "cat" to get the current "refresh" behaviour, or
> an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
> whatever clever filter one would want to use.
>
> Does it sound better ?
Yes. The first step would be to fix "stg refresh --edit --showpatch" to
actually respect edits made to the patch.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH] fsck-objects: support platforms without d_ino in struct dirent.
From: Christopher Faylor @ 2006-01-20 3:38 UTC (permalink / raw)
To: Junio C Hamano, Alex Riesen, git
In-Reply-To: <7vu0bz7lbk.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 19, 2006 at 05:13:51PM -0800, Junio C Hamano wrote:
>The d_ino field is only used for performance reasons in
>fsck-objects. On a typical filesystem, i-number tends to have a
>strong correlation with where the actual bits sit on the disk
>platter, and we sort the entries to allow us scan things that
>ought to be close together together.
>
>If the platform lacks support for it, it is not a big deal.
>Just do not use d_ino for sorting, and scan them unsorted.
Ah, interesting. I don't know if the file id objects would have
that sort of correlation on NT but obviously the file hashes don't.
cgf
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Christopher Faylor @ 2006-01-20 3:35 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vbqy78zwy.fsf@assigned-by-dhcp.cox.net>
On Thu, Jan 19, 2006 at 05:13:17PM -0800, Junio C Hamano wrote:
>Christopher Faylor <me@cgf.cx> writes:
>>Inodes are only calculated by hashing the path name when the OS lacks
>>the support to provide a "real" inode and in that case there is no hard
>>link support available so it's a non-issue.
>
>Does that mean on such filesystems "mv foo bar" would change the i-num
>of the moved entity?
I just tried this on Windows XP. On a FAT32 or a NTFS filesystem the
inode is unchanged. On a FAT filesystem, it changes. I assume that
means that FAT doesn't support a real file ID. The only thing I think
anyone would be using FAT for these days is possibly a boot partition.
That's the only reason I have one. I use to to multi-boot various
flavors of Windows. It's the lowest common denominator.
>I am not complaining even if that is the case. I just want to
>understand what it does.
NP. I complain about this fairly frequently myself. :-)
cgf
^ permalink raw reply
* Re: [QUESTION] about .git/info/grafts file
From: Junio C Hamano @ 2006-01-20 1:14 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <7v8xtdrqwg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> It _might_ work if you tell your downloader to have a proper
> graft file in his repository to cauterize the commit ancestry
> chain _before_ he pulls from you, though. I haven't tried it
> (and honestly I did not feel that is something important to
> support, so it might work by accident but that is not by
> design).
I just tried it and it actually works.
$ git clone git.git junk
$ cd junk ;# I am not brave enough to risk the real thing ;-)
$ git rev-parse master~4 >.git/refs/info/grafts
$ cd ..
$ mkdir cloned
$ cd cloned
$ git init-db
$ cp ../junk/.git/info/grafts .git/info/
$ git clone-pack ../baz
$ git fsck-objects --full
$ git log --pretty=short | cat
This "only the tip of the git.git" repository has about 450
objects in it, fully packed because of clone-pack, with one 680K
packfile. I think the true full history of git.git/ packed into
one is aruond a 5MB packfile. I suspect a bigger repository
would not see that much size reduction, as Linus already
explained here.
You could emulate what I just did above to prepare the
equivalent of "baz" above, and make it available over git://
protocol, say at git://franck.example.com/franck.git/.
Then you tell your downloaders something like this:
This repository has been cauterized, and cannot be
cloned in a usual manner, but once you make a clone
everything including further incremental updates should
work.
To clone this repository:
$ mkdir franckproject ;# make a new repository
$ cd franckproject && git init-db
$ echo 'XXxxxxXXxxx' >.git/info/grafts
$ git clone-pack git://franck.example.com/franck.git/
^ permalink raw reply
* [PATCH] DT_UNKNOWN: do not fully trust existence of DT_UNKNOWN
From: Junio C Hamano @ 2006-01-20 1:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Christopher Faylor
In-Reply-To: <81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com>
The recent Cygwin defines DT_UNKNOWN although it does not have d_type
in struct dirent. Give an option to tell us not to use d_type on such
platforms. Hopefully this problem will be transient.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* By sending this out, I am not claiming this is better than
your version or anything like that. This is just for
completeness and convenience, because my other two patches
touch overlapping areas in the same Makefile. This patch
comes after the other two.
Makefile | 7 +++++++
cache.h | 2 +-
2 files changed, 8 insertions(+), 1 deletions(-)
80a4322a9bfbf0389ba8cb50f674682349f40a3a
diff --git a/Makefile b/Makefile
index 31898f7..84f5d24 100644
--- a/Makefile
+++ b/Makefile
@@ -21,6 +21,9 @@ all:
#
# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
#
+# Define NO_D_TYPE_IN_DIRENT if your platform defines DT_UNKNOWN but lacks
+# d_type in struct dirent (latest Cygwin -- will be fixed soonish).
+#
# Define NO_STRCASESTR if you don't have strcasestr.
#
# Define NO_SETENV if you don't have setenv in the C library.
@@ -233,6 +236,7 @@ ifeq ($(uname_S),SunOS)
ALL_CFLAGS += -D__EXTENSIONS__
endif
ifeq ($(uname_O),Cygwin)
+ NO_D_TYPE_IN_DIRENT = YesPlease
NO_D_INO_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
@@ -335,6 +339,9 @@ ifdef NEEDS_NSL
LIBS += -lnsl
SIMPLE_LIB += -lnsl
endif
+ifdef NO_D_TYPE_IN_DIRENT
+ ALL_CFLAGS += -DNO_D_TYPE_IN_DIRENT
+endif
ifdef NO_D_INO_IN_DIRENT
ALL_CFLAGS += -DNO_D_INO_IN_DIRENT
endif
diff --git a/cache.h b/cache.h
index 29c9e81..3d79c55 100644
--- a/cache.h
+++ b/cache.h
@@ -10,7 +10,7 @@
#define deflateBound(c,s) ((s) + (((s) + 7) >> 3) + (((s) + 63) >> 6) + 11)
#endif
-#ifdef DT_UNKNOWN
+#if defined(DT_UNKNOWN) && !NO_D_TYPE_IN_DIRENT
#define DTYPE(de) ((de)->d_type)
#else
#define DT_UNKNOWN 0
--
1.1.3-gacdd
^ permalink raw reply related
* [PATCH] fsck-objects: support platforms without d_ino in struct dirent.
From: Junio C Hamano @ 2006-01-20 1:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Christopher Faylor
In-Reply-To: <7vlkxciodu.fsf@assigned-by-dhcp.cox.net>
The d_ino field is only used for performance reasons in
fsck-objects. On a typical filesystem, i-number tends to have a
strong correlation with where the actual bits sit on the disk
platter, and we sort the entries to allow us scan things that
ought to be close together together.
If the platform lacks support for it, it is not a big deal.
Just do not use d_ino for sorting, and scan them unsorted.
---
Junio C Hamano <junkio@cox.net> writes:
> ... I'll see how we would
> work this around on the git side to make things more portable.
Makefile | 6 ++++++
fsck-objects.c | 13 +++++++++++--
2 files changed, 17 insertions(+), 2 deletions(-)
4bec2123116a92fbeae12afc70317dfc85f6087b
diff --git a/Makefile b/Makefile
index e8f4b24..31898f7 100644
--- a/Makefile
+++ b/Makefile
@@ -19,6 +19,8 @@ all:
# Define NO_EXPAT if you do not have expat installed. git-http-push is
# not built, and you cannot push using http:// and https:// transports.
#
+# Define NO_D_INO_IN_DIRENT if you don't have d_ino in your struct dirent.
+#
# Define NO_STRCASESTR if you don't have strcasestr.
#
# Define NO_SETENV if you don't have setenv in the C library.
@@ -231,6 +233,7 @@ ifeq ($(uname_S),SunOS)
ALL_CFLAGS += -D__EXTENSIONS__
endif
ifeq ($(uname_O),Cygwin)
+ NO_D_INO_IN_DIRENT = YesPlease
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
# There are conflicting reports about this.
@@ -332,6 +335,9 @@ ifdef NEEDS_NSL
LIBS += -lnsl
SIMPLE_LIB += -lnsl
endif
+ifdef NO_D_INO_IN_DIRENT
+ ALL_CFLAGS += -DNO_D_INO_IN_DIRENT
+endif
ifdef NO_STRCASESTR
COMPAT_CFLAGS += -DNO_STRCASESTR
COMPAT_OBJS += compat/strcasestr.o
diff --git a/fsck-objects.c b/fsck-objects.c
index 90e638e..9950be2 100644
--- a/fsck-objects.c
+++ b/fsck-objects.c
@@ -20,6 +20,13 @@ static int check_strict = 0;
static int keep_cache_objects = 0;
static unsigned char head_sha1[20];
+#if NO_D_INO_IN_DIRENT
+#define SORT_DIRENT 0
+#define DIRENT_SORT_HINT(de) 0
+#else
+#define SORT_DIRENT 1
+#define DIRENT_SORT_HINT(de) ((de)->d_ino)
+#endif
static void objreport(struct object *obj, const char *severity,
const char *err, va_list params)
@@ -307,7 +314,9 @@ static void fsck_sha1_list(void)
{
int i, nr = sha1_list.nr;
- qsort(sha1_list.entry, nr, sizeof(struct sha1_entry *), ino_compare);
+ if (SORT_DIRENT)
+ qsort(sha1_list.entry, nr,
+ sizeof(struct sha1_entry *), ino_compare);
for (i = 0; i < nr; i++) {
struct sha1_entry *entry = sha1_list.entry[i];
unsigned char *sha1 = entry->sha1;
@@ -361,7 +370,7 @@ static int fsck_dir(int i, char *path)
memcpy(name+2, de->d_name, len+1);
if (get_sha1_hex(name, sha1) < 0)
break;
- add_sha1_list(sha1, de->d_ino);
+ add_sha1_list(sha1, DIRENT_SORT_HINT(de));
continue;
}
fprintf(stderr, "bad sha1 file: %s/%s\n", path, de->d_name);
--
1.1.3-gacdd
^ permalink raw reply related
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Junio C Hamano @ 2006-01-20 1:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Christopher Faylor
In-Reply-To: <81b0412b0601180547q4a812c8xb632de6ab13a5e62@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> For reasons unknown, cygwin decided to use our sockaddr_storage.
> As it is redefined to sockaddr_in it'd cause compilation errors in
> cygwin headers.
Just removing "-Dsockaddr_storage=sockaddr_in" from ALL_CFLAGS
seems to solve the problem for new Cygwin.
I doubt that -Dsockaddr_storage=sockaddr_in should be tied to
NO_IPV6. Maybe a better approach would be something like the
attached patch.
Although /usr/include/cygwin/in.h seems to have struct sockaddr_in6,
getaddrinfo() and friends still do not seem to be there, so
NO_IPV6 still remains in effect on Cygwin.
Comments?
-- >8 --
[PATCH] Makefile: do not assume lack of IPV6 means no sockaddr_storage.
Noticed first by Alex, that the latest Cygwin now properly has
sockaddr_storage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Makefile | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
0b61a10bb258ae0971bce3e01e40a5a9e5d9537f
diff --git a/Makefile b/Makefile
index f6d9e0a..e8f4b24 100644
--- a/Makefile
+++ b/Makefile
@@ -42,6 +42,9 @@ all:
#
# Define NO_IPV6 if you lack IPv6 support and getaddrinfo().
#
+# Define NO_SOCKADDR_STORAGE if your platform does not have struct
+# sockaddr_storage.
+#
# Define COLLISION_CHECK below if you believe that SHA1's
# 1461501637330902918203684832716283019655932542976 hashes do not give you
# sufficient guarantee that no collisions between objects will ever happen.
@@ -342,7 +345,14 @@ ifdef NO_MMAP
COMPAT_OBJS += compat/mmap.o
endif
ifdef NO_IPV6
- ALL_CFLAGS += -DNO_IPV6 -Dsockaddr_storage=sockaddr_in
+ ALL_CFLAGS += -DNO_IPV6
+endif
+ifdef NO_SOCKADDR_STORAGE
+ifdef NO_IPV6
+ ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in
+else
+ ALL_CFLAGS += -Dsockaddr_storage=sockaddr_in6
+endif
endif
ifdef PPC_SHA1
--
1.1.3-gacdd
^ permalink raw reply related
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Junio C Hamano @ 2006-01-20 1:13 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119222553.GB7567@trixie.casa.cgf.cx>
Christopher Faylor <me@cgf.cx> writes:
> Inodes are only calculated by hashing the path name when the OS lacks
> the support to provide a "real" inode and in that case there is no hard
> link support available so it's a non-issue.
Does that mean on such filesystems "mv foo bar" would change the
i-num of the moved entity?
I am not complaining even if that is the case. I just want to
understand what it does.
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Junio C Hamano @ 2006-01-20 1:13 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060119221346.GC3601@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> Maybe just wait for 3 (three) seconds? It should guarantee the change
> in mtime.
That is certainly an easy way out. Unless somebody comes up
with more simple and elegant solution I'd opt for this.
^ permalink raw reply
* Re: [PATCH] local push/pull env cleanup
From: Junio C Hamano @ 2006-01-20 1:13 UTC (permalink / raw)
To: Matt Draisey; +Cc: git
In-Reply-To: <20060119205803.308.78669.stgit@della.draisey.ca>
Matt Draisey <matt@draisey.ca> writes:
> From: Matt Draisey <matt@draisey.ca>
>
> remove environment variables relating to the current repository
> before execing the 'remote' half of a local push or pull operation
> ---
>
> connect.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index d6f4e4c..50cc879 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -644,8 +644,13 @@ int git_connect(int fd[2], char *url, co
> ssh_basename++;
> execlp(ssh, ssh_basename, host, command, NULL);
> }
> - else
> + else {
> + unsetenv("GIT_DIR");
> + unsetenv("GIT_INDEX_FILE");
> + unsetenv("GIT_OBJECT_DIRECTORY");
> + unsetenv("GIT_ALTERNATE_OBJECT_DIRECTORIES");
> execlp("sh", "sh", "-c", command, NULL);
> + }
> die("exec failed");
> }
> fd[0] = pipefd[0][0];
There are platforms that lack unsetenv(3C), so you also need an
emulation similar to what we do for setenv(3) in
compat/setenv.c.
I suspect GIT_DIR is automatically set up by enter_repo on the
other side when upload-pack (for fetch case) or receive-pack
(for push case) is run, so that may not be necessary, but
cleaning it along with others here sounds sane, even if only for
consistency's sake.
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 22:51 UTC (permalink / raw)
To: Alex Riesen, git
In-Reply-To: <20060119220843.GA3601@steel.home>
On Thu, Jan 19, 2006 at 11:08:43PM +0100, Alex Riesen wrote:
>Christopher Faylor, Thu, Jan 19, 2006 19:31:43 +0100:
>>Hmm. I thought we'd already dispelled the myth that cygwin is
>>unsupported in this very mailing list. That is an odd impression given
>>the fact that you were complaining about behavior in a version of
>>cygwin which was released on Monday but, apology accepted.
>
>It was my first update since a long time (which BTW broke some programs
>like cp: they missed symbols in cygwin1.dll).
Detailed bug reports are always welcome on the cygwin mailing list:
cygwin at cygwin dot com . I should point out that the existence of
bugs in a product does not indicate a lack of support of the product,
however.
>Maybe it'd be a good idea just to remove the definitions? Or, as
>__INSIDE_CYGWIN__ implies, move them into cygwin internal sources.
>Would be less confusion and no chance of someone defining one of the
>macros and getting a binary-incompatible object?
I sincerely doubt that anyone in this mailing list wants to get into a
discussion of cygwin design. If you really want to discuss this, the
cygwin mailing list is a much better place for that.
cgf
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Christopher Faylor @ 2006-01-19 22:25 UTC (permalink / raw)
To: git
In-Reply-To: <20060119221227.GB3601@steel.home>
On Thu, Jan 19, 2006 at 11:12:27PM +0100, Alex Riesen wrote:
>Christopher Faylor, Thu, Jan 19, 2006 19:28:22 +0100:
>>>>By the way, if you have an access to git on cygwin with FAT, could you
>>>>test your patch ($SECONDS) and then i-num patch (the machine with
>>>>cygwin I can borrow has only NTFS) please?
>>>
>>>Works if sleep is for 2 secs (I completely forgot about that stupid FAT
>>>granularity!) st_ino is always the same (it is a hash of pathname).
>>>Christopher, how is that supposed to work with hardlinks? (NTFS has
>>>hardlinks, BTW)
>>
>>There is OS support hardlinks work on NTFS/NT but not on FAT*
>>"filesystems" or Windows 9x variants. Hardlink support on Cygwin
>>mirrors this.
>
>No, I rephrase the question: how does the method of calculating .st_ino
>from pathname handles hardlinked files on NTFS? By briefly looking at
>the code it does not seem to be possible.
Cygwin doesn't create an inode from the path name on NTFS. NT gives you
a 64 bit unique number which identifies a file so we use that. That
means that the inodes of hardlinked files should be the same, just like
on linux.
Inodes are only calculated by hashing the path name when the OS lacks
the support to provide a "real" inode and in that case there is no hard
link support available so it's a non-issue.
cgf
^ permalink raw reply
* Re: /etc in git?
From: Daniel Barkalow @ 2006-01-19 22:22 UTC (permalink / raw)
To: Adam Hunt; +Cc: Junio C Hamano, git
In-Reply-To: <7v64ogkdtu.fsf@assigned-by-dhcp.cox.net>
On Wed, 18 Jan 2006, Junio C Hamano wrote:
> Adam Hunt <kinema@gmail.com> writes:
>
> > Do you have any more details by chance? Does it work? Does it work
> > well? How does one do it?
>
> I personally feel it is a horrible and stupid thing to do, if by
> "version control /etc" you mean to have /.git which controls
> /etc/hosts and stuff in place. It would work (git does not
> refuse to run as root). But being a *source* control system, we
> deliberately refuse to store the full permission bits, so if
> your /etc/shadow is mode 0600 while /etc/hosts is mode 0644, you
> have to make sure they stay that way after checking things out.
At some point, people considered setting up an object type that would have
all of the bits. That is, if you want a directory to come out literally
the same as it went in, uid/gid/sticky-bit and all, you'd do something
special to make this happen.
I think you could do some nifty stuff where you have git take care of
/etc, and make all your changes to clones of the repository, push them,
and check them out. I bet you could even have three-way merge on package
installs this way; install the package into a fake root that has the /etc
generated by the install of the previous version of the package (i.e.,
without your changes), commit that head, then merge that head into your
master branch etc (in a non-real working tree, of course), check over the
result, commit, push to the real repository, and check out. For that
matter, you could probably generate the "package added replacing previous
package" commit without using a working tree, directly from the package.
(Sure, it's currently set up for source control only, but the original
theory was general content, and it should be good at producing exactly the
right directory structure if it had a type to represent exact stuff like
that)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Alex Riesen @ 2006-01-19 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git, Christopher Faylor
In-Reply-To: <7vr774dqjo.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Thu, Jan 19, 2006 19:24:27 +0100:
>
> > Works if sleep is for 2 secs (I completely forgot about that stupid
> > FAT granularity!)
> > st_ino is always the same (it is a hash of pathname).
> > Christopher, how is that supposed to work with hardlinks? (NTFS has
> > hardlinks, BTW)
>
> So the verdict is to take your patch but wait for three seconds?
> I still have mild aversion about $SECONDS though...
>
Maybe just wait for 3 (three) seconds? It should guarantee the change
in mtime.
^ permalink raw reply
* Re: [PATCH] "sleep 1" sleeps too little on cygwin
From: Alex Riesen @ 2006-01-19 22:12 UTC (permalink / raw)
To: Christopher Faylor; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20060119182822.GA32022@trixie.casa.cgf.cx>
Christopher Faylor, Thu, Jan 19, 2006 19:28:22 +0100:
> >> By the way, if you have an access to git on cygwin with FAT,
> >> could you test your patch ($SECONDS) and then i-num patch (the
> >> machine with cygwin I can borrow has only NTFS) please?
> >
> >Works if sleep is for 2 secs (I completely forgot about that stupid
> >FAT granularity!)
> >st_ino is always the same (it is a hash of pathname).
> >Christopher, how is that supposed to work with hardlinks? (NTFS has
> >hardlinks, BTW)
>
> There is OS support hardlinks work on NTFS/NT but not on FAT*
> "filesystems" or Windows 9x variants. Hardlink support on Cygwin
> mirrors this.
>
No, I rephrase the question: how does the method of calculating
.st_ino from pathname handles hardlinked files on NTFS?
By briefly looking at the code it does not seem to be possible.
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Alex Riesen @ 2006-01-19 22:08 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119183143.GB27888@trixie.casa.cgf.cx>
Christopher Faylor, Thu, Jan 19, 2006 19:31:43 +0100:
> >>"They" probably don't like it when people treat an open source project
> >>as if it was some unresponsive proprietary enterprise which does not
> >>listen to or accept patches.
> >Please, accept my appologies for the sarcasm in the original post.
> >Sometimes I get an impression of cygwin being not maintained at all,
> >and that, if not justifies my behavior, but at least is an attempt to
> >explain it.
>
> Hmm. I thought we'd already dispelled the myth that cygwin is
> unsupported in this very mailing list. That is an odd impression given
> the fact that you were complaining about behavior in a version of cygwin
> which was released on Monday but, apology accepted.
It was my first update since a long time (which BTW broke some
programs like cp: they missed symbols in cygwin1.dll).
> If you want to see evidence of continual cygwin development, you can always
> visit this page: http://cygwin.com/snapshots/ . This page has snapshots
> of cygwin built from cvs. We make these available so that people will check
> things out prior to an actual release.
Thanks.
> >>>And on top of that, they removed dirent->d_ino (or probably replaced it
> >>>by __ino32, if at all). BTW, can we somehow avoid using d_ino? It is
> >>>referenced only in fsck-objects.c Anyway, to workaround this I put
> >>>
> >>>COMPAT_CFLAGS += -Dd_ino=__ino32
> >>>
> >>>It helps, but surely is not the solution.
> >>
> >>I don't see how it could help since __ino32 is not actually filled in
> >>with anything. In fact, I'll rename the field to __invalid_ino32 to
> >>make that clear.
> >
> >But why keep the DT_-macros?! And why there is two fields hinting at
> >d_ino, and why there is 3 (!)
>
> The default entry (i.e., the one you get without defining
> __INSIDE_CYGWIN__ or __CYGWIN_USE_BIG_TYPES__) in dirent.h is the
> correct one.
Maybe it'd be a good idea just to remove the definitions? Or, as
__INSIDE_CYGWIN__ implies, move them into cygwin internal sources.
Would be less confusion and no chance of someone defining one of the
macros and getting a binary-incompatible object?
> >"struct dirent" definitions in dirent.h (sys/dirent.h)? Some with
> >different names (d_reserved?). And if cygwin is aiming for posix, what
> >would d_fd or d_version be (Open Group Specs v6[1] mention only d_ino
> >and d_name)?
> >
> >[1]
> >http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
>
> Hmm. On linux, my /usr/include/bits/dirent.h has a d_reclen field in
> dirent. I know what that is and what it is used for but it's not
> mentioned, that I can see, in SUSv3. But, since I don't see anything in
> the description of dirent in SUSv3 which says that the must have only
> the fields mentiond, that's ok.
Of course, you don't have to. It all about making an impression
> In any event, we don't claim to be POSIX compatible. We actually are
> working for linux compatibility but this is one regrettable place where
> Windows doesn't allow that.
The word was "aiming"
> Anyway, I understand why the DT macros would cause problems and I have
> removed them from the current CVS. I don't see why the existence of
> extra fields in dirent or why other non-default definitions would
> cause any problems other than the "Doctor, doctor, it hurts when I
> do this" variety.
It is not the existance of the extra fields which cause problems. It
is an existance of fields, the names of which imply a functionality
they do not provide which causes problems. Why should I seeing __ino32
in an official header think: "it is never filled anyway, so I
shouldn't use it"?! Or what could "__invalid_d_ino" mean? If it is
invalid (as in "can't be used", why is it there at all?
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 21:51 UTC (permalink / raw)
To: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0601191334390.3240@g5.osdl.org>
On Thu, Jan 19, 2006 at 01:44:58PM -0800, Linus Torvalds wrote:
>
>On Thu, 19 Jan 2006, Christopher Faylor wrote:
>>
>> The only thing that would speed up process creation in cygwin now is
>> the use of the windows spawn* family of function calls. Those could be
>> used instead of fork/exec but I have a personal aversion to using them
>> since they are so non-UNIX. If performance is an issue, however, that
>> could be something to investigate.
>
>What about posix_spawn()? I don't know the windows spawn things, but I
>assume posix_spawn() is basically trying to be them.. Does it work with
>cygwin if we try to convert some of the more obvious users?
You know, I couldn't remember what the name of the spawn that was
introduced for posix. I was going to mention it in my email and I
forgot. Obviously it was because the name so obscure that no one could
possibly remember it. :-)
We don't emulate posix_spawn currently but we could and should. I'll
put it on the todo list.
cgf
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Linus Torvalds @ 2006-01-19 21:44 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119212856.GA6317@trixie.casa.cgf.cx>
On Thu, 19 Jan 2006, Christopher Faylor wrote:
>
> The only thing that would speed up process creation in cygwin now is
> the use of the windows spawn* family of function calls. Those could be
> used instead of fork/exec but I have a personal aversion to using them
> since they are so non-UNIX. If performance is an issue, however, that
> could be something to investigate.
What about posix_spawn()? I don't know the windows spawn things, but I
assume posix_spawn() is basically trying to be them.. Does it work with
cygwin if we try to convert some of the more obvious users?
Some of the git users should be easy to convert to posix_spawn()..
Linus
^ permalink raw reply
* Re: StGIT: "stg new" vs "stg new --force"
From: Yann Dirson @ 2006-01-19 21:38 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Catalin Marinas, git, Charles Lever
In-Reply-To: <1137631749.13853.22.camel@dv>
On Wed, Jan 18, 2006 at 07:49:09PM -0500, Pavel Roskin wrote:
> > But it would not be a replacement to selecting changes with a
> > granularity finer than file-level, which is what I wanted to suggest.
>
> Why? Maybe you got confused by two meanings of the word "patch"? I
> think StGIT should use some other term, e.g. changeset. I meant that
> the diff file (e.g. made by "stg diff") could be edited and folded into
> one of the StGIT patches (changesets). Unless you want non-interactive
> separation of the hunks, using an editor should be a reasonable
> approach.
> My approach suggests that the user work with the diff from the
> beginning, and separates the changes by looking at them.
Oh, I think I now see what you meant. I'm not sure it would be a good
idea to let the user edit the diff, although running an editor on it
is not much different from feeding it through filterdiff, or a
even through a graphical equivalent allowing to point at the hunks.
> I believe StGIT should be primarily designed to be used interactively.
I tend to disagree. 3rd-party apps like qgit should be able to let
the user do the selection, and tell the command-line tool what they
want to act upon. It may be useful as well if stg gains
interactivity, but should not become the only way to work with it
(unix way of life).
> Your approach looks like a usability disaster to me. The user is
> supposed to find numbers of the hunks, although s/he is working on the
> whole file (since it's "stg refresh").
That's what I'm currently doing to feed the hunk numbers to
filterdiff. Any improvement in the process would be welcomed :)
Maybe we could have a "fold" or "refresh" variant that takes its
output from the output of "stg diff" (or any arbitrary diff on stdin,
to be friendly with GUI wrappers) filtered by an arbitrary command.
That command could be "cat" to get the current "refresh" behaviour, or
an editor wrapper acting on stdin/out, or a wrapper to filterdiff, or
whatever clever filter one would want to use.
Does it sound better ?
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 21:28 UTC (permalink / raw)
To: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.64.0601191309130.3240@g5.osdl.org>
On Thu, Jan 19, 2006 at 01:16:17PM -0800, Linus Torvalds wrote:
>On Thu, 19 Jan 2006, Christopher Faylor wrote:
>>Btw, we're looking to roll out a new release of cygwin which fixes the
>>embarrassing typo in sockaddr_storage. It is fixed in cygwin
>>snapshots:
>>
>>http://cygwin.com/snapshots/
>
>Quick question for cygwin people (I asked this at an earlier point, but
>I don't think there was any reply): would cygwin prefer using "vfork()"
>over "fork()", or is there no advantage? With vfork(), I could imagine
>that you might avoid a lot of strange VM games..
Sorry, I missed the earlier question. I have to get in the habit of
scanning this list more regularly for this type of thing.
Cygwin's vfork implementation currently defaults to fork so it doesn't
matter which is used.
We used to have a vfork which tried to cut down on some of the
substantial overhead that comes with cygwin's fork() but the vfork
implementation eventually grew so complicated that there was eventually
no performance gain and I decided to just yank it and revisit it at
a later point.
So, for now, there is no difference, but, eventually, there might be if
someone masters courage to revisit vfork-on-cygwin.
So, I guess that means that it would be a good idea to switch to vfork
if you were planning for the nebulous future when this made a difference
to cygwin. Otherwise, I wouldn't bother.
>Alternatively, is there anything else we can do that makes things easier?
I'm really committed to making cygwin as much like linux as possible so
that you won't have to make things easier. The last release added some
stuff which should make building linux easier, in fact. Also, the
mmap() implementation should be a littler closer to linux. It is, of
course, a work in progress, though.
The only thing that would speed up process creation in cygwin now is
the use of the windows spawn* family of function calls. Those could be
used instead of fork/exec but I have a personal aversion to using them
since they are so non-UNIX. If performance is an issue, however, that
could be something to investigate.
cgf
^ permalink raw reply
* [PATCH] Unclutter cg status with --directory as GIT does
From: Paolo 'Blaisorblade' Giarrusso @ 2006-01-19 21:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Pass the new --directory option (from git 1.1) to git-ls-others for
list_untracked_files, as does git-status - it's very useful.
Probably this must be deferred to when the git 1.1 dependency is added, however
please queue it for then.
Thanks.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 30e2ee9..539c885 100755
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -206,7 +206,7 @@ list_untracked_files()
fi
EXCLUDE="$EXCLUDE --exclude-per-directory=.gitignore"
fi
- git-ls-files -z --others $EXCLUDE
+ git-ls-files -z --others --directory $EXCLUDE
}
# Usage: showdate SECONDS TIMEZONE [FORMAT]
^ permalink raw reply related
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Linus Torvalds @ 2006-01-19 21:16 UTC (permalink / raw)
To: Christopher Faylor; +Cc: git
In-Reply-To: <20060119203428.GA5090@trixie.casa.cgf.cx>
On Thu, 19 Jan 2006, Christopher Faylor wrote:
>
> Btw, we're looking to roll out a new release of cygwin which fixes the
> embarrassing typo in sockaddr_storage. It is fixed in cygwin snapshots:
>
> http://cygwin.com/snapshots/
Quick question for cygwin people (I asked this at an earlier point, but I
don't think there was any reply): would cygwin prefer using "vfork()" over
"fork()", or is there no advantage? With vfork(), I could imagine that you
might avoid a lot of strange VM games..
I think almost all of the git fork usage is of the type where "vfork()"
would work fine (git-daemon in non-inetd form is an exception, perhaps the
only one).
So if using vfork() is preferable, we probably should do that. It tends to
be a small performance improvement on Linux too, although on Linux it's
really pretty much in the noise.
Alternatively, is there anything else we can do that makes things easier?
Linus
^ permalink raw reply
* [PATCH] local push/pull env cleanup
From: Matt Draisey @ 2006-01-19 20:58 UTC (permalink / raw)
To: git
From: Matt Draisey <matt@draisey.ca>
remove environment variables relating to the current repository
before execing the 'remote' half of a local push or pull operation
---
connect.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/connect.c b/connect.c
index d6f4e4c..50cc879 100644
--- a/connect.c
+++ b/connect.c
@@ -644,8 +644,13 @@ int git_connect(int fd[2], char *url, co
ssh_basename++;
execlp(ssh, ssh_basename, host, command, NULL);
}
- else
+ else {
+ unsetenv("GIT_DIR");
+ unsetenv("GIT_INDEX_FILE");
+ unsetenv("GIT_OBJECT_DIRECTORY");
+ unsetenv("GIT_ALTERNATE_OBJECT_DIRECTORIES");
execlp("sh", "sh", "-c", command, NULL);
+ }
die("exec failed");
}
fd[0] = pipefd[0][0];
^ permalink raw reply related
* Re: cygwin-latest: compile errors related to sockaddr_storage, dirent->d_type and dirent->d_ino
From: Christopher Faylor @ 2006-01-19 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060119161000.GA27888@trixie.casa.cgf.cx>
On Thu, Jan 19, 2006 at 11:10:00AM -0500, Christopher Faylor wrote:
>On Thu, Jan 19, 2006 at 12:59:57AM -0800, Junio C Hamano wrote:
>>Christopher Faylor <me@cgf.cx> writes:
>>>"They" probably would like to hear about any irregularities that are
>>>found. "They" probably don't like it when people treat an open source
>>>project as if it was some unresponsive proprietary enterprise which
>>>does not listen to or accept patches.
>>
>>First of all, thanks for joining our discussion.
>
>You're welcome. I use git on linux and cygwin so I'm happy to try to help.
Btw, we're looking to roll out a new release of cygwin which fixes the
embarrassing typo in sockaddr_storage. It is fixed in cygwin snapshots:
http://cygwin.com/snapshots/
cgf
^ 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