On 05/08/10 05:08, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6: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 g
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 08/04/2010 10:08 PM, Daniel Farina wrote:
On Wed, Aug 4, 2010 at 6: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
On Wed, Aug 4, 2010 at 6: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
> ;-).
Does even
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 04/08/10 13:32, Robert Haas wrote:
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
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
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 parent via the
> alternate refer
On Sun, Aug 1, 2010 at 5:08 AM, Heikki Linnakangas
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 there really a risk of
> data loss
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 d
On Wed, Jul 21, 2010 at 9:22 AM, Robert Haas 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 that wiki page ther
On Wed, Jul 21, 2010 at 5:03 PM, Robert Haas 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 incorporating some
On Wed, Jul 21, 2010 at 3:37 PM, Andrew Dunstan 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 current
> branch head
On Wed, Jul 21, 2010 at 3:31 PM, Alvaro Herrera
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. Bare
>> > git pu
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 a
On Jul 21, 2010, at 2:39 PM, Magnus Hagander wrote:
> On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan 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
On Wed, Jul 21, 2010 at 21:37, Andrew Dunstan 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 anyon
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 adequa
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,
On Wed, Jul 21, 2010 at 3:23 PM, David Christensen wrote:
>
> On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
>
>> On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander wrote:
6. Finally, you must push your changes back to the server.
git push
This will push changes in all bra
On Jul 21, 2010, at 2:20 PM, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander 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 21:20, Robert Haas wrote:
> On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander 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 r
On Wed, Jul 21, 2010 at 3:11 PM, Magnus Hagander 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
>> local work
On Wed, Jul 21, 2010 at 21:07, Peter Eisentraut 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.
>>
>> http://wiki.postgresql.org/wiki/Committing_with_G
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
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 com
25 matches
Mail list logo
