On Sep 18, 2013, at 5:52 PM, Marc Petit-Huguenin <marc@xxxxxxxxxxxxxxxxxx> wrote:
> One of the essential rule is that you *never*, *ever* work in the master branch.
Why not?
> This branch must be considered read-only. So to create a patchset, you need
> first to create a topic branch.
...
> Obviously some patchsets will probably be merged in the master branch before
> your patchset is reviewed and merged, so you will need to rebase it. First to
> need to switch back to the master branch and to pull all the new modifications:
>
> git checkout master
> git pull
>
> If you followed the rule above (never work on the master branch), there should
> not be any conflicts when running the "git pull" command. The next step is to
> rebase your patchset:
>
> git rebase master first-patchset-master
>
> There may be conflicts at this time. Resolve them, do a "git add" of the
> modified files and then finish the rebase with the following command with the
> following command:
>
> git rebase --continue
>
> (you may have to do that multiple times)
So how is this better than just working on a clone of the trunk, periodically doing "git stash; git pull; git stash apply", and then resolving conflicts (which is how I work with libpcap and tcpdump)? Is the idea that you're not resolving conflicts with a full set of changes all at once, you're resolving them one change at a time?
