On Mon, Apr 29, 2013 at 11:42 PM, Nguyễn Thái Ngọc Duy
pclo...@gmail.com wrote:
diff --git a/cache.h b/cache.h
index 94ca1ac..bed403a 100644
--- a/cache.h
+++ b/cache.h
@@ -744,12 +744,33 @@ char *strip_path_suffix(const char *path, const char
*suffix);
int daemon_avoid_alias(const char
On Mon, Apr 29, 2013 at 11:42 PM, Nguyễn Thái Ngọc Duy
pclo...@gmail.com wrote:
A submodule's object database may be imported to in-core object pool
for a quick peek without paying the price of running a separate git
command. These databases are marked in for stricter checks later to
s/marked
On Mon, Apr 29, 2013 at 11:42 PM, Nguyễn Thái Ngọc Duy
pclo...@gmail.com wrote:
This patch separates submodule odb sources from ordinary alternate
sources. The new sources can be accessed with ODB_EXTALT (e.g. via
read_sha1_file_extended).
ODB_EXTALT is only added to odb_default in certain
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com 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', but we can't remove '{0}'?
This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly
On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com 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
On Tue, Apr 30, 2013 at 1:07 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com 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', but we can't remove '{0}'?
On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
So we can type '@' instead of 'HEAD@', or rather 'HEAD'.
On Tue, Apr 30, 2013 at 1:17 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Apr 30, 2013 at 12:54 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
'master@'.
I'm a bit reluctant to this. It looks like incomplete syntax to me as
'@' has always been followed by '{'. Can we have the
On 04/30/2013 07:54 AM, Duy Nguyen wrote:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com 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
Michael Haggerty wrote:
git symbolic-ref -m Create @ alias for HEAD @ HEAD
I find this very interesting. I already have a symbolic ref H
pointing to HEAD, but it has some quirks: H@{u} complains that H is an
invalid branch for example. When I create the symbolic-ref @, I'm not
_exactly_
On Tue, Apr 30, 2013 at 1:30 AM, Duy Nguyen pclo...@gmail.com wrote:
On Tue, Apr 30, 2013 at 1:10 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This patch allows 'HEAD@' to be the same as 'HEAD@{0}', and similarly with
'master@'.
I'm a bit reluctant to this. It looks like incomplete
On Mon, Apr 29, 2013 at 03:22:24PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
No, I was the one missing something (--root to be precise). But with
TEST_OUTPUT_DIRECTORY you also get the result files in your temporary
location, not just the trash directory.
With
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
In this particular code path, we add base to the delta base
cache. Then decide to free it, but we forgot about a dangling pointer
in the cache. Invalidate that entry when we free base.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The idea behind this series is, after add_submodule_odb, odb may have
new temporary objects that only appear after the call. These temporary
objects may lead to repo corruption (e.g. some new objects are created
and point to these temporary
On Sun, Apr 21, 2013 at 2:42 PM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
The thing is, I'm not convinced this is a bad default. Shows no diff
at all for merges is easy for a person to understand. It is much
easier to understand its limitations than
On Tue, Apr 30, 2013 at 2:09 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
According to git-check-ref-format(1), an @ character is currently
legal in a reference name as long as it is not followed by {. As an
example, git-svn uses @ in reference names (e.g.,
On Tue, Apr 30, 2013 at 2:35 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Michael Haggerty wrote:
git symbolic-ref -m Create @ alias for HEAD @ HEAD
I find this very interesting. I already have a symbolic ref H
pointing to HEAD, but it has some quirks: H@{u} complains that H is an
On Tue, Apr 30, 2013 at 3:27 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
In this particular code path, we add base to the delta base
cache. Then decide to free it, but we forgot about a dangling pointer
in the cache. Invalidate that entry when we
On Tue, Apr 30, 2013 at 3:43 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
The idea behind this series is, after add_submodule_odb, odb may have
new temporary objects that only appear after the call. These temporary
objects may lead to repo corruption
Duy Nguyen wrote:
Habits aside, why do you do H@{u} when @{u} is enough (and shorter)?
I don't. In the @{} spec, HEAD is implicit. My initial itch was that
HEAD is not implicit in the ~n spec, and started off by thinking how
we could make HEAD implicit specifically for that case [1]. Since
On Monday, April 29, 2013, 20:20, John Keeping, j...@keeping.me.uk wrote:
On Mon, Apr 29, 2013 at 07:34:27PM +0200, Steffen Jaeckel wrote:
snip
sjaeckel@T7400-003 /h/projects/my_project (develop)
$ GIT_TRACE=2 git subtree push --prefix=lib/com_lib/ git@git.local:com_lib
develop -b
Sorta OT, but I'm curious,
On Sun, Apr 21, 2013 at 12:09 PM, Jonathan Nieder jrnie...@gmail.com wrote:
For example, whenever git adds (or plans) support for a new header
line in commit objects, before you've upgraded, a prankster can
provide a bad value for that header line in objects they
Apparently GMail for Android only sends HTML encoded emails (and the
list rightly rejected it).
On Mon, Apr 29, 2013 at 4:31 PM, shawn wilson ag4ve...@gmail.com wrote:
On Apr 29, 2013 12:42 PM, Junio C Hamano gits...@pobox.com wrote:
shawn wilson ag4ve...@gmail.com writes:
How do I
The rev spec forms @{}, .., ... fill in HEAD as the missing argument
automatically. Unfortunately, HEAD~n is a very common idiom and
there is no way to make HEAD implicit here (due the shell expansion of
~n).
However, there is an alternative solution to the issue: overload the
character @ to
On Tue, Apr 30, 2013 at 7:24 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
The rev spec forms @{}, .., ... fill in HEAD as the missing argument
automatically. Unfortunately, HEAD~n is a very common idiom and
there is no way to make HEAD implicit here (due the shell expansion of
~n).
Duy Nguyen pclo...@gmail.com 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 bug report) and let you
Ramkumar Ramachandra artag...@gmail.com writes:
The rev spec forms @{}, .., ... fill in HEAD as the missing argument
automatically. Unfortunately, HEAD~n is a very common idiom and
there is no way to make HEAD implicit here (due the shell expansion of
~n).
However, there is an alternative
On Tue, Apr 30, 2013 at 7:53 PM, Thomas Rast tr...@inf.ethz.ch wrote:
Duy Nguyen pclo...@gmail.com 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
Thomas Rast wrote:
But then why don't you just 'git symbolic-ref H HEAD' for a sort of
local alias?
Yes, I already have @ pointing to HEAD. And I think it's much nicer
than H (also since H@{u} doesn't resolve [1]). The purpose of this
patch is to standardize @ for everyone.
What annoys me
On 13-04-29 05:15 PM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
This started out as an attempt to make the backward compatibility notes
more parsable, but then I just kept going...
Thanks.
* git bundle did not like a bundle created using a commit without
-
On Tue, Apr 30, 2013 at 03:01:22PM +0200, Thomas Rast wrote:
This patch has the exact same effect as:
$ git symbolic-ref @ HEAD
But then why don't you just 'git symbolic-ref H HEAD' for a sort of
local alias?
For me, it's because I don't want to do that on every repo. One day if
I
On Tue, Apr 30, 2013 at 09:08:49AM +0100, John Keeping wrote:
With your patch, doesn't t-*.sh --root $there automatically
use the fast $there temporary location as the result depot, too?
No, the current code uses:
$TEST_OUTPUT_DIRECTORY/$root/trash\ directory.t
where we
On 04/30/2013 05:04 PM, Duy Nguyen wrote:
On Tue, Apr 30, 2013 at 03:01:22PM +0200, Thomas Rast wrote:
What annoys me more is that there's no way to say
git symbolic-ref U @{u}
so that I can avoid that -- it's really clumsy to type on a Swiss German
keyboard. We'd need some sort of
Duy Nguyen pclo...@gmail.com writes:
It's not hard to do. The below patch makes . equivalent to HEAD and
.U - @{u}. Refs are not supposed to have '.' at the beginning, so
it's easy ...
How is the equivalent of master..@{u} expressed? master...U? How is
it disambiguated from a symmetric
On Tue, Apr 30, 2013 at 11:59:39AM -0400, Jeff King wrote:
On Tue, Apr 30, 2013 at 09:08:49AM +0100, John Keeping wrote:
With your patch, doesn't t-*.sh --root $there automatically
use the fast $there temporary location as the result depot, too?
No, the current code uses:
On Tue, Apr 30, 2013 at 05:12:08PM +0100, John Keeping wrote:
So I'm not against TEST_OUTPUT_DIRECTORY as a concept, but I'm having
trouble seeing how it is more useful than --root.
I think the original intent of TEST_OUTPUT_DIRECTORY was to allow other
users of the test framework (in
On Tue, Apr 30, 2013 at 11:09 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
It's not hard to do. The below patch makes . equivalent to HEAD and
.U - @{u}. Refs are not supposed to have '.' at the beginning, so
it's easy ...
How is the equivalent of
John Szakmeister j...@szakmeister.net writes:
When I added -c/--cc, I contemplated making -p imply --cc, but
decided against it primarily because it is a change in traditional
behaviour, and it is easy for users to say --cc instead of -p from
the command line.
FWIW, security aside, I
Does anybody familiar with the http codepath have comments on this?
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 0x070704
On Tue, Apr 30, 2013 at 12:37 PM, Junio C Hamano gits...@pobox.com wrote:
John Szakmeister j...@szakmeister.net writes:
When I added -c/--cc, I contemplated making -p imply --cc, but
decided against it primarily because it is a change in traditional
behaviour, and it is easy for users to say
Ramsay Jones ram...@ramsay1.demon.co.uk writes:
However, I'm always a little wary when I hear someone say this may be
useful to others in the future, so lets do X to make it easier
I have noticed that, much more often than not, that future user never
does materialise ... ;-)
I do not
Jonathan Nieder jrnie...@gmail.com writes:
The reordering made in v1.8.1.1~7^2~2 still seems like voodoo to me,
but at least it works. This patch applies that same order for
everyone. Systems that would previously use the I have old win32api
and don't need that reordering codepath don't
Junio C Hamano wrote:
We need to see if we can make the explanation we will give
to end users is understandable.
I'll make an attempt.
@ can be used in two contexts:
1. When used without the {}, it means HEAD.
2. When used with a {}, it means what those three forms individually
mean. @{}
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 symref peeling is a bad idea: I can't take my aliases with
me, and they
Duy Nguyen pclo...@gmail.com writes:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com 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
Junio C Hamano wrote:
git update-ref HEAD $commit is accepted. If @ is a synonym for
HEAD, git update-ref @ $commit should work exactly the same way,
but is it desirable?
Would we have $GIT_DIR/@ as the result? How
about git symbolic-ref?
Yes, it is a valid refname that can be overridden
Junio C Hamano gits...@pobox.com 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 defaulting to --cc may be convenient, it would indeed
On Tue, Apr 30, 2013 at 12:23 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Junio C Hamano wrote:
Would @@{4} and HEAD@{4} be the same?
No. Why should they?
Why would HEAD^0^0~4 work? Because the syntax is recursive.
--
Felipe Contreras
--
To unsubscribe from this list: send the line
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?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
From: Junio C Hamano gits...@pobox.com
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t6012-rev-list-simplify.sh | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/t/t6012-rev-list-simplify.sh b/t/t6012-rev-list-simplify.sh
index
When simplifying an odd merge, such as one that used -s ours, we may
find ourselves TREESAME to apparently redundant parents. Prevent
simplify_merges() from removing every TREESAME parent; if this would
happen reinstate the first TREESAME parent - the one that the default
log would have followed.
When growing the table, take the opportunity to compact it by removing
entries with NULL decoration.
Users may have removed decorations by passing NULL to
insert_decoration. An object's table entry can't actually be removed
during normal operation, as it would break the linear hash collision
In the example given, P is not TREESAME to E. This doesn't affect the
current result, but it will matter when we change behaviour.
Signed-off-by: Kevin Bracey ke...@bracey.fi
---
Documentation/rev-list-options.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
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.
New part 1 is just me making amends for writing
Reimplement commit 4b7f53da on top of the new simplify-merges
infrastructure, tightening the condition to only consider root parents;
the original version incorrectly dropped parents that were TREESAME to
anything.
Original log message follows.
The merge simplification rule stated in 6546b59
History simplification previously always treated merges as TREESAME
if they were TREESAME to any parent.
While this was consistent with the default behaviour, this could be
extremely unhelpful when searching detailed history, and could not be
overridden. For example, if a merge had ignored a
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@{0} becomes HEAD@ and master@{0}
becomes
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@{0} becomes HEAD@ and master@{0}
becomes
On Tue, Apr 30, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
So we can type '@' instead of 'HEAD@', or rather 'HEAD'. So now we can
use 'git show @~1', and
When --stdlayout and --preserve-empty-dirs flags are used and a
directory becomes empty, two things happen:
Sometimes find_empty_directories() returns empty list and no empty dir
placeholder file created. This happens, because find_empty_directories()
marks all directories as non-empty, if at
In the previous commit a showcase was added to
t9160-git-svn-preserve-empty-dirs.sh for the Failed to strip path bug.
Now the flag --stdlayout should be enough.
---
t/t9160-git-svn-preserve-empty-dirs.sh | 16
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git
The Fetcher accumulates deleted paths in an array and doesn't reset the
array on next commit. This causes different results when interrupting
and resuming the fetch.
When --preserve-empty-dirs flag is used, a path in the array can be
erroneously treated as just deleted (although it was deleted in
.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
---
- 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
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Ramkumar Ramachandra artag...@gmail.com 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
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 nothing, same
On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Junio C Hamano gits...@pobox.com 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
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/@.
Ramkumar Ramachandra artag...@gmail.com 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
On Tue, Apr 30, 2013 at 12:54 PM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Never-mind, now I see the difference, still, I don't think it's
relevant for this patch.
I don't
On Tue, Apr 30, 2013 at 12:56 PM, Jeff King p...@peff.net 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.
Hmm,
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}
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
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 0x070704
Stephen Boyd sb...@codeaurora.org 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
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
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
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 @{0}
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, @@{n} will show the reflog
for HEAD. To the user, it looks like @ is behaving like a true ref by
On Tue, Apr 30, 2013 at 12:40 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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
Ilya Basin basini...@gmail.com 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
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-
On 30 April 2013 18:58, John Szakmeister j...@szakmeister.net wrote:
On Tue, Apr 30, 2013 at 1:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Junio C Hamano gits...@pobox.com writes:
By the way, these options are _not_ about showing merge commits
that introduce code, and they do not
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Apr 30, 2013 at 2:35 AM, Felipe Contreras
felipe.contre...@gmail.com 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
John Tapsell johnf...@gmail.com 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
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 respecting
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
Junio C Hamano gits...@pobox.com 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
On Tue, Apr 30, 2013 at 11:27 AM, Jeff King p...@peff.net 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
Ramkumar Ramachandra artag...@gmail.com 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
}
@@ -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)}) {
-
On 30 April 2013 20:44, Junio C Hamano gits...@pobox.com wrote:
John Tapsell johnf...@gmail.com 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
Jerry Qassar jqas...@gmail.com 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.
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
On Tue, Apr 30, 2013 at 01:17:03PM -0700, Junio C Hamano wrote:
Jerry Qassar jqas...@gmail.com 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
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com 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
John Tapsell johnf...@gmail.com writes:
On 30 April 2013 20:44, Junio C Hamano gits...@pobox.com wrote:
John Tapsell johnf...@gmail.com 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
1 - 100 of 160 matches
Mail list logo
