On Wed, May 1, 2013 at 12:44 AM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> After being contacted by the emacs developers and others who are stuck with
>> Bazaar, which at this point seems to be utterly abandoned, I realized the
>> current implementation is too crude.
>> ...
>> That is
Felipe Contreras writes:
> After being contacted by the emacs developers and others who are stuck with
> Bazaar, which at this point seems to be utterly abandoned, I realized the
> current implementation is too crude.
> ...
> That is of course, if pushing actually worked (which in many cases does
IB> + return undef if (!keys $self->{_save_ph});
Correct is: return undef if (!keys %{$self->{_save_ph}});
In my repo the placeholders change too often (in 1/4 commits). I'm
thinking of using:
'git config --unset "svn-remote.$repo_id.added-placeholder" path_regex'
instead of full rewrite.
-
On Tue, Apr 30, 2013 at 1:38 PM, Ilya Basin wrote:
> - When creating a tag or branch from a subdir, a disjoint branch is
> created. Then git-svn re-imports the commits using this dir as strip
> path.
>
> During this re-import the variable %added_placeholder is not up to
> date. B
On Tue, Apr 30, 2013 at 11:01 PM, Nguyễn Thái Ngọc Duy
wrote:
> The current behavior is inconsistent when passing SHA-1 to get_sha1.
> If it's a short sha-1, refs take precedence. "git rev-parse 1234" will
> resolve refs/heads/1234 if exists even if there is an unambiguous
> SHA-1 starting with 12
The current behavior is inconsistent when passing SHA-1 to get_sha1.
If it's a short sha-1, refs take precedence. "git rev-parse 1234" will
resolve refs/heads/1234 if exists even if there is an unambiguous
SHA-1 starting with 1234. However if it's full SHA-1, the SHA-1 takes
precedence and refs wit
On Wed, May 1, 2013 at 12:15 AM, Ramkumar Ramachandra
wrote:
> Duy Nguyen wrote:
>> We could put still ref aliases
>> into the same ref namespace, with lower precedence that actual refs,
>> so no new syntax required.
>
> Actually, ref-alises are the right way to solve the problem.
> Recursive symr
On Wed, May 1, 2013 at 4:49 AM, Felipe Contreras
wrote:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
> can't remove '{0}'?
>
> This patch allows '@' to be the same as 'HEAD'.
>
> So now we can u
On Mon, Apr 29, 2013 at 4:01 PM, Junio C Hamano wrote:
> * fc/transport-helper-error-reporting (2013-04-25) 10 commits
> (merged to 'next' on 2013-04-25 at 3358f1a)
> + t5801: "VAR=VAL shell_func args" is forbidden
> (merged to 'next' on 2013-04-22 at 5ba6467)
> + transport-helper: update r
Bazaar doesn't seem to be tested for multiple usage of branches, so
resources seem to be leaked all over. Let's try to minimize this by
accessing the Branch objects only when needed.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 28
1 fi
This way we don't need to store the list of all the revisions, which
doesn't seem to be very memory efficient with bazaar's design, for
whatever reason.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --gi
So it doesn't time out.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index 66e3861..b2d67f7 100755
--- a/contrib/r
No need to manually count the revisions, and also, this would help to
iterate more properly.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
We might not want all the branches. And branch handling in bazaar is
rather tricky, so it's safer to simply specify them.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/contrib/re
The official method is incredibly inefficient and slow.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-rem
So that we don't end up with '', and also synchronize it with the
one from remote-hg.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/re
This way all the remotes share the same data, so adding multiple
remotes, or renaming them doesn't create extra overhead.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/contrib/
When branches have '/' in their name (aka. sub-branches), bazaar seems
to choke while creating the new directory.
Also, git cannot have both 'foo' and 'foo/bar'.
So let's replace slashes with a plus sign.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 1 +
1 file c
In bazaar, a repository can contain multiple branches, and previously we
were supporting only one branch at a time. Now we fetch them all.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 158 ++
contrib/remote-helpers/test-bzr.sh|
There should be no functional changes. Basically we want to reserve the
'repo' variable.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 35 ++-
1 file changed, 18 insertions(+), 17 deletions(-)
diff --git a/contrib/remote-helpers/git-
If part of the merge was already pushed, we don't have the blob_marks
available, however, the commits are already stored in bazaar, so we can
use the revision_tree to fetch the contents.
We want to do this only when there's no other option.
There's no easy way to test this.
Signed-off-by: Felipe
If the branches diverge we want to reset the pointer to where the remote
actually is. Since we can access remote branches just as easily as local
ones, let's do so.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 8 +++-
1 file changed, 7 insertions(+), 1 deletion
And fail properly when we can't.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index b428244..eb91d28 100755
--- a/c
In order to do that, we need to store the marks of every file, so that
they can be fetched when needed. Unfortunately we can't tell bazaar that
nothing changed, we need to send the data so that it can figure it out
by itself.
And since it will be requesting a bunch of information by the file_id,
i
It doesn't seem to make any difference, but revision_tree() requires a
lock.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bz
Might be more efficient, but the real reason to use the marks will be
revealed in upcoming patches.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contr
This code was not used at all.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
index c19ed0e..7452a57 100755
--- a/c
Hi,
This is the same as last series, except that I dropped a couple of conflicting
patches, and added one test.
After being contacted by the emacs developers and others who are stuck with
Bazaar, which at this point seems to be utterly abandoned, I realized the
current implementation is too crud
Felipe Contreras writes:
> On Tue, Apr 30, 2013 at 6:00 PM, Felipe Contreras
> wrote:
>
>> +static int interpret_empty_at(const char *name, int namelen, int len,
>> struct strbuf *buf)
>> +{
>> + if (namelen - len < 1 || name[len + 1] == '{')
>> + return -1;
>> +
>> + s
On Tue, Apr 30, 2013 at 6:00 PM, Felipe Contreras
wrote:
> +static int interpret_empty_at(const char *name, int namelen, int len,
> struct strbuf *buf)
> +{
> + if (namelen - len < 1 || name[len + 1] == '{')
> + return -1;
> +
> + strbuf_reset(buf);
> + if (len ==
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> Yoda speaks in reverse "Stopped they must be; on this all depends".
>> "if (0 < len)" says "if zero is less than len", which is in reverse,
>> as reverse as "if 1.50 is taller than you". It's all reversed: "if you
>> are taller than 1.50", "
Felipe Contreras writes:
> Yoda speaks in reverse "Stopped they must be; on this all depends".
> "if (0 < len)" says "if zero is less than len", which is in reverse,
> as reverse as "if 1.50 is taller than you". It's all reversed: "if you
> are taller than 1.50", "if len is greater than zero", "T
On Tue, Apr 30, 2013 at 5:53 PM, Felipe Contreras
wrote:
> On Tue, Apr 30, 2013 at 5:42 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Since 'update-ref master' updates the 'master' ref, and not
>>> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense
>>> that @{-1}
On Tue, Apr 30, 2013 at 5:42 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> Since 'update-ref master' updates the 'master' ref, and not
>> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense
>> that @{-1} is not parsed, and neither is @.
>
> That is a very valid point.
Am 30.04.2013 02:11, schrieb Stephen Boyd:
> (resending since the attachment seems to make vger sad)
>
> Hi,
>
> I'm running git rev-list | git cherry-pick --stdin on a range of about
> 300 commits. Eventually the chery-pick dies with:
>
> error: cannot fork() for commit: Cannot allocate me
On Tue, Apr 30, 2013 at 5:30 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, Apr 30, 2013 at 5:13 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
On Tue, Apr 30, 2013 at 5:00 PM, Junio C Hamano wrote:
> What is a Yoda condition?
---
Using if
Felipe Contreras writes:
> Since 'update-ref master' updates the 'master' ref, and not
> 'refs/heads/master' (IOW; no parsing at all), I think it makes sense
> that @{-1} is not parsed, and neither is @.
That is a very valid point.
What should "rev-parse --symbolic-full-name @" say?
--
To unsub
Thomas Rast writes:
> Duy Nguyen writes:
>
>> Apply this patch on top of master (no need to apply full series) and run
>> t5303
>>
>> http://article.gmane.org/gmane.comp.version-control.git/222895
> [...]
>> OK since you know this code much better than me, I withdraw my patch
>> (consider it a
On Tue, Apr 30, 2013 at 5:27 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>>> That means "git checout @" should work the same way as "git checkout
>>> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
>>> "git update-ref @ $(git rev-parse master)" should update the HEAD
Junio C Hamano writes:
> Felipe Contreras writes:
>
>> On Tue, Apr 30, 2013 at 5:13 PM, Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>>
On Tue, Apr 30, 2013 at 5:00 PM, Junio C Hamano wrote:
> What is a Yoda condition?
---
Using if (constant == variable) instead
Felipe Contreras writes:
> On Tue, Apr 30, 2013 at 5:13 PM, Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> On Tue, Apr 30, 2013 at 5:00 PM, Junio C Hamano wrote:
What is a Yoda condition?
>>>
>>> ---
>>> Using if (constant == variable) instead of if (variable == constant),
>>> l
Felipe Contreras writes:
>> That means "git checout @" should work the same way as "git checkout
>> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
>> "git update-ref @ $(git rev-parse master)" should update the HEAD
>> without creating $GIT_DIR/@, etc.
>>
>> You can't go any si
Felipe Contreras writes:
> Signed-off-by: Felipe Contreras
> ---
> sha1_name.c| 21 +
> t/t1508-at-combinations.sh | 2 +-
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/sha1_name.c b/sha1_name.c
> index 887de6c..8f65bad 100644
> --- a/s
On Tue, Apr 30, 2013 at 5:13 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Tue, Apr 30, 2013 at 5:00 PM, Junio C Hamano wrote:
>>> What is a Yoda condition?
>>
>> ---
>> Using if (constant == variable) instead of if (variable == constant),
>> like if (4 == foo).
>>
>> Because it's
On Tue, Apr 30, 2013 at 2:42 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Duy Nguyen writes:
>>
>>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>>> wrote:
So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
use 'git show @~1', and all that goody goo
Felipe Contreras writes:
> On Tue, Apr 30, 2013 at 5:00 PM, Junio C Hamano wrote:
>> What is a Yoda condition?
>
> ---
> Using if (constant == variable) instead of if (variable == constant),
> like if (4 == foo).
>
> Because it's like saying "if blue is the sky" or "if tall is the man".
That is
On Tue, Apr 30, 2013 at 1:45 PM, Ramkumar Ramachandra
wrote:
> Felipe Contreras wrote:
>> It's not. The same way master^0^0~4 is not useful, yet it's works;
>> it's a logical result from the syntax.
>
> It's logical if you explain @ as a shortcut for @{0}, and make
> @{0}@{1} resolve somehow [*1*]
Felipe Contreras writes:
> So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
> remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
> can't remove '{0}'?
>
> This patch allows '@' to be the same as 'HEAD'.
>
> So now we can use 'git show @~1', and all tha
On Tue, Apr 30, 2013 at 5:00 PM, Junio C Hamano wrote:
> What is a Yoda condition?
---
Using if (constant == variable) instead of if (variable == constant),
like if (4 == foo).
Because it's like saying "if blue is the sky" or "if tall is the man".
---
--
Felipe Contreras
--
To unsubscribe from
Felipe Contreras writes:
> This code essentially replaces part of ref with another ref, for example
> '@{-1}@{u}' is replaced with 'master@{u}', but this can be reused for
> other purposes other than nth prior checkouts.
>
> Signed-off-by: Felipe Contreras
> ---
Makes sense.
> sha1_name.c |
What is a Yoda condition?
--
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
On Tue, Apr 30, 2013 at 1:22 PM, Ramkumar Ramachandra
wrote:
> Junio C Hamano wrote:
>> @{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}
>> is.
>
> Right. I missed that.
>
>> '"@" given alone' has to be a ref if we want @@{5.minutes.ago} to
>> resolve.
>
> Yeah, I just real
So HEAD@{0}~0^0 is too much to type, but we can remove '^0', and we can
remove '~0', and we can remove 'HEAD', which leaves us with @{0}, but we
can't remove '{0}'?
This patch allows '@' to be the same as 'HEAD'.
So now we can use 'git show @~1', and all that goody goodness.
Until now '@' was a
Signed-off-by: Felipe Contreras
---
sha1_name.c| 21 +
t/t1508-at-combinations.sh | 2 +-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/sha1_name.c b/sha1_name.c
index 887de6c..8f65bad 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -969,6 +969,
This code essentially replaces part of ref with another ref, for example
'@{-1}@{u}' is replaced with 'master@{u}', but this can be reused for
other purposes other than nth prior checkouts.
Signed-off-by: Felipe Contreras
---
sha1_name.c | 42 +++---
1 file ch
Signed-off-by: Felipe Contreras
---
sha1_name.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 01e49a9..6530ddd 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -465,12 +465,11 @@ static int get_sha1_basic(const char *str, int len,
unsigned
Signed-off-by: Felipe Contreras
---
sha1_name.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 6530ddd..93c4e8c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -996,9 +996,9 @@ int interpret_branch_name(const char *name, struct strbuf
*buf)
'at' is always 0, since we can reach this point only if
!len && reflog_len, and len=at when reflog is assigned.
Signed-off-by: Felipe Contreras
---
sha1_name.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_name.c b/sha1_name.c
index 3820f28..01e49a9 100644
--- a/sha1_n
Hi,
Same as before, except that now only '@' changes, 'master@' remains the same as
before.
Also, cleanups for sha1_name, and an update so '@@{u}' works.
Felipe Contreras (6):
sha1_name: remove no-op
sha1_name: remove unnecessary braces
sha1_name: avoid Yoda conditions
sha1_name: refacto
Kevin Bracey writes:
> Okay, here's what I'll call v2 of this series. In the 3 parts from
> before (4,6 & 7), I've addressed the comments from Junio and David,
> corrected some errors, reconstructed the main commit message, and made
> some adjustments in preparation for part 8.
Overally, very ni
Kevin Bracey writes:
> The simplification and rewriting logic previously paid little heed to
> whether parents were UNINTERESTING, leading to situations where limited
> histories could unnecessarily include a lot of irrelevant merges along
> the boundary. Tighten up the rules to properly account
On Tue, Apr 30, 2013 at 1:29 PM, Jeff King wrote:
> On Tue, Apr 30, 2013 at 01:17:03PM -0700, Junio C Hamano wrote:
>
>> Jerry Qassar writes:
>>
>> > Curl already does support engine-based certificates (in code and
>> > help). Its problem is that a) it doesn't yet read your engine
>> > defs out
Kevin Bracey writes:
> @@ -342,13 +342,13 @@ In the following, we will always refer to the same
> example history to
> illustrate the differences between simplification settings. We assume
> that you are filtering for a file `foo` in this commit graph:
> -
John Tapsell writes:
> On 30 April 2013 20:44, Junio C Hamano wrote:
>> John Tapsell writes:
>>
>>> Is there no way to fix --cc to work even in the edge cases?
>>
>> Can you clarify what you mean by "fix" and "edge cases"?
>
> My understanding is that even with -cc there will be changes that
>
Junio C Hamano wrote:
> Ramkumar Ramachandra writes:
>
>> In other words: the sequence "@" is short for "HEAD".
>
> That is saying a very different thing. master@{4.days} is not short
> for masterHEAD{4.days}.
I meant after ^, ~, @{} have been peeled off. Just before resolving
what's left.
> A
On Tue, Apr 30, 2013 at 01:17:03PM -0700, Junio C Hamano wrote:
> Jerry Qassar writes:
>
> > Curl already does support engine-based certificates (in code and
> > help). Its problem is that a) it doesn't yet read your engine
> > defs out of OpenSSL config, and b) a bug in copying the engine
> >
On Tue, Apr 30, 2013 at 01:04:17PM -0700, Jerry Qassar wrote:
> First, thanks very much for taking a look at this. I wasn't 100% certain
> about
> the versioning to use for it (specifically the version-to-0x mapping), so any
> input on that would be a big help. I'll try to answer your questions
Jerry Qassar writes:
> Curl already does support engine-based certificates (in code and
> help). Its problem is that a) it doesn't yet read your engine
> defs out of OpenSSL config, and b) a bug in copying the engine
> data, once that's patched, to the handle that calling apps use.
So once the
On 30 April 2013 20:44, Junio C Hamano wrote:
> John Tapsell writes:
>
>> Is there no way to fix --cc to work even in the edge cases?
>
> Can you clarify what you mean by "fix" and "edge cases"?
My understanding is that even with -cc there will be changes that
won't be seen - and hence why --cc
>> }
>>
>> @@ -458,9 +459,12 @@ sub find_empty_directories {
>> my $skip_added = 0;
>> foreach my $t (qw/dir_prop file_prop/) {
>> foreach my $path (keys %{ $self->{$t} }) {
>> - if (exists $self->{$t}->{dirname($path)
Ramkumar Ramachandra writes:
> In other words: the sequence "@" is short for "HEAD".
That is saying a very different thing. master@{4.days} is not short
for masterHEAD{4.days}.
> Isn't that
> _exactly_ what I implemented in my two-liner?
I dunno.
As design and semantics look still fuzzy (t
On Tue, Apr 30, 2013 at 11:27 AM, Jeff King wrote:
> On Tue, Apr 30, 2013 at 09:45:44AM -0700, Junio C Hamano wrote:
>
>> The authoritative source
>>
>> https://github.com/bagder/curl/blob/master/docs/libcurl/symbols-in-versions
>>
>> tells me that the CURLOPT_* used in this patch are available si
Junio C Hamano writes:
> The rule would be "You should be able to say '@' where-ever you
> currently say HEAD" (aka '@' is a short-hand for 'HEAD').
>
> That means "git checout @" should work the same way as "git checkout
> HEAD", "git log @~4" would work the same way as "git log HEAD~4",
> "git
In preparation for upcoming TREESAME work, check the result for G.t,
which is dropped in "-s ours" merge L. The default rev-list is empty, as
expected - it follows the first parent path where it never existed.
Unfortunately, --ancestry-path is also empty. Merges H J and L are all
TREESAME to 1 par
Junio C Hamano wrote:
> [...]
> You can't go any simpler than that rule, and there is no room for
> confusion if that rule is properly implemented.
In other words: the sequence "@" is short for "HEAD". Isn't that
_exactly_ what I implemented in my two-liner?
However, I'm tilting towards respecti
John Tapsell writes:
> Is there no way to fix --cc to work even in the edge cases?
Can you clarify what you mean by "fix" and "edge cases"?
--
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.
Junio C Hamano writes:
> Duy Nguyen writes:
>
>> On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
>> wrote:
>>> So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
>>> use 'git show @~1', and all that goody goodness.
>>
>> I like this. I haven't spent a lot of time on thinki
On 30 April 2013 18:58, John Szakmeister wrote:
> On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy
> wrote:
>> Junio C Hamano writes:
>>
>>> By the way, these options are _not_ about "showing merge commits
>>> that introduce code", and they do not help your kind of "security".
>>> As I repeatedly s
Show what would be done and the user must confirm before actually
cleaning. In the confirmation dialog, the user has three choices:
* Yes: Start to do cleaning.
* No: Nothing will be deleted.
* Edit (default): Enter edit mode.
When the user chooses the edit mode, the user can input space-
sep
Ilya Basin writes:
[PATCH 1/5] git-svn: fix occasional "Failed to strip path" error on fetch
next commit, try #3
Please make it like this.
[PATCH v3 1/5] git-svn: fix occasional "Failed to strip path" error on
fetch next commit
> When --stdlayout and --preserve-empty-dirs flags a
Ramkumar Ramachandra wrote:
> I'm not
> _exactly_ creating a synonym for HEAD: @{u} works, not @@{u}.
Turns out this is actually a parsing-bug in @{u}. @@{5.minutes.ago}
and @@{5} work just fine.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord.
On Tue, Apr 30, 2013 at 12:40 PM, Ramkumar Ramachandra
wrote:
> Junio C Hamano wrote:
>> If you accept only "@" but not "master@", that behaviour needs a
>> wrong world model to understand and justify (one of which is "@ is a
>> synonym for HEAD"). If your rule is "In $anything@{$n}, you can
>> d
Ramkumar Ramachandra wrote:
> So, without the .git/@, @@{1} will complain that
> the reflog only has 1 entry (in other words, it is "correct" but not
> useful).
Even better idea. When not overridden, @@{} will show the reflog
for HEAD. To the user, it looks like @ is behaving like a true ref by
Felipe Contreras wrote:
> It's not. The same way master^0^0~4 is not useful, yet it's works;
> it's a logical result from the syntax.
It's logical if you explain @ as a shortcut for @{0}, and make
@{0}@{1} resolve somehow [*1*].
[Footnotes]
*1*: The best I can do is @{0} is like a ref (while @{>
The simplification and rewriting logic previously paid little heed to
whether parents were UNINTERESTING, leading to situations where limited
histories could unnecessarily include a lot of irrelevant merges along
the boundary. Tighten up the rules to properly account for limited
lists:
1) If a mer
Ramkumar Ramachandra wrote:
> Therefore, @@{5.minutes.ago} should work with my implementation too.
Caveat: we won't keep reflogs for @ unless the manual override .git/@
is present (what's the point of keeping a duplicate of .git/logs/HEAD
in .git/logs/@?). So, without the .git/@, @@{1} will compl
Stephen Boyd writes:
> (resending since the attachment seems to make vger sad)
>
> Hi,
>
> I'm running git rev-list | git cherry-pick --stdin on a range of about
> 300 commits. Eventually the chery-pick dies with:
>
> error: cannot fork() for commit: Cannot allocate memory
Unfortunately, I a
On Tue, Apr 30, 2013 at 09:45:44AM -0700, Junio C Hamano wrote:
> The authoritative source
>
> https://github.com/bagder/curl/blob/master/docs/libcurl/symbols-in-versions
>
> tells me that the CURLOPT_* used in this patch are available since
> cURL 7.9.3, but I see a #if LIBCURL_VERSION_NUM < 0x
Ramkumar Ramachandra wrote:
> @@{5.minutes.ago} and @@{1} work perfectly fine on git.git master.
(with the .git/@ symref obviously)
--
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
Junio C Hamano wrote:
> @{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}
> is.
Right. I missed that.
> '"@" given alone' has to be a ref if we want @@{5.minutes.ago} to
> resolve.
Yeah, I just realized that it's a bug in the @{u} implementation.
@@{5.minutes.ago} and @@{1
On Tue, Apr 30, 2013 at 12:56 PM, Jeff King wrote:
> On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:
>
>> > We should make sure that the code rejects "git update-ref @ foo"
>> > because that is "git update-ref @{0} ref", by the way. I didn't
>> > check with Felipe's patch.
>>
>>
On Tue, Apr 30, 2013 at 12:54 PM, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
>> Junio C Hamano wrote:
>>> Felipe Contreras writes:
>>
Never-mind, now I see the difference, still, I don't think it's
relevant for this patch.
>>>
>>> I don't either. With the precedence of @{u}, @ d
Ramkumar Ramachandra writes:
> Felipe Contreras wrote:
>> Why would HEAD^0^0~4 work? Because the syntax is recursive.
>
> That's because you can compose with ^ and ^, while you can't with @
> and @. Does @{0}@{0} resolve?
@{-1}@{0} does. That means @{0} is a revision and not a ref, but @{-1}
i
Junio C Hamano wrote:
> How else would you explain why "rev-parse --symbolic-full-name @"
> does not make sense
It does make sense. (Try it with my patch) [*1*]
> and "update-ref @" does not update HEAD?
Why should update-ref update HEAD? I'm asking it to update the
symbolic-ref override .git/
On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy
wrote:
> Junio C Hamano writes:
>
>> By the way, these options are _not_ about "showing merge commits
>> that introduce code", and they do not help your kind of "security".
>> As I repeatedly said, you would need "-p -m" for that.
>
> Actually, while
On Tue, Apr 30, 2013 at 12:47:57PM -0500, Felipe Contreras wrote:
> > We should make sure that the code rejects "git update-ref @ foo"
> > because that is "git update-ref @{0} ref", by the way. I didn't
> > check with Felipe's patch.
>
> Hmm, with or without my patch 'git update @ foo' does noth
Ramkumar Ramachandra writes:
> Junio C Hamano wrote:
>> If you accept only "@" but not "master@", that behaviour needs a
>> wrong world model to understand and justify (one of which is "@ is a
>> synonym for HEAD"). If your rule is "In $anything@{$n}, you can
>> drop {$n} when $n==0", then HEAD@
Jonathan Nieder writes:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>
>>> Never-mind, now I see the difference, still, I don't think it's
>>> relevant for this patch.
>>
>> I don't either. With the precedence of @{u}, @ does not need to have
>> anything to do with a reflog. It is just a
- When creating a tag or branch from a subdir, a disjoint branch is
created. Then git-svn re-imports the commits using this dir as strip
path.
During this re-import the variable %added_placeholder is not up to
date. Because the branch is disjoint, this variable should be empty
.git/config is written on each commit. It's slow
---
perl/Git/SVN/Fetcher.pm | 77 +++--
1 file changed, 49 insertions(+), 28 deletions(-)
diff --git a/perl/Git/SVN/Fetcher.pm b/perl/Git/SVN/Fetcher.pm
index e658889..a5ad4cd 100644
--- a/perl/Git/SVN/Fe
1 - 100 of 155 matches
Mail list logo
