he makefile fixed
> up and hopefully then have more people package 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
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
---
contrib/remote-helpers/test-hg.sh | 150 ++
1 file changed, 150 insertions(+)
diff --git a/contrib/r
Inspired by gitifyhg.
Signed-off-by: Felipe Contreras
---
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..df09966 100755
--- a
Signed-off-by: Felipe Contreras
---
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/remote-helpers/git-remote-hg
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/r
There was a broken && chain, and cat is simpler than echo in a subshell.
Signed-off-by: Felipe Contreras
---
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/remote-help
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).
> >
re what is the track record
of the people in the discussion. If their argument is good, 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 &q
flags are frowned upon, so let's just avoid the warning altogether.
Signed-off-by: Felipe Contreras
---
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 9cfef6c.
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 reaso
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-
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.
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 specifi
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
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 un
ast
majority of people would want.
Even more, I'm 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 &q
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
it/233554
[2] http://article.gmane.org/gmane.comp.version-control.git/234295
[3] http://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.o
p://training.github.com/kit/
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 "uns
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 e208f9cc7574f5980faba498d0aa30b4defeb34
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:
> >
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
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
gt; + # MinGW-W64 < x.y headers do not provide 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
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
> > > > >
'!git remote update -p; git update-branch -a'
>
> If there's interest I can tweak the style to conform 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 up
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 un
t to defer that one
for later, but eventually do it.
I'd say for v2.0 we should go for 1), and 2) should be considered for
v3.0, perhaps.
[1] http://article.gmane.org/gmane.comp.version-control.git/248065
[2] https://travis-ci.org/felipec/git
[3] https://github.com/felipec/git/wiki/Compariso
Mostly copied from my personal github wiki.
Signed-off-by: Felipe Contreras
---
Documentation/git-remote-bzr.txt | 74
Documentation/git-remote-hg.txt | 121 +++
2 files changed, 195 insertions(+)
create mode 100644 Documentation
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 contr
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 unsubscrib
;s because remote-hg/bzr
had already the code for these features, it was just not exercised until
the transport-helper was modified.
I think the current transport-helper infraestructure is already good
enough to detect the features and options of the remote helpers so
unbundling wouldn't be a
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
new
> feature until you update Git" and "if you update Mercurial then the
> remote helper will stop working",
s/the remote helper will stop working/certain features of the remote
helper *might* stop working, but we are trying hard to make sure that
doesn't happen/
--
it/233554
[2] http://article.gmane.org/gmane.comp.version-control.git/234295
[3] http://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.o
them by default.
That implies that git-remote-hg would become a baggage to Git as a
whole.
If you are arguing that git-remote-hg should be distributed by default,
and only if the dependencies become a problem, demote to 'contrib/' that
is fine. The same for git-p4 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
l stop working", and that's why I think the
> > remote 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
ur of the new command is to
>replay the first-parent history on top 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,
mpt (2014-04-24) 2 commits
+ mergetool: document the default for --[no-]prompt
+ mergetool: run prompt only if guessed tool
Plus this one which has been completely ignored:
completion: move out of contrib
Since you are not going to do so, I do not feel compelled to fix the
synchronization
Junio C Hamano wrote:
> Felipe Contreras 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 integr
#x27;s standalone.
[1] https://github.com/mlafeldt/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 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.
> &
he user has installed Git in his $home, when building a
package the package manager would use ~/libexec/git-core, which is
wrong.
Moreover, if you are cross-compiling you won't be able to run the
target's `git` binary.
If anything, it should be `pkg-config --variable=exec-path git`.
It's better if all our scripts use the same '/usr/bin/env python'.
Signed-off-by: Felipe Contreras
---
contrib/hooks/multimail/README | 6 +++---
contrib/hooks/multimail/git_multimail.py| 2 +-
contrib/hooks/multimail/migrate-mailhook-config | 2 +-
Felipe Contreras wrote:
> Yes, *if* they have been packaging them, they have a way. But what if
> they haven't been doing so?
>
> And for the ones that have a way, now they need one hack less.
As an example of all the hacks needed by a real distribution package,
here'
Johan Herland wrote:
> On Wed, May 7, 2014 at 12:03 PM, Felipe Contreras
> wrote:
> > It's better if all our scripts use the same '/usr/bin/env python'.
>
> Only if they are source compatible with both Python2 and Python3. See
> PEP394 http://legacy.python
Junio C Hamano wrote:
> Felipe Contreras 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-graduation
Really? Based on wh
Matthieu Moy wrote:
> Felipe Contreras writes:
>
> > It's better if all our scripts use the same '/usr/bin/env python'.
>
> Why?
>
> Using python2 for git_multimail.py is a deliberate decision:
If you want to use python2, then use '/usr/bin/env py
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > As an example of all the hacks needed by a real distribution package,
> > here's the stuff ArchLinux packagers have to do:
> >
> > # bash completion
> > mkdir -p "$pkgdir"/usr/sha
isn't a standard $HTML_PATH to
> match $MAN_PATH and $PATH.
Using `git --html-path` for that is wrong.
--
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
r things for
> less popular remote helpers, that starts to be a real burden.
It doesn't *need* them to build. The Mercurial/Bazaar dependencies are
optional, both at build-time and at run-time. Most distributions would
want to test the functionality they are distributing, and for testing
th
ttps://github.com/felipec/git-reintegrate
[2]
https://github.com/felipec/git-reintegrate/commit/332412470c6e084f10ac2f8dc11e86ab4680974a
--
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 writes:
> > Really? Based on what reasoning? I have proven his reasoning to be
> > basically wrong.
>
> Perhaps s/proven/convinced myself only/; you didn't prove it to me
> and I doubt you proved it to John.
And you are st
Matthieu Moy wrote:
> Felipe Contreras writes:
> > If you want to use python2, then use '/usr/bin/env python2'.
>
> Err, yes, this is what the code does before your patch.
Not for all the instances.
> > If you are going to follow practices different than git.gi
John Keeping wrote:
> On Wed, May 07, 2014 at 03:26:15PM -0500, Felipe Contreras wrote:
> > Junio C Hamano wrote:
> > > Your git-integrate might turn into something I could augment my
> > > workflow with with some additions.
> > >
> > > - specif
Greg Troxel wrote:
>
> Felipe Contreras 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 dependenc
Junio C Hamano wrote:
> Felipe Contreras 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 remo
Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Felipe Contreras 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
> > rushin
that would be a possibility,
but they are more like a hack.
--
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
ake it a separate follow-up patch with a log message
> that explains why it now uses LookupError (not ManifestLookupError),
> or do you want to reroll the original by squashing it?
I don't want to do anything for a "contrib" tool.
It's already broken in v2.0 anyway.
ny more git-remote-hg patches from me. If Junio thinks
it's just another crappy contrib tool, then I'll threat it as one.
And unfortunately Junio would rather let an important part of Git die a
slow death rather than admit he was wrong. Just watch him ignore the
problem.
--
Felipe Contreras
tenance releases)
> is also fine by me.
Are you saying that the graduation plan is going to continue and they
are going to move out of contrib and be distributed by default?
If that's the case I'll resume the fixes because the current sitution is
not good.
--
Felipe Contrera
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > I already said this multiple times, but let me be clear once more:
> >
> > MASTER HAS A REGRESSION (for all versions of Mercurial).
>
> As you said, that is not a regression, isn't it? It is an old
>
Felipe Contreras wrote:
> Junio C Hamano wrote:
> > I do not see a strong reason to move it out of contrib, either.
>
> Really? So why did you say this?[2]
>
> > > Either way, I think if things go well, remote-hg will prove it's
> > > worth an
David Lang wrote:
> On Thu, 8 May 2014, Felipe Contreras wrote:
> > If submodules were an integral part of Git that would be a possibility,
> > but they are more like a hack.
>
> Well, if git.git can't use them, then how can anyone else be expected to.
That is a very g
te even if they are perfect. These
tools apparently should live out-of-tree.
After the cleanup, the only tools that remain are 'completion',
'credential' and 'subtree', which might eventually graduate.
Felipe Contreras (25):
Remove remote-helpers
contrib: remove
There hasn't been any real activity on it since 2010.
Plus there are better out-of-tree tools.
No tests and no real documentation either.
Cc: Miklos Vajna
Signed-off-by: Felipe Contreras
---
contrib/hg-to-git/hg-to-git.py | 255
contrib/hg-to-g
No activity since 2010, no tests.
Cc: Tim Henigan
Signed-off-by: Felipe Contreras
---
contrib/diffall/README | 31 --
contrib/diffall/git-diffall | 257
2 files changed, 288 deletions(-)
delete mode 100644 contrib/diffall/README
delete
No activity since 2010, no documentation, no tests.
Signed-off-by: Felipe Contreras
---
contrib/buildsystems/Generators.pm| 42 --
contrib/buildsystems/Generators/QMake.pm | 189 -
contrib/buildsystems/Generators/Vcproj.pm | 626 --
contrib
No real activity since 2012 (or ever), no tests, no documentation.
Signed-off-by: Felipe Contreras
---
contrib/stats/git-common-hash | 26 --
contrib/stats/mailmap.pl | 70 --
contrib/stats/packinfo.pl | 212 --
3 files changed
No activity since 2010, no tests, no documentation.
Signed-off-by: Felipe Contreras
---
contrib/convert-objects/convert-objects.c | 329
contrib/convert-objects/git-convert-objects.txt | 29 ---
2 files changed, 358 deletions(-)
delete mode 100644 contrib
No activity, no tests.
Signed-off-by: Felipe Contreras
---
contrib/git-jump/README | 92 ---
contrib/git-jump/git-jump | 69 ---
2 files changed, 161 deletions(-)
delete mode 100644 contrib/git-jump/README
delete
There are better out-of-tree tools, and this tool is not planned to move
into the core anyway.
No tests either.
Cc: Eric Sunshine
Signed-off-by: Felipe Contreras
---
contrib/contacts/git-contacts | 203 --
contrib/contacts/git-contacts.txt | 94
No tests, no documentation.
No chance of ever graduating.
Cc: Johannes Schindelin
Cc: David Aguilar
Signed-off-by: Felipe Contreras
---
contrib/fast-import/git-import.perl | 64 -
contrib/fast-import/git-import.sh | 38 ---
contrib/fast-import/git-p4.README
No activity, no tests.
Signed-off-by: Felipe Contreras
---
contrib/git-shell-commands/README | 18 --
contrib/git-shell-commands/help | 18 --
contrib/git-shell-commands/list | 10 --
3 files changed, 46 deletions(-)
delete mode 100644 contrib/git
No activity since 2007. No documentation, no tests.
Signed-off-by: Felipe Contreras
---
contrib/remotes2config.sh | 33 -
1 file changed, 33 deletions(-)
delete mode 100755 contrib/remotes2config.sh
diff --git a/contrib/remotes2config.sh b/contrib
No activity, no tests.
Signed-off-by: Felipe Contreras
---
contrib/thunderbird-patch-inline/README | 20
contrib/thunderbird-patch-inline/appp.sh | 55
2 files changed, 75 deletions(-)
delete mode 100644 contrib/thunderbird-patch-inline/README
No activity since 2010, no documentation, no tests.
Signed-off-by: Felipe Contreras
---
contrib/workdir/git-new-workdir | 82 -
1 file changed, 82 deletions(-)
delete mode 100755 contrib/workdir/git-new-workdir
diff --git a/contrib/workdir/git-new
No activity. No tests.
No chance of ever moving into the core because it uses Go.
Signed-off-by: Felipe Contreras
---
contrib/persistent-https/LICENSE | 202 -
contrib/persistent-https/Makefile | 38 ---
contrib/persistent-https/README| 62
No activity since 2012, no tests, no chance of ever graduating.
Cc: Jeff King
Signed-off-by: Felipe Contreras
---
contrib/diff-highlight/README | 152 -
contrib/diff-highlight/diff-highlight | 173 --
2 files changed, 325
No activity since 2007.
Better out-of-tree tools out there.
Cc: Aneesh Kumar K.V
Signed-off-by: Felipe Contreras
---
contrib/gitview/gitview | 1305 ---
contrib/gitview/gitview.txt | 57 --
2 files changed, 1362 deletions(-)
delete mode 100755
No activity since 2008, no tests, no documentation.
Cc: Gerrit Pape
Cc: Shawn O. Pearce
Cc: Andy Parkins
Signed-off-by: Felipe Contreras
---
contrib/hooks/post-receive-email | 759 --
contrib/hooks/pre-auto-gc-battery | 42 ---
contrib/hooks
No activity since 2012, no tests.
Cc: Jonathan Nieder
Signed-off-by: Felipe Contreras
---
contrib/svn-fe/.gitignore | 4 ---
contrib/svn-fe/Makefile| 63 -
contrib/svn-fe/svn-fe.c| 18 ---
contrib/svn-fe/svn-fe.txt | 71
No activity, no documentation, no tests, no chance of ever graduating.
Signed-off-by: Felipe Contreras
---
contrib/git-resurrect.sh | 182 ---
1 file changed, 182 deletions(-)
delete mode 100755 contrib/git-resurrect.sh
diff --git a/contrib/git
There's nothing there.
Signed-off-by: Felipe Contreras
---
contrib/vim/README | 22 --
1 file changed, 22 deletions(-)
delete mode 100644 contrib/vim/README
diff --git a/contrib/vim/README b/contrib/vim/README
deleted file mode 100644
index 8f16d06..000
--- a/co
No activity, no nothing.
Signed-off-by: Felipe Contreras
---
contrib/rerere-train.sh | 52 -
1 file changed, 52 deletions(-)
delete mode 100755 contrib/rerere-train.sh
diff --git a/contrib/rerere-train.sh b/contrib/rerere-train.sh
deleted file
No updates since 2010, and no tests.
Plus, foreign SCM tools should live out-of-tree anyway.
Cc: Eric Wong
Cc: Martin Langhoff
Signed-off-by: Felipe Contreras
---
.gitignore |1 -
Documentation/git-archimport.txt | 112
Makefile |1
e these unused tools.
Felipe Contreras (2):
Remove 'git archimport'
Remove 'git quiltimport'
.gitignore|2 -
Documentation/git-archimport.txt | 112
Documentation/git-quiltimport.txt | 54 --
Makefile |2 -
No updates since 2009 and no tests.
Foreign SCM tools should live out-of-tree anyway.
Cc: Johannes Schindelin
Signed-off-by: Felipe Contreras
---
.gitignore| 1 -
Documentation/git-quiltimport.txt | 54 ---
Makefile | 1
Jeff King wrote:
> On Thu, May 08, 2014 at 07:58:30PM -0500, Felipe Contreras wrote:
>
> > No activity since 2012, no tests, no chance of ever graduating.
>
> I don't think "no activity" is an interesting indicator. This tool _is_
> actively maintained, but it
Martin Langhoff wrote:
> On Thu, May 8, 2014 at 8:58 PM, Felipe Contreras > wrote:
>
> > Let us be honest, the vast majority of tools in 'contrib/' have no chance
> > of
> > ever graduating, so let's remove them.
> >
>
> I am curious
lly I try to follow pep8 in git-remote-{hg,bzr}, but only to some
extent.
I do this:
[pep8]
ignore = E401,E302,E201,E202,E203,E126,E128
max-line-length = 160
That said there's a couple of issues present that I didn't notice.
Thanks for checking.
--
Felipe Contreras
--
To unsubscrib
Jeff King wrote:
> On Thu, May 08, 2014 at 07:58:18PM -0500, Felipe Contreras wrote:
>
> > No activity, no tests.
>
> Like diff-highlight, I don't think "no activity" is a useful indicator.
> I use this daily, and several people have commented off-list to me
If some weird distribution has a problem with the location, they can
override 'bashcompdir' anyway.
[1] http://article.gmane.org/gmane.linux.redhat.fedora.devel/177405
Signed-off-by: Felipe Contreras
---
Makefile | 6 ++
{contrib/completion =>
Actually we need a symlink for gitk. At least ArchLinux doesn't do that,
so we would be fixing at least one bug.
Signed-off-by: Felipe Contreras
---
Makefile | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Makefile b/Makefile
index 2690903..a3d27d8 100644
--- a/Makefile
+++ b/Mak
William Giokas wrote:
> On Thu, May 08, 2014 at 09:10:25PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > Which is a whole bunch of errors and warnings thrown by pep8. Is pep8
> > > just getting put by the wayside? I would much rather have these
> &
Eric Wong wrote:
> Felipe Contreras wrote:
> > No updates since 2010, and no tests.
>
> Who benefits from this removal? Is this causing a maintenance
> burden for Junio?
It is cruft that nobody uses and we are not even testing.
> > Plus, foreign SCM tools should
William Giokas wrote:
> On Thu, May 08, 2014 at 11:36:29PM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > E401: Multi-line imports seems like something that would just be
> > > changing one line
> >
> > Yes, and make the code very annoying.
William Giokas wrote:
> On Fri, May 09, 2014 at 02:18:54AM -0500, Felipe Contreras wrote:
> > William Giokas wrote:
> > > On Thu, May 08, 2014 at 11:36:29PM -0500, Felipe Contreras wrote:
> > > > William Giokas wrote:
> > > > > E401: Multi-line im
401 - 500 of 3330 matches
Mail list logo
