On Thu, Jul 10, 2008 at 04:12:34PM +0530, Abhijit Menon-Sen wrote: > 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?
Here are my objectives: 1. Make a repository that keeps up with CVS HEAD. 2. Allow people who are not currently committers on CVS HEAD to make needed changes. > 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.) If you know a better way to do this, I'm all ears :) I'm completely new to git and pretty fuzzy on CVS. > 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. They aren't committing, at least in part, because they did not have any way to do so. I'm fixing things so that they do by creating git-shell accounts on git.postgresql.org which will have write access to that repository. To get such an account, please send me your public key and preferred user name so I can move forward on this. > 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. Great idea! I'd be happy to wipe this repository and start over just as you propose. It would be even nicer if we can put together a standard procedure for new patches. Would you be willing to write it up? > That way I could pull from the repository and run e.g. > "git-log --stat origin/master..with-recursive" or similar. Excellent :) > Hope this helps. It does indeed. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
