On Thu, May 1, 2014 at 4:35 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Now I know, the '--git-dir' option may usually be meant to use
when the repository is somewhere outside of the work tree, and such a
problem would not arise. And even if it is inside, sure enough, you
can add this
On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote:
...
But these days there's hardly any risk to using a detached HEAD. Plus
nowadays I think it's commonly accepted that using topic branches is a git
best practice. The notion of doing work on a generically-named branch like
maint
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does.
That still doesn't
On Thu, May 01, 2014 at 11:58:26AM -0700, Junio C Hamano wrote:
This patch seems to address two unrelated issues in that.
(1) The existing support does not help a platform where the
convention is to define either _BIG_ENDIAN (with one leading
underscore) or _LITTLE_ENDIAN and
---
compat/bswap.h | 33 -
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index 120c6c1..f08a9fe 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x)
Andreas Krey wrote:
My personal beef with 'git pull' is still that sometimes (namely in
the 'git pull git push' sequence) it should reverse the order of
the parents in the merge commit, so that *my* commits look like an
integrated topic branch, instead of the former mainline.
I haven't
Andreas Krey a.k...@gmx.de writes:
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from
Hi,
I’m very new to ‘git’ github. I reported the #178 issue in github and the
issue has been closed, I believe this means no further discussion.
There are a three additional comments, thank you to the contributors. The
advise was to discuss upstream which meant nothing to me (again thanks to
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley dbradl...@bell.net wrote:
Hi,
I’m very new to ‘git’ github. I reported the #178 issue in github and the
issue has been closed, I believe this means no further discussion.
When you say the #178 issue in github, you really mean issue #178
for Git for
On Thu, May 01, 2014 at 07:00:02PM -0500, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
Perhaps this has already been hashed out in a previous version of this
series, but we may want to use pull.update and branch.name.update to
match the existing
Fixed. Thanks.
On Thu, May 1, 2014 at 9:11 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, May 1, 2014 at 4:37 PM, Ronnie Sahlberg sahlb...@google.com wrote:
In s_update_ref there are two calls that when they fail we return an error
based on the errno value. In particular we want to
Fixed. Thanks.
On Thu, May 1, 2014 at 9:22 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, May 1, 2014 at 4:37 PM, Ronnie Sahlberg sahlb...@google.com wrote:
Allow passing a list of refs to ckip checking to name_conflict_fn.
s/ckip/skip/
There are some conditions where we want to
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through all the way. I'm also
not used to reading Git's output and using 'reset --hard' with the
On Thu, May 01, 2014 at 07:00:06PM -0500, Felipe Contreras wrote:
It is very typical for Git newcomers to inadvertently create merges and
worst; inadvertently pushing them. This is one of the reasons many
experienced users prefer to avoid 'git pull', and recommend newcomers to
avoid it as
(Apologies for not CCing all the folks who've participated in the Pull is
Evil thread -- I couldn't find a good branch of that thread for this message.)
OK, so maybe git pull is just Mostly Evil. People seem to have found many
different ways to make it work for them.
But in reality git pull
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run git help pull
for guidance.
Fetching is uncontentious,
From: David Kastrup d...@gnu.org
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should run git help pull
for
On Thu, May 1, 2014 at 6:35 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Phil Hord wrote:
When I use zsh tab-completion to complete the submodule name in 'git
submodule init', I get more than I expected.
From the gerrit repository (which has plugins):
$ git submodule init
Charles Bailey cbaile...@bloomberg.net writes:
---
Please sign-off your patches ;-)
This swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the
original, which we may not want to. It is easy for me to swap the
order of if/elif to restore it, so it is not a big deal, though.
Thanks.
On Fri, May 02, 2014 at 09:48:58AM -0700, Junio C Hamano wrote:
Charles Bailey cbaile...@bloomberg.net writes:
---
Please sign-off your patches ;-)
Oops! Please consider this patch...
Signed-off-by: Charles Bailey cbaile...@bloomberg.net
This swaps the precedence of BYTE_ORDER and
Erik Faye-Lund kusmab...@gmail.com writes:
On Fri, May 2, 2014 at 1:50 PM, Dave Bradley dbradl...@bell.net wrote:
Hi,
I’m very new to ‘git’ github. I reported the #178 issue in github and the
issue has been closed, I believe this means no further discussion.
When you say the #178 issue in
Hi Dave,
Dave Bradley wrote:
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all
--pretty=format:%an %ad -- pom.xml
Mon Nov 23 03:09:17 2009 +
Mon Nov 23 02:42:24 2009 +
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all
--pretty=format:%an %ad
(resending with the correct address for the Git for Windows developers.
Sorry for the noise.)
Hi Dave,
Dave Bradley wrote:
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all
--pretty=format:%an %ad -- pom.xml
Mon Nov 23 03:09:17 2009 +
Mon Nov 23 02:42:24
Marc Branchaud marcn...@xiplink.com writes:
(Apologies for not CCing all the folks who've participated in the Pull is
Evil thread -- I couldn't find a good branch of that thread for this
message.)
OK, so maybe git pull is just Mostly Evil. People seem to have found many
different ways to
Jeff King p...@peff.net writes:
On Wed, Apr 30, 2014 at 02:45:11PM -0700, Junio C Hamano wrote:
See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
Signed-off-by: Junio C Hamano gits...@pobox.com
Don't you often complain about submitters referencing a discussion
in
On Fri, May 2, 2014 at 7:23 PM, Jonathan Nieder jrnie...@gmail.com wrote:
(resending with the correct address for the Git for Windows developers.
Sorry for the noise.)
Hi Dave,
Dave Bradley wrote:
G:\ws_test_env\GIT_TESTBED_TMP\fest-swing-1.xgit log --all
--pretty=format:%an %ad --
Jeff King p...@peff.net writes:
On Thu, May 01, 2014 at 10:51:19AM -0700, Junio C Hamano wrote:
If you want to fix something here, do s/judgement/judgment/ instead.
That too.
FWIW, neither is outright wrong; it is an America/British variation, and
apparently dictionaries disagree on
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through all the way. I'm also
not used to reading Git's output and using
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through
W. Trevor King wk...@tremily.us writes:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
Philip Oakley wrote:
From: David Kastrup d...@gnu.org
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*. It should just print out a message to the effect that it
hasn't been configured, and that the user should
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new command to make the
distinction stand out more. What if the command sequence were like
this
W. Trevor King wrote:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command
Marc Branchaud marcn...@xiplink.com writes:
I may be mistaken, but I think git pull evolved to try to address the
detached-HEAD risk (at least in part).
You are totally mistaken.
git pull was part of the things to make git usable by Linus before
1.0 release, and matches the integrator
On Fri, 2 May 2014, David Kastrup wrote:
Date: Fri, 02 May 2014 17:45:23 +0200
From: David Kastrup d...@gnu.org
To: git@vger.kernel.org
Subject: Re: Pull is Mostly Evil
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to do
*nothing*.
On Thu, May 01, 2014 at 09:41:34PM -0500, Felipe Contreras wrote:
brian m. carlson wrote:
On Thu, May 01, 2014 at 07:00:05PM -0500, Felipe Contreras wrote:
Also, deprecate --no-rebase since there's no need for it any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
Charles Bailey cbaile...@bloomberg.net writes:
I claim that any
platform which provides both but with differing senses is somewhat
broken so I cannot see the precedence mattering much.
I agree with that, and that is the reason why we shouldn't change
the order all of a sudden. If it
Junio C Hamano gits...@pobox.com writes:
Charles Bailey cbaile...@bloomberg.net writes:
I claim that any
platform which provides both but with differing senses is somewhat
broken so I cannot see the precedence mattering much.
I agree with that, and that is the reason why we shouldn't
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
W. Trevor King wrote [1]:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My
Junio C Hamano gits...@pobox.com writes:
Marc Branchaud marcn...@xiplink.com writes:
I may be mistaken, but I think git pull evolved to try to address the
detached-HEAD risk (at least in part).
You are totally mistaken.
git pull was part of the things to make git usable by Linus before
On Fri, May 02, 2014 at 12:43:32PM -0700, Junio C Hamano wrote:
So,... I am inclined to queue this on top of your patch at least for
now, before I go into incommunicado-mode to finish preparing -rc2.
Yes, I'd agree with that.
--
To unsubscribe from this list: send the line unsubscribe git in
Felipe Contreras felipe.contre...@gmail.com writes:
Stepping back even further, and thinking what is different between
these two pulls, we notice that the first one is pulling from the
place we push back to. Perhaps a way to solve this issue, without
having to introduce a new 'git update'
brian m. carlson wrote:
My point is that it's unclear to me what options I need to use to
retain the current behavior (fast-forward if possible, merge
otherwise) without a warning.
The current behavior is to always merge (ff or otherwise), just what
`git merge` would do, so `git pull --merge`.
On Fri, May 02, 2014 at 11:18:34AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
On Wed, Apr 30, 2014 at 02:45:11PM -0700, Junio C Hamano wrote:
See http://thread.gmane.org/gmane.comp.version-control.git/3903/focus=4126
Signed-off-by: Junio C Hamano gits...@pobox.com
On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote:
But let's follow this one:
http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q
which seems to say that with 'e' is more common.
Grammar by democracy. ;)
*1* To Americans, the form with 'e' is
On Fri, May 02, 2014 at 03:14:44PM -0500, Felipe Contreras wrote:
brian m. carlson wrote:
My point is that it's unclear to me what options I need to use to
retain the current behavior (fast-forward if possible, merge
otherwise) without a warning.
The current behavior is to always merge
Jeff King p...@peff.net writes:
I meant something even less in-depth. Your message says only on
comparison, and I did not even know what this in your sentence above
would mean until I followed the link.
There are arguments for writing a conditional as a b rather than
b a, or vice
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code.
Let's
On 2014-05-01 20:00, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
This way we can add more modes and the default can be something else,
namely it can be set to merge-ff-only, so eventually we can reject
non-fast-forward merges by default.
The old
Jeff King wrote:
On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote:
But let's follow this one:
http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q
which seems to say that with 'e' is more common.
Grammar by democracy. ;)
Languages are
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/CodingGuidelines | 55 ++
1 file changed, 55 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index 02ca67c..4dd07c3 100644
---
David Lang da...@lang.hm writes:
On Fri, 2 May 2014, David Kastrup wrote:
It's just when the merge-left/merge-right/rebase-left/rebase-right
decision kicks in that prescribing one git-pull behavior looks like a
recipe for trouble.
confusion at least. It's not fatal confusion, people have
Felipe Contreras felipe.contre...@gmail.com writes:
Jeff King wrote:
On Fri, May 02, 2014 at 11:31:10AM -0700, Junio C Hamano wrote:
But let's follow this one:
http://www.google.com/trends/explore#q=judgement%20call%2C%20judgment%20callcmpt=q
which seems to say that with 'e' is
Firstly, I apologize for sending you this sensitive information via E-mail.
In my banking department we discovered an abandoned sum of
10,000,000.00$ [Ten Million Dollars Only) in an account that belongs
to one of our Foreign customers who unfortunately lost his life with
his entire family on
Hi.
Problem #6: push - reject - pull - push sequence sometimes transforms
into a loop with several iterations and doesn't add happiness.
As far as I undestand, this is the most annoying thing. In
git (like other distributed systems), you cannot push your
changes unless you merge them with a
On Fri, May 02, 2014 at 01:51:55PM -0700, Junio C Hamano wrote:
+ - When splitting a long logical line, with everything else being
+ equal, it is preferrable to split after the operator at higher
dict.org says that it should be preferable, not preferrable.
--
brian m. carlson / brian with
Hi All,
surprisingly, searching this list and by way of Google
I cannot find an answer to a simple question:
In presence of smudge/clean filters which SHA1 hash
(clean content or smudged content) gets stored in the repository?
Thanks,
--Leo--
P.S. Very similar question [1] was posted here in
On Fri, May 2, 2014 at 2:05 PM, Leo Razoumov slonik...@gmail.com wrote:
surprisingly, searching this list and by way of Google
I cannot find an answer to a simple question:
In presence of smudge/clean filters which SHA1 hash
(clean content or smudged content) gets stored in the repository?
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Stepping back even further, and thinking what is different between
these two pulls, we notice that the first one is pulling from the
place we push back to. Perhaps a way to solve this issue, without
having to
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much
that matters is probably best
Richard Hansen wrote:
On 2014-05-01 20:00, Felipe Contreras wrote:
Also 'branch.name.rebase' to 'branch.name.pullmode'.
This way we can add more modes and the default can be something else,
namely it can be set to merge-ff-only, so eventually we can reject
non-fast-forward merges by
W. Trevor King wrote:
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new command to make the
On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Leo Razoumov slonik...@gmail.com writes:
In presence of smudge/clean filters which SHA1 hash
(clean content or smudged content) gets stored in the repository?
You are cleaning cruft in the contents before the contents are
hashed to compute the object name. The point is to keep clean
objects
According to
https://www.kernel.org/pub/software/scm/git/docs/git-check-ref-format.html a
'/' is character to use in a branch name.
git imposes the following rules on how references are named:
1. They can include slash / for hierarchical (directory) grouping, but no
slash-separated component
Jeff King wrote:
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a new
On Fri, May 02, 2014 at 07:15:44AM +0700, Duy Nguyen wrote:
On Fri, May 2, 2014 at 6:05 AM, Jonathan Nieder jrnie...@gmail.com wrote:
I can make up for it in enthuasiasm. Please? It's something I've
wanted for a long time but never found the time to do.
It's definitely better in the
From: Marc Branchaud marcn...@xiplink.com
Sent: Friday, May 02, 2014 4:37 PM
(Apologies for not CCing all the folks who've participated in the
Pull is
Evil thread -- I couldn't find a good branch of that thread for this
message.)
OK, so maybe git pull is just Mostly Evil. People seem to have
Keith Derrick keith.derr...@lge.com writes:
The problem arises when a branch already exists with a name
matching the stem of the new branch name.
...
But, for the reverse reason, I can't now create the branch named 'hotfix'
All correct. Allowing '/' in branch names came about not with a
Hi Keith,
Keith Derrick wrote:
$ git checkout -b hotfix
Switched to a new branch 'hotfix'
$ git checkout -b hotfix/b2
error: unable to resolve reference refs/heads/hotfix/b2: Not a directory
fatal: Failed to lock ref for update: Not a directory
$
That's an ugly
Keith Derrick wrote:
I can see the value in grouping branches in a directory tree under
refs/heads, but wouldn't it make more sense to simply escape the '/'
in the branch name so that 'hotfix/b1' is stored on disk as
'hotfix\/b1'?
This would be nice for remote helpers: Mercurial can have
A release candidate Git v2.0.0-rc2 is now available for testing
at the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following public repositories all have a copy of the 'v2.0.0-rc2'
tag and the 'master' branch that the tag points at:
W. Trevor King wrote:
I've renamed this sub-thread (which started around $gmane/247835) to
avoid potential confusion/dilution.
Thanks.
The goal is to train them to do:
% git config --global pull.mode none
% git fetch
% git merge --no-ff
Sticking to my 'no-ff' topic
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Friday, May 02, 2014 8:05 PM
Philip Oakley wrote:
From: David Kastrup d...@gnu.org
Marc Branchaud marcn...@xiplink.com writes:
To that end, I suggest that pull's default behaviour should be to
do
*nothing*. It should just print out
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:
They can do:
% git pull origin master
That shouldn't revese the bases.
Then they have to remember to do that every time, no? That seems a
little error-prone versus setting a config option.
Such users are going to run git
Yes, I've since found some discussion on this, and had already changed
to use '-' to append the classifier.
But the other problem is that I can't easily find this restriction
documented anywhere - which means it comes as a suprise to people.
As it stands, the documentation implies that what I
Hi,
Keith Derrick wrote:
Yes, I've since found some discussion on this, and had already changed
to use '-' to append the classifier.
But the other problem is that I can't easily find this restriction
documented anywhere - which means it comes as a suprise to people.
That sounds like
Hi,
Philip Oakley wrote:
That assumes that [git pull] doing something is better than doing nothing,
which is appropriate when the costs on either side are roughly
similar.
I think the conversation's going around in circles.
Potential next steps:
a. Documentation or test patch illustrating
From: David Turner dtur...@twitter.com
Signed-off-by: David Turner dtur...@twitter.com
---
builtin/grep.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/builtin/grep.c b/builtin/grep.c
index 69ac2d8..e9fe040 100644
--- a/builtin/grep.c
+++ b/builtin/grep.c
@@
The most sigificant patch uses Facebook's watchman daemon[1] to monitor
the repository work tree for changes. This makes allows git status
to avoid traversing the entire work tree to find changes.
This change requires libwatchman[2], a client library that I wrote for
watchman.
While making the
Philip Oakley wrote:
From: Felipe Contreras felipe.contre...@gmail.com
So? No defaults can please absolutely everyone, the best anybody can
do is try to please the majority of people, and merging
fast-forwards only does that.
That assumes that doing something is better than doing
Jeff King wrote:
On Fri, May 02, 2014 at 04:55:01PM -0500, Felipe Contreras wrote:
They can do:
% git pull origin master
That shouldn't revese the bases.
Then they have to remember to do that every time, no? That seems a
little error-prone versus setting a config option.
Yes.
On 2014-05-02 17:12, Felipe Contreras wrote:
Richard Hansen wrote:
Should branch.autosetuprebase be replaced with a new
branch.autosetupmode setting?
Maybe. But if so, I think that should be done in another series.
Otherwise we'll never have a chance to change anything.
Sure.
On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
The 'git pull' (with 'none' mode) explainer just helps retrain folks
that are already using the current 'git pull' incorrectly.
If you are going to train them to use a configuration, it should
These have been stable and widely used for quite a long time, they even
have tests outside of the contrib area, and most distributions ship
them, so they can be considered part of the core already.
Let's move them out of contrib and install them by default.
Signed-off-by: Felipe Contreras
On Sat, May 3, 2014 at 6:14 AM, dtur...@twopensource.com wrote:
The index format change might be less important with the split index;
I haven't investigated that since at the time I wrote these patches,
it didn't exist.
This is the worst case scenario of git status on webkit.git (182k
files,
Jeff King p...@peff.net writes:
On Fri, May 02, 2014 at 02:11:05PM -0500, Felipe Contreras wrote:
Junio C Hamano wrote:
If we step back a bit, because we are forcing him to differentiate
these two pulls in his mental model anyway, perhaps it may help
people (both new and old) if we had a
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
dturner@ wrote:
Test repository 1: Linux
Linux is about 45k files in 3k directories. The average length of a
filename is about 32 bytes.
Git status timing:
no watchman: 125ms
watchman: 90ms
That's very interesting.
David Turner wrote:
On Fri, 2014-05-02 at 18:20 -0500, Felipe Contreras wrote:
dturner@ wrote:
Test repository 1: Linux
Linux is about 45k files in 3k directories. The average length of a
filename is about 32 bytes.
Git status timing:
no watchman: 125ms
watchman: 90ms
On Sat, 2014-05-03 at 07:52 +0700, Duy Nguyen wrote:
On Sat, May 3, 2014 at 6:14 AM, dtur...@twopensource.com wrote:
The index format change might be less important with the split index;
I haven't investigated that since at the time I wrote these patches,
it didn't exist.
This is the
This is the error message git-apply emits in this case:
error: cannot apply binary patch to 'filename' without full index line
error: filename: patch does not apply
Cheers,
Tolga
Any feedback is appreciated.
Cheers,
Tolga
--
To unsubscribe from this list: send the line unsubscribe git in
92 matches
Mail list logo
