On 04/08/10 16:50, Andrew Dunstan wrote:
On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
All those issues can be avoided if you only run git gc when all the
working directories are in a clean state, with no staged but
uncommitted changes or other funny things. I can live with that gun
tied
On 05/08/10 05:08, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
All those issues can be avoided if you only run git gc when all the
working directories are in a clean state, with no staged but uncommitted
changes or other
On 21/07/10 18:22, Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
http://wiki.postgresql.org/wiki/Committing_with_Git
Note that while anyone is welcome to comment, I mostly care about
whether the
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm a bit disappointed that the wiki page advises against git-new-workdir -
that's exactly what I was planning to use. It claims there's data loss
issues with that, does someone know the details? Is
On Wed, Aug 4, 2010 at 9:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, if I understand correctly, Daniel talks about data loss when using
alternates, if you e.g delete a branch and run git gc in the parent
repository, because the child repository referring to the
On 04/08/10 13:32, Robert Haas wrote:
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
I'm a bit disappointed that the wiki page advises against git-new-workdir -
that's exactly what I was planning to use. It claims there's data loss
issues with
On 08/04/2010 09:29 AM, Heikki Linnakangas wrote:
All those issues can be avoided if you only run git gc when all the
working directories are in a clean state, with no staged but
uncommitted changes or other funny things. I can live with that gun
tied to my ankle ;-).
But to make sure
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
All those issues can be avoided if you only run git gc when all the
working directories are in a clean state, with no staged but uncommitted
changes or other funny things. I can live with that gun tied
On 08/04/2010 10:08 PM, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
All those issues can be avoided if you only run git gc when all the
working directories are in a clean state, with no staged but uncommitted
changes or
On Wed, Jul 21, 2010 at 9:22 AM, Robert Haas robertmh...@gmail.com wrote:
On the other hand, if you have technical corrections, or if
you have suggestions on how to do the same things better (rather than
suggestions on what to do differently), that would be greatly
appreciated.
Somewhere in
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
http://wiki.postgresql.org/wiki/Committing_with_Git
Note that while anyone is welcome to comment, I mostly care about
whether the document is adequate for our existing
On ons, 2010-07-21 at 12:22 -0400, Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
http://wiki.postgresql.org/wiki/Committing_with_Git
Looks good. Please consolidate this with the Committers
On Wed, Jul 21, 2010 at 21:07, Peter Eisentraut pete...@gmx.net wrote:
On ons, 2010-07-21 at 12:22 -0400, Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all branches you've updated, but only branches
that also exist on the remote side will be pushed; thus, you can have
On Wed, Jul 21, 2010 at 21:20, Robert Haas robertmh...@gmail.com wrote:
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all branches you've updated, but only branches
On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all branches you've updated, but only branches
that also exist on the
On Wed, Jul 21, 2010 at 3:23 PM, David Christensen da...@endpoint.com wrote:
On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander mag...@hagander.net wrote:
6. Finally, you must push your changes back to the server.
git push
This will push
Excerpts from Robert Haas's message of mié jul 21 15:26:47 -0400 2010:
So you're working on some back branch, and make a WIP commit so you can
switch to master to make a quick commit. Create a push on master. Bare
git push. WIP commit gets pushed upstream. Oops.
Sure, oops, but I
Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
http://wiki.postgresql.org/wiki/Committing_with_Git
Note that while anyone is welcome to comment, I mostly care about
whether the document is
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
http://wiki.postgresql.org/wiki/Committing_with_Git
Note that while
On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote:
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
At the developer meeting, I promised to do the work of documenting how
committers should use git. So here's a first version.
Magnus Hagander wrote:
Personally, I have a strong opinion that for everything but totally trivial
patches, the committer should create a short-lived work branch where all the
work is done, and then do a squash merge back to the main branch, which is
then pushed. This pattern is not mentioned
On Wed, Jul 21, 2010 at 3:31 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mié jul 21 15:26:47 -0400 2010:
So you're working on some back branch, and make a WIP commit so you can
switch to master to make a quick commit. Create a push on master.
On Wed, Jul 21, 2010 at 3:37 PM, Andrew Dunstan and...@dunslane.net wrote:
Well, either we have a terminology problem or a statement of policy that I'm
not sure I agree with, in point 2. IMNSHO, what we need to forbid is
commits that are not fast-forward commits, i.e. that do not have the
On Wed, Jul 21, 2010 at 5:03 PM, Robert Haas robertmh...@gmail.com wrote:
working setup in place. But we can certainly add whatever you think
is important, or maybe some language indicating that 'git commit -a'
is just an EXAMPLE of how to create a commit...
I took a crack at this, as well as
25 matches
Mail list logo
