IRCloggy #git 2006-11-29

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.

2006-11-29

→ riddochc joined00:20
→ DebolazX joined00:23
→ Gitzilla joined00:33
mugwump so, pasky, why does cg-update print the "Fast-forwarding" message to STDERR?00:34
er, cg-merge, I mean00:34
(not a criticism, just asking for the rationale...)00:34
pasky uh.. hmm.. can't remember, sorry :) it does so from the start, I think00:36
mugwump ok. it's just, if you're scripting, you normally don't want STDERR to be used for normal messages,00:37
unless the output of the program is intended to be captured00:38
would you accept a patch for that?00:38
er, I mean, would you consider a change to that behaviour with a suitably engineered patch? :)00:39
pasky yes00:40
→ anholt joined00:40
→ GeertB joined00:43
→ cdcarter joined01:11
cdcarter ok, so i have a git repo on my local machine, i want to upload it to my server as a bare repo so i can serve it, and use gitweb01:15
whats the best way of doing this01:15
spearce ssh into the server, `git --git-dir=myproj.git init-db`; then push to that directory from your local machine.01:16
ShadeHawk You have to initialize via git init-db --bare the git repository on server, push changes from client (or fetch on server), setup gitweb on server01:17
Insount_away → Insount01:17
spearce oh yea, duh, --bare. :)01:18
cdcarter cool01:18
git is looking really neat01:18
spearce we like it. :)01:18
cdcarter heh01:18
i get this error: fatal: git-init-db [--template=<template-directory>] [--shared]01:21
spearce that's a usage message, what was the command line you gave it?01:21
cdcarter git init-db --bare01:21
Thumper_ git --bare init-db01:21
cdcarter i get a USAGE message for that one01:22
Thumper_ swap the --bare and init-db01:22
cdcarter cdcarter@concentrationstudios:~/git-presenter$ git --bare init-db01:22
Usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--help] COMMAND [ ARGS ]01:22
cdcarter@concentrationstudios:~/git-presenter$ git init-db --bare01:22
fatal: git-init-db [--template=<template-directory>] [--shared]01:22
spearce heh, ok, that's an option we should support.01:23
and that's an old version of git.01:23
Thumper_ works for me in 1.4.3.501:23
spearce use instead then GIT_DIR=myproj.git git init-db01:23
cdcarter must not be running 1.4.3.5 then. :)01:23
cdcarter its version 1.4.101:23
mugwump ancient! ;)01:23
cdcarter from the ubuntu repo01:23
ill update that01:24
and trying to get it from the git repo and build it gives me errors01:26
spearce git.git always compiles.01:27
cdcarter has to do with openssl01:27
spearce ah01:27
cdcarter cache.h:6:21: error: openssl/sha.h: No such file or directory01:27
i have openssl installed though01:27
Insount cdcarter: You need the openssl-devel package (or whatever Ubuntu calls that).01:27
mugwump libssl-dev01:28
cdcarter libssl-dev it seems01:28
ok, its working01:29
this is good!01:29
ShadeHawk ah, well, that teach us to provide git version when asking "why it doesn't work"01:35
cdcarter ok, im on 1.4.4.1.ge151 ab=nd it still isnt working01:38
cdcarter@concentrationstudios:~/git-presenter$ git init-db --bare01:38
usage: git-init-db [--template=<template-directory>] [--shared]01:38
spearce git --bare init-db01:38
cdcarter ah ha01:39
→ hub joined01:41
dwmw2 → dwmw2_gone01:53
treitter is there any way to generate an index for a repo without having to do the "make scratch repo, commit, push onto original repo"?01:57
basically, I'm doing a bare clone of an existing repo with a valid index and everything. But the bare clone doesn't have an index of its own, and I'd like to avoid creating the scratch repo, doing a meaningless commit, etc.01:58
nevermind. I was running into a different issue02:15
cdcarter could someone help me with my gitweb apache configuration02:26
http://pastie.caboo.se/2477502:26
im getting a Forbidden error02:28
→ Gitzilla joined03:15
DraX I'm not sure how interested people might be in this but I've been working on a python class for accessing a git repository. It's mostly introspective but will have some manipulative abilities too (basic brancing and committing).03:15
it can do stuff like: http://rafb.net/paste/results/60UVKg67.html03:16
→ wildfire joined03:17
cdcarter DraX: it looks cool, is it pure python?03:29
DraX cdcarter: it parses git-* output03:29
cdcarter: I toyed with directly reading the tree, but decided I didn't want the headache03:30
cdcarter DraX: is the code public?03:30
DraX cdcarter: One sec and i'll put it up03:31
cdcarter DraX: cool03:31
DraX cdcarter: http://git.geekfire.com/?p=gitstore.git;a=summary03:33
cdcarter DraX: do you serve your gitweb on apache03:33
DraX cdcarter: yes03:33
cdcarter DraX: could i see your vhost, mine just fails?03:34
DraX add_edit_file is leftovers from the original GitStore implementation03:37
cdcarter DraX: thanks03:38
DraX and i have a violent (and sometimes wrongfully so) aversion to regex03:38
cdcarter hrm, my config stilld eosnt work03:41
and i set permissions03:42
drwxrwxrwx 3 cdcarter cdcarter 4096 Nov 29 03:38 gitweb03:42
-rwxrwxrwx 1 cdcarter cdcarter 131285 Nov 29 02:15 index.cgi03:42
DraX you may need to tell apache to handle .cgi03:43
cdcarter i have this line03:43
AddHandler cgi-script .cgi03:43
DraX should do it i think03:44
← puzzles left04:00
→ Gitzilla joined04:29
cdcarter im having problems with gitweb, http://pastie.caboo.se/24793 < thats my vonfiguration, and im getting 403 forbidden- no projects found04:32
← Newsome left04:59
→ lyakh joined06:00
→ kanru joined06:31
→ ferdy joined06:34
→ gitster joined06:54
→ puzzles joined06:56
→ meyering joined07:15
→ ShadeHawk joined08:19
dwmw2_gone → dwmw209:31
→ wildfire joined09:37
→ nud joined09:37
→ kanru joined11:03
→ biesi joined13:12
→ segher joined13:23
→ Oejet joined13:31
→ timlarson_ joined13:38
→ chris2 joined13:40
→ nud joined13:57
kblin there's no way I can get cg update to do the same as git fetch; git rebase origin, is there?13:59
fonseca You might be able to do it with a hook.14:12
kblin I just don't want to do a git merge but a git rebase instead14:13
fonseca Then you don't want to use cg-update, but cg-fetch14:13
There are some merge hooks where you could do ugly stuff before and after a merge, such as stashing away you local changes and rebasing them afterwards.14:15
kblin but how do I rebase after the cg-fetch?14:29
I mean, I don't mind using git fetch and git rebase, but I'm in the process of writing a guide to using cogito with wine, and I figured it'd be nice to use cogito for most of the stuff14:30
I can't cg-fetch a tree I cloned using git, right?14:31
→ GyrosGeier joined14:32
fonseca kblin: No, at least not for now. Cogito is moving to also use remotes.14:35
Why do you want to avoid merges so badly?14:35
→ DanielHolth joined15:02
ShadeHawk kblin: you might want to rework and resubmit 'rebase' merge strategy (formerly: 'subordinate' merge strategy)15:22
kblin: it should be somewhere on git mailing list15:23
→ hub joined15:23
→ benlau joined15:24
→ alc joined15:46
→ Oejet joined16:11
→ Newsome joined16:17
→ microm joined16:33
microm I can't compile git, I get ar: exec_cmd.o: No such file or directory (latest stable v1.4.4.1)16:34
→ spearce joined16:48
→ robinr joined16:55
spearce robinr: so i'm about 1/2-way through rewriting the pack access code in jgit. 16:57
meyering aconway: also includes the spec, and gentools, of course.17:01
ShadeHawk microm: do you have 'ar' installed? Do you have exec_cmd.o after compile?17:08
→ Gitzilla joined17:15
ShadeHawk what do you think is more important for gitweb: committags support (making http://somehere.com hyperlinks, making BUG(n) link to bugtracker), or remotes (refs/remotes) support?17:15
and does anyone want for gitweb to work also with StGit?17:16
spearce i don't know why you are doing remotes support in gitweb; i would think the committags would be more useful to more people.17:16
but i really don't use gitweb so don't pay attention to me. :)17:17
ShadeHawk well, someone asked for remotes support. on the other hand, someone posted plain_text_url committag support, admittedly broken17:18
spearce if the big project that i care about had a bug tracking system which had a web interface which allowed hyperlinking, i'd care very much about committags support. alas, it doesn't. :)17:18
→ anholt joined17:35
Gitzilla Tali: What if I want the submodule to track a branch that is _not_ master or HEAD?17:39
spearce (cd submodule;git reset --hard otherbranch)17:39
puzzles is submodule support mainstream?17:42
spearce no, not even into pu yet.17:42
puzzles aww :(17:43
→ DrNick joined17:44
→ kanru joined17:48
microm ShadeHawk: ar exists, exec_cmd.o is built, but immediately removed with rm -f (along with lots of other .o files), then ar does not find exec_cmd.o. I'll examine the Makefile...17:52
spearce robinr: rewritten pack code in jgit is in my web repository. 17:53
microm sorry, "rm -f libgit.a && ar ..." only deletes libgit.a17:54
→ Eludias joined17:59
microm I don't get it. In the Makefile, the command for the exec_cmd.o: is executed, but it's like $* is empty, so instead of getting exec_cmd.o, I get .o18:01
got it. I alias to make -r because I never use c. \make brings exec_cmd back into $*18:06
spearce hmm... jgit is 15 times slower than native c git.18:08
"log" of 164302 commits in 105s (jgit) vs. 7s (c git).18:09
ShadeHawk it would be nice if it got into pu. but it is in repository; read GitWiki on Submodule support for link.18:13
← microm left18:22
robinr spearce: i'll try it18:29
spearce robinr: it read the entire mozilla pack, but took 105 seconds to do it. :( 18:30
robinr how much speedup was there on the mozilla repo?18:31
spearce i'm not sure, gimme a couple of minutes to find out.18:31
robinr just curious18:32
spearce hmm, not much, past version was 146s.18:35
robinr I get the my history in 2.3s here18:40
used to be 2.718:40
spearce that's without mmaping too, i forgot to turn that on when i sent you the code. :)18:41
my mozilla test was about 73% of the original time, yours was about 85% of your original time.18:42
→ lyakh joined18:43
robinr my times varies more, some cases was over 3s18:44
the same "case", different runs18:44
→ alley_cat joined18:49
→ spearce joined19:01
robinr hmm, 2.419:16
with MapMode.READ_ONLY19:17
spearce try MapMode.READ_WRITE. We're slower with READ_ONLY.19:22
but not by much19:22
i removed the double decompression we're doing and it didn't make a difference for commit walking on the mozilla repository.19:23
i'm going to have to throw a profiler onto it to see if i can find where we are spending our time. argh.19:30
→ Gitzilla joined19:41
→ znephf joined19:46
robinr READ_ONLY is the only one that works19:56
spearce is your pack file not writeable by you maybe?19:57
dwmw2 → dwmw2_gone19:57
spearce packs are usually read-only so that might be the issue19:57
robinr it is19:57
it is writable, i.e.19:57
oops, looked at the wrong repo19:59
spearce the differnce in jgit though between the two formats is probably only a few machine instructions per byte read, maybe less.20:00
s/foramts/MapModes/20:00
robinr nah, slower20:00
spearce hmmph. that's interesting. less bytecode to execute yet it took longer. cute.20:01
tko hmm, is there some documentation about just how exactly does loving the index save the day when it comes to merge conflicts and other stuff the index is meant to help with? how things are made better when you understand the index20:02
I couldn't see anything clear in core-tutorial or tutorial or tutorial-220:02
robinr maybe my environment is not set up for benchmarking20:03
spearce mine isn't exactly either. :)20:03
but 100s vs. 7s is easy to test and compare. problem is i'm not sure where all of the time is going in jgit...20:04
robinr the difference is small, but seems repeatable20:04
ShadeHawk what about tutorial-3 (on git mailing list, http://permalink.gmane.org/gmane.comp.version-control.git/3162520:04
robinr spearce: as you said, a profiler is the way to go20:04
guessing is almost always wrong20:04
spearce robinr: know of any good free ones ? i use a commercial one at work, but don't have it here on my mac... 20:04
robinr I used perfanal a while20:05
ShadeHawk tko: index is the place where trivial merges got resolved. index is a place where different versions of file (ancestor, ours, theirs) get saved.20:05
spearce tko: it also stores the files which were merged cleanly, so they don't appear in a "git diff". thus "git diff" shows you only the files which still have unresolved conflicts. 20:06
ShadeHawk if there is conflict during merge20:06
tko ShadeHawk, too abstract I'm afraid. I'm yet to see a clear real-world example how the index makes things more easy .. I'll see the tutorial-320:06
I guess I'm missing the 'life with index' vs. 'life without the index' picture and just can't quite visualize it20:07
→ sgrimm joined20:08
tko having used/played with cvs, svn, tla, baz and bzr some aspects (like git diff) are surprising currently20:09
ShadeHawk tko: what spearce said follows from the "index as commit preparation stage". It allows to mark things resolved cleanly (and no, merge markers cannot do)20:09
robinr i understand the index is very important for git internal, but for the user interface I don't really understand it20:09
i use stgit most of the time and try not to think of the index20:09
tko ShadeHawk, what do you mean commit preparation and why should I care? svn et al have little problems without such thing20:10
ShadeHawk as Linus said other SCM use poor-man's-index anyway when preparing and generating a commit20:10
git allows you to meddle with it20:10
robinr ShadeHawk: wrong, it *forces* you to meedle with it20:10
ShadeHawk "working area", index is "staging area", and repository is "storage"20:11
robinr: Not exactly. With Cogito you can forget about index (almost completely I think)20:11
ajax i have never wanted to meddle with it20:12
tko my commits are usually two kinds.. subset (possibly full set) of files in working tree, or one/some of the files having multiple changes of which I want to commit one or two. first case has never been a problem (just commit those files) -- does the index perhaps help with the second?20:12
I'm trying to understand just what would be the workflow where the index helps20:13
spearce robinr: perfanal sysa we're spending 50% of our time in character set conversion. 20:14
tko currently I don't see it fitting into much anything I usually end up doing20:14
spearce commit bytes -> message string20:14
robinr spearce: sounds likely20:14
spearce: and in my case the conversion is wrong anyway :)20:15
it tries to interpret iso-8859-1 as utf-820:15
tko fwiw I sort of kind of understand where the index lies between the commit and working tree, but I fail to see the application for it20:16
robinr it would probably be faster to convert outside the reading, if and when conversion is wanted20:16
ok, some conversion is wanted regardless, but may be fast on a byte array than in a stream20:17
faster20:17
spearce right, lemme see what i can shave out of the commit constructor.20:17
robinr tko: to me the index looks like stgit, but with only one level20:17
spearce: isn't the conversion in the bufferedreader you use to read the commit data?20:18
spearce yea, but the commit header (non-message part) i can probably just do in byte[]s.20:18
and that lets me remove the reader.20:18
ShadeHawk tko: In the case of merge, you might have to correct (change) some files which merge algorithm resolved cleanly. Without index you would have no way to check differences between what you did and what merge did, only diff between merge parents and what is in working area20:20
tko robinr, ah, a description I can grok. (index doesn't have the commit message though, I think) .. don't see it too useful though :)20:20
robinr ShadeHawk: ok, that's a valid point.20:21
when merging (which is ofcourse most of what Linus does)20:22
ShadeHawk and that index is a kind of poor-man's-stgit is also valid20:22
tko ok, I haven't done enough merging to have such a problems20:22
ShadeHawk hack; hack; git update-index <file>; oh, I forgot something hack; _git diff_; git commit <file>20:24
is the same (with respect to _git diff_) as20:24
robinr tko: in a scaled up environment it is important (I think) to track how conflicts were resolve20:24
ShadeHawk hack; hack; git commit <file>; oh, I forgot something hack; _git diff_; git commit --amend <file>20:24
but --amend was added later20:25
DanielHolth Is 'git clone' supposed to eat my server for ten minutes on a 1 GB repository?20:25
ShadeHawk also, the index is what traces which files are to be added, or to be removed. some kind of at least implicit poor-man's-index is needed20:25
spearce DanielHolth: it may, the server needs to generate the pack for the client. 20:26
ShadeHawk DanielHolth: which git version? I think that for _clone_ new git just get's pack and doesn't explode it (as older version did due to sharing code with git-fetch and possibility of thin packs sent over wire)20:27
s/did/probably did/20:27
DanielHolth I think I'm using git-by-git20:27
spearce ShadeHawk: we've never exploded the initial pack. 20:27
tko ShadeHawk, ok, but merging aside why would I want to do update-index rather than commit <files> if I think I'm done?20:27
DanielHolth Actually I just saw the -s option, which is what I really want.20:27
spearce The issue poor DanielHolth is fighting is that the server is repacking the entire repository, which is somewhat expensive on a large repo.20:28
DanielHolth Now my network guy is asking me if it has a pretty Windows frontend & eclipse plugin.20:28
So anyway 99% of the source repository is one pack anyway. It would be nice if it figured that out.20:28
spearce I'm working on both a pretty frontend (git-gui) and an exclipse plugin.20:29
pretty gui is further along then plugin.20:29
DanielHolth Really? And Javagit I suppose.20:29
Neta20:29
nifty20:29
→ dmlb2000 joined20:30
ShadeHawk 38s vs around 2s for combinationf of clone -s, clone -s -l, clone -l20:30
tko spearce, can you make the pretty gui to have just one "do what I mean" -button? =)20:30
spearce tko: that's its default mode. but it doesn't have all of the commands that a git user raelly needs. 20:31
ShadeHawk strange that git-clone doesn't just transfer existing packs, but generate them on server side, _thickens_ them regardless of whether they are thin or thick, and regenerates index20:31
→ niv joined20:32
niv g'evning :)20:32
robinr SWT/Jface sucks20:32
I tried to change to using SWT.VIRTUAL to speed up the population of the revision browser. but then I had to rewite much of the code instead of using the nice interfaces20:33
niv ... i noticed, that git remote info storing has changed so far... and i learned how to store the remotes links into my .git/config... so far so good ...20:33
... so i have to use git checkout -b remotes/heads/<head> now to track the remote branches now?20:34
... and second question: how do i automate this... is there a way to have this ... at least per branch like in the old days?20:35
spearce robinr: i've thus far not had to deal with large jface models. :) 20:35
niv ... after a git pull i mean.20:35
ShadeHawk niv: erm? is should just work, regardless of whether you have remotes info in files in .git/remotes/ or in git config20:36
robinr spearce: maybe just me doing something stupid (as usual)20:36
ShadeHawk niv: unless you are talking about made default --use-separate-remote20:36
niv ShadeHawk: the first thing, which make me wonder was that after a fresh pull of git repository, there was only one local branch... master20:37
it is the default --use-seaprate-remote20:37
which is not a bad thing at all.20:37
... after i recognized, master was the only local branch, i began tracking next by git checkout -b next remotes/heads/next20:38
... and now i wonder, if the local heads (or at least some local heads) are automagically updated on git pull, and if not, how do i setup this.20:39
spearce no local heads are updated on pull, only tracking branches.20:41
niv so i have to update them by myself... ok :)20:41
spearce right. :)20:42
niv ... and for new heads or for a new entrypoint i simply have to establish a new branch?20:43
for new local heads..20:43
spearce yes20:43
niv ok, i hope i can train that habbit :)20:43
ShadeHawk Tali: have you considered mirroring your module2 repo as fork of git-git repository on repo.or.cz?20:50
niv: git can only merge into current branch20:51
niv: which is kind of obcous limitation (what about conflicts)20:51
spearce that's just laziness on our part. :) the merge driver could do trivial index merges on other branches.20:52
niv well i can live with that... together with that psi1-script from the list20:52
-i20:52
ShadeHawk niv: about new heads - the new glob support for Pull: lines/remote.<repo>.fetch should take care of that20:52
spearce: what about when merge fails?20:53
niv i try to read as fast as i can in my free time.. :)20:53
spearce ShadeHawk: notice the "trival" in my comment. :) merge failures can't be handled that way. 20:53
niv unfortunatelly, there are other disturbing things like university of science and sleep and other things, which take away much free time20:53
i notised the glob support-threads, but i havent read them.20:54
noticed *G*20:54
ShadeHawk spearce:<pipe dream> about git-gui - it would be nice if git-gui allowe to mark as _for commit_ not only file by file, but chunk by chunk of diff</pipe dream>20:57
spearce ShadeHawk: the thought has crossed my mind. :) 20:57
ShadeHawk spearce: by the way, what is relation between your git-gui and Paul gitool (in provenience, inspiration, and most important features)?21:00
robinr add qgit to the comparision table21:01
ShadeHawk: I entered that as a feature request in eclipse.. not implemented yet :(21:01
it would fit nicely into the eclipse quickdiff gui :)21:02
spearce ShadeHawk: Paul's gitool inspired me to write git-gui, i borrowed the icons from it, and some of his basic gui ideas. Then did more. git-gui can fetch/push/pull some branches, shows the current branch, has good amend support. 21:03
niv are there any screenshots yet about git-gui?21:03
spearce no, i've been too lazy to make them. :)21:03
niv hush? :) *duck*21:03
spearce oh, git-gui also crashes less than paul's first citool release. the code is more stable.21:04
niv well i am more familiar with a text terminal :)21:05
so its not that urgent :)21:05
spearce dammit, why did linus use hex strings for sha1s in commit objects, but binary ones in trees?21:06
ShadeHawk because most of commit is text, so it makes sense to make all of it text, while most of tree info (mode, sha1) is binary, so it makes sense to make all binary?21:08
spearce its not all binary, the modes are ascii. :)21:08
ShadeHawk (filename is also binary of sorts, because it can contain "\n", so has to be "\0" terminated, IIRC)21:09
Urgh? Why modes in tree are ascii?21:09
spearce Yup. :)21:09
ShadeHawk Hey, so we can use invalid (non-octal) mode for commit entries/submodules-in-trees support... or can't we?21:12
spearce no, because in the index its binary.21:12
niv mh... i still don't get howto switch back to a later HEAD, if you made git reset to a former head and want to get back...21:13
ShadeHawk Aaargh, using content-type: application/x-tar + content-encoding: gzip makes Mozilla uncompress gzip file on saving21:13
niv unfortunatelly i didn't remember the head former revision21:13
the former head revision :)21:13
ShadeHawk do you have reflog enabled?21:13
niv nafaik... or is it enabled by default?21:14
ShadeHawk otherwise, try git fsck-objects -v, or git lost-found and try to find from there (perhaps using gitk/qgit)21:14
niv well if i remember the head sha1, then i can easily switch back... mh...21:15
ShadeHawk core.logAllRefUpdates:: This value is false by default21:15
sorry21:16
niv so, it is useful to turn that on before going back in history and afterwards turn it back off?21:16
ShadeHawk core.logAllRefUpdates is useful to have turned on by default (if remember correctly there was patch for that on git mailing list)21:18
it allows for things like HEAD@{2 days ago} or HEAD@{2} (2 updates ago)21:19
cworth OK. Here's a quick git puzzle for somebody:21:20
There was a project in cvs. Someone took the HEAD from CVS, hacked for a while, then shoved the result into git and hacked away for a few months.21:20
Meanwhile, the original project converted all of its old history to git and conveniently, (though it wouldn't have made it any harder), hasn't done any work in the intervening months.21:21
So I just want to replay the one repository onto the other. "git-format-patch and git-am" would do the trick, except I need to take care of the "missing" code changes first.21:22
So, what's the simplest way to make a new commit onto one repository such that it has a tree equivalent to the tree of the initial commit in the other repository?21:23
What I tried was:21:23
anholt doesn't git-format-patch and git-am lose merge history during a branch? it seems like a poor replacement for git-rebase --onto.21:23
cworth git pull --strategy=theirs ../other initial-branch21:23
anholt: Does it? Well, I'd definitely like some replacement for "format-patch and am" without that bug. But, sure, I can just use rebase once I get both of these lines into a single repository.21:24
anholt cworth: what I've done before is fetch both branches into a repository, then git-rebase --onto origin company-first-commit company-head21:25
our only problem is company-first-commit != origin21:26
cworth OK. So a "theirs" strategy doesn't exist, but I guess I can use "ours" easily enough. It "feels" awkward, but it should work well enough.21:26
Never mind. No merge strategy will do what I want since I don't want to generate a multi-parent commit here.21:27
I feel like I should be able to just copy .git/index or so and get the result I want. Anybody have the trick for me?21:27
→ Beuc joined21:27
Beuc Hey. Is there any situation where a git repository can be automatically repacked?21:28
anholt cworth: actually, I think creating one that had as parents origin and company-first-commit, keeping company's would be fine. then we pull the rest of company's stuff onto it. won't that work?21:28
robinr cworth: git checkout <commitish> files will update the index to any version21:28
ShadeHawk cworth: I think what you can do is to fetch import and hack into one repository, different branches, and then rebase hack branch onto import branch21:28
Beuc I created a repository via git-shell today, and looking at it later, I was it packed. But the guy would imported the project only had git-shell access. I'm puzzed :)21:29
(I mean I created a repository accessible via git-shell only)21:29
ShadeHawk if there were changes since hack, I think it would be better to just merge two branches21:29
anholt ShadeHawk: that's exactly what we first tried, only the first commit of hack is not equal (at all) to any commit in import.21:29
cworth anholt: I should be able to do that with "ours" yes. And I guess it really is a more "honest" represenation in the history of what happened.21:29
niv ... one last thing... i think, the email went down in the storm of others... but seriously, the update-hook-example-script really doesn't work..21:30
cworth ShadeHawk: Yes, I want to rebase, and yes I would merge if there had been changes first.21:30
ShadeHawk ah, rebase tool needs <upstream>, which in this case would be NULL/VOID commit21:30
cworth ShadeHawk: The problem is that the first commit on hack doesn't apply at all to the head of the import due to the "missing" commits.21:31
ShadeHawk well, I think you could use cg-admin-rewritehist there21:31
or try to graft (using graft files) the hack branch on top of import branch21:32
ShadeHawk wonders how fetch deals with grafts21:32
cworth A single merge with "ours" followed by rebase seems to be doing the trick now.21:33
ShadeHawk you can rebase using merge with theirs/ours strategy21:33
cworth Hmm... merge conflict and failure at patch 166/434.21:33
ShadeHawk: Is there a "theirs" strategy? The message I got was:21:34
available strategies are: recur recursive octopus resolve stupid ours21:34
ShadeHawk Beuc: with new git, if pack file downloaded cross some threshold (also I think for push) it is stored thickened, instead of exploded into loose objects on receiving21:34
well, you can trivially modify ours to theirs21:34
and add it to list of available strategies21:35
cworth ShadeHawk: Yeah, so that's the one (tiny) bug I found so far in this. I should be able to put that together easily enough.21:36
ShadeHawk well, theirs strategy is I think usually not used for merges, and while I think it might be useful for rebase the rebase-using-merge is quite new21:37
and post patch to git mailing list...21:38
cworth But for now I'm trying to figure out why there's a patch failure during rebase. That shouldn't really be possible since I'm rebasing from one commit to another that should have the same tree (result of an "ours" merge), right?21:38
ShadeHawk check out if the commit it fails isn't merge itself21:38
cworth gitk suggests I did something seriously strange. Let me start over.21:41
ShadeHawk cg-admin-rewritehist with very simple parent filter: see etch-graft example in cg-admin-rewritehist(1)21:42
To "etch-graft" a commit to the revision history (set a commit to be21:42
the parent of the current initial commit and propagate that):21:42
cg-admin-rewritehist --parent-filter sed\ 's/^$/-p graftcommitid/' newbranch21:42
cg is Cogito21:42
Beuc ShadeHawk: cool. Do you know whether the threshold depends on the current push/pull size, or just repacks the repository after more than N MB of objects exist (i.e. even if the latest push was very small)? I ask because I wonder about installing an auto-packing hook script in each repository :)21:44
cworth Aha!21:44
So, I hadn't done anything all that weird after all. gitk just doesn't present multiple parent-less commits in a very intuitive way.21:45
(One branch ended up getting stacked above the other in the same color and it wasn't at all obvious that they weren't connected at all.)21:45
ShadeHawk receive.unpackLimit::21:47
If the number of objects received in a push is below this21:47
limit then the objects will be unpacked into loose object21:47
files. However if the number of received objects equals or21:47
exceeds this limit then the received pack will be stored as21:47
a pack, after adding any missing delta bases. Storing the21:47
pack from a push can make the push operation complete faster,21:47
especially on slow filesystems.21:47
cworth: did you use --topo-order option to git?21:48
cworth ShadeHawk: I'm just running "gitk --all". I don't know what options it might be using.21:49
ShadeHawk: The layout it presents is even quite reasonable really. It was just a bit surprising, (and the branch colors are actually different---it was just hard to tell that because the blue dots dominate the short lines for linear sequences).21:50
robinr cworth: try qgit, it lays out the branches slightly differently21:52
ShadeHawk s/to git/to gitk/ gitk actually passes the options to git-rev-list and adds some21:54
cworth Hmmm... rebase seems to be creating linear history only. That's not what I want.21:54
ShadeHawk what about the cg-admin-rewritehist? it is sledgehammer, I agree...21:55
cworth Heh, qgit presents an identical layout.21:56
mugwump hmm, that's only one branch at a time21:56
robinr no, --all shows all branches21:56
mugwump I mean cg-admin-rewritehist is one branch21:57
cworth At first I thought qgit would make the disconnectedness more obvious (the dots change color as well as the connecting lines), but it turns out that it colors both lines entirely red. :-(21:57
mugwump: What does "one branch" mean? I am replaying only one "branch", but it's not entirely linear, (it has a few merge commits in its history).21:58
mugwump I had to wrap it to deal with multiple heads. I guess I could have made an octopus and pointed it at that21:59
cworth ShadeHawk: Yeah, that might be the thing I want here. Or I could just make a merge commit and forget about it.21:59
ShadeHawk by the way, pasky, perhaps it would be useful to have ch-admin-rewritehist --sync-with-grafts which sould sync history with [given] graft file.22:02
cworth reads up on rewritehist22:04
cworth ShadeHawk: OK. Looks like etch-graft will do what I want as for as a replacement for rebase. There's still the issue of easily creating that first "missing" commit.22:09
Hmm.. some quoting problem or something. With the example etch-graft command I keep getting:22:14
sed: -e expression #1, char 1: unknown command: `22:14
ShadeHawk probably the whole sed invocation should be in "..."22:15
--parent-filter "sed -e 's/^$/-p graftcommitid/'"22:16
but I'm not sure22:16
cworth Ah, looks like I managed to cut-and-paste a character other than '22:16
ShadeHawk the graftcommitid would be of course the topmost commit of the cvsimport branch22:16
before etch-graft:22:17
cworth Oh, yes. Much more clear in this font. The man page gave me "’" where I wanted "'". :-(22:17
ShadeHawk 1---2---3---4---5 <-- cvsimpoer22:17
A---B---C---D <-- hack branch22:17
after etch-graft22:18
1---2---3---4---5---A---B---C---D22:18
cworth ShadeHawk: yup.22:18
ShadeHawk perhaps the commit message for 5---A should also be corrected, or some dummy 6' commit be created on top of cvsimport branch... your call...22:18
cworth Though what I have right now is instead an extra X commit in there:22:18
1--2--3--4--5--X--A--B--C--D22:19
Where X is a commit that goes from the tree of 5 to the tree of A.22:19
ShadeHawk A is initial (parentless) commit in the 'hack' branch, isn't it?22:20
cworth ShadeHawk: Oh, you're right, that would just work and I don't need my extra commit at all.22:20
← Beuc left22:20
cworth But, yes, I will want to rewrite that commit message.22:21
ShadeHawk: cg-admin-rewritehist is a more "true git" tool than "rebase" or "format-patch;am" since it only deals with trees, and never patches. That's nice.22:22
ShadeHawk well, rebase --merge also doesn't deal with patches, using "linear" merge instead22:28
on the other hand rebase and "format-patch; am" are higher level: you usually want to rebase _changes_, not the commits itself (so after rebase the branch would incorporate new features from trunk; this is not the case for rewritehist)22:29
cworth ShadeHawk: I gues I haven't read up on that yet.22:29
ShadeHawk: Yes. And something that rewrites history just turns out to be exactly what I wanted here.22:30
I just hope we can get rid of the git vs. cg- split at some point.22:30
ShadeHawk: Anyway, I've got the result I want now, so thanks for the help.22:30
→ halfline_ joined22:55
mugwump why would git diff-index show all files as, eg, :100644 100644 51be44f54793748bb2637280c7d54282fb99111b 0000000000000000000000000000000000000000 M .gitignore23:25
er, git diff-index HEAD23:25
oh, running inside fakeroot it does23:25
weird23:25
maybe it's something to do with that ipc stuff going on23:29
ShadeHawk have you reset softly to unrelated branch?23:34
mugwump no, normal `git-status' thinks everything is fine23:35
try it: fakeroot git-diff-index HEAD23:35
I'll try it on a newer git, this one is from the dark ages. 1.4.2.323:36
ShadeHawk don't have fakeroot23:40
niv there were ages much lighter before the dark ages *G*23:44
mugwump roman warm period? :)23:47
ShadeHawk dark ages?23:48
ah23:48
niv 1.4.2.3 was not too bad.23:49
ShadeHawk Oct 2 is not dark ages23:49
→ Newsome joined23:50
ShadeHawk if you still used 1.3.0 or 1.2.4 this woulc be dark ages. 0.99 would be ancient23:51
niv ... and bitkeeper pre-historic?23:51
mugwump well, 1.4.4.1 doesn't have the problem :-P23:52
Oct 2 is like 2 months ago. An aeon!23:53
there's been 1094 commits since that release!23:54
and that's just on next!23:54
ShadeHawk git rev-list origin | wc -l (which includes gitweb and gitk commits) is 705023:57
mugwump I did cg-log -s -r v1.4.2.3..next | wc -l23:58
ShadeHawk git rev-list v1.4.2.3..origin | wc -l is 121823:58
mugwump but yeah, good point - that's 1/7th of the lifetime of the project! :)23:58
measuring time in commits23:58
ShadeHawk but that includes merges23:58
Thu Apr 7 15:13:13 2005 -0700 <-- (one of) initial revision23:59

Logs Search ←Prev date Next date→ Channels Documentation