* Re: bzr to git syncing
From: Alex Bennee @ 2009-08-28 17:47 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, David Reitter
In-Reply-To: <fabb9a1e0908280919o412baeb1ka69968a93297ca59@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
2009/8/28 Sverre Rabbelier <srabbelier@gmail.com>:
> Heya,
>
> On Fri, Aug 28, 2009 at 09:02, Alex Bennee<kernel-hacker@bennee.com> wrote:
>> I've attached the fast-import crash I'm seeing. Are you seeing the
>> same sort of failure?
>
> The program you used to generate the stream (I assume git-bzr?) is
> generating an invalid mode, git understands '100644', '100755',
> '120000', and '160000'; the mode in the stream, '040000', is not
> something we understand.
Yeah, it seems in bzr land it mean new directory which we don't care
about. The following patch makes it work. Apologies for failure to
inline but Gmail would just corrupt it if I tried.
I also had to patch the ref check code to accept bzr style branch
names but I suspect that patch should be kept out of the repo.
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
[-- Attachment #2: 0001-Handle-new-directory-commands-from-a-bzr-fast-export.patch --]
[-- Type: application/x-httpd-php, Size: 1071 bytes --]
[-- Attachment #3: 0002-Allow-in-a-branch-name.patch --]
[-- Type: application/x-httpd-php, Size: 1086 bytes --]
^ permalink raw reply
* [RFC PATCH] upload-pack: expand capability advertises additional refs
From: Shawn O. Pearce @ 2009-08-28 17:30 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin
In-Reply-To: <20090826021057.GL1033@spearce.org>
The expand capability and associated command permits the client
to ask for information about refs which were not in the initial
advertisement sent when the connection was first opened.
In the below exchange the server initially only advertises its
current HEAD, refs/heads and refs/tags namespaces. However,
the client has been instructed to fetch anything which matches
refs/remotes/jc/*.
Since no matching refs appeared in the initial advertisement,
the client requests the server to expand the desired pattern,
and terminates its expand request list with a flush.
Upon receiving a flush from the client, the server displays any
local refs which match any of the expand patterns requested,
and then closes this secondary advertisement list with a flush.
If no refs matched, the server immediately returns a flush.
If multiple expand patterns match the same ref, the ref is returned
only once in the secondary advertisement, avoid confusing the client
with duplicate results.
S: 008f... HEAD\0...include-tag expand
S: 0043... refs/heads/build-next
S: 0040... refs/tags/v1.6.4.1
S: 0043... refs/tags/v1.6.4.1^{}
S: 0000
C: 001dexpand refs/remotes/jc/*
C: 0000
S: 0043... refs/remotes/jc/maint
S: 0044... refs/remotes/jc/master
S: 0000
C: 0031want ...
C: 0000
Repository owners can control the set of refs which are sent as part
of the initial advertisement by configuring upload.advertise in the
repository configuration file. If not set this is assumed to be
"refs/*", matching the prior behavior of advertising every local ref.
Fetch clients which are not using the anonymous git:// protocol
and which do not support the expand protocol extension may still
force the server to expand its configured upload.advertise set by
passing the --expand=<pattern> command line flag as part of the
--upload-pack= command line given to clone or fetch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
This is roughly my final server side version of this proposal.
I still need to write the client code, but want to at least get
this out there for further discussion.
Documentation/config.txt | 10 +++
Documentation/git-upload-pack.txt | 10 +++-
upload-pack.c | 131 +++++++++++++++++++++++++++++++++++--
3 files changed, 143 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..07907b6 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1489,6 +1489,16 @@ transfer.unpackLimit::
not set, the value of this variable is used instead.
The default value is 100.
+upload.advertise::
+ The default set of refs to advertise when a fetch or
+ clone client connects to this repository. Additional
+ local refs not in the default advertisement can still
+ be guessed and requested by clients through additional
+ network round trips. Refs may be expressed as a complete
+ name ("refs/heads/master") or as a pattern expected by
+ remote.<name>.fetch (such as "refs/heads/*"). If not
+ specified, all refs are advertised ("refs/*").
+
url.<base>.insteadOf::
Any URL that starts with this value will be rewritten to
start, instead, with <base>. In cases where some site serves a
diff --git a/Documentation/git-upload-pack.txt b/Documentation/git-upload-pack.txt
index b8e49dc..4cd9cc0 100644
--- a/Documentation/git-upload-pack.txt
+++ b/Documentation/git-upload-pack.txt
@@ -8,7 +8,7 @@ git-upload-pack - Send objects packed back to git-fetch-pack
SYNOPSIS
--------
-'git upload-pack' [--strict] [--timeout=<n>] <directory>
+'git upload-pack' [--strict] [--timeout=<n>] [--expand=<pattern> ...] <directory>
DESCRIPTION
-----------
@@ -30,6 +30,14 @@ OPTIONS
--timeout=<n>::
Interrupt transfer after <n> seconds of inactivity.
+--expand=<pattern>::
+ Expand the requested pattern and advertise matching refs,
+ even if those refs were not matched by upload.advertise.
+ This option may be repeated to request expansion of more
+ than one pattern. This option is intended only as an
+ escape hatch for older clients to fetch from a server
+ which has hidden interesting refs.
+
<directory>::
The repository to sync from.
diff --git a/upload-pack.c b/upload-pack.c
index 4d8be83..890c1c5 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -10,6 +10,8 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "remote.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=nn] <dir>";
@@ -30,6 +32,19 @@ static int multi_ack, nr_our_refs;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
static int shallow_nr;
+
+struct adv_ref {
+ struct adv_ref *next;
+ char *name;
+ unsigned pattern:1;
+};
+static struct adv_ref *to_advertise;
+static struct adv_ref **advertise_tail = &to_advertise;
+static int configured_advertise;
+
+static struct ref *local_refs;
+static struct ref **refs_tail = &local_refs;
+
static struct object_array have_obj;
static struct object_array want_obj;
static unsigned int timeout;
@@ -470,6 +485,69 @@ static int get_common_commits(void)
}
}
+static void push_advertise(const char *name)
+{
+ struct adv_ref *adv = xcalloc(1, sizeof(*adv));
+ adv->name = xstrdup(name);
+ adv->pattern = !!strchr(adv->name, '*');
+ *advertise_tail = adv;
+ advertise_tail = &adv->next;
+}
+
+static int upload_pack_config(const char *var, const char *value, void *cb)
+{
+ if (strcmp(var, "upload.advertise") == 0) {
+ configured_advertise = 1;
+ push_advertise(value);
+ return 0;
+ }
+
+ return git_default_config(var, value, cb);
+}
+
+static int send_ref(struct string_list_item *item, void *cb_data);
+static void send_refs(void)
+{
+ struct ref *to_send = NULL, **tail = &to_send;
+ struct ref *ref;
+ struct adv_ref *adv, *next_adv;
+ struct string_list sorted_names;
+
+ for (adv = to_advertise; adv; adv = next_adv) {
+ struct refspec spec;
+
+ memset(&spec, 0, sizeof(spec));
+ spec.pattern = adv->pattern;
+ spec.src = adv->name;
+ spec.dst = adv->name;
+ next_adv = adv->next;
+ get_fetch_map(local_refs, &spec, &tail, 1);
+
+ free(adv->name);
+ free(adv);
+ }
+ to_advertise = NULL;
+ advertise_tail = &to_advertise;
+
+ /* We may have duplicate copies of the same ref above, if
+ * two advertise records matched the same local name. To
+ * avoid sending the same ref twice to the client, we put
+ * them into a sorted list and then skip duplicates as we
+ * output them.
+ */
+ memset(&sorted_names, 0, sizeof(sorted_names));
+ for (ref = to_send; ref; ref = ref->next)
+ string_list_append(ref->name, &sorted_names)->util = ref;
+ sort_string_list(&sorted_names);
+
+ ref = NULL;
+ for_each_string_list(send_ref, &sorted_names, &ref);
+
+ string_list_clear(&sorted_names, 0);
+ free_refs(to_send);
+ packet_flush(1);
+}
+
static void receive_needs(void)
{
struct object_array shallows = {0, 0, NULL};
@@ -484,11 +562,22 @@ static void receive_needs(void)
unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
- if (!len)
+ if (!len) {
+ if (to_advertise) {
+ send_refs();
+ continue;
+ }
break;
+ }
if (debug_fd)
write_in_full(debug_fd, line, len);
+ if (!prefixcmp(line, "expand ")) {
+ if (line[len - 1] == '\n')
+ line[len - 1] = 0;
+ push_advertise(line + 7);
+ continue;
+ }
if (!prefixcmp(line, "shallow ")) {
unsigned char sha1[20];
struct object *object;
@@ -603,13 +692,22 @@ static void receive_needs(void)
free(shallows.objects);
}
-static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+static int send_ref(struct string_list_item *item, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
- " include-tag";
- struct object *o = parse_object(sha1);
+ " include-tag expand";
+ struct ref **last_ref = cb_data;
+ struct ref *ref = item->util;
+ const char *refname = ref->name;
+ const unsigned char *sha1 = ref->new_sha1;
+ struct object *o;
+
+ if (*last_ref && !strcmp(refname, (*last_ref)->name))
+ return 0;
+ *last_ref = ref;
+ o = parse_object(sha1);
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
@@ -631,12 +729,26 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int scan_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct ref *r = alloc_ref(refname);
+ hashcpy(r->new_sha1, sha1);
+ *refs_tail = r;
+ refs_tail = &r->next;
+ return 0;
+}
+
static void upload_pack(void)
{
+ git_config(upload_pack_config, NULL);
+ if (!configured_advertise)
+ push_advertise("refs/*");
+
+ head_ref(scan_ref, NULL);
+ for_each_ref(scan_ref, NULL);
+
reset_timeout();
- head_ref(send_ref, NULL);
- for_each_ref(send_ref, NULL);
- packet_flush(1);
+ send_refs();
receive_needs();
if (want_obj.nr) {
get_common_commits();
@@ -652,6 +764,7 @@ int main(int argc, char **argv)
git_extract_argv0_path(argv[0]);
read_replace_refs = 0;
+ push_advertise("HEAD");
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -667,6 +780,10 @@ int main(int argc, char **argv)
daemon_mode = 1;
continue;
}
+ if (!prefixcmp(arg, "--expand=")) {
+ push_advertise(arg + 9);
+ continue;
+ }
if (!strcmp(arg, "--")) {
i++;
break;
--
1.6.4.1.341.gf2a44
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Nicolas Pitre @ 2009-08-28 17:28 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, David Reiss, git
In-Reply-To: <20090828150212.GA6013@coredump.intra.peff.net>
On Fri, 28 Aug 2009, Jeff King wrote:
> On Fri, Aug 28, 2009 at 09:58:27AM +0200, Alex Riesen wrote:
>
> > > I couldn't find any tests related to relative date processing, so it
> > > would be really nice to have some. But I'm not sure of the best way to
> > > do it without dealing with race conditions. Annoyingly, show_date calls
> > > gettimeofday at a pretty low level, so there isn't a way of
> > > instrumenting it short of LD_PRELOAD trickery (which is probably not
> > > very portable).
> >
> > Maybe better prepare the _test_ so that it uses current time and time
> > arithmetics then put yet another cludge in operational code? Especially
> > when we already have a greate number of GIT_ environment variables,
> > documented nowhere, with effects not immediately obvious:
>
> But that's the point: you can't do that without a race condition. Your
> test gets a sense of the current time, then runs git, which checks the
> current time again. How many seconds elapsed between the two checks?
>
> I guess it is good enough for testing large time spans, but I was hoping
> for a comprehensive time test.
I agree with your concern. This is why I created the --index-version
switch to pack-objects.
However I was hoping for a current time trickery solution that could
live in test-date.c instead of interfering with the main code in such a
way.
Did a quick test to override the library version:
diff --git a/test-date.c b/test-date.c
index 62e8f23..0bcd0c9 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,5 +1,10 @@
#include "cache.h"
+int gettimeofday(struct timeval *tv, struct timezone *tz)
+{
+ return 0;
+}
+
int main(int argc, char **argv)
{
int i;
Result:
$ ./test-date now
now -> bad -> Wed Dec 31 19:00:00 1969
now -> Tue Jan 22 10:48:24 10199
So this seems to work. ;-)
Nicolas
^ permalink raw reply related
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 17:15 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Reiss, git
In-Reply-To: <81b0412b0908281000l41c862f9ye52da7251014c4f7@mail.gmail.com>
On Fri, Aug 28, 2009 at 07:00:59PM +0200, Alex Riesen wrote:
> On Fri, Aug 28, 2009 at 17:02, Jeff King<peff@peff.net> wrote:
> > But that's the point: you can't do that without a race condition. Your
> > test gets a sense of the current time, then runs git, which checks the
> > current time again. How many seconds elapsed between the two checks?
>
> How _many_ do you need?
I don't understand what you're trying to say. My point is that if you
are checking results to a one-second precision, you need to know whether
zero seconds elapsed, or one second, or two seconds, or whatever to get
a consistent result.
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Alex Riesen @ 2009-08-28 17:00 UTC (permalink / raw)
To: Jeff King; +Cc: David Reiss, git
In-Reply-To: <20090828150212.GA6013@coredump.intra.peff.net>
On Fri, Aug 28, 2009 at 17:02, Jeff King<peff@peff.net> wrote:
> But that's the point: you can't do that without a race condition. Your
> test gets a sense of the current time, then runs git, which checks the
> current time again. How many seconds elapsed between the two checks?
How _many_ do you need?
^ permalink raw reply
* Running git server from NAS
From: John @ 2009-08-28 16:31 UTC (permalink / raw)
To: git
Hello,
I need to have a git server available for multiple users, but I want the git
home directory and repositories on NAS due to data backup, and minimal down
time if the Linux host goes down I can start another host pointing to the git
home directory on the NAS.
What would be the best way to configure this?
Thanks
-John
^ permalink raw reply
* Re: Merging in Subversion 1.5
From: Avery Pennarun @ 2009-08-28 16:34 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <200908281819.10135.jnareb@gmail.com>
On Fri, Aug 28, 2009 at 4:19 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> On Fri, 28 Aug 2009, Avery Pennarun wrote:
>> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>> > * You have to explicitely enable using svn:mergeinfo in log and blame
>>
>> Conversely, in git you can basically disable it using --first-parent,
>> which is sometimes handy. [...]
>
> In git-log. But in git-blame?
I don't know about git-blame, as I rarely use it. If it doesn't
support --first-parent, I imagine it would be easy to add, if it were
important to someone.
Avery
^ permalink raw reply
* Re: Merging in Subversion 1.5
From: Matthias Andree @ 2009-08-28 16:28 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Jakub Narebski
In-Reply-To: <200908281819.10135.jnareb@gmail.com>
[culling most of Cc: list]
Am 28.08.2009, 18:19 Uhr, schrieb Jakub Narebski <jnareb@gmail.com>:
> On Fri, 28 Aug 2009, Avery Pennarun wrote:
>> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
>
>> > From what I understand (from what I have read, and browsed, and
>> > lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
>> > in very different way that in Git:
>> >
>> > * the svn:mergeinfo is client-side property; if I understand
>> > correctly this would help you in repeated merges, but not anyone
>> > other
>>
>> I don't believe there is such a thing as a "client-side property" in
>> svn.
>
> What about svn:ignore or svn:mimetype (IIRC) property?
All this is committed to the repository, so there isn't a question of if
it's client-side in a sense of "local to the client/checkout". Some
properties (such as svn:mergeinfo) require a bit of additional server-side
support, but that's about it.
Oh, and to complicate matters, let me mention revprops (such as
svn:log). SCNR :^)
--
Matthias Andree
^ permalink raw reply
* Re: bzr to git syncing
From: Sverre Rabbelier @ 2009-08-28 16:19 UTC (permalink / raw)
To: Alex Bennee; +Cc: git, David Reitter
In-Reply-To: <b2cdc9f30908280902m22d594bam3c70259d4c296e52@mail.gmail.com>
Heya,
On Fri, Aug 28, 2009 at 09:02, Alex Bennee<kernel-hacker@bennee.com> wrote:
> I've attached the fast-import crash I'm seeing. Are you seeing the
> same sort of failure?
The program you used to generate the stream (I assume git-bzr?) is
generating an invalid mode, git understands '100644', '100755',
'120000', and '160000'; the mode in the stream, '040000', is not
something we understand.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Merging in Subversion 1.5
From: Jakub Narebski @ 2009-08-28 16:19 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>
On Fri, 28 Aug 2009, Avery Pennarun wrote:
> On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> > From what I understand (from what I have read, and browsed, and
> > lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
> > in very different way that in Git:
> >
> > * the svn:mergeinfo is client-side property; if I understand
> > correctly this would help you in repeated merges, but not anyone
> > other
>
> I don't believe there is such a thing as a "client-side property" in
> svn.
What about svn:ignore or svn:mimetype (IIRC) property?
> I see someone said this on stackoverflow
> (http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)
> but I'm pretty sure they were either mistaken or using a different
> definition of "client-side."
I think I got this (wrong?) impression from there.
> > * svn:mergeinfo contains _per-file_ merge info, so it is much, much
> > more "chatty" than Git multiple parents. This might be more
> > powerfull approach, in the same sense that more advanced merge
> > strategies that 3-way merge were more powerfull -- but 3-way merge
> > is best because it is simple (and either it is simple that 3-way
> > merge is enough, or complicated so manual intervention is required).
>
> svn people really love their cherry-picks and want to keep track of
> which things get cherry picked from one branch to another. This is
> nice (at least for informational purposes) although they go through
> some probably-unnecessary contortions *after* doing this, including
> splitting a merge from "maint" into "master" into two sequential
> merges, if you've previously cherry-picked a commit from master into
> maint. The above svn book link describes this in a bit more detail.
>
> I don't think that behaviour would be much help in any situation I've
> ever experienced, so I agree with your comment that 3-way merge is
> generally better.
Errr... what I meant here that I have read (on some blog, but either
I didn't bookmark it, or I can't find the bookmark) that svn:mergeinfo
is not as simple as listing _revisions_ which are merged (i.e. either
all parents, or additional parent), but it lists per-file merge
information, and can be quite large.
> > * You have to explicitely enable using svn:mergeinfo in log and blame
>
> Conversely, in git you can basically disable it using --first-parent,
> which is sometimes handy. [...]
In git-log. But in git-blame?
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: demerphq @ 2009-08-28 16:12 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
2009/8/28 seanh <seanh.nospam@gmail.com>:
> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
>> As you can generate the PDF's from the latex then just hack gitweb to
>> let them download it from there.
>
> Unfortunately gitweb is written in Perl. But I know what you mean, it
> should in theory be possible for them to click on a 'Get PDF' link for a
> particular revision that causes the PDF to be built and returned to
> their browser.
What is unfortunate about that? Perl is a duct tape/swiss-army-knife
of the internet. Hacking gitweb to generate PDF's on the fly from
latex documents should be a fairly trivial hack, even if you aren't a
Perl hacker.
See:
http://search.cpan.org/~andrewf/LaTeX-Driver-0.08/lib/LaTeX/Driver.pm
for just one of many Perl modules to interface with with LaTeX.
Good luck.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: bzr to git syncing
From: Alex Bennee @ 2009-08-28 16:02 UTC (permalink / raw)
To: git, David Reitter
In-Reply-To: <F84D4C0F-1CEF-4853-84DB-B7927CBE62B3@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 807 bytes --]
2009/6/29 David Reitter <david.reitter@gmail.com>:
> Does anyone have experience syncing a Bzr repository to git?
> I would ideally want two-way syncing, but even the bzr->git route would be a
> start.
I've a sneaking suspicion a breakage has been introduced to either the
git-bzr script or
the bzr fast-import module. I say this as I have successfully pulled
from a bzr repo into
git before but having need to do it today and I get a crash in fast-import.
A few quick questions:
* What versions of git/bzr are you using (me: git 1.6.4, bzr 1.17)?
* Which git-bzr script are you using (me:
http://github.com/mcepl/git-bzr/tree/master)?
I've attached the fast-import crash I'm seeing. Are you seeing the
same sort of failure?
--
Alex, homepage: http://www.bennee.com/~alex/
http://www.half-llama.co.uk
[-- Attachment #2: fast_import_crash_21774 --]
[-- Type: application/octet-stream, Size: 1094 bytes --]
fast-import crash report:
fast-import process: 21774
parent process : 21773
at Fri Aug 28 16:54:14 2009
fatal: Corrupt mode: M 040000 - content
Most Recent Commands Before Crash
---------------------------------
commit refs/heads/bzr/upstream
mark :1
committer Alexander Sack <asac@jwsdot.com> 1181743954 +0200
data 39
M 644 inline build.sh
data 3963
M 644 inline chrome.manifest
data 192
M 644 inline config_build.sh
data 170
* M 040000 - content
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 0 refs/heads/bzr/upstream
Inactive Branches
-----------------
refs/heads/bzr/upstream:
status : active loaded dirty
tip commit : 0000000000000000000000000000000000000000
old tree : 0000000000000000000000000000000000000000
cur tree : 0000000000000000000000000000000000000000
commit clock: 0
last pack :
Marks
-----
exported to /export/src/debs/cbnlfox.git/.git/bzr-git/upstream-git-map
-------------------
END OF CRASH REPORT
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Paolo Bonzini @ 2009-08-28 15:50 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
On 08/28/2009 03:37 PM, seanh wrote:
> In response to Matthieu and Paolo, I'm not sure I understand the git
> internals involved in the discussion around merge --squash, I had a
> feeling this would produce a 'merge' that git in some sense would 'not
> know about', since it sounds complex and I don't understand it I don't
> think I want to go there.
Yes, the problem is that git does not track what happens when you do
"git merge --squash", which makes it harder to do merges after some time
(because of conflicts).
The solution I gave (and Matthieu explained how it works, even though
it's very technical) is a way to "explain" git what you did. If you try
it on a fake example with gitk, you should understand it better.
mkdir test
cd test
# import
git init
echo a > test
git add a
git commit -m1
# some changes happen in your local "fine grained" branch
git checkout -b local
echo b > test
git commit -a -m2
echo c >> test
git commit -a -m3 ##<<<
# the magic incantation brings those commit to master
# (first two commands) and teaches git what happened (last two)
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
# more local changes
sed -i s/b/d/ test
git commit -a -m4
echo z >> test
git commit -a -m5 ##<<<
# the magic incantation, again
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
Use gitk at the points indicated with ##<<<
It is actually very similar to what you chose to do. My commits to
master, in practice, are your tags. You may want to see how gitk's
graphs looks in both scenarios, and choose the one that you prefer.
Hope this helps!
Paolo
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Matthias Andree @ 2009-08-28 15:44 UTC (permalink / raw)
To: Avery Pennarun, Jakub Narebski; +Cc: git, Matthieu Moy
In-Reply-To: <32541b130908280829s6fcebbe5ja84b10e649de1eb3@mail.gmail.com>
Am 28.08.2009, 17:29 Uhr, schrieb Avery Pennarun <apenwarr@gmail.com>:
> I think they probably meant that it's the client's responsibility to
> set the property correctly, not the server's, and if your client is
> too old any you do a merge, it'll forget to set svn:mergeinfo, causing
> confusion for everyone. There's discussion in the svn book
> (http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
> nothing implies that it's a non-replicated property. Indeed, I can
> see no particular reason that anyone would want it to be, for the
> reasons you specify.
It is replicated, and the common remedy against older clients is to refuse
commits from those clients that do not support mergeinfo. This is done by
defining a repository hook on the server side that validates this. AFAIR
such a hook example ships with SVN.
--
Matthias Andree
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Johannes Schindelin @ 2009-08-28 15:31 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Todd Zullinger, Nanako Shiraishi, git
In-Reply-To: <32541b130908280815y78f95140re679c336fbd17443@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1041 bytes --]
Hi,
On Fri, 28 Aug 2009, Avery Pennarun wrote:
> On Fri, Aug 28, 2009 at 4:53 AM, Junio C Hamano<gitster@pobox.com> wrote:
> > Hmph, I don't know. Googling "overrideable" suggests "Did you mean
> > overridable?" which is enough clue for me.
>
> Using a similar system, the Google hit count:
>
> overrideable: 26,900
> overridable: 339,000
> overridden: 2,280,000
But of course, "overidable" means "able to be overridden", not
"overridden".
> Which agrees with my intuition that you can get away with overridable,
> but it's much more common to just use overridden.
>
> "override" of course comes from "ride" (181,000,000). A horse can be
> ridden (10,500,000) if it's ridable (82,500).
>
> The bad news: rideable (201,000).
>
> http://www.merriam-webster.com/dictionary/ridable shows rideable as
> the preferred spelling, but accepts both.
Actually, I do not trust the bda speling of the many internet content
providers as much as Merriam Webster, so of all your analysis, I find this
the most important finding.
Ciao,
Dscho
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Avery Pennarun @ 2009-08-28 15:29 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <m3ocq0km5m.fsf_-_@localhost.localdomain>
On Fri, Aug 28, 2009 at 3:12 PM, Jakub Narebski<jnareb@gmail.com> wrote:
> From what I understand (from what I have read, and browsed, and
> lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
> in very different way that in Git:
>
> * the svn:mergeinfo is client-side property; if I understand
> correctly this would help you in repeated merges, but not anyone
> other
I don't believe there is such a thing as a "client-side property" in
svn. I see someone said this on stackoverflow
(http://stackoverflow.com/questions/1156698/are-svn-merges-idempotent)
but I'm pretty sure they were either mistaken or using a different
definition of "client-side."
I think they probably meant that it's the client's responsibility to
set the property correctly, not the server's, and if your client is
too old any you do a merge, it'll forget to set svn:mergeinfo, causing
confusion for everyone. There's discussion in the svn book
(http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html) but
nothing implies that it's a non-replicated property. Indeed, I can
see no particular reason that anyone would want it to be, for the
reasons you specify.
> * svn:mergeinfo contains _per-file_ merge info, so it is much, much
> more "chatty" than Git multiple parents. This might be more
> powerfull approach, in the same sense that more advanced merge
> strategies that 3-way merge were more powerfull -- but 3-way merge
> is best because it is simple (and either it is simple that 3-way
> merge is enough, or complicated so manual intervention is required).
svn people really love their cherry-picks and want to keep track of
which things get cherry picked from one branch to another. This is
nice (at least for informational purposes) although they go through
some probably-unnecessary contortions *after* doing this, including
splitting a merge from "maint" into "master" into two sequential
merges, if you've previously cherry-picked a commit from master into
maint. The above svn book link describes this in a bit more detail.
I don't think that behaviour would be much help in any situation I've
ever experienced, so I agree with your comment that 3-way merge is
generally better.
Tracking cherry picks in git would be really nice *sometimes*, but it
creates a tradeoff where you then have to slurp in huge amounts of
history that you might not want. In svn, this tradeoff doesn't exist,
since anything you cherry pick must have already existed on the server
anyway, and can never go away.
> * You have to explicitely enable using svn:mergeinfo in log and blame
Conversely, in git you can basically disable it using --first-parent,
which is sometimes handy. (It's handiest if your team has a policy of
always using --no-ff when merging into trunk, which makes git act a
bit more like svn's merge tracking. I realize this is a bit heretical
to suggest on the git list, but I appreciate that the option exists
despite its heresy :))
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Avery Pennarun @ 2009-08-28 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Todd Zullinger, Nanako Shiraishi, git
In-Reply-To: <7v63c8a69a.fsf@alter.siamese.dyndns.org>
On Fri, Aug 28, 2009 at 4:53 AM, Junio C Hamano<gitster@pobox.com> wrote:
> Hmph, I don't know. Googling "overrideable" suggests "Did you mean
> overridable?" which is enough clue for me.
Using a similar system, the Google hit count:
overrideable: 26,900
overridable: 339,000
overridden: 2,280,000
Which agrees with my intuition that you can get away with overridable,
but it's much more common to just use overridden.
"override" of course comes from "ride" (181,000,000). A horse can be
ridden (10,500,000) if it's ridable (82,500).
The bad news: rideable (201,000).
http://www.merriam-webster.com/dictionary/ridable shows rideable as
the preferred spelling, but accepts both.
Have fun,
Avery
^ permalink raw reply
* Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Jakub Narebski @ 2009-08-28 15:12 UTC (permalink / raw)
To: Matthias Andree; +Cc: git, Matthieu Moy
In-Reply-To: <4A97E1B1.7090107@gmx.de>
Matthias Andree <matthias.andree@gmx.de> writes:
> Matthieu Moy schrieb:
>> seanh <seanh.nospam@gmail.com> writes:
>>
>>> In response to Matthieu and Paolo, I'm not sure I understand the git
>>> internals involved in the discussion around merge --squash, I had a
>>> feeling this would produce a 'merge' that git in some sense would 'not
>>> know about',
>>
>> Yes, that's it. Git does a merge, and immediately forgets it was a
>> merge. The consequence is when you merge again later, Git will not be
>> able to use the merge information to be clever about merging. Somehow,
>> Git will be as bad as SVN for merging if you don't know what you're
>> doing ;-).
>
> To be fair, SVN versions 1.5 and newer can track merges. If the
> repository predates 1.5, it has to be updated on the server side
> (see the release notes for details). It just tracks which revisions
> have been merged and which not, for further details, see the svn
> book. (http://svnbook.red-bean.com/ IIRC)
>From what I understand (from what I have read, and browsed, and
lurged, and noticed) is that Subversion 1.5+ does merge tracking, but
in very different way that in Git:
* the svn:mergeinfo is client-side property; if I understand
correctly this would help you in repeated merges, but not anyone
other
* svn:mergeinfo contains _per-file_ merge info, so it is much, much
more "chatty" than Git multiple parents. This might be more
powerfull approach, in the same sense that more advanced merge
strategies that 3-way merge were more powerfull -- but 3-way merge
is best because it is simple (and either it is simple that 3-way
merge is enough, or complicated so manual intervention is required).
* You have to explicitely enable using svn:mergeinfo in log and blame
* The command to merge trunk into branch is different from command to
merge branch into trunk.
Also IIRC there is warning (well, at least there was in Subversion 1.5
release notes) that merge tracking doesn't work entirely correctly in
the face of criss-cross merges (multiple merge bases) and renaming
(although I do hope that they fixed problem with silent corruption if
there is rename during merge).
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: Jeff King @ 2009-08-28 15:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: David Reiss, git
In-Reply-To: <81b0412b0908280058i364bfb83nb04354d982abc053@mail.gmail.com>
On Fri, Aug 28, 2009 at 09:58:27AM +0200, Alex Riesen wrote:
> > I couldn't find any tests related to relative date processing, so it
> > would be really nice to have some. But I'm not sure of the best way to
> > do it without dealing with race conditions. Annoyingly, show_date calls
> > gettimeofday at a pretty low level, so there isn't a way of
> > instrumenting it short of LD_PRELOAD trickery (which is probably not
> > very portable).
>
> Maybe better prepare the _test_ so that it uses current time and time
> arithmetics then put yet another cludge in operational code? Especially
> when we already have a greate number of GIT_ environment variables,
> documented nowhere, with effects not immediately obvious:
But that's the point: you can't do that without a race condition. Your
test gets a sense of the current time, then runs git, which checks the
current time again. How many seconds elapsed between the two checks?
I guess it is good enough for testing large time spans, but I was hoping
for a comprehensive time test.
-Peff
^ permalink raw reply
* Re: [PATCHv4 08/12] Teach the notes lookup code to parse notes trees with various fanout schemes
From: Johan Herland @ 2009-08-28 14:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, Shawn O. Pearce, trast, tavestbo, git,
chriscool
In-Reply-To: <alpine.DEB.1.00.0908281349270.7434@intel-tinevez-2-302>
On Friday 28 August 2009, Johannes Schindelin wrote:
> On Fri, 28 Aug 2009, Johan Herland wrote:
> > On Friday 28 August 2009, Johannes Schindelin wrote:
> > > And I can easily imagine a repository that has a daily note
> > > generated by an automatic build, and no other notes. The
> > > date-based fan-out just wastes our time here, and even hurts
> > > performance.
> >
> > What about a month-based fanout?
>
> Well, I hoped to convince you that the date-based approach is too
> rigid. You basically cannot adapt the optimal data layout to the
> available data.
>
> (I like to think of this issue as related to storing deltas: we let
> Git choose relatively freely what to delta against, and do not force
> a delta against the parent commit like others do; I think it is
> pretty obvious that our approach is more powerful.)
>
> So the simplest (yet powerful-enough) way I could imagine is to teach
> the reading part to accept any fan-out (but that fan-out is really
> only based on the object name, nothing else), and to adjust the
> writing/merging part such that it has a maximum bin size (i.e. it
> starts a new fan-out whenever a tree object contains more than a
> config-specifyable limit).
I agree with your points on flexibility and not nailing down a structure
that might prove too rigid in the future.
But it seems the date-based approach might offer wins that an
object-name-based approach (flexible or not) simply cannot hope to
match...
Also a rigid organization (with unique note locations) makes the
implementation simpler and faster: If you allow notes for a given
commit at several places in the notes tree (and require the result to
be the concatenation of those notes, which seems to be the saner
choice), the lookup procedure must keep looking even after it has found
the first match. This affects both runtime and memory consumption
negatively (more subtrees must be unpacked, etc.)
I guess I'll code up both alternatives so that we can get some actual
numbers...
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Matthias Andree @ 2009-08-28 13:54 UTC (permalink / raw)
To: git
In-Reply-To: <vpqpragt5bo.fsf@bauges.imag.fr>
Matthieu Moy schrieb:
> seanh <seanh.nospam@gmail.com> writes:
>
>> In response to Matthieu and Paolo, I'm not sure I understand the git
>> internals involved in the discussion around merge --squash, I had a
>> feeling this would produce a 'merge' that git in some sense would 'not
>> know about',
>
> Yes, that's it. Git does a merge, and immediately forgets it was a
> merge. The consequence is when you merge again later, Git will not be
> able to use the merge information to be clever about merging. Somehow,
> Git will be as bad as SVN for merging if you don't know what you're
> doing ;-).
To be fair, SVN versions 1.5 and newer can track merges. If the repository
predates 1.5, it has to be updated on the server side (see the release notes for
details). It just tracks which revisions have been merged and which not, for
further details, see the svn book. (http://svnbook.red-bean.com/ IIRC)
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: Matthieu Moy @ 2009-08-28 13:51 UTC (permalink / raw)
To: seanh; +Cc: git
In-Reply-To: <20090828133708.GA11146@kisimul>
seanh <seanh.nospam@gmail.com> writes:
> In response to Matthieu and Paolo, I'm not sure I understand the git
> internals involved in the discussion around merge --squash, I had a
> feeling this would produce a 'merge' that git in some sense would 'not
> know about',
Yes, that's it. Git does a merge, and immediately forgets it was a
merge. The consequence is when you merge again later, Git will not be
able to use the merge information to be clever about merging. Somehow,
Git will be as bad as SVN for merging if you don't know what you're
doing ;-).
> since it sounds complex and I don't understand it I don't think I
> want to go there.
Well, it's fun also to learn Git notions in more details ;-).
--
Matthieu
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: seanh @ 2009-08-28 13:37 UTC (permalink / raw)
To: git
In-Reply-To: <20090827203402.GC7168@kisimul>
Wow, really helpful responses, thanks a lot.
I think having read all this that I'll do it manually. I'll still use
git to track my latex source and will commit to it as often as I like
and not worry about commit granularity. Whenever I've finished a
significant chunk I'll add a PDF of it to a manually edited web page
along with a description of what changed since the last time I added a
PDF. I can use git log etc to help write the manual changelog. My
supervisors can just look at this manually constructed page and if it
gets too big I'll just archive the oldest PDFs. I can tag the git repo
at the points where I add a PDF to the web page. I guess this is pretty
close to what software projects do with version releases and their
public website.
On Thu, Aug 27, 2009 at 01:41:04PM -0700, Sverre Rabbelier wrote:
> If they only care about the pdf anyway, why not have a separate branch
> to which you commit the pdf's instead?
Well I was thinking they'd look at the changelogs with the diffs showing
exactly what changed in the latex source files, which should be pretty
self-explanatory, but then when they wanted to read a whole chapter and
add comments to it they'd want the PDF not the latex.
I don't really understand the script Junio posted (not literate in sh)
but I think it might have something to do with copying changelogs over
from the source repo to a PDFs repo.
On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
> As you can generate the PDF's from the latex then just hack gitweb to
> let them download it from there.
Unfortunately gitweb is written in Perl. But I know what you mean, it
should in theory be possible for them to click on a 'Get PDF' link for a
particular revision that causes the PDF to be built and returned to
their browser.
In response to Matthieu and Paolo, I'm not sure I understand the git
internals involved in the discussion around merge --squash, I had a
feeling this would produce a 'merge' that git in some sense would 'not
know about', since it sounds complex and I don't understand it I don't
think I want to go there.
Thanks all
^ permalink raw reply
* Re: Question regarding git fetch
From: Tom Lambda @ 2009-08-28 13:24 UTC (permalink / raw)
To: git
In-Reply-To: <1251387045053-3527289.post@n2.nabble.com>
Thank you all for your answers and the interesting following discussion.
>From a user perspective (I do not know how git works internally), the
approach proposed by Juno looks very intuitive to me. Now I understand there
are other cases and users to take into account, which make the
implementation complex. I hope this will be part of git 1.7.0.
--Tom
--
View this message in context: http://n2.nabble.com/Question-regarding-git-fetch-tp3527289p3534609.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Abhijit Bhopatkar @ 2009-08-28 13:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, teamgit
In-Reply-To: <m3skfckzk1.fsf@localhost.localdomain>
2009/8/28 Jakub Narebski <jnareb@gmail.com>:
> Abhijit Bhopatkar <bain@devslashzero.com> writes:
>
>> So I ask you people, is there a solution already cooking someplace?
>> may be something i can integrate with teamGIT? (e.g. bonjour plugin
>> for git dameon)
>
> There is gitjour:
> http://rubyforge.org/projects/gitjour
> http://github.com/chad/gitjour
Hmm... almost perfect, except i don't want to depend on ruby to be
installed on the target machine.
Sigh!
BAIN
^ 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