* [PATCH 1/2] stat_tracking_info(): only count real commits
From: Kjetil Barvik @ 2009-03-04 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kjetil Barvik
In-Reply-To: <cover.1236187259.git.barvik@broadpark.no>
stat_tracking_info() in remote.c is used to collect the statistics to
be able to say (for instance) from the output of "git checkout':
Your branch and 'foo' have diverged,
and have X and Y different commit(s) each, respectively.
Currently X and Y also includes the count of merges. This patch
excludes the merges from being counted.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
I hope this is a correct fix, and that it is realy a bugfix.
~~
By the way, I have noticed that when the Y number above is large
(for instance for a branch I have where Y is ~ 600), then the
function get_merge_bases_many() and in particular merge_bases_many()
in commit.c will take a noticable amount of user time (aprox 0.4
seconds). So if the chekcout results in that few files need to be
updated (< 10), this will sometimes acount for much of the total
time needed for the 'git checkout' command.
It seems that even though only max 4000 or so unique commits is
touched (when Y ~ 600), each commit is touched over 250 times, for
instancce by the insert_by_date() function inside the while-loop in
merge_bases_many().
Do someone think it is possible to have a better algorithm here?
Maybe O(Nlog(n)) or better? Does someone has a hint about how to
make it better?
remote.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/remote.c b/remote.c
index d7079c6..06c414e 100644
--- a/remote.c
+++ b/remote.c
@@ -1310,9 +1310,10 @@ int stat_tracking_info(struct branch *branch, int *num_ours, int *num_theirs)
if (theirs == ours)
return 0;
- /* Run "rev-list --left-right ours...theirs" internally... */
+ /* Run "rev-list --no-merges --left-right ours...theirs" internally... */
rev_argc = 0;
rev_argv[rev_argc++] = NULL;
+ rev_argv[rev_argc++] = "--no-merges";
rev_argv[rev_argc++] = "--left-right";
rev_argv[rev_argc++] = symmetric;
rev_argv[rev_argc++] = "--";
--
1.6.1.GIT
^ permalink raw reply related
* [PATCH 2/2] better introduction of GIT with USE_NSEC defined
From: Kjetil Barvik @ 2009-03-04 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kjetil Barvik
In-Reply-To: <cover.1236187259.git.barvik@broadpark.no>
Change the source code such that when USE_NSEC is not defined,
possible nanosecond timestamps will still be saved in the index file,
but not used inside if-test's, and will therefore not affect the
outcome of GIT commands, other than the saved nanosecond timestamps in
the index file.
This will make it easier to use a system with 2 versions of GIT, one
with and one without USE_NSEC defined.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
read-cache.c | 23 +----------------------
unpack-trees.c | 2 --
2 files changed, 1 insertions(+), 24 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 91f1d03..7fca804 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -69,13 +69,8 @@ void fill_stat_cache_info(struct cache_entry *ce, struct stat *st)
{
ce->ce_ctime.sec = (unsigned int)st->st_ctime;
ce->ce_mtime.sec = (unsigned int)st->st_mtime;
-#ifdef USE_NSEC
ce->ce_ctime.nsec = (unsigned int)st->st_ctim.tv_nsec;
ce->ce_mtime.nsec = (unsigned int)st->st_mtim.tv_nsec;
-#else
- ce->ce_ctime.nsec = 0;
- ce->ce_mtime.nsec = 0;
-#endif
ce->ce_dev = st->st_dev;
ce->ce_ino = st->st_ino;
ce->ce_uid = st->st_uid;
@@ -1183,13 +1178,8 @@ static void convert_from_disk(struct ondisk_cache_entry *ondisk, struct cache_en
ce->ce_ctime.sec = ntohl(ondisk->ctime.sec);
ce->ce_mtime.sec = ntohl(ondisk->mtime.sec);
-#ifdef USE_NSEC
ce->ce_ctime.nsec = ntohl(ondisk->ctime.nsec);
ce->ce_mtime.nsec = ntohl(ondisk->mtime.nsec);
-#else
- ce->ce_ctime.nsec = 0;
- ce->ce_mtime.nsec = 0;
-#endif
ce->ce_dev = ntohl(ondisk->dev);
ce->ce_ino = ntohl(ondisk->ino);
ce->ce_mode = ntohl(ondisk->mode);
@@ -1308,12 +1298,8 @@ int read_index_from(struct index_state *istate, const char *path)
src_offset += ondisk_ce_size(ce);
dst_offset += ce_size(ce);
}
- istate->timestamp.sec = st.st_mtime;
-#ifdef USE_NSEC
+ istate->timestamp.sec = (unsigned int)st.st_mtime;
istate->timestamp.nsec = (unsigned int)st.st_mtim.tv_nsec;
-#else
- istate->timestamp.nsec = 0;
-#endif
while (src_offset <= mmap_size - 20 - 8) {
/* After an array of active_nr index entries,
@@ -1500,13 +1486,8 @@ static int ce_write_entry(git_SHA_CTX *c, int fd, struct cache_entry *ce)
ondisk->ctime.sec = htonl(ce->ce_ctime.sec);
ondisk->mtime.sec = htonl(ce->ce_mtime.sec);
-#ifdef USE_NSEC
ondisk->ctime.nsec = htonl(ce->ce_ctime.nsec);
ondisk->mtime.nsec = htonl(ce->ce_mtime.nsec);
-#else
- ondisk->ctime.nsec = 0;
- ondisk->mtime.nsec = 0;
-#endif
ondisk->dev = htonl(ce->ce_dev);
ondisk->ino = htonl(ce->ce_ino);
ondisk->mode = htonl(ce->ce_mode);
@@ -1583,9 +1564,7 @@ int write_index(struct index_state *istate, int newfd)
if (ce_flush(&c, newfd) || fstat(newfd, &st))
return -1;
istate->timestamp.sec = (unsigned int)st.st_ctime;
-#ifdef USE_NSEC
istate->timestamp.nsec = (unsigned int)st.st_ctim.tv_nsec;
-#endif
return 0;
}
diff --git a/unpack-trees.c b/unpack-trees.c
index 9fe0cd5..da2e3c0 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -362,9 +362,7 @@ int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options
o->result.initialized = 1;
if (o->src_index) {
o->result.timestamp.sec = o->src_index->timestamp.sec;
-#ifdef USE_NSEC
o->result.timestamp.nsec = o->src_index->timestamp.nsec;
-#endif
}
o->merge_size = len;
--
1.6.1.GIT
^ permalink raw reply related
* [PATCH 0/2] some few more 'git checkout' improvements
From: Kjetil Barvik @ 2009-03-04 17:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Kjetil Barvik
- one bugfix (I hope)
- and one patch to make life easier when using the USE_NSEC define
These 2 patches is based on 'next' because patch 2/2 is based on one
previous patch, which is only in 'next' for the moment.
Kjetil Barvik (2):
stat_tracking_info(): only count real commits
better introduction of GIT with USE_NSEC defined
read-cache.c | 23 +----------------------
remote.c | 3 ++-
unpack-trees.c | 2 --
3 files changed, 3 insertions(+), 25 deletions(-)
^ permalink raw reply
* Re: Strange push/clone errors
From: Tim Visher @ 2009-03-04 17:37 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: git
In-Reply-To: <20090304143938.GB12901@vidovic>
On Wed, Mar 4, 2009 at 9:39 AM, Nicolas Sebrecht
<nicolas.s-dev@laposte.net> wrote:
>
> On Wed, Mar 04, 2009 at 09:01:51AM -0500, Tim Visher wrote:
>
>> As you can see, v1.6.2 and v1.6.2-rc2 are missing from the repo that
>> I'm pushing to on my thumb drive, despite it claiming it's up to date.
>>
>> What am I doing wrong?
>
> You need to push the tags using the --tags option of git-push (when
> pushing to your sandbox repository).
Thank you, Nicolas! I actually discovered the `--mirror` option.
Since that's basically what I'm trying to do, that's what I ended up
going with. It appears to be working.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] Make the 'lock file exists' error more informative
From: Matthieu Moy @ 2009-03-04 15:54 UTC (permalink / raw)
To: John Tapsell; +Cc: git
In-Reply-To: <1236179277-12477-1-git-send-email-johnflux@gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> It looks like someone did 90% of the work, then forgot to actually use
> the function
someone = me ;-).
The message is a bit inacurrate: the function is already used in two
places, I just didn't notice this one.
> - if (errno == EEXIST) {
> + if (err == EEXIST) {
Oops, right.
> - die("unable to create '%s.lock': %s", path, strerror(errno));
> + unable_to_lock_index_die(path, errno);
Actually, _this_ instance is still to be fixed in next. You probably
looked at the other one that my original message fixes.
IOW:
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
--
Matthieu
^ permalink raw reply
* I want to suggest this page to you
From: John @ 2009-03-04 15:42 UTC (permalink / raw)
To: git
Amazing list of sale coupons! http://erhtd.greatsalesgroup.com/sale.php
^ permalink raw reply
* Re: Lock binairy files in Git
From: Michael Hendricks @ 2009-03-04 15:41 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1236175008046-2422894.post@n2.nabble.com>
On Wed, Mar 04, 2009 at 05:56:48AM -0800, Henk wrote:
> In our current version control system we lock binairy files when we
> edit them. This way other developers know when a file is being
> edited. Is there something simular in Git? Or is there another
> method to let others now I am currently editing a file?
>
> We need this only for binairy files, because they cannot be merged.
You can't lock files, but perhaps you could specify a custom merge
driver to define how those files should be "merged" (for whatever
definition you choose). See
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
for details.
--
Michael
^ permalink raw reply
* [PATCH] Clarify the "cannot lock existing info/refs" error
From: John Tapsell @ 2009-03-04 15:37 UTC (permalink / raw)
To: git; +Cc: John Tapsell
---
http-push.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/http-push.c b/http-push.c
index 30d2d34..6666956 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2293,7 +2293,7 @@ int main(int argc, char **argv)
if (info_ref_lock)
remote->can_update_info_refs = 1;
else {
- fprintf(stderr, "Error: cannot lock existing info/refs\n");
+ error("cannot lock existing info/refs on remote server\nPerhaps the server is currently busy, or your ~/.netrc file is not configured correctly.");
rc = 1;
goto cleanup;
}
--
1.6.2.rc2.23.g77740
^ permalink raw reply related
* Re: [PATCH] Make the 'lock file exists' error more informative
From: John Tapsell @ 2009-03-04 15:18 UTC (permalink / raw)
To: git
In-Reply-To: <1236179277-12477-1-git-send-email-johnflux@gmail.com>
2009/3/4 John Tapsell <johnflux@gmail.com>:
> It looks like someone did 90% of the work, then forgot to actually use
> the function
It seems that this was already fixed in the 'next' branch. (Sorry, I
didn't know about this branch before).
The first bug fix is still required. (well, for niceness. In
practise it isn't)
John Tapsell
> ---
> lockfile.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/lockfile.c b/lockfile.c
> index 1db1a2f..3dbb2d1 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -158,7 +158,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
>
> NORETURN void unable_to_lock_index_die(const char *path, int err)
> {
> - if (errno == EEXIST) {
> + if (err == EEXIST) {
> die("Unable to create '%s.lock': %s.\n\n"
> "If no other git process is currently running, this probably means a\n"
> "git process crashed in this repository earlier. Make sure no other git\n"
> @@ -184,7 +184,7 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
> fd = lock_file(lk, path, flags);
> if (fd < 0) {
> if (flags & LOCK_DIE_ON_ERROR)
> - die("unable to create '%s.lock': %s", path, strerror(errno));
> + unable_to_lock_index_die(path, errno);
> return fd;
> }
>
> --
> 1.6.2.rc2.23.g77740
>
>
^ permalink raw reply
* [PATCH] Make the 'lock file exists' error more informative
From: John Tapsell @ 2009-03-04 15:07 UTC (permalink / raw)
To: git; +Cc: John Tapsell
It looks like someone did 90% of the work, then forgot to actually use
the function
---
lockfile.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 1db1a2f..3dbb2d1 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -158,7 +158,7 @@ static int lock_file(struct lock_file *lk, const char *path, int flags)
NORETURN void unable_to_lock_index_die(const char *path, int err)
{
- if (errno == EEXIST) {
+ if (err == EEXIST) {
die("Unable to create '%s.lock': %s.\n\n"
"If no other git process is currently running, this probably means a\n"
"git process crashed in this repository earlier. Make sure no other git\n"
@@ -184,7 +184,7 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
fd = lock_file(lk, path, flags);
if (fd < 0) {
if (flags & LOCK_DIE_ON_ERROR)
- die("unable to create '%s.lock': %s", path, strerror(errno));
+ unable_to_lock_index_die(path, errno);
return fd;
}
--
1.6.2.rc2.23.g77740
^ permalink raw reply related
* [PATCH] allow guilt to handle binary files
From: Yasushi SHOJI @ 2009-03-04 14:19 UTC (permalink / raw)
To: jeffpc; +Cc: git
git plumbings has been working with binary diff for a while. this one
liner enable guilt to use those capabilities.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
Hi Jeff,
I just found out that guilt does not yet support binary patch
capability git has for a while.
so, before I leave my office, I just tried guilt with this one liner.
the result was:
- my local test with biniary files work (pop/push was check with md5), and
- all regression test completed without any error
I felt that I just send it out. :-)
# Note: I've googled "guilt bianry" before sending this but could not
# find any. I'm not following nether git nor guilt development for a
# while. so, let me know if I'm off track.
thanks,
guilt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/guilt b/guilt
index c98fd30..17a6288 100755
--- a/guilt
+++ b/guilt
@@ -689,7 +689,7 @@ __refresh_patch()
fi
# get the new patch
- git diff $diffopts "$2" >> "$TMP_DIFF"
+ git diff --binary $diffopts "$2" >> "$TMP_DIFF"
# move the new patch in
mv "$p" "$p~"
--
1.6.1.rc3.51.g5832d
^ permalink raw reply related
* Re: [PATCH] Make the 'lock file' exists error more informative
From: John Tapsell @ 2009-03-04 15:03 UTC (permalink / raw)
To: git
In-Reply-To: <1236178844-7958-1-git-send-email-johnflux@gmail.com>
Argh, I'm so sorry. After all that, I went and sent a broken version.
Plus I just noticed another bug. Will retry..
2009/3/4 John Tapsell <johnflux@gmail.com>:
> It looks like someone did 90% of the work, then forgot to actually use
> the function
> ---
> lockfile.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/lockfile.c b/lockfile.c
> index 1db1a2f..6772f38 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -184,7 +184,7 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
> fd = lock_file(lk, path, flags);
> if (fd < 0) {
> if (flags & LOCK_DIE_ON_ERROR)
> - die("unable to create '%s.lock': %s", path, strerror(errno));
> + unable_to_lock_index_die(path, strerror(errno));
> return fd;
> }
>
> --
> 1.6.2.rc1.3.g7d31b.dirty
>
>
^ permalink raw reply
* [PATCH] Make the 'lock file' exists error more informative
From: John Tapsell @ 2009-03-04 15:00 UTC (permalink / raw)
To: git; +Cc: John Tapsell
It looks like someone did 90% of the work, then forgot to actually use
the function
---
lockfile.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 1db1a2f..6772f38 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -184,7 +184,7 @@ int hold_lock_file_for_append(struct lock_file *lk, const char *path, int flags)
fd = lock_file(lk, path, flags);
if (fd < 0) {
if (flags & LOCK_DIE_ON_ERROR)
- die("unable to create '%s.lock': %s", path, strerror(errno));
+ unable_to_lock_index_die(path, strerror(errno));
return fd;
}
--
1.6.2.rc1.3.g7d31b.dirty
^ permalink raw reply related
* Re: Strange push/clone errors
From: Nicolas Sebrecht @ 2009-03-04 14:39 UTC (permalink / raw)
To: Tim Visher; +Cc: git
In-Reply-To: <c115fd3c0903040601xbfce200q78c53aeee0b44f2c@mail.gmail.com>
On Wed, Mar 04, 2009 at 09:01:51AM -0500, Tim Visher wrote:
> As you can see, v1.6.2 and v1.6.2-rc2 are missing from the repo that
> I'm pushing to on my thumb drive, despite it claiming it's up to date.
>
> What am I doing wrong?
You need to push the tags using the --tags option of git-push (when
pushing to your sandbox repository).
--
Nicolas Sebrecht
^ permalink raw reply
* Re: can not clone via git:// anymore
From: Jeff King @ 2009-03-04 14:24 UTC (permalink / raw)
To: Hinko Kocevar; +Cc: Michael J Gruber, git
In-Reply-To: <49AE8208.7090204@cetrtapot.si>
On Wed, Mar 04, 2009 at 02:28:40PM +0100, Hinko Kocevar wrote:
> git-daemon was/is running:
>
> CETRTAPOT\zidarhw@zidar:~$ ps -ef | grep git
> root 3207 1 0 14:15 ? 00:00:00 runsvdir -P /etc/service log: d user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?
> root 3208 3207 0 14:15 ? 00:00:00 runsv git-daemon
> root 3373 3208 0 14:16 ? 00:00:00 git-daemon --verbose --base-path=/var/cache /var/cache/git
> 11418 3399 2762 0 14:16 pts/0 00:00:00 grep git
See all the runsvdir errors? That probably means that git-daemon's log
output is going nowhere, since the log is not running. Which means
eventually the pipe from git-daemon to the log will get full, and
git-daemon will block writing out the log. And then stop dealing with
requests.
So even if restarting helps now, it may fill up again unless you fix the
logging problem (presumably by creating the right "gitlog" user).
-Peff
^ permalink raw reply
* Re: [RFC PATCH] Windows: Assume all file names to be UTF-8 encoded.
From: Dmitry Potapov @ 2009-03-04 14:18 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0903041149250.8926@perkele.intern.softwolves.pp.se>
On Wed, Mar 04, 2009 at 11:51:15AM +0100, Peter Krefting wrote:
> The problem with changing wchar_t is that_
> it was defined to use 16-bit values at a time where Unicode was defined_
> to use 16-bit code points (but they soon figured out that was not_
> enough).
I do realize that is a problem, and unfortunately there is no easy and
quick fix to it. But you brought Windows as an example of good Unicode
support... Well, to my mind, it is not, at least, not for C programs.
You have two serious problems here:
1. wchar_t is too small to hold all Unicode characters as it is required
by C standard.
2. UTF-8 support is broken in C runtime library.
In fact, if UTF-8 were supported by C runtime, we would not have this thread
in the first place... Now, it is possible to wrap all C functions used by Git to
make them work with UTF-8, but it is a lot of work...
Dmitry
^ permalink raw reply
* Re: Lock binairy files in Git
From: Johannes Schindelin @ 2009-03-04 14:15 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1236175008046-2422894.post@n2.nabble.com>
Hi,
On Wed, 4 Mar 2009, Henk wrote:
> In our current version control system we lock binairy files when we edit
> them. This way other developers know when a file is being edited.
No, you cannot. Git is distributed, and therefore what you want is
fundamentally impossible.
You can write hooks, however, enforcing "locks", and make your users
install them.
But due to the fundamental impossibility of the thing, you have to risk
that this scenario fails.
It might be better to come up with a non-tool solution to the problem,
i.e. appointing people responsible for a certain set of your binary files.
That is outside the purview of Git, though.
Ciao,
Dscho
^ permalink raw reply
* Strange push/clone errors
From: Tim Visher @ 2009-03-04 14:01 UTC (permalink / raw)
To: git
Hello Everyone,
I'm trying to maintain an offline copy of the Git repo for our Sandbox
environment at work and I just came across and oddity in the behavior
I'd expect.
I have a repo on an Internet enabled machine that is a direct clone of
the kernel.org version.
$ git show remote origin
* remote origin
URL: http://www.kernel.org/pub/scm/git/git.git
Remote branch merged with 'git pull' while on branch master
master
Tracked remote branches
html
maint
man
master
next
pu
todo
I then have a repo on a thumb drive that's initially a `clone --bare`
of the repo on the Internet enabled machine. I added that as a remote
on the previously mentioned repo.
$ git remote show sandbox
* remote sandbox
URL: /cygdrive/f/Documents/git.git/
Tracked remote branch
master
When I do a `git push sandbox master` I get the following
$ git push sandbox master
Everything up-to-date
The problem is here. Now that I have a supposedly up to date copy on
my thumb drive, I'd like to be able to push it out to a central server
on our Sandbox network. However, when I do a git clone, tags are
missing.
$ git clone /cygdrive/f/Documents/git.git/
Initialized empty Git repository in /home/tvishe01/Desktop/git/.git/
Checking out files: 100% (1589/1589), done.
$ cd git/
$ git tag
...
v1.6.1.3
v1.6.2-rc0
v1.6.2-rc1
Doing the same thing in the repo connected to kernel.org I get:
$ git tag
v1.6.1.3
v1.6.2
v1.6.2-rc0
v1.6.2-rc1
v1.6.2-rc2
As you can see, v1.6.2 and v1.6.2-rc2 are missing from the repo that
I'm pushing to on my thumb drive, despite it claiming it's up to date.
What am I doing wrong?
Thanks in advance!
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Lock binairy files in Git
From: Henk @ 2009-03-04 13:56 UTC (permalink / raw)
To: git
In our current version control system we lock binairy files when we edit
them. This way other developers know when a file is being edited. Is there
something simular in Git? Or is there another method to let others now I am
currently editing a file?
We need this only for binairy files, because they cannot be merged.
Henk
--
View this message in context: http://n2.nabble.com/Lock-binairy-files-in-Git-tp2422894p2422894.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: can not clone via git:// anymore
From: Hinko Kocevar @ 2009-03-04 13:28 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <49AE7B23.1070008@drmicha.warpmail.net>
Michael J Gruber wrote:
> Hinko Kocevar venit, vidit, dixit 04.03.2009 12:24:
>> Hi,
>>
>> I've recently discovered that my GIT repository is not letting me clone it via git clone git://.
>> It works using git clone git@.. (SSH) but with GIT protocol..
>>
>> Here is the case:
>> hinkok@alala /tmp $ git --version
>> git version 1.6.0.6
>> hinkok@alala /tmp $ git clone git://zidar/sdk.git
>> Initialized empty Git repository in /tmp/sdk/.git/
>> fatal: The remote end hung up unexpectedly
>>
>> My earlier clone (few months old) has this in .git/config:
>> hinkok@alala /work/git/sdk.git $ cat .git/config
>> [core]
>> repositoryformatversion = 0
>> filemode = true
>> bare = false
>> logallrefupdates = true
>> [remote "origin"]
>> url = git@zidar:repositories/sdk.git
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>>
>>
>> But I remember cloning via SSH that time, because I needed git push to work,
>> but now other developer do not need the SSH access, but only GIT read-only -
>> they can only clone, not push.
>>
>> I do not administer the server git repos is located on, so I must have some
>> information before I attack the admin..
>
> Sorry in case this is trivial, but has git: access ever worked? It
It did. I found this repos on the server that used git to checkout the repo:
CETRTAPOT\zidarhw@zidar:~$ cat sdk/.git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://zidar/sdk.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
> requires a git daemon running on the server, whereas ssh access does not
> require that. git@zidar:repositories/sdk.git uses ssh access.
>
> Michael
git-daemon was/is running:
CETRTAPOT\zidarhw@zidar:~$ ps -ef | grep git
root 3207 1 0 14:15 ? 00:00:00 runsvdir -P /etc/service log: d user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?chown: invalid user: `gitlog:adm'?
root 3208 3207 0 14:15 ? 00:00:00 runsv git-daemon
root 3373 3208 0 14:16 ? 00:00:00 git-daemon --verbose --base-path=/var/cache /var/cache/git
11418 3399 2762 0 14:16 pts/0 00:00:00 grep git
But after doing:
/etc/init.d/git-daemon stop
/etc/init.d/git-daemon start
Nothing much happened (this is on Ubuntu 8.04.1)!
After a while I managed to get git-daemon to die properly
- '/etc/init.d/git-daemon stop' didn't do that. After
'/etc/init.d/git-daemon start' the git clone git://.. works!
hinkok@alala /tmp $ git clone git://zidar/sdk.git
Initialized empty Git repository in /tmp/sdk/.git/
remote: Counting objects: 62636, done.
remote: Compressing objects: 100% (49201/49201), done.
Receiving objects: 40% (25055/62636), 59.97 MiB | 11069 KiB/s
Thank your for the 'obvious' I haven't checked myself!
Best regards,
Hinko
--
Hinko Kočevar, OSS developer
ČETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel ++386 (0) 4 280 66 03
e-mail hinko.kocevar@cetrtapot.si
http www.cetrtapot.si
^ permalink raw reply
* Re: Subject: [PATCH] Push to create
From: Jay Soffian @ 2009-03-04 13:06 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Shawn O. Pearce, git
In-Reply-To: <20090304054211.GA3753@coredump.intra.peff.net>
On Wed, Mar 4, 2009 at 12:42 AM, Jeff King <peff@peff.net> wrote:
> Now we just need somebody who cares enough about this feature to work on
> it. ;)
I'll see what I can do with the patches Junio sent.
(See Junio, I care enough.) :-)
j.
^ permalink raw reply
* Re: can not clone via git:// anymore
From: Michael J Gruber @ 2009-03-04 12:59 UTC (permalink / raw)
To: Hinko Kocevar; +Cc: git
In-Reply-To: <49AE64F2.1090405@cetrtapot.si>
Hinko Kocevar venit, vidit, dixit 04.03.2009 12:24:
> Hi,
>
> I've recently discovered that my GIT repository is not letting me clone it via git clone git://.
> It works using git clone git@.. (SSH) but with GIT protocol..
>
> Here is the case:
> hinkok@alala /tmp $ git --version
> git version 1.6.0.6
> hinkok@alala /tmp $ git clone git://zidar/sdk.git
> Initialized empty Git repository in /tmp/sdk/.git/
> fatal: The remote end hung up unexpectedly
>
> My earlier clone (few months old) has this in .git/config:
> hinkok@alala /work/git/sdk.git $ cat .git/config
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [remote "origin"]
> url = git@zidar:repositories/sdk.git
> fetch = +refs/heads/*:refs/remotes/origin/*
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
>
> But I remember cloning via SSH that time, because I needed git push to work,
> but now other developer do not need the SSH access, but only GIT read-only -
> they can only clone, not push.
>
> I do not administer the server git repos is located on, so I must have some
> information before I attack the admin..
Sorry in case this is trivial, but has git: access ever worked? It
requires a git daemon running on the server, whereas ssh access does not
require that. git@zidar:repositories/sdk.git uses ssh access.
Michael
^ permalink raw reply
* Re: How does Git know which files no longer needed during upgrade?
From: Jeff King @ 2009-03-04 12:38 UTC (permalink / raw)
To: Stefan Näwe; +Cc: git
In-Reply-To: <loom.20090304T122643-455@post.gmane.org>
On Wed, Mar 04, 2009 at 12:28:07PM +0000, Stefan Näwe wrote:
> > > cd /path/to/copy
> > > rm -rf *
> > > cp -a /path/to/new/version/* .
> > > git add -A
> > > git commit -m 'update foo to 2.0'
> >
> > Nit: "rm -rf *" will miss files starting with '.'. So it is probably
> > simpler to say what you mean: delete all files managed by git:
> >
> > git ls-files -z | xargs -0 rm -f
>
> But maybe one wants to keep a .gitignore file.
True. The problem is that you have no way of saying "give me all the
files that git cares about, except the ones that I put there manually
and not from this tarball." If you guess that dot-files are manual and
everything else isn't, then that is easy, but not necessarily right.
If you tagged the last import, you use "git ls-tree" to get you the list
of files just from the tarball.
-Peff
^ permalink raw reply
* Re: How does Git know which files no longer needed during upgrade?
From: Stefan Näwe @ 2009-03-04 12:28 UTC (permalink / raw)
To: git
In-Reply-To: <20090304094951.GA32433@coredump.intra.peff.net>
Jeff King <peff <at> peff.net> writes:
>
> > cd /path/to/copy
> > rm -rf *
> > cp -a /path/to/new/version/* .
> > git add -A
> > git commit -m 'update foo to 2.0'
>
> Nit: "rm -rf *" will miss files starting with '.'. So it is probably
> simpler to say what you mean: delete all files managed by git:
>
> git ls-files -z | xargs -0 rm -f
>
> -Peff
But maybe one wants to keep a .gitignore file.
Regrads,
Stefan
^ permalink raw reply
* can not clone via git:// anymore
From: Hinko Kocevar @ 2009-03-04 11:24 UTC (permalink / raw)
To: git
Hi,
I've recently discovered that my GIT repository is not letting me clone it via git clone git://.
It works using git clone git@.. (SSH) but with GIT protocol..
Here is the case:
hinkok@alala /tmp $ git --version
git version 1.6.0.6
hinkok@alala /tmp $ git clone git://zidar/sdk.git
Initialized empty Git repository in /tmp/sdk/.git/
fatal: The remote end hung up unexpectedly
My earlier clone (few months old) has this in .git/config:
hinkok@alala /work/git/sdk.git $ cat .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git@zidar:repositories/sdk.git
fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
remote = origin
merge = refs/heads/master
But I remember cloning via SSH that time, because I needed git push to work,
but now other developer do not need the SSH access, but only GIT read-only -
they can only clone, not push.
I do not administer the server git repos is located on, so I must have some
information before I attack the admin..
Thank you,
Hinko
--
Hinko Kočevar, OSS developer
ČETRTA POT, d.o.o.
Planina 3, 4000 Kranj, SI EU
tel ++386 (0) 4 280 66 03
e-mail hinko.kocevar@cetrtapot.si
http www.cetrtapot.si
^ 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