* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Daniel Barkalow @ 2007-06-04 23:48 UTC (permalink / raw)
To: Bryan Childs; +Cc: Linus Torvalds, git
In-Reply-To: <5971b1ba0706040838nc9ea7c7h54a57d4235d53bcf@mail.gmail.com>
On Mon, 4 Jun 2007, Bryan Childs wrote:
> On 6/4/07, Linus Torvalds < [send email to
> torvalds@linux-foundation.org via gmail]
> torvalds@linux-foundation.org> wrote:
> > So I *hope* that you want to just have automated build machinery that
> > builds the binaries to a *separate* location? You could use git to archive
> > them, and you can obviously (and easily) name the resulting binary blobs
> > by the versions in the source tree, but I'm just saying that trying to
> > track the binaries from within the same git repository as the source code
> > is less than optimal.
>
> Oh lord no - I never meant to imply that we'd be checking those
> binaries in, I just meant to hi-light that we need a central
> repository to build those binaries from - otherwise we'd end up with a
> selection of binaries for our users to download which contain a bunch
> of different features if they were built from a combination of
> repositories. I know you think everyone else is a moron, but we're not
> quite dumb enough to think maintaining binaries in a repository is a
> good idea :)
Actually, I've been playing with using git's data-distribution mechanism
to distribute generated binaries. You can do tags for arbitrary binary
content (not in a tree or commit), and, if you have some way of finding
the right tag name, you can fetch that and extract it.
I came up with this at my job when we were trying to decide what to do
with firmware images that we'd shipped, so that we'd be able to examine
them again even if we lose the compiler version we used at the time. We
needed an immutable data store with a mapping of tags to objects, and I
realized that we already had something with these exact characteristics.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Use git-tag in git-cvsimport
From: Elvis Pranskevichus @ 2007-06-04 23:55 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <7v1wgto2mh.fsf@assigned-by-dhcp.cox.net>
> hoi :)
Hi =)
> On Sun, Jun 03, 2007 at 05:01:03PM -0700, Junio C Hamano wrote:
> > Martin Waitz <tali@admingilde.org> writes:
> > > but lightweight tags are not fetched by default.
> >
> > Are you sure about that?
> not any more now that you questioned it ;-)
Last time I checked, unannotated tags are git-cloned and git-fetched just
fine. I'm not sure about the exact definition and behaviour of lightweight
tags, though.
CVS just doesn't attach any valuable info to the tags, it's just a point in
time.
> But at least there is a hook script which refuses to receive
> un-annotated tags and I always considered those tags to be temporary
> tags in the local repository.
Well, there's no mention about that in the docs. And I don't think that the
notion of git losing valid objects along the way is the good one =)
Anyways, the patch wasn't about the tag type change. As I mentioned it's just
a side effect. The main point is to fix the cvsimport tag breakage. I've
tested that change on a few big (and messy) CVS repos, and it works just
fine.
Cheers,
--
Elvis
^ permalink raw reply
* clarify git clone --local --shared --reference
From: Brandon Casey @ 2007-06-04 23:53 UTC (permalink / raw)
To: git
I think the goal of these three objects is space savings (and speed),
but I don't understand when I should prefer one option over another, or
when/whether to use a combination of them. And I am unsure (SCARED)
about any side effects they may have.
This is all based on the information in git-clone.txt. If there is more
detail someplace else please let me know.
1) What does local mean?
--local says repository must be on the "local" machine and claims it
attempts to make hardlinks when possible. Of course hard links cannot
be created across filesystems, so are there other speedups/space
savings when repository is on local machine but not on the same
filesystem? Is this option still valid then?
2) Does --shared imply shared write access? Does --local?
I'll point out that git-init has an option with the same name.
3) --shared seems like a special case of --reference? Are there
differences?
4) what happens if the source repository dissappears? Is --local ok
but --shared screwed?
4) is space savings obtained only at initial clone? or is it on going?
does a future git pull from the source repository create new hard
links where possible?
Can --shared be used with --reference. Can --reference be used multiple
times (and would I want to). Does -l with -s get you anything? (the
examples use this)
thanks,
-brandon
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds @ 2007-06-05 0:21 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Bryan Childs, git
In-Reply-To: <Pine.LNX.4.64.0706041923580.22840@iabervon.org>
On Mon, 4 Jun 2007, Daniel Barkalow wrote:
>
> Actually, I've been playing with using git's data-distribution mechanism
> to distribute generated binaries. You can do tags for arbitrary binary
> content (not in a tree or commit), and, if you have some way of finding
> the right tag name, you can fetch that and extract it.
Yes, I think git should be very nice for doing binary stuff like firmware
images too, my only worry is literally about "mixing it in" with other
stuff.
Putting lots of binary blobs into a git archive should work fine: but
if you would then start tying them together (with a commit chain), it just
means that even if you only really want _one_ of them, you end up getting
them all, which sounds like a potential disaster.
On the other hand, if you actually want a way to really *archive* the dang
things, that may well be what you actually want. In that case, having a
separate branch that only contains the binary stuff might actually be what
you want to do (and depending on the kind of binary data you have, the
delta algorithm might even be good at finding common data sequences and
compressing it).
> I came up with this at my job when we were trying to decide what to do
> with firmware images that we'd shipped, so that we'd be able to examine
> them again even if we lose the compiler version we used at the time. We
> needed an immutable data store with a mapping of tags to objects, and I
> realized that we already had something with these exact characteristics.
Yeah, if you just tag individual blobs, git will keep track of them, but
won't link them together, so you can easily just look up and fetch a
single one from such an archive. Sounds sane enough.
Linus
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: david @ 2007-06-05 1:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Daniel Barkalow, Bryan Childs, git
In-Reply-To: <alpine.LFD.0.98.0706041715500.23741@woody.linux-foundation.org>
On Mon, 4 Jun 2007, Linus Torvalds wrote:
> On Mon, 4 Jun 2007, Daniel Barkalow wrote:
>>
>> Actually, I've been playing with using git's data-distribution mechanism
>> to distribute generated binaries. You can do tags for arbitrary binary
>> content (not in a tree or commit), and, if you have some way of finding
>> the right tag name, you can fetch that and extract it.
>
> Yes, I think git should be very nice for doing binary stuff like firmware
> images too, my only worry is literally about "mixing it in" with other
> stuff.
>
> Putting lots of binary blobs into a git archive should work fine: but
> if you would then start tying them together (with a commit chain), it just
> means that even if you only really want _one_ of them, you end up getting
> them all, which sounds like a potential disaster.
if you put the binaries in a seperate repository and do shallow clones to
avoid getting all the old stuff wouldn't that work well?
David Lang
> On the other hand, if you actually want a way to really *archive* the dang
> things, that may well be what you actually want. In that case, having a
> separate branch that only contains the binary stuff might actually be what
> you want to do (and depending on the kind of binary data you have, the
> delta algorithm might even be good at finding common data sequences and
> compressing it).
>
>> I came up with this at my job when we were trying to decide what to do
>> with firmware images that we'd shipped, so that we'd be able to examine
>> them again even if we lose the compiler version we used at the time. We
>> needed an immutable data store with a mapping of tags to objects, and I
>> realized that we already had something with these exact characteristics.
>
> Yeah, if you just tag individual blobs, git will keep track of them, but
> won't link them together, so you can easily just look up and fetch a
> single one from such an archive. Sounds sane enough.
>
> Linus
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH 1/3] Move buffer_is_binary() to xdiff-interface.h
From: Johannes Schindelin @ 2007-06-05 2:36 UTC (permalink / raw)
To: git, junkio
We already have two instances where we want to determine if a buffer
contains binary data as opposed to text.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff.c | 6 +-----
grep.c | 11 -----------
xdiff-interface.c | 8 ++++++++
xdiff-interface.h | 1 +
4 files changed, 10 insertions(+), 16 deletions(-)
diff --git a/diff.c b/diff.c
index 508bc51..1a72688 100644
--- a/diff.c
+++ b/diff.c
@@ -1107,7 +1107,6 @@ static void setup_diff_attr_check(struct git_attr_check *check)
check->attr = attr_diff;
}
-#define FIRST_FEW_BYTES 8000
static int file_is_binary(struct diff_filespec *one)
{
unsigned long sz;
@@ -1127,10 +1126,7 @@ static int file_is_binary(struct diff_filespec *one)
return 0;
diff_populate_filespec(one, 0);
}
- sz = one->size;
- if (FIRST_FEW_BYTES < sz)
- sz = FIRST_FEW_BYTES;
- return !!memchr(one->data, 0, sz);
+ return buffer_is_binary(one->data, one->size);
}
static void builtin_diff(const char *name_a,
diff --git a/grep.c b/grep.c
index fcc6762..f05ae84 100644
--- a/grep.c
+++ b/grep.c
@@ -232,17 +232,6 @@ static void show_line(struct grep_opt *opt, const char *bol, const char *eol,
printf("%.*s\n", (int)(eol-bol), bol);
}
-/*
- * NEEDSWORK: share code with diff.c
- */
-#define FIRST_FEW_BYTES 8000
-static int buffer_is_binary(const char *ptr, unsigned long size)
-{
- if (FIRST_FEW_BYTES < size)
- size = FIRST_FEW_BYTES;
- return !!memchr(ptr, 0, size);
-}
-
static int fixmatch(const char *pattern, char *line, regmatch_t *match)
{
char *hit = strstr(line, pattern);
diff --git a/xdiff-interface.c b/xdiff-interface.c
index 10816e9..963bb89 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -122,4 +122,12 @@ int read_mmfile(mmfile_t *ptr, const char *filename)
return 0;
}
+#define FIRST_FEW_BYTES 8000
+int buffer_is_binary(const char *ptr, unsigned long size)
+{
+ if (FIRST_FEW_BYTES < size)
+ size = FIRST_FEW_BYTES;
+ return !!memchr(ptr, 0, size);
+}
+
diff --git a/xdiff-interface.h b/xdiff-interface.h
index 1918808..536f4e4 100644
--- a/xdiff-interface.h
+++ b/xdiff-interface.h
@@ -18,5 +18,6 @@ int parse_hunk_header(char *line, int len,
int *ob, int *on,
int *nb, int *nn);
int read_mmfile(mmfile_t *ptr, const char *filename);
+int buffer_is_binary(const char *ptr, unsigned long size);
#endif
--
1.5.2.1.2626.ge1044-dirty
^ permalink raw reply related
* [PATCH 3/3] git-merge-file: refuse to merge binary files
From: Johannes Schindelin @ 2007-06-05 2:37 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-merge-file.c | 6 +++++-
t/t6023-merge-file.sh | 5 +++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/builtin-merge-file.c b/builtin-merge-file.c
index 9135773..10ec63b 100644
--- a/builtin-merge-file.c
+++ b/builtin-merge-file.c
@@ -36,9 +36,13 @@ int cmd_merge_file(int argc, char **argv, char **envp)
for (; i < 3; i++)
names[i] = argv[i + 1];
- for (i = 0; i < 3; i++)
+ for (i = 0; i < 3; i++) {
if (read_mmfile(mmfs + i, argv[i + 1]))
return -1;
+ if (buffer_is_binary(mmfs[i].ptr, mmfs[i].size))
+ return error("Cannot merge binary files: %s\n",
+ argv[i + 1]);
+ }
ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
&xpp, XDL_MERGE_ZEALOUS, &result);
diff --git a/t/t6023-merge-file.sh b/t/t6023-merge-file.sh
index c76fccf..1decbfb 100755
--- a/t/t6023-merge-file.sh
+++ b/t/t6023-merge-file.sh
@@ -134,5 +134,10 @@ EOF
test_expect_success "expected conflict markers" "git diff expect out"
+test_expect_success 'binary files cannot be merged' '
+ ! git merge-file -p orig.txt ../test4012.png new1.txt 2> merge.err &&
+ grep "Cannot merge binary files" merge.err
+'
+
test_done
--
1.5.2.1.2626.ge1044-dirty
^ permalink raw reply related
* [PATCH 2/3] merge-recursive: refuse to merge binary files
From: Johannes Schindelin @ 2007-06-05 2:36 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
merge-recursive.c | 6 ++++++
t/t6024-recursive-merge.sh | 14 ++++++++++++++
2 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 4d70fd4..02c7983 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -658,6 +658,12 @@ static int ll_xdl_merge(const struct ll_merge_driver *drv_unused,
{
xpparam_t xpp;
+ if (buffer_is_binary(orig->ptr, orig->size) ||
+ buffer_is_binary(src1->ptr, src1->size) ||
+ buffer_is_binary(src2->ptr, src2->size))
+ return error("Cannot merge binary files: %s vs. %s\n",
+ name1, name2);
+
memset(&xpp, 0, sizeof(xpp));
return xdl_merge(orig,
src1, name1,
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
index a398556..058db9c 100755
--- a/t/t6024-recursive-merge.sh
+++ b/t/t6024-recursive-merge.sh
@@ -81,4 +81,18 @@ EOF
test_expect_success "virtual trees were processed" "git diff expect out"
+git reset --hard
+test_expect_success 'refuse to merge binary files' '
+ printf "\0" > binary-file &&
+ git add binary-file &&
+ git commit -m binary &&
+ git checkout G &&
+ printf "\0\0" > binary-file &&
+ git add binary-file &&
+ git commit -m binary2 &&
+ ! git merge F > merge.out 2> merge.err &&
+ grep "Cannot merge binary files: HEAD:binary-file vs. F:binary-file" \
+ merge.err
+'
+
test_done
--
1.5.2.1.2626.ge1044-dirty
^ permalink raw reply related
* [PATCH] git-fsck: learn about --verbose
From: Johannes Schindelin @ 2007-06-05 2:44 UTC (permalink / raw)
To: git, junkio; +Cc: Steven Grimm
With --verbose, it gets really chatty now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Steven Grimm on IRC said that this might come in handy someday,
although it did not help _his_ case.
Documentation/git-fsck.txt | 5 ++++-
builtin-fsck.c | 42 +++++++++++++++++++++++++++++++++++++++++-
2 files changed, 45 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index 8c68cf0..ed6413a 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git-fsck' [--tags] [--root] [--unreachable] [--cache] [--no-reflogs]
- [--full] [--strict] [<object>*]
+ [--full] [--strict] [--verbose] [<object>*]
DESCRIPTION
-----------
@@ -61,6 +61,9 @@ index file and all SHA1 references in .git/refs/* as heads.
objects that triggers this check, but it is recommended
to check new projects with this flag.
+--verbose::
+ Be chatty.
+
It tests SHA1 and general object sanity, and it does full tracking of
the resulting reachability and everything else. It prints out any
corruption it finds (missing or bad objects), and if you use the
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 9959818..bacae5d 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -20,6 +20,7 @@ static int check_strict;
static int keep_cache_objects;
static unsigned char head_sha1[20];
static int errors_found;
+static int verbose;
#define ERROR_OBJECT 01
#define ERROR_REACHABLE 02
@@ -149,6 +150,9 @@ static void check_unreachable_object(struct object *obj)
static void check_object(struct object *obj)
{
+ if (verbose)
+ fprintf(stderr, "Checking %s\n", sha1_to_hex(obj->sha1));
+
if (obj->flags & REACHABLE)
check_reachable_object(obj);
else
@@ -161,6 +165,9 @@ static void check_connectivity(void)
/* Look up all the requirements, warn about missing objects.. */
max = get_max_object_index();
+ if (verbose)
+ fprintf(stderr, "Checking connectivity (%d objects)\n", max);
+
for (i = 0; i < max; i++) {
struct object *obj = get_indexed_object(i);
@@ -229,6 +236,10 @@ static int fsck_tree(struct tree *item)
const char *o_name;
const unsigned char *o_sha1;
+ if (verbose)
+ fprintf(stderr, "Checking tree %s\n",
+ sha1_to_hex(item->object.sha1));
+
init_tree_desc(&desc, item->buffer, item->size);
o_mode = 0;
@@ -317,6 +328,10 @@ static int fsck_commit(struct commit *commit)
char *buffer = commit->buffer;
unsigned char tree_sha1[20], sha1[20];
+ if (verbose)
+ fprintf(stderr, "Checking commit %s\n",
+ sha1_to_hex(commit->object.sha1));
+
if (memcmp(buffer, "tree ", 5))
return objerror(&commit->object, "invalid format - expected 'tree' line");
if (get_sha1_hex(buffer+5, tree_sha1) || buffer[45] != '\n')
@@ -345,6 +360,10 @@ static int fsck_tag(struct tag *tag)
{
struct object *tagged = tag->tagged;
+ if (verbose)
+ fprintf(stderr, "Checking tag %s\n",
+ sha1_to_hex(tag->object.sha1));
+
if (!tagged) {
return objerror(&tag->object, "could not load tagged object");
}
@@ -446,6 +465,9 @@ static void fsck_dir(int i, char *path)
if (!dir)
return;
+ if (verbose)
+ fprintf(stderr, "Checking directory %s\n", path);
+
while ((de = readdir(dir)) != NULL) {
char name[100];
unsigned char sha1[20];
@@ -480,6 +502,10 @@ static int fsck_handle_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
{
struct object *obj;
+ if (verbose)
+ fprintf(stderr, "Checking reflog %s->%s\n",
+ sha1_to_hex(osha1), sha1_to_hex(nsha1));
+
if (!is_null_sha1(osha1)) {
obj = lookup_object(osha1);
if (obj) {
@@ -549,6 +575,10 @@ static void get_default_heads(void)
static void fsck_object_dir(const char *path)
{
int i;
+
+ if (verbose)
+ fprintf(stderr, "Checking object directory\n");
+
for (i = 0; i < 256; i++) {
static char dir[4096];
sprintf(dir, "%s/%02x", path, i);
@@ -564,6 +594,9 @@ static int fsck_head_link(void)
int null_is_error = 0;
const char *head_points_at = resolve_ref("HEAD", sha1, 0, &flag);
+ if (verbose)
+ fprintf(stderr, "Checking HEAD link\n");
+
if (!head_points_at)
return error("Invalid HEAD");
if (!strcmp(head_points_at, "HEAD"))
@@ -586,6 +619,9 @@ static int fsck_cache_tree(struct cache_tree *it)
int i;
int err = 0;
+ if (verbose)
+ fprintf(stderr, "Checking cache tree\n");
+
if (0 <= it->entry_count) {
struct object *obj = parse_object(it->sha1);
if (!obj) {
@@ -605,7 +641,7 @@ static int fsck_cache_tree(struct cache_tree *it)
static const char fsck_usage[] =
"git-fsck [--tags] [--root] [[--unreachable] [--cache] [--full] "
-"[--strict] <head-sha1>*]";
+"[--strict] [--verbose] <head-sha1>*]";
int cmd_fsck(int argc, char **argv, const char *prefix)
{
@@ -645,6 +681,10 @@ int cmd_fsck(int argc, char **argv, const char *prefix)
check_strict = 1;
continue;
}
+ if (!strcmp(arg, "--verbose")) {
+ verbose = 1;
+ continue;
+ }
if (*arg == '-')
usage(fsck_usage);
}
--
1.5.2.1.2626.ge1044-dirty
^ permalink raw reply related
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Johannes Schindelin @ 2007-06-05 2:56 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Linus Torvalds, Thomas Glanzmann, Bryan Childs, git
In-Reply-To: <20070604212121.GA31852@dspnet.fr.eu.org>
Hi,
On Mon, 4 Jun 2007, Olivier Galibert wrote:
> On Mon, Jun 04, 2007 at 01:45:26PM -0700, Linus Torvalds wrote:
>
> > I'd like to point out some more upsides and downsides of "git rebase".
> >
> > Downsides:
> >
> > - you're rewriting history, so you MUST NOT have made your pre-rebase
> > changes available publicly anywhere else (or you are in a world of
> > pain with duplicate history and tons of confusion)
>
> Wouldn't it be possible to register the rebase somewhere (weak parent?
> some kind of note not influencing the sha1 ?) that pull/merge could
> follow?
Actually, with reflogs (if you did not explicitely disable them), you
should have the information already.
> Rebases and cherry-picking are a special kind of merge, so maybe it can
> be handled like one where it counts...
There is something I have to add as a real disadvantage in rebase:
Usually you are expected to test your commits. So, say that you work on
some patch series, and produce 3 well tested patches. Then you fetch
upstream and realize it advanced by some commits, and rebase your three
patches.
However, _none_ of your patches is well tested, because there is a quite
real chance that your patches interact _badly_ with the patches you just
fetched.
And if that is the case, git-bisect can very well attribute it to a wrong
patch, either because more than one patch is bad, or because the last
patch in your series _exposes_ the bug (but does not _introduce_ it).
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-svn: allow to specify svn branch for commands
From: Sam Vilain @ 2007-06-05 3:42 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Central, stephen, Sam Vilain
"git-svn dcommit" ends up making an arbitrary decision when pushing
back merges. Allow the user to specify which one is used, albeit in a
rather hack-ish way.
---
Documentation/git-svn.txt | 11 +++++++++++
git-svn.perl | 16 +++++++++-------
2 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index c0d7d95..3e64522 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -69,6 +69,17 @@ COMMANDS
argument if that is what you want. This is useful if
you wish to track multiple projects that share a common
repository.
+-B<svn_branch>;;
+--branch=<svn_branch>;;
+ Normally, git-svn is capable of figuring out which branch you
+ are working on. However, if you are doing merges between svn
+ branches using git then the decision about which branch to
+ dcommit to will end up being made based on which of the
+ branches you are merging has the newest upstream commit. This
+ option enables a global filter that tells git-svn what to look
+ for in the git-svn-id: line - specify a repository UUID or a
+ branch name here. So, it may be used with "git-svn log",
+ "git-svn dcommit", etc.
'fetch'::
Fetch unfetched revisions from the Subversion remote we are
diff --git a/git-svn.perl b/git-svn.perl
index e350061..b667f80 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -54,7 +54,7 @@ $sha1 = qr/[a-f\d]{40}/;
$sha1_short = qr/[a-f\d]{4,40}/;
my ($_stdin, $_help, $_edit,
$_message, $_file,
- $_template, $_shared,
+ $_template, $_shared, $_branch,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_verbose);
@@ -69,6 +69,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'useSvmProps' => \$Git::SVN::_use_svm_props,
'useSvnsyncProps' => \$Git::SVN::_use_svnsync_props,
'log-window-size=i' => \$Git::SVN::Ra::_log_window_size,
+ 'branch|B=s' => \$_branch,
'no-checkout' => \$_no_checkout,
'quiet|q' => \$_q,
'repack-flags|repack-args|repack-opts=s' =>
@@ -367,7 +368,7 @@ sub cmd_dcommit {
my $head = shift;
$head ||= 'HEAD';
my @refs;
- my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
+ my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs, $_branch);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"$head history\n";
@@ -441,7 +442,7 @@ sub cmd_find_rev {
my $head = shift;
$head ||= 'HEAD';
my @refs;
- my (undef, undef, undef, $gs) = working_head_info($head, \@refs);
+ my (undef, undef, undef, $gs) = working_head_info($head, \@refs, $_branch);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"$head history\n";
@@ -457,7 +458,7 @@ sub cmd_find_rev {
sub cmd_rebase {
command_noisy(qw/update-index --refresh/);
- my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD', undef, $_branch);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"working tree history\n";
@@ -474,7 +475,7 @@ sub cmd_rebase {
}
sub cmd_show_ignore {
- my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD', undef, $_branch);
$gs ||= Git::SVN->new;
my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
$gs->traverse_ignore(\*STDOUT, $gs->{path}, $r);
@@ -801,11 +802,12 @@ sub cmt_metadata {
}
sub working_head_info {
- my ($head, $refs) = @_;
+ my ($head, $refs, $grep) = @_;
my ($fh, $ctx) = command_output_pipe('rev-list', $head);
while (my $hash = <$fh>) {
chomp($hash);
my ($url, $rev, $uuid) = cmt_metadata($hash);
+ next unless (!$grep or $url =~ m{$grep} or $uuid =~ m{$grep});
if (defined $url && defined $rev) {
if (my $gs = Git::SVN->find_by_url($url)) {
my $c = $gs->rev_db_get($rev);
@@ -3394,7 +3396,7 @@ sub git_svn_log_cmd {
last;
}
- my ($url, $rev, $uuid, $gs) = ::working_head_info($head);
+ my ($url, $rev, $uuid, $gs) = ::working_head_info($head, undef, $_branch);
$gs ||= Git::SVN->_new;
my @cmd = (qw/log --abbrev-commit --pretty=raw --default/,
$gs->refname);
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: Linus Torvalds @ 2007-06-05 3:58 UTC (permalink / raw)
To: david; +Cc: Daniel Barkalow, Bryan Childs, git
In-Reply-To: <Pine.LNX.4.64.0706041841010.6705@asgard.lang.hm>
On Mon, 4 Jun 2007, david@lang.hm wrote:
>
> if you put the binaries in a seperate repository and do shallow clones to
> avoid getting all the old stuff wouldn't that work well?
Yes. I'm not a huge fan of shallow clones, and I suspect they've not
gotten all that much testing, but that would certainly solve the problem
of getting unnecessarily much data..
Linus
^ permalink raw reply
* Re: [PATCH 3/3] git-merge-file: refuse to merge binary files
From: Linus Torvalds @ 2007-06-05 4:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.64.0706050337010.4046@racer.site>
I really think this would be better off using the crlf-like heuristics.
It's entirely possible that the "NUL character in the first X bytes"
heuristic is wrong for some cases, so I find it a bit nasty to hardcoding
it as the only rule for "it must be binary"
Linus
^ permalink raw reply
* Re: [PATCH] git-svn: allow to specify svn branch for commands
From: Eric Wong @ 2007-06-05 4:14 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Central, stephen
In-Reply-To: <1181014957993-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> "git-svn dcommit" ends up making an arbitrary decision when pushing
> back merges. Allow the user to specify which one is used, albeit in a
> rather hack-ish way.
Frightening... Perhaps we should echo the final URL out
to the user and prompt them for confirmation.
> ---
> Documentation/git-svn.txt | 11 +++++++++++
> git-svn.perl | 16 +++++++++-------
> 2 files changed, 20 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index c0d7d95..3e64522 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -69,6 +69,17 @@ COMMANDS
> argument if that is what you want. This is useful if
> you wish to track multiple projects that share a common
> repository.
> +-B<svn_branch>;;
> +--branch=<svn_branch>;;
> + Normally, git-svn is capable of figuring out which branch you
> + are working on. However, if you are doing merges between svn
> + branches using git then the decision about which branch to
> + dcommit to will end up being made based on which of the
> + branches you are merging has the newest upstream commit. This
> + option enables a global filter that tells git-svn what to look
> + for in the git-svn-id: line - specify a repository UUID or a
> + branch name here. So, it may be used with "git-svn log",
> + "git-svn dcommit", etc.
This should clarify that a Perl regular expression is used.
'.' can match '-' or '_' which is also pretty common in version
numbers. Perhaps give an -F(ixed-string) option like grep does?
> sub working_head_info {
> - my ($head, $refs) = @_;
> + my ($head, $refs, $grep) = @_;
> my ($fh, $ctx) = command_output_pipe('rev-list', $head);
> while (my $hash = <$fh>) {
> chomp($hash);
> my ($url, $rev, $uuid) = cmt_metadata($hash);
> + next unless (!$grep or $url =~ m{$grep} or $uuid =~ m{$grep});
> @@ -3394,7 +3396,7 @@ sub git_svn_log_cmd {
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-svn: allow to specify svn branch for commands
From: Stephen Touset @ 2007-06-05 4:16 UTC (permalink / raw)
To: Sam Vilain; +Cc: Eric Wong, Git Central
In-Reply-To: <1181014957993-git-send-email-sam.vilain@catalyst.net.nz>
[-- Attachment #1: Type: text/plain, Size: 534 bytes --]
On Tue, 2007-06-05 at 15:42 +1200, Sam Vilain wrote:
> "git-svn dcommit" ends up making an arbitrary decision when pushing
> back merges. Allow the user to specify which one is used, albeit in a
> rather hack-ish way.
I've been thinking about this. I'm rather new to git internals, but if
I've created a local copy of a remote branch (git-checkout -b
local-branch --track remote-branch), can't git-svn use the tracking
metadata to determine which part of the tree to dcommit to?
--
Stephen Touset <stephen@touset.org>
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-svn: allow to specify svn branch for commands
From: Sam Vilain @ 2007-06-05 4:23 UTC (permalink / raw)
To: Eric Wong; +Cc: Sam Vilain, Git Central, stephen, Jonathan Rockway
In-Reply-To: <20070605041446.GA4266@untitled>
Eric Wong wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
>> "git-svn dcommit" ends up making an arbitrary decision when pushing
>> back merges. Allow the user to specify which one is used, albeit in a
>> rather hack-ish way.
>
> Frightening... Perhaps we should echo the final URL out
> to the user and prompt them for confirmation.
Actually in between sending this to the list, I figured that it should
be possible to detect when this is happening, at the expense of an extra
"git-log" command. Basically, take the first revision you found a
commitlog entry in, and then do a log from the indicated head excluding
that commit. If you find more valid tips then the user is merging in
gitspace.
Of course ideally you want to make sure that merge commits posted back
are shipped with all of the necessary tokens for the various SVN-land
tools out there. eg, svk:merge, svnmerge, and whatever kooky system the
SVN dev team come up with. But that's a separate issue.
The original patch had a fairly dire bug, so here's a version that at
least doesn't break the test suite.
Subject: [PATCH] git-svn: allow to specify svn branch for commands
"git-svn dcommit" ends up making an arbitrary decision when pushing
back merges. Allow the user to specify which one is used, albeit in a
rather hack-ish way.
---
Documentation/git-svn.txt | 11 +++++++++++
git-svn.perl | 17 ++++++++++-------
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index c0d7d95..3e64522 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -69,6 +69,17 @@ COMMANDS
argument if that is what you want. This is useful if
you wish to track multiple projects that share a common
repository.
+-B<svn_branch>;;
+--branch=<svn_branch>;;
+ Normally, git-svn is capable of figuring out which branch you
+ are working on. However, if you are doing merges between svn
+ branches using git then the decision about which branch to
+ dcommit to will end up being made based on which of the
+ branches you are merging has the newest upstream commit. This
+ option enables a global filter that tells git-svn what to look
+ for in the git-svn-id: line - specify a repository UUID or a
+ branch name here. So, it may be used with "git-svn log",
+ "git-svn dcommit", etc.
'fetch'::
Fetch unfetched revisions from the Subversion remote we are
diff --git a/git-svn.perl b/git-svn.perl
index e350061..906aa4b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -54,7 +54,7 @@ $sha1 = qr/[a-f\d]{40}/;
$sha1_short = qr/[a-f\d]{4,40}/;
my ($_stdin, $_help, $_edit,
$_message, $_file,
- $_template, $_shared,
+ $_template, $_shared, $_branch,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_verbose);
@@ -69,6 +69,7 @@ my %fc_opts = ( 'follow-parent|follow!' => \$Git::SVN::_follow_parent,
'useSvmProps' => \$Git::SVN::_use_svm_props,
'useSvnsyncProps' => \$Git::SVN::_use_svnsync_props,
'log-window-size=i' => \$Git::SVN::Ra::_log_window_size,
+ 'branch|B=s' => \$_branch,
'no-checkout' => \$_no_checkout,
'quiet|q' => \$_q,
'repack-flags|repack-args|repack-opts=s' =>
@@ -367,7 +368,7 @@ sub cmd_dcommit {
my $head = shift;
$head ||= 'HEAD';
my @refs;
- my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs);
+ my ($url, $rev, $uuid, $gs) = working_head_info($head, \@refs, $_branch);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"$head history\n";
@@ -441,7 +442,7 @@ sub cmd_find_rev {
my $head = shift;
$head ||= 'HEAD';
my @refs;
- my (undef, undef, undef, $gs) = working_head_info($head, \@refs);
+ my (undef, undef, undef, $gs) = working_head_info($head, \@refs, $_branch);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"$head history\n";
@@ -457,7 +458,7 @@ sub cmd_find_rev {
sub cmd_rebase {
command_noisy(qw/update-index --refresh/);
- my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD', undef, $_branch);
unless ($gs) {
die "Unable to determine upstream SVN information from ",
"working tree history\n";
@@ -474,7 +475,7 @@ sub cmd_rebase {
}
sub cmd_show_ignore {
- my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
+ my ($url, $rev, $uuid, $gs) = working_head_info('HEAD', undef, $_branch);
$gs ||= Git::SVN->new;
my $r = (defined $_revision ? $_revision : $gs->ra->get_latest_revnum);
$gs->traverse_ignore(\*STDOUT, $gs->{path}, $r);
@@ -801,12 +802,14 @@ sub cmt_metadata {
}
sub working_head_info {
- my ($head, $refs) = @_;
+ my ($head, $refs, $grep) = @_;
my ($fh, $ctx) = command_output_pipe('rev-list', $head);
while (my $hash = <$fh>) {
chomp($hash);
my ($url, $rev, $uuid) = cmt_metadata($hash);
if (defined $url && defined $rev) {
+ next unless (!$grep or
+ $url =~ m{$grep} or $uuid =~ m{$grep});
if (my $gs = Git::SVN->find_by_url($url)) {
my $c = $gs->rev_db_get($rev);
if ($c && $c eq $hash) {
@@ -3394,7 +3397,7 @@ sub git_svn_log_cmd {
last;
}
- my ($url, $rev, $uuid, $gs) = ::working_head_info($head);
+ my ($url, $rev, $uuid, $gs) = ::working_head_info($head, undef, $_branch);
$gs ||= Git::SVN->_new;
my @cmd = (qw/log --abbrev-commit --pretty=raw --default/,
$gs->refname);
--
1.5.2.0.45.gfea6d-dirty
^ permalink raw reply related
* Re: Improved git-gui blame viewer
From: Shawn O. Pearce @ 2007-06-05 4:28 UTC (permalink / raw)
To: Matthijs Melchior; +Cc: git
In-Reply-To: <4664838C.8000109@xs4all.nl>
Matthijs Melchior <mmelchior@xs4all.nl> wrote:
> Shawn O. Pearce wrote:
> > I'm not sure I understand what you are looking for here. Right now
> > git-gui should be inverting the foreground/background colors on
> > the file that is "selected" (shown in the lower diff view pane).
> > So the background should be black, and the foreground white.
> > Is this not happening? Or are you looking for something else?
> >
>
> No, I am not looking for something else...., the inverting you describe
> does not happen on my machine....
I'm wrong. Its not inverting. Its bold if its selected, and normal
if its not selected. Perhaps your font is already a bold weight
so you aren't seeing a difference between the selected item and
the non-selected items.
> I am now running Debian git-core 1.5.2.1-1 with 'make install' done
> in the origin/pu branch of git-gui.
> 'About git-gui' now says:
> git-gui version 0.7.2.58-gf9e9
> git version 1.5.2.1
> Tcl/Tk version 8.4.12
>
> If you explain where this inverting is taking place, I can do some
> experiments to find out more [use gray background i.s.o. inverting...]
> Maybe it has something to do with Desktop themes, I use the standard
> Gnome theme.
Around line 1803 of git-gui.sh we setup the in_diff tag for the
$ui_index and $ui_workdir Tk widgets. That tag is applied to the
file that is in the diff viewer. Perhaps adding a background to
the tag would get you an improved interface?
--
Shawn.
^ permalink raw reply
* Re: Improved git-gui blame viewer
From: Shawn O. Pearce @ 2007-06-05 4:38 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0706040910w1894770bm593e0e54fbb3c44@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> wrote:
> On 6/2/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> >
> >I finally got the git-gui code to the point where cleaning up the
> >user interface was possible without sending myself to the nut house.
> >
>
> Very-very nice :)
Thanks. I'm not done yet. There's a lot of interesting navigation
I still want to get in, like visting the parent of a changed line,
instead of the commit that changed that line. I also want to let
you open commits in a new window, rather than the current one.
> Does not seem to save sizes and positions of
> blame and file browser windows, though. It did before, I believe
> in .git/config.
Actually we have never saved the window sizes/positions of the
blame and browser windows, only the main commit window. Though
you may have been seeing a bug where we restored the main commit
window's saved geometry on a browser or blame window if the latter
was started from the command line...
> BTW, saving windows positions in .git/config was scary: I
> considered it user domain (yes, I _am_ afraid of using
> git-config too).
> Maybe it could be something like either ~/.git-gui or .git/guiconfig?
I'm apparently not afraid of git-config editing file(s). I have
yet to see a failure from it. I guess I'm lucky, but will now
suffer a failure tomorrow when I'm least expecting it. ;-)
Don't we use git-config to edit the config file in git-branch?
In git-remote? git-gui has *always* used git-config to store
its data. You are sort of asking me to replace a working config
system with a new one that hasn't been tested...
Now moving the git-gui config to say ~/.gitgui-config and
.git/gitgui-config may have a good argument, as then git-gui
is editing its own files. Unless the user changes user.name
or user.email through git-gui, in which case we have to edit
.git/config or ~/.gitconfig anyway...
--
Shawn.
^ permalink raw reply
* Re: clarify git clone --local --shared --reference
From: Shawn O. Pearce @ 2007-06-05 4:50 UTC (permalink / raw)
To: Brandon Casey; +Cc: git
In-Reply-To: <4664A5FE.30208@nrlssc.navy.mil>
Brandon Casey <casey@nrlssc.navy.mil> wrote:
>
> I think the goal of these three objects is space savings (and speed),
> but I don't understand when I should prefer one option over another, or
> when/whether to use a combination of them. And I am unsure (SCARED)
> about any side effects they may have.
Yes, they are mainly about saving time setting up the new clone,
and about disk space required by the new clone.
> 1) What does local mean?
> --local says repository must be on the "local" machine and claims it
> attempts to make hardlinks when possible. Of course hard links cannot
> be created across filesystems, so are there other speedups/space
> savings when repository is on local machine but not on the same
> filesystem? Is this option still valid then?
Basically --local means instead of using the native Git transport to
copy object data from one repository to another we shortcut and use
`find . | cpio -lpumd` or somesuch, so that cpio can use hardlinks if
possible (same filesystem) but fallback to whole copy if it cannot.
This is usually faster than the native Git transport as we copy
every file, without first trying to compute if the file would be
needed by the new clone or not.
So --local may copy garbage that git-prune would have removed,
or that git-repack/git-gc might have eliminated from a packfile.
But generally that's such a small amount of data that the faster
cpio path (and even better, the hardlinks) saves disk.
Note we only hardlink the immutable data under .git/objects; the
mutable data and the working directory files that are checked out
are *not* hardlinked.
> 2) Does --shared imply shared write access? Does --local?
> I'll point out that git-init has an option with the same name.
No. --shared means something entirely different in git-clone
than it does in git-init.
The --shared here implies adds the source repository to the new
repository's .git/objects/info/alternates. This means that the
new clone doesn't copy the object database; instead it just accesses
the source repository when it needs data.
This exposes two risks:
a) Don't delete the source repository. If you delete the source
repository then the clone repository is "corrupt" as it won't be
able to access object data.
b) Don't repack the source repository without accounting for the
refs and reflogs of all --shared repositories that came from it.
Otherwise you may delete objects that the source repository no
longer needs, but that one or more of the --shared repositories
still needs.
Objects that are newly created in a --shared repository are written
in the --shared area, not in the source repository. Hence the
source repository can be read-only to the current user.
> 3) --shared seems like a special case of --reference? Are there
> differences?
--reference is actually a special case of --shared. --reference is
meant for cloning a remote repository over the network, where you
already have an existing local repository that has most of the
objects you need to successfully clone the remote repository.
With --reference we setup a temporary copy of refs from the
--reference repository in the new repository, so that during the
network transfer from the remote system we don't download things
the --reference repository already has.
But --reference implies --shared, and has the same issues as above.
> 4) what happens if the source repository dissappears? Is --local ok
> but --shared screwed?
Correct.
> 4) is space savings obtained only at initial clone? or is it on going?
> does a future git pull from the source repository create new hard
> links where possible?
Only on initial clone. Later pulls will copy. You can try using
git-relink to redo the hardlinks after the pull.
> Can --shared be used with --reference. Can --reference be used multiple
> times (and would I want to). Does -l with -s get you anything? (the
> examples use this)
--reference can only be given once in a git-clone; we only setup
one set of temporary references during the network transfer.
And as I said above, --reference implies --shared.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] git-merge-file: refuse to merge binary files
From: Johannes Schindelin @ 2007-06-05 5:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, junkio
In-Reply-To: <alpine.LFD.0.98.0706042059420.23741@woody.linux-foundation.org>
Hi,
On Mon, 4 Jun 2007, Linus Torvalds wrote:
> I really think this would be better off using the crlf-like heuristics.
I don't know. Given that it took quite a while to actually hit this bug...
> It's entirely possible that the "NUL character in the first X bytes"
> heuristic is wrong for some cases, so I find it a bit nasty to
> hardcoding it as the only rule for "it must be binary"
Yes, you're right.
However, if you call git-merge-file, you have to be aware of what it does.
It is a _standalone_ program, meant to make it easier to write scripts.
Maybe it is not worth detecting binary files _at all_ in merge-file.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] git-merge-file: refuse to merge binary files
From: Junio C Hamano @ 2007-06-05 5:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.LFD.0.98.0706042059420.23741@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I really think this would be better off using the crlf-like heuristics.
>
> It's entirely possible that the "NUL character in the first X bytes"
> heuristic is wrong for some cases, so I find it a bit nasty to hardcoding
> it as the only rule for "it must be binary"
>
> Linus
On the other hand that hardcoded fallback is consistent with
diff, which is closely related to xdl_merge(). Attributes can
be specified to override this anyway, so...
^ permalink raw reply
* Re: [PATCH 3/3] git-merge-file: refuse to merge binary files
From: Junio C Hamano @ 2007-06-05 5:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706050337010.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> builtin-merge-file.c | 6 +++++-
> t/t6023-merge-file.sh | 5 +++++
> 2 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-merge-file.c b/builtin-merge-file.c
> index 9135773..10ec63b 100644
> --- a/builtin-merge-file.c
> +++ b/builtin-merge-file.c
> @@ -36,9 +36,13 @@ int cmd_merge_file(int argc, char **argv, char **envp)
> for (; i < 3; i++)
> names[i] = argv[i + 1];
>
> - for (i = 0; i < 3; i++)
> + for (i = 0; i < 3; i++) {
> if (read_mmfile(mmfs + i, argv[i + 1]))
> return -1;
> + if (buffer_is_binary(mmfs[i].ptr, mmfs[i].size))
> + return error("Cannot merge binary files: %s\n",
> + argv[i + 1]);
> + }
>
> ret = xdl_merge(mmfs + 1, mmfs + 0, names[0], mmfs + 2, names[2],
> &xpp, XDL_MERGE_ZEALOUS, &result);
Oh, my.
I wonder if we can expose ll_merge() from merge-recursive to
this part, instead of raw xdl_merge(). That would give you the
custom merge driver the user may have specified in
.gitattributes.
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Marco Costalba @ 2007-06-05 5:50 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Pavel Roskin, Jan Hudec
In-Reply-To: <200706042004.01819.andyparkins@gmail.com>
On 6/4/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Monday 2007, June 04, Marco Costalba wrote:
>
> > P.S: Your approach is simple and good, the only downside is the
> > screen estate taken by the tab bar. But I agree it's absolutly not a
> > biggie.
>
> Yeah, that is a bit of a drawback. How about not putting the tabs on
> the top or bottom, but on the left or right? In fact if you put them
> on the right, they'd be almost exactly where your jump labels would be.
>
Andy, another point scored for you!
I will do exactly that!
Now the only drawback it remains (more "mental" then real) is that the
user already scrolls down to read the message / patch and, at the end,
it's easier to just continue scrolling to jump to next/previous
revision then move the mouse to point the tab, click, and go back to
start scrolling again: a finger against a double hand movment + click.
Yes, I know, I'm veeery lazy ;-)
Marco
^ permalink raw reply
* Re: How to use git-svn to clone from a mirror?
From: David Kastrup @ 2007-06-05 6:41 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0706041906570.4046@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 4 Jun 2007, Raja R Harinath wrote:
>
>> David Kastrup <dak@gnu.org> writes:
>>
>> > I have used something like
>> >
>> > git-svn clone -T trunk -b branches -t tags file:///tmp/rsync-mirror
>> >
>> > to clone an rsync mirror of an SVN repository. Now I want to have
>> > fetch revert to pulling from the upstream repository in future.
>> > However, if I change the respective line in .git/config to
>> > svn://the.svn.link/whatever, git-rebase will fetch the right updates,
>> > but then says that it can't work with the objects in the git
>> > repository.
>> >
>> > Changing the config back will make git-rebase -l work.
>> >
>> > So what would be the right procedure to shift the SVN source from an
>> > rsync mirror to the original, without git-svn breaking?
>>
>> I think you'll have to
>>
>> -------------8<------------
>> # remove stored revision db, since we're going to change all the commit ids
>> rm .git/svn/git-svn/.rev_db.*
>>
>> # rewrite git-svn-id: lines
>> cg-admin-rewritehist \
>> --msg-filter \
>> 'sed "s,file:///tmp/rsync-mirror,svn://the.svn.link/whatever,"'
>>
>> # recreate new revision db, and fetch updates, if any
>> git-svn rebase
>> -------------8<------------
>
> <shameless plug>
> Or you use the just-rewritten version of it, git-filter-branch.
> </shameless>
Well, part of the reason I worked from an rsynced copy was to be able
to repeat the experiment by just wasting a few hours of time each
time, without wasting more bandwidth.
What I arrived at was to use
git-svn init -T trunk -t tags -b branches
--rewrite-root svn://tug.org/texlive file:///mirror/texlive
git-svn fetch --all
[edit .git/config and replace the url and rewrite-root lines with a
single url line pointing to the root]
git-reset --hard [don't ask me why]
and afterwards fetches worked online.
I liked the commit messages when using --no-metadata better than with
--rewrite-root, but I found no way to get the resulting archive
operative for git-svn rebase afterwards.
Could someone explain to me why git needs to know the upstream URL
history, whether by --rewrite-root or rewrite-hist or
git-filter-branch?
I find this rather hard to understand, so I would like to get an idea
where this fits naturally into the overall design of git, and how it
makes sense.
Thanks,
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 4/4] Add new --diff-opts/-O flag to diff- and status-related commands.
From: Yann Dirson @ 2007-06-05 6:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <b0943d9e0706041515l6114a015ye45d40478cc0e3ef@mail.gmail.com>
On Mon, Jun 04, 2007 at 11:15:23PM +0100, Catalin Marinas wrote:
> On 31/05/07, Yann Dirson <ydirson@altern.org> wrote:
> >This new flag allows to pass arbitrary flags to the git-diff calls
> >underlying several StGIT commands. It can be used to pass flags
> >affecting both diff- and status-generating commands (eg. -M or -C), or
> >flags only affecting diff-generating ones (eg. --color, --binary).
> >
> >It supercedes --binary for commands where it was allowed,
> >'-O --binary' is now available for the same functionality.
>
> BTW, should we add --binary by default to export and mail? Do you see
> any problem with this?
>
> Another idea would be to add support for a [stgit "options"] section
> with entries like "mail = -O --binary".
Right, but we have to think how flags in the config file interact with
flags on command line.
- does the command line shadow the config file completely (ie. "-O ''"
can be used for to not pass any flags), in which case, each time we
want a particular flag we need to pass all default ones again ?
- does the command line add to the flags specified from config file,
in which case we still need a way to override those ; I have 2 ideas
here: a flag that resets opts to '', or a flag to remove specific
flags (eg. if we have '--binary -w' in the config and we want
'--binary -C', we can say something like '-O -C --no-diff-opts -w').
Also useful would be to have different config defaults for the case
where we go through the pager, but then we may have to guess when the
pager will trigger (or maybe we can ask pydoc if the pager will
trigger ?).
Best regards,
--
Yann
^ 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