On Sep 18, 2013, at 5:52 PM, Marc Petit-Huguenin <m...@petit-huguenin.org>
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?
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
