This patch puts the usage info strings that were not already in docopt-
like format into docopt-like format, which will be a litle easier for
end users and a lot easier for translators. Changes include:
- Placing angle brackets around fill-in-the-blank parameters
- Putting dashes in multiword para
On Wed, Jan 7, 2015 at 5:31 PM, Reuben Hawkins wrote:
> On Wed, Jan 7, 2015 at 1:37 PM, Eric Sunshine wrote:
>> On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
>>> +GIT_CHECK_FUNC(clock_gettime,
>>> +[HAVE_CLOCK_GETTIME=YesPlease],
>>> +[HAVE_CLOCK_GETTIME=])
>>> +GIT_CONF_SUBST([HAVE_CLOC
On Wed, Jan 7, 2015 at 5:19 PM, Reuben Hawkins wrote:
> On Wed, Jan 7, 2015 at 1:19 PM, Eric Sunshine wrote:
>> On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
>>> This check will automatically set the correct NO_NSEC setting.
>>
>> This commit message neglects to mention the important poi
This commit allows us in a later patch to easily distinguish between
the non atomic way to update the received refs and the atomic way which
is introduced in a later patch.
Signed-off-by: Stefan Beller
---
Notes:
v10, v11, v12:
no changes
v9:
new and shiny. But makes the ne
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
This introduces the new function execute_commands_atomic which will use
one atomic transaction for all updates. The default behavior is still
the old non atomic way, one ref at a time. This is to cause as little
disruption as possible to existing clients. It is unknown if there are
client scripts t
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:
v10, v11, v12
This moves all code related to transactions into the
execute_commands_non_atomic function. This includes
beginning and committing the transaction as well as
dealing with the errors which may occur during the
begin and commit phase of a transaction.
No functional changes intended.
Helped-by: Eric
From: Ronnie Sahlberg
This adds the atomic protocol option to allow
receive-pack to inform the client that it has
atomic push capability.
This commit makes the functionality introduced
in the previous commits go live for the serving
side. The changes in documentation reflect the
protocol capabil
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:
v10, v11, v12:
* no changes
v8, v9:
no changes
v7:
Use OPT_BOOL instead of OPT_BIT.
Discussion on the previous patch revealed we rather want to err on the
safe side. To do so we need to stop receive-pack in case of the possible
future bug when connectivity is not checked on a shallow push.
Also while touching that code we considered that removing the reported
refs may be harmful
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
Make the main "execute_commands" loop in receive-pack easier to read
by splitting out some steps into helper functions. The new helper
'should_process_cmd' checks if a ref update is unnecessary, whether
due to an error having occurred or for another reason. The helper
'warn_if_skipped_connectivity_
There wasn't discussion within the last 24 hours and we were discussing only
about minor changes. Changes compared to v9 (the last time I completely sent the
series) is only found in the first 2 patches, where we had a back and forth
about naming the method warn_if_skipped_connectivity_check and
Apache servers using mod_auth_kerb can be configured to allow the user
to authenticate either using Negotiate (using the Kerberos ticket) or
Basic authentication (using the Kerberos password). Often, one will
want to use Negotiate authentication if it is available, but fall back
to Basic authentic
On Tue, Jan 06, 2015 at 04:07:01PM +, Dan Langille (dalangil) wrote:
< HTTP/1.1 401 Authorization Required
< Date: Tue, 06 Jan 2015 16:02:48 GMT
< Server: Apache
< WWW-Authenticate: Negotiate
Your server is set up incorrectly. You should see a Negotiate line and
a Basic line as well. Rig
Dscho, this sounds to me like the additional "8.3 ambiguity
protection" (which is only in Git for Windows) in action. Any
thoughts?
On Wed, Jan 7, 2015 at 3:26 PM, Dmitry Bykov wrote:
> Hello,
>
> Recently I installed 1.9.5 git version and faced the problem that one
> of the files in my cloned re
On Wed, Jan 7, 2015 at 3:26 PM, Dmitry Bykov wrote:
> Hello,
>
> Recently I installed 1.9.5 git version and faced the problem that one
> of the files in my cloned repository with a name ICON~714.PNG is
> marked as deleted even repository was freshly cloned. Trying to do
> anything with that file r
Hello,
Recently I installed 1.9.5 git version and faced the problem that one
of the files in my cloned repository with a name ICON~714.PNG is
marked as deleted even repository was freshly cloned. Trying to do
anything with that file resulted in constant "Invalid Path" errors.
Reverting back to 1.9
On Wed, Jan 7, 2015 at 1:37 PM, Eric Sunshine wrote:
> On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
>> CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
>> systems being used in production. This change makes compiling git
>> less tedious on older platforms without CLOC
On Wed, Jan 7, 2015 at 1:19 PM, Eric Sunshine wrote:
> On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
>> This check will automatically set the correct NO_NSEC setting.
>
> This commit message neglects to mention the important point that
> you're also now setting USE_ST_TIMESPEC when detect
On Wed, Jan 7, 2015 at 4:33 PM, Reuben Hawkins wrote:
> On Wed, Jan 7, 2015 at 1:19 PM, Eric Sunshine wrote:
>> On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
>>> +# Define USE_ST_TIMESPEC=YesPlease when stat.st_mtimespec.tv_nsec exist
>>
>> It would be slightly more accurate to drop the
On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
> OpenSSL version 0.9.6b and before defined the function HMAC_cleanup.
> Newer versions define HMAC_CTX_cleanup. Check for HMAC_CTX_cleanup and
> fall back to HMAC_cleanup when the newer function is missing.
Missing sign-off.
Overall, these
On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
> CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
> systems being used in production. This change makes compiling git
> less tedious on older platforms without CLOCK_MONOTONIC.
The second sentence is implied by the very pr
On Wed, Jan 7, 2015 at 1:19 PM, Eric Sunshine wrote:
> On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
>> This check will automatically set the correct NO_NSEC setting.
>
> This commit message neglects to mention the important point that
> you're also now setting USE_ST_TIMESPEC when detect
On Wed, Jan 7, 2015 at 3:23 PM, Reuben Hawkins wrote:
> This check will automatically set the correct NO_NSEC setting.
This commit message neglects to mention the important point that
you're also now setting USE_ST_TIMESPEC when detected. You might
revise the message like this:
Detect 'tv_ns
diff.submodule when set to log produces output which git-am cannot
handle. Ignore this setting when generating patch output.
Signed-off-by: Doug Kelly
---
builtin/log.c | 2 +-
t/t4255-am-submodule.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/log.
git am will break when using diff.submodule=log; add some test cases
to illustrate this breakage as simply as possible. There are
currently two ways this can fail:
* With errors ("unrecognized input"), if only change
* Silently (no submodule change), if other files change
Test for both condition
kel...@shysecurity.com writes:
>>> Content-Type: text/plain; charset=utf-8; format=flowed
>>Please. No format=flawed. Really.
> I'll figure out the line-wrapping.
>
>> Also this step is not about --no-relative and diff.relative but is
>> only about --no-relative option.
> Should I submit as two
OpenSSL version 0.9.6b and before defined the function HMAC_cleanup.
Newer versions define HMAC_CTX_cleanup. Check for HMAC_CTX_cleanup and
fall back to HMAC_cleanup when the newer function is missing.
---
Makefile | 3 +++
configure.ac | 7 +++
git-compat-util.h | 3 +++
3 file
This check will automatically set the correct NO_NSEC setting.
---
configure.ac | 12
1 file changed, 12 insertions(+)
diff --git a/configure.ac b/configure.ac
index 6af9647..dcc4bf0 100644
--- a/configure.ac
+++ b/configure.ac
@@ -754,6 +754,18 @@ AC_CHECK_TYPES([struct itimerval],
These patches add a few autoconfig checks for nanosecond resolution fields in
struct stat, CLOCK_MONOTONIC, and HMAC_CTX_cleanup. I'm fairly sure I've fixed
the concerns/doubts the first set of patched raised.
(I rarely use git-send-email so forgive me if I botch this)
--
To unsubscribe from this
CLOCK_MONOTONIC isn't available on RHEL3, but there are still RHEL3
systems being used in production. This change makes compiling git
less tedious on older platforms without CLOCK_MONOTONIC.
---
Makefile | 4
config.mak.uname | 1 +
configure.ac | 22 ++
tra
Doug Kelly writes:
> On Mon, Dec 29, 2014 at 9:42 AM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
+ (git am --abort || true) &&
>>
>> Why (x || y)? Is 'x' so unreliable that we do not know how should exit?
>> Should this be "test_must_fail git am --abort"?
>>
> Updated to test
diff.submodule when set to log produces output which git-am cannot
handle. Ignore this setting when generating patch output.
Signed-off-by: Doug Kelly
---
builtin/log.c | 2 +-
t/t4255-am-submodule.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/log.
git am will break when using diff.submodule=log; add some test cases
to illustrate this breakage as simply as possible. There are
currently two ways this can fail:
* With errors ("unrecognized input"), if only change
* Silently (no submodule change), if other files change
Test for both condition
On Wed, Jan 7, 2015 at 2:31 PM, Doug Kelly wrote:
> git am will break when using diff.submodule=log; add some test cases
> to illustrate this breakage as simply as possible. There are
> currently two ways this can fail:
>
> * With errors ("unrecognized input"), if only change
> * Silently (no sub
On Mon, Dec 29, 2014 at 9:42 AM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> + (git am --abort || true) &&
>
> Why (x || y)? Is 'x' so unreliable that we do not know how should exit?
> Should this be "test_must_fail git am --abort"?
>
Updated to test_might_fail -- we don't know if
diff.submodule when set to log produces output which git-am cannot
handle. Ignore this setting when generating patch output.
Signed-off-by: Doug Kelly
---
builtin/log.c | 2 +-
t/t4255-am-submodule.sh | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/log.
git am will break when using diff.submodule=log; add some test cases
to illustrate this breakage as simply as possible. There are
currently two ways this can fail:
* With errors ("unrecognized input"), if only change
* Silently (no submodule change), if other files change
Test for both condition
Junio C Hamano writes:
> Patch 2/2 also seems to share similar line-wrapping breakages that
> make it unappliable, but more importantly, the configuration that is
> supposed to correspond to --relative option only parses a boolean.
> Is that the right design, or should it also be able to substitu
Content-Type: text/plain; charset=utf-8; format=flowed
Please. No format=flawed. Really.
I'll figure out the line-wrapping.
Also this step is not about --no-relative and diff.relative but is only about
--no-relative option.
Should I submit as two independent patches then? I took the approac
This allows switching to some commit quickly.
Signed-off-by: Ismael Luceno
---
gitk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gitk b/gitk
index 78358a7..9552fd4 100755
--- a/gitk
+++ b/gitk
@@ -2561,6 +2561,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d "$ctext yvie
Philip Oakley writes:
> The assume-unchanged bit, and consequently core.ignoreStat, can be
> misunderstood. Be assertive about the expectation that file changes should
> notified to Git.
>
> Overhaul the general wording thus:
> 1. direct description of what is ignored given first.
> 2. ex
kel...@shysecurity.com writes:
> Content-Type: text/plain; charset=utf-8; format=flowed
Please. No format=flawed. Really.
> Subject: Re: [PATCH 1/2] support for --no-relative and diff.relative
"diff: teach --no-relative to override earlier --relative" or
something. Saying the affeced area up
On Tue, Jan 6, 2015 at 4:58 PM, Michael Paquier
wrote:
> Hi all,
>
> While toying with the tab completion script for bash, I found a couple
> of things missing that cannot be completed:
> - git config --includes
> - git config branch.$BRANCH_NAME.description
> Attached are trivial patches based on
Johan Herland writes:
> Have you looked at git show-branch --all?
>
> ...Johan
Yeah, sounds vaguely like it. Its display certainly is easier to
read while the set of branches you have is minimum and everything
fits in a window; that is exactly why I wrote it back when the
branches I was handlin
On 01/07/2015 04:47 PM, Johan Herland wrote:
> Have you looked at git show-branch --all?
I didn't. Helpful, but I need to get used to the output.
The first impression after looking at some random repository histories
is that it's still not what I had in mind, though.
--
To unsubscribe from this
Jeff King writes:
> ... Knowing what each state _means_
> and what operations are meaningful to perform is much trickier (e.g., if
> we are in a rebase, you probably do not want to start a new rebase. But
> is it wrong to cherry-pick?).
>
> It would be nice if we could find a way to generalize in
Johan Herland writes:
> Alternatively (or additionally), for issue (2), we could add a
> --disable-ref-safety option to 'git notes', to explicitly disable the
> safety checks for "experimental" use.
I actually would rather prefer to see a proper plumbing use
supported, either by a new "git notes
Jeff King writes:
> On Tue, Jan 06, 2015 at 02:20:33AM -0800, Junio C Hamano wrote:
>
>> The fact that "git notes merge refs/heads/master" fails is a very
>> good prevention of end-user mistakes, and this removal of test
>> demonstrates that we are dropping a valuable safety.
>
> Is it really tha
Have you looked at git show-branch --all?
...Johan
On Wed, Jan 7, 2015 at 3:23 PM, Yuri D'Elia wrote:
> Hi everyone,
>
> git log --graph is hard for me to parse mentally when developing a
> project which has a lot of branches.
>
> All the tools I've been using seem to just parse log --graph's ou
Hi everyone,
git log --graph is hard for me to parse mentally when developing a
project which has a lot of branches.
All the tools I've been using seem to just parse log --graph's output,
and thus are no better at showing history.
I would love to have a graph mode where each branch is assigned a
This option was added in 587947750bd73544 (not to be confused with
--autosquash).
Signed-off-by: Matthieu Moy
---
contrib/completion/git-completion.bash | 1 +
1 file changed, 1 insertion(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 2398
On Wed, Jan 7, 2015 at 2:17 AM, Junio C Hamano wrote:
> When I do a SQUASH???, I expect the original authors use it as a
> hint in their rerolls, but because this series has seen no comments
> so far (no interests???), I do not foresee or expect you to feel a
> need for rerolling at this point. I
On Tue, Jan 06, 2015 at 06:37:34PM +0100, Christian Couder wrote:
> On Tue, Jan 6, 2015 at 5:05 PM, Charles Rudolph
> wrote:
> > I am writing some higher level git commands for
> > https://github.com/Originate/git-town and would like some additional
> > plumbing commands that can tell me
> >
> >
56 matches
Mail list logo
