At 2008-07-09 17:06:19 -0700, [EMAIL PROTECTED] 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 have during 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 exactly the 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers