IRCloggy #git 2006-04-04

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-04-04

pschulz01_ mugwump: Can I delete the file/reset it?00:00
mugwump if you want to discard your local changes, you can use `git-checkout -f`00:01
pschulz01_ mugwump: That worked well.. thanks.00:02
mugwump np00:03
pasky > + if [ "$arg" = "-d" ]; then00:18
case "$arg" in -d)...00:18
umm00:18
gitster: I appreciate the attention to the portability; very nice to be able to run git-clean on a /bin/sh from 197500:19
but, er... what's the point? :)00:19
gitster the point is it is shorter, sweeter and more idiomatic so eyes can coast over when reviewing the code.01:33
mugwump hmm, interesting to see merlyn asking about git-svnimport on the list01:34
→ DrNick joined01:41
→ spuk_ joined02:36
→ anholt joined02:40
→ juvenis-- joined03:10
→ njs` joined05:46
→ pasky joined06:03
→ robfitz joined06:03
→ GyrosGeier joined06:13
→ gavin_s joined06:19
→ njs` joined06:21
→ gavin_s joined06:29
→ hharrison joined06:38
→ gavin_s joined06:41
→ gavin_s joined06:58
→ njs` joined07:11
→ gavin_s joined07:22
→ gavin_s joined07:42
pasky gitster: shorter, yes. :) I'm not sure if it is sweeter and more idiomatic for any other git developer than you... ;-) *shrug*07:58
→ gavin_s joined07:59
ChanServ set mode: +o07:59
pasky gavin_s: please msg someone from /msg chanserv access #git list after your connection is fixed07:59
pasky set mode: +b07:59
pasky set mode: -o08:00
gitster wonders what that +b *!* stuff is about, being IRC illiterate.08:17
GyrosGeier gitster, a ban08:17
pasky prevents the user matching that string from joining the channel08:17
gitster is again reminded that shell script style is far more personal than other languages, and also suspects it shows Pasky is as half as age as himself ;-).08:18
pasky gitster: yes, perhaps ;)08:21
pasky is 21 and already grew up almost exclusively in a GNU/Linux environment08:22
pasky (one of the few places where GNU/Linux usage is proper ;)08:24
→ ferdy joined08:25
njs` huh, what do you mean by "exlusively GNU/Linux environment"?08:25
gitster ... as opposed to having access to twenty different UNIX implementations and could run a porting lab if he wanted to, perhaps.08:26
pasky that I didn't use any other system a lot08:26
gitster: ...or having access to indows08:26
W08:26
njs` like, your grandparents use Linux? :-) Or maybe they just don't use a computer? :is curious about how different cultures work :-):08:28
gitster having access to is opt-in, so it is not so bad. Forced to use is what most people ends up with X-<.08:28
pasky I spent childhood in DRDOS, then one or two months on Win95 and then switched to Linux when I was 14 and got that cool P75 and have been living happily ever after :^)08:28
I've tried Linux on my 386 before but it really sucked ;)08:29
gitster happy, happy, happy, happy.08:29
gitster is borrowing a Solaris box at work and Linus/Jason signal patch seems to fix the clone problem.08:30
pasky njs`: my grandparents didn't use Linux :) but one my grandfather was a coder (done various scientific calculation stuff and physics experiments stuff at the academy of sciences) and thanks to him I got to programming08:31
pasky afk08:31
njs` nod08:31
pasky njs`: I meant, my grandparents didn't have computer08:31
mindtypo08:31
telmich mine do not have either08:34
GyrosGeier switched when writing his first thesis (you are required to do one in school)08:36
njs` weirdly, I know the guy who wrote the first UC Berkeley PhD thesis typed on a computer... he had one committee member who was just amazed every week, that he had incorported fixes and retyped the whole thing since their last meeting.08:37
GyrosGeier I chose "an implementation of the Gauss algorithm for solving equation systems in Java" as the topic.08:37
maths => LaTeX08:37
njs` (I guess it might have been the first not in the hard sciences or something)08:37
GyrosGeier I'm still amazed how much better at OO design I was back then, before my mind got twisted by templates08:38
→ Tv joined08:51
→ hh joined09:19
Oejet GyrosGeier: Do you know Haskell?09:27
GyrosGeier Oejet, not too well09:28
Oejet, we were forced to learn GOFER at uni09:28
Oejet, I learned it during the exam and forgot immediately after09:28
Oejet, the prof said that I was one of the few people who had understood the lesson09:28
Oejet Why do so many students at uni choke on functional languages?09:30
kampasky because they are different and not everyone is good at grasping new and very different concepts fast09:43
GyrosGeier I think it's mostly because they've heard that OO pwns09:45
so who needs functional?09:45
Oejet Java r0xers, right?09:45
kampasky at our uni OO isn't that prevalent09:45
GyrosGeier ack09:45
njs` hard core functional programming is _majorly_ abstract09:45
kampasky and students still struggle with functional programming09:45
njs` the difference between "hey, computer, do this than that than that" and monad combinators is kinda non-trivial.09:46
s/than/then/g09:46
GyrosGeier we have one professor who asks for assignments to be handed in on paper09:46
→ mchehab joined09:46
kampasky "do this" vs "what if" :)09:46
GyrosGeier she just browses through the pages, then says "the destructor on page 7 isn't virtual"09:46
kampasky :)09:46
njs` one of the major things in SICP is building lazy list structures, and in haskell that's like the first line of code you write ;-)09:47
kampasky we have "Non-procedural programming" course in the second year - first half prolog, then one lecture lisp and the second half haskell09:48
I kind of like haskell (but still can't imagine writing anything large in it) and I knew lisp from before09:48
but Prolog is weird - it's interesting but doesn't feel very good in practice :)09:49
ShadeHawk Well, SQL is on the similar ideas like Prolog (describe what you want, and steps, and compiler/interpreter does the rest)09:51
kampasky interesting point09:52
so, kind of "functional SQL" ;)09:52
gitster oejet still here?09:53
Oejet gitster: I am.09:54
gitster thanks for debugging session the other night (might have been afternoon for you).09:54
Oejet I'm trying out the next branch with the Solaris fixes.09:55
You're welcome.09:55
gitster Thanks. I made sure "master" still fails (it lacks the fixes) and "next" passes the "local clone" test.09:55
(I was on a Solaris box at work late night)09:56
Oejet Yes, saw that on the list.09:56
ShadeHawk kampasky: rather "SQL of logical statements/deduction"09:57
gitster I'll be heading for bed (now daylight saving time so it is 3am) soon, but I think I can do 1.2.5 with the Solaris fixes tomorrow (oops, today).09:57
GyrosGeier wonders whether it would be possible to get a "git bisect testcase" command09:58
gitster that would be wonderful.09:58
GyrosGeier also, I sometimes need a "git bisect noidea", when a tree fails to build because someone fecked up a commit, so I cannot tell whether it works or not09:59
gitster you need to have one good and bad, but after that you should be able to have a trivial shell script that autocruises git bisect sequence given a testcase.09:59
njs` that's exactly how traditional bisect search scripts work10:00
I think the reason bisect works this way instead of that is just that linus wanted it to hunt kernel bugs, and you can't run the kernel from inside a shell script.10:00
GyrosGeier (in which case I'd just like to try some other version without bisecting exactly in the middle10:00
well, I have a script that can run the kernel on an embedded box10:01
gitster The canned answer to GyrosGeier's question is to "eyeball git bisect visualize" output.10:01
GyrosGeier hm10:02
that does not help much for "this tree is borked, try another one" case, does it?10:03
gitster Then you pick another commit (visualize opens gitk), grab the commit object name and say "git reset --hard $that_commit", test it out and if it is good/bad, mark it with "git bisect good" (or "git bisect bad").10:03
GyrosGeier ah10:03
gitster That is exactly "try another one--which is this".10:03
→ cworth joined10:03
GyrosGeier wouldn't it pick the borked one again rather quickly?10:03
gitster Depends on which side of the broken one the real bug is and how broad the remaining search space is, but perhaps not, as long as you choose wisely (meaning, close to broken one). We are *bisecting*, so if your alternate choice is close enough to the one you would want to avoid, it should take a while before the avoided one becomes midpoint again.10:06
GyrosGeier true10:07
would you accept a patch to automate that?10:07
i.e. "git bisect dunno"10:07
gitster If it is just a simple "oh, this does not compile" kind of thing, "git bisect dunno" would perhaps be a simple "git reset --hard HEAD^" ;-).10:07
GyrosGeier gitster, well, one could try the next two choices for bisect next10:08
gitster, then we have a maximum "penalty" of one additional cycle10:09
gitster By "next two choices" do you mean "the commit we would suggest if the user said this borked one was good" and the other one for bad case?10:09
GyrosGeier exactly.10:10
gitster But then instead of trying to choose close to midpoint (because exact midpoint is untestable) you are choosing either 1/4 or 3/4 wouldn't you? Why?10:10
GyrosGeier this takes us away from the broken revision, increasing the chance of trying a non-broken version next10:11
if we pick the nearest one, there is a certain chance it is also broken, and thus waste another cycle10:12
gitster There's a truth to it, I agree.10:12
njs` pick the nearest one, if that doesn't work go twice as far away, repeat ;-)10:13
(to do it Optimally you need some idea of the conditional probability that some rev is broken, givne that some other nearby rev is broken...)10:13
GyrosGeier well, if the nearest one does not work, we already have as many cycles as we need with just going for both bisections10:13
njs`, go forward to the next commit whose message contains "argh", "stupid" or "head", "against" and "wall"10:14
gitster It really becomes heuristic. GyrosGeier's argument assumes an irrelevant bug tend to live for a while. If you instead choose to believe that silly irrelevant mistakes tend to be fixed quickly, going back one rev (forward is equally fine but is more expensive) would be optimum.10:14
GyrosGeier well, it evens out already when the next version we choose is also bad10:15
njs` GyrosGeier: I dunno, I tend to commit like 5 of those in a row, with progressively more caps and swearing as I discover how my last trivial fix totally didn't work.10:15
GyrosGeier so if the problem exists in one version only, we waste one cycle (or rather, close to one).10:16
gitster I tend to think of bisect an archaeology tool, also I think it is a good discipline to brew uncooked things in topic branches until they are at least free of silly obvious mistakes, so I hope 5 silly bad commits in a row would be rare in a history worth bisecting.10:18
kampasky different people have different standards and modus operandi10:20
gitster that's true. considering all things, I tend to agree with the "either 1/4 or 3/4 at random" suggestion made earlier by GyrosGeier.10:20
kampasky you could restrict gcc to require the source indented :)10:20
njs` gitster: you assume topic branches will be rewritten before being merged?10:21
GyrosGeier gitster, however in a project like the Linux kernel, entire arches can be broken for really long times10:22
gitster In the above sentence of mine, yes. At least in my topic branches, commits near the tip are not even merged into "next" and are cleaned up before becoming presentable.10:22
GyrosGeier, yes, I realize that now, so that's why I said I tend to agree with your "instead suggest 1/4 or 3/4 as alternative" approach.10:23
kampasky I really really cared about clean history, atomic branches and stuff when I started hacking elinks 5 years ago10:23
I still care, of course, but I'm much less anal about it now :)10:23
s/branches/commits/10:24
gitster you were on svn?10:24
kampasky gitster: nope, cvs... svn either didn't exist back then or was early alpha10:24
I think10:24
gitster wonders who kampasky and pasky are, and if they ever talk with each other...10:25
kampasky Version 0.6 (released 12 Nov 2001, revision 444)10:25
* 'svn log'10:25
gitster: we always start arguing when we talk with each other, so we gave up and just live quietly together in the single body10:26
gitster realizes it is already 03:30am and heads to bed...10:28
Oejet gitster: The current next branch seems to fix the Solaris issues for me too.10:30
kampasky gitster: right, I should go get some lunch10:30
gitster: 'nite to you :)10:31
Oejet Where do I get an overview of available C string procedures on a Unix system?10:40
njs` Oejet: info libc?10:40
kampasky that's on a GNU system :)10:41
njs` oh10:41
Oejet: ask your vendor10:41
kampasky http://www.opengroup.org/onlinepubs/000095399/toc.htm10:41
this is a useful reference for modern UNIX systems10:41
njs` yeah10:41
kampasky my most frequently visited bookmark10:41
Oejet njs`: kampasky: Thanks.10:42
→ chris2 joined11:02
→ coywolf joined11:09
→ spuk- joined11:47
→ boto joined12:00
→ timlarson_ joined12:39
Oejet What is the purpose of libgit.a?12:48
→ chris2_ joined13:04
chris2_ → chris213:12
jdl So, another factor in chooseing an alternate bisect spot is to select one either just prior to, or just after a major merge.13:15
Depending on if you think that merge was potentially _cause_ of problem, or likely to _fix_ problem.13:16
That is, maybe you can look at the merge log message and see something obvious like "merge up <frotz> fixes" or something.13:17
jdl didnt mean to scare Tv off...13:17
→ chris2_ joined13:24
chris2_ → chris213:26
Oejet found the explanation for libgit at http://article.gmane.org/gmane.comp.version-control.git/8705/.13:30
→ Tv joined13:51
→ ACSpike[Work] joined14:00
→ GyrosGeier joined14:03
→ cworth joined14:05
Oejet How does realloc resize an array?14:10
GyrosGeier try whether it has memory free behind it, if not, allocate a new one, free the old one.14:11
Oejet So all the pointers to the old one will be dangling, so one would use a layer of indirection (a pointer) to the array?14:13
Tv Oejet: don't realloc stuff others point to14:15
Oejet: but yeah, indirection helps14:15
Oejet OK, I get it, thanks.14:17
What do you think about this style? int next = (last + first) >> 1;14:25
fonseca s#>> 1#/ 2#?14:26
GyrosGeier Oejet, readable, but you should also check that you really ended up in the middle.14:27
Oejet I don't get the question?14:27
It's not my code, it's in read-cache.c14:28
GyrosGeier Oh.14:28
fonseca I think: int next = (last + first) / 2; is better style .. let the compiler optimize it to >> 1 or whatever. (if it was my question you didn't get)14:29
Oejet fonseca: Great.14:31
→ wildfire joined14:34
Oejet "cache.h: struct cache_entry" has a field "unsigned short ce_flags", in which many unrelated things are packed:15:08
#define CE_NAMEMASK (0x0fff)15:09
#define CE_STAGEMASK (0x3000)15:09
#define CE_UPDATE (0x4000)15:09
#define CE_VALID (0x8000)15:09
One should be aware that ce_flags is stored in network byte order, but wouldn't it be nicer to split that flag into several bit fields like:15:11
cache_entry {15:13
unsigned int name_length : 12;15:13
unsigned int stage : 2;15:13
unsigned int update : 1;15:13
unsigned int valid : 1;15:13
GyrosGeier bitfields are evil15:13
because they fill from top to bottom on LE and from bottom to top on BE15:13
i.e. you would need to reverse the entries15:13
and that's just for gcc15:14
Oejet Why would I need to reverse the entries? Isn't bit fields an abstraction for packing things yourself?15:14
GyrosGeier no, it's an abstraction for "do what you want with it"15:15
i.e. you have zero control over the layout15:15
the last compiler I wrote ignored bitfields and just gave every entry its own spot15:16
perfectly valid15:16
Oejet Since I haven't written a C compiler, I take your word for it. :-)15:17
Bit fields are used in cache.h, diff.h, diffcore.h, object.h, revision.h, and tree.h.15:19
Used, but not in as tricky a way.15:23
GyrosGeier well, they are fine for internal data structures15:32
you just shouldn't write them to disk15:32
(in fact, anything else than writing stuff to a char array is undefined behaviour)15:32
Oejet Signed or unsigned char? ;-)15:37
GyrosGeier yes. :-P15:52
Oejet What I don't get, is why keep in-memory data in network byte order. It seems it should be translated ntohl() at read_cache(), and htonl() at write_cache().15:55
?15:55
GyrosGeier ack15:55
but perhaps this is for mmap()ed indexes15:56
Oejet Aha.15:56
And cache.h: "We save the fields in big-endian order to allow using the index file over NFS transparently.". That's it, I think.15:57
GyrosGeier I have an index file on an USB stick that I carry from and amd64 box to a powerpc15:58
Oejet All that to avoid parsing some stupid cache entries. The on-disk index format is exactly as the in-memory format.15:59
That makes for easy serialization though. :)15:59
kampasky and fast16:04
Oejet mmap read the contents of the file into memory lazily, right?16:05
*reads16:05
fonseca kampasky: I don't quite get the test naming scheme. Shoul I use t9500-add.sh?16:07
kampasky fonseca: it degenerated to mostly random :)16:17
Oejet What purpose does the +8 and ~7 have in:16:30
#define cache_entry_size(len) ((offsetof(struct cache_entry,name) + (len) + 8) & ~7)16:30
is it some kind of word alignment?16:30
kampasky yes16:34
if you like playing with bits etc, you can try to figure out what (c >> 6) * 9 + c & (((c >> 2) & 0x10) | 0xF) does ;)16:35
Oejet passes out.16:38
Oejet See you tomorrow.16:44
kampasky waves16:46
→ benlau joined16:49
→ mcr joined17:07
mcr I am still disturbed by lack of $Id$. I know all the reasons for why it sucks. So, stick with me a moment. In the old days of SCCS, we had a neat program called "what".17:08
It searched binaryes for the string @(#), which there was a magic substitution in SCCS for. So, if you wanted to know what .c files when into a given binary, you could find this out by running "what /bin/login", and you'd get lines from each source file that had the version numbers in it. This is the only thing that I wanted $Id$ for. Audit trail.17:10
So, I'm thinking of something like the following in a source file:17:10
char gitid[]=GITSHA1;17:10
then -DGITSHA1="\"@(#) full-path-name [gitid]\"" on the compile space. I don't need any help doing this. Am I bonkers?17:11
fonseca Which doesn't leave trails in shipped tarballs ...17:16
An enhanced git export?17:17
→ anholt_ joined17:24
mcr fonseca... YEAH. no trail in shipped tar bars.17:26
balls. even. and I don't want to run sha1 on the file itself, because the thing I want to track is when source code leaves my desk... gets absorbed into ScrewThemHarder distro,17:26
PugMajere Unless you use gitid somewhere in the output, it might get removed by the linker.17:26
mcr patched to hell (with no comments), and then I get blamed, and I can't even tell what source tree they started from.17:27
If you look at *BSD code, you'll see that $Id$ has often been replaced with $NetBSD$ and $OpenBSD$... this is very useful when you move code back and forth between systems.17:28
the code isn't even at the same path names in their kernel trees...17:28
ShadeHawk Is there som mail size limit on git mailing list?17:28
mcr PugMajere, a static char foo[] will stay in the .o file. The problem is what to set things to.17:28
mcr wishes we had resource forks everywhere...17:30
PugMajere ShadeHawk: yes, umm, same as the kernel list, probably 50-100k, honestly.17:32
ShadeHawk who wonders why some mail didn't appear in the gmane archives/nntp interface.17:35
ShadeHawk No, the "lost" posts are way under 50k (below 10k, even).17:37
mcr gmane can take hours to crunch through stuff.17:37
okay... so my char gitid[] idea is okay if I can figure out how to keep the original SHA1 hashes somewhere.17:37
ShadeHawk mcr: If I remember correctly, there is some hack in GIT Makefile to make GIT version look like 1.2.4-8_chars_of_sha1 (or something like that).17:41
mcr yes... scripts/setlocalversion.17:42
It's nice... but it doesn't persist outside of the git repository.17:42
i.e. after git export.17:42
and it doesn't tell me which version of which file... just a general lower-8 of the commit id, which if I have the git repository, I might be able to recover enough info about.17:43
setlocalversion is in the kernel tree, actually.17:43
ShadeHawk commit-id gives tree, gives files versions, if I am not mistaken.17:44
ChanServ set mode: +o17:48
mcr but if you only have lower-8, then you have to search for the right commit-id.17:52
GyrosGeier set mode: -b17:53
GyrosGeier set mode: -o17:54
ShadeHawk Yes, but the version info is <tag>-<lower-8>, and those <lower-8> are for commit-id for commit which is descendant of <tag> commit.17:54
And which is probablu in 'master' branch.17:54
Er, is there any way to go from tag to descendants?17:55
gitster mcr, that is upper-n, and you can use "git describe" with your own precision if you do not like the default. It can give more than you specify if that prefix is ambiguous.17:55
So, my installed git is right now... "1.3.0.rc1.g00cb" (git --version), which means "a commit whose abbreviated name is 00cb that comes after 1.3.0.rc1 tag".17:56
And "git show 00cb" shows which version it is.17:56
mcr hmm. okay.17:56
gitster, didn't know that okay.17:57
gitster If somebody else _modifies_ what you ship, and they honor your embedding scheme, then their commit ID will be for a commit you do not have, so you are SOL.17:57
But at least you can tell it is not pristine.17:58
s/_modifies_/modifies and uses git to make their own commit on top of/17:58
mcr so question is now... how to preserve this info through stuff.... if I could get cg-export to stamp the info into all of my Makefiles, or make a new file with it in it...17:59
(I want it in all of my makefiles... because sometimes people take parts of a project...)17:59
→ Eludias joined18:02
kampasky mcr: you might find cg-object-id -d helpful18:22
ah, gitster already suggested git describe18:24
this is the same thing18:24
hmm, rewriting tarball, that'd need git-tar-tree support18:25
git-tar-tree --keyword-subst=Makefile would rewrite $Revision$ to $Revision: `git describe`$18:28
I'm not sure I really like the idea, though18:29
mcr nor I....18:29
maybe I should just have a pre-commit-hook that does $Id$ substitution on my files before they get into git.18:30
probably I don't know the commit-id... so I can't stick that in yet. too bad.18:30
→ gavins joined18:32
← gavins left18:48
→ gavins joined18:48
→ bjk joined19:52
bjk how do i have gitweb show a "tag" after a merge but without an actual tag. i see in the summary that 'master/exp' is shown after a git-pull (i think) but now it doesn't show.19:53
→ hharrison joined19:55
gitster gitweb reads from info/refs so you would need update-server-info in the repository you expose from gitweb.20:26
← mcr left20:40
→ DrNick joined21:34
ShadeHawk Branches in GIT are essentially just heads? They do not store the indoemation where they branched off?21:39
pasky off what?21:40
:)21:40
ShadeHawk Well, when they were created off some branch.21:42
Eludias A HEAD points to a commit.21:44
A commit forms a graph of commits.21:44
...so you just follow the parent of the HEAD.21:45
And its parent.21:45
And its parent.21:45
ShadeHawk Yes, but commits lead only to parents, so you don't see branching this way. You can't see history split.21:45
Eludias Finally, you get at a point where the parent (of parent of ..) is the same as parent (of parent of ..) other HEAD/branch.21:45
That's where they branched off from.21:45
Use 'gitk' for a nice visualisation.21:46
ShadeHawk Well, you have to track more than one branch parent after parent... and guess which branches has common ancestor.21:46
So the answer is yes (i.e. branches are ~= heads, and don't store the information where they started)?21:48
PugMajere correct21:49
It can be inferred, but it is not stored.21:49
ShadeHawk I find GIT branches more natural than Subversion ones, and much more than *ahem* CVS.22:05
(And one can always have the tag with the same name as branch, created at branch creation... or do tag and branch names musb, or better be different?)22:05
mugwump subversion branches are a hack22:05
ShadeHawk they are glorified (and hacked) snapshots, if I am not mistaken.22:06
and what you would say about CVS branches, eh?22:06
mugwump um. "of limited use"22:07
anholt_ if I've had to re-import my repository to git, but want to move the branch I'd developed in the old repository to the new one, is there a nice way to do it?22:09
(git-cvsimport got things all wrong, so I'm using parsecvs now)22:09
→ spuk joined22:25
Eludias How do I recursively add files to the index? 'git-update-index --add --remove .' doesn't work...22:25
Ah, 'find * | git-update-index --add --remove --stdin' does the trick...22:36
ShadeHawk git-update-index hasn't got --recursive option?22:37
Eludias Nope, and refuses to work on './' files.22:38
And on '.*' files.22:38
gitster how about "git add ."?23:05
anholt_ is finding that git-format-patch followed by git-am is resulting in failed patching of the new file created and modified in this series of patches23:21

Logs Search ←Prev date Next date→ Channels Documentation