IRCloggy #git 2007-02-10

Logs Search ←Prev date Next date→ Channels Documentation

Provider of IRC logs since 2005.
WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

2007-02-10

bronson joined00:39
benlau joined01:16
RoomsterRomster01:32
linuxmigration joined02:19
orospakr_ joined02:31
T2 joined02:53
T2Tv02:54
linuxmig1ation joined03:23
linuxmig2ation joined03:28
linuxmigration joined03:29
linuxmig2ation joined03:37
kanru joined03:40
linuxmig1ation joined03:43
linuxmig2ation joined03:51
linuxmigration joined03:56
linuxmig3ation joined04:01
linuxmig4ation joined04:07
linuxmig1ation joined04:12
linuxmigration joined04:23
linuxmig2ation joined04:28
Romster joined04:38
bernardl_home joined05:09
linuxmigration joined05:15
bronson joined05:20
rkaway1 joined05:28
bernardl_home left05:28
mugwump normalperson: any thoughts on svn:ignore <-> .gitignore conversion?05:39
aeruder svndir=/home/andy/svnproj;gitdir=/home/andy/gitproj; (cd $svndir ; find . -type d | grep -v '\.svn$' | while read line ; do svn propget svn:ignore "$line" > "$gitdir"/"$line"/.gitignore ; done05:44
completely and totally untested ;)05:44
i already see i forgot a closing )05:45
Roomster joined05:50
orospakr joined05:54
kanru joined06:43
gitster sneezes... it's awfully quiet here...07:36
cehteh 07:38
Roomster joined07:51
RoomsterRomster07:58
Oeje1 joined08:03
cyrillos joined08:27
cyrillos left08:34
robinr joined08:45
Eludias joined09:10
benlau joined09:25
coondog joined09:47
coondog i have things that are changed but not updated, and I have run git-update-index like the comment said to mark for commit09:47
but then when i do a git commit the changes (ie. deleted files) and so on don't get committed09:47
Oeje1 coondog: Did you run git-update-index without any arguments?09:54
coondog Oeje1: yes09:54
Oeje1 Did you want to commit all changes?09:54
coondog Oeje1: and I tried running it with filename arguments09:54
yes09:55
and when i run git clone right now to check out a fresh copy i get what I originally put in there09:55
none of my changes have been commit yet09:55
but i have run git add a filename and then git committed it, added comments and everything09:55
Oeje1 Normally you would just use "git commit -a", which commits all changes.09:55
coondog huh09:56
looks like that just worked09:56
yeah i guess that didn't work09:57
when i want to checkout a fresh copy i should just use09:57
git clone right?09:57
and when I do a git status now, it says that there are no changes09:57
Oeje1 First I will point you to "man git-commit".09:58
coondog lol09:58
Oeje1 What do you mean by checking out a fresh copy?09:58
coondog as in i don't have the source code on my computer, let me check out a fresh copy09:58
benlau joined10:00
Oeje1 Yes, clone downloads the whole history in the remote repository, and checks out the files into your working directory.10:00
coondog so then what is going on?10:00
any ideas? because git status says that there is nothing to commit10:00
apparently10:00
Oeje1 You just committed something, right?10:01
I am a bit confused: You committed, and then cloned? Or are those two separate projects?10:02
devogon joined10:06
kim0 joined10:31
robfitz joined11:08
nud joined11:20
ferdy joined11:23
chris2 joined12:21
kanru joined12:41
kim0_ joined13:16
alley_cat joined13:16
kim0_ joined14:49
meyering joined14:55
Alex joined14:56
lhz joined14:59
mukund joined15:55
mukund the manpage for git-repack says that -a can be used when there's "no need to worry about people fetching via dumb protocols".. please can anyone explain that?15:56
is this for when git repos are accessed via file transfer protocols?15:57
i'm guessing this makes the person downloading new objects via file-transfer protocols get the entire pack file again, instead of new objects16:00
and git:// works around that by extracting and delivering the new objects from the pack file on the server side?16:01
orospakr joined16:05
kim0_ left16:08
niv guys, whish me luck.. i try to use git for etc-directory-tracking and have just updated my base-system..16:11
now there will be the step to rebase and update another box.16:12
gitster "repack -a" is unfriendly to dumb protocols for exactly the reason mukund guessed.16:17
mukund gitster: thank you :)16:31
linuxmigration joined16:36
niv any forecasts about the arrival of git 1.5.0 in the next 1,5 weeks?16:37
merlyn how would it affect you if it did?16:41
niv merlyn: well, it would be in my system image...16:54
it would affect not much... but i am curious16:55
matled gitster: anything wrong with the documentation patch for git-merge.txt (-m is optional)?16:57
mukund http://www.mukund.org/tmp/0001-Fixed-some-typos-in-git-repack-docs.txt17:48
does that look ok?17:48
robinr definitely better than the original17:51
send it to the mailing list17:54
mukund subscribing18:00
does it take a while to get the response to a subscribe message?18:02
got it18:06
nud joined18:09
coondog joined18:15
coondog none of my commits have taken place18:16
but when i do a git-status it says there is nothing to be done18:30
but when i do a git clone of hte files they are exactly they were when I frist initiated the source tree?18:30
anyone know about this?18:30
MadCoder_MadCoder18:30
mukund are you using a shared repository (CVS model)?18:31
did you push your commits to it?18:31
coondog mukund: yes i pushed it to the repository18:32
i have a repository on my local network18:32
but when I git add & git commit, doesn't that push it to the server?18:32
i mean once i do a git add & git commit , that pushes it to the server gith mukund ?18:37
mukund no it doesn't18:37
coondog what does?18:37
mukund it commits it in your local repository18:37
coondog so how do i push it to the server?18:37
mukund coondog: read the git tutorial18:37
coondog lol18:38
ok18:38
Oeje1 joined19:16
masterdriverz joined19:17
masterdriverz anyone know how i revert uncommited changes to a single file (w/o reverting other files) with git?19:18
Oeje1 masterdriverz: git checkout [‎file]19:19
lyakh joined19:19
tko hmm, git-checkout keeps uncommited changes IIRC19:19
I just use git diff file | patch -p1 -R19:20
and I'm sure there's an easier way but that hasn't stuck with me19:20
Oeje1 tko: Are you sure?19:21
(about git-checkout)19:21
tko well, I'm optimistic :)19:21
AFAIK it's git checkout <branch>19:22
Oeje1 tko: Go read the man page.19:22
merlyn or improve your psychic abilities19:24
mukund joined19:24
tko git-checkout [-f] [-b <new_branch> [-l]] [-m] [<branch>]19:24
git-checkout [-m] [<branch>] <paths>...19:24
it mostly says branches19:24
Oeje1 tko: Read on ...19:24
masterdriverz: Are you more confused now? :-)19:25
masterdriverz Oeje1: yes :)19:25
mainly 'cuz git checkout doesn't work, but it seems like it should19:25
tko well, I have both a branch and directory called 'patches' (not checked in) and git checkout patches checks out the branch.. and yes, I realize my mental model is affected by the circumstances19:26
Oeje1 tko: You have not gotten to the examples section yet?19:26
masterdriverz tko: git checkout -- patches ;)19:27
deleted file mode 10064419:28
index f67b4bc..000000019:28
^^ is that why checkout doesn't work?19:28
Oeje1 Is it deleted in the working tree, or in the index?19:29
tko Oeje1, nah.. if it's not in the synopsis I'm not reading it unless I'm *really* motivated :)19:30
masterdriverz looks like the index, but not the working tree19:30
tko the '--' is not mentioned in the synopsis :)19:30
Oeje1 tko: You are right. How is it written in the other man pages?19:30
tko git-commit: [whatever] '[--] [[-i | -o]<file>...]'19:31
not immediately standing out but still there19:32
Oeje1 git-rev-list <commit>... [ -- <paths>... ]19:32
tko hmm, also missing from git-diff19:32
Oeje1 tko: Are you up for a patch making it consistent?19:32
tko imagine that, I've been using git-diff branch1..branch2 -- file intuitively ;-)19:33
Oeje1, not really, sorry19:33
Oeje1 tko: I'm just fishing. :-) masterdriverz: How about you?19:34
masterdriverz Oeje1: it doesn't really bother me ... i'm more interested in restoring this file :)19:34
i could if you really wanted though...19:34
masterdriverz has nothing better to do19:35
Oeje1 masterdriverz: Have you operated git-format-patch before?19:35
masterdriverz nope :)19:35
Oeje1 OK, go for it then.19:36
masterdriverz Oeje1: patch needs to be against current git or just the latest tarball?19:38
Oeje1 Current master is best.19:39
masterdriverz :(19:40
Oeje1 I guess the tarball is fine, but then you'll not learn about git-format-patch.19:44
GyrosGeier joined19:55
cworth joined20:00
kukks joined20:16
DrNick joined20:34
normalperson mugwump: there was a valid reason for not having .gitignore sync with svn:ignore back when I used the command-line client as a backend20:48
mugwump: how would dcommit work, though?20:49
I guess having it as an option would be good20:49
I personally prefer .git/info/exclude myself (git-svn show-ignore > .git/info/exclude)20:49
mugwump wow, timing20:55
normalperson huh?20:55
mugwump I mean, I only just connected today :)\20:55
normalperson ah :)20:56
mugwump I guess it would allow for the ignore list to change over time20:56
normalperson yes20:56
I'm working on getting globbing working with reasonable performance20:57
mugwump on dcommit it would have to send the .gitignore files as dir/«svn:ignore» (where «foo» represents an entity in another dimension)20:58
Personally I'd like to see all of those properties available to be converted to dotfiles20:59
mugwump ruffles around for his svk extension patches21:00
normalperson yeah, I guess that could work21:00
I still have those around21:00
have you tried the latest version of git-svn (on git.bogomips.org)21:01
mugwump no, I'll take a look21:02
normalperson I'll probably push out globbing support in a bit21:03
mugwump globbing support in which part?21:04
normalperson I've been getting burned out working with the SVN API :/21:04
having something like this in your config: branches = branches/*:refs/remotes/branches/*21:04
that way you can track deleted branches and new branches, too (without having to constantly re-run multi-init)21:05
you should be able to do branches/*/project-name:refs/remotes/branches/* too21:07
mugwump that's a good idea, my workmates were confused that fetching didn't fetch all branches21:09
aeruder is the git-svn stuff for using git to commit to svn repositories? (kind of like svk in a way)21:11
mugwump very much like svk21:11
normalperson aeruder: yes21:11
aeruder very cool, i may be using that then, i need to use git for some stuff and was really not looking forward to using git for some projects and svk for others21:11
mugwump I also have a patch that lets you convert your svk repositories to git-svn format so you don't have to re-sync them again :)21:12
aeruder mugwump: resyncing isn't too much of an issue, i have a local copy of the big svn repos ( i think... )21:16
25000 revs or somethin, heh21:16
mugwump sure, but for pugs, parrot, it takes *days*21:16
mugwump is only mildly exaggerating21:16
aeruder mugwump: yea, it takes days for gnustep too, just i'm the one that did the cvs2svn originally so i still have the svndump i uploaded around somewhere :)21:17
probably nothing like gcc tho, man that is a huge repos21:17
mugwump KDE's is 48GB of svn21:18
or about 4GB of git pack ;)21:18
aeruder yikes21:21
but anyway, that is very good news, i will definitely look into that21:22
imo, git seems much more powerful than svk (or at least much more thought out)21:22
mugwump much easier to track wtf is happening for sure21:22
Oeje1 aeruder: It is indeed well thought out.21:22
A bit like an algebra.21:23
mugwump normalperson: I'm having problems rebasing these old patches, eg libsvn_ls_fullurl is now gone, what happened to it?21:23
aeruder and there are just so many cpan deps for svk that there are just so many points of failure21:23
merlyn I gave up on svk21:23
as soon as I discovered git21:23
aeruder yea, just until now i didn't realize git would halfway decently interoperate with a svn repos21:24
mugwump at kiwifoo camp, I almost had to run screaming when I heard Jesse jubilantly proclaim that they'd managed to "back a database onto svk"21:24
aeruder which is a necessity for me (svn is much more 'mainstream', and much easier to convince non hardcore-devs to check out using svn than git, or something like that)21:24
mugwump he then started talking like an eager kid about how you could then swap database updates "with anyone in the room"21:25
normalperson: is complete_url_ls_init the new function?21:26
normalperson mugwump: basically the new version of git-svn is a rewrite21:27
mugwump oh :)21:27
normalperson it's very different21:27
mugwump ok, well perhaps going through it one by one would be better21:28
Tv joined21:29
mugwump the first thing it needs to do is be able to collect the properties of a directory, so you can look for the "svm:source" and "svm:uuid" props21:29
then init/multi-init can check for and store the "upstream" URL this mirror path has copied21:32
then the revision properties need to be collected during "fetch" / "multi-fetch"21:33
aeruder mugwump: my biggest issue is that the most useful lines of docs for svk is a wiki (p.s. wiki's suck unless there's someone that makes a point to constantly be organizing) and an out of date svnbook clone21:33
normalperson hmm.. one issue with the new git-svn is that local refnames need to be unique throughout all remotes21:33
mugwump: but it should be able to support unique refnames within it's own [svn-remote "foo"] name21:34
mugwump: I take it you want to have multiple [svn-remote "..."] sections21:34
one with the svk source, another with the original source21:34
running tests, pushing out if all goes well21:35
mugwump oh, no, hardly anyone republishes their svk repositories21:35
most people push back to the centre21:35
normalperson but for fetching, you can fetch from your svk repo21:35
mugwump what I want to do is fetch from my svk repo, then run "rebuild" so that further fetches come from the original21:36
normalperson crap... I actually changed that part :x21:37
no more rebuild...21:37
mugwump Some people might be interested in preserving their merge information from their local branches21:37
no more rebuild? what's this on line 1316? :)21:38
normalperson it's not an explicit command anymore21:38
mugwump ah right21:39
normalperson I've rebased against Junio's master and pushed out glob support21:39
mugwump well all I'm interested in is that if I publish this mirror via git, and somebody mirrors it, they can pull further revisions from the upstream21:39
normalperson yeah, that should work if they fiddle with .git/config a little21:39
the problem is that git clone doesn't copy refs/remotes/ nor .git/config21:40
mugwump: I think what you want to do with your patches is in make_log_entry()21:40
Oeje1 left21:41
normalperson set $self->{-want_extra_revprops} somewhere and generate the git-svn-id: line in there instead of in do_git_commit()21:41
also, $_no_metadata shouldn't be a global variable in the future21:41
merlyn you have a variable in the future!?21:42
normalperson I still haven't used any newer version of git-svn than what's in Junio's master21:42
mugwump sure, it's written in perl 621:42
normalperson (on a real repository, at least)21:42
normalperson needs to stretch and eat lunch soon-ish21:43
aeruder git-svn is written in perl 6 ?21:44
normalperson most if not all options in git-svn should be settable per [svn-remote "..."] and not globally in [svn]21:44
DrNick is there an option to clone like --reference that will look in a repository for objects, but will not set it up as an alternate?21:44
normalperson aeruder: no21:44
aeruder oh, ok, phew ;)21:45
DrNick or a way to make an alternates-using repository stop using alternates?21:46
I'm looking for a way to do a new clone with 1.5 but not waste server resources21:46
merlyn git-repack I think21:46
some switch to say "pretend alternates is about to go away"21:47
mugwump yeah, git-repack -a might be enough21:47
normalperson rsync on the objects/ directory should work :)21:47
corecode do a non-shared bare clone?21:48
mugwump ah, I think git-repack -l is what you want21:48
DrNick lets find out!21:49
mugwump ooo, unhandled.log, me likes21:49
DrNick mugwump: nope21:53
mugwump git-repack -ald? :)21:54
DrNick too late now21:54
and I tried with -a -l21:54
mugwump and you didn't get just one big pack out of it?21:54
DrNick apparently not, because after21:55
oh wait, I should've probably removed info/alternates21:55
corecode eh?21:55
no21:55
not before repack21:55
DrNick no, after the repack and the deletion of the original and the renaming of the new to the original21:56
DrNick looks for another repository to experiment on21:57
orospakr joined21:57
DrNick nope, repack -l just doesn't do it22:00
mugwump normalperson: perhaps the rev_db needs to be keyed by repository UUID22:05
ie, one rev_db per tracked repository22:06
so that you can have local SVK revisions and remote SVN revisions separately22:07
normalperson mugwump: nope, the same commit can affect something in branches/foo and trunk but we have separate refs for trunk and branches/foo22:08
"same commit" on the SVN side of things22:08
wait, I might have misread you22:09
mugwump I mean, in do_git_commit, instead of writing the original URL / revision / UUID to the log message, I want to write the upstream one22:10
normalperson so .git/svn/trunk/.rev_db.<orig_uuid> and .git/svn/trunk/.rev_db.<svk_uuid>22:10
mugwump yeah, basically22:10
the SVK one might end up quite sparse22:11
normalperson yeah, that should work22:11
yeah, that's an issue with .rev_db :(22:11
mugwump still, 40000 * 41 is still only 1.6MB22:11
normalperson I'm not sure about adding an sqlite/bdb/gdbm/... dependency22:11
corecode pitties normalperson22:12
corecode a svn converter must be ugly as well22:12
mugwump your file format is identical to DB_File with RECLEN :)22:12
normalperson corecode:22:13
oops22:13
yeah, I lose it sometimes with SVN22:13
corecode what for do you need a db?22:14
not even my cvs converter needs a db22:14
mugwump you need to map from subversion revs to git revs22:14
normalperson mainly reverse lookups for doing "git svn log -r6"22:14
corecode oh that is for converting git->svn as well?22:15
normalperson everything else can be tracked by just keeping the max rev22:15
no, "git svn log" is simply a somewhat friendly wrapper for git log22:15
corecode eh?22:15
normalperson when somebody refers to revision [0-9]+, I can quickly look it up (and even show them the output as it would look in svn)22:16
corecode why would anybody want to do this?22:17
normalperson corecode: I want to be able to communicate with svn-only folks22:17
corecode oh22:17
corecode pitties normalperson even more22:17
normalperson eh, I'll live22:18
jeffpc joined22:20
normalperson bbiab, lunch22:20
robfitz joined22:39
robinr corecode: seen empty commits when doing incremental fromcvs runs?22:47
corecode no22:48
you?22:48
robinr yes22:48
corecode hm/22:48
how empty?22:49
robinr a commit, but nothing in it22:50
seems it already made a commit earlier with the wanted contents22:50
corecode ah22:50
hm.22:50
is this commit the first in the run?22:50
robinr no22:51
commits made on a branch22:51
corecode is the "copied" commit from the same run?22:51
robinr I don't know for sure, I think so22:52
corecode branch/head?22:52
robinr branch22:52
corecode vendor branch?22:52
niv mh..22:52
robinr a normal branch22:52
niv could you lend me some brain cells on how i could manage following scenario, please?22:53
i have a base system... with one git commit22:53
then i started to alter this base system..22:53
i customized it... and made several git commits22:53
now i have updated this base system..22:54
and now i should update the customized system as well.22:54
robinr remember a mail I sent where I had commented out a couple of lines. Could they be involved somehow?22:54
corecode hm22:55
lemme see22:55
niv and i would rebase now the custom system on the updated base system..22:55
*scratch head*22:55
robinr "overall" the results are ok, but at some points in the history things look strange22:55
corecode robinr: that shouldn't interfere22:56
how, strange22:57
robinr is it possible to make fromcvs convert up to a certain date? (to simulate incremental imports)22:57
corecode niv: merge?22:57
niv corecode: well rebasing sounds better, i think..22:58
the two systems have one commit in common :)22:58
corecode so?22:58
merge sounds good to me22:58
niv *scratch head*22:59
corecode robinr: yes, just hack it to exit22:59
niv corecode: well, ok, i try that :)22:59
linuxmig1ation joined23:00
robinr corecode: nicely commented code :)23:05
corecode is that irony?23:06
(european irony, not u.s. irony)23:06
robinr no23:06
corecode yah, i still hope that people will start using+hacking it23:07
robinr oh, i shouldn't have used the smiley there23:07
corecode so i opted for comments23:07
yah, irony indicator23:07
robinr isn't that ;-)23:09
corecode no, they started out as ":)"23:11
that ";)" one is stupid, IMO23:11
either you mean it funny, then it is ":)", or you don't, then it is "".23:12
robinr I meant "happy"23:12
corecode k23:12
robinr http://en.wikipedia.org/wiki/Emoticon23:19
I'm not sure hacking it to exit is that easy23:21
corecode ah23:21
sure is23:21
robinr it still need to look at the branch and ignore the changes that are too new23:21
corecode @fixedsets.clear23:21
or so23:21
Tv joined23:22
corecode the sets get committed in order23:22
you just have to break out of it23:22
robinr some of the sets are wrong, so I want to see when that happens23:23
i.e. drop revisions before the sets are computed23:24
corecode eh?23:24
wut?23:24
why?23:24
ah23:24
no23:24
much simpler:23:25
robinr how else could I figure what combination of CVS revisions cause the computed sets to go wrong23:25
corecode rewind the branches23:25
just have a look which files are involved in the set23:25
files/revs23:25
mugwump normalperson: I've re-done those patches against your current HEAD, but they're still missing the e-mail domain re-writing23:38
and I expect they will need tidying up23:38
normalperson mugwump: sure, send them over to me (normalperson@yhbt.net)23:40
mugwump should be in your inbox. I've got to shoot off.. just quickly trying to find the test script I wrote for this before23:40
normalperson k23:41
mugwump: got them, thanks23:42
mugwump: DB::single?23:44
mugwump er, whoops, that's a breakpoint :)23:45
maybe I shouldn't have cc:'ed the list on those ;)23:45
normalperson yeah23:46
mugwump darn, it looks like I've lost the old test script...23:46
oh well, it probably wanted to be re-written to use the real svk anyway23:47
normalperson there was a test in your last set of patches23:47
mugwump ah, ok23:47
gotta run... laters23:47
normalperson lates23:47
I don't think things like svm:source and svm:uuid should be stored in the .git/config (which is intended to be read/writeable by $EDITOR)23:58
rather a flag to enable/disable using those in [svn-remote "..."]23:59

Logs Search ←Prev date Next date→ Channels Documentation