Am 8/27/2013 23:48, schrieb Jeff King:
The counterarguments I can see are:
1. Who cares? If you want to know whether pack-objects will choke on
your huge config value, then run pack-objects.
2. Such a check would involve knowing which type we use internally to
look at
Junio C Hamano gits...@pobox.com writes:
Christian Couder chrisc...@tuxfamily.org 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
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
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
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 install the
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 users
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 j.s...@viscovery.net 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
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
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
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
(--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
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
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 the
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 the
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
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
From: Junio C Hamano gits...@pobox.com
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
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 ram...@ramsay1.demon.co.uk
---
Hi Junio,
When
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 netserv...@niekom.de
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 13 ++---
1 file changed, 10 insertions(+), 3
It wasn't being checked properly before; those refs never existed.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
---
In accordance with pep8.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
It appears 'let' is not present in all shells.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
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
They don't need to be specified if they are not going to be set.
Suggested-by: Dusty Phillips du...@linux.ca
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 29 -
contrib/remote-helpers/git-remote-hg | 30
Reported-by: Joakim Verona joa...@verona.se
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 1 +
contrib/remote-helpers/test-bzr.sh| 30 ++
2 files changed, 31 insertions(+)
diff --git
Thomas Rast tr...@inf.ethz.ch 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
Jeff King p...@peff.net 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
Matthieu Moy matthieu@imag.fr 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
Felipe Contreras felipe.contre...@gmail.com 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 commit...@example.com expected
Git's
Junio C Hamano gits...@pobox.com 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.
--
wor...@alum.mit.edu (Dale R. Worley) writes:
From: Junio C Hamano gits...@pobox.com
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 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
was
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com 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
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr 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
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
+ bzr log | grep ^committer: ../actual
+ )
+
+ echo committer: Grégoire commit...@example.com expected
Git's source code usually says
Am 28.08.2013 14:47, schrieb Matthieu Moy:
Signed-off-by: Matthieu Moy matthieu@imag.fr
---
(--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
Reported-by: Joakim Verona joa...@verona.se
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 1 +
contrib/remote-helpers/test-bzr.sh| 30 ++
2 files changed, 31 insertions(+)
diff --git
On Wed, Aug 28, 2013 at 3:54 PM, Antoine Pelisse apeli...@gmail.com wrote:
On Wed, Aug 28, 2013 at 10:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Aug 28, 2013 at 4:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
+ bzr log | grep ^committer: ../actual
+ )
+
+ echo
Matthieu Moy matthieu@imag.fr 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))
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..dacf4b9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
Matthieu Moy matthieu@grenoble-inp.fr writes:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
+ bzr log | grep ^committer: ../actual
+ )
+
+ echo committer: Grégoire
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 gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Felipe Contreras felipe.contre...@gmail.com writes:
On Wed, Aug 28, 2013 at 3:05 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
+ bzr log | grep ^committer:
David Aguilar dav...@gmail.com writes:
On Wed, Aug 28, 2013 at 2:39 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net 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,
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 content.
On Fri, Jun 28, 2013 at 5:41 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk 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
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
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
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 systems
53 matches
Mail list logo
