From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E5A9013838B for ; Mon, 15 Sep 2014 20:55:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 938BFE0930; Mon, 15 Sep 2014 20:55:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8C00DE08B2 for ; Mon, 15 Sep 2014 20:55:36 +0000 (UTC) Received: from [192.168.1.131] (CPE002401f30b73-CM78cd8ec1b205.cpe.net.cable.rogers.com [99.224.181.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: axs) by smtp.gentoo.org (Postfix) with ESMTPSA id A0DA133F52C for ; Mon, 15 Sep 2014 20:55:35 +0000 (UTC) Message-ID: <5417524A.2090806@gentoo.org> Date: Mon, 15 Sep 2014 16:55:38 -0400 From: Ian Stakenvicius User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] git basics References: <20140914140344.6c6b99e5@pomiot.lan> <16601943.lz3Cz1dQbC@localhost> <5415B757.8090800@gentoo.org> <1983964.TQhU476HiO@localhost> <20140915010646.8506.qmail@stuge.se> <54172509.1080301@gentoo.org> <54173163.3080604@gentoo.org> <54173E07.2030400@gentoo.org> <54174B09.8000706@gentoo.org> <54174CB4.4090908@gentoo.org> In-Reply-To: <54174CB4.4090908@gentoo.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 555f0254-212b-4110-b1dd-b915564d5fbd X-Archives-Hash: 22f5cb4f8fb3c76a230c6febbb7e4016 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 15/09/14 04:31 PM, hasufell wrote: > hasufell: >> Ian Stakenvicius: >>> >>> Repeating my example, say i'm working on a new release of >>> firefox, it takes ~40 mins to compile and there's some stuff it >>> needs to do with files in ${FILESDIR} during src_install. So >>> i'm 'ebuild ... install'ing that. In the meantime, there's a >>> high-priority fix that came up that I have to do in say, eudev. >>> Unless i'm doing my firefox work in the master branch locally >>> (and probably am running these tests on >>> modified-but-not-committed files), i can't just switch branches >>> to do/test/commit/push while ebuild does its thing in the >>> background. Or can I? I'd have to resort to (3), right? >>> >> >> 1. git checkout -b eudev-tmp (create new branch which has the >> firefox changes you just made and switch to it) 2. git reset >> --mixed HEAD~1 (dump the firefox patch back to the unstaged area, >> the file is still the same!) 3. fiddle around with eudev, commit >> and push 4. git checkout -f master (switch back to the master >> branch and throw away the unstaged changes in eudev-tmp, >> however... file is still the same) >> It's generally considered safe to push to origin/master a commit from a temporary local branch? how would that end up working with the repoman->push->[fail]->pull cycle due to possible non-fast-forward conflicts? how difficult will it be to ensure local history isn't all messed up, later on? >> Alternatives: Copy over the firefox ebuild to your local overlay >> before doing extensive tests and fiddling. That's what I'd do >> anyway instead of working directly on the tree. >> Yes, that's always a possibility as well -- having a second copy of the tree, pulling (local) changes from the working copy and merge-testing from that would reduce most of these concurrency issues.. Probably worthwhile suggesting this in the git workflow guide, as I expect there are plenty of people that test ebuilds straight from CVS right now. > > That said... I find that workflow a bit weird. Why is the firefox > ebuild already committed if it hasn't even been tested? > That's just how i tend to work with git in what little i've been exposed to: git checkout -b tmpbranch ; develop; commit; test && {squash,checkout master,cherry-pick,push} || develop [....] It lets me roll back to earlier commits if i want to undo something, or revisit some code that i discarded, or whatnot... Since committing != pushing, generally there isn't much harm, and i squash all these misc commits into one after everything's ready, so it doesn't clutter the history. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlQXUkoACgkQ2ugaI38ACPAmvQD9GeqZu6dHi5BSd2lpArMvHES/ whHLDOoPdXUeb3Uh99kBAKorCvYZFmKEDHWgvbnCuk/vfua58ItwOjtQIY/WG1Az =pNOG -----END PGP SIGNATURE-----