Florian Achleitner writes:
>> This change makes me uncomfortable.
>> We are doubling up on hashing with fast-import.
>> This introduces git-specific logic into vcs-svn.
IIUC, vcs-svn/fast-export is meant to produce a stream in the
fast-import format, and that format is meant to be VCS agnostic,
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 _
Florian Achleitner writes:
>> If you need to re-roll your patches in the 'fa/remote-svn' branch, could
>> you please squash this fix into them. [This was implemented on top of
>> commit 2ce959ba, but you will probably want to make the equivalent change
>> to commit d319a37c ("Create a note for ev
On Sunday 19 August 2012 04:37:35 David Michael Barr wrote:
> On Sat, Aug 18, 2012 at 6:40 AM, Florian Achleitner
>
> wrote:
> > Hi!
> >
> > This patch series should prepare vcs-svn/svndump.* for branch
> > detection. When starting with this feature I found that the existing
> > functions are no
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"
On Sunday 19 August 2012 16:29:02 Ramsay Jones wrote:
> In particular, gcc complains thus:
>
> CC vcs-svn/fast_export.o
> vcs-svn/fast_export.c: In function 'fast_export_begin_note':
> vcs-svn/fast_export.c:77: warning: long long unsigned int format, \
> different type arg
Jose Nobile skrev 2012-08-20 07.12:
I have a big repository, around 80GB
git --version
#git version 1.7.12
git init .
#Initialized empty Git repository in /reponame/.git/
git add -A .
git commmit -m "Backup 2012-08-19 03:43:44"
#fatal: Out of memory, malloc failed (tried to allocate 32220431361
On Sun, Aug 19, 2012 at 05:38:29PM -0700, Junio C Hamano wrote:
> Kacper Kornet writes:
> > Documentation of git-for-each-ref says that --sort= option can be
> > used multiple times, in which case the last key becomes the primary key.
> > However this functionality was never checked in test suite
I have a big repository, around 80GB
git --version
#git version 1.7.12
git init .
#Initialized empty Git repository in /reponame/.git/
git add -A .
git commmit -m "Backup 2012-08-19 03:43:44"
#fatal: Out of memory, malloc failed (tried to allocate 32220431361 bytes)
#[master (root-commit) 8053f0d]
Welcome to the Git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports
The latest feature release Git v1.7.12 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
42ec1037f1ee5bfeb405710c83b73c0515ad26e6 git-1.7.12.tar.gz
50bbfeba77af9a411cc1a1e41220782cf3fd9b5
This fixes a bug where git finds the incorrect merge parent. Consider a
repository with trunk, branch1 of trunk, and branch2 of branch1.
Without this change, git interprets a merge of branch2 into trunk as a
merge of branch1 into trunk.
Signed-off-by: Steven Walter
---
perl/Git/SVN.pm
Consider the case where you have trunk, branch1 of trunk, and branch2 of
branch1. trunk is merged back into branch2, and then branch2 is
reintegrated into trunk. The merge of branch2 into trunk will have
svn:mergeinfo property references to both branch1 and branch2. When
git-svn fetches the comm
Robert Luberda writes:
> Eric Wong wrote:
>
> Hi,
>
>> Junio C Hamano wrote:
>>> I should have asked this yesterday, but do you mean you want to have
>>> your "maint" in the upcoming 1.7.12? This does look like a useful
>>> thing to do, but does not seem like a regression fix to me.
>>
>> Yeah
Junio C Hamano writes:
> Either Jeff's "refname $name's log goes to logs/graveyard/$name~" or
> Michael's "append ~d to each directory component, append ~f to the
> leaf component" that are already proposed will keep "one file per
> name" property to allow us to open once and efficiently read the
Ramsay Jones writes:
> I had the same problem (or at least it *looks* like the same problem) on Linux
> last year (May 2011), which turned out to be a bug in the regex routines in an
> old version of glibc.
>
> I don't know OS X at all, so this may not be relevent; does OS X use glibc?
> (I didn
Kacper Kornet writes:
> The linked list describing sort options was not correctly set up in
> opt_parse_sort. In the result, contrary to the documentation. only the
> last of multiple --sort options to git-for-each-ref was taken into
> account. This commit fixes it.
>
> Signed-off-by: Kacper Korn
Kacper Kornet writes:
> Documentation of git-for-each-ref says that --sort= option can be
> used multiple times, in which case the last key becomes the primary key.
> However this functionality was never checked in test suite and is
> currently broken. This commit adds appropriate test in prepara
Alexey Muranov writes:
> I only suggested how to resolve conflicts between dead reflogs in
> graveyard if "next" and "next/foo" cannot coexist.
But Jeff's patch series already has the support for a case where you
delete next (graveyard gets 'next'), create next/foo and then delete
that (graveyar
Robert Luberda writes:
> Introduce a `--trim-svn-log' option and svn.trimsvnlog boolean
> configuration key for git svn commands.
>
> When enabled while retrieving commits from svn, git svn will strip any
> white spaces from beginnings and endings of SVN commit messages and will
> skip adding an
Introduce a `--trim-svn-log' option and svn.trimsvnlog boolean
configuration key for git svn commands.
When enabled while retrieving commits from svn, git svn will strip any
white spaces from beginnings and endings of SVN commit messages and will
skip adding an extra new line character before `git
Eric Wong wrote:
Hi,
> Junio C Hamano wrote:
>> I should have asked this yesterday, but do you mean you want to have
>> your "maint" in the upcoming 1.7.12? This does look like a useful
>> thing to do, but does not seem like a regression fix to me.
>
> Yeah, I wasn't sure what to name it since
Eric Wong wrote:
Hi,
>> I don't think it will be hard to make it configurable. I can try to make
>> such a change, do you have any preferences about the option and
>> configuration key names?
>
> No preference off the top of my head. As long as it makes sense to
> enough people here and is consi
On 19 Aug 2012, at 19:38, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> 2. I think that allowing both "next" and "next/foo" complicates
>> the mapping from branch names to file paths, and it does not seem
>> necessary if dead reflogs are moved away to "graveyard" anyway.
>
> It is unclear
The linked list describing sort options was not correctly set up in
opt_parse_sort. In the result, contrary to the documentation. only the
last of multiple --sort options to git-for-each-ref was taken into
account. This commit fixes it.
Signed-off-by: Kacper Kornet
---
builtin/for-each-ref.c |
Documentation of git-for-each-ref says that --sort= option can be
used multiple times, in which case the last key becomes the primary key.
However this functionality was never checked in test suite and is
currently broken. This commit adds appropriate test in preparation for fix.
Signed-off-by: Ka
Am 19.08.2012 16:50, schrieb Ramsay Jones:
> Brian Gernhardt wrote:
>> I've been getting a couple of test failures and finally had the
>> time to track them down.
>>
>> t4034-diff-words fails tests "22 diff driver 'bibtex'" and "26 diff
>> driver 'html'". Bisecting shows that the file started giv
Am 17.08.2012 20:11, schrieb Phil Hord:
> On Fri, Aug 17, 2012 at 12:44 PM, Jens Lehmann wrote:
>>
>> I'm almost there. The only thing left is to check if a nested
>> submodule is using a git directory. In that case I expect "rm" to
>> fail even when -f is used to protect the submodule's history.
Steven Walter wrote:
> On Sat, Aug 18, 2012 at 3:51 PM, Sam Vilain wrote:
> > On 08/11/2012 10:14 AM, Steven Walter wrote:
> >> ---
> >> git-svn.perl |1 -
> >> t/t9164-git-svn-fetch-merge-branch-of-branch2.sh | 53
> >> ++
Thanks a
Hi Thomas,
Just an FYI; two out of the three gcc compilers I use (Linux, cygwin
but not MingW), issue the following warnings:
CC read-cache-v5.o
read-cache-v5.c: In function `write_index_v5':
read-cache-v5.c:1011: warning: 'dir' might be used uninitialized in this
function
re
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Ramsay Jones wrote:
>>> Junio C Hamano wrote:
>>
Observing that all well-written test scripts we have begin with this
boilerplate line:
test_expect_success setup '
I wouldn't mind introducing a new helper function
In particular, gcc complains thus:
CC vcs-svn/fast_export.o
vcs-svn/fast_export.c: In function 'fast_export_begin_note':
vcs-svn/fast_export.c:77: warning: long long unsigned int format, \
different type arg (arg 2)
In order to fix the warning, we cast the second size_t a
Brian Gernhardt wrote:
> I've been getting a couple of test failures and finally had the time to track
> them down.
>
> t4034-diff-words fails tests "22 diff driver 'bibtex'" and "26 diff driver
> 'html'". Bisecting shows that the file started giving me errors in commit
> 8d96e72 "t4034: bulk
Alexey Muranov writes:
> 2. I think that allowing both "next" and "next/foo" complicates
> the mapping from branch names to file paths, and it does not seem
> necessary if dead reflogs are moved away to "graveyard" anyway.
It is unclear why the first two lines above leads to the conclusion
"it d
"Joachim Schmitz" writes:
> Found the problem: our mkdir(dir,flags) fails with ENOENT when dir ends with
> a '/'.
> Not sure whether this us a bug on out platform or just allowed by POSIX and
> as such a wrong assumption in git though?
>
> [shortly after]
> A bit of googleing revealed that there
On 17.08.12 19:30, Junio C Hamano wrote:
> Robin Rosenberg writes:
>
>> Remove extraneous parentheses and braces
>> Remove redundant NUL-termination
>> Check result of unlink when probing for decomposed file names
>>
>> Signed-off-by: Robin Rosenberg
>> ---
> Thanks. I've found and fixed a bit m
Brian Gernhardt writes:
> I wonder if there is something non-portable about the bibtex
> filter? (The HTML filter as well, since that errors on my machine
> too.)
Yeah, that I didn't think of, but is a possibility (part of (1)
above).
The HTML one is "[^<>= \t]+" and
the Bibtex one is "[={}\"]
Michael Haggerty writes:
> I just verified that the combination of your two suggestions (i.e., the
> patch below) fixes the problem for me.
Good to know.
The only remaining two worries from me are if everybody has working
pwd at that early point in the script (I think MINGW replaces pwd
with it
Michael Haggerty writes:
> It's been a wish of mine, but it's pretty low priority. I've also
> brainstormed about some other changes that could be connected with a new
> repo format:
>
> * Allow "deleted" loose references (for example denoted by value 0{40})
> that override packed references wit
On Tuesday 2012-08-14 17:52, Joachim Schmitz wrote:
> @@ -98,6 +99,11 @@
> #include
> #include
> #include
>+#ifdef __TANDEM
>+# include /* for strcasecmp() */
>+ typedef int intptr_t; /* not "int *" ?!? */
>+ typedef unsigned int uintptr_t; /* not "unsigned int *" ?!? */
Of course not. intp
On 08/18/2012 10:36 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I can work around the problem by using "--root=/run/shm".
>
> I do not necessarily think it is a work around.
http://en.wiktionary.org/wiki/workaround:
2. (computing) A procedure or a temporary fix that bypasses a pr
On 08/18/2012 10:39 PM, Junio C Hamano wrote:
> mhag...@alum.mit.edu writes:
>
>> Given that a flag day would anyway be required to add a d/f-tolerant
>> system, I could live with a separate "graveyard" namespace as
>> originally proposed by Jeff.
>>
>> However, I still think that as long as we ar
On Thu, 2012-08-16 at 12:47 -0600, Jean Tappan wrote:
> I am looking for a tool that will control not only versioning for
> software, but also the software's associated user and support manuals.
> I haven't been able to find anything that addresses this particular
> topic. Can you tell me about thi
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> Excuse me if i miss something again, but i might be willing to
>> discuss the "ultimate destination". Could you possibly state in
>> simple terms what the problem with determining the "ultimate
>> destination" is?
>
On 18-08-2012 14:39, James R. McKaskill wrote:
As a twist the code does not use the svn library, but rather talks the
svn protocol directly. I actually found it much easier to go this route
then trying to bend everything to how the svn library understands
things. It also has the advantage of not
On 08/19/2012 01:39 AM, Junio C Hamano wrote:
Junio C Hamano writes:
The bigger question is whether this example is improved by including
quotation marks, or whether they are just a distraction from the main
point. I abstain.
Thanks for spelling that bigger question out. Given that the
exa
> From: Shawn Pearce [mailto:spea...@spearce.org]
> Sent: Friday, August 10, 2012 7:38 PM
> To: Joachim Schmitz
> Cc: git@vger.kernel.org; rsbec...@nexbridge.com
> Subject: Re: Porting git to HP NonStop
>
> On Fri, Aug 10, 2012 at 10:32 AM, Joachim Schmitz
> wrote:
> >> then use `git init --bare`
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> I hope my opinion might be useful because i do not know anything
>> about the actual implementation of Git,...
>
> That sounds like contradiction.
I meant that i am psychologically not attached to the current behavio
On 19 Aug 2012, at 02:02, Junio C Hamano wrote:
> Alexey Muranov writes:
>
>> I hope my opinion might be useful because i do not know anything
>> about the actual implementation of Git,...
>
> That sounds like contradiction.
I think that the implementation (the code), the model, and the interf
49 matches
Mail list logo
