"Jason Pyeron" writes:
> When a repo has multiple initial commits, the oneline graph can get borked.
>
> It will put a commit * with no parent directly above the next commit *
> with no children. This gives the false impression that the two commits
> are a sequence on a branch.
Sounds vaguely fa
In git 2.2.0 (also tested on 2.2.0.65.g9abc44b), if an external
smudge/clean filter is called on an empty file git reports something
like:
error: copy-fd: read returned Bad file descriptor
error: cannot feed the input to external filter cat
error: external filter cat failed
Test case:
mkdir bug
c
> - ./uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD |
> + uniset/uniset --32 cat:Me,Mn,Cf + U+1160..U+11FF - U+00AD |
(Technically both do the same)
I personally think that using ./ it is extra obvious that a command is not
from the path somewhere.
But that may
On Dec 19, 2014, at 3:16 PM, brian m. carlson
wrote:
>
> On Fri, Dec 19, 2014 at 03:07:20PM +, Dan Langille (dalangil) wrote:
>> Correct, we are trying to avoid that. In addition, there is only https, no
>> http.
>
> I don't think HTTPS versus HTTP matters. I use Kerberos over HTTPS only
On Fri, Dec 19, 2014 at 03:07:20PM +, Dan Langille (dalangil) wrote:
> Correct, we are trying to avoid that. In addition, there is only https, no
> http.
I don't think HTTPS versus HTTP matters. I use Kerberos over HTTPS only
and it works fine.
> To be clear, for the following tests, there
This way we don't need to declare the function first and implement it
later, but rather we put the implementation directly at the place where
the function was declared.
The reason I did not move it up in the first place is better readability
of the diff as the execute_commands_non_atomic function
From: Ronnie Sahlberg
This adds support to send-pack to negotiate and use atomic pushes
iff the server supports it. Atomic pushes are activated by a new command
line flag --atomic.
In order to do this we also need to change the semantics for send_pack()
slightly. The existing send_pack() functio
This adds tests for the atomic push option.
The first four tests check if the atomic option works in
good conditions and the last three patches check if the atomic
option prevents any change to be pushed if just one ref cannot
be updated.
Signed-off-by: Stefan Beller
---
Notes:
v6: the same
From: Ronnie Sahlberg
Add a command line argument to the git push command to request atomic
pushes.
Signed-off-by: Ronnie Sahlberg
Signed-off-by: Stefan Beller
---
Notes:
Changes v1 -> v2
It's --atomic now! (dropping the -push)
v2->v3:
* s/atomic-push/atomic/
This renames ref_update_to_be_sent to check_to_send_update and inverts
the meaning of the return value. Having the return value inverted we
can have different values for the error codes. This is useful in a
later patch when we want to know if we hit the CHECK_REF_STATUS_REJECTED
case.
Signed-off-b
From: Ronnie Sahlberg
This adds support to the protocol between send-pack and receive-pack to
* allow receive-pack to inform the client that it has atomic push capability
* allow send-pack to request atomic push back.
There is currently no setting in send-pack to actually request that atomic
pus
Update receive-pack to use an atomic transaction iff the client negotiated
that it wanted atomic-push. This leaves the default behavior to be the old
non-atomic one ref at a time update. This is to cause as little disruption
as possible to existing clients. It is unknown if there are client scripts
This patch series adds a flag to git push to update the remote refs atomically.
This series applies on top of origin/mh/reflog-expire
It can also be found at github[1].
This series incorporates all suggestions by Eric. Most changes appear in
patch 4/7 as it is a complete rewrite compared to v5 of
(Separated out from another thread since this issue seems more general.)
I am planning to use 'git new-workdir', which basically lets several
workspaces share a single .git/refs directory. (Among other dirs in
.git) It's possible that I'll end up running 'git fetch' in these
workspaces simultaneou
Hi,
I¹m having some trouble with gitk on Mac using a very large repository
(chromium/src).
I¹m using git version 2.2.1 from Homebrew.
The error details are the following:
couldn't execute "git": argument list too long
couldn't execute "git": argument list too long
while executing
"open [conc
Commit 5ed85684 ("reflog_expire(): new function in the reference
API", 12-12-2014) added a new function definition which included
the extern keyword.
While this is not an illegal use of the keyword, it is somewhat
unusual to include it in a function definition. (It would be
unique in the git code
Anastas Dancha schrieb am 19.12.2014 um 16:44:
> Hello Johannes,
>
> On Fri, Dec 19, 2014 at 4:37 AM, Johannes Schindelin
> wrote:
>> [...]
>> There is one bit left to clarify: let me guess, you have a $HOME/.gitconfig
>> like this:
>>
>> [url "anas...@company.com"]
>> ins
When a repo has multiple initial commits, the oneline graph can get borked.
It will put a commit * with no parent directly above the next commit * with no
children. This gives the false impression that the two commits are a sequence
on a branch. E.g:
* xxx update of A (#0011)
* xxx merg
From: Beat Bolli
Now that the whole file is generated by one single command, the command
group is no longer needed.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.s
From: Beat Bolli
By using a here document instead of the echo/uniset sequence, the final
structure of the generated file becomes obvious.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/update_unicode.sh b/upd
From: Beat Bolli
The value is the same on both uniset invocations, so "Don't Repeat
Yourself" applies.
Since we're in a subshell already, there's no need to unset UNICODE_DIR
at the end.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Beat Bolli
Instead of capturing the output of each echo and uniset invocation, wrap
the whole section in a group command and redirect its output all at
once.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --gi
From: Beat Bolli
"uniset/uniset" is a relative path; there's no need to prefix it with "./".
Signed-off-by: Beat Bolli
---
update_unicode.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index bed8916..f5cc14b 100755
--- a/update_
From: Beat Bolli
By using a here document instead of the echo/uniset sequence, the final
structure of the generated file becomes obvious.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/update_unicode.sh b/upd
From: Beat Bolli
The value is the same on both uniset invocations, so "Don't Repeat
Yourself" applies.
Since we're in a subshell already, there's no need to unset UNICODE_DIR
at the end.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Beat Bolli
"uniset/uniset" is a relative path; there's no need to prefix it with "./".
Signed-off-by: Beat Bolli
---
update_unicode.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index bed8916..f5cc14b 100755
--- a/update_
From: Beat Bolli
Now that the whole file is generated by one single command, the command
group is no longer needed.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 23 +++
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.s
From: Beat Bolli
Instead of capturing the output of each echo and uniset invocation, wrap
the whole section in a group command and redirect its output all at
once.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --gi
2014-12-19 3:38 GMT-07:00 Albert Astals Cid :
> Hi, i'm attaching a fix for the Catalan translation were it seems some
> Spanish sneaked in.
Hi Albert, thanks for your interest, and sorry for the error. I'm
currently working with Joan Perals on a batch of corrections to the
Catalan translation, in
> On Dec 19, 2014, at 10:07 AM, Dan Langille (dalangil)
> wrote:
>
>> You might also try specifying KrbMethodK5Passwd on explicitly. I don't
>> happen to use that option (I use Kerberos to avoid passwords altogether)
>> so that might work for you.
>>
>> I don't know what version of git you're
> On Dec 19, 2014, at 10:07 AM, Dan Langille (dalangil)
> wrote:
>
>> You might also try specifying KrbMethodK5Passwd on explicitly. I don't
>> happen to use that option (I use Kerberos to avoid passwords altogether)
>> so that might work for you.
>>
>> I don't know what version of git you're
On Fri, Dec 19, 2014 at 04:43:51PM +0100, Beat Bolli wrote:
> I think the code looks much nicer with a here doc.
>
> Checking in t/, it looks that there's no consensus about whether to
> indent the content relative to the cat statement or not. What do you
> suggest?
I think we typically do it at
Hello Johannes,
On Fri, Dec 19, 2014 at 4:37 AM, Johannes Schindelin
wrote:
> [...]
> There is one bit left to clarify: let me guess, you have a $HOME/.gitconfig
> like this:
>
> [url "anas...@company.com"]
> insteadOf = backup
> pushInsteadOf = backup
>
>
On 19.12.14 16:22, Jeff King wrote:
> On Fri, Dec 19, 2014 at 03:39:30PM +0100, dev+...@drbeat.li wrote:
>
>> By using printf instead of the echo/uniset sequence, the final structure
>> of the generated file becomes obvious.
>
> This whole series looks pretty sane to me, and the result is easier
On Fri, Dec 19, 2014 at 03:39:30PM +0100, dev+...@drbeat.li wrote:
> By using printf instead of the echo/uniset sequence, the final structure
> of the generated file becomes obvious.
This whole series looks pretty sane to me, and the result is easier to
read.
I did wonder if a here-doc would be
On 19.12.14 15:39, dev+...@drbeat.li wrote:
> From: Beat Bolli
Sorry, it looks like git send-email borked these messages. This line
should be part of the mail headers.
Regards,
Beat Bolli
--
https://drbeat.li
pgp: 0x506A903A; 49D5 794A EA77 F907 764F D89E 304B 93CF 506A 903A
gsm: 4.7.7.6.0.7
> On Dec 18, 2014, at 5:54 PM, brian m. carlson
> wrote:
>
> On Thu, Dec 18, 2014 at 10:19:19PM +, Dan Langille (dalangil) wrote:
>> This is what happens without a valid ticket:
>>
>> $ git clone https://us.example.com/git/clamav-bytecode-compiler
>> Cloning into 'clamav-bytecode-compiler'.
From: Beat Bolli
By using printf instead of the echo/uniset sequence, the final structure
of the generated file becomes obvious.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/update_unicode.sh b/update_un
From: Beat Bolli
Now that the whole file is generated by one single command, the command
group is no longer needed.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index 6196
From: Beat Bolli
The value is the same on both uniset invocations, so "Don't Repeat
Yourself" applies.
Since we're in a subshell already, there's no need to unset UNICODE_DIR
at the end.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: Beat Bolli
"uniset/uniset" is a relative path; there's no need to prefix it with "./".
Signed-off-by: Beat Bolli
---
update_unicode.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/update_unicode.sh b/update_unicode.sh
index bed8916..f5cc14b 100755
--- a/update_
From: Beat Bolli
Instead of capturing the output of each echo and uniset invocation, wrap
the whole section in a group command and redirect its output all at
once.
Signed-off-by: Beat Bolli
---
update_unicode.sh | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --gi
I'm not subscribed, please CC-me.
Hi, i'm attaching a fix for the Catalan translation were it seems some
Spanish sneaked in.
Cheers,
Albert
P.S: Sending again since your list didn't like me sending this from
@yahoo mail server
From e8ae2db0d0f9736bd35d92a66fc46f59d762ad95 Mon Sep 17 00:00:00 2
On Thu, Dec 18, 2014 at 7:22 PM, Stefan Beller wrote:
> From: Ronnie Sahlberg
>
> Update receive-pack to use an atomic transaction iff the client negotiated
> that it wanted atomic-push. This leaves the default behavior to be the old
> non-atomic one ref at a time update. This is to cause as litt
[using v2.1.3]
When using "rebase -i" and the working dir contains untracked files that are
present
in the new base, we correctly get a "would be overwritten by checkout" error,
but then
the whole rebase interrupts the (long) listing of the incriminated files in the
middle
of a line and termina
Hi Anastas,
On Tue, 16 Dec 2014, Anastas Dancha wrote:
> Then I wrote "alias", I've meant the following:
> ```
> [url "g...@githost.com"]
> insteadOf = myalias
> pushInsteadOf = myalias
> ```
> Unfortunately, your suggested fix will not allow my [poorly] described
> use case.
There is one bit le
Hi Max,
On Fri, 19 Dec 2014, Max Kirillov wrote:
> Hello. Thank you for the fix.
You are welcome.
> Would it be more reliable to compare inode of directory in question and
> ".git"? (there is [*] for windows). So that any unspotted name
> equivalence is prevented to cause any harm.
>
> *)
> h
Signed-off-by: Alexander Kuleshov
---
builtin/clean.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 7784676..7e7fdcf 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -321,7 +321,7 @@ static void print_highlight_menu_stuff(struct m
48 matches
Mail list logo
