Update "git push" and "git send-pack" to parse this commnd line
option.
The intended sematics is:
* "--force-with-lease" alone, without specifying the details, will
protect _all_ remote refs that are going to be updated by
requiring their current value to be the same as some reasonable
Prepare two repositories, src and dst, the latter of which is a
clone of the former (with tracking branches), and push from the
latter into the former, with various --force-with-lease options.
Signed-off-by: Junio C Hamano
---
t/t5533-push-cas.sh | 189 +++
The command line parser of "git push" for "--tags", "--delete", and
"--thin" options still used outdated OPT_BOOLEAN. Because these
options do not give escalating levels when given multiple times,
they should use OPT_BOOL.
Signed-off-by: Junio C Hamano
---
builtin/push.c | 6 +++---
1 file chan
The definition of "struct ref" in "cache.h", a header file so
central to the system, always confused me. This structure is not
about the local ref used by sha1-name API to name local objects.
It is what refspecs are expanded into, after finding out what refs
the other side has, to define what ref
This is mostly unchanged since the previous round, except that
* The option is spelled "--force-with-lease=:".
Nobody liked "cas" as it was too technical, many disliked
"lockref" because "lock" sounded as if push by others were
excluded by it while in fact this is to fail us.
The fin
This teaches the deepest part of the callchain for "git push" (and
"git send-pack") to enforce "the old value of the ref must be this,
otherwise fail this push" (aka "compare-and-swap" / "--lockref").
Signed-off-by: Junio C Hamano
---
builtin/send-pack.c | 5 +
remote.c| 49
This plugs the push_cas_option data collected by the command line
option parser to the transport system with a new function
apply_push_cas(), which is called after match_push_refs() has
already been called.
At this point, we know which remote we are talking to, and what
remote refs we are going to
On Tue, Jul 23, 2013 at 11:08 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> This one, on the other hand, changes the "shape" of the repo (now with
>> holes) and might need to go through the same process we do with this
>> series. Maybe we should prepare for it now. Do you have a use case fo
Junio C Hamano writes:
>> I think the notice still deserve the "***NOTICE***" or whatever makes it
>> visible enough to distinguish it from the traditional licence &
>> non-warranty header, but I don't think we should kill the old script too
>> early.
>
> True. I personally felt that Jonathan's
Duy Nguyen writes:
> This one, on the other hand, changes the "shape" of the repo (now with
> holes) and might need to go through the same process we do with this
> series. Maybe we should prepare for it now. Do you have a use case for
> size-based filtering? What can we do with a repo with some
Duy Nguyen writes:
> But yeah, maybe defaulting to no shallow is better. Will do so in the
> reroll unless someone objects.
No objections from me ;-).
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo in
On Tue, Jul 23, 2013 at 2:10 AM, Philip Oakley wrote:
>> And a full repository may automatically become shallow if
>> you fetch from a shallow repository.
>
>
> This "sounds" risky: Perhaps add a note about '[PATCH v2 15/16] config: add
> core.noshallow to prevent turning a repo into a
On Tue, Jul 23, 2013 at 2:23 AM, Philip Oakley wrote:
> From: "Nguyễn Thái Ngọc Duy"
> Subject: [PATCH v2 15/16] config: add core.noshallow to prevent turning a
> repo into a shallow one
>
> Surely this should be the default now that it is possible to corrupt a
> golden repo by pushing/fetching a
On Tue, Jul 23, 2013 at 6:41 AM, Philip Oakley wrote:
> From: "Nguyễn Thái Ngọc Duy"
> Subject: [PATCH v2 00/16] First class shallow clone
>
> It's nice to see that shallow can be a first class clone.
>
> Thinking outside the box, does this infrastructure offer the opportunity to
> maybe add a da
From: "Nguyễn Thái Ngọc Duy"
Subject: [PATCH v2 00/16] First class shallow clone
It's nice to see that shallow can be a first class clone.
Thinking outside the box, does this infrastructure offer the opportunity
to maybe add a date based depth option that would establish the shallow
watermark
Yamada Saburo writes:
> Is free translation impossible?
Sorry, I do not understand the question. Aren't you helping us with
that?
> I want to give priority to ease of use.
> Does Mr. Hamano know that it is said that Japanese translation of
> Git-gui is very unclear?
Yes. Aren't we trying to
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
This again is one of those back-to-back issues of "What's cooking"
report that I avoid doing, but I expect that the rest of the week
will be slo
> ml/cygwin-updates:
> cygwin: stop forcing core.filemode=false
I like that: cygwin behaves more like Unix/Linux.
Just a side-comment: When working on NTFS, cygwin
will set core.filemode=true, and as a result of that,
the "cheating lstat" code is not used any more.
So it is not run under
Ondřej Bílka writes:
> Hi, this is refactored version of my previous typofix patch. I avoid
> here controversional fixes.
> I am writing a https://github.com/neleai/stylepp tool to handle
> various style issues.
>
> To simplify review I wrote a utility:
>
> stylepp_strip_diff
>
> That takes a pat
Is free translation impossible? I want to give priority to ease of use.
Does Mr. Hamano know that it is said that Japanese translation of
Git-gui is very unclear? It is wonderful that my translation is
severely examined so far by me compared with a former translator.
Compiled .msg file so that it
"Kyle J. McKay" writes:
> After replacing "take" with "takes" in the change I'm good with just
> squashing that diff in.
Thanks for proofreading. Then let's omit an extra back-and-forth.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger
Yamada Saburo writes:
> -#: git-gui.sh:2893
> +#: git-gui.sh:2983 git-gui.sh:3115
> +msgid "Usage"
> +msgstr "使用状況"
Is this correct? I am not familiar with the context this string
appears, but shouldn't it be "使い方"?
> -#: lib/choose_repository.tcl:479
> +#: lib/choose_repository.tcl:480
> msg
Yamada Saburo writes:
> Signed-off-by: Yamada Saburo
> ---
Assuming that this was generated automatically by running "make
po/git-gui.pot" in git-gui tree, this looks good to me.
But it would have been nice if the proposed commit log message said
so, if that is indeed the case.
> po/git-gui.
Yamada Saburo writes:
> Signed-off-by: Yamada Saburo
This looks good to me.
> ---
> lib/option.tcl | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/option.tcl b/lib/option.tcl
> index 0cf1da1..7af858c 100644
> --- a/lib/option.tcl
> +++ b/lib/option.tcl
> @@ -158,7
John Keeping writes:
> The options section of the git-rev-parse manual page has grown
> organically so that there now does not seem to be much logic behind the
> ordering of the options. It also does not make it clear that certain
> options must appear first on the command line.
>
> Address this
On Sun, Jul 21, 2013 at 11:57:43PM -0700, Junio C Hamano wrote:
> * jk/fast-import-empty-ls (2013-06-23) 4 commits
> - fast-import: allow moving the root tree
> - fast-import: allow ls or filecopy of the root tree
> - fast-import: set valid mode on root tree in "ls"
> - t9300: document fast-imp
On 07/22/2013 01:02 AM, Junio C Hamano wrote:
b) The Cygwin project has always shipped git binaries built without
NO_TRUSTABLE_FILEMODE
That is a fair point. So let's do this instead.
-- >8 --
From: Mark Levedahl
Subject: [PATCH] cygwin: stop forcing core.filemode=false
We force core.filemod
Yamada Saburo writes:
> My patch is not listed. When is it merged?
I do not take patches to git-gui (or gitk) directly to my tree.
Because nobody acked nor nacked the latest round yet, I do not think
the area maintainer has picked them up yet.
--
To unsubscribe from this list: send the line "un
On Jul 22, 2013, at 14:51, Junio C Hamano wrote:
"Kyle J. McKay" writes:
A solid wall of text is somewhat hard to read, so I'd queue the
equivalent of the following "git diff -w" output on top.
Can I send out the change as a 'fixup!' patch? Or do I need to
send a
new v9 patch series wi
The latest maintenance release Git v1.8.3.4 is now available at
the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
fe633d02f7d964842d7ea804278b75120fc60c11 git-1.8.3.4.tar.gz
1f1200515e1e7042bcbd4176ef76c5802
"Kyle J. McKay" writes:
>> A solid wall of text is somewhat hard to read, so I'd queue the
>> equivalent of the following "git diff -w" output on top.
>
> Can I send out the change as a 'fixup!' patch? Or do I need to send a
> new v9 patch series with the documentation update?
If you are OK wit
Thomas Rast writes:
> When using pathspec filtering in combination with diff-based log
> output, parent simplification happens before the diff is computed.
> The diff is therefore against the *simplified* parents.
>
> This works okay, arguably by accident, in the normal case: the pruned
> commits
My patch is not listed. When is it merged?
--
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
Thomas Rast writes:
> I'll just leave it at that and let you decide what to do (presumably go
> ahead as you already outlined). I've never actually ever used multiple
> -L in the same log/blame invocation, anyway.
Nobody has ;-).
It is just between my "I often wished while looking at 'less foo
When using pathspec filtering in combination with diff-based log
output, parent simplification happens before the diff is computed.
The diff is therefore against the *simplified* parents.
This works okay, arguably by accident, in the normal case: the pruned
commits did not affect the paths being f
Hi, this is refactored version of my previous typofix patch. I avoid
here controversional fixes.
I am writing a https://github.com/neleai/stylepp tool to handle
various style issues.
To simplify review I wrote a utility:
stylepp_strip_diff
That takes a patch file, strips surrounding lines and pr
Am 22.07.2013 09:48, schrieb Duy Nguyen:
> On Mon, Jul 22, 2013 at 2:32 PM, Jens Lehmann wrote:
>> Am 22.07.2013 08:57, schrieb Junio C Hamano:
>>> * jl/submodule-mv (2013-04-23) 5 commits
>>> . submodule.c: duplicate real_path's return value
>>> . rm: delete .gitmodules entry of submodules remo
On Jul 22, 2013, at 11:00, Junio C Hamano wrote:
"Kyle J. McKay" writes:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index e461f32..c418adf 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1517,15 +1517,26 @@ http..*::
Any of the http.* options abo
Hi,
Sorry for the delay. Not been monitoring the list lately.
I'm afraid work stopped for two reasons. Lack of interest from the
list was the main one. I understand subtree isn't used much and
subsequently there wasn't much interest in reviewing the patches I was
putting out. As a result I lost i
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Eric Sunshine writes:
>>
>>> The proposal currently is only for "-L /RE/,whatever" to behave in a
>>> relative fashion, beginning the search at the end of the last range
>>> specified via -L (or line 1 if there is no previous -L).
>>>
>>> Would
From: "Nguyễn Thái Ngọc Duy"
Subject: [PATCH v2 15/16] config: add core.noshallow to prevent turning
a repo into a shallow one
Surely this should be the default now that it is possible to corrupt a
golden repo by pushing/fetching a shallow repository to it and it then
becomes shallow, and al
From: "Nguyễn Thái Ngọc Duy"
upload-pack already advertises all shallow grafts if server repository
is shallow. This information can be used to add more grafts to the
client if the server sends commit chains down to its graft points.
If the server is shallow, before we receive the pack, we setu
"Kyle J. McKay" writes:
> Previously the had to specify an exactly matching user name
> and password if those were present in the url being matched against.
>
> Now the password portion is always ignored and omitting the user
> name from allows it to match against any user name.
>
> Signed-off-
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Also I wonder if this one Documentation/git-log.txt:156
>>
>> git log -L '/int main/',/^}/:main.c
>>
>> should be more like one of these:
>>
>> git log -L '/int main/,/^}/':main.c
>> git log -L '/int main/,/^}/:main.c'
>>
>> I find it
Thomas Rast writes:
> Eric Sunshine writes:
>
>> The proposal currently is only for "-L /RE/,whatever" to behave in a
>> relative fashion, beginning the search at the end of the last range
>> specified via -L (or line 1 if there is no previous -L).
>>
>> Would it also make sense to support "-L +
Improve on the http..* url matching behavior by first
normalizing the urls before they are compared.
With this change, for example, the following configuration
section:
[http "https://example.com/path";]
useragent = example-agent
sslVerify = false
will properly match a "HTTPS://e
In order to perform sane URL matching for http..* options,
http.c normalizes URLs before performing matches.
A new test-url-normalize test program is introduced along with
a new t5200-url-normalize.sh script to run the tests.
Since the url_normalize function currently lives in http.c this
test wi
Previously the had to specify an exactly matching user name
and password if those were present in the url being matched against.
Now the password portion is always ignored and omitting the user
name from allows it to match against any user name.
Signed-off-by: Kyle J. McKay
---
Documentation/
The credentials configuration values already support url-specific
configuration items in the form credential..*. This patch
adds similar support for http configuration values.
The value is considered a match to a url if the value
is either an exact match or a prefix of the url which ends on a
p
NOTE: This patch requires the following preparatory change:
f1ff763 http.c: fix parsing of http.sslCertPasswordProtected variable
which is currently in pu.
This patch series adds support for http..* settings. The patch is
organized as a series of improvements on the functionality:
1/4 - adds
On Jul 21, 2013, at 22:28, Junio C Hamano wrote:
"Kyle J. McKay" writes:
diff --git a/test-url-normalize.c b/test-url-normalize.c
index d68312d..f325571 100644
--- a/test-url-normalize.c
+++ b/test-url-normalize.c
@@ -9,7 +9,7 @@ int main()
It looks like that this program could also drive ht
Джесика Альба рекомендует http://taek.me/28563
NЇВцьrИyњшиbВXЌЖЧЇvи^)оК{.nЧ+З иЇЖЁмЈ}ЉВЦ
zк&j:+vЈОЋъчzZ+Ъ+zfЃЂЗhЇ~лiџћрzЙ ЎwЅЂИ?Јшк&Ђ)пЂf
Eric Sunshine writes:
> The proposal currently is only for "-L /RE/,whatever" to behave in a
> relative fashion, beginning the search at the end of the last range
> specified via -L (or line 1 if there is no previous -L).
>
> Would it also make sense to support "-L +N,whatever" as relative to
> t
Junio C Hamano writes:
> * tr/merge-recursive-index-only (2013-07-07) 3 commits
> - merge-recursive: -Xindex-only to leave worktree unchanged
> - merge-recursive: untangle double meaning of o->call_depth
> - merge-recursive: remove dead conditional in update_stages()
>
> What's the status of
Uwe Kleine-König writes:
> Hello,
>
> today I looked at the changes to drivers/net/ethernet/freescale/fec.c in
> the kernel since v3.8 using
>
> git log --stat v3.8.. --full-diff --
> drivers/net/ethernet/freescale/fec.c
>
> which looks as expected. But when I added --graph the diffstats c
Junio C Hamano writes:
> Also I wonder if this one Documentation/git-log.txt:156
>
> git log -L '/int main/',/^}/:main.c
>
> should be more like one of these:
>
> git log -L '/int main/,/^}/':main.c
> git log -L '/int main/,/^}/:main.c'
>
> I find it somewhat hard to spot the closing
I was able to apply the patch I got back. It was marked as
charset=ISO-8859-1 so it should be fine.
I wasn't sure how best to handle those though, so I will send a new
version with the suggested .gitattributes patch included as well.
On Jul 21, 2013, at 23:45, Junio C Hamano wrote:
I susp
On Jul 21, 2013, at 22:15, Junio C Hamano wrote:
"Kyle J. McKay" writes:
+test_expect_success 'url general escapes' '
+ ! test-url-normalize "http://x.y?%fg"; &&
+ test "$(test-url-normalize -p "X://W/%7e%41^%3a")" = "x://w/~A%5E
%3A" &&
+ test "$(test-url-normalize -p "X://W/:/?#[]@")"
Hello,
today I looked at the changes to drivers/net/ethernet/freescale/fec.c in
the kernel since v3.8 using
git log --stat v3.8.. --full-diff --
drivers/net/ethernet/freescale/fec.c
which looks as expected. But when I added --graph the diffstats change.
E.g. for 793fc0964be1921f15a44be5
On Tue, Jul 9, 2013 at 4:25 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> It would be more general to support "follow the second match to /A/"
>> *independent* of whether the first match is also followed. I think your
>> proposal only allows the second to be followed if the first is
On Sun, Jul 21, 2013 at 03:33:57PM -0700, Junio C Hamano wrote:
> Thanks; the patch seems to cover all the instances.
>
> Sign off?
ok
> --
> 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
On Mon, Jul 22, 2013 at 2:32 PM, Jens Lehmann wrote:
> Am 22.07.2013 08:57, schrieb Junio C Hamano:
>> * jl/submodule-mv (2013-04-23) 5 commits
>> . submodule.c: duplicate real_path's return value
>> . rm: delete .gitmodules entry of submodules removed from the work tree
>> . Teach mv to update
Am 22.07.2013 08:57, schrieb Junio C Hamano:
> * jl/submodule-mv (2013-04-23) 5 commits
> . submodule.c: duplicate real_path's return value
> . rm: delete .gitmodules entry of submodules removed from the work tree
> . Teach mv to update the path entry in .gitmodules for moved submodules
> . Tea
On Mon, Jul 22, 2013 at 2:57 AM, Junio C Hamano wrote:
> * es/contacts (2013-07-21) 5 commits
> - contrib: contacts: add documentation
> - contrib: contacts: add mailmap support
> - contrib: contacts: interpret committish akin to format-patch
> - contrib: contacts: add ability to parse from co
64 matches
Mail list logo
