On Wed, Sep 11, 2013 at 6:38 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
So, you insist in asking the user to chose between rebase and merge, but
On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
The problem is the newcomers, and the newcomers will most definitely
not activate a configuration option to tell them that they are doing
something potentially
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 10, 2013 at 3:26 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
So, you insist in asking the user to chose between rebase and merge, but
you also insist that they will not chose rebase? So, why ask?
Because as you said,
On Mon, Sep 09, 2013 at 06:02:35PM -0500, Felipe Contreras wrote:
On Mon, Sep 9, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk wrote:
On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
You are in favor of an
Felipe Contreras felipe.contre...@gmail.com writes:
The problem is the newcomers, and the newcomers will most definitely
not activate a configuration option to tell them that they are doing
something potentially undesirable.
I teach Git to 200 newcommers each year. All of them run git pull
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I think other people are also in
agreement.
Yes. Having an option can't harm anybody, and there's a clear
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
Yes, that would be me. My hesitance here is that as the one usually
driving git updates (which so far have happened once a year), I will end
up
Matthieu Moy matthieu@grenoble-inp.fr writes:
First, the discussions on this thread show that it's hard to find the
right behavior. My guess is that it's hard because we're trying to think
for the users. I've used GNU Arch for a while, and this VCS was trying
to impose what the developer
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I think other people are also in
agreement. So perhaps:
- drop jc/pull-training-wheel and revert its merge from 'next';
- update
On Sun, Sep 08, 2013 at 11:03:52AM +0100, John Keeping wrote:
I know those are all balanced by some advantages of rebasing, but I also
think they are things that can be troublesome for a user who does not
fully grok the rebase process. I'm just wondering if we should mention
both, but
On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most frequently, what kinds of workflows they tend to
see, etc. Their
On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I think other people are also in
agreement. So perhaps:
- drop
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
I think that would address the concern I raised, because it does not
create a roadblock to new users accomplishing their task. They can
ignore the warning, or choose merge as the default to shut up the
warning (and it is easy
John Keeping j...@keeping.me.uk writes:
I think we need to make sure that we give instructions for how to go
back if the default hasn't done what you wanted. Something like this:
Your pull did not fast-forward, so Git has merged '$upstream' into
your branch, which may not be correct
Junio C Hamano gits...@pobox.com writes:
You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I think other people are also in
agreement.
Yes. Having an option can't harm anybody, and there's a clear demand for
that.
So perhaps:
- drop
On Mon, Sep 09, 2013 at 04:44:16PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
I think that would address the concern I raised, because it does not
create a roadblock to new users accomplishing their task. They can
ignore the warning, or choose
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:
John Keeping j...@keeping.me.uk writes:
I think we need to make sure that we give instructions for how to go
back if the default hasn't done what you wanted. Something like this:
Your pull did not fast-forward, so Git
From: Jeff King p...@peff.net
Sent: Monday, September 09, 2013 9:53 PM
On Mon, Sep 09, 2013 at 10:50:31PM +0200, Matthieu Moy wrote:
John Keeping j...@keeping.me.uk writes:
I think we need to make sure that we give instructions for how to
go
back if the default hasn't done what you
On 2013-09-09 16:44, Jeff King wrote:
On Mon, Sep 09, 2013 at 09:24:35PM +0100, John Keeping wrote:
I think we need to make sure that we give instructions for how to go
back if the default hasn't done what you wanted. Something like this:
Your pull did not fast-forward, so Git has merged
On Mon, Sep 9, 2013 at 3:24 PM, John Keeping j...@keeping.me.uk wrote:
On Mon, Sep 09, 2013 at 03:52:31PM -0400, Jeff King wrote:
On Mon, Sep 09, 2013 at 11:47:45AM -0700, Junio C Hamano wrote:
You are in favor of an _option_ to allow people to forbid a pull in
a non-ff situation, and I
On Mon, Sep 9, 2013 at 3:17 PM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 03:50:46AM -0400, Jeff King wrote:
If you are interested, I can ask the opinion of some of the GitHub
trainers. They see a lot of new users and have a sense of what kinds of
confusion come up most
On Mon, Sep 9, 2013 at 2:18 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
Yes, that would be me. My hesitance here is that as the one usually
On Sun, Sep 8, 2013 at 12:21 AM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told replace
svn commit with git
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Which can be solved by adding the above fail option, and then
renaming them to pull.integrate and branch.name.integrate to
clarify what these variables are about (it is no
On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
I think it's fine to tell them to do git pull --merge. What I'd worry
more about is somebody who is suddenly presented with the choice between
--rebase and --merge and doesn't know which to choose. We've created a
cognitive
On Sun, Sep 8, 2013 at 1:54 AM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote:
I think it's fine to tell them to do git pull --merge. What I'd worry
more about is somebody who is suddenly presented with the choice between
--rebase and
On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
I think the guy may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'? Certainly not git.
Any of the hundreds of existing tutorials that
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 3:34 AM
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping j...@keeping.me.uk
wrote:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If
On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley philipoak...@iee.org wrote:
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 3:34 AM
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping j...@keeping.me.uk wrote:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano
From: Felipe Contreras felipe.contre...@gmail.com
To: Philip Oakley philipoak...@iee.org
Cc: John Keeping j...@keeping.me.uk; Junio C Hamano
gits...@pobox.com; git@vger.kernel.org; Andreas Krey
a.k...@gmx.de
Sent: Sunday, September 08, 2013 9:16 AM
Subject: Re: [PATCH 0/3] Reject non-ff pulls
On Sun, Sep 8, 2013 at 2:50 AM, Jeff King p...@peff.net wrote:
On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote:
I think the guy may be git itself. For example, here is a possible
session with jc/pull-training-wheel:
$ git push
Who told him to use 'git push'?
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley philipoak...@iee.org wrote:
The 'problem' is (would be) that I don't yet know that I would need the
--onto pu until I discover (how?) that the default rebase would result in
conflicts.
I don't see what that has to do with an invocation of 'git
From: Felipe Contreras felipe.contre...@gmail.com
Sent: Sunday, September 08, 2013 9:49 AM
On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley philipoak...@iee.org
wrote:
The 'problem' is (would be) that I don't yet know that I would need
the
--onto pu until I discover (how?) that the default
On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote:
I am genuinely curious what people in favor of this feature would want
to say in the documentation to a user encountering this choice for the
first time. In my experience, rebasing introduces more complications,
specifically:
1.
From: Philip Oakley philipoak...@iee.org
[2] http://dx.doi.org/10.%2F1467-8721.01235 Why People Fail to
Recognize Their Own Incompetence.
Oops, That's behind a paywall, and a more recent variant.
Though the corollaries
(People fail to recognise
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King p...@peff.net wrote:
By svn-like, I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
Richard Hansen rhan...@bbn.com writes:
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Which can be solved by adding the above fail option, and then
renaming them to pull.integrate and branch.name.integrate to
clarify
On 2013-09-08 14:10, Junio C Hamano wrote:
Richard Hansen rhan...@bbn.com writes:
What about something like:
pull.mergeoptions (defaults to --ff-only)
pull.rebaseoptions (defaults to empty? --preserve-merges?)
branch.name.pull.mergeoptions (defaults to pull.mergeoptions)
On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King p...@peff.net wrote:
$ hack hack hack
$ svn commit ;# oops, somebody else committed in the
From: Junio C Hamano gits...@pobox.com
Sent: Sunday, September 08, 2013 7:10 PM
Richard Hansen rhan...@bbn.com writes:
On 2013-09-07 22:41, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com
wrote:
Which can be solved by adding the above fail option,
On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano gits...@pobox.com wrote:
pull.someoption = rebase | merge [| always-fail]
makes that choice in a clear way, I think.
Regarding the verb integrate.
I doubt anybody thinks of pull being an integration, and even if it
is, it's still doesn't
Felipe Contreras wrote:
On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano gits...@pobox.com wrote:
pull.someoption = rebase | merge [| always-fail]
makes that choice in a clear way, I think.
The core issue is that users rarely want to merge locally: that's the
maintainer's job. Users simply
On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do, will they choose 'git pull --rebase' by mistake?
I agree, they will not choose git
On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson
sand...@crustytoothpaste.net wrote:
On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
Yeah, but the key question at hand in this discussion is; what happens
when 'git pull' stops working for them, and they don't know what to
do,
On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
My patches pretty much do nothing else but introduce a warning.
Nothing is broken, nothing is changed in the test suite:
http://article.gmane.org/gmane.comp.version-control.git/233669
You are confusing my
On Sun, Sep 08, 2013 at 07:36:21PM -0500, Felipe Contreras wrote:
On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
My patches pretty much do nothing else but introduce a warning.
Nothing is broken, nothing is changed in the test suite:
On Fri, Sep 06, 2013 at 03:14:25PM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@gmail.com writes:
John Keeping wrote:
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I am
On Thu, Sep 5, 2013 at 3:06 AM, John Keeping j...@keeping.me.uk wrote:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches from the other
side? Nothing?
One
On Fri, Sep 6, 2013 at 5:14 PM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
John Keeping wrote:
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I
On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano gits...@pobox.com wrote:
Which can be solved by adding the above fail option, and then
renaming them to pull.integrate and branch.name.integrate to
clarify what these variables are about (it is no longer do you
rebase or not---if you choose not
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King p...@peff.net wrote:
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like workflow without thinking too hard about it.
How? Subversion would complain
On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King p...@peff.net wrote:
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be annoying clueless new users who simply want an
svn-like
On Sat, Sep 7, 2013 at 11:18 PM, Jeff King p...@peff.net wrote:
On Sat, Sep 07, 2013 at 09:52:16PM -0500, Felipe Contreras wrote:
On Wed, Sep 4, 2013 at 4:25 AM, Jeff King p...@peff.net wrote:
The patch in jc/pull-training-wheel talks about annoying old timers, but
I think you may also be
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
By svn-like, I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git pull
$ git push
But that's not svn-like at all.
It's not if
On Sat, Sep 7, 2013 at 11:43 PM, Jeff King p...@peff.net wrote:
On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote:
By svn-like, I mean the people whose workflow is:
$ hack hack hack
$ git commit
$ git push ;# oops, somebody else pushed in the meantime
$ git
On Sun, Sep 08, 2013 at 12:09:34AM -0500, Felipe Contreras wrote:
It's not if you understand the difference between merge-then-commit and
commit-then-merge. But for a clueless user who has been told replace
svn commit with git commit git push and replace svn update with
git pull, it is
John Keeping wrote:
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I am not remembering correctly.
It just does @{upstream} by default, which tends to get messy if the
upstream has
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches from the other
side? Nothing?
One other thing that I can see being useful occasionally is:
git rebase
On Thu, Sep 05, 2013 at 07:01:03AM -0400, John Szakmeister wrote:
On Wed, Sep 4, 2013 at 6:59 PM, Junio C Hamano gits...@pobox.com wrote:
[snip]
When git pull stops because what was fetched in FETCH_HEAD does
not fast-forward, then what did _you_ do (and with the knowledge you
currently
Junio C Hamano gits...@pobox.com writes:
Peff already covered (1)---it is highly doubtful that a merge is
almost always wrong. In fact, if that _were_ the case, we should
simply be defaulting to rebase, not failing the command and asking
between merge and rebase like jc/pull-training-wheel
On 2013-09-04 18:59, Junio C Hamano wrote:
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
John Keeping j...@keeping.me.uk writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches
John Keeping j...@keeping.me.uk writes:
On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote:
Are there cases where you do not want to either rebase nor merge?
If so what do you want to do after git pull fetches from the other
side? Nothing?
One other thing that I can see being
From: Junio C Hamano gits...@pobox.com
Philip Oakley philipoak...@iee.org writes:
From: Junio C Hamano gits...@pobox.com
John Keeping j...@keeping.me.uk writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
...
Peff already covered (1)---it is highly
Junio C Hamano gits...@pobox.com writes:
I can imagine users might want to say when I am on these small
number of branches, I want to merge (or rebase), but when I am on
other, majority of my branches, because they are private, unfinished
and unpublished work, please stop me from accidentally
Philip Oakley philipoak...@iee.org writes:
It's not clear to me that a single default that uses a merge or
rebase, without a 'stop if' criteria would be of any help in my
situation.
My thoughts are that the options on a fetch-pull are for the branch to
be:
* Overwritte (--force) (i.e. a
On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio already sent a similar patch, but I
On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong thing to do since it will be
backwards and break --first-parent.
On Wed, Sep 04, 2013 at 05:25:27AM -0400, Jeff King wrote:
On Wed, Sep 04, 2013 at 09:10:47AM +0100, John Keeping wrote:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong
John Keeping j...@keeping.me.uk writes:
On Tue, Sep 03, 2013 at 03:38:58PM -0700, Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
From: Junio C Hamano gits...@pobox.com
John Keeping j...@keeping.me.uk writes:
I think there are two distinct uses for pull, which boil down to:
(1) git pull
(2) git pull $remote $branch
For (1) a merge is almost always the wrong thing to do since it will
be
backwards and break
Felipe Contreras felipe.contre...@gmail.com writes:
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure if the behaviour is
necessarily better (note that this is different from saying I think
the behaviour of this patch is worse).
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure if the behaviour is
necessarily better (note that this
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio already sent a similar patch, but I think this is simpler.
I agree that this is simpler, but I am not sure
On Tue, Sep 3, 2013 at 5:38 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Sep 3, 2013 at 12:21 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio already sent a similar patch, but I
Junio already sent a similar patch, but I think this is simpler.
Felipe Contreras (3):
merge: simplify ff-only option
t: replace pulls with merges
pull: reject non-ff pulls by default
Documentation/git-pull.txt | 1 +
builtin/merge.c| 20
76 matches
Mail list logo
