On Tuesday 28 August 2012 10:49:34 Florian Achleitner wrote:
> Reroll includes fixups by Ramsey. Thanks!
> Diff:
> [..]
> - improve compatibility of integer types.
> [..]
This line is wrong in this series. Just delete it. Sorry.
--
To unsubscribe from this list: send the line "unsubscribe git" in
Reroll includes fixups by Ramsey. Thanks!
Diff:
- Add missing dependency to rule in Makefile.
- improve compatibility of integer types.
- t9020-*.sh: remove excess slash in urls that makes python on windows
interpret it as a network path.
- t9020-*.sh: skip if python isn't available.
- replace g
Florian Achleitner writes:
> Another improved series with fixups by Junio, and a little by me.
> Diff:
> - fix inconsistend indent in Documentation/git-remote-helpers.txt
> - remove trailing newline in Makefile
> - fix argument list and usage of regenerate_marks(void) in remote-svn.c
>
>
> [PATCH
Another improved series with fixups by Junio, and a little by me.
Diff:
- fix inconsistend indent in Documentation/git-remote-helpers.txt
- remove trailing newline in Makefile
- fix argument list and usage of regenerate_marks(void) in remote-svn.c
[PATCH v6 01/16] Implement a remote helper for sv
New version with these changes:
- includes fixups and changes by Junio from fa/remote-svn
- move contrib/svn-fe/remote-svn.c to remote-testsvn.c (in toplevel)
- add it to the toplevel Makefile
(needed to copy the linker rule, is there a nicer way?)
- check for prerequisite in test script (probab
Hi,
Florian Achleitner wrote:
> What version would you prefer?
I think git-remote-svn should move out of contrib to the toplevel of
git.git (as I think I've mentioned before). Since it's just a new git
command in incubation, I don't want the maintenance hassle of keeping
it in contrib/svn-fe.
Florian Achleitner writes:
> On Saturday 18 August 2012 13:13:47 Junio C Hamano wrote:
>> That indicates that one necessary patch to add logic to Makefile to
>> go and build that subdirectory, at least before running the test,
>> but possibly as part of the "all" target, is missing, isn't it?
>>
On Saturday 18 August 2012 13:13:47 Junio C Hamano wrote:
> That indicates that one necessary patch to add logic to Makefile to
> go and build that subdirectory, at least before running the test,
> but possibly as part of the "all" target, is missing, isn't it?
>
> Or you can add, at the beginning
Florian Achleitner writes:
> On Saturday 18 August 2012 23:35:38 Junio C Hamano wrote:
>> Junio C Hamano writes:
>> [..]
>> Just to show how, here is what I did just now.
>> [..]
>> Thanks.
>
> Thanks for you guidance!
> I'll base a new version on your fixups.
Just to make sure...
Please do _
On Saturday 18 August 2012 23:35:38 Junio C Hamano wrote:
> Junio C Hamano writes:
> [..]
> Just to show how, here is what I did just now.
> [..]
> Thanks.
Thanks for you guidance!
I'll base a new version on your fixups.
Florian
--
To unsubscribe from this list: send the line "unsubscribe git"
Junio C Hamano writes:
> Florian Achleitner writes:
>
>> On Friday 17 August 2012 21:16:59 Junio C Hamano wrote:
>>> Comments from mentors and people interested in remote helpers?
>>>
>>> I did minimum line wrapping, typofix and small compilation fixes
>>> and queued these on 'pu'; I think I sa
Florian Achleitner writes:
> On Friday 17 August 2012 21:16:59 Junio C Hamano wrote:
>> Comments from mentors and people interested in remote helpers?
>>
>> I did minimum line wrapping, typofix and small compilation fixes
>> and queued these on 'pu'; I think I saw one commit whose message
>> I d
On Friday 17 August 2012 21:16:59 Junio C Hamano wrote:
> Comments from mentors and people interested in remote helpers?
>
> I did minimum line wrapping, typofix and small compilation fixes
> and queued these on 'pu'; I think I saw one commit whose message
> I didn't quite get what it was trying t
Comments from mentors and people interested in remote helpers?
I did minimum line wrapping, typofix and small compilation fixes
and queued these on 'pu'; I think I saw one commit whose message
I didn't quite get what it was trying to say, and another that was
missing S-o-b (I left them untouched).
Hi!
Thanks for the reviews!
This series contains the follwing improvements.
I decided to summarize them here, sorted by topic instead of
attaching them to the patches.
all:
- remove all merge garbage and debugging legacy (hopefully).
- reviews: style
- reorder patches
remote-svn:
- review: refa
On Wed, Aug 15, 2012 at 5:13 AM, Florian Achleitner
wrote:
> Hi.
>
> Version 3 of this series adds the 'bidi-import' capability, as suggested
> Jonathan.
> Diff details are attached to the patches.
> 04 and 05 are completely new.
>
> [PATCH/RFC v3 01/16] Implement a remote helper for svn in C.
> [
Hi.
Version 3 of this series adds the 'bidi-import' capability, as suggested
Jonathan.
Diff details are attached to the patches.
04 and 05 are completely new.
[PATCH/RFC v3 01/16] Implement a remote helper for svn in C.
[PATCH/RFC v3 02/16] Integrate remote-svn into svn-fe/Makefile.
[PATCH/RFC v
On Saturday 04 August 2012 23:53:58 Ramkumar Ramachandra wrote:
> Hi,
>
> Florian Achleitner wrote:
> > 1. Import linearly and split later:
> I think this approach will be a lot less messy if you can cleanly
> separate the fetching component from the mapper. Currently, svndump
> re-creates the la
Hi,
Florian Achleitner wrote:
> 1. Import linearly and split later:
I think this approach will be a lot less messy if you can cleanly
separate the fetching component from the mapper. Currently, svndump
re-creates the layout of the SVN repository. And the series you
posted last week contains a p
Hi,
On Sat, Aug 4, 2012 at 12:17 AM, Jonathan Nieder wrote:
> Hi,
>
> Florian Achleitner wrote:
>
>> Two approaches:
>> 1. Import linearly and split later:
>> One idea is to import from svn linearly, i.e. one revision on top of it's
>> predecessor, like now, and detect and split branches afterwar
Hi,
Florian Achleitner wrote:
> Two approaches:
> 1. Import linearly and split later:
> One idea is to import from svn linearly, i.e. one revision on top of it's
> predecessor, like now, and detect and split branches afterwards. The svn
> metadata is stored in git notes, so the required informa
Hi!
I'm playing around in vcs-svn/ to start a framework for detecting and
processing branches in svndumps. So I wanted to let you know about my ideas.
Two approaches:
1. Import linearly and split later:
One idea is to import from svn linearly, i.e. one revision on top of it's
predecessor, like
Hi!
I decided to completely rewrite my commit history, I split, dropped, squashed,
and reordered.
And finally rebased it all onto the current master.
Hope this removed a lot of my personal confusion and makes the patches
more useful and understandable.
I think the remote helper does what it shou
Florian Achleitner wrote:
> But when I fetch from a git repo that imported from svn, the notes are not
> fetched automatically. In this case I currently loose marks and notes.
> What can I do?
In the long term, git will need to be tweaked to automatically fetch
notes along with branches by defau
Matthieu Moy wrote:
> The man page for git-remote-helpers says:
>
> refspec
> [...] It is recommended that all importers providing the import
> capability use this.
>
> I'm not sure I fully understand the rationale, but one difference
> between refs//* and refs/remotes/ is that
> refs/rem
On Sunday 22 July 2012 23:03:27 Florian Achleitner wrote:
> This got stuck on another problem:
> Incremental update of the note tree doesn't work. fast-import refuses to
> update the notes tree: ' doesn't contain '.
> I don't yet know what's the reason for this.
> I'm digging into the internals of
On Sunday 22 July 2012 16:43:33 Jonathan Nieder wrote:
> Hi,
>
> Florian Achleitner wrote:
> > After several mailing iterations, showing me that I was wrong, I found
> > what
> > the right point is, namely that the remote helper writes references to a
> > really private dir in refs//, it doesn't t
Florian Achleitner writes:
> But my remote-helper didn't advertise the refspec capability, so transport-
> helper assumed it imports to refs/heads/master, which is the default import
> refspec.
The man page for git-remote-helpers says:
refspec
[...] It is recommended that all importers pr
Hi,
Florian Achleitner wrote:
> After several mailing iterations, showing me that I was wrong, I found what
> the right point is, namely that the remote helper writes references to a
> really private dir in refs//, it doesn't touch anything else,
> and
> by advertising the 'refspec' capabilit
Hi!
Refering to Jonathan's concerns in Saturday night's IRC log:
> [22:59:34] barrbrain, flyingflo: I'm worried about the remote
helper project
> [23:00:05] someone needs to review remote-svn.c to catch things
like that refspec issue which should be straightforward to an experienced eye
Let
Hi!
This series adds creating notes to vcs-svn, plus some testing aids.
I picked one patch from Dmitry's existing work.
Next steps are storing the fetched revisions and notes in the right place
in refs/remote/ and adding incremental import using the notes.
Im currently stuck on some unexpected b
31 matches
Mail list logo
