From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: developing for guix with git Date: Mon, 01 Feb 2016 00:49:09 +0100 Message-ID: <87y4b5ia2y.fsf@elephly.net> References: <87io2eszya.fsf@grrlz.net> <20160128222903.51f615c0@debian-netbook> <878u35bscu.fsf@grrlz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:60704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQ1kB-0004Kt-H6 for help-guix@gnu.org; Sun, 31 Jan 2016 18:49:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aQ1k7-0002Hj-Hi for help-guix@gnu.org; Sun, 31 Jan 2016 18:49:23 -0500 Received: from sender163-mail.zoho.com ([74.201.84.163]:25099) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aQ1k7-0002HO-8V for help-guix@gnu.org; Sun, 31 Jan 2016 18:49:19 -0500 In-reply-to: <878u35bscu.fsf@grrlz.net> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org Sender: help-guix-bounces+gcggh-help-guix=m.gmane.org@gnu.org To: Nils Gillmann Cc: help-guix@gnu.org Nils Gillmann writes: > Do you happen to know why guix in the situation I described, > being on an up to date branch following master refuses to build, > but once I switch to master branch, make clean, make clean-go (or > go-clean?) and run make (and the other commands) again it builds > successfully? This was my initial confusion. It’s hard to say without being able to take a look at the state of the branch. It is possible that a change you introduced in your branch broke things. Maybe you could share error messages? > I might have a thing or 2 to learn about rebasing and branching, but in > theory from what I know it shouldn't really matter which branch I am > on unless something's corrupted or broken. I think of a branch as a pointer to a some commit in the graph. Rebasing takes a range of commits and applies the changes they introduce on top of some other commit. When things suddenly break after rebasing the reason is usually in of two categories: * one of your (now relocated) commits broke something * after rebasing, master commits that have been added since you first committed your changes are now part of the history of your commits — maybe these commits altered assumptions that were still valid when you first committed your changes. An example for this is when a variable was renamed or moved in a master commit and your commits still use the old name. Sharing some error output with us might help us identify what’s going on in your case. In any case, you could try bisecting your changes (divide the set of your commits in half, and see if things are broken at that commit; then recurse until you find the commit that introduced the cause for the failure). This works best when you made many small commits. I’m using multiple branches for things that take me too long. For most developments, however, I’m working in a local “wip” branch, which is regularly and in short intervals rebased onto master. ~~ Ricardo