Robert Haas wrote:
> > What is it about add/deletes that it doesn't do? ?Is the problem 'git
> > add' creates a stage already? ?How is that a problem?
>
> Tom is slightly incorrect. Deletions work fine with git commit -a.
> git already knows about the files, so everything just works. However,
>
On Wed, Sep 22, 2010 at 12:40 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> > There is no need for 'git add' because once you are done you can use git
>> > commmit -a in each branch to add all modifications and commit them.
>>
>> git commit -a is not a universal solution.
Tom Lane wrote:
> Bruce Momjian writes:
> > There is no need for 'git add' because once you are done you can use git
> > commmit -a in each branch to add all modifications and commit them.
>
> git commit -a is not a universal solution. In particular, the patch
> I was dealing with yesterday invo
Bruce Momjian writes:
> There is no need for 'git add' because once you are done you can use git
> commmit -a in each branch to add all modifications and commit them.
git commit -a is not a universal solution. In particular, the patch
I was dealing with yesterday involved additions and removals
Tom Lane wrote:
> Okay, so now that I've actually done a couple of multi-branch commits...
>
> I'm using the multiple-work-directory arrangement suggested on our wiki
> page. The work flow seems to boil down to:
>
> * Prepare patch in master
> * Stage patch with git add
> * git diff --staged >/t
On Tue, Sep 21, 2010 at 9:20 PM, Tom Lane wrote:
> So it seems like maybe we still need some more thought about how to
> recognize related commits in different branches. Or at the very least,
> we need a best-practice document explaining how to manage this --- we
> shouldn't expect every committe
On Wed, Sep 22, 2010 at 13:47, Andrew Dunstan wrote:
>
>
> On 09/22/2010 07:07 AM, Magnus Hagander wrote:
>>
>> On Wed, Sep 22, 2010 at 05:47, Tom Lane wrote:
>>>
>>> Bruce Momjian writes:
However, keep in mind that creating a branch in every existing backpatch
branch is going to
On 09/22/2010 07:07 AM, Magnus Hagander wrote:
On Wed, Sep 22, 2010 at 05:47, Tom Lane wrote:
Bruce Momjian writes:
However, keep in mind that creating a branch in every existing backpatch
branch is going to create even more backpatching monkey-work.
Monkey-work is scriptable though. It'l
On Wed, Sep 22, 2010 at 05:47, Tom Lane wrote:
> Bruce Momjian writes:
>> However, keep in mind that creating a branch in every existing backpatch
>> branch is going to create even more backpatching monkey-work.
>
> Monkey-work is scriptable though. It'll all be worth it if git
> cherry-pick is
At 2010-09-21 21:20:06 -0400, t...@sss.pgh.pa.us wrote:
>
> So it seems like maybe we still need some more thought about how to
> recognize related commits in different branches.
I'd suggest using "git cherry-pick -x" (or something similar) to mark
backported patches:
-x When recording the c
On September 21, 2010 11:47:30 pm Tom Lane wrote:
> Bruce Momjian writes:
> > However, keep in mind that creating a branch in every existing backpatch
> > branch is going to create even more backpatching monkey-work.
>
> Monkey-work is scriptable though. It'll all be worth it if git
> cherry-pic
On 22/09/10 04:20, Tom Lane wrote:
Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff --stage
On Sep 21, 2010, at 8:19 PM, Tom Lane wrote:
> You sure about the "staged" part?
Yes, I do it all the time (I make a lot of mistakes).
> Offhand I think I like Andrew's recommendation of a shortlived branch
> better. In essence your idea is using the tip of "master" itself as a
> shortlived bra
On Sep 21, 2010, at 11:19 PM, Tom Lane wrote:
>
> Offhand I think I like Andrew's recommendation of a shortlived branch
> better. In essence your idea is using the tip of "master" itself as a
> shortlived branch, which is maybe a bit too cute. If you get distracted
> and need to do something el
Bruce Momjian writes:
> However, keep in mind that creating a branch in every existing backpatch
> branch is going to create even more backpatching monkey-work.
Monkey-work is scriptable though. It'll all be worth it if git
cherry-pick is even marginally smarter about back-merging the actual
pat
Bruce Momjian writes:
> The problem is that the cherrypicks will often have to modified, and it
> can take +20 minutes to resolve some of them.
To say nothing of actually *testing* the patch in each branch, which is
Strongly Recommended if it didn't apply cleanly. I've not infrequently
spent man
David Christensen writes:
> Is the issue here the clock time spent between the commits, i.e., the
> possibility that someone is going to push to the specific branches in between
> or the date/time that the commit itself displays? Because if it's
> specifically commit time that's at issue, I be
Bruce Momjian wrote:
> > Offhand I think I like Andrew's recommendation of a shortlived branch
> > better. In essence your idea is using the tip of "master" itself as a
> > shortlived branch, which is maybe a bit too cute. If you get distracted
>
> True.
However, keep in mind that creating a br
Tom Lane wrote:
> "David E. Wheeler" writes:
> > On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
> >>> Then they'd all be patched and staged.
> >>
> >> If I understand correctly, that 'git reset' will mark all branch changes
> >> as staged but not committed, and then you can commit all branches
"David E. Wheeler" writes:
> On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
>>> Then they'd all be patched and staged.
>>
>> If I understand correctly, that 'git reset' will mark all branch changes
>> as staged but not committed, and then you can commit all branches at
>> once and push it. Is
David E. Wheeler wrote:
>
> On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
>
> >> Then they'd all be patched and staged.
> >
> > If I understand correctly, that 'git reset' will mark all branch changes
> > as staged but not committed, and then you can commit all branches at
> > once and push
David Christensen wrote:
> > If I commit in master
> > before I start working on 9.0, and so on back, then the commits will be
> > separated in time by a significant amount, thus destroying any chance of
> > having git_topo_order recognize them as related. So we're back up
> > against the problem
On Sep 21, 2010, at 8:01 PM, Bruce Momjian wrote:
>> Then they'd all be patched and staged.
>
> If I understand correctly, that 'git reset' will mark all branch changes
> as staged but not committed, and then you can commit all branches at
> once and push it. Is that right?
Right.
David
--
> If I commit in master
> before I start working on 9.0, and so on back, then the commits will be
> separated in time by a significant amount, thus destroying any chance of
> having git_topo_order recognize them as related. So we're back up
> against the problem of git not really understanding the
David E. Wheeler wrote:
> On Sep 21, 2010, at 6:20 PM, Tom Lane wrote:
>
> > While this isn't much worse than what I was used to with CVS, it's
> > definitely not better. I think that I could simplify transferring the
> > patch back to older branches if I could use git cherry-pick. However,
> >
On Sep 21, 2010, at 6:20 PM, Tom Lane wrote:
> While this isn't much worse than what I was used to with CVS, it's
> definitely not better. I think that I could simplify transferring the
> patch back to older branches if I could use git cherry-pick. However,
> that only works on already-committed
On 09/21/2010 09:20 PM, Tom Lane wrote:
Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff
Okay, so now that I've actually done a couple of multi-branch commits...
I'm using the multiple-work-directory arrangement suggested on our wiki
page. The work flow seems to boil down to:
* Prepare patch in master
* Stage patch with git add
* git diff --staged >/tmp/patch-head
* cd into REL9_0_S
28 matches
Mail list logo
