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
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
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
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: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: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
13 matches
Mail list logo
