| 2006-05-27 |
| → robfitz joined | 00:06 |
| dwmw2 → dwmw2_gone | 00:19 |
|
| GyrosGeier wonders whether it would be safe to cg-fetch two completely unrelated remote branches at the same time | 00:40 |
|
pasky
| cg-fetch won't let you currently do that | 00:43 |
|
GyrosGeier
| ah | 00:43 |
|
pasky
| patch welcome | 00:53 |
|
GyrosGeier
| heh | 00:55 |
|
| it only makes sense for me while I'm on GPRS | 00:55 |
|
PugMajere
| Are the remote ends actually bandwidth limited enough to make it worthwhile? | 01:03 |
|
GyrosGeier
| the link doesn't seem to be 100% full | 01:04 |
| → coywolf joined | 03:02 |
| → agile joined | 03:36 |
| → cworth_ joined | 04:38 |
| → lilo joined | 04:54 |
| → somegeek joined | 05:02 |
| → somegeek joined | 05:10 |
| → Beber` joined | 06:24 |
| → lilo_ joined | 07:06 |
| lilo_ → lilo | 07:08 |
| → somegeek_ joined | 07:10 |
| somegeek_ → somegeek | 07:11 |
| → somegeek joined | 07:20 |
| → ferdy joined | 07:40 |
| → dst_ joined | 07:43 |
| → Andrew_NZ joined | 10:00 |
| → chris2 joined | 11:18 |
|
| jdl makes coffee | 12:02 |
|
ShadeHawk
| Are there any benchmarks comparing *network* usage (bandwidth, time, CPU on both sides) of git and other DSCM like Mercurial, Monotone and BitKeeper? | 12:05 |
|
jdl
| Not that I've seen yet. | 12:06 |
|
ShadeHawk
| quite a few benchmarks of disk space, some of speed (usually compared to Mercurial)... | 12:37 |
| cworth_ → cworth | 13:13 |
|
| jdl is the kolachi fetcher this Graduation morning! | 13:15 |
| → alley_cat joined | 13:25 |
| → lilo joined | 13:38 |
| → robinr joined | 14:10 |
| → cworth_ joined | 14:19 |
|
CIA-13
| Cogito: pasky * r5d3dd8dd8bb4 /cg-patch: Make cg-patch -d apply the patches in sorted order | 14:29 |
|
jdl
| How clever is the detection of "duplicate patches"? Start with a common repo, clone it. Some non-common time period later, the same patch was applied to each of the original and the clone. In the meantime, though, they have both had other different stuff done to them. Now, it is time to sync up again. The clone needs to pull from the origin(al). Will the patching cause a conflict now? Or is it clever enough to see that the | 14:33 |
|
| file-changes-effect is the same? I suspect that the commit message might be different, though. | 14:33 |
|
pasky
| it might or might not conflict, depending if that patch was the only one touching that bit of file or not | 14:35 |
|
jdl
| Hrm. So it will be file-content specific then. Good. | 14:37 |
|
| (As expected, BTW) | 14:37 |
| dedekind → dedekind_dead | 14:55 |
| → cworth__ joined | 15:26 |
| → biesi joined | 15:46 |
| → Vitamin-C joined | 15:48 |
|
biesi
| hm | 16:09 |
|
| why is git cherry-pick so much slower than git-show | git-apply? | 16:10 |
|
| and why can't I pipe git show into git am? | 16:20 |
| → gittus joined | 16:23 |
|
robfitz
| hi gittus | 16:24 |
|
gittus
| biesi: what version of git are you running? | 16:24 |
|
| in particular, for some loads, commit d1802851 will make cherry-picking orders of magnitude faster | 16:24 |
|
| hi robfitz | 16:25 |
|
robfitz
| I'll ask you the question in a bit. | 16:25 |
| cworth__ → cworth | 16:25 |
|
biesi
| hmm | 16:25 |
|
gittus
| Anyway, the reason that git cherrypick is slower than "git diff | git apply" is that it's actually a _lot_ smarter than that. | 16:25 |
|
biesi
| this seems to be 1.2.4.g7e93 | 16:25 |
|
gittus
| What it actually does is a magic three-way merge, except it uses the parent of the original commit as the base. | 16:25 |
|
| The three-way merge means that it will actually do the right thing if (for example) part of the commit had been applied already to the branch you are cherry-picking to. | 16:26 |
|
biesi
| I think this is basically the next branch from narch 25 | 16:26 |
|
gittus
| And if the merge fails, you'll be left with all the nice merge markers to make it easy to fix up, rather than an unexplainable .rej file | 16:27 |
|
biesi
| gittus, so I just hacked together a script that combines git-format-patch $rev^..$rev with git-am -3 | 16:27 |
|
gittus
| and yes, 1.2.4 doesn't have the --aggressive thing. | 16:27 |
|
biesi
| in what ways is that worse? | 16:27 |
|
| (it is better in that it takes seconds rather than half an hour) | 16:28 |
|
gittus
| Well, git-am should try the 3-way merge too, but basically, you're going to be screwed on patch apply errors | 16:28 |
|
biesi
| doesn't git am handle those OK? | 16:28 |
|
gittus
| Applying the patch will do the wrong thing if the patch happens to apply faultlessly, even though the patch had already been applied once | 16:29 |
|
biesi
| hmm | 16:29 |
|
| I guess that's true | 16:29 |
|
gittus
| Basically, any system that depends on applying patches is always going to be objectively worse than trying to do a three-way-merge | 16:29 |
|
| And with --aggressive, most real loads are really very efficient in git revert/cherrypick (they actually do exactly the same thing) | 16:30 |
|
biesi
| ok, I'll try a newer version then | 16:30 |
|
gittus
| The --aggressive thing was the performance issue that fixed the sourcemage thing that took several minutes, and after that commit it was down in the sub-second range, so it really should matter. Of course, it matters only for certain cases. | 16:31 |
|
| (The sourcemage issue was that they were cherry-picking across versions that had tons of files (unrelated to the cherry-pick) added or removed. That's when git cherrypick used to be really really slow) | 16:32 |
|
biesi
| ah, exactly my case | 16:32 |
|
gittus
| Btw, you don't even need to upgrade git. The fix is a trivial one-liner | 16:33 |
|
biesi
| that's ok, I like to use the latest version of stuff :) | 16:33 |
|
gittus
| So you can just edit your "git-revert.sh" file, and add "--aggressive" to the arguments to that "git-read-tree -m -u" line | 16:33 |
|
| (But yeah, upgrading to 1.3.3 should bea good thing regardless, it improves other things too) | 16:34 |
|
biesi
| awesome, that did help | 16:34 |
|
| gittus, thanks | 16:36 |
|
gittus
| you're welcome. We aim to please. | 16:36 |
|
biesi
| yep, in general using git is a pleasure indeed :) | 16:37 |
|
| although now that I know what a good VCS looks like, I hate using CVS/SVN... | 16:38 |
|
| shouldn't the message about a failed cherry pick refer to "git update-index" rather than "git-update-index"? | 16:40 |
|
gittus
| Hmm. I think we're a bit schizophrenic wrt "git-xyz" and "git xyz" still. We're clearly moving towards "git xyz".. | 16:43 |
|
| But "git-xyz" ends up still being required at least for man-pages, if nothing else. And it still shell-completes better without any extra rules.. | 16:43 |
|
biesi
| well, that specific message mentions both "git commit" and "git-update-index" | 16:43 |
|
| so it is inconsistent.. | 16:44 |
|
gittus
| Well, for a long time, the "git-xyz" format was preferred for the "internal" commands (that users wouldn't use directly), while the "git xyz" format was for the user-visible helper scripts | 16:44 |
|
| That explains the inconsistency: "git commit" is almost never written "git-commit", because people don't think of it as a low-level command. | 16:45 |
|
biesi
| oh, update-index is a low level command? | 16:45 |
|
gittus
| While git-rev-list is almost never written as "git rev-list", although that is _starting_ to change now. | 16:45 |
|
| And yeah, git-update-index is one of the original commands, and most people never need to use it. Most normal usage will be to use "git commit filename" instead. | 16:46 |
|
| (or variations, like "git commit -a" etc) | 16:46 |
|
biesi
| hm... I suppose so | 16:47 |
|
gittus
| Of course, once you embrace the index, especially for conflicting merges, you do start learning about the index, and you may start using git-update-index directly. But it's definitely a "level 2 wizard" thing vs a "level 1 plodding farmer" thing. | 16:47 |
|
biesi
| yeah, for conflicts update-index is very useful | 16:50 |
|
| ohh, this new gitk version allows me to browse the tree as of a specific revision | 16:53 |
|
| that's really cool | 16:53 |
|
robfitz
| My question is, is there a way to list all the commmits (objects) that being with a specific abbriviated sha1 value? | 16:58 |
|
| being = begin | 16:59 |
|
gittus
| Sure. Just do "git-rev-list --all | grep ^abbrev" | 16:59 |
|
| Of course, if the abbreviation is unique, you can just do "git show abbrev" to show the commit. | 17:01 |
|
robfitz
| Yeah, git-rev-list that should work. Not the commit wasn't unique. | 17:01 |
|
gittus
| And if you want all objects (this is going to be pretty expensive), add the "--objects" flag to the git-rev-list command. | 17:01 |
|
| Side note: if you really want any arbitrary object, and this is somethign you do _often_ (ie you care about performance), you're better off listing the objects some other way. | 17:02 |
|
robfitz
| I was using git blame to track down a problem with the kernel last weekend. And I couldn't think of away to do it. | 17:02 |
|
gittus
| git-rev-list is "expensive" in that it follows the object pointers, which isn't at all interesting if you just want to see any jumble of object SHA1's and don't care about how they are reachable. | 17:03 |
|
| For a more efficient "list every single object you know about", you'd just do a readdir() on the object directories, and look at all the pack index files, and list them all that way. | 17:04 |
|
| Without ever worrying about how those objects are actually _reached_. | 17:04 |
|
| Oh, then the easier solution would actually have been to use "git blame -l", which shows the whole SHA1 | 17:05 |
|
robfitz
| Yeah, that's the fix. | 17:05 |
|
gittus
| I think pretty much every command that shows an abbreviation should be able to not show it (and most of them you can tell the command how long an abbreviation you want) | 17:06 |
|
robfitz
| ok, thanks for the help | 17:19 |
| ← gittus left | 17:41 |
| ← marineam left | 18:22 |
| → fonseca joined | 18:53 |
| → Aexoden joined | 19:31 |
|
| jdl blinks | 19:40 |
| → GyrosGeier joined | 19:48 |
| → Oeje1 joined | 20:32 |
|
Oeje1
| Hard rock, halleluja! | 20:33 |
|
| Greetings. :-) | 20:33 |
|
fonseca
| Hej med dig. | 20:34 |
| → DrNick joined | 20:34 |
|
fonseca
| Oeje1: Going to Roskilde? | 20:35 |
|
Oeje1
| I've been looking at the shell scripts a bit. | 20:35 |
|
| fonseca: No, it's not my kind of festival. I think, I'm studying at that time too. | 20:36 |
|
| They shouldn't be that difficult to translate more or less directly into C. There's only about 6000 lines of sh. | 20:37 |
|
fonseca
| Are you going to make a small library? | 20:42 |
|
Oeje1
| Yes, I think so. | 20:42 |
|
Elrond
| Is it possible to remotely (via git:) get a specific object by sha1? | 20:43 |
|
ShadeHawk
| I wonder if removing dependency on shell would make git usable on MS Windows without help of GNU-ification like Cygwin (only with Perl and optionally Python). | 20:44 |
|
fonseca
| Elrond: There is always something like: ssh remote-machine "GIT_DIR=path/to/project.git git cat-file -p HEAD" | 20:45 |
|
Elrond
| fonseca - Well, I don't have an ssh-account on kernel.org ;) | 20:45 |
|
| ShadeHawk - It will help. | 20:46 |
|
| ShadeHawk - fork() does not exist on plain win32 | 20:47 |
|
ShadeHawk
| Elrond: you can I think get object by it's sha1 from kernel.org via gitweb | 20:49 |
|
| so, what, native Windows Perl implementation _don't_ implement fork? I was more woried about some system() call or backticks. | 20:51 |
|
Elrond
| I don't know about perl and fork. | 20:52 |
|
ShadeHawk
| as to bringing some library with git, that doesn't make using git on Win that much harder. Installing Cygwin does... | 20:52 |
|
fonseca
| As gitster pointed out yesterday, some forks may even be eliminated if it is written in C. | 20:54 |
|
ShadeHawk
| can anyone write good guideline for how to do benchmarking report at http://git.or.cz/gitwiki/GitBenchmarks | 20:55 |
|
| something including giving *version* of the tested SCMs (as performance changes), and perhaps the stats of machine although that might not be required for comparison? | 20:56 |
| → Oeje1 joined | 20:56 |
|
Oeje1
| Ups. | 20:56 |
|
jdl
| Hey. | 20:59 |
| → robfitz joined | 21:03 |
|
Oeje1
| jdl: Hejsa. | 21:38 |
|
pasky
| [offtopic] just in case, does anyone know if there is some (or someone is planning to do it) macosx emulation layer for linux/ | 21:58 |
|
| sort of like wine | 21:58 |
|
| I think it should be quite simpler | 21:58 |
|
Elrond
| No idea. | 22:01 |
|
| pasky - You don't happen to know, how one gets specific objects via git:? | 22:01 |
|
pasky
| you mean, over network? | 22:02 |
|
| or from the object database? | 22:02 |
|
Elrond
| Right. | 22:02 |
|
| Over network. | 22:03 |
|
pasky
| hmm | 22:03 |
|
| there has been a thread recently on git@ about that | 22:03 |
|
| can't remember the conclusion now, tho' | 22:03 |
|
Elrond
| Hmm, do you have a link? | 22:03 |
|
pasky
| 16405 May 24 Eric W. Biederm ( 2.3K) [RFC][PATCH] Allow transfer of any valid sha1 | 22:04 |
|
| no wait, that's not it.. hmm | 22:04 |
|
| Elrond: over network means which protocol? | 22:05 |
|
Elrond
| git: | 22:06 |
|
| Reading git-fetch-pack(1), it seems, git: gets an old ref and a new. So IF I could use that directly, I could of course just send commit^ and commit, where commit has a ref to the "new" file | 22:08 |
|
pasky
| I don' | 22:10 |
|
| t think there is a generic way to accomplish what you want in git now | 22:10 |
|
| but better ask on the mailing list | 22:10 |
|
| since I may well be wrong | 22:11 |
|
Elrond
| Hmm. | 22:12 |
|
| Okay, posted. | 22:26 |
| → goncha joined | 22:32 |
| → GeertB joined | 22:58 |
|
Elrond
| I finally did it the hard way: Clone the remote repos and extract the stuff locally using git-cat-file. | 23:01 |
|
| But let's see, if someone on the ML has a better way anyway. | 23:01 |
|
ShadeHawk
| commits you can get bu sha1id via gitweb | 23:22 |
|
| don't know about files and trees... | 23:22 |
|
| s/bu/by/ | 23:22 |