On 04/02/2015 07:52 AM, Eli Zaretskii wrote: >> Date: Wed, 1 Apr 2015 12:32:41 +0000 >> From: Alan Mackenzie >> Cc: Andreas Schwab , Harald Hanche-Olsen , >> rms@gnu.org, emacs-devel@gnu.org >> >> I do not constrain my git pulls exclusively to the times when I'm >> ready to make a sensible commit. > > May I ask why do you pull (a.k.a. "merge from master") at all while > working on a feature? > > Also, are we talking about you working on a feature branch, or about > working directly on master? > > Generally, work that takes more than, say, an hour or two, and is > expected to involve a non-trivial amount of changes, is better done on > a separate branch, which you then merge onto master when you are done. > While working on such a branch, it makes little sense to merge from > master, because that just brings unrelated changes that could > potentially disrupt your development. Instead, wait until you are > finished with your changes, and then merge. If you do that, then the > potential conflicts due to pull/merge from master simply cannot > happen. When I develope a major new feature, it's usually because I'm scratching some personal itch. I want to take advantage of whatever the feature provides while I develop it. I also want to use the latest bugfixes and unrelated features from Emacs trunk. Regularly rebasing my feature work on top of trunk is the best way to accomplish both goals.