Junio C Hamano wrote:
> Eric Wong writes:
> > Thanks for reminding me, I went back to an old chroot 1.4.2 indeed
> > does fail canonicalization.
> >
> > Will bisect and squash a fix in.
>
> Oops; should I eject this out of next and wait for a reroll, then?
Y
Eric Wong wrote:
> Michael G Schwern wrote:
> > On 2012.7.28 6:55 AM, Jonathan Nieder wrote:
> > > Michael G. Schwern wrote:
> > >> --- a/perl/Git/SVN/Utils.pm
> > >> +++ b/perl/Git/SVN/Utils.pm
> > >> @@ -86,6 +86,27 @@ sub _collapse_do
Eric Wong wrote:
> Junio C Hamano wrote:
> > Eric Wong writes:
> > > Thanks for reminding me, I went back to an old chroot 1.4.2 indeed
> > > does fail canonicalization.
> > >
> > > Will bisect and squash a fix in.
> >
> > Oops; sh
"Robin H. Johnson" wrote:
> On Thu, Aug 02, 2012 at 11:58:08AM -0700, Junio C Hamano wrote:
> > > Thanks from me as well. I'm still worried about whether the increased
> > > use of canonicalize_url will introduce regressions for the existing
> > > SVN 1.6 support, and I should have time to look
Steven Walter wrote:
> Consider the case where you have trunk, branchA of trunk, and branchB of
> branchA. trunk is merged back into branchB, and then branchB is
> reintegrated into trunk. The merge of branchB into trunk will have
> svn:mergeinfo property references to both branchA and branchB.
Steven Walter wrote:
> 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.
Sam: your eyes would be much a
Peter Baumann wrote:
> Therefore the easiest solution to clear the cache is to delete the files
> on disk in 'git svn reset'. Normally, deleting the files behind the back
> of the memoization module would be problematic, because the in-memory
> representation would still exist and contain wrong da
Peter Baumann wrote:
> On Tue, Aug 07, 2012 at 08:45:10PM +, Eric Wong wrote:
> > Peter Baumann wrote:
> > > + for my $suffix (qw(yaml db)) {
> > > + unlink("$cache_file.$suffix");
> >
> > Nee
Robert Luberda wrote:
> Eric Wong wrote:
> >> + echo "PATH=\"$PATH\"; export PATH" >> $hook
> >> + echo "svnconf=\"$svnconf\"" >> $hook
> >> + cat >> "$hook" <&
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 my master is still carrying
Mic
Peter Baumann wrote:
> First, let me thank you for your review and your detailed explanation.
> I really appreciate it.
You're welcome, Peter. Thanks again for the patch. I've signed-off and
pushed for Junio.
The following changes since commit 034161a94e827ef05790b1c7ce5a6e3e740c864e:
Merge
Junio C Hamano wrote:
> Eric Wong writes:
> > Peter Baumann (1):
> > git svn: reset invalidates the memoized mergeinfo caches
> >
> > Robert Luberda (1):
> > git svn: handle errors and concurrent commits in dcommit
>
> OK, so these two are fi
Steven Walter wrote:
> Consider the case where you have trunk, branchA of trunk, and branchB of
> branchA. trunk is merged back into branchB, and then branchB is
> reintegrated into trunk. The merge of branchB into trunk will have
> svn:mergeinfo property references to both branchA and branchB.
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
Barry Wardell wrote:
> These patches fix a bug which prevented git-svn from working with repositories
> which use gitdir links.
>
> Changes since v2:
> - Rebased onto latest master.
> - Added test case which verifies that the problem has been fixed.
> - Fixed problems with git svn (init|clone|
Barry Wardell wrote:
> On Wed, Jan 23, 2013 at 2:32 AM, Eric Wong wrote:
> > Does squashing this on top of your changes fix all your failures?
> > I plan on squashing both your changes together with the below:
>
> Yes, I can confirm that applying this patch on top of min
We do not need to call uc() separately for sprintf("%x")
as sprintf("%X") is available.
Signed-off-by: Eric Wong
---
perl/Git/SVN.pm| 4 ++--
perl/Git/SVN/Editor.pm | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/perl/Git/SVN.pm b/perl/Git/
:
git-svn: cleanup sprintf usage for uppercasing hex (2013-01-24 01:30:04 +)
Barry Wardell (1):
git-svn: Simplify calculation of GIT_DIR
Eric Wong (1):
git-svn: cleanup sprintf usage for uppercasing hex
git-svn.perl
Junio C Hamano wrote:
> Eric Wong writes:
>
> > diff --git a/git-svn.perl b/git-svn.perl
> > index c232798..e5bd292 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -332,11 +332,13 @@ if ($cmd && $cmd =~ /(?:clone|init|multi-init)$/) {
>
er is unchanged.)
Barry Wardell (1):
git-svn: Simplify calculation of GIT_DIR
Eric Wong (1):
git-svn: cleanup sprintf usage for uppercasing hex
git-svn.perl | 37 ++---
perl/Git/SVN.pm | 4
Signed-off-by: Andrew Wong
---
Documentation/githooks.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 8181e4e..eab9b35 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -365,7 +365,7
(adding Sam to the Cc:, I rely on him for SVN merge knowledge)
Jan Pešta wrote:
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a
The previous code was assuming length ends at either `)` or `,`, and was
not handling the case where strcspn returns length due to end of string.
So specifying ":(top" as pathspec will cause the loop to go pass the end
of string.
Signed-off-by: Andrew Wong
---
setup.c | 6 --
1 fi
On 3/7/13, Junio C Hamano wrote:
> The parser that goes past the end of the string may be a bug worth
> fixing, but is this patch sufficient to diagnose such an input as an
> error?
Yea, the patch should fix the passing end of string too. The parser
was going past end of string because the nextat
On 3/7/13, Junio C Hamano wrote:
> This did not error out for me, though.
>
> $ cd t && git ls-files ":(top"
No error message at all? Hm, maybe in your case, the byte after the
end of string happens to be '\0' and the loop ended by chance?
git doesn't crash for me, but it generates this erro
On 03/07/13 20:51, Junio C Hamano wrote:
> But it is equally broken to behave as if there is nothing wrong in
> the incomplete magic ":(top" that is not closed, isn't it?
Ah, yea, I did notice that, but then I saw a few lines below:
if (*copyfrom == ')')
copyfrom++;
which is exp
,
I've pushed this with a minor formatting change (added space after
"W:") will push another change for formatting existing warnings more
consistently.
Signed-off-by: Eric Wong
--
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
Eric Wong wrote:
> will push another change for formatting existing warnings more
> consistently.
Just pushed. My master is sitting at git://git.bogomips.org/git-svn.git
commit eae6cf5aa8ae2d8a90a99bbe4aeb01c29e01fd02
Eric Wong (1):
git svn: consistent spacing after &
On 3/8/13, Max Horn wrote:
> All in all, I suspect that Mac OS X and/or the filesystem (HFS+ with
> journaling, not case sensitive (the default)) might be at fault. Still, this
> is quite puzzling and annoying, and so I still wonder if anybody has any
> insights on this.
When "rebase" errors out
On 3/8/13, Max Horn wrote:
> I tried this a dozen times, but 'git apply' failed to fail even once. No
> surprise there, given that the patch that throws off rebase every time is
> clean and simple. I am flabbergasted :-(
Hm, what if you add in the "--index" flag? i.e.
git apply --index .git/r
On 3/8/13, Max Horn wrote:
> Same result, it works fine.
Just shooting in the dark here... I wonder if there's some background
process running in OS X that's messing with the files/directories
while rebase is working... backup, virus scan, etc? Or maybe some
programs that you're using at the same
On 03/09/13 06:26, Max Horn wrote:
> It tends to fail in separate places, but eventually "stabilizes". E.g. I just
> did a couple test rebases, and it failed twice in commit 14, then the third
> time in commit 15 (which underlines once more that the failures are
> inappropriate).
>
> The fourth
On 03/09/13 13:32, Andrew Wong wrote:
> Yea, that's really suspicious. This could mean there's an issue with
> when git is checking the index. Try running these a couple times in a
> clean work tree:
> $ git update-index --refresh
> $ git diff-files
>
> In a
The previous code was assuming length ends at either ")" or ",", and was
not handling the case where strcspn returns length due to end of string.
So specifying ":(top" as pathspec will cause the loop to go pass the end
of string.
Signed-off-by: Andrew Wong
---
setu
The previous code allowed the ")" to be optional.
Signed-off-by: Andrew Wong
---
setup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/setup.c b/setup.c
index f4c4e73..5ed2b93 100644
--- a/setup.c
+++ b/setup.c
@@ -225,8 +225,9 @@ static const char *prefi
On 3/10/13, Max Horn wrote:
> I did run
>
> touch lib/*.* src/*.* && git update-index --refresh && git diff-files
>
> a couple dozen times (the "problematic" files where in src/ and lib), but
> nothing happened. I just re-checked, and the rebase still fails in the same
> why...
>
> Perhaps I sho
On 3/11/13, Max Horn wrote:
> So I tried this:
>
> git rebase branches/stable-4.6 # ... which leads to the error
> git ls-files -m
>
> but got nothing. Perhaps you had something else in mind, though, but I am
> not quite sure what... sorry for being dense, but if you let me know what
> exactl
On 3/11/13, Max Horn wrote:
> PS: Just as a side note, I should mention that I have done tons of rebases
> on various repositories on this very machine: same hard drive, same file
> system; the git version of course has changed over time, but as I already
> described, I can reproduce the same issu
On 3/11/13, Max Horn wrote:
> Looking at the git config man page to check what each of my config settings
> does, I discovered "trustctime". And adding
> trustctime = false
> to .git/config made the rebase work, every single time. Huh.
>
>
> Adding this to the fact that a clone works fine, I
On 03/11/13 20:29, Max Horn wrote:
> sudo launchctl unload /System/Library/LaunchDaemons/com.apple.revisiond.plist
>
> -> this exits revisiond, and prevents launchd from respawning it. After that,
> the problem is gone, on several attempts. And once I reactivate revisions,
> the problem reoccurs.
On 03/11/13 21:01, Jeff King wrote:
> From "git help config":
>
> core.trustctime
> If false, the ctime differences between the index and the working
> tree are ignored; useful when the inode change time is regularly
> modified by something outside Git (file system crawlers and some
>
Adam Retter wrote:
> Our public SourceForge Subversion repository is here:
> http://svn.code.sf.net/p/exist/code/trunk/eXist
It's asking me for a username/password...
> We cloned that to the local server using rsync and are attempting to
> migrate to git using the following commands:
>
> $ git
Adam Retter wrote:
> If your able, any idea of when you might be able to take a look at the
> bug? Our svn repo is publicly available for all.
svn ls https://svn.code.sf.net/p/exist/code/trunk
...Is asking me for username
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
On 3/19/13, Ramkumar Ramachandra wrote:
> I know that this is expected behavior, but is there an easy way to get
> rid of this inconsistency?
You can actually rely on "rebase" to run the appropriate command. In
the first edit commit (the_
no conflict one), I usually run only "git add" to add my c
Junio C Hamano wrote:
> For reference, here is the CoC the patch wants to add (there is no
> such topic yet locally, nor a single patch that can be made into
> such a topic, so there isn't exactly something people can Ack on
> yet. So here is a "preview" of what we would see once such a series
Jonathan Nieder wrote:
> Eric Wong wrote:
> > Konstantin Ryabitsev wrote:
>
> >> This is actually really fast if you already have a local copy of the
> >> repository with most objects. Try this yourself if you have
> >> torvalds/linux.git locally:
Johannes Schindelin wrote:
> On Fri, 11 Oct 2019, Junio C Hamano wrote:
> > * ds/sparse-cone (2019-10-08) 17 commits
> > - sparse-checkout: cone mode should not interact with .gitignore
> > - sparse-checkout: write using lockfile
> > - sparse-checkout: update working directory in-process
> > -
Junio C Hamano wrote:
> Eric Wong writes:
>
> > I just took a brief look, but that appears to leak memory.
> >
> > "hashmap_free(var, 1)" should be replaced with
> > "hashmap_free_entries(var, struct foo, member)"
> >
> > Onl
ld.
I'm also still learning my way around git's C internals, but
using patch.{old,new}_oid_prefix seems alright...
FIXME: tests, t3206 needs updating
Not-signed-off-by: Eric Wong
---
range-diff.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/ran
ers brought up around exactness
and working on top of cherry-picks.
> PS: Eric Wong described something that comes quite close to this idea, but
> AFAICT without actually recreating commits exactly. I've included the link
> for completeness. [4]
> [4]: https://lore.kernel.org/work
Vegard Nossum wrote:
> I sent v2 of the patches (with metadata _after_ the diff) to the git
> list here:
>
> https://public-inbox.org/git/20191022114518.32055-1-vegard.nos...@oracle.com/T/#u
>
> As I wrote in there, we could already today start using
>
>git am --message-id
>
> when applyin
Johannes Schindelin wrote:
> Hi Eric,
>
>
> On Thu, 17 Oct 2019, Eric Wong wrote:
>
> > (WIP, mostly stream-of-concious notes + reasoning)
> >
> > When using "git format-patch --range-diff", the pre and
> > post-image blob OIDs are in each
Eric Wong wrote:
> Johannes Schindelin wrote:
> > I guess your patch won't hurt.
>
> Cool, will update tests and resend.
Turns out the t3206 "trivial reordering" case is way too noisy.
I might need to change diff.c to support this case; will update
in a few days or week.
Tervehdys ja kohteliaisuuksia.
Olen Peter Wong Työskentelen BANK OF CHINA Minulla Business ehdotus
vireessä US $ 22.500.000 Million siirretään offshore tilin apua, jos
haluaa.
Jos kiinnostaa minä lähetän teille täyden tapahtuman tiedot saatuaan
vastaustasi. Voit ottaa yhteyttä minuun minun
--
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
901 - 955 of 955 matches
Mail list logo
