On Thu, May 23, 2013 at 06:53:36PM -0500, Felipe Contreras wrote:
The alternatives are these:
a) you annoy the vast majority of the user-base by making 'git pull' a
dangerous operation that should be avoided, and replaced with 'git
fetch'+'git rebase'.
b) you annoy a minority of the
Am 23.05.2013 21:25, schrieb Andreas Krey:
On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote:
...
...
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
On Fri, May 24, 2013 at 4:29 AM, John Keeping j...@keeping.me.uk wrote:
[snip]
Note that in my email that started this, I tried to be clear that I was
talking about git pull *without a branch name*. If this user
explicitly says git pull remote branch then I consider that a clear
indication
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost completely meaningless. I could just
do my
Am 24.05.2013 15:42, schrieb Andreas Krey:
On Fri, 24 May 2013 11:29:00 +, Holger Hellmuth (IKS) wrote:
...
Here is an idea (probably already discussed in the long history of git):
1) the branch name is recorded in a commit (for merges the branch that
is updated)
The branch name is almost
Felipe Contreras felipe.contre...@gmail.com writes:
... but I don't see why something small like that
wouldn't make sense:
The pull was not fast-forward, please either merge or rebase.
OK, I think I got what John was getting at and this single liner
message is a good summary of it.
Instead
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
Instead of having a nice these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully history that explains how these commits were
related and these commits are
On Fri, 24 May 2013 17:05:26 +, Holger Hellmuth (IKS) wrote:
Am 24.05.2013 15:42, schrieb Andreas Krey:
...
The branch name is almost completely meaningless. I could just
do my feature in my local master and never have a different name.
In which case parent switching in the commit
Andreas Krey a.k...@gmx.de writes:
On Thu, 23 May 2013 09:01:15 +, Junio C Hamano wrote:
...
Instead of having a nice these six commits marked as 'x' were done
on a branch forked some time ago, to address only this one issue and
to address it fully history that explains how these commits
On Wed, 22 May 2013 11:07:07 +, Junio C Hamano wrote:
...
If you have a four-commit segment in your commit ancestry graph
I never had yet. :-(
(time flows from left to right; turn your head 90-degrees to the
right if you want a gitk representation):
---A--X
\/
/\
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote:
[snip]
...
Don't do that, then.
:-) Problem is, in this case 'I' expands to about
17 people I need to educate on this.
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as
- Mail original -
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote:
[snip]
...
Don't do that, then.
:-) Problem is, in this case 'I' expands to about
17 people I need to educate on this.
This is a feature of `git pull` that I really despise. I really
On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
...
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as the first parent in its merge
operation.
I'd actually only like it that way when pulling from
the tracking branch, not for any
On Thu, May 23, 2013 at 12:29:59PM +0200, Andreas Krey wrote:
On Thu, 23 May 2013 05:48:38 +, John Szakmeister wrote:
...
This is a feature of `git pull` that I really despise. I really wish
`git pull` treated the remote as the first parent in its merge
operation.
I'd actually only
On Wed, May 22, 2013 at 6:50 AM, Andreas Krey a.k...@gmx.de wrote:
Hi everyone,
I'm just looking into better displays of the commit graph (as
displayed with gitk, smartgit, fisheye) - they tend to quickly
dissolve into a heap of spaghetti.
We had the idea that treating the first parent
On Thu, 23 May 2013 06:34:38 +, Felipe Contreras wrote:
...
I don't understand; gitk already shows the first parent starting from
the bottom, and the merge commits arrive from the right side. What am
I missing?
That this isn't (consistently) the case in complicated situations.
I'll need to
John Keeping j...@keeping.me.uk writes:
I've been annoyed by this at $DAYJOB recently. A lot of people seem to
blindly git pull without much thought about how the history is ending
up and what they actually want to do.
I think these two are essentially the same thing, and having an
option to
On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I've been annoyed by this at $DAYJOB recently. A lot of people seem to
blindly git pull without much thought about how the history is ending
up and what they actually want to do.
I
On Thu, 23 May 2013 11:06:57 +, Andreas Krey wrote:
...
...
Don't do that, then.
Ouch, you're right. The problem is not actually in the
pull; only the *last* pull into a feature branch that
then get pushed back ff to master needs to be reversed.
And at that time you don't know it's the
John Keeping j...@keeping.me.uk writes:
I have to wonder how often git pull with no arguments actually does
what users really want (even if they don't know it!) when it doesn't
result in a fast-forward (and pull.rebase isn't configured).
If you are in a totally centralized shared repository
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
I have to wonder how often git pull with no arguments actually does
what users really want (even if they don't know it!) when it doesn't
result in a fast-forward (and pull.rebase isn't
On Thu, May 23, 2013 at 4:55 PM, John Keeping j...@keeping.me.uk wrote:
So I was asking if it would be sensible (possibly in Git 2.0) to make
git-pull pass --ff-only to git-merge by default.
Definitely yes.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git
John Keeping j...@keeping.me.uk writes:
This isn't about swap parents, it's about helping people realise that
just git pull isn't necessarily the best thing for them to do, and
that they may want --rebase.
So I was asking if it would be sensible (possibly in Git 2.0) to make
git-pull pass
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
This isn't about swap parents, it's about helping people realise that
just git pull isn't necessarily the best thing for them to do, and
that they may want --rebase.
So I was
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
This isn't about swap parents, it's about helping people realise that
just git pull isn't necessarily the best thing for them
On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
This isn't about swap parents, it's about helping
Felipe Contreras felipe.contre...@gmail.com writes:
Unless your primary user base is those who use Git as a deployment
tool to always follow along the tip of some external repository
without doing anything on your own on the branch you run your git
pull on, defaulting it to --ff-only does not
On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Unless your primary user base is those who use Git as a deployment
tool to always follow along the tip of some external repository
without doing anything on your own on
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano gits...@pobox.com wrote:
If the proposal were to make pull.rebase the default at a major
version bump and force all integrators and other people who are
happy with how pull = fetch + merge (not fetch + rebase) works
to say pull.rebase = false in
Linus Torvalds torva...@linux-foundation.org writes:
It would be a *horrible* mistake to make rebase the default, because
it's so much easier to screw things up that way.
That said, making no-ff the default, and then if that fails, saying
The pull was not a fast-forward pull, please say
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano gits...@pobox.com wrote:
I would assume that no-ff above was meant to be --ff-only from
the first part of the message.
Yeah, I may need more coffee..
I also would assume that I can rephrase that setting pull.merge
(which does not exist) as
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote:
Linus Torvalds torva...@linux-foundation.org writes:
It would be a *horrible* mistake to make rebase the default, because
it's so much easier to screw things up that way.
That said, making no-ff the default, and then if
On Thu, May 23, 2013 at 7:25 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano gits...@pobox.com wrote:
Linus Torvalds torva...@linux-foundation.org writes:
It would be a *horrible* mistake to make rebase the default, because
it's so much
Andreas Krey a.k...@gmx.de writes:
A short trial showed that representing first parent chains as
straight lines in the graph does actually improve understandability,
as feature branches clearly stand out as separate lines even when
they no longer carry a branch name.
If you have a
34 matches
Mail list logo
