Simo Sorce wrote:
> No, if the branches are identical then by all means keep them aligned.
> But once they diverge, do not try anymore, at that point merges will
> just mess up the history with no gain whatsoever.
But if the branches didn't actually diverge, but got different history for
some rea
Toshio Kuratomi wrote:
> I'm a little leary of rebase... Everytime I've tried to use it in any
> project I've managed to get my checkout in a state where I had to make
> a fresh clone, do a manual diff between my old working tree and new one,
> and then delete the old clone. I know that other peop
Adam Williamson wrote:
> Take the current state of gnome-power-manager. Master is at:
>
> commit dfd0f074a7d41d355da28180eae1bda5dc2bba66
> Author: Richard Hughes
> Date: Mon Sep 26 16:58:28 2011 +0100
>
> New upstream version.
>
> f16 is at:
>
> commit b0b31219d2cfdffa815659a8aad78509b65c41
On Thu, 2011-11-10 at 13:49 -0800, Toshio Kuratomi wrote:
> On Thu, Nov 10, 2011 at 09:37:38PM +, phantomjinx wrote:
> >
> >
> > I would recommend rebasing branches against master up until they are
> > pushed, if
> > required to be shared. Doing so retains a linear history on the branch and
On Thu, Nov 10, 2011 at 09:37:38PM +, phantomjinx wrote:
>
>
> I would recommend rebasing branches against master up until they are pushed,
> if
> required to be shared. Doing so retains a linear history on the branch and can
> mean the branch commits can end up being fast forwarded onto mas
Bruno Wolff III wrote:
On Thu, Nov 10, 2011 at 12:38:16 -0800, Toshio Kuratomi
wrote: > -- Although others have pointed out how to use git log and git >
cherry-pick to achieve that... I find it faster to use git merge and just >
remove the empty conflicts markers if I encounter this situatio
On Thu, 2011-11-10 at 12:38 -0800, Toshio Kuratomi wrote:
> On Thu, Nov 10, 2011 at 11:59:50AM -0800, Adam Williamson wrote:
> > On Thu, 2011-11-10 at 08:55 -0800, Toshio Kuratomi wrote:
> > > On Thu, Nov 10, 2011 at 09:02:45AM -0500, Simo Sorce wrote:
> > > > On Thu, 2011-11-10 at 13:27 +0100, Mic
On Thu, Nov 10, 2011 at 12:38:16 -0800,
Toshio Kuratomi wrote:
> -- Although others have pointed out how to use git log and git
> cherry-pick to achieve that... I find it faster to use git merge and just
> remove the empty conflicts markers if I encounter this situation. Using git
> log and th
On Thu, Nov 10, 2011 at 2:59 PM, Adam Williamson wrote:
> My problem came in the case where someone has already *not* done this -
> they've updated f16 separately from, and more than, master, and I wanted
> to get them back in sync.
If you want to keep merging as long as possible, and you are in
On Thu, Nov 10, 2011 at 11:59:50AM -0800, Adam Williamson wrote:
> On Thu, 2011-11-10 at 08:55 -0800, Toshio Kuratomi wrote:
> > On Thu, Nov 10, 2011 at 09:02:45AM -0500, Simo Sorce wrote:
> > > On Thu, 2011-11-10 at 13:27 +0100, Michael J Gruber wrote:
> > > > I'm sorry but the reason is that peop
On Thu, 2011-11-10 at 08:55 -0800, Toshio Kuratomi wrote:
> On Thu, Nov 10, 2011 at 09:02:45AM -0500, Simo Sorce wrote:
> > On Thu, 2011-11-10 at 13:27 +0100, Michael J Gruber wrote:
> > > I'm sorry but the reason is that people don't know git workflows.
> >
> > I guess it depends on what is the m
> "JK" == Jesse Keating writes:
JK> I don't believe you can delete a branch remotely, I think releng has
JK> to do it on the server. Yes, you could still ask releng to delete a
JK> branch, then you could re-create it with the same name and have the
JK> same net effect, however we don't let d
On Nov 10, 2011, at 10:23 AM, Josh Stone wrote:
> On 11/10/2011 10:15 AM, Jesse Keating wrote:
>> On Nov 10, 2011, at 1:52 AM, Fabian Deutsch wrote:
>>>
>>> Someone might correct me, but rebasing introduces problems for
>>> co-maintainers, if upstream (maintainer) decides to rebase some
>>> branc
On 11/10/2011 10:15 AM, Jesse Keating wrote:
> On Nov 10, 2011, at 1:52 AM, Fabian Deutsch wrote:
>>
>> Someone might correct me, but rebasing introduces problems for
>> co-maintainers, if upstream (maintainer) decides to rebase some
>> branch.
>>
>> See http://man.he.net/man1/git-rebase
>
> Ou
On Nov 10, 2011, at 1:52 AM, Fabian Deutsch wrote:
>
> Someone might correct me, but rebasing introduces problems for
> co-maintainers, if upstream (maintainer) decides to rebase some branch.
>
> See http://man.he.net/man1/git-rebase
Our repo setup does not allow non-fastforward changes, so ther
On 2011-11-09 18:48, Adam Williamson wrote:
> thanks both of you; I hadn't really thought about the consequences of
> merging vs. cherry-picking, I think I'd just cargo-culted from somewhere
> the idea of using git merge instead of manually re-doing changes without
> considering cherry-picking inst
On Thu, Nov 10, 2011 at 09:02:45AM -0500, Simo Sorce wrote:
> On Thu, 2011-11-10 at 13:27 +0100, Michael J Gruber wrote:
> > I'm sorry but the reason is that people don't know git workflows.
>
> I guess it depends on what is the maintainer preferred workflow.
>
> I personally hate git merge, espe
On Thu, 2011-11-10 at 13:46 +, Tom Hughes wrote:
> On 10/11/11 13:38, Simo Sorce wrote:
> > On Thu, 2011-11-10 at 19:07 +0800, Mathieu Bridon wrote:
> >
> >> Yes, in case of such a fast-forward then rebasing gives the same result
> >> as merging.
> >
> > No, you are dead wrong here. Merging doe
On Wed, Nov 9, 2011 at 8:46 PM, Adam Williamson wrote:
> I'm currently going through and bumping several packages whose Rawhide
> builds have got behind their F16 builds.
>
> I've come across several packages where git merge hit 'conflicts' for no
> readily apparently reason in this case.
http://
On Thu, 2011-11-10 at 13:27 +0100, Michael J Gruber wrote:
> I'm sorry but the reason is that people don't know git workflows.
I guess it depends on what is the maintainer preferred workflow.
I personally hate git merge, especially for stuff so simple as fedora
trees. It gives no advantages I can
On Wed, Nov 9, 2011 at 7:46 PM, Adam Williamson wrote:
> I'm currently going through and bumping several packages whose Rawhide
> builds have got behind their F16 builds.
>
> I've come across several packages where git merge hit 'conflicts' for no
> readily apparently reason in this case.
I ran i
On 10/11/11 13:38, Simo Sorce wrote:
> On Thu, 2011-11-10 at 19:07 +0800, Mathieu Bridon wrote:
>
>> Yes, in case of such a fast-forward then rebasing gives the same result
>> as merging.
>
> No, you are dead wrong here. Merging does *join* the history of 2
> branches in git, and the top commit has
On Thu, 2011-11-10 at 19:07 +0800, Mathieu Bridon wrote:
> On Thu, 2011-11-10 at 11:43 +0100, Vratislav Podzimek wrote:
> > On Thu, 2011-11-10 at 10:52 +0100, Fabian Deutsch wrote:
> > > Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek:
> > > > Isn't it better to use 'git rebas
On Thu, 2011-11-10 at 10:52 +0100, Fabian Deutsch wrote:
> Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek:
> > On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote:
> > > On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote:
> > > > On Wed, 2011-11-09 at 21:20 -0500, S
Adam Williamson venit, vidit, dixit 10.11.2011 02:46:
> I'm currently going through and bumping several packages whose Rawhide
> builds have got behind their F16 builds.
>
> I've come across several packages where git merge hit 'conflicts' for no
> readily apparently reason in this case.
>
> Take
On Wed, Nov 09, 2011 at 05:46:57PM -0800, Adam Williamson wrote:
> I'm currently going through and bumping several packages whose Rawhide
> builds have got behind their F16 builds.
>
> I've come across several packages where git merge hit 'conflicts' for no
> readily apparently reason in this case
On Thu, 2011-11-10 at 11:43 +0100, Vratislav Podzimek wrote:
> On Thu, 2011-11-10 at 10:52 +0100, Fabian Deutsch wrote:
> > Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek:
> > > Isn't it better to use 'git rebase'? E.g. on master use 'git rebase
> > > f16'. As I understand it
On Thu, 2011-11-10 at 10:52 +0100, Fabian Deutsch wrote:
> Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek:
> > On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote:
> > > On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote:
> > > > On Wed, 2011-11-09 at 21:20 -0500, S
Am Donnerstag, den 10.11.2011, 10:36 +0100 schrieb Vratislav Podzimek:
> On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote:
> > On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote:
> > > On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote:
> > > > On Wed, 2011-11-09 at 17:46 -0800, Adam
On Wed, 2011-11-09 at 18:48 -0800, Adam Williamson wrote:
> On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote:
> > On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote:
> > > On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote:
> > > > I'm currently going through and bumping several packa
On Wed, Nov 09, 2011 at 07:46:57PM -0600, Adam Williamson wrote:
> It's rather infuriating to have to go in and 'fix' a bunch of
> 'conflicts' which are not conflicts at all, but just the changes you
> wanted to merge with a bunch of silly and around them.
I use this:
fedpkg switch-bran
On Thu, 2011-11-10 at 10:29 +0800, Mathieu Bridon wrote:
> On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote:
> > On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote:
> > > I'm currently going through and bumping several packages whose Rawhide
> > > builds have got behind their F16 builds.
>
On Wed, 2011-11-09 at 21:20 -0500, Simo Sorce wrote:
> On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote:
> > I'm currently going through and bumping several packages whose Rawhide
> > builds have got behind their F16 builds.
> >
> > I've come across several packages where git merge hit 'co
On Wed, 2011-11-09 at 17:46 -0800, Adam Williamson wrote:
> I'm currently going through and bumping several packages whose Rawhide
> builds have got behind their F16 builds.
>
> I've come across several packages where git merge hit 'conflicts' for no
> readily apparently reason in this case.
I ha
I'm currently going through and bumping several packages whose Rawhide
builds have got behind their F16 builds.
I've come across several packages where git merge hit 'conflicts' for no
readily apparently reason in this case.
Take the current state of gnome-power-manager. Master is at:
commit dfd
35 matches
Mail list logo
