Signed-off-by: Alex Henrie
---
builtin/remote.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 7f28f92..c55c7ce 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -13,7 +13,7 @@ static const char * const builtin_remote_usage[] =
On Wed, Dec 17, 2014 at 4:20 AM, Alex Henrie wrote:
> Signed-off-by: Alex Henrie
> ---
> builtin/remote.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/builtin/remote.c b/builtin/remote.c
> index 7f28f92..c55c7ce 100644
> --- a/builtin/remote.c
> +++ b/builtin/remote.c
On 11/25/2014 12:48 PM, Peter Wu wrote:
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for "update fetch URL and
leave whatever was in place for the push URL".
This patch adds support for a '--fetch' option which implements tha
Hi all,
I'm interested in putting in some time and effort into improving the
output of "git branch".
What I'm thinking is an output like this:
$ git branch
2014-12-17 * (detached from origin/master) deaba04 Do stuff
2014-12-15 john.ta/add_timing_info6edbcfa Add timing
John Tapsell schrieb am 17.12.2014 um 12:10:
> Hi all,
>
> I'm interested in putting in some time and effort into improving the
> output of "git branch".
>
> What I'm thinking is an output like this:
>
> $ git branch
>
> 2014-12-17 * (detached from origin/master) deaba04 Do stuff
> 2014
I don't fully understand - if I did that, then what difference would
an average user actually see?
On 17 December 2014 at 11:28, Michael J Gruber
wrote:
> John Tapsell schrieb am 17.12.2014 um 12:10:
>> Hi all,
>>
>> I'm interested in putting in some time and effort into improving the
>> outpu
Also, please don't top-post here.
That would allow everyone to get their favourite listing, just like for
logs.
John Tapsell schrieb am 17.12.2014 um 12:51:
> I don't fully understand - if I did that, then what difference would
> an average user actually see?
>
> On 17 December 2014 at 11:28, Mi
git remote set-url knew about the '--push' option to update just the
pushurl, but it does not have a similar option for "update fetch URL and
leave whatever was in place for the push URL".
This patch adds support for a '--fetch' option which implements that use
case in a backwards compatible way:
On Wednesday 17 December 2014 11:08:07 Torsten Bögershausen wrote:
> On 11/25/2014 12:48 PM, Peter Wu wrote:
> > git remote set-url knew about the '--push' option to update just the
> > pushurl, but it does not have a similar option for "update fetch URL and
> > leave whatever was in place for the
On Wed, Dec 17, 2014 at 03:20:58PM +0100, Peter Wu wrote:
> > There are 2 warning "dangling else", line 1570 and 1578
> > I think we should use:
> >
> > for (i = 0; i < remote->pushurl_nr; i++) {
> > if (!regexec(&old_regex, remote->pushurl[i], 0,
On Wed, Dec 17, 2014 at 03:18:56PM +0100, Peter Wu wrote:
> This is the fourth revision of the patch that allows for just setting the
> fetch
> URL. Eric wondered why '--fetch --push' is not used to describe the state
> '--both', so I added this to the commit message.
Thanks, I think that explan
On Wednesday 17 December 2014 09:32:13 Jeff King wrote:
> On Wed, Dec 17, 2014 at 03:18:56PM +0100, Peter Wu wrote:
>
> > This is the fourth revision of the patch that allows for just setting the
> > fetch
> > URL. Eric wondered why '--fetch --push' is not used to describe the state
> > '--both',
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 little disruption
as possible to existing clients. It is unknown if
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:
Changes in v3
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
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
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
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[2].
Changes v3->v3 are annotated in each patch.
[2] https://github.com/stefanbeller/git/tree/atomic-push-v3
Ronnie Sahlberg (4):
John Tapsell writes:
> I'm interested in putting in some time and effort into improving the
> output of "git branch".
>
> What I'm thinking is an output like this:
>
> $ git branch
>
> 2014-12-17 * (detached from origin/master) deaba04 Do stuff
> 2014-12-15 john.ta/add_timing_info
Michael J Gruber writes:
> Rather than extending "git branch" any further[*], I suggest a bolder
> strategy:
>
> - unify/merge for-each-ref and pretty formats (and code) as far as possible
> - leverage that for the list modes of branch and tag
>
> That would allow everyone to get their favourite
On Wed, Dec 17, 2014 at 12:53:49PM -0800, Junio C Hamano wrote:
> Michael J Gruber writes:
>
> > Rather than extending "git branch" any further[*], I suggest a bolder
> > strategy:
> >
> > - unify/merge for-each-ref and pretty formats (and code) as far as possible
> > - leverage that for the lis
I am not sure if there was any improvement since then, but Junio
wrote about alternates 2 years ago
http://git-blame.blogspot.com/2012/08/bringing-bit-more-sanity-to-alternates.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.o
=-O
--
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
Peter Wu writes:
> git remote set-url knew about the '--push' option to update just the
> pushurl, but it does not have a similar option for "update fetch URL and
> leave whatever was in place for the push URL".
>
> This patch adds support for a '--fetch' option which implements that use
> case i
(+cc: Duy who wrote the recent 'checkout --to' patch series)
Hi Craig,
Craig Silverstein wrote:
> By design, our Jenkins machine has several different
> directories that each hold a copy of the same git repository. (For
> instance, Jenkins may be running tests on our repo at several
> d
Eric Sunshine writes:
> These Apple-specific warnings are pure noise: they don't tell us
> anything useful and we have no control over them, nor is Apple likely to
> provide replacements any time soon. Such noise may obscure other
> legitimate warnings, therefore silence them.
Sad but it appears
Stefan Beller writes:
> 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_STA
Stefan Beller writes:
> 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.
Looks sensible. Thanks.
--
To unsubscribe from this list: send the line "unsubscr
On Tue, Dec 16, 2014 at 11:46 AM, Junio C Hamano wrote:
>> + (
>> + cd upstream && git config receive.denyCurrentBranch warn
>> + ) &&
>
> I was wondering how you would do this part after suggesting use of
> test_create_repo, knowing very well that one of them was a bare one
>
Stefan Beller writes:
> @@ -1086,8 +1100,25 @@ static void execute_commands(struct command *commands,
>
> if (cmd->skip_update)
> continue;
> -
> + if (!use_atomic) {
> + transaction = ref_transaction_begin(&err);
> +
Stefan Beller writes:
> On Tue, Dec 16, 2014 at 11:46 AM, Junio C Hamano wrote:
>
>>> + (
>>> + cd upstream && git config receive.denyCurrentBranch warn
>>> + ) &&
>>
>> I was wondering how you would do this part after suggesting use of
>> test_create_repo, knowing very well
On Wed, Dec 17, 2014 at 2:32 PM, Jonathan Nieder wrote:
> You might find 'git new-workdir' from contrib/workdir to be helpful.
> It lets you attach multiple working copies to a single set of objects
> and refs.
Thanks! That does indeed sound promising -- like a more principled
version of my GIT_
On Wed, Dec 17, 2014 at 3:26 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> @@ -1086,8 +1100,25 @@ static void execute_commands(struct command *commands,
>>
>> if (cmd->skip_update)
>> continue;
>> -
>> + if (!use_atomic) {
>> +
Craig Silverstein wrote:
> On Wed, Dec 17, 2014 at 2:32 PM, Jonathan Nieder wrote:
>> Craig Silverstein wrote:
>>> Question 4) Is there a practical way to set up submodules so they can
>>> use the same object-sharing framework that the main repo does?
>>
>> It's possible to do, but we haven't wri
On Wed, Dec 17, 2014 at 3:51 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> On Tue, Dec 16, 2014 at 11:46 AM, Junio C Hamano wrote:
>>
+ (
+ cd upstream && git config receive.denyCurrentBranch warn
+ ) &&
>>>
>>> I was wondering how you would do this pa
Junio C Hamano wrote:
> The issue is if some existing tests will be helped, if we had such a
> helper.
Since both bin-wrappers/git and test-lib.sh set GIT_TEMPLATE_DIR and
templates/blt doesn't contain any enabled hooks, I don't see how such
a helper would be useful.
If making things more consis
This adds an explanation of why you want to have the --notes option
given to git format-patch.
Signed-off-by: Stefan Beller
---
Notes:
> with optionally update Documentation/SubmittingPatches
> to point at the file.
That file actually talks about notes already. I am sending
The Developers Certificate of Origin has a mixture of tabs and white
spaces which is annoying to view if your editor explicitly views white
space characters.
Signed-off-by: Stefan Beller
---
Notes:
I'll also try to send it upstream to linux.
Documentation/SubmittingPatches | 12 ++-
The Developers Certificate of Origin has a mixture of tabs and white
spaces which is annoying to view if your editor explicitly views white
space characters.
Signed-off-by: Stefan Beller
---
Documentation/SubmittingPatches | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff
The situation is actually slightly more complex than I stated previously. From
the docs:
The exit value of this program is negative on error,
But there’s no such thing as a negative error code under Unix, so (at best)
that will be exit(255).
No patch, because this is getting painfully close t
41 matches
Mail list logo
