* [PATCH] use xread where we are not checking for EAGAIN/EINTR
From: Andy Whitcroft @ 2007-01-05 10:54 UTC (permalink / raw)
To: git
We have xread() to handle those OS's which will return EAGAIN or
EINTR when the read is interrupted. We should use this where we
are not otherwise handling such errors.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
We have an xread() wrapper to help us with those nasty
interrupt returns and yet we fail to use it consistently.
This patch updates those plain read()'s which do not
have any handling for errors, or which treat those errors
as user visible fatal errors.
This feels right to me, but perhaps there is some good
reason that things are done this way ... if so could
someone elighten me.
If this is a sensible change, then I'll have a look at
the write side.
---
diff --git a/dir.c b/dir.c
index 0338d6c..8fe0865 100644
--- a/dir.c
+++ b/dir.c
@@ -142,7 +142,7 @@ static int add_excludes_from_file_1(const char *fname,
return 0;
}
buf = xmalloc(size+1);
- if (read(fd, buf, size) != size)
+ if (xread(fd, buf, size) != size)
goto err;
close(fd);
diff --git a/http-fetch.c b/http-fetch.c
index 396552d..50a3b00 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -175,7 +175,7 @@ static void start_object_request(struct object_request *obj_req)
prevlocal = open(prevfile, O_RDONLY);
if (prevlocal != -1) {
do {
- prev_read = read(prevlocal, prev_buf, PREV_BUF_SIZE);
+ prev_read = xread(prevlocal, prev_buf, PREV_BUF_SIZE);
if (prev_read>0) {
if (fwrite_sha1_file(prev_buf,
1,
diff --git a/http-push.c b/http-push.c
index ecefdfd..acb5c27 100644
--- a/http-push.c
+++ b/http-push.c
@@ -288,7 +288,7 @@ static void start_fetch_loose(struct transfer_request *request)
prevlocal = open(prevfile, O_RDONLY);
if (prevlocal != -1) {
do {
- prev_read = read(prevlocal, prev_buf, PREV_BUF_SIZE);
+ prev_read = xread(prevlocal, prev_buf, PREV_BUF_SIZE);
if (prev_read>0) {
if (fwrite_sha1_file(prev_buf,
1,
diff --git a/imap-send.c b/imap-send.c
index ad91858..3f1e542 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -224,7 +224,7 @@ socket_perror( const char *func, Socket_t *sock, int ret )
static int
socket_read( Socket_t *sock, char *buf, int len )
{
- int n = read( sock->fd, buf, len );
+ int n = xread( sock->fd, buf, len );
if (n <= 0) {
socket_perror( "read", sock, n );
close( sock->fd );
@@ -390,7 +390,7 @@ arc4_init( void )
fprintf( stderr, "Fatal: no random number source available.\n" );
exit( 3 );
}
- if (read( fd, dat, 128 ) != 128) {
+ if (xread( fd, dat, 128 ) != 128) {
fprintf( stderr, "Fatal: cannot read random number source.\n" );
exit( 3 );
}
diff --git a/local-fetch.c b/local-fetch.c
index 7b6875c..21bcf75 100644
--- a/local-fetch.c
+++ b/local-fetch.c
@@ -184,7 +184,7 @@ int fetch_ref(char *ref, unsigned char *sha1)
fprintf(stderr, "cannot open %s\n", filename);
return -1;
}
- if (read(ifd, hex, 40) != 40 || get_sha1_hex(hex, sha1)) {
+ if (xread(ifd, hex, 40) != 40 || get_sha1_hex(hex, sha1)) {
close(ifd);
fprintf(stderr, "cannot read from %s\n", filename);
return -1;
diff --git a/path.c b/path.c
index 066f621..f6f9cfd 100644
--- a/path.c
+++ b/path.c
@@ -113,7 +113,7 @@ int validate_symref(const char *path)
fd = open(path, O_RDONLY);
if (fd < 0)
return -1;
- len = read(fd, buffer, sizeof(buffer)-1);
+ len = xread(fd, buffer, sizeof(buffer)-1);
close(fd);
/*
diff --git a/refs.c b/refs.c
index 121774c..f6afd61 100644
--- a/refs.c
+++ b/refs.c
@@ -284,7 +284,7 @@ const char *resolve_ref(const char *ref, unsigned char *sha1, int reading, int *
fd = open(path, O_RDONLY);
if (fd < 0)
return NULL;
- len = read(fd, buffer, sizeof(buffer)-1);
+ len = xread(fd, buffer, sizeof(buffer)-1);
close(fd);
/*
diff --git a/sha1_file.c b/sha1_file.c
index d9622d9..0c9483c 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1869,7 +1869,7 @@ int write_sha1_from_fd(const unsigned char *sha1, int fd, char *buffer,
if (ret != Z_OK)
break;
}
- size = read(fd, buffer + *bufposn, bufsize - *bufposn);
+ size = xread(fd, buffer + *bufposn, bufsize - *bufposn);
if (size <= 0) {
close(local);
unlink(tmpfile);
diff --git a/ssh-fetch.c b/ssh-fetch.c
index b006c5c..6ec9488 100644
--- a/ssh-fetch.c
+++ b/ssh-fetch.c
@@ -82,7 +82,7 @@ int fetch(unsigned char *sha1)
remote = conn_buf[0];
memmove(conn_buf, conn_buf + 1, --conn_buf_posn);
} else {
- if (read(fd_in, &remote, 1) < 1)
+ if (xread(fd_in, &remote, 1) < 1)
return -1;
}
/* fprintf(stderr, "Got %d\n", remote); */
@@ -99,7 +99,7 @@ static int get_version(void)
char type = 'v';
write(fd_out, &type, 1);
write(fd_out, &local_version, 1);
- if (read(fd_in, &remote_version, 1) < 1) {
+ if (xread(fd_in, &remote_version, 1) < 1) {
return error("Couldn't read version from remote end");
}
return 0;
@@ -111,10 +111,10 @@ int fetch_ref(char *ref, unsigned char *sha1)
char type = 'r';
write(fd_out, &type, 1);
write(fd_out, ref, strlen(ref) + 1);
- read(fd_in, &remote, 1);
+ xread(fd_in, &remote, 1);
if (remote < 0)
return remote;
- read(fd_in, sha1, 20);
+ xread(fd_in, sha1, 20);
return 0;
}
diff --git a/ssh-upload.c b/ssh-upload.c
index 0b52ae1..3f2794c 100644
--- a/ssh-upload.c
+++ b/ssh-upload.c
@@ -23,7 +23,7 @@ static int serve_object(int fd_in, int fd_out) {
signed char remote;
int posn = 0;
do {
- size = read(fd_in, sha1 + posn, 20 - posn);
+ size = xread(fd_in, sha1 + posn, 20 - posn);
if (size < 0) {
perror("git-ssh-upload: read ");
return -1;
@@ -54,7 +54,7 @@ static int serve_object(int fd_in, int fd_out) {
static int serve_version(int fd_in, int fd_out)
{
- if (read(fd_in, &remote_version, 1) < 1)
+ if (xread(fd_in, &remote_version, 1) < 1)
return -1;
write(fd_out, &local_version, 1);
return 0;
@@ -67,7 +67,7 @@ static int serve_ref(int fd_in, int fd_out)
int posn = 0;
signed char remote = 0;
do {
- if (read(fd_in, ref + posn, 1) < 1)
+ if (xread(fd_in, ref + posn, 1) < 1)
return -1;
posn++;
} while (ref[posn - 1]);
@@ -89,7 +89,7 @@ static void service(int fd_in, int fd_out) {
char type;
int retval;
do {
- retval = read(fd_in, &type, 1);
+ retval = xread(fd_in, &type, 1);
if (retval < 1) {
if (retval < 0)
perror("git-ssh-upload: read ");
diff --git a/upload-pack.c b/upload-pack.c
index c568ef0..03a4156 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -242,7 +242,7 @@ static void create_pack_file(void)
*cp++ = buffered;
outsz++;
}
- sz = read(pu_pipe[0], cp,
+ sz = xread(pu_pipe[0], cp,
sizeof(data) - outsz);
if (0 < sz)
;
@@ -267,7 +267,7 @@ static void create_pack_file(void)
/* Status ready; we ship that in the side-band
* or dump to the standard error.
*/
- sz = read(pe_pipe[0], progress,
+ sz = xread(pe_pipe[0], progress,
sizeof(progress));
if (0 < sz)
send_client_data(2, progress, sz);
^ permalink raw reply related
* Re: [PATCH 2/4] Improve cached content header of status output
From: Andy Whitcroft @ 2007-01-05 10:54 UTC (permalink / raw)
To: Juergen Ruehle; +Cc: git, Junio C Hamano, Jürgen Rühle
In-Reply-To: <11677659921833-git-send-email-j.ruehle@bmiag.de>
Juergen Ruehle wrote:
> From: =?iso-8859-1?q?J=FCrgen_R=FChle?= <j-r@online.de>
>
> This tries to be more to the point while also including a pointer on how to
> unstage changes from the index.
>
> Since this header is printed in two different code paths and the name of the
> reference commit is needed for the unstage part, provide a new printing
> function.
>
> Signed-off-by: Jürgen Rühle <j-r@online.de>
> ---
> wt-status.c | 18 ++++++++++++++----
> 1 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 34be91b..98ca135 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -53,6 +53,18 @@ void wt_status_prepare(struct wt_status *s)
> s->untracked = 0;
> }
>
> +static void wt_status_print_cached_header(const char *reference)
> +{
> + const char *c = color(WT_STATUS_HEADER);
> + color_printf_ln(c, "# Cached changes to be committed:");
> + if (reference) {
> + color_printf_ln(c, "# (use \"git reset %s <file>...\" and \"git rm --cached <file>...\" to unstage)", reference);
> + } else {
> + color_printf_ln(c, "# (use \"git rm --cached <file>...\" to unstage)");
> + }
> + color_printf_ln(c, "#");
We seem to be using 'Cached' and 'staged' here. I thought we had
updated all the docs to call files in the index "Staged for commit". It
feels like the header should be more like:
# Currently staged changes, will be commited:
The rm --cached is somewhat unfortunate either way.
-apw
^ permalink raw reply
* Deleting branches in cogito
From: Jonathan Trites @ 2007-01-05 10:29 UTC (permalink / raw)
To: git
Forgive my brain damage, but how does one go about deleting branches
in cogito? I've been up and down google and the mailing lists and I
can't find any mention of how one does this.
I see there are commands cg-switch, cg-branch-add, cg-branch-chg, and
cg-branch-ls, but nowhere do I see a "cg-branch-rm" command or
equivalent cg-switch command line option.
In the git commands I see "git-branch -d", and maybe this is the
command I am looking for, but is there a "native" cogito command to
delete branches?
^ permalink raw reply
* Re: [PATCH 2/2] git-reset <tree> -- <path> restores absense of <path> in <tree>
From: Johannes Schindelin @ 2007-01-05 10:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz4xiz6t.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 5 Jan 2007, Junio C Hamano wrote:
> * By the way, I noticed that "git log --diff-filter=A --
> t/t5401-update-hooks.sh" does not find the commit that
> introduced the path. v1.4.1.1 seems to work but v1.4.2.4
> does not. I haven't bisected it yet...
It is this commit:
1798562: "log --raw: Don't descend into subdirectories by default"
And sure enough,
$ git log next -r --diff-filter=A -- t/t5401-update-hooks.sh
works.
Ciao,
Dscho
^ permalink raw reply
* Re: Pushing into a repository with working directory?
From: Junio C Hamano @ 2007-01-05 9:50 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <459E1B23.4060400@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> Is it fishy if the working directory and index match HEAD? If not, then
> we could detect that and allow update in that case?
That actually is what 'git-pull' does when you misconfigure and
use your current branch as the tracking branch (which is the
only reason 'git-fetch' has the --update-head-ok option that
should never be used by the end user).
We really should disallow this.
^ permalink raw reply
* [PATCH 2/2] git-reset <tree> -- <path> restores absense of <path> in <tree>
From: Junio C Hamano @ 2007-01-05 9:46 UTC (permalink / raw)
To: git; +Cc: Juergen Ruehle
When <path> exists in the index (either merged or unmerged), and
<tree> does not have it, git-reset should be usable to restore
the absense of it from the tree. This implements it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* By the way, I noticed that "git log --diff-filter=A --
t/t5401-update-hooks.sh" does not find the commit that
introduced the path. v1.4.1.1 seems to work but v1.4.2.4
does not. I haven't bisected it yet...
git-reset.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-reset.sh b/git-reset.sh
index a969370..76c8a81 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -44,8 +44,10 @@ if test $# != 0
then
test "$reset_type" == "--mixed" ||
die "Cannot do partial $reset_type reset."
- git ls-tree -r --full-name $rev -- "$@" |
- git update-index --add --index-info || exit
+
+ git-diff-index --cached $rev -- "$@" |
+ sed -e 's/^:\([0-7][0-7]*\) [0-7][0-7]* \([0-9a-f][0-9a-f]*\) [0-9a-f][0-9a-f]* [A-Z] \(.*\)$/\1 \2 \3/' |
+ git update-index --add --remove --index-info || exit
git update-index --refresh
exit
fi
--
1.5.0.rc0.ge0f6
^ permalink raw reply related
* [PATCH 1/2] diff-index --cached --raw: show tree entry on the LHS for unmerged entries.
From: Junio C Hamano @ 2007-01-05 9:42 UTC (permalink / raw)
To: git
This updates the way diffcore represents an unmerged pair
somewhat. It used to be that entries with mode=0 on both sides
were used to represent an unmerged pair, but now it has an
explicit flag. This is to allow diff-index --cached to report
the entry from the tree when the path is unmerged in the index.
This is used in updating "git reset <tree> -- <path>" to restore
absense of the path in the index from the tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This is rather subtle but touches fairly core part of the
plumbing, which I tried to stay away from doing these days.
I do not think it would break anything, but please holler if
it breaks your scripts...
diff-lib.c | 9 ++++++---
diff.c | 6 ++++--
diff.h | 4 +++-
diffcore.h | 4 ++--
4 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/diff-lib.c b/diff-lib.c
index fc69fb9..2c9be60 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -97,7 +97,7 @@ int run_diff_files(struct rev_info *revs, int silent_on_removed)
* Show the diff for the 'ce' if we found the one
* from the desired stage.
*/
- diff_unmerge(&revs->diffopt, ce->name);
+ diff_unmerge(&revs->diffopt, ce->name, 0, null_sha1);
if (ce_stage(ce) != diff_unmerged_stage)
continue;
}
@@ -297,9 +297,12 @@ static int diff_cache(struct rev_info *revs,
!show_modified(revs, ce, ac[1], 0,
cached, match_missing))
break;
- /* fallthru */
+ diff_unmerge(&revs->diffopt, ce->name,
+ ntohl(ce->ce_mode), ce->sha1);
+ break;
case 3:
- diff_unmerge(&revs->diffopt, ce->name);
+ diff_unmerge(&revs->diffopt, ce->name,
+ 0, null_sha1);
break;
default:
diff --git a/diff.c b/diff.c
index f14288b..2c2e9dc 100644
--- a/diff.c
+++ b/diff.c
@@ -2875,10 +2875,12 @@ void diff_change(struct diff_options *options,
}
void diff_unmerge(struct diff_options *options,
- const char *path)
+ const char *path,
+ unsigned mode, const unsigned char *sha1)
{
struct diff_filespec *one, *two;
one = alloc_filespec(path);
two = alloc_filespec(path);
- diff_queue(&diff_queued_diff, one, two);
+ fill_filespec(one, sha1, mode);
+ diff_queue(&diff_queued_diff, one, two)->is_unmerged = 1;
}
diff --git a/diff.h b/diff.h
index eff4455..7a347cf 100644
--- a/diff.h
+++ b/diff.h
@@ -144,7 +144,9 @@ extern void diff_change(struct diff_options *,
const char *base, const char *path);
extern void diff_unmerge(struct diff_options *,
- const char *path);
+ const char *path,
+ unsigned mode,
+ const unsigned char *sha1);
extern int diff_scoreopt_parse(const char *opt);
diff --git a/diffcore.h b/diffcore.h
index 2249bc2..1ea8067 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -54,9 +54,9 @@ struct diff_filepair {
unsigned source_stays : 1; /* all of R/C are copies */
unsigned broken_pair : 1;
unsigned renamed_pair : 1;
+ unsigned is_unmerged : 1;
};
-#define DIFF_PAIR_UNMERGED(p) \
- (!DIFF_FILE_VALID((p)->one) && !DIFF_FILE_VALID((p)->two))
+#define DIFF_PAIR_UNMERGED(p) ((p)->is_unmerged)
#define DIFF_PAIR_RENAME(p) ((p)->renamed_pair)
--
1.5.0.rc0.ge0f6
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Alex Riesen @ 2007-01-05 9:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20070105025921.GA14042@spearce.org>
On 1/5/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > >* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
> >
> > Running this and the merge-recursive speedup I sent today locally.
> > sp/mmap needs relatively recent cygwin library (otherwise pread
> > is broken). No other ill effects noticed. Perfomance is bearable.
>
> The default on Cygwin is now NO_MMAP. I've disabled that default
I left it at NO_MMAP: wanted to see how bad pread performs.
No worse than mmap, as it seems.
> in my own Cygwin environment and continue to use mmap() rather than
> pread(), but I'm also running my sp/mmap change there. I haven't
> noticed a performance difference, but I also haven't tested for one.
> IOW if there is a difference its close enough to noise to not be
> visible to me as a user.
Confirm that.
^ permalink raw reply
* Re: Pushing into a repository with working directory?
From: Andy Whitcroft @ 2007-01-05 9:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt41j1le.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
>> Special casing the 'current' branch makes any sort of automated push
>> setup unreliable. Indeed the special case preventing a fetch into the
>> current branch is pretty annoying for the same reason. I would almost
>> prefer to relax that than add the same for push.
>
> How would you relax the fetch case? Fetching into the current
> branch, unless the repository is bare, is always a fishy
> operation.
Is it fishy if the working directory and index match HEAD? If not, then
we could detect that and allow update in that case?
Also, if we had dangling head support we could "leave" HEAD pointing to
the starting commit, and emit a nice fat warning.
-apw
^ permalink raw reply
* Re: git-svn throwing assertion on old svn tracking branch
From: Nicolas Vilz @ 2007-01-05 9:18 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070101022734.GF7730@hand.yhbt.net>
On Sun, Dec 31, 2006 at 06:27:34PM -0800, Eric Wong wrote:
> Eric Wong <normalperson@yhbt.net> wrote:
> > Nicolas Vilz <niv@iaglans.de> wrote:
> > > hello guys,
> > >
> > > it has been a while, i tried git in conjunction with svn... i got a nice
> > > history, when working with it. This Work is now a year old.
> > >
> > > Now I wanted to get on working and got following error message while
> > > fetching from one specific svn tracking branch:
> > >
> > > $ git-svn fetch -i svn_master
> > > perl: subversion/libsvn_subr/path.c:343: svn_path_remove_component:
> > > Assertion `is_canonical(path->data, path->len)' failed.
> > > Aborted
>
> Actually, I just hit upon a weird bug in svm (SVN::Mirror) that was
> similar to this (line 114 of the same file, 1.4.2dfsg1-2 in Debian).
> Can you try taking the trailing slash out of the URL?
> (.git/svn/svn_master/info/url).
>
> Thanks.
Actually I can fetch the revisions now again. Maybe that that little
trailing slash did it.
Nicolas Vilz
^ permalink raw reply
* Re: [BUG] stgit: unexpected "unknown user details" on refresh
From: Catalin Marinas @ 2007-01-05 9:07 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20070104232224.GA12756@nan92-1-81-57-214-146.fbx.proxad.net>
On 04/01/07, Yann Dirson <ydirson@altern.org> wrote:
> Here is an error I just got when refreshing. The refresh did occur, but
> the error is annoying and may hide something:
>
> dwitch@gandelf:/export/work/yann/git/stgit$ ./stg ref contrib/stg-whatchanged
> Checking for changes in the working directory... done
> Refreshing patch "whatchanged"...stg ref: unknown user details
I changed StGIT to use the same configuration file as GIT and it
cannot find the user information. To remove the error:
git repo-config --global user.name Yann Dirson
git repo-config --global user.email ydirson@altern.org
It probably tries to set the author information for the patch and
GIT_AUTH* or GIT_COMMIT* aren't set but it would be probably useful to
get the full backtrace of this error (at the end of the stgit/main.py
file, just add a "raise" before sys.exit(2)).
--
Catalin
^ permalink raw reply
* Re: Pushing into a repository with working directory?
From: Junio C Hamano @ 2007-01-05 8:54 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <459E1182.201@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> Special casing the 'current' branch makes any sort of automated push
> setup unreliable. Indeed the special case preventing a fetch into the
> current branch is pretty annoying for the same reason. I would almost
> prefer to relax that than add the same for push.
How would you relax the fetch case? Fetching into the current
branch, unless the repository is bare, is always a fishy
operation.
^ permalink raw reply
* Re: Pushing into a repository with working directory?
From: Andy Whitcroft @ 2007-01-05 8:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070102045108.GC27690@spearce.org>
Shawn O. Pearce wrote:
> So tonight on #git I think I answered for the 10th time why the
> working directory doesn't update after a push to its associated
> repository.
>
> We all know its somewhat dangerous to push into the current branch
> of a working directory, especially if that working directory contains
> uncommitted changes, as HEAD no longer matches the index.
>
> But we all also know its incredibly useful to be able to push into
> a repository with a working directory, so we certainly don't want
> to disallow it entirely.
>
> What about refusing a push to the current branch (branch listed in
> $GIT_DIR/HEAD) and the repository appears to have a working directory
> (is_bare_git_dir is false)?
Special casing the 'current' branch makes any sort of automated push
setup unreliable. Indeed the special case preventing a fetch into the
current branch is pretty annoying for the same reason. I would almost
prefer to relax that than add the same for push.
-apw
^ permalink raw reply
* Re: [1/2 PATCH] git-svn: make multi-init less confusing
From: David Kågedal @ 2007-01-05 6:37 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20070105020158.GA21925@localdomain>
Eric Wong <normalperson@yhbt.net> writes:
> It now requires at least one of the (trunk|branch|tags) arguments
> (either from the command-line or in .git/config). Also we make
> sure that anything that is passed as a URL ('help') in David's
> case is actually a URL.
If I understand correctly, this still allows you to write
$ git svn svn://foo/bar multi-init
which is kindof confusing. But I guess it's less likely that anyone
does it by mistake.
Thanks for the quick response, anyway. The documentation patch is
also a great improvement.
Now if you could only clarify the documentation of dcommit to explain
whether it creates one svn revision per commit in your branch, or if
it creates a single svn revision with the full diff, and the
documentation would be perfect :-)
--
David Kågedal
^ permalink raw reply
* Re: [PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.
From: Junio C Hamano @ 2007-01-05 6:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070105032808.GA14247@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> If we have a 64 bit address space we can easily afford to commit
> a larger amount of virtual address space to pack file access.
> So on these platforms we should increase the default settings of
> core.packedGit{Limit,WindowSize} to something that will better
> handle very large projects.
Hmmmm. What's the reasoning behind this?
We have more than enough virtual memory anyway, we do not bother
with our own mmap limit -- we will let the operating system
worry about it.
If that is the reasoning, I have a feeling that we might want to
be even more agressive. If you have a 1.5GB pack, wouldn't you
rather map the whole thing in a single window, instead of
splitting that into two?
Currently we are limited (by pack offset) to 4GB per pack, so
raising the window max to 4GB might make sense.
On the total size of vm space, I am wondering what would happen
if we make this unbounded. You certainly notice mmap() failure
and fall back to recycle other windows even when your total
usage is under the limit, don't you? Your later patches in the
series even unmap the mapped but unused window lazily to make
room for xmalloc() and friends, so I suspect it might even make
it simpler not to have this limit especially on larger systems.
^ permalink raw reply
* Re: [PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"
From: Junio C Hamano @ 2007-01-05 3:50 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <605150.6351.qm@web31807.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> A quick show-and-tell of this patch is after applying it, open
> "blame" on a file, click on a linenr link of a block which
> has only a single line changed -- the diff between what
> you're seeing now and before is at least that line. This you can
> data-mine with gitweb back to where the line was introduced. Similar
> argument applies to blocks of more than one line.
One non-question and one question:
- This favors the first parent, which is obviously the right
thing for most of the time. I wonder what happens to a
merge, though, but I realize that a line attributed to a
merge is even rarer, and such a line is introduced by the
"evil merge".
- I wonder if the line number is correct for the parent
commit. How well does this work when you clicked a line that
was added at the end of the file, where the $orig_lineno goes
beyond the whole file in the parent?
^ permalink raw reply
* [PATCH] Increase packedGit{Limit,WindowSize} on 64 bit systems.
From: Shawn O. Pearce @ 2007-01-05 3:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If we have a 64 bit address space we can easily afford to commit
a larger amount of virtual address space to pack file access.
So on these platforms we should increase the default settings of
core.packedGit{Limit,WindowSize} to something that will better
handle very large projects.
Thanks to Andy Whitcroft for pointing out that we can safely
increase these defaults on such systems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/config.txt | 16 ++++++++++------
git-compat-util.h | 10 ++++++++--
2 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e4ee52f..b4aae0d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -125,9 +125,12 @@ core.packedGitWindowSize::
more quickly. Smaller window sizes will negatively affect
performance due to increased calls to the operating system's
memory manager, but may improve performance when accessing
- a large number of large pack files. Default is 32 MiB,
- which should be reasonable for all users/operating systems.
- You probably do not need to adjust this value.
+ a large number of large pack files.
++
+Default is 1 MiB if NO_MMAP was set at compile time, otherwise 32
+MiB on 32 bit platforms and 1 GiB on 64 bit platforms. This should
+be reasonable for all users/operating systems. You probably do
+not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
@@ -136,9 +139,10 @@ core.packedGitLimit::
from pack files. If Git needs to access more than this many
bytes at once to complete an operation it will unmap existing
regions to reclaim virtual address space within the process.
- Default is 256 MiB, which should be reasonable for all
- users/operating systems, except on the largest projects.
- You probably do not need to adjust this value.
++
+Default is 256 MiB on 32 bit platforms and 8 GiB on 64 bit platforms.
+This should be reasonable for all users/operating systems, except on
+the largest projects. You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
diff --git a/git-compat-util.h b/git-compat-util.h
index f243b86..55456da 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -97,11 +97,17 @@ extern int git_munmap(void *start, size_t length);
#else /* NO_MMAP */
#include <sys/mman.h>
-#define DEFAULT_PACKED_GIT_WINDOW_SIZE (32 * 1024 * 1024)
+#define DEFAULT_PACKED_GIT_WINDOW_SIZE \
+ (sizeof(void*) >= 8 \
+ ? 1 * 1024 * 1024 * 1024 \
+ : 32 * 1024 * 1024)
#endif /* NO_MMAP */
-#define DEFAULT_PACKED_GIT_LIMIT (256 * 1024 * 1024)
+#define DEFAULT_PACKED_GIT_LIMIT \
+ (sizeof(void*) >= 8 \
+ ? 8 * 1024 * 1024 * 1024 \
+ : 256 * 1024 * 1024)
#ifdef NO_SETENV
#define setenv gitsetenv
--
1.5.0.rc0.gce9e
^ permalink raw reply related
* Re: [RFC] git-remote
From: Shawn O. Pearce @ 2007-01-05 3:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodpejhmt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> By the way, do you have comments on my counterproposal for
> lockfile fix?
Yea, see the email in that thread.
Sorry for the lag. I've been sidetracked by a new and fairly useless
(to me anyway) project that I have to put a lot of time into now.
Arrgh. At least I have a sound version control system to track
its source code in. :-)
--
Shawn.
^ permalink raw reply
* Re: [RFC] git-remote
From: Junio C Hamano @ 2007-01-05 3:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20070105030245.GC14042@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> It might be handy to have a single command that helps you manage
>> your configuration that relates to downloading from remote
>> repositories. This currently does only about 20% of what I want
>> it to do.
>>
>> $ git remote
>
> This is pretty cool. It would be nice if something like it was
> in 1.5.0. ;-)
Hmph.
By the way, do you have comments on my counterproposal for
lockfile fix?
^ permalink raw reply
* Re: [PATCH] Fix infinite loop when deleting multiple packed refs.
From: Shawn O. Pearce @ 2007-01-05 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicholas Miell
In-Reply-To: <7vy7oluthy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Nicholas Miell reported that `git branch -D A B` failed if both refs
> > A and B were packed into .git/packed-refs. This happens because the
> > same pack_lock instance was being enqueued into the lock list twice,
>
> I do not like this, actually.
[snip]
> In other words, I am suspecting this might be a cleaner fix.
Ack'd. I like your patch better.
--
Shawn.
^ permalink raw reply
* Re: [RFC] git-remote
From: Shawn O. Pearce @ 2007-01-05 3:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyarokk7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> It might be handy to have a single command that helps you manage
> your configuration that relates to downloading from remote
> repositories. This currently does only about 20% of what I want
> it to do.
>
> $ git remote
This is pretty cool. It would be nice if something like it was
in 1.5.0. ;-)
--
Shawn.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Shawn O. Pearce @ 2007-01-05 2:59 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <81b0412b0701041022h30cd4fcxd62dbf3ecb504ea9@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 1/2/07, Junio C Hamano <junkio@cox.net> wrote:
> >Here are the topics that have been cooking. Commits prefixed
> >with '-' are only in 'pu' while commits prefixed with '+' are
> >in 'next'. The topics list the commits in reverse chronological
> >order.
> >
> >* sp/mmap (Sat Dec 30 22:13:43 2006 -0500) 25 commits
>
> Running this and the merge-recursive speedup I sent today locally.
> sp/mmap needs relatively recent cygwin library (otherwise pread
> is broken). No other ill effects noticed. Perfomance is bearable.
The default on Cygwin is now NO_MMAP. I've disabled that default
in my own Cygwin environment and continue to use mmap() rather than
pread(), but I'm also running my sp/mmap change there. I haven't
noticed a performance difference, but I also haven't tested for one.
IOW if there is a difference its close enough to noise to not be
visible to me as a user.
--
Shawn.
^ permalink raw reply
* [PATCH] [gitweb] Blame "linenr" link jumps to previous state at "orig_lineno"
From: Luben Tuikov @ 2007-01-05 2:37 UTC (permalink / raw)
To: git
Blame currently displays the commit id which introduced a
block of one or more lines, the line numbers wrt the current
listing of the file and the file's line contents.
The commit id displayed is hyperlinked to the commit.
Currently the linenr links are hyperlinked to the same
commit id displayed to the left, which is _no_ different
than the block of lines displayed, since it is the _same
commit_ that is hyperlinked. And thus clicking on it leads
to the same state of the file for that chunk of
lines. I.e. data mining is not currently possible with
gitweb given a chunk of lines introduced by a commit.
This patch makes such data mining possible.
The line numbers are now hyperlinked to the parent of the
commit id of the block of lines. Furthermore they are
linked to the line where that block was introduced.
Thus clicking on a linenr link will show you the file's
line(s) state prior to the commit id you were viewing.
So clicking continually on a linenr link shows you how this
line and its line number changed over time, leading to the
initial commit where it was first introduced.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
A quick show-and-tell of this patch is after applying it, open
"blame" on a file, click on a linenr link of a block which
has only a single line changed -- the diff between what
you're seeing now and before is at least that line. This you can
data-mine with gitweb back to where the line was introduced. Similar
argument applies to blocks of more than one line.
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ac602ae..c87c61d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3208,9 +3208,14 @@ HTML
esc_html($rev));
print "</td>\n";
}
+ open (my $dd, "-|", git_cmd(), "rev-parse", "$full_rev^")
+ or die_error("could not open git-rev-parse");
+ my $parent_commit = <$dd>;
+ close $dd;
+ chomp($parent_commit);
my $blamed = href(action => 'blame',
file_name => $meta->{'filename'},
- hash_base => $full_rev);
+ hash_base => $parent_commit);
print "<td class=\"linenr\">";
print $cgi->a({ -href => "$blamed#l$orig_lineno",
-id => "l$lineno",
--
1.5.0.rc0.g90e5
^ permalink raw reply related
* [PATCH] git-svn: make --repack work consistently between fetch and multi-fetch
From: Eric Wong @ 2007-01-05 2:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Lee, Git Mailing List
In-Reply-To: <20070104023350.GA1194@localdomain>
Since fetch reforks itself at most every 1000 revisions, we
need to update the counter in the parent process to have a
working count if we set our repack interval to be > ~1000
revisions. multi-fetch has always done this correctly
because of an extra process; now fetch uses the extra process;
as well.
While we're at it, only compile the $sha1 regex that checks for
repacking once.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
I wrote:
> Just set the repack interval to something smaller than 1000;
> (--repack=100) if you experience timeouts.
Chris: you shouldn't get timeouts (at least not across HTTP(s)).
Also, don't worry about repack=100 either; there was a bug that
was triggered only in 'fetch' not 'multi-fetch' (you should use
'multi-fetch'). This patch fixes the 'fetch' bug.
git-svn.perl | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0fc386a..5377762 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -102,7 +102,7 @@ my %cmt_opts = ( 'edit|e' => \$_edit,
);
my %cmd = (
- fetch => [ \&fetch, "Download new revisions from SVN",
+ fetch => [ \&cmd_fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision, %fc_opts } ],
init => [ \&init, "Initialize a repo for tracking" .
" (requires URL argument)",
@@ -293,6 +293,10 @@ sub init {
setup_git_svn();
}
+sub cmd_fetch {
+ fetch_child_id($GIT_SVN, @_);
+}
+
sub fetch {
check_upgrade_needed();
$SVN_URL ||= file_to_s("$GIT_SVN_DIR/info/url");
@@ -836,7 +840,6 @@ sub fetch_child_id {
my $ref = "$GIT_DIR/refs/remotes/$id";
defined(my $pid = open my $fh, '-|') or croak $!;
if (!$pid) {
- $_repack = undef;
$GIT_SVN = $ENV{GIT_SVN_ID} = $id;
init_vars();
fetch(@_);
@@ -844,7 +847,7 @@ sub fetch_child_id {
}
while (<$fh>) {
print $_;
- check_repack() if (/^r\d+ = $sha1/);
+ check_repack() if (/^r\d+ = $sha1/o);
}
close $fh or croak $?;
}
@@ -1407,7 +1410,6 @@ sub git_commit {
# this output is read via pipe, do not change:
print "r$log_msg->{revision} = $commit\n";
- check_repack();
return $commit;
}
--
1.5.0.rc0.g0d67
^ permalink raw reply related
* [PATCH 2/2] git-svn: update documentation for multi-{init|fetch}
From: Eric Wong @ 2007-01-05 2:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Kågedal
In-Reply-To: <87fyaqvgoz.fsf@morpheus.local>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
Documentation/git-svn.txt | 54 ++++++++++++++++++++++++++++++--------------
1 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index f5f57e8..f754d2f 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -3,7 +3,7 @@ git-svn(1)
NAME
----
-git-svn - bidirectional operation between a single Subversion branch and git
+git-svn - bidirectional operation between Subversion and git
SYNOPSIS
--------
@@ -11,24 +11,20 @@ SYNOPSIS
DESCRIPTION
-----------
-git-svn is a simple conduit for changesets between a single Subversion
-branch and git. It is not to be confused with gitlink:git-svnimport[1].
-They were designed with very different goals in mind.
+git-svn is a simple conduit for changesets between Subversion and git.
+It is not to be confused with gitlink:git-svnimport[1], which is
+read-only and geared towards tracking multiple branches.
-git-svn is designed for an individual developer who wants a
+git-svn was originally designed for an individual developer who wants a
bidirectional flow of changesets between a single branch in Subversion
-and an arbitrary number of branches in git. git-svnimport is designed
-for read-only operation on repositories that match a particular layout
-(albeit the recommended one by SVN developers).
+and an arbitrary number of branches in git. Since its inception,
+git-svn has gained the ability to track multiple branches in a manner
+similar to git-svnimport; but it cannot (yet) automatically detect new
+branches and tags like git-svnimport does.
-For importing svn, git-svnimport is potentially more powerful when
-operating on repositories organized under the recommended
-trunk/branch/tags structure, and should be faster, too.
-
-git-svn mostly ignores the very limited view of branching that
-Subversion has. This allows git-svn to be much easier to use,
-especially on repositories that are not organized in a manner that
-git-svnimport is designed for.
+git-svn is especially useful when it comes to tracking repositories
+not organized in the way Subversion developers recommend (trunk,
+branches, tags directories).
COMMANDS
--------
@@ -370,7 +366,7 @@ SVN was very wrong.
Basic Examples
~~~~~~~~~~~~~~
-Tracking and contributing to a Subversion-managed project:
+Tracking and contributing to a the trunk of a Subversion-managed project:
------------------------------------------------------------------------
# Initialize a repo (like git init-db):
@@ -388,6 +384,30 @@ Tracking and contributing to a Subversion-managed project:
git-svn show-ignore >> .git/info/exclude
------------------------------------------------------------------------
+Tracking and contributing to an entire Subversion-managed project
+(complete with a trunk, tags and branches):
+See also:
+'<<tracking-multiple-repos,Tracking Multiple Repositories or Branches>>'
+
+------------------------------------------------------------------------
+# Initialize a repo (like git init-db):
+ git-svn multi-init http://svn.foo.org/project \
+ -T trunk -b branches -t tags
+# Fetch remote revisions:
+ git-svn multi-fetch
+# Create your own branch of trunk to hack on:
+ git checkout -b my-trunk remotes/trunk
+# Do some work, and then commit your new changes to SVN, as well as
+# automatically updating your working HEAD:
+ git-svn dcommit -i trunk
+# Something has been committed to trunk, rebase the latest into your branch:
+ git-svn multi-fetch && git rebase remotes/trunk
+# Append svn:ignore settings of trunk to the default git exclude file:
+ git-svn show-ignore -i trunk >> .git/info/exclude
+# Check for new branches and tags (no arguments are needed):
+ git-svn multi-init
+------------------------------------------------------------------------
+
REBASE VS. PULL
---------------
--
1.5.0.rc0.g0d67
^ permalink raw reply related
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