headers
Maaartin-1 | 15 Jan 2011 01:04
Picon
Favicon

Re: [RFC/PATCH 2/1] fixup! Documentation: start to explain what git replace is for

On 11-01-14 23:48, Jakub Narebski wrote:
> On Fri, 14 Jan 2011, Maaartin-1 wrote:
>> On 11-01-14 09:49, Jonathan Nieder wrote:
>>> Some tweaks suggested by Maaartin:

>>> [side note: please do not prune the cc list; I only stumbled on this
>>> message in the online archive by luck]
>>
>> What could I have done about it? I didn't received it by email and
>> answered using post.gmane.org. There's no way to add CC there. If I'd
>> wrote an email instead, it wouldn't be placed in the thread.
> 
> In a good newsreader, like e.g. Gnus from GNU Emacs, you have option
> to do 'reply all via email', which includes also git <at> vger.kernel.org,
> i.e. mailing list from which gmane newsgroup is created.  That's what
> I do nowadays (usually).

I hate using Emacs for too many things. However, I'm starting to use
Thunderbird as newsreader, and it's quite OK.

>> I'd go the other way round and use "-i" so I'd need only one file. Using
>> a shell variable instead would be even better, s. below.
> 
> No, using shell variable for storing commit object is *not* a good idea.
> Either save it to temporary file, where you can edit it using editor of
> your choice, or use pipeline.

I see that the line-breaks get (for whatever reason) replaced by blanks,
sorry for the noise.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Neal Kreitzinger | 15 Jan 2011 05:53
Picon

multiple group access to update repo

How do I allow users from different linux group to cd to a common bare 
mirror repo and also to a common non-bare cloned repo and perform 
git-fetch and git pull --ff-only?  Currently, the non-owner group gets 
this error:

error: cannot open FETCH_HEAD: Permission denied

v/r,
Neal
Permalink | Reply | 1 comment |
headers
Phillip Susi | 15 Jan 2011 06:27
Picon

Re: small downloads and immutable history (Re: clone breaks replace)

On 01/14/2011 03:53 PM, Jonathan Nieder wrote:
> Ah, I forgot the use case.  If you are using this to at long last get
> past the limitations (e.g., inability to push) of "fetch --depth",
> then yes, rewriting existing history is bad.

I'm not really talking about using --depth, but more of the project 
deciding to truncate the history in the central repository.

> So what's left is some way to make the "have" part of transport
> negotiation make sense in this context.  I'll be happy if it happens.

Good point.  Whether local history is short because of --depth or 
replace records, the same problem arises; the negotiation needs to be 
able to exclude older objects that are not present locally, rather than 
assuming that the client has the entire history if it has any at all. 
It seems like this should just require sending the server and end point 
in addition to a start point.  In other words, not just send ID of the 
most recent commit, but also the oldest that it has on hand, so that the 
server can be sure that it does not deltafy against objects prior to 
that commit.
Permalink | Reply | 0 comments |
headers
Ramkumar Ramachandra | 15 Jan 2011 07:31
Picon
Gravatar

[PATCH] fast-import: Introduce --import-marks-if-exists

The --import-marks option errors out when the specified marks file
doesn't exist. If a frontend is just using a marks file to ensure its
state persists between runs, it would be simpler if missing marks
files were tolerated.  In some cases, the frontend cannot even check
for the existence of the marks file because with --relative-marks, the
location of the marks file is backend-dependent. This can be solved by
changing the meaning of --import-marks, but will result in trading off
functionality that some frontends might desire. So, add new
command-line option --import-marks-if-exists that's like
--import-marks, except that it tolerates missing marks files.

Helped-by: Junio C Hamano <gitster <at> pobox.com>
Helped-by: Jonathan Nieder <jrnieder <at> gmail.com>
Signed-off-by: Ramkumar Ramachandra <artagnon <at> gmail.com>
---
 Changes since last time: Junio suggested making this an optional
 feature, and Jonathan wrote a fixup patch for the same.

 Documentation/git-fast-import.txt |    4 +++
 fast-import.c                     |   16 +++++++++--
 t/t9300-fast-import.sh            |   55 +++++++++++++++++++++++++++++++++++++
 3 files changed, 72 insertions(+), 3 deletions(-)

diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index f56dfca..32a062c 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
 <at>  <at>  -78,6 +78,10  <at>  <at>  OPTIONS
 	set of marks.  If a mark is defined to different values,
 	the last file wins.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ramkumar Ramachandra | 15 Jan 2011 07:51
Picon
Gravatar

[PATCH 2/3] vcs-svn: Start working on the dumpfile producer

Start off with some broad design sketches. Compile succeeds, but
parser is incorrect. Include a Makefile rule to build it into
vcs-svn/lib.a.

Signed-off-by: Ramkumar Ramachandra <artagnon <at> gmail.com>
---
 Makefile              |    2 +-
 vcs-svn/dump_export.c |   73 ++++++++++++
 vcs-svn/svnload.c     |  294 +++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 368 insertions(+), 1 deletions(-)
 create mode 100644 vcs-svn/dump_export.c
 create mode 100644 vcs-svn/svnload.c

diff --git a/Makefile b/Makefile
index 1345c38..40f6691 100644
--- a/Makefile
+++ b/Makefile
 <at>  <at>  -1834,7 +1834,7  <at>  <at>  ifndef NO_CURL
 endif
 XDIFF_OBJS = xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
 	xdiff/xmerge.o xdiff/xpatience.o
-VCSSVN_OBJS = vcs-svn/line_buffer.o \
+VCSSVN_OBJS = vcs-svn/line_buffer.o vcs-svn/svnload.o vcs-svn/dump_export.o \
 	vcs-svn/repo_tree.o vcs-svn/fast_export.o vcs-svn/sliding_window.o \
 	vcs-svn/svndiff.o vcs-svn/svndump.o
 VCSSVN_TEST_OBJS = test-obj-pool.o \
diff --git a/vcs-svn/dump_export.c b/vcs-svn/dump_export.c
new file mode 100644
index 0000000..04ede06
--- /dev/null
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ramkumar Ramachandra | 15 Jan 2011 07:51
Picon
Gravatar

[PATCH 3/3] Build an svn-fi target in contrib/svn-fe

Build an svn-fi target for testing the dumpfile producer in vcs-svn/.

Signed-off-by: Ramkumar Ramachandra <artagnon <at> gmail.com>
---
 contrib/svn-fe/Makefile   |   23 +++++++++++++++++++++--
 contrib/svn-fe/svn-fi.c   |   16 ++++++++++++++++
 contrib/svn-fe/svn-fi.txt |   28 ++++++++++++++++++++++++++++
 3 files changed, 65 insertions(+), 2 deletions(-)
 create mode 100644 contrib/svn-fe/svn-fi.c
 create mode 100644 contrib/svn-fe/svn-fi.txt

diff --git a/contrib/svn-fe/Makefile b/contrib/svn-fe/Makefile
index 360d8da..555a8ff 100644
--- a/contrib/svn-fe/Makefile
+++ b/contrib/svn-fe/Makefile
 <at>  <at>  -37,7 +37,7  <at>  <at>  svn-fe$X: svn-fe.o $(VCSSVN_LIB) $(GIT_LIB)
 	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $ <at>  svn-fe.o \
 		$(ALL_LDFLAGS) $(LIBS)

-svn-fe.o: svn-fe.c ../../vcs-svn/svndump.h
+svn-fe.o: svn-fe.c ../../vcs-svn/svnload.h
 	$(QUIET_CC)$(CC) -I../../vcs-svn -o $*.o -c $(ALL_CFLAGS) $<

 svn-fe.html: svn-fe.txt
 <at>  <at>  -51,6 +51,24  <at>  <at>  svn-fe.1: svn-fe.txt
 		../contrib/svn-fe/$ <at> 
 	$(MV) ../../Documentation/svn-fe.1 .

+svn-fi$X: svn-fi.o $(VCSSVN_LIB) $(GIT_LIB)
+	$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $ <at>  svn-fi.o \
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ramkumar Ramachandra | 15 Jan 2011 07:51
Picon
Gravatar

[RFC PATCH 0/3] Towards a Git-to-SVN bridge

Hi,

Over the last couple of days, I've been working on a parser that
converts a fast-import stream into a SVN dumpfile. So far, it's very
rough and works minimally for some common fast-import
commands. However, the major roadblock is persisting blobs: in this
implementation, they're persisted as an array of strbufs. This is very
memory-intensive and not scalable at all. With some valuable insight
from Jonathan on IRC, I've decided to try re-implementing fast-export
to eliminate blob marks and produce them inline instead [1].

Comments are much appreciated.

[1]: http://colabti.org/irclogger/irclogger_log/git-devel?date=2011-01-14

Ramkumar Ramachandra (3):
  date: Expose the time_to_tm function
  vcs-svn: Start working on the dumpfile producer
  Build an svn-fi target in contrib/svn-fe

 Makefile                  |    2 +-
 cache.h                   |    1 +
 contrib/svn-fe/Makefile   |   23 ++++-
 contrib/svn-fe/svn-fi.c   |   16 +++
 contrib/svn-fe/svn-fi.txt |   28 +++++
 date.c                    |    2 +-
 vcs-svn/dump_export.c     |   73 +++++++++++
 vcs-svn/svnload.c         |  294 +++++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 435 insertions(+), 4 deletions(-)
 create mode 100644 contrib/svn-fe/svn-fi.c
(Continue reading)

Permalink | Reply | 7 comments |
headers
Ramkumar Ramachandra | 15 Jan 2011 07:51
Picon
Gravatar

[PATCH 1/3] date: Expose the time_to_tm function

Signed-off-by: Ramkumar Ramachandra <artagnon <at> gmail.com>
---
 cache.h |    1 +
 date.c  |    2 +-
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/cache.h b/cache.h
index d83d68c..95fea31 100644
--- a/cache.h
+++ b/cache.h
 <at>  <at>  -816,6 +816,7  <at>  <at>  enum date_mode {
 	DATE_RAW
 };

+struct tm *time_to_tm(unsigned long time, int tz);
 const char *show_date(unsigned long time, int timezone, enum date_mode mode);
 const char *show_date_relative(unsigned long time, int tz,
 			       const struct timeval *now,
diff --git a/date.c b/date.c
index 00f9eb5..e601a50 100644
--- a/date.c
+++ b/date.c
 <at>  <at>  -54,7 +54,7  <at>  <at>  static time_t gm_time_t(unsigned long time, int tz)
  * thing, which means that tz -0100 is passed in as the integer -100,
  * even though it means "sixty minutes off"
  */
-static struct tm *time_to_tm(unsigned long time, int tz)
+struct tm *time_to_tm(unsigned long time, int tz)
 {
 	time_t t = gm_time_t(time, tz);
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jonathan Nieder | 15 Jan 2011 08:22
Picon

Re: [RFC PATCH 0/3] Towards a Git-to-SVN bridge

Hi Ram,

Ramkumar Ramachandra wrote:

> Over the last couple of days, I've been working on a parser that
> converts a fast-import stream into a SVN dumpfile. So far, it's very
> rough and works minimally for some common fast-import
> commands.

Some early questions:

 - what are the design goals?  Is this meant to be super fast?
   Robust?  Simple?  Why should I be excited about it?[1]

 - what subset of fast-import commands is supported?  Is it well
   enough defined to make a manpage?

 - does this produce v2 or v3 dumpfiles?

 - why would I use this instead of git2svn?  Does git2svn do anything
   this will not eventually be able to do?  (Not a trick question ---
   I don't have enough experience with git2svn to tell its strengths
   and weaknesses.)

> I've decided to try re-implementing fast-export
> to eliminate blob marks

Hopefully "re-implement" means "patch" here. :)

I can comment on the code but it's probably better if I have a sense
(Continue reading)

Permalink | Reply | 1 comment |

Gmane