search for: reclone

I have moved all three repositories to new locations on github: https://github.com/libguestfs/libguestfs https://github.com/libguestfs/hivex https://github.com/libguestfs/febootstrap You don't need to reclone them (unless you want to). You can simply edit .git/config and adjust the URL to: git at github.com:libguestfs/libguestfs.git git at github.com:libguestfs/hivex.git git at github.com:libguestfs/febootstrap.git There is also a mirror of these git repos on http://fedorahosted.org/git You shouldn&...

> Install debian-archive-keyring: > > http://packages.debian.org/sid/debian-archive-keyring > > Debirf wants to pass it to debootstrap for verification. The other > possibility is to try to build an Ubuntu based appliance instead of a > Debian based one with: > > /configure --with-repo=karmic --with-mirror=<your_ubuntu_mirror> Hi, I just got the same issue, and

...ide, but just give a perspective on a few questions asked. >From an outsiders perspective, that list isn't what I'd typically describe as the workflow, since it makes "fork" and "branch" sound like difficult operations. This sounds akin to thinking that someone would reclone the svn repo before working on a new commit—possible, but rather extreme. The distributed nature of git means that the fork is pretty simple for github (essentially creates a new branch in their database, but that is just defining a new name for an existing commit). I've noticed GitHub recently...

...perspective on > a few questions asked. > > From an outsiders perspective, that list isn't what I'd typically describe > as the workflow, since it makes "fork" and "branch" sound like difficult > operations. This sounds akin to thinking that someone would reclone the svn > repo before working on a new commit—possible, but rather extreme. The > distributed nature of git means that the fork is pretty simple for github > (essentially creates a new branch in their database, but that is just > defining a new name for an existing commit). > > &g...

I think that it's really important that we try to strike some balance here. Based on my experience, this thread, and offline conversations, two things seem clear to me: 1. Overall, Phabricator is a superior tool for managing code reviews and some related processes (although GitHub's tools certainly have some benefits, and both are getting better over time). 2. Not accepting GitHub PRs