Stefan Beller writes:
> A race condition may be a serious objection then? Once people believe the
> refs can scale fairly well they will use it, which means blasting the ref
> advertisement will become very worse over time.
I think we are already in agreement about that case:
A misdetected
bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-return-to-sanity
--
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
David Lang writes:
> how would these approaches be affected by a client that is pulling
> from different remotes into one local repository? For example, pulling
> from the main kernel repo and from the -stable repo.
>
> David Lang
As I said in $gmane/264000, which the above came from:
Note
Johannes Sixt writes:
> You may also consider an idea I proposed here:
>
> http://thread.gmane.org/gmane.comp.version-control.git/206886/focus=207342
>
> The idea is that the exchange begins as usual, but when the v2 client
> sees that the server also supports v2, then it begins sending its
> des
On Sun, 1 Mar 2015, Junio C Hamano wrote:
and if the only time your refs/remotes/origin/* hierarchy changes is
when you fetch from there (which should be the norm), you can look
into remote.origin.fetch refspec (to learn that "refs/heads*" is
what you are asking) and your refs/remotes/origin/* r
On Sun, 1 Mar 2015, Stefan Beller wrote:
The way I understand Junio here is to have predefined points which
makes it easier to communicate. There are lots of clients and they usually
want to catch up a different amount of commits, so we need to recompute it
all the time. The idea is then to comp
Hi,
Quoting Mårten Kongstad :
On Sun, Mar 01, 2015 at 11:25:53AM +0100, Torsten Bögershausen wrote:
On 2015-03-01 08.39, Mårten Kongstad wrote:
[]
+test_expect_success '--shortstat --dirstat should output only
one dirstat' '
+ git diff --shortstat --dirstat=changes HEAD^..HEAD
actual
On Mon, Nov 10, 2014 at 12:20:02AM +0200, Max Kirillov wrote:
> If several gitk instances are closed simultaneously, safestuff procedure
> can run at the same time, resulting in a conflict which may cause losing
> of some of the instance's changes, failing the saving operation or even
> corrupting
On Mon, Nov 10, 2014 at 12:20:01AM +0200, Max Kirillov wrote:
> When gitk contains some changed parameter, and there is existing
> instance of gitk where the parameter is still old, it is reverted to
> that old value when the instance exits.
>
> Instead, store a parameter in config only it is has
On Sun, Mar 1, 2015 at 1:48 AM, Alexander Kuleshov
wrote:
> 'was_alias' variable does not need to store it's value each iteration in the
> loop, anyway this variable changes it's value with run_argv. So it does not
> need to be static.
>
> Signed-off-by: Alexander Kuleshov
> ---
> git.c | 2 +-
>
Trevor Saunders writes:
>> ... For these "per-invocation" differences, attributes
>> to declare permenent/inherent nature of the contents is much less
>> suited than per-invocation inclusion/exclusion mechanism based on
>> pathspecs, I would think.
>
> I think that makes some amount of sense, ho
Duy Nguyen writes:
> On Sun, Mar 1, 2015 at 3:41 PM, Junio C Hamano wrote:
>>> - Because the protocol exchange starts by the server side
>>>advertising all its refs, even when the fetcher is interested in
>>>a single ref, the initial overhead is nontrivial, especially when
>>>you ar
From: "Junio C Hamano"
I earlier said:
So if we are going to discuss a new protocol, I'd prefer to see the
discussion without worrying too much about how to inter-operate
with the current vintage of Git. It is no longer an interesting
problem,
as we know how to solve it with minimum risk. In
On Sun, Mar 1, 2015 at 3:32 AM, Duy Nguyen wrote:
> On Sun, Mar 1, 2015 at 3:41 PM, Junio C Hamano wrote:
>>> - Because the protocol exchange starts by the server side
>>>advertising all its refs, even when the fetcher is interested in
>>>a single ref, the initial overhead is nontrivial,
Stefan Beller writes:
> So maybe you create a bash alias for
> alias gitup='git push origin HEAD:${USER}/$(date -Iseconds)'
> which would push your current tip of the repository to the remote with
> quite a unique name.
>
> Then you could also do a "git commit -a && gitup" to push your changes
>
Mårten Kongstad venit, vidit, dixit 01.03.2015 17:01:
> On Sun, Mar 01, 2015 at 03:23:37PM +0100, Michael J Gruber wrote:
> []
>> If I would have had to guess from the documentation: What does "git diff
>> --dirstat --shortstat" do? I would have answered: It displays both the
>> dirstat and the sho
On Sun, Mar 01, 2015 at 03:23:37PM +0100, Michael J Gruber wrote:
[]
> If I would have had to guess from the documentation: What does "git diff
> --dirstat --shortstat" do? I would have answered: It displays both the
> dirstat and the shortstat.
>
> So, is what you are trying to "fix" a peculiarit
On Sun, Mar 01, 2015 at 11:25:53AM +0100, Torsten Bögershausen wrote:
> On 2015-03-01 08.39, Mårten Kongstad wrote:
> []
> > +test_expect_success '--shortstat --dirstat should output only one dirstat'
> > '
> > + git diff --shortstat --dirstat=changes HEAD^..HEAD
> > >actual_diff_shortstat_dirs
Torsten Bögershausen venit, vidit, dixit 01.03.2015 11:25:
> On 2015-03-01 08.39, Mårten Kongstad wrote:
> []
> index ed7e093..128f7bf 100755
>> --- a/t/t4047-diff-dirstat.sh
>> +++ b/t/t4047-diff-dirstat.sh
>> @@ -973,4 +973,15 @@ test_expect_success 'diff.dirstat=future_param,0,lines
>> should
On Sat, Feb 28, 2015 at 07:06:16PM -0800, Junio C Hamano wrote:
> Trevor Saunders writes:
>
> > There have been cases where I wanted grep to always ignore certain
> > files, but to still get text diffs for those files. One case is people
> > insist on using ChangeLog files, and another is peo
For translators, specify that a y/N reply is needed.
Signed-off-by: Jean-Noel Avila
---
builtin/clean.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/builtin/clean.c b/builtin/clean.c
index 7e7fdcf..98c103f 100644
--- a/builtin/clean.c
+++ b/builtin/clean.c
@@ -754,7 +75
On Sun, Mar 1, 2015 at 3:41 PM, Junio C Hamano wrote:
>> - Because the protocol exchange starts by the server side
>>advertising all its refs, even when the fetcher is interested in
>>a single ref, the initial overhead is nontrivial, especially when
>>you are doing a small incremental
On 2015-03-01 08.39, Mårten Kongstad wrote:
[]
index ed7e093..128f7bf 100755
> --- a/t/t4047-diff-dirstat.sh
> +++ b/t/t4047-diff-dirstat.sh
> @@ -973,4 +973,15 @@ test_expect_success 'diff.dirstat=future_param,0,lines
> should warn, but still wo
> test_i18ngrep -q "diff\\.dirstat" actual_e
Am 28.02.2015 um 02:01 schrieb Stefan Beller:
Heavily inspired by the ideas of Duy, who wrote the first
patches nearly a year ago.
Nguyễn Thái Ngọc Duy (2):
upload-pack: only accept capabilities on the first "want" line
upload-pack: support out of band client capability requests
Stefan Be
I earlier said:
> So if we are going to discuss a new protocol, I'd prefer to see the
> discussion without worrying too much about how to inter-operate
> with the current vintage of Git. It is no longer an interesting problem,
> as we know how to solve it with minimum risk. Instead, I'd like to
>
25 matches
Mail list logo
