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 packages whose
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 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, Simo Sorce
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, it
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.
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 the
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, Simo Sorce
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 rebase'? E.g.
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 Wed, Nov 9, 2011 at 7:46 PM, Adam Williamson awill...@redhat.com 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
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 8:46 PM, Adam Williamson awill...@redhat.com 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
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 does *join* the
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
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
Our repo setup
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
branch.
See
JK == Jesse Keating jkeat...@redhat.com 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
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 maintainer
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 people don't
On Thu, Nov 10, 2011 at 2:59 PM, Adam Williamson awill...@redhat.com 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
On Thu, Nov 10, 2011 at 12:38:16 -0800,
Toshio Kuratomi a.bad...@gmail.com wrote:
nod -- 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.
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, Michael J
Bruno Wolff III br...@wolff.to wrote:
On Thu, Nov 10, 2011 at 12:38:16 -0800, Toshio Kuratomi a.bad...@gmail.com
wrote: nod -- 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
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 master
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
can
Adam Williamson wrote:
Take the current state of gnome-power-manager. Master is at:
commit dfd0f074a7d41d355da28180eae1bda5dc2bba66
Author: Richard Hughes rich...@hughsie.com
Date: Mon Sep 26 16:58:28 2011 +0100
New upstream version.
f16 is at:
commit
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 people
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
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
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
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 'conflicts'
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, 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-branch f16
git
33 matches
Mail list logo
