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
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 configu
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 l
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 maintenan
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
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 …'). Th
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 runni
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 h
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 ru
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 maintenan
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`. Ther
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
>>>
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
13 matches
Mail list logo
