Junio C Hamano writes:
> Christian Couder writes:
>
>> Users replacing an object with one of a different type were not
>> prevented to do so, even if it was obvious, and stated in the doc,
>> that bad things would result from doing that.
>>
>> To avoid mistakes, it is better to just forbid that
Hi,
I think I understand what's going on. If there are no net changes in one
of the two branches, the id of the merge commit will be the same as that
of the last commit on the other branch (pass the -d option to 'git subtree
split' to see the new commit id's of the split out commits). In th
Historically, "git status" needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when "git status" is ran from the
command-line, and this may distract users from the real content.
Allow the user to dis
Hi Ron,
On 28/08/13 03:10, Ron Tregaskis - NOAA Federal wrote:
> Does git work with Eclipse?
>
> Ron
> --
Eclipse does have git integration courtesy of the EGit plugin. At
$dayjob most of us are running eclipse 3.7 a.k.a "Indigo". When we
started with an earlier eclipse version we had to instal
Am 8/28/2013 10:32, schrieb Matthieu Moy:
> Historically, "git status" needed to prefix each output line with '#' so
> that the output could be added as comment to the commit message. This
> prefix comment has no real purpose when "git status" is ran from the
> command-line, and this may distract u
ttn/Dear
Contact Western union offfice with your name,Adres,City,Country,phone
no
and ur ID,for your $10.5m comenstion,Mr. Frank Edward
Email:
(uw...@yahoo.fr)+229 68035435
but note that you will be receiving $20,000 usd everyday
until your $10.5M completed transferred to you
Regards
Dr JOHNSON
Johannes Sixt writes:
> How does your solution work when dirty submodules are involved and
> submodule status is included?f
Badly ;-).
I didn't notice the subcommand call for submodules summary. It's a bit
more tricky to get right, as the "git sumbodule summary --for-status"
call did not know w
Signed-off-by: Matthieu Moy
---
I normally don't like whitespace-only patches, but the indentation was
seriously broken here.
Can safely be dropped.
builtin/stripspace.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index
Signed-off-by: Matthieu Moy
---
(--for-status was undocumented, so I didn't bother documenting this either)
git-submodule.sh | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..ac0fdad 100755
--- a/git-submo
Historically, "git status" needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when "git status" is ran from the
command-line, and this may distract users from the real content.
Allow the user to dis
Hi Nguy,
On Fri, Aug 16, 2013 at 04:52:05PM +0700, Nguyễn Thái Ngọc Duy wrote:
> upload-pack has a special rev walking code for shallow recipients. It
> works almost like the similar code in pack-objects except:
>
> 1. in upload-pack, graft points could be added for deepening
>
> 2. also when th
Hi Duy,
> I thought a bit but my thoughts often get stuck if I don't write them
> down in form of code :-) so this is what I got so far. 4/6 is a good
> thing in my opinion, but I might overlook something 6/6 is about this
> thread.
The series looks good to me, though I don't know enough about t
On Mon, Aug 26, 2013 at 09:47:56AM -0400, Corey Thompson wrote:
> You are correct that git-fast-import is killed by the OOM killer, but I
> was unclear about which process was malloc()ing so much memory that the
> OOM killer got invoked (as other completely unrelated processes usually
> also get ki
This is a testcase that checks for a problem where, during a specific
shallow fetch where the client does not have any commits that are a
successor of the new shallow root (i.e., the fetch creates a new
detached piece of history), the server would simply send over _all_
objects, instead of taking i
> From: Junio C Hamano
>
> > I've noticed that Git by default puts long output through "less" as a
> > pager. I don't like that, but this is not the time to change
> > established behavior. But while tracking that down, I noticed that
> > the paging behavior is controlled by at least 5 things:
Sparse issues an "'prepare_transport' was not declared. Should it
be static?" warning. In order to suppress the warning, since this
symbol only requires file scope, we simply add the static modifier
to it's declaration.
Signed-off-by: Ramsay Jones
---
Hi Junio,
When you re-build the next branc
Felipe Contreras (8):
remote-bzr: fix export of utf-8 authors
remote-bzr: make bzr branches configurable per-repo
remote-hg: fix test
remote-hg: add missing &&s in the test
remote-hg: improve basic test
remote-helpers: trivial style fixes
remote-helpers: cleanup more global variables
Different repositories have different branches, some are are even
branches themselves.
Reported-by: Peter Niederlag
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers
It wasn't being checked properly before; those refs never existed.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg.sh | 2 --
1 file changed, 2 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index f7ce8aa..cbf8617 100755
--- a
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index cbf8617..94b0bba 100755
--- a/contrib/remote-helpers/test-hg.sh
+++ b/contrib/
In accordance with pep8.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 4 ++--
contrib/remote-helpers/git-remote-hg | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/git-remote-bzr
It appears 'let' is not present in all shells.
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/test-hg.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 94b0bba..5a6f745 100755
--- a/
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-hg | 33 -
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 307d82c..0dbda75 100755
--- a/contrib/r
They don't need to be specified if they are not going to be set.
Suggested-by: Dusty Phillips
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 29 -
contrib/remote-helpers/git-remote-hg | 30 ++
2 files changed,
Reported-by: Joakim Verona
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 1 +
contrib/remote-helpers/test-bzr.sh| 30 ++
2 files changed, 31 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/
Thomas Rast writes:
> Hrm, you're right, that's a flaw in my logic. You could do the same in
> all other cases too, e.g. replace a tree so that an entry is of a
> different type and at the same time change the type of the object
> itself. You however have to carefully go through all objects tha
Jeff King writes:
> This makes the code simpler and shorter (because we don't
> have to correlate strchrnul with the length calculation),
> correct (because the code with the off-by-one just goes
> away), and more efficient (we can drop the extra allocation
> we needed to create NUL-terminated st
Matthieu Moy writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ec57a15..dacf4b9 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2118,6 +2118,11 @@ status.branch::
> Set to true to enable --branch by default in linkgit:git-statu
Felipe Contreras writes:
> + echo greg >> content &&
> + git add content &&
> + git commit -m one
test_commit would make it shorter.
> + bzr log | grep "^committer: " > ../actual
> + ) &&
> +
> + echo "committer: Grégoire " > expected &&
Git's source code usually says >
Junio C Hamano writes:
> "status.omitCommentPrefix" that defaults to false might be a better
> setting, I suspect.
Or status.showCommentPrefix that defaults to true; I didn't mean to
say a setting that defaults to false is preferred over one that
defaults to true in my message.
--
To unsubscribe
wor...@alum.mit.edu (Dale R. Worley) writes:
>> From: Junio C Hamano
>>
>> > I've noticed that Git by default puts long output through "less" as a
>> > pager. I don't like that, but this is not the time to change
>> > established behavior. But while tracking that down, I noticed that
>> > the
On Wed, Aug 28, 2013 at 3:23 PM, Felipe Contreras
wrote:
> Reported-by: Joakim Verona
> Signed-off-by: Felipe Contreras
> ---
> contrib/remote-helpers/git-remote-bzr | 1 +
> contrib/remote-helpers/test-bzr.sh| 30 ++
> 2 files changed, 31 insertions(+)
>
> diff
On Wed, Aug 28, 2013 at 01:05:38PM -0700, Junio C Hamano wrote:
> What are our plans to help existing scripts people have written over
> time, especially before "status -s" was invented, that will be
> broken by use of this?
I thought that our response to parsing the long output of "git status"
w
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> + echo greg >> content &&
>> + git add content &&
>> + git commit -m one
>
> test_commit would make it shorter.
And it would make it inconsistent with the rest of the script.
>> + bzr log | grep
On Wed, Aug 28, 2013 at 10:48 PM, Felipe Contreras
wrote:
> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
> wrote:
>> Felipe Contreras writes:
>>
>>> + echo greg >> content &&
>>> + git add content &&
>>> + git commit -m one
>>
>> test_commit would make it shorter.
>
> And it would m
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>> index ec57a15..dacf4b9 100644
>> --- a/Documentation/config.txt
>> +++ b/Documentation/config.txt
>> @@ -2118,6 +2118,11 @@ status.branch::
>> Set to true to enable --branc
Felipe Contreras writes:
> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
> wrote:
>
>>> + bzr log | grep "^committer: " > ../actual
>>> + ) &&
>>> +
>>> + echo "committer: Grégoire " > expected &&
>>
>> Git's source code usually says >../actual and >expected, without space
>> after '
Am 28.08.2013 14:47, schrieb Matthieu Moy:
> Signed-off-by: Matthieu Moy
> ---
> (--for-status was undocumented, so I didn't bother documenting this either)
That's fine, as both if these options will - hopefully - only be used
by wt-status.c internally.
But I'm not terribly happy about having th
Reported-by: Joakim Verona
Signed-off-by: Felipe Contreras
---
contrib/remote-helpers/git-remote-bzr | 1 +
contrib/remote-helpers/test-bzr.sh| 30 ++
2 files changed, 31 insertions(+)
diff --git a/contrib/remote-helpers/git-remote-bzr
b/contrib/remote-helpers/
On Wed, Aug 28, 2013 at 3:54 PM, Antoine Pelisse wrote:
> On Wed, Aug 28, 2013 at 10:48 PM, Felipe Contreras
> wrote:
>> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
>> wrote:
>>> Felipe Contreras writes:
>>>
+ echo greg >> content &&
+ git add content &&
+ git commi
On Wed, Aug 28, 2013 at 4:05 PM, Matthieu Moy
wrote:
> Felipe Contreras writes:
>
>> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
>> wrote:
>>
+ bzr log | grep "^committer: " > ../actual
+ ) &&
+
+ echo "committer: Grégoire " > expected &&
>>>
>>> Git's source co
On Wed, Aug 28, 2013 at 4:21 PM, Felipe Contreras
wrote:
> On Wed, Aug 28, 2013 at 3:54 PM, Antoine Pelisse wrote:
>> On Wed, Aug 28, 2013 at 10:48 PM, Felipe Contreras
>> wrote:
>>> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
>>> wrote:
Felipe Contreras writes:
> + echo gr
Jeff King writes:
> On Wed, Aug 28, 2013 at 01:05:38PM -0700, Junio C Hamano wrote:
>
>> What are our plans to help existing scripts people have written over
>> time, especially before "status -s" was invented, that will be
>> broken by use of this?
>
> I thought that our response to parsing the
Matthieu Moy writes:
> diff --git a/wt-status.c b/wt-status.c
> index cb24f1f..97068d5 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -774,12 +778,21 @@ static void wt_status_print_tracking(struct wt_status
> *s)
> if (!format_tracking_info(branch, &sb))
> return;
>
>
Matthieu Moy writes:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> diff --git a/Documentation/config.txt b/Documentation/config.txt
>>> index ec57a15..dacf4b9 100644
>>> --- a/Documentation/config.txt
>>> +++ b/Documentation/config.txt
>>> @@ -2118,6 +2118,11 @@ status.branch::
>>>
Matthieu Moy writes:
> Felipe Contreras writes:
>
>> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
>> wrote:
>>
+ bzr log | grep "^committer: " > ../actual
+ ) &&
+
+ echo "committer: Grégoire " > expected &&
>>>
>>> Git's source code usually says >../actual and
On Wed, Aug 28, 2013 at 2:39 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Wed, Aug 28, 2013 at 01:05:38PM -0700, Junio C Hamano wrote:
>>
>>> What are our plans to help existing scripts people have written over
>>> time, especially before "status -s" was invented, that will be
>>> broken
wor...@alum.mit.edu (Dale R. Worley) writes:
>> For now, I'll queue your version as-is modulo style fixes, while
>> waiting for others to help polishing the documentation better.
>
> It'd difficult to figure out how to describe it well. In my
> opinion, the problem here is the DWIM nature of the
On Wed, Aug 28, 2013 at 4:58 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Felipe Contreras writes:
>>
>>> On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
>>> wrote:
>>>
> + bzr log | grep "^committer: " > ../actual
> + ) &&
> +
> + echo "committer: Grégoire "
David Aguilar writes:
> On Wed, Aug 28, 2013 at 2:39 PM, Junio C Hamano wrote:
>> Jeff King writes:
>>
>>> On Wed, Aug 28, 2013 at 01:05:38PM -0700, Junio C Hamano wrote:
>>>
What are our plans to help existing scripts people have written over
time, especially before "status -s" was i
We have systems hosting git which are behind proxies, and unless the client
sets the http.postBuffer to a large size they connections fails.
Is there a way to set this on the server side? If not would a patch be possible
to fix this?
jason.pyeron@hostname /home/jason.pyeron/desktop/projectname
Matthieu Moy wrote:
> Historically, "git status" needed to prefix each output line with '#' so
> that the output could be added as comment to the commit message. This
> prefix comment has no real purpose when "git status" is ran from the
> command-line, and this may distract users from the real co
On Fri, Jun 28, 2013 at 5:41 PM, Junio C Hamano wrote:
> John Keeping writes:
>> I don't think "git pull remote branch" falls into the same category as
>> plain "git pull" so I'm not convinced that defaulting to merge there is
>> unreasonable. The original message about this [1] did talk about
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The tip of 'next' has been rewound. I ejected a handful of topics
that have been cooking there while rebuilding it, but it is not
because I foun
On Aug 28, 2013, at 16:24, Junio C Hamano wrote:
* km/svn-1.8-serf-only (2013-07-18) 3 commits
(merged to 'next' on 2013-08-28 at 1119134)
+ Git.pm: revert _temp_cache use of temp_is_locked
+ git-svn: allow git-svn fetching to work using serf
+ Git.pm: add new temp_is_locked function
Originall
On Wed, Aug 28, 2013 at 11:08:02PM +, Pyeron, Jason J CTR (US) wrote:
> We have systems hosting git which are behind proxies, and unless the
> client sets the http.postBuffer to a large size they connections
> fails.
>
> Is there a way to set this on the server side? If not would a patch be
>
> -Original Message-
> From: Jeff King
> Sent: Wednesday, August 28, 2013 23:52
> To: Pyeron, Jason J CTR (US)
> Cc: git@vger.kernel.org
> Subject: Re: http.postBuffer set at the server side?
>
> On Wed, Aug 28, 2013 at 11:08:02PM +, Pyeron, Jason J CTR
> (US) wrote:
>
> > We have sy
From: Junio C Hamano
>
> Thomas Rast writes:
>
>> Hrm, you're right, that's a flaw in my logic. You could do the same in
>> all other cases too, e.g. replace a tree so that an entry is of a
>> different type and at the same time change the type of the object
>> itself. You however have to care
On Thu, Aug 29, 2013 at 12:40:16AM -0400, Jason Pyeron wrote:
> > What would it mean to set it on the server? It is the size
> > at which the client decides to use a "chunked"
>
> To tell the client...
But the server in this case cannot tell it a useful size. Only "whatever
you do, do not chu
Jonathan Nieder writes:
> Matthieu Moy wrote:
>
>>In the long run, if users
>> like the non-prefix output, it may make sense to flip the default value
>> to true.
>
> Hmm, do you mean that the configuration is to give the change-averse
> some time t
With nd/magic-pathspec I get the following failure on Windows in
t2016-checkout-patch.sh:
expecting success:
set_state dir/foo work head &&
# the third n is to get out in case it mistakenly does not apply
(echo y; echo n; echo n) | (cd dir && git checkout -p foo) &&
David Aguilar writes:
> I have a poor imagination and cannot imagine why it needs to be
> switchable.
I could not either, but I found the reason in the commit message:
eff80a9fd990
Some users do want to write a line that begin with a pound sign, #,
in their commit log message. Many tra
62 matches
Mail list logo
