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.zs
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/completi
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-completion.zsh
index 1f786cc..28eaaed 100644
--- a/c
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-complet
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/completi
It has been deprecated for more than three years. 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/completi
The original code was correct: the example location ~/.git-completion.sh
is correct, because it's not only used by Bash. And zstyle command in
Zsh should use that same location; the Bash script.
This reverts commit 0e5ed7cca3c51c821c2bb0465617e75d994f432f.
Signed-off-by: Felipe Contreras
We can add colour in Zsh without the need of pcmode.
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-prompt.sh | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/completion/git-prompt.sh b/contrib/completion/git-pro
Sometimes we want to use the function directly (e.g. _git_checkout), for
example when zsh has the option 'complete_aliases', this way, we can do
something like:
compdef _git gco=git_checkout
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-completi
Signed-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
contrib/completion/git-completion.bash | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index e3918c8..ecdf742 100644
--- a/contrib/completi
Hi,
Here's a bunch of patches I've been using for a long time. I don't recall if
I've sent some of these before.
Here they are in case anybody is interested.
Cheers.
Felipe Contreras (11):
completion: add missing fetch options
completion: bash: remove old wrappers
completion: bash
On Tue, May 17, 2016 at 10:59 PM, Junio C Hamano <gits...@pobox.com> wrote:
> On Tue, May 17, 2016 at 8:31 PM, Felipe Contreras
> <felipe.contre...@gmail.com> wrote:
>> On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> - Ev
On Tue, May 17, 2016 at 5:22 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Felipe Contreras <felipe.contre...@gmail.com> writes:
>
>> Certain lines of the marks file might be corrupted (or the objects
>> missing due to a garbage collection), but that's no
-off-by: Felipe Contreras <felipe.contre...@gmail.com>
---
fast-import.c | 7 +--
t/t9300-fast-import.sh | 15 +++
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 9fc7093..a975c34 100644
--- a/fast-import.c
+++
waffling about indexes and go straight there instead.
Or maybe we need to have sane options, like --stage, --work, and --keep.
--
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
plenty of times, included by Junio.
--
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
reset by
checkout and be carefree.
Doesn't 'git reset orign/master' do 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
Felipe Contreras wrote:
Atsushi Nakagawa wrote:
Ok, the typical use case is: I'm on 'master' and I make a few test
commits. Afterwards, I want to discard the commits and move back to
'origin/master'. I could type 'reset --hard origin/master' and risk
blowing away dirty files if I'm
Jeff King wrote:
On Wed, May 28, 2014 at 06:17:25PM -0500, Felipe Contreras wrote:
This is the last mail I sent to you, because you ignore them anyway, and
remove them from the mailing list.
[...]
[2], a mail you conveniently removed from the tracked record.
[...]
You also
.
--
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
.
[1] 20140516084126.gb21...@sigill.intra.peff.net
[2] 537bbd6c1daf_a6f166b308b0@nysa.notmuch
[3] xmqqlhtwrufq@gitster.dls.corp.google.com
For reference, here's the full content of mail [2]:
From: Felipe Contreras felipe.contre...@gmail.com
Subject: Re: [PATCH] remote-helpers: point
Felipe Contreras wrote:
In mail [3] you acknowledged my wish, and you said you were going to put
stubs for v2.0, and you didn't. You also conveniently removed this mail
from the archives.
My bad. You actually did it. I missed it because the commit is named
'Revert Merge branch 'jc/graduate
changes are independent of the
graduation.
--
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
'
(provided that there is a way to tell it to replay on HEAD and
ignore base and have merge instruction become a no-op when the
branch has already been merged).
Done.
% git checkout next
% git reintegrate --apply match-next
https://github.com/felipec/git-reintegrate/commit/036395b
--
Felipe
Felipe Contreras wrote:
Yes, I see how xx/topic~4 would be useful in the instruction sheet, I
just didn't see it would be useful to generate that from an existing
integration branch. After the explanation above I see how it could be
useful to some people (though not all). I'll implement
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
* The remote-helper interface to fast-import/fast-export via the
transport-helper has been tightened to avoid leaving the import
marks file from a failed/crashed run, as such a file
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
2. add warning that is given every time the scripts are run and
give the same instruction as in README.
3. (optional) cripple the script to make them always fail after
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
After looking at the reverse-depends list of packages, my faith is
strengthened in that the Git ecosystem is truly maturing and useful
third-party plug-ins will be picked up by distro
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Which will generate the integration instructions for you:
% git reintegrate --cat
base master
merge jl/submodule-mv
Moving a regular file in a repository with a .gitmodules file
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Let's try this in a different way, as I sense there is a
misunderstanding somewhere about your wish.
...
No, I already said I do not want the code removed from v2.0, that's why
I sent patches that simply added
Johan Herland wrote:
On Tue, May 20, 2014 at 4:55 PM, Michael Haggerty mhag...@alum.mit.edu
wrote:
On 05/19/2014 11:31 PM, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Where is git-imerge packaged?
I didn't see it on the archive the said Ubuntu box slurps
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Or have an option to specify a dynamic instruction sheet, so you can cat
the instructions of 'match-next' and replace the base. However, I don't
see the point of re-applying the branches for 'next' if you already
On Tue, May 20, 2014 at 5:47 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
I'm not sure what would be the usefulness of using things like
'xx/topic~4'.
As a notation it is not very pretty ;-).
Imagine that xx/topic is about a multistep
.
Really? Where are the patches for that?
I think it's fair to say the way the remote-helpers and transport-helper
has been handled for v2.0 has been a total disaster.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
- The always warn does not force update at the point of use, but
it still does not help them to notice well before they try to use
it for the first time after update;
I don't
Ævar Arnfjörð Bjarmason wrote:
On Mon, May 19, 2014 at 2:36 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This tool finds people that might be interested in a patch, by going
back through the history for each single hunk modified, and finding
people that reviewed, acknowledged
Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
Felipe Contreras felipe.contre...@gmail.com writes:
We could. Personally I don't see the point of making the warning any
more annoying
If we were giving the users a choice of no thanks, I'll keep using
the obsolete
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
% git fetch
WARNING: git-remote-hg is now maintained independently.
WARNING: For more information visit
https://github.com/felipec/git-remote-hg
searching for changes
no changes found
I don't think
--continue`.
Despite having more features, the code is actually smaller thanks to
Ruby awesomeness.
Enjoy.
https://github.com/felipec/git-reintegrate
Changes since v0.1:
* Add support for empty commits
* Add support for pause command
* Update manpage
* Add bash completion
Felipe Contreras (26
Hamano gits...@pobox.com (signer: 90%, author: 5%)
Felipe Contreras felipe.contre...@gmail.com (author: 25%, reviewer: 2%)
Sverre Rabbelier srabbel...@gmail.com (author: 17%, acker: 2%, signer: 7%)
Jeff King p...@peff.net (acker: 17%, author: 10%)
Shawn O. Pearce spea...@spearce.org (author: 5
to see what was the status of your series of
the branch 'feature-a' in version 2, you can use 'sent/feature-a/v2', for
example to create an interdiff to see what changed between one version an the
other.
Enjoy.
https://github.com/felipec/git-send-series
--
Felipe Contreras
--
To unsubscribe from
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
But that being said, this is Felipe's code. While we have a legal right
to distribute it in v2.0, if he would really prefer it out for v2.0, I
would respect that.
I am fine with that.
Are you? Because
everything else.
After you've removed the code, I don't care what you do, but I'd say you
should remove the stubs after a long period of time.
--
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
.
--
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 Sat, May 17, 2014 at 12:25:30AM -0500, Felipe Contreras wrote:
I agree with the line of reasoning you laid out in your email,
especially:
What a shock.
Please stop with these unproductive and rude comments.
I am sorry, but the fact of the matter is that you
James Denholm wrote:
Felipe Contreras wrote:
James Denholm wrote:
On Fri, May 16, 2014 at 05:39:42PM -0500, Felipe Contreras wrote:
(...) I would venture to say you have never made a package in your
life.
And you have, Felipe? Let us see the years of experience you surely have
.
--
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:
== contrib vs. core ==
This is the only point relevant to contrib vs. core:
- We may be painted in a hard place if remote-hg or remote-bzr take
us to a position where the Git as a whole is blocked while
would prefer to keep it _in_ the git.git
repository and eventually get it included in the core.
That is correct.
--
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
they will if there's only stubs there.
Cheers.
--
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
William Giokas wrote:
On Fri, May 16, 2014 at 03:08:51AM -0500, Felipe Contreras wrote:
This is a red herring. Ignore the fact that it will never happen (which
it won't), the next point remains a FACT, and you conveniently ignore
it.
It may not block git being released, but as we can see
William Giokas wrote:
On Fri, May 16, 2014 at 05:21:36AM -0500, Felipe Contreras wrote:
How exactly would it be better?
If you concede that the Git release wouldn't be affected, then assuming
a hypothetical future where git-remote-hg is bundled, and we have a
Mercurial API breakage, we
this patch is not doing anything in recent versions of Git.
--
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
to push a file named refs/heads/master and I saw the
issue. I'd say it's a very rare issue, and I don't see how it could be
triggered with normal files since all the ref names have the full name.
That being said I don't think it would hurt.
--
Felipe Contreras
--
To unsubscribe from this list: send
(core.commentChar should only be
one character);
+ }
Small nit:
if (ret)
return ret;
if (comment[0] !comment[1])
comment_line_char = comment[0];
else
return error(core.commentChar should only be one character);
--
Felipe Contreras--
To unsubscribe
all this *before* making your stupid decision.
--
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
that.
Now it seems you are changing your mind and you are OK with the code
remaining in.
Do what you will, but I already told you what I will do in response.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
it?
Adding an extra '--' would make sense if we do something like
'git fast-export $stuff master' and there was a file named master.
However, we do 'git fast-export $stuff refs/heads/master', which case
the '--' is a no-nop *always*.
It doesn't hurt to add it though. I think.
--
Felipe Contreras
to.
--
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
Ronnie Sahlberg wrote:
On Tue, May 13, 2014 at 4:37 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
But if I have to adjust for saying that (which was true), what do you
say to Junio for saying this? (which was not)
I know I shouldn't but I will respond anyway.
The problem
, that was all his explanation for
the *TECHNICAL* reason.
You, and other people, are using the behavior I displayed *AFTER* Junio
made his *TECHNICAL* decision as the cause for his decision not to
graduate. That's a wrong direction fallacy.
--
Felipe Contreras
--
To unsubscribe from this list: send
that.
It's all on you.
--
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
.
--
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:
Junio C Hamano wrote:
So at this point, I would have to say that the users of remote-hg is
taken hostage by its author.
The users of remote-hg are being affected negatively *because* of your
decisions.
You
Jeff King wrote:
On Wed, May 14, 2014 at 02:35:08PM -0500, Felipe Contreras wrote:
Prior to his decision there were no complaints about my manners since
I returned. It was his *TECHNICAL* decision that triggered this.
There have been several complaints about your behavior since you
David Kastrup wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Philippe Vaucher wrote:
[...]
Do you feel Felipe is in control of what you label bad behavior? Do you
feel you are in control over how you react to his behavior?
I feel that Felipe cannot control
offsensive and insulting.
--
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:
Junio never explained his *TECHNICAL* reason, and Michael Haggerty
simply said there are good technical arguments for and against
moving git-remote-hg out of contrib, that was all his explanation for
the *TECHNICAL
Martin Langhoff wrote:
On Wed, May 14, 2014 at 7:28 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Do we no longer have to be afraid of that? WHY? All the responses from
the contrib cleanup patches seem to suggest that pretty much *everyone*
The responses also been clear
by whom? If it's by the environment you should be running 'make -e'.
--
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
Otherwise it might collide with a function of the same name in the
user's environment.
Suggested-by: SZEDER Gábor sze...@ira.uka.de
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/completion/git-prompt.sh | 16
1 file changed, 8 insertions(+), 8 deletions
Martin Langhoff wrote:
On Thu, May 8, 2014 at 9:33 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
No updates since 2010, and no tests.
NAK.
IMHO, this is quite unfriendly.
Is this removal based on your opinion, or Junio's position (or
consensus from maintainers from the list
-hg and
git-remote-hg are no longer maintained in git.git.
If you hadn't made such a move, you would have your answer, the fix
would be properly explained, the regression fixed, and all your users
would be happy that git-remote-hg and git-remote-bzr get distributed by
default.
--
Felipe Contreras
Martin Langhoff wrote:
On Tue, May 13, 2014 at 2:05 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This tool doesn't even work anyway.
It doesn't? Bug report / more info please?
Show me that it does. The documentation is lacking, and there's no tests
at all.
So it's hard to say
Junio C Hamano wrote:
Martin Langhoff martin.langh...@gmail.com writes:
On Fri, May 9, 2014 at 5:54 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
You are once more twisting the sequence of events.
Found this gem looking for background to the proposed removal to code
://github.com/felipec/git-remote-hg.
Cheers.
--
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
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 10:30:26AM -0700, Junio C Hamano wrote:
Why do we import changegroup unconditionally, even though it
is only used in the new codepath meant
that they are unmaintained, and the
right location for them. And yes, I also think this should be done for
v2.0.
--
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
The tools are now maintained out-of-tree, and they have a regression in
v2.0. It's better to start warning the users as soon as possible.
Can't possibly introduce regressions.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
contrib/remote-helpers/git-remote-bzr | 3 +++
contrib
William Giokas wrote:
On Tue, May 13, 2014 at 03:24:51PM -0500, Felipe Contreras wrote:
William Giokas wrote:
On Tue, May 13, 2014 at 02:09:55PM -0500, Felipe Contreras wrote:
As you say, it's perfectly OK.
But wrong. Yes, it works, but it's not how it should be done when we
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
The tools are now maintained out-of-tree, and they have a regression in
v2.0.
You seem not to understand at all what a regression is.
My understanding is that versions of remote-hg shipped with all
versions
, because Junio said so, then he changed his mind and
didn't want to explain his reasoning.
It's not just a bad day.
--
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:
Sigh, you just don't seem to understand that you are thinking about a
different issue. I don't think there's any other way I can explain it to
you.
Perhaps pointing out which commit(s) to revert might be a good
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio, do you honestly think I am a troll?
You certainly are acting like one, aren't you?
I'm deeply offended by the fact that would think that I'm purposely
intent on provoking people, or disrupting more important
brain, or just it fails to grab
your attention.
But if I have to adjust for saying that (which was true), what do you
say to Junio for saying this? (which was not)
Stop this idiocy.
I presume nothing, because Junio is a riskier target.
--
Felipe Contreras
--
To unsubscribe from this list: send
Linus Torvalds wrote:
On May 12, 2014 8:35 AM, Felipe Contreras felipe.contre...@gmail.com
wrote:
This move is already
under way, but suddenly Junio changed his mind.
That suddenly wouldn't have anything to do with you being an ass and
difficult as usual, arguing about everything
Felipe Contreras wrote:
Linus Torvalds wrote:
Felipe, stop this stupid blaming of everybody but yourself.
Show me evidence that this decision was my fault. Junio certainly hasn't
said so. You just have no idea what we are talking about.
Here, let me show you.
Junio, can you answer
Michael Haggerty wrote:
On 05/12/2014 01:34 AM, Felipe Contreras wrote:
Recently Junio said he was willing to hear the opinion of other people
regarding the move from contrib to the core[1]. This move is already
under way, but suddenly Junio changed his mind.
I agree with Junio
Stefan Beller wrote:
2014-05-12 10:12 GMT+02:00 Felipe Contreras felipe.contre...@gmail.com:
Felipe Contreras wrote:
Linus Torvalds wrote:
Felipe, stop this stupid blaming of everybody but yourself.
Show me evidence that this decision was my fault. Junio certainly hasn't
said so. You
Michael Haggerty wrote:
On 05/12/2014 12:37 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
On 05/12/2014 01:34 AM, Felipe Contreras wrote:
Recently Junio said he was willing to hear the opinion of other people
regarding the move from contrib to the core[1]. This move is already
working on what I think is
important.
If you really think the patches can be accepted with a different
attitude, by all means, let's do the experiment and find out.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 2:48 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Paolo Ciarrocchi wrote:
On Mon, May 12, 2014 at 11:42 AM, Michael Haggerty
mhag...@alum.mit.eduwrote:
While I agree with you the this project is managed in a bit conservative
Michael Haggerty wrote:
On 05/12/2014 02:29 PM, Felipe Contreras wrote:
Michael Haggerty wrote:
[...]
2. Moving git-remote-hg into the core would require you to continue your
presence on the Git mailing list.
That is another red herring. Moving them back to the contrib/ area which
hg, or rebuild Git and cherry-pick this commit:
No need to rebuild Git.
You can also use the latest version:
https://github.com/felipec/git-remote-hg
--
Felipe Contreras--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
an
agreement on future behavior is in the best interest of our users. Will
you do it?
*1* http://thread.gmane.org/gmane.comp.version-control.git/248063/focus=248341
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
...
I was originally led to believe that its code quality was good
enough, and that was why I merged the bottom three patches of the
series even down to 'next' in the first place
of the week, this is how I silenced
the warnings in git-fc:
https://github.com/felipec/git/commit/e14ca39ba0092f0305d5fb347e20b829f736b29b
--
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
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
* fc/remote-helpers-hg-bzr-graduation (2014-04-29) 11 commits
- remote-hg: trivial cleanups
- remote-hg: make sure we omit multiple heads
- git-remote-hg: use internal clone's hgrc
-control.git/248676
[2] http://article.gmane.org/gmane.comp.version-control.git/248167
[3] http://article.gmane.org/gmane.comp.version-control.git/248683
[4] https://travis-ci.org/felipec/git
[5] http://article.gmane.org/gmane.comp.version-control.git/220277
--
Felipe Contreras
--
To unsubscribe from
Felipe Contreras wrote:
== git update ==
Another proposed solution is to have a new command: `git update`. This
command would be similar to `git pull --ff-only` by default, but it
could be configured to do merges instead, and when doing so in reverse.
And here it is:
https://github.com
1 - 100 of 3053 matches
Mail list logo
