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
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
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
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 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
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 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
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
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
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
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
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
>
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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:
>
> > 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
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
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'
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 +-
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`.
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.
> &
#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:
> > 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
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
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,
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
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
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
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/
--
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
;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:
> 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
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
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
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
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
'!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
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
> > > > >
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
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
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
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 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
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
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
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
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
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
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
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
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.
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);
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-
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
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).
> >
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
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
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
Philip Oakley wrote:
> From: "Felipe Contreras"
> > 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 d
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 curren
ath represents a series of completed tasks
It is very rare that an integrator is even able to do a fast-forward
merge anyway. So being explicit about --no-ff might better, but it would
hardly make a difference. Either way, a good integrator would configure
pull.ff = false.
I'd say `git pull origin 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
greement
> > about what 'git pull' should do.
>
> 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 im
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.
>
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 Cont
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
Philip Oakley wrote:
> From: "Felipe Contreras"
> > 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 b
201 - 300 of 3330 matches
Mail list logo
