Greg Troxel wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Greg Troxel wrote:
In a packaging system, dependencies are much more troublesome.
Dependencies have to be declared, and the build limited to use only
those declared dependencies, in order to get repeatable builds
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
And you are still conveniently avoiding the question:
Based on what reasoning?
Go re-read what was already said in the thread.
I already read it, and I already responded.
I still think remote-hg and remote-bzr
Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
I think the discussion with John Keeping hints that we shouldn't be
rushing fc/remote-helpers-hg-bzr
://article.gmane.org/gmane.comp.version-control.git/225146
[4] http://article.gmane.org/gmane.comp.version-control.git/247237
[5] http://article.gmane.org/gmane.comp.version-control.git/247939
[6] http://article.gmane.org/gmane.comp.version-control.git/130819
--
Felipe Contreras
--
To unsubscribe from
and other tools already out of contrib.
--
Felipe Contreras
--
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
helpers may benefit from a separate release schedule.
The conclusion is correct, the premises are not.
--
Felipe Contreras
--
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
of the updated tip of your
upstream (which by the way is different from how rebase
--preserve-merges works; it is more like how J6t wanted to make
rebase --preserve-merges work, IIRC).
What is the difference with 'rebase -p'?
--
Felipe Contreras
--
To unsubscribe from this list: send
completely ignored:
completion: move out of contrib
Since you are not going to do so, I do not feel compelled to fix the
synchronization crash regression that is present in v2.0.0-rc2 and I
already warned you about.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Plus this one which has been completely ignored:
completion: move out of contrib
It is not about ignored. It is about running out of time before
concluding the day's integration.
A comment doesn't require
/sharness
--
Felipe Contreras
--
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
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
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
Jeff King wrote:
On Mon, May 05, 2014 at 12:45:30AM -0500, Felipe Contreras wrote:
Jeff King wrote:
On Sun, May 04, 2014 at 01:12:53AM -0500, Felipe Contreras wrote:
So it looks like gcc is smarter now, and in trying to fix a few warnings
we generated hundreds more
Jeff King wrote:
On Mon, May 05, 2014 at 01:14:43AM -0500, Felipe Contreras wrote:
Jeff King wrote:
You could try reading the commit message of the commit you are
reverting, which explains it, but the short answer is: try compiling
with -O3.
Sigh. And I'm the one
MsgWaitForMultipleObjects with
NOGDI
MinGW-w64 != x86_64; it provides a i686 compiler as well.
--
Felipe Contreras
--
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 Turner wrote:
On Fri, 2014-05-02 at 22:40 -0500, Felipe Contreras wrote:
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
to
Documentation/CodingGuidelines and stick it in contrib/ or something.
I think this would fit perfectly in the proposed `git update` command as
an option: `git update --all`.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Andreas Schwab wrote:
This thread is about objects of type struct object_id, and their
address is always the same as the address of its first member.
Nothing else is relevant.
Indeed. I suggest you ingore that guy, he will only derail the
discussion.
--
Felipe Contreras
--
To unsubscribe
://article.gmane.org/gmane.comp.version-control.git/248065
[2] https://travis-ci.org/felipec/git
[3] https://github.com/felipec/git/wiki/Comparison-of-git-remote-hg-alternatives
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
Mostly copied from my personal github wiki.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-remote-bzr.txt | 74
Documentation/git-remote-hg.txt | 121 +++
2 files changed, 195 insertions(+)
create
John Keeping wrote:
On Mon, May 05, 2014 at 02:08:28PM -0500, Felipe Contreras wrote:
John Keeping wrote:
I am not convinced that tools for interoperating with other VCSs need to
be part of core Git; as Junio has pointed out previously, while contrib/
was necessary for promoting
Felipe Contreras wrote:
John Keeping wrote:
I don't see that building against Mercurial's default branch, so it
will not help with future releases.
I can easily add that.
There:
https://travis-ci.org/felipec/git
--
Felipe Contreras
--
To unsubscribe from this list: send the line
to detect the features and options of the remote helpers so
unbundling wouldn't be a major problem.
Having said that alignment issues do happen, and we have one of those in
Git v2.0, but I don't think they are a major concern (at least for
remote-hg/bzr).
--
Felipe Contreras
--
To unsubscribe
Felipe Contreras wrote:
Having said that alignment issues do happen, and we have one of those
in Git v2.0, but I don't think they are a major concern (at least for
remote-hg/bzr).
Actually I just noticed that the remote-helpers side is not in the
master branch.
I don't know what is your plan
are frowned upon, so let's just avoid the warning altogether.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/commit.c | 2 +-
wt-status.c | 22 +++---
2 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index
In recent versions of gcc (4.9.0), we get a few of these:
notes.c: In function ‘notes_display_config’:
notes.c:970:28: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
config_error_nonbool(k);
^
Previous commit explains the
Hi,
I'm getting tons and tons of warnings with gcc 4.9.0. Here are the patches to
fix them all.
Felipe Contreras (3):
Revert make error()'s constant return value more visible
Revert silence some -Wuninitialized false positives
Silence a bunch of format-zero-length warnings
builtin
In recent versions of gcc (4.9.0), we get hundreds of these:
advice.c: In function ‘error_resolve_conflict’:
advice.c:79:69: warning: right-hand operand of comma expression has no effect
[-Wunused-value]
error('%s' is not possible because you have unmerged files., me);
James Denholm wrote:
Felipe Contreras wrote:
David Lang wrote:
the vast majority of people here do not take that attitude.
It's actually the exact opposite. I don't care what is the track record
of the people in the discussion.
Ah, yes, like that discussion we once had where you totally
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
Richard Hansen wrote:
Or are you proposing that pull --merge should reverse the parents if and
only if the remote ref is @{u}?
Only if no remote or branch are specified `git pull --merge`.
OK. Let me summarize
brian m. carlson wrote:
On Sun, May 04, 2014 at 01:12:55AM -0500, Felipe Contreras wrote:
This is in gcc 4.9.0:
wt-status.c: In function ‘wt_status_print_unmerged_header’:
wt-status.c:191:2: warning: zero-length gnu_printf format string
[-Wformat-zero-length
Marat Radchenko wrote:
If one wants to dig deeper, I'd say the problem is in MinGW-W64
headers because their behavior of hiding MsgWaitForMultipleObjects
doesn't match behavior of MSVC headers.
I agree with that. Can you file a bug report?
--
Felipe Contreras
--
To unsubscribe from this list
now feeling confident I will be able to put a proposal
that allow a simple configuration to fulfill the need of these users
without affecting anyone else negatively.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I proposed a few alternatives in my
earlier email (though not in the form
://article.gmane.org/gmane.comp.version-control.git/225146
[4] http://article.gmane.org/gmane.comp.version-control.git/247237
[5] http://article.gmane.org/gmane.comp.version-control.git/247939
[6] http://article.gmane.org/gmane.comp.version-control.git/130819
--
Felipe Contreras
--
To unsubscribe from
/
Very nice!
I'm skimming through the contents and I noticed you mention
'color.ui = auto' a lot. There's no need for that, it has been the
default since v1.8.4.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Jeff King wrote:
On Sun, May 04, 2014 at 01:12:53AM -0500, Felipe Contreras wrote:
So it looks like gcc is smarter now, and in trying to fix a few warnings
we generated hundreds more.
This reverts commit e208f9cc7574f5980faba498d0aa30b4defeb34f.
And now we've gone the other way
Richard Hansen wrote:
On 2014-05-04 17:13, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-04 06:17, Felipe Contreras wrote:
Richard Hansen wrote:
On 2014-05-03 23:08, Felipe Contreras wrote:
It is the only solution that has been proposed.
It's not the only proposal -- I
.
Should a screwdriver be turning clockwise or counterclockwise by
default? There are valid arguments for either.
If you don't have anything to contribute don't disturb the people that
actually care and are trying to improve Git. Thanks.
--
Felipe Contreras
--
To unsubscribe from this list
master` already works fine for this case.
--
Felipe Contreras
--
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
W. Trevor King wrote:
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
Philip Oakley wrote:
From: Felipe Contreras felipe.contre...@gmail.com
When doing something is better for the vast majority of people, that's
what should be done by default, unless the results are catastrophic
for
the minority.
Since doing something is not catastrophic
subtree by default,
overall I'll very likely extend that to general work on subtree and such.
I think you should take a look at the Makefile of
contrib/remote-helpers. I bet something simple like that would work just
fine for subtree.
--
Felipe Contreras
--
To unsubscribe from this list: send
Inspired by the tests in gitifyhg.
One test is failing, but that's because of a limitation of
remote-helpers.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 150 ++
1 file changed, 150 insertions(+)
diff
Inspired by gitifyhg.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 76 +++
1 file changed, 76 insertions(+)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib/remote-helpers/test-hg.sh
index 33a434d
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-hg | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/contrib/remote-helpers/git-remote-hg
b/contrib/remote-helpers/git-remote-hg
index 34cda02..8b02803 100755
--- a/contrib
Here's a bunch of tests more, and a fixes for Mercurial v3.0.
Felipe Contreras (4):
remote-hg: add more tests
t: remote-hg: add file operation tests
t: remote-hg: trivial cleanups and fixes
remote-hg: add support for hg v3.0
contrib/remote-helpers/git-remote-hg | 6 +-
contrib/remote
There was a broken chain, and cat is simpler than echo in a subshell.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/test-hg.sh | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/contrib/remote-helpers/test-hg.sh
b/contrib
Richard Hansen wrote:
On 2014-05-03 05:26, Felipe Contreras wrote:
Richard Hansen wrote:
I think the fundamental difference is in the relationship between the
local and the remote branch (which branch derives from the other).
The relationship between the branches determines what
, their
argument is good.
It's the others that focus on the carisma and credentials of the people
in the discussion, rather than the arguments.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo
really thought much about this but it does make sense. How
about changing the behavior so `git pull` by default changes the order
of the parents, but `git pull repo branch` doesn't.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
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
is try to please the majority of people, and merging fast-forwards only
does that.
--
Felipe Contreras
--
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
is basically essentially the same as not specifying anything, or
rather, running `git pull` without arguments.
--
Felipe Contreras
--
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
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
`. I don't see what's
confusing about that.
--
Felipe Contreras
--
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
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
are a democracy. There's no authority that decides if
unibrow should become part of the English language. We all do.
--
Felipe Contreras
--
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
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
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
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
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
hotfix and
hotifx/b1, so importing such a Mercurial repository creates problems.
--
Felipe Contreras
--
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
: pull.topicargs = --merge --no-ff.
--
Felipe Contreras
--
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
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 nothing
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
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
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
brian m. carlson wrote:
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
Marc Branchaud wrote:
On 14-04-30 04:14 PM, Felipe Contreras wrote:
What is wrong when `git pull` merges a fast-forward?
Nothing. Everything. It depends.
It depends on what? I don't
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
brian m. carlson wrote:
..
At work, we have a workflow where we merge topic branches as
non-fast-forward, so that we have a record of the history (including who
reviewed the code), but when we want to just
/topic-branch
git push main-repo HEAD
You mean `git push main-repo HEAD:maintenance-branch`, right?
--
Felipe Contreras
--
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
.
git push main-repo HEAD
main-repo/maintenance-branch should be the upstream of
maintenance-branch, in which hase:
% git push
--
Felipe Contreras
--
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
this?
Define 'works' in bash. From what I can see from the bash completion,
it's not doing anything special, so the completion you see are simply
files.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
W. Trevor King wrote:
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
The only problem would be when it's not desirable, however, that's a
problem of the user's ignorance, and the failure of the project's
policity to communicate clearly to him that he should be running
the defaults.
--
Felipe Contreras--
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
Marc Branchaud wrote:
So what benefit does git pull provide?
The same that 'hg update' provies: a way for the user fetch/pull the
latest changes and check them out into the working directory.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body
a fast-forward by mistake.
I think a non-fast-forward warning by default, and eventually rejecting
them is the most sensible approach.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
brian m. carlson wrote:
I just used this to illustrate the fact that there isn't actually one
completely correct case with pull.
Nobody is arguing otherwise. The argument is that `git pull` by default
can be made more sensible.
--
Felipe Contreras
--
To unsubscribe from this list: send
And branch.$name.pullmode.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
t/t5505-remote.sh | 2 +-
t/t5520-pull.sh | 54 +++---
2 files changed, 24 insertions(+), 32 deletions(-)
diff --git a/t/t5505-remote.sh b/t/t5505
-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/config.txt | 39 ++-
Documentation/git-pull.txt | 2 +-
branch.c | 4 ++--
builtin/remote.c | 14 --
git-pull.sh| 31
reset --hard master
+ test_must_fail git pull
+'
+
test_done
Felipe Contreras (7):
pull: rename pull.rebase to pull.mode
pull: migrate all the tests to pull.mode
pull: refactor $rebase variable into $mode
pull: add --merge option
pull: add merge-ff-only option
pull: add warning
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
git-pull.sh | 64 +++--
1 file changed, 33 insertions(+), 31 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 3dbf9cf..50c612f 100755
--- a/git-pull.sh
+++ b/git
on this mode can be enabled by default.
For the full discussion you can read:
http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=225305
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/config.txt | 7 +--
git-pull.sh | 15
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-pull.txt | 2 +-
git-pull.sh | 15 +++
t/t4013-diff-various.sh | 2 +-
t/t5500-fetch-pack.sh| 2 +-
t/t5520-pull.sh | 5 +
t/t5524-pull-msg.sh
, they know what to type without interrupting or changing their
workflow.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-pull.txt | 18 ++
git-pull.sh| 15 ---
t/t5520-pull.sh| 14 ++
3 files changed, 44
Also, deprecate --no-rebase since there's no need for it any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-pull.txt | 8 ++--
git-pull.sh| 10 +-
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/Documentation
W. Trevor King wrote:
On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:
Nobody ever complained about somebody doing a fast-forward by mistake.
Unless they fast-forward merged a feature branch into master, but the
project prefers explicitly-merged feature branches
W. Trevor King wrote:
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
My interest in all of the proposed git-pull-training-wheel patches is
that they give users a way to set
W. Trevor King wrote:
On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:
If that was the case the user wouls have run `git merge
--no-ff`. Only expereinced users would answer 'no'.
Folks who are setting any ff options don't need any of these training
wheels.
Indeed.
My
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
---
Documentation/git-pull.txt | 8 ++--
git-pull.sh
_complete' and I get bashcompinit's complete, and the internal
_complete() function is used only by the _git completion.
How have you configured this completion? Are you using the recommended
instructions?
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git
-to-munging-mail-as-mail-was-meant-to-be/
--
Felipe Contreras
--
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
Jeff King wrote:
On Tue, Apr 29, 2014 at 11:08:29PM -0500, Felipe Contreras wrote:
If we use a different conflict style `git rerere forget` is not able to
find the matching conflict SHA-1 because the diff generated is actually
different from what `git merge` generated.
Can you show
Felipe Contreras wrote:
Phil Pennock wrote:
The bash completion pulled into zsh was being pulled in _as_ zsh, but
used patterns which relied on falling through as unhandled. In zsh
5.0.3 this no longer works, resulting in:
__git_complete_remote_or_refspec:33: bad pattern
Felipe Contreras wrote:
Mark Lodato wrote:
Previously, git-completion.zsh redefined complete() to make
__git_complete() a no-op. This broke zsh's built-in bash completion
compatibility layer (bashcompinit), which defines its own complete().
How exactly? I'm testing this and I don't see
Avoid Yoda conditions, use test, and cleaner statement.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git
It has been deprecated for one year and a half. It's time to move on.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 64 --
1 file changed, 64 deletions(-)
diff --git a/contrib/completion/git
We don't want to override the 'complete()' function in zsh, which can be
used by bashcomp.
Reported-by: Mark Lodato lod...@google.com
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 1 +
contrib/completion/git-completion.zsh | 6 --
2
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.bash | 12
1 file changed, 12 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 9525343..6e331d2 100644
--- a/contrib
We don't need to override IFS, zsh has a native way of splitting by new
lines: the expansion flag (f).
Also, we don't need to split files by ':' or '='; that's only for words.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.zsh | 10 +++---
1
There's no need to hide the fact that we are on zsh any more.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-completion.zsh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.zsh
b/contrib/completion/git
201 - 300 of 3053 matches
Mail list logo
