At 2008-07-09 17:06:19 -0700, david@fetter.org wrote:
>
> I'm really new to this git thing, but I now have access to create
> git-shell accounts, etc. on git.postgresql.org. Any ideas you can
> offer on how better to handle this would really help me. :)
The question is: what is your objective in providing this repository?
I've only just cloned your repository, so I can only guess at how it is
managed, but you seem to be rebasing your changes on top of the current
Postgres source and responding to upstream changes by throwing away the
old patches and applying the new ones. (By the way, your origin/master
appears to be lagging the current HEAD by 71 commits, i.e. a month.)
That has several problems:
- There is no indication of how the WITH RECURSIVE patches have changed over time or in response to feedback. For
example,the bugs recently fixed are indistinguishable from earlier changes. This would be very valuable information to
haveduring review (and that's really what I was expecting when I cloned).
- One has to clone a 250MB repository (over HTTP, with almost no progress indication) to see what is essentially
exactlythe same as the posted patch.
- Rebasing isn't appropriate for a public branch, since you're rewriting history that people have pulled already.
If your objective is only to make an up-to-date patch always available,
then it is unnecessary to publicise your repository. You could just use
git-rebase to stay abreast of significant changes in origin/master and
run git-format-patch to generate a patch... but then you still end up
with essentially the same thing that Tatsuo Ishii posted to the list
the other day anyway.
I agree with Alvaro. If the developers aren't committing to this
repository that the patches are generated from, there's really no
point to using the repository for review. It's very much simpler
to just read the patch as posted to the list.
The only real benefit to review that I can imagine would be if full
change history were available, which it could do if a) changes were
committed separately with proper comments and b) if the branch were
*NOT* rebased, but instead periodically merged with origin/master.
That way I could pull from the repository and run e.g.
"git-log --stat origin/master..with-recursive" or similar.
Hope this helps.
-- ams
