From: "Junio C Hamano"
Sent: Friday, May 24, 2013 5:26 PM
Felipe Contreras 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 i
Andreas Krey 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 wer
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
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
Felipe Contreras 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 of telling them "you ca
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
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
On Fri, May 24, 2013 at 4:29 AM, John Keeping 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 that they rea
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 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
On Thu, May 23, 2013 at 7:25 PM, Felipe Contreras
wrote:
> On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano wrote:
>> Linus Torvalds 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
On Thu, May 23, 2013 at 7:21 PM, Junio C Hamano wrote:
> Linus Torvalds 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
On Thu, May 23, 2013 at 5:21 PM, Junio C Hamano 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 setting pull
Linus Torvalds 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 if you want to
> mer
On Thu, May 23, 2013 at 3:11 PM, Junio C Hamano 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 their
On Thu, May 23, 2013 at 6:26 PM, Junio C Hamano wrote:
> Felipe Contreras 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 "g
Felipe Contreras 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 make muc
On Thu, May 23, 2013 at 5:54 PM, Junio C Hamano wrote:
> Felipe Contreras writes:
>
>> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:
>>> John Keeping writes:
>>>
This isn't about "swap parents", it's about helping people realise that
just "git pull" isn't necessarily the best
Felipe Contreras writes:
> On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:
>> John Keeping 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.
>>>
On Thu, May 23, 2013 at 5:11 PM, Junio C Hamano wrote:
> John Keeping 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 s
John Keeping 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 --ff-only
On Thu, May 23, 2013 at 4:55 PM, John Keeping 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" in
the body of a
On Thu, May 23, 2013 at 02:01:39PM -0700, Junio C Hamano wrote:
> John Keeping 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 configure
John Keeping 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 mindset
without
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
On Thu, May 23, 2013 at 09:01:15AM -0700, Junio C Hamano wrote:
> John Keeping 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 t
John Keeping 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 flip the head
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
On Wed, May 22, 2013 at 6:50 AM, Andreas Krey 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 specially w
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 actu
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 an
- Mail original -
> On Thu, May 23, 2013 at 5:06 AM, Andreas Krey wrote:
> [snip]
> > ...
> >> Don't do that, then.
> >
> > :-) Problem is, in this case 'I' expands to about
> > 1<<7 people I need to educate on this.
>
> This is a feature of `git pull` that I really despise. I reall
On Thu, May 23, 2013 at 5:06 AM, Andreas Krey wrote:
[snip]
> ...
>> Don't do that, then.
>
> :-) Problem is, in this case 'I' expands to about
> 1<<7 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 the f
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
> \/
>
Andreas Krey 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 four-commit segment
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 specially would
have some advantage here - including graphically indicating w
36 matches
Mail list logo
