Re: Why does git merge have so much trouble with Fedora package branches?
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 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 haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. 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 instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? Isn't it better to use 'git rebase'? E.g. on master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. -- Vratislav Podzimek Anaconda Rider Red Hat, Inc. | Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 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 haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. 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 instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? Isn't it better to use 'git rebase'? E.g. on master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. 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 - fabian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 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' for no readily apparently reason in this case. I haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. 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 instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? Isn't it better to use 'git rebase'? E.g. on master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. 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 Yes, but I don't see any problem in a situation like this: A--B--C*master A--B--C--D--E *f16 I would expect the result to look like: A--B--C--D--E *master A--B--C--D--E *f16 -- Vratislav Podzimek Anaconda Rider Red Hat, Inc. | Brno, Czech Republic -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 would do the same as cherry-picking commit after commit in these cases. 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 Yes, but I don't see any problem in a situation like this: A--B--C*master A--B--C--D--E *f16 I would expect the result to look like: A--B--C--D--E *master A--B--C--D--E *f16 Yes, in case of such a fast-forward then rebasing gives the same result as merging. Which means it would not be the same as cherry-picking (as you were saying previously). -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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.
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 b0b31219d2cfdffa815659a8aad78509b65c412a
Author: Richard Hughes rich...@hughsie.com
Date: Mon Oct 17 11:34:50 2011 +0100
New upstream version.
which is just a single commit ahead of the master branch. The git diff
is incredibly trivial:
[adamw@adam gnome-power-manager (f16)]$ git diff
dfd0f074a7d41d355da28180eae1bda5dc2bba66
diff --git a/.gitignore b/.gitignore
index 7cf4a61..b9cba18 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ gnome-power-manager-2.31.4.tar.bz2
/gnome-power-manager-3.1.90.tar.xz
/gnome-power-manager-3.1.92.tar.xz
/gnome-power-manager-3.2.0.tar.xz
+/gnome-power-manager-3.2.1.tar.xz
diff --git a/gnome-power-manager.spec b/gnome-power-manager.spec
index cba83e2..e5a512f 100644
--- a/gnome-power-manager.spec
+++ b/gnome-power-manager.spec
@@ -1,6 +1,6 @@
Summary: GNOME power management service
Name: gnome-power-manager
-Version: 3.2.0
+Version: 3.2.1
Release: 1%{?dist}
License: GPLv2+ and GFDL
Group: Applications/System
@@ -75,6 +75,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas
/dev/null
%{_mandir}/man1/*.1.gz
%changelog
+* Mon Oct 17 2011 Richard Hughes rhug...@redhat.com - 3.2.1-1
+- New upstream version.
+
* Mon Sep 26 2011 Richard Hughes rhug...@redhat.com - 3.2.0-1
- New upstream version.
diff --git a/sources b/sources
index 81e4f0f..2d18e7f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4dafea2ae923599685f91de033f23888 gnome-power-manager-3.2.0.tar.xz
+8e8a3759e0805041342c1f49471ee4ed gnome-power-manager-3.2.1.tar.xz
But if you try and do a merge:
[adamw@adam gnome-power-manager (master)]$ git merge --no-ff
b0b31219d2cfdffa815659a8aad78509b65c412a
Auto-merging sources
CONFLICT (content): Merge conflict in sources
Auto-merging gnome-power-manager.spec
CONFLICT (content): Merge conflict in gnome-power-manager.spec
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.
why the conflict? Why can it not merge this incredibly simple version
bump? I guess I'm just missing something about how git works, but I
can't really see why this causes a problem.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
You're getting problems I think because a merge joins two branches together by
merging the changes from both since the most recent merge base (as found by git
merge-branch A B)
If you run git merge-branch dfd0f074a7d41d355da28180eae1bda5dc2bba66 f16, you
actually come up with quite a number of commits that need to be merged. Several
of those commits are probably in the master and f16 branches under separate
commit ids. Being separate commit ids, but having the same diff changes,
results in git tossing them out as conflicts, even though the result of taking
either change would be the same.
Neil
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 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 b0b31219d2cfdffa815659a8aad78509b65c412a
Author: Richard Hughes rich...@hughsie.com
Date: Mon Oct 17 11:34:50 2011 +0100
New upstream version.
which is just a single commit ahead of the master branch. The git diff
is incredibly trivial:
[adamw@adam gnome-power-manager (f16)]$ git diff
dfd0f074a7d41d355da28180eae1bda5dc2bba66
diff --git a/.gitignore b/.gitignore
index 7cf4a61..b9cba18 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ gnome-power-manager-2.31.4.tar.bz2
/gnome-power-manager-3.1.90.tar.xz
/gnome-power-manager-3.1.92.tar.xz
/gnome-power-manager-3.2.0.tar.xz
+/gnome-power-manager-3.2.1.tar.xz
diff --git a/gnome-power-manager.spec b/gnome-power-manager.spec
index cba83e2..e5a512f 100644
--- a/gnome-power-manager.spec
+++ b/gnome-power-manager.spec
@@ -1,6 +1,6 @@
Summary: GNOME power management service
Name: gnome-power-manager
-Version: 3.2.0
+Version: 3.2.1
Release: 1%{?dist}
License: GPLv2+ and GFDL
Group: Applications/System
@@ -75,6 +75,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas
/dev/null
%{_mandir}/man1/*.1.gz
%changelog
+* Mon Oct 17 2011 Richard Hughes rhug...@redhat.com - 3.2.1-1
+- New upstream version.
+
* Mon Sep 26 2011 Richard Hughes rhug...@redhat.com - 3.2.0-1
- New upstream version.
diff --git a/sources b/sources
index 81e4f0f..2d18e7f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4dafea2ae923599685f91de033f23888 gnome-power-manager-3.2.0.tar.xz
+8e8a3759e0805041342c1f49471ee4ed gnome-power-manager-3.2.1.tar.xz
But if you try and do a merge:
[adamw@adam gnome-power-manager (master)]$ git merge --no-ff
b0b31219d2cfdffa815659a8aad78509b65c412a
Auto-merging sources
CONFLICT (content): Merge conflict in sources
Auto-merging gnome-power-manager.spec
CONFLICT (content): Merge conflict in gnome-power-manager.spec
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.
why the conflict? Why can it not merge this incredibly simple version
bump? I guess I'm just missing something about how git works, but I
can't really see why this causes a problem.
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'm sorry but the reason is that people don't know git workflows. Many
fedora repos have a crappy history: Even the Fedora guidelines say you
should commit changes to master and merge them down to release branches
one (branch) by one. Some of those histories are due to the import from
cvs times, of course, but some are new.
If you look at gnome-power-manager you see that starting from the fork
point 1b8c97a, origin/f16 and origin/master have diverged by applying
the same patches separately to both branches, rather then applying them
on master and merging them to f16. Actually, it's hard to see, because
the commit messages are crappy also... With the current state (merge at
origin/master):
git log --oneline --cherry-mark origin/f16...origin/master^
+ b0b3121 New upstream version.
= d13e256 New upstream version.
= dfd0f07 New upstream version.
= 6d8cf84 New upstream version.
= b16cb9b New upstream version.
= 4e66202 Fix an error in the postun scriptlet Require
gnome-settings-daemon as we use its schema.
= 7e353a1 Fix an error in the postun scriptlet Require
gnome-settings-daemon as we use its schema.
= 17e071c g-s-d is a runtime dep, not a buildtime dep
= 4a083bd g-s-d is a runtime dep, not a buildtime dep
= acf3bc4 Add BR gnome-settings-daemon
= 05641e6 Add BR gnome-settings-daemon
= 380709b New upstream version.
= aab8201 New upstream version.
Tons of equivalent, but different patches. Only one non-equivalent
patch. (What keeps one from saying which new upstream version...?) But
by its very nature, a merge cannot coalesce different equivalent
patches, only a rebase would. A merge gives conflicts because as
compared to the fork point (merge base), both branches change the same
lines in different ways (e.g. the sources file).
Mixing cherry-picks and merges almost inevitably leads to these problems.
In this situation, cherry-picking b0b3121 from origin/f16 to master
would have been the best fixup for the crappy history. After that, both
diverging branches are equivalent, and a merge from master to
origin/f16 would have
Re: Why does git merge have so much trouble with Fedora package branches?
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 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' for no readily apparently reason in this case. I haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. 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 instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? Isn't it better to use 'git rebase'? E.g. on master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. Someone might correct me, but rebasing introduces problems for co-maintainers, if upstream (maintainer) decides to rebase some branch. Only if you rewrite history. For forwards it does not cause any issue. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 master use 'git rebase f16'. As I understand it, it would do the same as cherry-picking commit after commit in these cases. 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 Yes, but I don't see any problem in a situation like this: A--B--C*master A--B--C--D--E *f16 I would expect the result to look like: A--B--C--D--E *master A--B--C--D--E *f16 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 multiple ancestors. Which means it would not be the same as cherry-picking (as you were saying previously). No, a forward rebase is *exactly* the same as a rebase on top. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 multiple ancestors. Not if it is a fast forward merge, unless you force it. Here's what the manual says: --ff, --no-ff Do not generate a merge commit if the merge resolved as a fast-forward, only update the branch pointer. This is the default behavior of git-merge. With --no-ff Generate a merge commit even if the merge resolved as a fast-forward. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 case. I ran into the same problem when 'git merge master' worked in the past. In retrospect I realize it was due to Spot updating my packages for FTBFS when he didn't realize I already had builds in the works. Right or wrong I ended up doing a 'git diff HEAD..master patch' (or was it master..HEAD) and then applying the patch. I'm not sure if there's any future gotcha's with that method but it worked quite well. Put me in the camp with all the other people that don't really understand how git works. All I ask is that once this conversation/debate ends, that the best practices make it to the proper wiki pages. Thanks, Richard -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 see to the way I work and causes quite a lot of bad side-issues. [..] Tons of equivalent, but different patches. Only one non-equivalent patch. (What keeps one from saying which new upstream version...?) But by its very nature, a merge cannot coalesce different equivalent patches, only a rebase would. A merge gives conflicts because as compared to the fork point (merge base), both branches change the same lines in different ways (e.g. the sources file). Mixing cherry-picks and merges almost inevitably leads to these problems. True, that's why it would be *very* nice if the maintainer could decide the policy and have git hooks on the server enforce it. Ie if the maintainer does not want merges it should be possible for him to save that information somewhere and then hoos would refuse a push with merges. In this situation, cherry-picking b0b3121 from origin/f16 to master would have been the best fixup for the crappy history. After that, both diverging branches are equivalent, and a merge from master to origin/f16 would have succeeded with the default recursive strategy and without any conflicts. True. Hmm, do I sound like ranting? I hope not, or else sorry, I'd be barking up the wrong tree. In any case I hope this post helps. Well it does sound a bit like ranting, but I think it is ok to some degree. Git is still a very new tool for many, and some package maintainers may be using it only for fedora packaging. Also there are basically opposite camps when it comes to deal with git merge. People like me that avoid it like the plague on most of his projects, and other people that love it. I find git merge justified only on very bug projects that heavily use feature branches, but in the end it is about maintainer comfort when it comes to Fedora, IMHO. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 case. http://nathaniel.themccallums.org/2010/10/18/using-git-fast-forward-merging-to-keep-branches-in-sync/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 history of 2 branches in git, and the top commit has multiple ancestors. Not if it is a fast forward merge, unless you force it. Here's what the manual says: --ff, --no-ff Do not generate a merge commit if the merge resolved as a fast-forward, only update the branch pointer. This is the default behavior of git-merge. With --no-ff Generate a merge commit even if the merge resolved as a fast-forward. My fault. I stand corrected. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? FWIW, that is the way I approach it. If several branches are in sync (or nearly so) then merging makes more sense to me. But if the branches diverge then merging from the rawhide branch to a maintenance branch makes little sense, making cherry-picking the better choice. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 does not allow non-fastforward changes, so there is no way to have a rebase action create problems for other maintainers. I suppose you mean no git push -f, but do you also prevent deleting branches? Otherwise you can manually force by deleting and pushing anew. Of course, if you're doing that, you'd be better be very aware that you're playing with fire... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 http://man.he.net/man1/git-rebase Our repo setup does not allow non-fastforward changes, so there is no way to have a rebase action create problems for other maintainers. I suppose you mean no git push -f, but do you also prevent deleting branches? Otherwise you can manually force by deleting and pushing anew. Of course, if you're doing that, you'd be better be very aware that you're playing with fire... I don't believe you can delete a branch remotely, I think releng has to do it on the server. Yes, you could still ask releng to delete a branch, then you could re-create it with the same name and have the same net effect, however we don't let developers create (nor would we delete) the top level Fedora/EPEL branches. It'd be some other topic branch that would fall victim. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 don't let developers create (nor would JK we delete) the top level Fedora/EPEL branches. It'd be some other JK topic branch that would fall victim. I have on a few occasions deleted branches which were mistakenly created, including one or two top level release branches and a few weirdly-named branches that were pushed without the maintainer realizing that they would be permanent. But yes, those are outliers. SCM admins can do it, or at least they could at one point. - J -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 preferred workflow. I personally hate git merge, especially for stuff so simple as fedora trees. It gives no advantages I can see to the way I work and causes quite a lot of bad side-issues. [..] I've found git cherry-pick hard to use compared to git merge -- but then again, I'm using cherry-pick to actually cherry-pick; not keep two branches in sync. So if my usual workflow is commit to master, test, commit, test, then make fX equivalent to master and build there, what is the cherry-pick way to do that simple task? git merge way would be: $ git checkout f16 $ git merge master which seems very simple and very suited for this particular workflow. As I've understood the thread so far that's fine - so long as you actually want master and f16 to be the same, of course. I'm not sure what you're supposed to do when master has a later version of the package than f16, but you want to introduce some other change to both branches, for e.g. 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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 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 see to the way I work and causes quite a lot of bad side-issues. [..] I've found git cherry-pick hard to use compared to git merge -- but then again, I'm using cherry-pick to actually cherry-pick; not keep two branches in sync. So if my usual workflow is commit to master, test, commit, test, then make fX equivalent to master and build there, what is the cherry-pick way to do that simple task? git merge way would be: $ git checkout f16 $ git merge master which seems very simple and very suited for this particular workflow. As I've understood the thread so far that's fine - so long as you actually want master and f16 to be the same, of course. I'm not sure what you're supposed to do when master has a later version of the package than f16, but you want to introduce some other change to both branches, for e.g. Yeah -- That's where I would start to use cherry-pick. I was jsut asking since it seemed that Simo was saying that he thought cherry-pick was a better idea even in the case I outlined above. So I was curoius if I was missing something. 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. 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. Using git log and then finding the commits that need to be pulled in seems to require me to figure out which of the dozens of commits have been cherry-picked already and which have not, keep track of their hashes, apply each of them, and then try again. But I could be missing a simple cherry-pick subcommand that would make this easier. -Toshio pgpVWkNqJ9St2.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 possible, and you are in a position where F16 and master are starting to diverge, the trick is to apply your changes to f16 _first_, then merge those changes into master. This assumes that f16 is a subset of master. This naturally works well only in some cases, and given a compact spec file, you might get pointless conflicts. As f16 and master start diverging more significantly, cherry-pick is probably the most practical recourse. m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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. Using git log and then finding the commits that need to be pulled in seems to require me to figure out which of the dozens of commits have been cherry-picked already and which have not, keep track of their hashes, apply each of them, and then try again. But I could be missing a simple cherry-pick subcommand that would make this easier. I'm still getting used to git and do like to merge master into branches where they are all essentially in sync. But one thing I have been trying to get in the habit of is doing a git branch off of master to do complicated changes. I do local builds until it works and then merge the test branch in master and then later merge master into other branches. I think this can work better if master changes while you are working or if something works out to be a dead end and you want to mostly start over. And if something else comes up that you need to do to master while you are working you can do it pretty easily. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 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 see to the way I work and causes quite a lot of bad side-issues. [..] I've found git cherry-pick hard to use compared to git merge -- but then again, I'm using cherry-pick to actually cherry-pick; not keep two branches in sync. So if my usual workflow is commit to master, test, commit, test, then make fX equivalent to master and build there, what is the cherry-pick way to do that simple task? git merge way would be: $ git checkout f16 $ git merge master which seems very simple and very suited for this particular workflow. As I've understood the thread so far that's fine - so long as you actually want master and f16 to be the same, of course. I'm not sure what you're supposed to do when master has a later version of the package than f16, but you want to introduce some other change to both branches, for e.g. Yeah -- That's where I would start to use cherry-pick. I was jsut asking since it seemed that Simo was saying that he thought cherry-pick was a better idea even in the case I outlined above. So I was curoius if I was missing something. 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. 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. 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. Using git log and then finding the commits that need to be pulled in seems to require me to figure out which of the dozens of commits have been cherry-picked already and which have not, keep track of their hashes, apply each of them, and then try again. But I could be missing a simple cherry-pick subcommand that would make this easier. A merge in this case only risk to bring changes you do not want in one of the trees. Although cherry-pick is more tedious, you already have to do that job anyway to make sure you are not bringing in stuff you do not want to, so you can as well just do it. Of course the best course of action is to just apply the same commit to all branches it applies to when you create it and not wait months before doing that, but that's the ideal and reality often diverge. Another way you could use id to create a 'feature' branch and use rebase -i to play with commits , but that could end up being more complex than just chery picking for some issues. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 markers if I encounter this situation. Using git log and then finding the commits that need to be pulled in seems to require me to figure out which of the dozens of commits have been cherry-picked already and which have not, keep track of their hashes, apply each of them, and then try again. But I could be missing a simple cherry-pick subcommand that would make this easier. I'm still getting used to git and do like to merge master into branches where they are all essentially in sync. But one thing I have been trying to get in the habit of is doing a git branch off of master to do complicated changes. I do local builds until it works and then merge the test branch in master and then later merge master into other branches. I think this can work better if master changes while you are working or if something works out to be a dead end and you want to mostly start over. And if something else comes up that you need to do to master while you are working you can do it pretty easily. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel 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 when the feature is complete. My 2p Cheers Phantomjinx -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package?branches?
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 when the feature is complete. 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 somehow manage to use this successfully I've justnever managed to without disaster striking :-( -Toshio pgpjjWXBDa0N1.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package?branches?
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 mean the branch commits can end up being fast forwarded onto master when the feature is complete. 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 somehow manage to use this successfully I've justnever managed to without disaster striking :-( Toshio, I generally found this situation to happen when people haven't yet grokked how branches work in git. If you want I am available to get on a 1-1 session with to show how to successfully use rebases, which is the only thing I use. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 b0b31219d2cfdffa815659a8aad78509b65c412a Author: Richard Hughes rich...@hughsie.com Date: Mon Oct 17 11:34:50 2011 +0100 New upstream version. which is just a single commit ahead of the master branch. What you need to do in this case is: 1. Identify the commit in f16 which made it contain the same contents as master. (This is the magic ingredient in my recipe. If that state does not exist, it can sometimes be produced by judicious use of cherry-pick or revert.) In this case, this would have been commit d13e25653fec0bb1e09c99badbecc84688b28cd8. 2. Switch the current branch to master. 3. git merge d13e25653fec0bb1e09c99badbecc84688b28cd8 (git will recognize that the contents are identical and produce a trivial merge. No conflicts.) 4. git merge f16 (Now git will see from the history that only commit b0b31219d2cfdffa815659a8aad78509b65c412a remains to be merged and merge that. Again, no conflicts to deal with.) 5. Push your changes. I use this trick very frequently and I'm surprised that so many people here seem not to have figured it out yet (judging from the many complicated suggestions of how to do this). I discovered it more or less by accident, seeing how merges just worked if the trees were containing identical contents with different history, but not when they were containing different contents with different history. So I tried using the hash with identical contents as the branch to merge and, hey, it worked! And now it sounds obvious and straightforward to me. Of course, I blame maintainers (or scripts! Rel-eng's release bumping script is a big offender there) for committing the same thing to different branches as different commit hashes instead of using merge in the first place… Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package?branches?
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 somehow manage to use this successfully I've justnever managed to without disaster striking :-( I think your problem there was that you cannot use rebase on a branch you already pushed, because rebase rewrites the branch's history, and Fedora's git hooks ban you from doing that on already pushed branches. (A push which rewrites history is not a fast-forward push.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 reason, the way to make them fast-forwardable again (and thus not requiring any more merge commits) is to first merge branch A into branch B as you normally would (generating one last merge commit), then merge branch B back into branch A (which will fast-forward to that merge commit and make them point to the same hash again). (I didn't come up with that particular trick; it was brought up by one or more people as a solution to create fast-forward-mergeable branches after the CVS→git conversion.) Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Why does git merge have so much trouble with Fedora package branches?
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 dfd0f074a7d41d355da28180eae1bda5dc2bba66
Author: Richard Hughes rich...@hughsie.com
Date: Mon Sep 26 16:58:28 2011 +0100
New upstream version.
f16 is at:
commit b0b31219d2cfdffa815659a8aad78509b65c412a
Author: Richard Hughes rich...@hughsie.com
Date: Mon Oct 17 11:34:50 2011 +0100
New upstream version.
which is just a single commit ahead of the master branch. The git diff
is incredibly trivial:
[adamw@adam gnome-power-manager (f16)]$ git diff
dfd0f074a7d41d355da28180eae1bda5dc2bba66
diff --git a/.gitignore b/.gitignore
index 7cf4a61..b9cba18 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ gnome-power-manager-2.31.4.tar.bz2
/gnome-power-manager-3.1.90.tar.xz
/gnome-power-manager-3.1.92.tar.xz
/gnome-power-manager-3.2.0.tar.xz
+/gnome-power-manager-3.2.1.tar.xz
diff --git a/gnome-power-manager.spec b/gnome-power-manager.spec
index cba83e2..e5a512f 100644
--- a/gnome-power-manager.spec
+++ b/gnome-power-manager.spec
@@ -1,6 +1,6 @@
Summary: GNOME power management service
Name: gnome-power-manager
-Version: 3.2.0
+Version: 3.2.1
Release: 1%{?dist}
License: GPLv2+ and GFDL
Group: Applications/System
@@ -75,6 +75,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas /dev/null
%{_mandir}/man1/*.1.gz
%changelog
+* Mon Oct 17 2011 Richard Hughes rhug...@redhat.com - 3.2.1-1
+- New upstream version.
+
* Mon Sep 26 2011 Richard Hughes rhug...@redhat.com - 3.2.0-1
- New upstream version.
diff --git a/sources b/sources
index 81e4f0f..2d18e7f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4dafea2ae923599685f91de033f23888 gnome-power-manager-3.2.0.tar.xz
+8e8a3759e0805041342c1f49471ee4ed gnome-power-manager-3.2.1.tar.xz
But if you try and do a merge:
[adamw@adam gnome-power-manager (master)]$ git merge --no-ff
b0b31219d2cfdffa815659a8aad78509b65c412a
Auto-merging sources
CONFLICT (content): Merge conflict in sources
Auto-merging gnome-power-manager.spec
CONFLICT (content): Merge conflict in gnome-power-manager.spec
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.
why the conflict? Why can it not merge this incredibly simple version
bump? I guess I'm just missing something about how git works, but I
can't really see why this causes a problem.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 haven't looked deeply enough to tell, but in general merges are a very
bad tool and should be avoid IMHO.
It would be much more sane to git cherry-pick the changes you need and
keep the branches separate and have their own history.
Merges makes it really painful to follow history later.
My 2c.
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 b0b31219d2cfdffa815659a8aad78509b65c412a
Author: Richard Hughes rich...@hughsie.com
Date: Mon Oct 17 11:34:50 2011 +0100
New upstream version.
which is just a single commit ahead of the master branch. The git diff
is incredibly trivial:
[adamw@adam gnome-power-manager (f16)]$ git diff
dfd0f074a7d41d355da28180eae1bda5dc2bba66
diff --git a/.gitignore b/.gitignore
index 7cf4a61..b9cba18 100644
--- a/.gitignore
+++ b/.gitignore
@@ -15,3 +15,4 @@ gnome-power-manager-2.31.4.tar.bz2
/gnome-power-manager-3.1.90.tar.xz
/gnome-power-manager-3.1.92.tar.xz
/gnome-power-manager-3.2.0.tar.xz
+/gnome-power-manager-3.2.1.tar.xz
diff --git a/gnome-power-manager.spec b/gnome-power-manager.spec
index cba83e2..e5a512f 100644
--- a/gnome-power-manager.spec
+++ b/gnome-power-manager.spec
@@ -1,6 +1,6 @@
Summary: GNOME power management service
Name: gnome-power-manager
-Version: 3.2.0
+Version: 3.2.1
Release: 1%{?dist}
License: GPLv2+ and GFDL
Group: Applications/System
@@ -75,6 +75,9 @@ glib-compile-schemas %{_datadir}/glib-2.0/schemas
/dev/null
%{_mandir}/man1/*.1.gz
%changelog
+* Mon Oct 17 2011 Richard Hughes rhug...@redhat.com - 3.2.1-1
+- New upstream version.
+
* Mon Sep 26 2011 Richard Hughes rhug...@redhat.com - 3.2.0-1
- New upstream version.
diff --git a/sources b/sources
index 81e4f0f..2d18e7f 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4dafea2ae923599685f91de033f23888 gnome-power-manager-3.2.0.tar.xz
+8e8a3759e0805041342c1f49471ee4ed gnome-power-manager-3.2.1.tar.xz
But if you try and do a merge:
[adamw@adam gnome-power-manager (master)]$ git merge --no-ff
b0b31219d2cfdffa815659a8aad78509b65c412a
Auto-merging sources
CONFLICT (content): Merge conflict in sources
Auto-merging gnome-power-manager.spec
CONFLICT (content): Merge conflict in gnome-power-manager.spec
Auto-merging .gitignore
CONFLICT (content): Merge conflict in .gitignore
Automatic merge failed; fix conflicts and then commit the result.
why the conflict? Why can it not merge this incredibly simple version
bump? I guess I'm just missing something about how git works, but I
can't really see why this causes a problem.
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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' for no readily apparently reason in this case. I haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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. I've come across several packages where git merge hit 'conflicts' for no readily apparently reason in this case. I haven't looked deeply enough to tell, but in general merges are a very bad tool and should be avoid IMHO. It would be much more sane to git cherry-pick the changes you need and keep the branches separate and have their own history. Merges makes it really painful to follow history later. I agree. Once branches have started to diverge, merging them makes the history harder to follow because the branches keep diverging, merging back, diverging again, merging,... However, it is sometimes possible to never diverge. In the example of gnome-power-manager, the master and f16 branches seem to contain the exact same changes, in the same order. In such a case, it would have made sense to always keep merging the branches rather than cherry-picking, so that they would never have diverged. And that would have avoided the conflict Adam is seeing. 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 instead. so I guess in general it's both a better idea and more likely to work to use cherry-pick instead of merge, unless the two branches are really expected to be identical? -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Why does git merge have so much trouble with Fedora package branches?
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 merge -s recursive -X theirs master and have a git alias for it in ~/.gitconfig: [alias] copymaster = merge -s recursive -X theirs master This forces the f16 branch contents to match the master branch contents. I haven't looked closely at what it does to the linear git history though. -- Matt Domsch Technology Strategist Dell | Office of the CTO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
