Jens Neuhalfen wrote:
git://www.neuhalfen.name/git-selinux.git
I'm just an end user, too, so this isn't representing any official
statement, but imho you should clean up your history before you publish
it (and also, I think it would be a good idea to mention that your git
repo is really including the upstream git so that people know they
should use the --reference option to git clone to reuse the contents of
a local upstream git to avoid pulling everything from your server):
- remove commits that don't make sense like your "XXX" file
- generally look over your history again and rework it so that it makes
sense for a receiver (which is not necessarily the historic events of
how you wrote it)
- follow the common commit message format (one line subject, the rest in
the body and line wrapped)
- probably there's no reason to merge your history with historic events
of the upstream git, so you should rebase your history onto some point
of upstream.
You can do this by running
git branch last_upstream 053fd0c1c3da20474c4ff175c56ea4c1d6eeda11
git rebase --interactive last_upstream
(or alternatively (with the advantage that you can open and edit all
patches at the same time, but the disadvantage that editing diffs is
more difficult to get right than editing files in snapshots), by first
creating patch files by running:
git format-patch master...last_upstream
then editing the patch files (and remove those which don't make sense)
and then switch to the upstream branch and run "git-am --3way 00*patch",
or replace 00*patch with the patch files in the order you want them
applied).
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
