Re: git rebase master
On Ter, 2013-05-28 at 11:53 -0600, Kevin Fenzi wrote: On Mon, 27 May 2013 20:41:08 +0100 Sérgio Basto ser...@serjux.com wrote: I done it http://pkgs.fedoraproject.org/cgit/debconf.git/log/ but now [debconf] Created branch HEAD, we have a a branch called HEAD , can the git administrator of Fedora delete this branch ? Done. Note that you should next time request this by filing a ticket in releng trac. ;) Many many thanks :) -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
Il 27/05/2013 23:11, Adam Williamson ha scritto: As soon as your f19 build diverges from master at all, merging becomes inappropriate (and probably impossible) and you should instead use 'cherry-pick'. It helps to have at least a vague overview of how git is designed to be used, and what is the actual _point_ of the commands you're using in the intended git workflow. Interestingly, git itself is developed the other way round: you first do the fixes in the oldest applicable branch and git merge upwards (from f18 to f19, from f19 to master in the Fedora case). Paolo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On 05/28/2013 11:30 AM, Paolo Bonzini wrote: Il 27/05/2013 23:11, Adam Williamson ha scritto: As soon as your f19 build diverges from master at all, merging becomes inappropriate (and probably impossible) and you should instead use 'cherry-pick'. It helps to have at least a vague overview of how git is designed to be used, and what is the actual _point_ of the commands you're using in the intended git workflow. Interestingly, git itself is developed the other way round: you first do the fixes in the oldest applicable branch and git merge upwards (from f18 to f19, from f19 to master in the Fedora case). That's because there's little support in VCS for backporting. The VCS doesn't know if the new development in master is part of the fix, or unrelated new development. The only system I've ever used which had some support for this was darcs, but more often than not, I had unintentional patch dependencies on new development I didn't want to backport, so it didn't work out that well. The forward-porting approach has the risk that it stops before reaching master, so users will encounter regressions when updating. And both approaches do not really mix that well because merging from the stable branch with cherry-picked and massages backports tends to conflict a lot. Better tool support for backporting and the more general issue of patch stacks (like we have in RPM and Debian packages) is very desirable, but it's a really difficult problem. -- Florian Weimer / Red Hat Product Security Team -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Mon, 27 May 2013 20:41:08 +0100 Sérgio Basto ser...@serjux.com wrote: I done it http://pkgs.fedoraproject.org/cgit/debconf.git/log/ but now [debconf] Created branch HEAD, we have a a branch called HEAD , can the git administrator of Fedora delete this branch ? Done. Note that you should next time request this by filing a ticket in releng trac. ;) kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Tue, 2013-05-28 at 11:30 +0200, Paolo Bonzini wrote: Il 27/05/2013 23:11, Adam Williamson ha scritto: As soon as your f19 build diverges from master at all, merging becomes inappropriate (and probably impossible) and you should instead use 'cherry-pick'. It helps to have at least a vague overview of how git is designed to be used, and what is the actual _point_ of the commands you're using in the intended git workflow. Interestingly, git itself is developed the other way round: you first do the fixes in the oldest applicable branch and git merge upwards (from f18 to f19, from f19 to master in the Fedora case). Indeed, AFAICT though, merging down from master is the most common workflow in Fedora packaging git (and more in line with how the Fedora dev process is 'supposed' to work). -- 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
git rebase master
Hi, git puts me crazy in here : http://pkgs.fedoraproject.org/cgit/debconf.git/ I have master now correct and want F19 be the same (git merge master) but do a commit just in F19, seems that never will be the same . I try fedpkg switch-branch f19 git rebase master merges conflict ??? I just want F19 be a copy master who I can do that ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Seg, 2013-05-27 at 18:17 +0100, Sérgio Basto wrote: Hi, git puts me crazy in here : http://pkgs.fedoraproject.org/cgit/debconf.git/ I have master now correct and want F19 be the same (git merge master) but do a commit just in F19, seems that never will be the same . I try fedpkg switch-branch f19 git rebase master merges conflict ??? I just want F19 be a copy master who I can do that ? I done it http://pkgs.fedoraproject.org/cgit/debconf.git/log/ but now [debconf] Created branch HEAD, we have a a branch called HEAD , can the git administrator of Fedora delete this branch ? Thanks, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On May 27, 2013 11:17 AM, Sérgio Basto ser...@serjux.com wrote: Hi, git puts me crazy in here : http://pkgs.fedoraproject.org/cgit/debconf.git/ I have master now correct and want F19 be the same (git merge master) but do a commit just in F19, seems that never will be the same . I try fedpkg switch-branch f19 git rebase master merges conflict ??? I just want F19 be a copy master who I can do that ? Thanks, -- Sérgio M. B. -- I've been using git checkout $targetbranch; git checkout $sourcebranch -- relative/path/to/file to pull $file from $sourcebranch to $targetbranch. Globbing with * works, too. I have no idea if this is the best approach, but it works for my purposes. --Pete -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Monday 27 May 2013 18:17:19 Sérgio Basto wrote: I try fedpkg switch-branch f19 git rebase master Git rule #1 -- NEVER rebase a public branch (use git merge) [because rebasing rewrites history] -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron First they ignore you, then they laugh at you, then they fight you, then you win. -- Gandhi -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: git rebase master
On Mon, 2013-05-27 at 23:04 +0300, Oron Peled wrote: On Monday 27 May 2013 18:17:19 Sérgio Basto wrote: I try fedpkg switch-branch f19 git rebase master Git rule #1 -- NEVER rebase a public branch (use git merge) [because rebasing rewrites history] The ideal way to do it is to make your changes in 'master' and merge them down to any branches which have not yet diverged from 'master' at all: i.e. as long as your Rawhide and F19 builds are the same, you can just make changes in 'master' and merge them to 'f19'. As soon as your f19 build diverges from master at all, merging becomes inappropriate (and probably impossible) and you should instead use 'cherry-pick'. It helps to have at least a vague overview of how git is designed to be used, and what is the actual _point_ of the commands you're using in the intended git workflow. Just because the *content* of two branches is identical does not mean changes can be merged from one to the other with no issues. Merging will only work without issues if the change history of each branch is the same. In practice, you want to look at 'git log' for the two branches and check the commit IDs. If the last few commit IDs differ - even if the content of the commits is the same - you are not going to be able to merge without issues. At any point, if you're not sure what the hell is happening and you're getting error messages, *don't* just whack it with a hammer until it seems to be right, push that, and hope nobody notices; *do* yell for help from someone who really understands git (note: not me) in #fedora-devel or on here. -- 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
