On Tue, Dec 30, 2014 at 08:42:09PM -0500, Jeff King wrote:
> Both should be pretty trivial. This approach seems conceptually cleaner
> to me, though it does mean you could not specify a bearer via the
> terminal prompt for a password (e.g., by cutting and pasting from
> elsewhere). I don't know if
On Tue, Dec 30, 2014 at 11:56:11PM +, brian m. carlson wrote:
> On Tue, Dec 30, 2014 at 11:24:09AM -0800, David Renshaw wrote:
> > Hi,
> > I would like to be able to serve a git repository over HTTPS from a
> > web server that requires OAuth2-style bearer tokens for authorization.
> > For more
On Tue, Dec 30, 2014 at 03:39:53PM -0600, Robert Dailey wrote:
> It also feels like there should be a
> shorthand for the `git log` usage in conjunction with `git show`... I
> could probably make an alias for it.
One thing I didn't see mentioned in this thread is that the question
"show me the co
On Tue, Dec 30, 2014 at 11:24:09AM -0800, David Renshaw wrote:
> Hi,
> I would like to be able to serve a git repository over HTTPS from a
> web server that requires OAuth2-style bearer tokens for authorization.
> For more context, see this thread:
> https://groups.google.com/forum/#!topic/sandstor
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:
v9:
add
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
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 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:
v9:
new and shiny. But makes the next patch easier to review.
builtin/re
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:
v8, v9:
no changes
v7:
Use OPT_BOOL instead of OPT_BIT.
This allows for --no-atomic optio
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
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 commit shortens execute_commands loop over all commands by moving
some parts of the code to extra functions. This will help us in a later
patch to avoid duplicate code when the loop over all commands should be
made atomic or not.
No functional changes intended.
Suggested-by: Eric Sunshine
S
This patch series adds a flag to git push to update the remote refs atomically.
All comments from Eric and Junio have been incorporated.
The patch to negotiate the atomic push protocol was ripped apart
and we have one commit for the receiving side and one for the sending side,
so the order of new
On Mon, Dec 29, 2014 at 06:48:48PM -0800, Stefan Beller wrote:
> On Mon, Dec 29, 2014 at 6:47 PM, Stefan Beller wrote:
> > From: Eric Sunshine
>
> As I just copied the whole text of Eric, I think
> it would be better if Eric is credited for this commit.
>
> Eric,
> I already added your sign off
On Tue, Dec 30, 2014 at 5:21 PM, Josh Bleecher Snyder
wrote:
> In the section on using --temp, 'git help checkout-index' says:
>
> "The path field is always relative to the current directory and the
> temporary file names are always relative to the top level directory."
>
> However, this can be fa
In the section on using --temp, 'git help checkout-index' says:
"The path field is always relative to the current directory and the
temporary file names are always relative to the top level directory."
However, this can be false when an absolute path to the file is provided.
Reproduction:
~$ gi
On 12/30/2014 09:55 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> There is yet a third similar question: "What is the last commit that is
>> currently on the master branch that was *authored* at least one year
>> ago? Please note that this question is even subtler, because author
>> t
On Tue, Dec 30, 2014 at 2:55 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> There is yet a third similar question: "What is the last commit that is
>> currently on the master branch that was *authored* at least one year
>> ago? Please note that this question is even subtler, because au
On Tue, Dec 30, 2014 at 3:33 PM, Stefan Beller wrote:
> On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine
> wrote:
>> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>>> +static int should_process_cmd(struct command *cmd)
>>> +{
>>> + if (cmd->error_string)
>>> + return
Michael Haggerty writes:
> There is yet a third similar question: "What is the last commit that is
> currently on the master branch that was *authored* at least one year
> ago? Please note that this question is even subtler, because author
> timestamps are often out-of-order even on a single bran
Stefan Beller writes:
> On Tue, Dec 30, 2014 at 9:33 AM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> Signed-off-by: Stefan Beller
>>> ---
>>> Documentation/git-rebase.txt | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/Documentation/git-rebase.txt b/
On 12/30/2014 09:12 PM, Robert Dailey wrote:
> I was surprised to find today that the following didn't work as expected:
>
> $ git show master@{"1 year ago"}:Path/To/File.h
>
> It gave me the following warning which did not make the problem obvious at
> all:
> warning: Log for 'master' only goes
Robert Dailey writes:
> ... how can I view the
> contents of a file at a specified relative time frame ...
"git log --until=A --since=B master" asks Git to start traversing
the history backward from the tip of your current 'master' branch,
without showing anything until it finds a commit with ti
On Tue, Dec 30, 2014 at 1:45 PM, Stefan Beller wrote:
> On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine
> wrote:
>> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>>> No functional changes intended.
>>
>> Secondary information can be demoted to the end of the commit message.
>
> I think
On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine wrote:
> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>> No functional changes intended.
>
> This is useful to know but is of secondary importance, thus should be
> placed after the explanation and justification of the change.
>
>> Subject:
Robert Dailey writes:
> I was surprised to find today that the following didn't work as expected:
>
> $ git show master@{"1 year ago"}:Path/To/File.h
>
> It gave me the following warning which did not make the problem obvious at
> all:
> warning: Log for 'master' only goes back to Mon, 8 Sep 201
On Tue, Dec 30, 2014 at 12:12 PM, Robert Dailey
wrote:
> I was surprised to find today that the following didn't work as expected:
>
> $ git show master@{"1 year ago"}:Path/To/File.h
>
> It gave me the following warning which did not make the problem obvious at
> all:
> warning: Log for 'master'
I was surprised to find today that the following didn't work as expected:
$ git show master@{"1 year ago"}:Path/To/File.h
It gave me the following warning which did not make the problem obvious at all:
warning: Log for 'master' only goes back to Mon, 8 Sep 2014 12:08:44 -0500.
What it is trying
On Tue, Dec 30, 2014 at 10:25 AM, Stefan Beller wrote:
> Should this be s/current/previous/. Technically the current commit seems
> correct to me, but it was crafted in the previous lines of the instruction
> sheet
> so it feels like it's a commit which is already done and we're
> currently looki
added --no-relative option for git-diff (code, documentation, and tests)
--no-relative overrides --relative causing a return to standard behavior
Signed-off-by: Brandon Phillips
---
Documentation/diff-options.txt | 4
diff.c | 2 ++
t/t4045-diff-relative.sh
added diff.relative setting for git-diff (code, documentation, and tests)
`git-config diff.relative=true` causes `git diff` to behave like `git
diff --relative`. Overridden by `git diff --no-relative`.
Signed-off-by: Brandon Phillips
---
Documentation/diff-config.txt | 6 ++
diff.c
Hi,
I would like to be able to serve a git repository over HTTPS from a
web server that requires OAuth2-style bearer tokens for authorization.
For more context, see this thread:
https://groups.google.com/forum/#!topic/sandstorm-dev/4oigfb4-9E4
Does anyone here have any advice about how to convince
On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine wrote:
> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>> Subject: receive-pack.c: move transaction handling in a central place
>
> This is very generic, and doesn't really explain what this patch is
> about. (See below.)
>
>> No functional
On Tue, Dec 30, 2014 at 9:33 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Signed-off-by: Stefan Beller
>> ---
>> Documentation/git-rebase.txt | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
>> in
kel...@shysecurity.com writes:
> By default, git-diff shows changes and pathnames relative to the
> repository root.
> Setting diff.relative to "true" shows pathnames relative to the
> current directory
> and excludes changes outside this directory.
The above does not tell any lie, but it is most
added support for `git diff --no-relative` (code, documentation, and tests)
git-diff --no-relative overrides diff.relative config setting and prior
git-diff --relative[=] options.
---
Documentation/diff-config.txt | 1 +
Documentation/diff-options.txt | 4 +++
diff.c
By default, git-diff shows changes and pathnames relative to the
repository root.
Setting diff.relative to "true" shows pathnames relative to the current
directory
and excludes changes outside this directory.
---
Documentation/diff-config.txt | 5 +
diff.c| 8 +
Sitaram Chamarty writes:
> Just wanted to say there's a little script at [1] that saves the certificate
> blobs generated on the server side by "git push --signed".
>
> Quoting from the source:
>
> # Collects the cert blob on push and saves it, then, if a certain number of
> # signed pushes have
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> Documentation/git-rebase.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index 924827d..ffadb0b 100644
> --- a/Documentation/git-rebase.txt
>
Michael Haggerty writes:
> If I understand correctly, after this patch the server advertises the
> "atomic" capability even though it doesn't actually have that ability
> until a later patch. It seems to me that the order of the patches should
> be reversed: don't advertise the capability before
Stefan Beller writes:
>>> +can also be inserted using the `--notes` option. If you are one
>>> +of those developers who cannot write perfect code the first time
>>> +and need multiple iterations of review and discussion, you may
>>> +want to keep track of the changes between different versions of
Alex Kuleshov writes:
> What's about output like this:
>
> Unable to initialize SMTP properly. Check config and use --smtp-debug.
>
> VALUES:
> server=smtp.gmail.com
> encryption=
> hello=localhost.localdomain
> port=587
Hmmm, maybe I am being slow but what's about it? I
"Philip Oakley" writes:
> From: "Junio C Hamano"
>
>> * po/doc-core-ignorestat (2014-12-12) 1 commit
>> (merged to 'next' on 2014-12-23 at d2b3e84)
>> + doc: core.ignoreStat clarify the --assume-unchanged effect
>>
>> Will merge to 'master'.
>>
> I was hoping to re-roll but family Christmas / N
What's about output like this:
Unable to initialize SMTP properly. Check config and use --smtp-debug.
VALUES:
server=smtp.gmail.com
encryption=
hello=localhost.localdomain
port=587
Junio C Hamano @ 2014-12-30 00:50 QYZT:
> Alexander Kuleshov writes:
>
>> Signed
On Tue, Dec 30, 2014 at 3:33 AM, Stefan Beller wrote:
> On Mon, Dec 29, 2014 at 11:08 PM, Eric Sunshine
> wrote:
>> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>>> Subject: receive-pack.c: add documentation for atomic push support
>> When Michael raised the issue of the server being "
On Tue, Dec 30, 2014 at 3:42 AM, Stefan Beller wrote:
> On Mon, Dec 29, 2014 at 11:46 PM, Eric Sunshine
> wrote:
>> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>>> No functional changes intended.
>>> +static void check_shallow_bugs(struct command *commands,
>>> +
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
> Update receive-pack to use an atomic transaction iff the client negotiated
> that it wanted atomic push.
This first line seems germane to this patch...
> This leaves the default behavior to be the old
> non-atomic one ref at a time update.
On Mon, Dec 29, 2014 at 11:46 PM, Eric Sunshine wrote:
> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>> No functional changes intended.
>>
>> This commit shortens execute_commands by moving some parts of the code
>> to extra functions.
>>
>> Suggested-by: Eric Sunshine
>> Signed-off-by
reply to all instead of reply to Eric only.
On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine wrote:
> In v6, you considered this a fatal error in the atomic case, which
> caused the entire transaction to be rolled back. However, in this
> version, this error has no effect whatsoever on the atomic
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
> Subject: receive-pack.c: move transaction handling in a central place
This is very generic, and doesn't really explain what this patch is
about. (See below.)
> No functional changes intended.
Secondary information can be demoted to the end
On Mon, Dec 29, 2014 at 11:08 PM, Eric Sunshine wrote:
> On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller wrote:
>> Subject: receive-pack.c: add documentation for atomic push support
>
> This patch is doing a lot more than merely adding documentation. It's
> also updating send-pack and receive-pack
52 matches
Mail list logo
