On Mon, Dec 29, 2014 at 11:08 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com 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
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com 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
reply to all instead of reply to Eric only.
On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine sunsh...@sunshineco.com 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
On Mon, Dec 29, 2014 at 11:46 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended.
This commit shortens execute_commands by moving some parts of the code
to extra functions.
Suggested-by:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com 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
On Tue, Dec 30, 2014 at 3:42 AM, Stefan Beller sbel...@google.com wrote:
On Mon, Dec 29, 2014 at 11:46 PM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended.
+static void
On Tue, Dec 30, 2014 at 3:33 AM, Stefan Beller sbel...@google.com wrote:
On Mon, Dec 29, 2014 at 11:08 PM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
Subject: receive-pack.c: add documentation for atomic push support
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 gits...@pobox.com @ 2014-12-30 00:50 QYZT:
Alexander Kuleshov
Alex Kuleshov kuleshovm...@gmail.com 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
Stefan Beller sbel...@google.com 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
Michael Haggerty mhag...@alum.mit.edu 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
Stefan Beller sbel...@google.com writes:
Signed-off-by: Stefan Beller sbel...@google.com
---
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
---
Sitaram Chamarty sitar...@gmail.com 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
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
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[=path] options.
---
Documentation/diff-config.txt | 1 +
Documentation/diff-options.txt | 4 +++
diff.c
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 mostly a
On Tue, Dec 30, 2014 at 9:33 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
Signed-off-by: Stefan Beller sbel...@google.com
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com 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
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
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 kel...@shysecurity.com
---
Documentation/diff-options.txt | 4
diff.c | 2 ++
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 kel...@shysecurity.com
---
Documentation/diff-config.txt |
On Tue, Dec 30, 2014 at 10:25 AM, Stefan Beller sbel...@google.com 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
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 12:12 PM, Robert Dailey
rcdailey.li...@gmail.com 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:
Robert Dailey rcdailey.li...@gmail.com 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
On Tue, Dec 30, 2014 at 1:45 PM, Stefan Beller sbel...@google.com wrote:
On Tue, Dec 30, 2014 at 12:36 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended.
Secondary information can be
On Mon, Dec 29, 2014 at 10:11 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Dec 29, 2014 at 9:36 PM, Stefan Beller sbel...@google.com wrote:
No functional changes intended.
This is useful to know but is of secondary importance, thus should be
placed after the explanation and
Robert Dailey rcdailey.li...@gmail.com 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
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 back to
Stefan Beller sbel...@google.com writes:
On Tue, Dec 30, 2014 at 9:33 AM, Junio C Hamano gits...@pobox.com wrote:
Stefan Beller sbel...@google.com writes:
Signed-off-by: Stefan Beller sbel...@google.com
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1
Michael Haggerty mhag...@alum.mit.edu 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 Tue, Dec 30, 2014 at 2:55 PM, Junio C Hamano gits...@pobox.com wrote:
Michael Haggerty mhag...@alum.mit.edu 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
On 12/30/2014 09:55 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu 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
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:
~$ git
On Tue, Dec 30, 2014 at 5:21 PM, Josh Bleecher Snyder
joshar...@gmail.com 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,
On Mon, Dec 29, 2014 at 06:48:48PM -0800, Stefan Beller wrote:
On Mon, Dec 29, 2014 at 6:47 PM, Stefan Beller sbel...@google.com wrote:
From: Eric Sunshine sunsh...@sunshineco.com
As I just copied the whole text of Eric, I think
it would be better if Eric is credited for this commit.
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
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
From: Ronnie Sahlberg sahlb...@google.com
Add a command line argument to the git push command to request atomic
pushes.
Signed-off-by: Ronnie Sahlberg sahlb...@google.com
Signed-off-by: Stefan Beller sbel...@google.com
---
Notes:
v8, v9:
no changes
v7:
Use OPT_BOOL
From: Ronnie Sahlberg sahlb...@google.com
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
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 sbel...@google.com
---
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
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.
From: Ronnie Sahlberg sahlb...@google.com
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
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 sbel...@google.com
---
Notes:
v9:
new and shiny. But makes the next patch easier to
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:
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
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 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
50 matches
Mail list logo
