Re: Re*: [PATCH v9] Documentation/remote-helpers: Add invocation section
- From
Ramkumar Ramachandra <artagnon@gmail.com>
- Date
- Apr 10, 2010, 12:36 UTC
- Message-ID
- <m2jf3271551004100536q65725be3i224c7e7fb334563@mail.gmail.com>
- In-Reply-To
- <7vfx3567e2.fsf_-_@alter.siamese.dyndns.org>
Hi,
I like the idea, but I think it's too verbose. Perhaps something along these lines?
1. In general, base your patches on 'master'. 2. If your patch is a bugfix try to base it on 'maint'. If the bug's in 'master, but not in 'maint' also, base it on 'master'. 3. If you're working on a feature, some of whose patches are already in 'pu', base your work on the tip of the last commit in your topic branch (See THIS). If it's a minor correction, you might want to add a note asking the maintainer to squash it into the previous commit. 4. If you're working on an elaborate feature that depends on many commits in 'pu', maintain a public branch based on 'pu', and periodically post patches to the mailing list for feedback (all based on 'pu'). You might have to rebase/ wait before it's finally merged.
THIS:
> + work on the tip of the topic. "log --first-parent master..pu" would be > + a good way to find the tips of topic branches.
+ "The grandparent of this merge commit is your latest commit in this topic. This is the commit you should base your patch on."
-- Ram