IRC logs for #baserock for Sunday, 2015-06-14

*** pacon has joined #baserock00:43
*** zoli__ has joined #baserock01:58
*** zoli__ has quit IRC02:03
*** zoli__ has joined #baserock04:13
*** zoli___ has joined #baserock04:22
*** zoli__ has quit IRC04:22
*** zoli___ has quit IRC04:37
* paulsherwood discovers that ybd seems to be the first tool to need unpetrify-ref06:53
paulsherwoodbah. my br vm can't access network via my usb-connected phone08:45
*** zoli__ has joined #baserock08:49
*** zoli__ has quit IRC08:55
* paulsherwood notices we've misspelled daemon in DLT-deamon :/09:11
*** pacon has quit IRC11:16
*** pacon has joined #baserock11:19
*** pacon has quit IRC11:23
*** pacon has joined #baserock11:24
*** pacon has quit IRC11:43
*** pacon has joined #baserock11:45
*** pacon has quit IRC11:48
*** pacon has joined #baserock11:49
*** pacon has quit IRC12:24
persiaFor what does ybd use unpetrify-ref?14:01
paulsherwoodi'm trying --depth 1' to speed up initial user start. as a result it seems i need to do 'git fetch --depth 1000000 this['unpetrify-ref']' in the case where current SHA has not been found at tip of any branch19:01
paulsherwoods/trying/trying 'git clone /19:01
paulsherwoodthis is working, but showed (in definitions master) one example of 'unpretrify-ref' and one example of no field at all so far19:03
persiagit clone should work with a SHA1 that is not the tip of any branch.19:08
paulsherwoodin an existing clone?19:08
persiagit fetch has a documented bug about the use of SHA1s19:08
paulsherwoodyup, understood. my use-case is git submodule - eg gstreamer requires a non-tip checkout of gstreamer-common. i've already cloned gstreamer-common to calculate cache-key19:10
persiaBut I think git fetch will break with submodules even with that use of unpetrify-ref19:10
paulsherwoodno, it seems to be working19:10
persiaDocs say "Using --recurse-submodules can only fetch new commits in already checked out submodules right now. When e.g. upstream added a new submodule in the just fetched commits of the superproject the submodule itself can not be fetched, making it impossible to check out that submodule later without having to do a fetch again. This is expected to be fixed in a future Git version."19:11
paulsherwoodi'm fetching into the pre-existing --depth 1 clones /src/cache/gits19:11
paulsherwoodsadly i can't push my code... my br vm doesn't like airport networks19:12
persiaThat so many tools have such a dependence on high quality networks is a major failing with this particular toolset.19:13
persiaI am routinely in locations where everything doesn't work.  I recommend not using a VM on your laptop: using remote VMs somewhere seems a bit more stable.19:13
paulsherwoodfair point. but i'm developing locally on planes, too, with no network at all. ybd works pretty well for that use-case, once gits are pre-loaded19:14
paulsherwoodbut maybe this 'optimisation' will weaken that19:15
persiaVery much so.19:15
paulsherwoodi'll ponder, on my next flight :)19:16
persiaAs long as you have sufficiently deep clones for useful development of the trees that you need to modify, you will be fine.19:19
paulsherwoodit's hard to know what that depth would be, though19:24
persiaI find that I rarely need to review history more than about a decade, but that might just be me.19:39
paulsherwooddepth is nubmer of commits, though, not time.19:40
persiaI doubt there are useful heuristics.  Of the projects that I know that are more than 20 years old, some get an average of a commit a day, and others get an average of 100 commits a day.19:56

Generated by 2.15.3 by Marius Gedminas - find it at!