On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote:
...
What the gibbins? I don't even use git pull.
I do, but I watch for the fast-forward message
and undo as appropriate.
I use git fetch, and then, depending on my needs, I rebase or merge.
I wouldn't mind that, but I have a century of
Andreas Krey a.k...@gmx.de writes:
On Fri, 02 May 2014 10:46:09 +, David Kastrup wrote:
...
What the gibbins? I don't even use git pull.
I do, but I watch for the fast-forward message
and undo as appropriate.
I use git fetch, and then, depending on my needs, I rebase or merge.
I
On Thu, 01 May 2014 16:21:42 +, Marc Branchaud wrote:
...
But these days there's hardly any risk to using a detached HEAD. Plus
nowadays I think it's commonly accepted that using topic branches is a git
best practice. The notion of doing work on a generically-named branch like
maint
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does.
That still doesn't
Andreas Krey wrote:
My personal beef with 'git pull' is still that sometimes (namely in
the 'git pull git push' sequence) it should reverse the order of
the parents in the merge commit, so that *my* commits look like an
integrated topic branch, instead of the former mainline.
I haven't
Andreas Krey a.k...@gmx.de writes:
On Wed, 30 Apr 2014 13:01:49 +, Junio C Hamano wrote:
...
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through all the way. I'm also
not used to reading Git's output and using 'reset --hard' with the
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through all the way. I'm also
not used to reading Git's output and using
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command without thinking it through
W. Trevor King wk...@tremily.us writes:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
W. Trevor King wrote:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My proposed --prompt behavior is for folks who think “I often run
this command
Marc Branchaud marcn...@xiplink.com writes:
I may be mistaken, but I think git pull evolved to try to address the
detached-HEAD risk (at least in part).
You are totally mistaken.
git pull was part of the things to make git usable by Linus before
1.0 release, and matches the integrator
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
W. Trevor King wrote [1]:
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
My
Junio C Hamano gits...@pobox.com writes:
Marc Branchaud marcn...@xiplink.com writes:
I may be mistaken, but I think git pull evolved to try to address the
detached-HEAD risk (at least in part).
You are totally mistaken.
git pull was part of the things to make git usable by Linus before
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code.
Let's
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much
that matters is probably best
W. Trevor King wrote:
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
Some folks have explicit merge policies, and deciding how much
On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
It would matter almost exactly zero.
W. Trevor King wrote:
I've renamed this sub-thread (which started around $gmane/247835) to
avoid potential confusion/dilution.
Thanks.
The goal is to train them to do:
% git config --global pull.mode none
% git fetch
% git merge --no-ff
Sticking to my 'no-ff' topic
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
Marc Branchaud wrote:
On 14-04-30 04:14 PM, Felipe Contreras wrote:
What is wrong when `git pull` merges a fast-forward?
Nothing. Everything. It depends.
It depends on what? I don't see how a fast-forward `git pull`
brian m. carlson wrote:
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
Marc Branchaud wrote:
On 14-04-30 04:14 PM, Felipe Contreras wrote:
What is wrong when `git pull` merges a fast-forward?
Nothing. Everything. It depends.
It depends on what? I don't
On 14-05-01 05:46 AM, brian m. carlson wrote:
On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
Marc Branchaud wrote:
On 14-04-30 04:14 PM, Felipe Contreras wrote:
What is wrong when `git pull` merges a fast-forward?
Nothing. Everything. It depends.
It depends on what? I
Felipe Contreras felipe.contre...@gmail.com writes:
brian m. carlson wrote:
..
At work, we have a workflow where we merge topic branches as
non-fast-forward, so that we have a record of the history (including who
reviewed the code), but when we want to just update our local branches,
we
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to the latest from the main repo.
git pull --ff-only
git pull --no-ff developer-remote topic-branch
git
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to the latest from the main repo.
git pull --ff-only
git pull
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
brian m. carlson wrote:
..
At work, we have a workflow where we merge topic branches as
non-fast-forward, so that we have a record of the history (including who
reviewed the code), but when we want to just
Marc Branchaud wrote:
What's more, it seems to me that the only real advantage git pull
provides here is a less typing compared to the non-pull equivalent:
git fetch main-repo
git checkout main-repo/maintenance-branch
git fetch developer-remote
git merge --no-ff
brian m. carlson wrote:
At work, we have a workflow where we merge topic branches as
non-fast-forward, so that we have a record of the history (including
who reviewed the code), but when we want to just update our local
branches, we always want fast-forward:
git checkout
On 14-05-01 03:22 PM, Felipe Contreras wrote:
Marc Branchaud wrote:
What's more, it seems to me that the only real advantage git pull
provides here is a less typing compared to the non-pull equivalent:
git fetch main-repo
git checkout main-repo/maintenance-branch
git fetch
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
The only problem would be when it's not desirable, however, that's a
problem of the user's ignorance, and the failure of the project's
policity to communicate clearly to him that he should be running
`git merge --no-ff`. There's
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
My interest in all of the proposed git-pull-training-wheel patches is
that they give users a way to set a finger-breaking configuration that
makes pull a no-op (or slows it down, like 'rm -i …'). Then folks who
compulsively run
On 14-05-01 02:30 PM, W. Trevor King wrote:
I find a local branch useful to mark the amount of the upstream branch
that I've reviewed. The reflog helps a bit, but I may go several
fetches between reviews. For newbies, I recommend avoiding detached
HEADs, where possible, so they don't have
From: Marc Branchaud marcn...@xiplink.com
Sent: Wednesday, April 30, 2014 8:45 PM
[...]
I don't think we'll ever be able to create a One Git Pull To Rule
Them All.
At best we'll end up with something with enough knobs that it could be
configured to work in most workflows (I think we're actually
Oops..
From: Philip Oakley philipoak...@iee.org
From: Marc Branchaud marcn...@xiplink.com
Sent: Wednesday, April 30, 2014 8:45 PM
[...]
I don't think we'll ever be able to create a One Git Pull To Rule
Them All.
At best we'll end up with something with enough knobs that it could
be
configured
W. Trevor King wrote:
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
The only problem would be when it's not desirable, however, that's a
problem of the user's ignorance, and the failure of the project's
policity to communicate clearly to him that he should be running
W. Trevor King wrote:
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
My interest in all of the proposed git-pull-training-wheel patches is
that they give users a way to set a finger-breaking configuration that
makes pull a no-op (or slows it down, like 'rm -i …'). Then
Marc Branchaud wrote:
So what benefit does git pull provide?
The same that 'hg update' provies: a way for the user fetch/pull the
latest changes and check them out into the working directory.
--
Felipe Contreras
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
Philip Oakley wrote:
The point that there is no easy solution to an updated default pull
action that is right for everybody, straight out of the box, I think is
now fairly obvious, a summarised by Marc. I certainly avoid pull.
Yes, I avoid it too, and quite a lot of people.
My 'solution',
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
On 14-05-01 01:56 PM, W. Trevor King wrote:
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
On 14-05-01 05:46 AM, brian m. carlson wrote:
git checkout maintenance-branch
# Update our maintenance branch to
brian m. carlson wrote:
I just used this to illustrate the fact that there isn't actually one
completely correct case with pull.
Nobody is arguing otherwise. The argument is that `git pull` by default
can be made more sensible.
--
Felipe Contreras
--
To unsubscribe from this list: send the
On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:
Nobody ever complained about somebody doing a fast-forward by mistake.
Unless they fast-forward merged a feature branch into master, but the
project prefers explicitly-merged feature branches with a cover-letter
explaination in
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
My interest in all of the proposed git-pull-training-wheel patches is
that they give users a way to set a finger-breaking configuration
W. Trevor King wrote:
On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:
Nobody ever complained about somebody doing a fast-forward by mistake.
Unless they fast-forward merged a feature branch into master, but the
project prefers explicitly-merged feature branches with a
W. Trevor King wrote:
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
My interest in all of the proposed git-pull-training-wheel patches is
that they give users a way to set a
On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
W. Trevor King wrote:
Fast-forward $current_branch by $count commits to $repository
$refpec?
Why would anyone say 'no' to
W. Trevor King wrote:
On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:
If that was the case the user wouls have run `git merge
--no-ff`. Only expereinced users would answer 'no'.
Folks who are setting any ff options don't need any of these training
wheels.
Indeed.
My
On 14-04-28 02:41 PM, Junio C Hamano wrote:
Marat Radchenko ma...@slonopotamus.org writes:
Problem #1: TortoiseGit GUI windows for common tasks have a heck
lots of controls that a common Git user will never need.
Do people around TortoiseGit lurk on this list? Otherwise this may
not be
Marc Branchaud marcn...@xiplink.com writes:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
starting threads like this one
Marc Branchaud wrote:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
starting threads like this one on the mailing list.
Felipe Contreras felipe.contre...@gmail.com writes:
Marc Branchaud wrote:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Marc Branchaud wrote:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and everyone agrees
the default behavior is not correct.
You definitely have a strange notion of everyone.
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and everyone agrees
the default behavior is not correct.
You definitely have
On 14-04-30 10:55 AM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
But I'm definitely biased because I think pull is pretty much broken:
* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and everyone agrees
the
Marc Branchaud marcn...@xiplink.com writes:
On 14-04-30 10:55 AM, Junio C Hamano wrote:
Marc Branchaud marcn...@xiplink.com writes:
...
Anyway, rather than ranting on I'll just suggest that there's not enough
commonality between the ways people use git to make it worthwhile trying to
teach
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead me to
start using git pull let alone recommending it to new users.
If git pull starts using --ff-only by default then I might
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Junio C Hamano wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Matthieu Moy wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
...
Yes, this has been discussed many times in the past, and
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead
me to start using git pull let alone recommending it to new users.
What is wrong when `git pull` merges a fast-forward? The
On 14-04-30 04:01 PM, Junio C Hamano wrote:
Maybe I was unclear.
I didn't mean replace 'pull' with 'update' everywhere. I meant
Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does.
That's
On 14-04-30 04:14 PM, Felipe Contreras wrote:
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead
me to start using git pull let alone recommending it to new users.
What is wrong
Marc Branchaud wrote:
On 14-04-30 04:14 PM, Felipe Contreras wrote:
Marc Branchaud wrote:
All that said, I don't object to any attempts at improving the command
either. But I also don't see any kind of improvement that would lead
me to start using git pull let alone recommending it to
63 matches
Mail list logo
