On Wed, Mar 5, 2014 at 1:29 PM, Junio C Hamano wrote:
> If the user said "git merge" while another "git merge" is still
> outstanding, we would want to say "You have not concluded your
> previous merge" and die, and you presumably want to add the same
> "how to abort" message there. Such a codepa
On 02/26/14 15:53, Junio C Hamano wrote:
> - start warning against "reset" (no mode specifier) and "reset --mixed"
>when the index is unmerged *and* MERGE_HEAD exists; and then
Why do we also want to check if index is unmerged? This situation can
happen regardless of having conflicts or not (-
This is mainly changing messages that say:
run "git foo --bar"
to
use "git foo --bar" to baz
Although the commands and flags are usually self-explanatory, this is
more consistent with other status messages, and gives some sort of
explanation to the user.
Signed
Print message during "git merge" and "git status".
Add a new "mergeHints" advice to silence these messages.
Signed-off-by: Andrew Wong
---
Documentation/config.txt | 3 +++
advice.c | 2 ++
advice.h | 1 +
builtin/merge.c
we want to
make "git reset" error out when used in the middle of a merge. For now,
we simply print out a warning to the user.
Signed-off-by: Andrew Wong
---
builtin/reset.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/builtin/reset.c b/builtin/reset.c
index
x27;ll change this into an error to prevent work tree from becoming a
mess.
Andrew Wong (3):
wt-status: Make status messages more consistent with others
merge: Advise user to use "git merge --abort" to abort merges
reset: Print a warning when user uses "git reset" durin
On Fri, Mar 14, 2014 at 10:33 AM, Marc Branchaud wrote:
> I know this approach was suggested earlier, but given these dangers it seems
> silly to give this big warning on a plain "git reset" but still go ahead and
> do the things the warning talks about.
>
> Is there any issue with changing "git r
On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
> Suppose developer send 10 patches on branch1 where are changes in terms
> of _/ then I need to apply on my local repo branch1, till now
> is fine then I need to apply same 10 patches on to my branch2 where source
> tree which is quite question
On Fri, Mar 14, 2014 at 4:01 PM, Jagan Teki wrote:
> On Sat, Mar 15, 2014 at 12:48 AM, Andrew Wong wrote:
>> On Fri, Mar 14, 2014 at 1:39 PM, Jagan Teki wrote:
>>> Suppose developer send 10 patches on branch1 where are changes in terms
>>> of _/ then I need to app
On Fri, Mar 14, 2014 at 4:55 PM, Junio C Hamano wrote:
>> For the users that really did mean "--merge", the warning is silly.
>> It's basically saying "We know that you're about to mess up your work
>> tree, but we let you mess up anyway. Learn the correct way so that you
>> don't mess up next tim
On Fri, Mar 14, 2014 at 4:57 PM, Jagan Teki wrote:
> Mr.J> git cherry-pick -X subtree=foo
> cc70089614de16b46c08f32ea61c972fea2132ce
> 14e9c9b20e3bf914f6a38ec720896b3d67f94c90
> error: could not apply cc70089... A
> hint: after resolving the conflicts, mark the corrected paths
> hi
On Mon, Mar 17, 2014 at 7:04 PM, Junio C Hamano wrote:
> Has this series been tested with existing test suite? I tentatively
> queued it to 'pu' but then had to revert because many tests started
> failing, causing me to redo the today's integration cycle for 'pu'
> once again.
I tested it during
Elia Pinto wrote:
> The Git CodingGuidelines prefer the $( ... ) construct for command
> substitution instead of using the back-quotes, or grave accents (`..`).
I did not check very closely, but for the git-svn tests:
Acked-by: Eric Wong
Thanks.
--
To unsubscribe from this list: send th
Johan Herland wrote:
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -86,14 +86,7 @@ COMMANDS
> (refs/remotes/$remote/*). Setting a prefix is also useful
> if you wish to track multiple projects that share a common
> repository.
> -+
> -NOTE: In Git v2.0,
Johan Herland wrote:
> Feel free to add/squash this on top.
Thanks! Squashed and pushed.
The following changes since commit cc291953df19aa4a97bee3590e708dc1fc557500:
Git 2.0-rc0 (2014-04-18 11:21:43 -0700)
are available in the git repository at:
git://bogomips.org/git-svn.git master
for
Lawrence Velázquez wrote:
> Git no longer seems to use these flags or their associated config keys;
> when they are present, git-svn outputs a message indicating that they
> are being ignored.
>
> Signed-off-by: Lawrence Velázquez
Thanks, will queue.
Signed-off-by: E
acked in git (or SVN).
Thanks to Andrej Manduch for originally
noticing the issue and fixing my original version of this to handle
more corner cases such as "/path/to/top/../top" and
"/path/to/top/../top/file" as shown in the new test cases.
Signed-off-by: Andrej Manduch
Signed-off
Allow -B and -A to act as short aliases for --before and --after
options respectively. This reduces typing and hopefully allows
reuse of muscle memory for grep(1) users.
Signed-off-by: Eric Wong
---
Will push to git://bogomips.org/git-svn.git
Documentation/git-svn.txt | 2 ++
git-svn.perl
s);
+
$path = canonicalize_path($path);
} else {
$path = canonicalize_path($cmd_dir_prefix . $path);
--8<---
From: Eric Wong
Subject: [PATCH v3] git svn: info: correctly handle absolute path args
Calling "git svn info $(pwd)" would
On my Debian 7 system, this gives annoying warnings when the output
of "git svn" commands are redirected:
Unable to get Terminal Size. The TIOCGWINSZ ioctl didn't work.
The COLUMNS and LINES environment variables didn't work. The
resize program didn't work.
Eric Wong wrote:
> On my Debian 7 system, this gives annoying warnings when the output
s/gives/fixes/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
://bogomips.org/git-svn.git master
for you to fetch changes up to 30d45f798d1a4b14759cd977b68be4476d66ea17:
git-svn: delay term initialization (2014-09-14 08:08:54 +)
Eric Wong (3):
git svn: info: correctly handle absolute path
Hin-Tak Leung wrote:
> (I am not on the list - please CC)
Done, it is standard practice for git :)
> Thanks for git-svn - I use it instead of subversion itself for many years now.
>
> Just thought I'd ask/report a few issues I noticed for some time
> now, of tracking development of a particular
Eric Wong wrote:
> Jakob sent some patches a few months ago which seem to address the
> issue. Unfortunately we forgot about them :x
Hin-Tak: have you tried Jakob's patches? I've taken another look,
signed-off and pushed to my master.
> Can you take a look at the follo
Fabian Schmied wrote:
> Hi,
>
> I'm currently migrating an SVN repository to Git using git-svn (Git
> for Windows 1.8.3-preview20130601), and I'm experiencing severe
> performance problems with "git svn fetch". Commits to the SVN "trunk"
> are fetched very fast (a few seconds or so per SVN revisi
Robert Dailey wrote:
> Hey guys,
>
> I'm using MSMTP to define 2 accounts: Work email and personal email.
> If I send patches via email through Git at work, I want to use my work
> SMTP server and account information. Likewise at home for personal
> projects, I want to use my personal SMTP accoun
Eric Wong wrote:
> Hin-Tak (Cc-ed) reported good improvements with them, but also
> a large memory increase:
This might reduce the pathname and internal hash overheads:
8<---
From: Eric Wong
Date: Sun, 19 Oct 2014 02:26:53 +
Subject: [P
Eric Wong wrote:
> This reduces hash lookups for looking up cache data and will
> simplify tying data to disk in the next commit.
I considered the following, but GDBM might not be readily available on
non-POSIX platforms. I think the other problem is the existing caches
are still in
n thing to care about:
Does the repository history look right?
The check_cherry_pick cache can be made smaller, too:
--- 8< -
From: Eric Wong
Subject: [PATCH] git-svn: reduce check_cherry_pick cache overhead
We do not need to store entire list
thing like the below? (on top of your original two patches)
Pushed to my master @ git://bogomips.org/git-svn.git
Eric Wong (2):
git-svn: reduce check_cherry_pick cache overhead
git-svn: cache only mergeinfo revisions
Jakob Stoklund Olesen (2):
git-svn: only l
ng fix to the commit message:
Advertise that the svn-remote..pushurl config key allows specifying
the commit URL for the entire SVN repository in the documentation of the
git svn dcommit command.
Signed-off-by: Eric Wong
Pushed with updated commit message to "master" of gi
Tommaso Colombo wrote:
> When populating svn:mergeinfo, git-svn merge checks if the merge parent
> of the merged branch is under the same root as the git-svn repository.
> This was implemented comparing $gs->repos_root with the return value of
> of cmt_metadata for the merge parent. However, the f
commit -q -m A
nr=$((nr - 1))
done
echo "repository created in $repo"
-8<--
Signed-off-by: Eric Wong
---
Pushed to master of git://bogomips.org/git-svn
However, memory usage still seems to grow infinitely even in this simp
ems :<
8<-
From: Eric Wong
Date: Tue, 21 Oct 2014 06:23:22 +
Subject: [PATCH] git-svn: remove mergeinfo rev caching
This should further reduce memory usage from the new mergeinfo
speedups without hurting performance too much, assuming
reasonabl
Eric Wong wrote:
> + SVN::Core->gpool->clear;
Unfortunately, SVN::Core->gpool is not available in older SVN,
but I'm cooking a better patch which saves even more memory.
--
To unsubscribe from this list: send the line "unsubscribe git"
uot;
if ! test -f a
then
> a
svn add a
svn commit -m 'A'
fi
nr=1
while test $nr -gt 0
do
echo $nr > a
svn commit -q -m A
nr=$((nr - 1))
done
echo "repository created in $repo"
-8<---
Hin-Tak Leung wrote:
> I keep tabs of a particular svn repository over many years
> and run "git svn fetch --all" every few days. So that's the old clone.
> Since this discussion started, I made a new one with git 2.1.0 patched
> with the first two patches below, a couple of weeks ago. And I ran
>
Hin-Tak Leung wrote:
> Comparing trunk of old and new, I see one difference - One short
> commit message is missing in the *old* (the "Add checkPoFiles etc." part)
> and so all the sha1 afterwards differed. Is that an old bug that's fixed
> and therefore I should throw away the old clone?
I don
Hin-Tak Leung wrote:
> the old didn't missing a revision - just a revision 'message' - blank
> instead of 3 words, above the git svn id. I supppse it is possible
> some power problem or etc caused this. I'll check the other branches
> as well, and possibly clone again to be sure. ( The new clone d
This override was probably never necessary, but most likely a no-op
as it does not appear to do anything in SVN::Ra itself.
Signed-off-by: Eric Wong
---
perl/Git/SVN/Ra.pm | 4
1 file changed, 4 deletions(-)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 1828519..e326849
There is no reason to keep entries in the %revs hash after we're
done processing a revision, so allow entries become freed as
processing continues.
Signed-off-by: Eric Wong
---
perl/Git/SVN/Ra.pm | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/perl/Git/SVN/Ra.pm b/per
rom Jakob to improve svn:mergeinfo
performance along with some followup patches to reduce memory
use. However memory bloat is still a problem.
Currently in my "master" branch of git://bogomips.org/git-svn
Eric Wong (4):
git-svn: reduce check_cherry_pick cache overhead
git-svn:
Hin-Tak Leung wrote:
> On Sat, Oct 25, 2014 00:34 BST Eric Wong wrote:
> >Hin-Tak Leung wrote:
> >> 0006-git-svn-clear-global-SVN-pool-between-get_log-invoca.patch
> >
> >0006 is insufficient and incompatible with older SVN.
> >I pushed "git-svn: re
Hin-Tak Leung wrote:
> btw, git svn seems to disallow single word commit messages (or is it a
> svn config?). i found that i could not do git svn dcommit, when i had
> merely did git commit -m 'typos', for example, for an svn repo i have
> write access to. (I don't have them many such things, so i
svn.r-project.org/R
[2] file:// repos causes libsvn to use more memory internally
Signed-off-by: Eric Wong
Cc: Hin-Tak Leung
---
This patch is in my "less-memo" branch of bogomips.org/git-svn.git
Info here:
(not intended as a pull request for Junio, yet)
The following chang
Hin-Tak Leung wrote:
> On Sat, Oct 25, 2014 00:34 BST Eric Wong wrote:
> >0006 is insufficient and incompatible with older SVN.
> >I pushed "git-svn: reload RA every log-window-size"
> >(commit dfa72fdb96befbd790f623bb2909a347176753c2) instead
> >which saves
Eric Wong wrote:
> Which SVN version are you using? I'm cloning (currently on r373xx)
> https://svn.r-project.org/R using --stdlayout and
> unable to see memory growth of the git-svn Perl process beyond 40M
> (on a 32-bit system).
git-svn hit 45M and took 11:44 to finish.
Hin-Tak Leung wrote:
> To compare the old clone with the new, I did:
>
> git branch -r | sort | xargs -n 1 git log --decorate=full -n 1
>
> It turned out other than the empty vs 3 word commit messages
> about two years ago on trunk (which are inherited in all the newer
> branches), there are two
Hin-Tak Leung wrote:
> >Eric Wong wrote:
> >> Which SVN version are you using? I'm cloning (currently on r373xx)
> >> https://svn.r-project.org/R using --stdlayout and
> >> unable to see memory growth of the git-svn Perl process beyond 40M
> >> (
Hin-Tak Leung wrote:
> Hi, I patched my system git with the recent git-svn improvements, and just use
> it for general use; so theses are the patches, against 2.1.0.
>
> 0001-git-svn-only-look-at-the-new-parts-of-svn-mergeinfo.patch
> 0002-git-svn-only-look-at-the-root-path-for-svn-mergeinfo.patc
This should help me track down errors in git-svn more easily:
write .git/Git_XX: Bad file descriptor
at /usr/lib/perl5/SVN/Ra.pm line 623
Signed-off-by: Eric Wong
---
Not sure you want to take this separately or in a git-svn pull.
Still working on the error this patch
Memoizing these initialization functions saves some memory for
long fetches which require scanning many unwanted revisions
before any wanted revisions happen.
Signed-off-by: Eric Wong
---
perl/Git/SVN/Ra.pm | 63 +++---
1 file changed, 36
Hin-Tak Leung wrote:
> On Tue, 28/10/14, Eric Wong wrote:
>
> > So both merges
> are correct, but we lose one, and gain one?
> I'll try to check more closely tomorrow.
> Can you point out
> the exact revisions in the
> R repo? Thanks.
>
>
> T
Hin-Tak Leung wrote:
> Argh, sorry. I thought I included the info but I didn't.
Thanks. I'll try a different version of svn later.
> What do you think were missing in my e-mails?
I was skimming and missed the part about Debian packages :)
--
To unsubscribe from this list: send the line "unsubsc
And minor reformatting while we're in the area.
Signed-off-by: Eric Wong
---
perl/Git/SVN.pm | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 893b9a8..d9a52a5 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1798,12 +17
Neither find_extra_svk_parents or find_extra_svn_parents ever
used the `$ed' parameter.
Signed-off-by: Eric Wong
---
perl/Git/SVN.pm | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 5f9d469..893b9a8 100644
--- a/per
/bogomips.org/git-svn.git master
for you to fetch changes up to da0bc948ac2e01652a150fd4a57cebad6143242c:
git-svn: add space after "W:" prefix in warning (2014-10-30 08:31:28 +)
Eric Wong (11):
git-svn: reduce
g file descriptor is closed
without the PerlIO layer knowing about it. This is likely a bug
inside libsvn (1.6.17), as none of the Git.pm or Git::SVN
modules close IOs without the knowledge of the PerlIO layer.
Cc: Kyle J. McKay
Signed-off-by: Eric Wong
---
Kyle/Junio: thoughts? I'm running
Hin-Tak Leung wrote:
> That's quite straight-forward, I think - except for the recent burst (I am
> essentially
> adapting the git 2.1.0 release shipped by the upcoming fedora 21 scheduled
> for christmas)
> I tend to update to the latest fedora release about a week or two after
> release;
> f
"Kyle J. McKay" wrote:
> On Oct 30, 2014, at 15:08, Eric Wong wrote:
> >For a (currently) unknown reason, Git::SVN::Fetcher::close_file
> >sometimes triggers "Bad file descriptor" errors on syswrite when
> >writing symlink contents on the "svn_hash&qu
.org/git-svn.git master
for you to fetch changes up to 9d536cf625cf42b8a8272070e3720325c68f3b48:
git-svn: coerce check_path and get_log args to int (2014-10-30 23:10:57 +)
----
Eric Wong (12):
git-svn: reduce check_cherry_pick
f: <1414636504.45506.yahoomailba...@web172304.mail.ir2.yahoo.com>
ref: <1414722617.89476.yahoomailba...@web172305.mail.ir2.yahoo.com>
Signed-off-by: Eric Wong
Cc: Hin-Tak Leung
---
This should fix the vbox clone problem. SVN Perl binding
breakage (again :<). I shall revert the int() ch
f: <1414636504.45506.yahoomailba...@web172304.mail.ir2.yahoo.com>
ref: <1414722617.89476.yahoomailba...@web172305.mail.ir2.yahoo.com>
Signed-off-by: Eric Wong
Cc: Hin-Tak Leung
---
Sorry, waaay past my bed time. This version doesn't infinite loop
on autoload or older SVN(*) (at least I
Eric Wong wrote:
> Hi Junio, I haven't heard back from Hin-Tak about the last one
> ("git-svn: coerce check_path and get_log args to int")[1],
> but I think it's a harmless defensive patch in case you
> want to tag 2.2-rc0 soon.
OK, that coercion patch was p
Eric Wong wrote:
> This avoids the following failure with normal "get_dir" on newer
> versions of SVN (tested with SVN 1.8.8-1ubuntu3.1):
>
> Incorrect parameters given: Could not convert '%ld' into a number
Filed a bug in Debian since I hit it in sid, to
Hin-Tak Leung wrote:
> On Fri, Oct 31, 2014 19:08 GMT Eric Wong wrote:
> >Filed a bug in Debian since I hit it in sid, too:
> >http://bugs.debian.org/767530
> >
> >Thanks all.
>
> Hmm, but why are you filing at debian? I had the error when i applied
> the d
Hin-Tak Leung wrote:
> Tested-by: Hin-Tak Leung
>
> Okay, this one on top of my "git 2.1.0 + 10 recent git svn improvement
> patches"
> allow me to fetch further.
>
> I suspect the problem must be elsewhere though, and this just band-aided
> over it.
>
> For me, reverting the additional patch
Hin-Tak Leung wrote:
> While my 2.10 + 11 patches continue to fetch, where it was stuck, now
> it does "Couldn't find revmap..." - also, the single branch clone is doing
> the 'trunk/branches/... thing - are these supposed to happen?
I'm afraid this is a problem with the vbox repo not publishing
Hin-Tak Leung wrote:
> Hmm, I see you are filing the problem against subversion. FWIW,
> I am currently using subversion-perl-1.8.10-1.fc20.x86_64 package on fedora
> 20.
> I'll possibly think about filing one under redhat's bugzilla and
> let them take it upward too.
This is another problem wit
Michael Haggerty wrote:
> Michael Haggerty (2):
> create_default_files(): don't set u+x bit on $GIT_DIR/config
> config: clear the executable bits (if any) on $GIT_DIR/config
Thanks, I should've noticed this earlier :x
Tested-by: Eric Wong
Since the damage is done, perha
Thanks! I still haven't gotten around to looking at svn:mergeinfo
things, but this passes tests so I'm inclined to merge this unless
somebody disagrees.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
Jakob Stoklund Olesen wrote:
> Subversion can put mergeinfo on any sub-directory to track cherry-picks.
> Since cherry-picks are not represented explicitly in git, git-svn should
> just ignore it.
Hi, was git-svn trying to track cherry-picks as merge before?
This changes behavior a bit, so two i
Piotr Krukowiecki wrote:
> On Mon, Apr 28, 2014 at 9:26 PM, Aaron Laws wrote:
> > The way I understand it, when `git svn dcommit` is run, new commits
> > are created (A' is created from A adding SVN information), then the
> > current branch is moved to point to A'. Why don't we move any other
> >
Users may already store sensitive data such as imap.pass in
.git/config; making the file world-readable when "git config"
is called to edit means their password would be compromised
on a shared system.
Signed-off-by: Eric Wong
---
config.c | 7 +++
t/t1300-repo-con
Users may already store sensitive data such as imap.pass in
.git/config; making the file world-readable when "git config"
is called to edit means their password would be compromised
on a shared system.
[v2: updated for section renames, as noted by Junio]
Signed-off-by: Eric Wong
---
git repository, the following
document describes it:
http://ssoma.public-inbox.org/ssoma_repository.txt
Thanks for reading this far!
--
Eric Wong
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordo
Felipe Contreras wrote:
> No updates since 2010, and no tests.
Who benefits from this removal? Is this causing a maintenance
burden for Junio?
> Plus, foreign SCM tools should live out-of-tree anyway.
Even if so, there ought to be a transitionary period in case there are
any users. We would n
Felipe Contreras wrote:
> Eric Wong wrote:
> > Felipe Contreras wrote:
> > > No updates since 2010, and no tests.
> >
> > Who benefits from this removal? Is this causing a maintenance
> > burden for Junio?
>
> It is cruft that nobody uses and we ar
ieve them. I've forgotten how to use tla to get a public repo,
even.
> Eric Wong wrote:
> > No, I am not convinced existing foreign SCM tools should move
> > out-of-tree. Perhaps something like the following would be helpful:
>
> Tell that to Junio.
>
> If tools
Thomas Adam wrote:
> I think I speak for everyone when I say: fuck off.
I wouldn't put it so harshly...
Felipe: I suggest you take a long vacation away from development.
Whatever good you may be able to contribute today is drowned out by your
behavior. The projects you are involved with will g
Junio C Hamano wrote:
> Johannes Sixt writes:
> > Am 08.07.2014 21:34, schrieb Jens Lehmann:
> >>> And Msysgit complains
> >>> error: fchmod on c:/xxxt/trash
> >>> directory.t7613-merge-submodule/submodule_update_repo/.git/modules/sub1/config.lock
> >>> failed: Function not implemented
> >>
>
Torsten Bögershausen wrote:
> (And why is it "& 0" and not "& 0777")
This is to preserve the uncommon sticky/sgid/suid bits. Probably not
needed, but better to keep as much intact as possible.
> Can we avoid the fchmod() all together ?
For single-user systems, sure.
For multi-user syst
uring "reword",
> 2011-11-30); it seems that the primary point of the change was to
> make sure it exits and the warning message may not have been well
> thought out, but before discarding the result of somebody else's
> work, it may not be a bad idea to ask just in case
On Thu, Jul 10, 2014 at 12:35 PM, Fabian Ruch wrote:
> That is still taken care of by exit_with_patch here.
Oh, that's right. Ok, go ahead and remove the third warning then. Thanks!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel
Andrej Manduch wrote:
> * this fixes 'git svn info `pwd`' buggy behaviour
Good catch, the commit could use a better description, something like:
--- 8<
Subject: [PATCH] git-svn: "info" checks for dirs more carefully
This avoids a "Reading from
Monard Vong wrote:
> If a client certificate is required to connect to svn, "git svn branch"
> always prompt the user for the certificate location and password,
> even though those parameters are stored in svn file "server"
> located in svn config dir (generally ~/.subversion).
> On the opposite,
Thanks. In the future, it's expected to Cc: anybody who showed interest
in previous versions of your patch.
Monard Vong wrote:
> When a client certificate is required to connect to a Subversion repository,
> the certificate location and password may be stored in Subversion config
> directory.
>
Andrej Manduch wrote:
> On 07/24/2014 12:04 AM, Eric Wong wrote:
> > Andrej Manduch wrote:
> >> * this fixes 'git svn info `pwd`' buggy behaviour
> >
> > While your patch avoids an error, but the output isn't right, either.
> > I tried it runni
Andrej Manduch wrote:
> On 08/03/2014 02:22 PM, Andrej Manduch wrote:
> > Nice touch, It works like charm. However unfortunatelly now I think you
> > introduced new bug :)
Good catch!
> > On 08/03/2014 04:45 AM, Eric Wong wrote:
> >> sub cmd_info {
> >>
Patrick Reynolds wrote:
> But in the real world, several real potential callers, including
> Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE
> ignored.
s/Unicorn/Ruby/
But unicorn would ignore SIGPIPE it if Ruby did not; relying on SIGPIPE
while doing any multiplexed I/O doe
My name is Lee Wong,
I am contacting you beacuse a client I work for who pass away over 8 months ago
did not make
a will.
I believe you may be the heir to their unclaimed estate, please send your full
name so we can proceed
with this matter urgently and I can provided further details.
Thank
Detect a cherry-pick merge if there's only one parent and the git-svn-id
metadata exists. Then, get the parent's mergeinfo and merge this commit's
mergeinfo.
---
git-svn.perl | 52 +--
t/t9161-git-svn-mergeinfo-push.sh | 30 +
Instead of always storing mergeinfo at the root, give an option to store the
merge info in a subdirectory. The subdirectory must exist before we try to set
its property.
---
git-svn.perl | 21 +++--
perl/Git/SVN/Editor.pm| 5 -
t/t9161-git-svn-
cords that information in
svn:mergeinfo. These patches will enable git-svn to do the same.
Andrew Wong (3):
git-svn: Generate mergeinfo for every commit
git-svn: Support cherry-pick merges
git-svn: Add config to control the path of mergeinfo
git-svn.perl
The previous behavior would only generate mergeinfo once using the first
commit, and use that mergeinfo for all remaining commits. The new behavior will
generate it once for every commit.
---
git-svn.perl | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b
Aleksey Vasenev wrote:
> ---
What Thomas said about commit messages.
Note: I hardly use git-svn or SVN anymore and don't pay attention
to SVN changes.
Some style nitpicks:
> @@ -1304,16 +1318,20 @@ sub cmd_create_ignore {
> # which git won't track
> mkpath([$path])
his in an addendum to the commit:
Subversion serf backend in versions 1.8.5 and below has a bug(*) that the
...
* [ew: fixed in Subversion r1553376 as noted by Jonathan Nieder]
> > Cc: Benjamin Pabst
> > Cc: Eric Wong
> > Cc: Jonathan Nieder
>
> No need fo
manjian2...@gmail.com wrote:
> From: linzj
> I am trying to improve git svn's performance according to some
> profiling data.As the data showed,_rev_list subroutine and rebuild
> subroutine are consuming a large proportion of time.So I improve
> _rev_list's performance by memoize its resul
manjian2...@gmail.com wrote:
> * perl/Git/SVN.pm
> Modified according to Eric Wong
>
> >Hi, I'm interested in this. How much did performance improve by
> >(and how many revisions is the repository)>
> Our svn server are built in a LAN,15152 revisions.Not opti
> hours to 3-4 hours.
>
> Signed-off-by: lin zuojian
Thanks!
Signed-off-by: Eric Wong
Pushed for Junio.
The following changes since commit d9bb4be53bc5185244b4be9860562a012803bacb:
Merge tag 'gitgui-0.19.0' of http://repo.or.cz/r/git-gui (2014-01-21 13:16:17
-0800)
are
601 - 700 of 955 matches
Mail list logo
