| 2006-06-04 |
|
jdl
| Now, when I clone using http: all is well as it correctly maps the URL using the Apache Alias entry. | 00:00 |
|
| However, when cloning via git: it doesn't do the Alias mapping based on the given website prefix part of the URL. | 00:00 |
|
| I would have to clone using git://www.foo.com/pub/foo/scm even though I would clone using http://www.foo.com/pub/scm/ | 00:01 |
|
| So my proposed solution is to setup a genarlization of the git-daemon -baser-path=path argument. | 00:01 |
|
| Instead of a single --base-path, there are potentially multiple --base-path entries that match multiple a URL prefixes. | 00:02 |
|
| Thus, I'd use something like: --map-base=www.foo.com/pub/scm:/pub/foo/scm --map-base=www.bar.com/pub/scm=/pub/bar/scm | 00:04 |
|
dormando
| mod_rewrite for git :| | 00:04 |
|
jdl
| Quick prefix hack, yeah. | 00:05 |
|
| Um, stop me before I hack....? :-) | 00:06 |
|
dormando
| you're going to end up needing something that supports basic regexes before long | 00:06 |
|
| I can't think of many cases where you'd want to directly map like that, and especially in that specific manner. | 00:07 |
|
jdl
| I can't hear you. | 00:07 |
|
dormando
| sorry. | 00:07 |
|
| dormando was going to have similar problems for his hosting service | 00:07 |
|
jdl
| I'll scrape for ML too, I suppose... | 00:09 |
|
| Is there a better approach? Or am I being blind to the obvious solution here? | 00:09 |
|
BearPerson
| git:// uses ssh, right? | 00:10 |
|
dormando
| git:// uses git-daemon | 00:10 |
|
| git+ssh uses ssh? | 00:10 |
|
jdl
| git: uses ssh | 00:11 |
|
BearPerson
| ah, sorry | 00:11 |
|
dormando
| nm | 00:11 |
|
| dormando shuts up for good this time | 00:11 |
|
jdl
| Well, git: uses ssh and then git: | 00:11 |
|
| Can ssh swizzle that for me? | 00:11 |
|
BearPerson
| I'm probably thinking bzr, there you could just home foo-user's ssh account at /pub/foo/scm and bar-user at /pub/bar/scm | 00:12 |
|
jdl
| Oh, it's all just me ssh'ing in there... | 00:12 |
|
| Uh oh. Dinner call. BBIAB. | 00:13 |
|
| Feel free to discuss amongst yourselves. :-) | 00:14 |
|
dormando
| ah shit, you posted my idiocy to the list | 00:16 |
| → cworth joined | 01:23 |
| → benlau joined | 02:09 |
|
| jdl apologizes? | 02:16 |
|
eleusis
| heh | 02:17 |
| → coywolf joined | 02:58 |
| → dst_ joined | 03:37 |
| → cworth joined | 04:36 |
|
njs
| hmm, monotone can't do clashing merges sanely in the workspace because our merger had some deeply-coded assumptions, and didn't get rewritten until recently :-) I am not entirely sure what the index is in git, but we are working on adding in-workspace merge now, and haven't seen any reason to add any new concept we haven't had for ever and ever... | 06:05 |
|
| *sigh* it would be kind of nice if gittus stopped making things up about monotone and telling them to people :-) | 06:05 |
| → Tv joined | 06:26 |
| → njs` joined | 06:56 |
| → Soulfly joined | 07:03 |
| ← Soulfly left | 07:03 |
| → mchehab joined | 07:25 |
|
ShadeHawk
| njs: so first part in "I think that monotone (for example) still can't do clashing merges sanely in the workspace, exactly because they don't have our [git's] kind of index" is true, second is undecided? | 07:27 |
|
| njs: 'undecided' until you do clashing merges in workspace... | 07:28 |
|
njs`
| ShadeHawk: right, I think, monotone ATM doesn't do merges in workspace, but I can't think what this would have to do with not having git's index | 07:29 |
|
Capso
| If you use 'git pull' for a new branch... do you have to configure and make and all that for that branch, if you're already configured and done 'make' for the master branch? | 07:35 |
|
ShadeHawk
| I think that gittus is of opinion (maybe wrong) that you can't do clashing merges 'sanely' (whatever that means) using only workspace; some kind of index (or temporary space) is needed. | 07:35 |
|
njs`
| *shrug* maybe | 07:36 |
|
Capso
| Any ideas about my question? | 07:36 |
|
| I think it's pretty basic. | 07:36 |
|
njs`
| ShadeHawk: do you have a pointer to a conceptual explanation of what an index is? | 07:37 |
|
| or not so conceptual, but anyway, an explanation :-) | 07:37 |
|
ShadeHawk
| What do you mean by "configure and make and all that", Capso? Isn't it _working space_ concept? | 07:38 |
|
| njs`: as of now... I think not, unless you dig it from some git article, or tutorial. But it certainly is to come to GitWiki :-P | 07:39 |
|
Capso
| ShadeHawk: Not so familiar with the ways of git. | 07:40 |
|
| ShadeHawk: Does it merge codes of different branches together so you just have to do 'make clean' and 'make' ? | 07:41 |
|
ShadeHawk
| Capso, git doesn't overwrite untracked (including ignored) files, so config.cache and *.o should be safe... but mtime might make make to do unnecessary work. | 07:41 |
|
Capso
| ShadeHawk: Or is the code of each branch so separate that you go through './autogen.sh' (if any), './configure', 'make', and 'make install' for each branch? | 07:41 |
|
ShadeHawk
| Capso: No, you merge different branches together to bring changes from different branches into one branch, e.g. if you release new stable version (which is in "master", and was getting fixes only) joining development version (which was in "next" and was getting new features), you do a merge. | 07:43 |
|
| Capso: No, git doesn't use Subversion/Vault strange notation of branches as snapshots/copies/directories. To work on branch you have to checkout it to working directory. | 07:45 |
|
| Untracked files (config.cache, *.o, which should be in .gitignore or info/exclude) are left alone, and I think also unchanged files are left alone. | 07:46 |
|
| where left alone means that it doesn't change mtime (which make uses for checking if it needs to recompile) | 07:47 |
|
| BTW. beware of local, unsaved modifications. | 07:48 |
| → _JusSx_ joined | 09:54 |
| → north joined | 10:03 |
|
_JusSx_
| git uses VIM as default editor, how can i change it? | 10:05 |
|
normalperson
| _JusSx_: VISUAL or EDITOR environment | 10:08 |
|
_JusSx_
| ok thanx | 10:08 |
| → ferdy joined | 10:13 |
| → chris2 joined | 10:17 |
|
ShadeHawk
| Can anyone help with writing http://git.or.cz/gitwiki/Git ? I'm stumped somewhat. | 11:28 |
| → mchehab joined | 11:48 |
| ← mchehab left | 11:54 |
| → pasky joined | 12:03 |
|
laj_
| im no good at writing stuff like that, but the paragraf :implementation: could mention that because contents is store by it sha1-name no 2 files or tree's with identical content are stored more then ones | 12:08 |
|
| hence no need for extra work during packing | 12:09 |
| → struct joined | 12:32 |
|
fonseca
| ShadeHawk: On Git page: effectivity -> efficiency? | 13:24 |
|
| I think that maybe in the design section, the difference/separation between git-core and git-scm could be mentioned either in the "pure content tracker" part or in the top. | 13:28 |
|
| I will go over it and fix minor typos. | 13:29 |
| → alley_cat joined | 13:29 |
|
fonseca
| "loosely-knit team of hackers" .. this never gets old, huh? ;) | 13:29 |
|
ShadeHawk
| git-core/git-scm separation is _somewhat_ mentioned in "Toolkit design", but it is rather late on the page... | 13:37 |
|
fonseca
| Ah, the plumbing comes later, sorry. | 13:37 |
|
ShadeHawk
| perhaps it should be mentioned earlier and/or more clearly | 13:38 |
|
| feel free to contibute. | 13:38 |
|
| I'm stumped somewhat | 13:38 |
|
fonseca
| It's good. :) | 13:39 |
|
| Under tree object you mention "type bits" is this the mode bits? | 13:43 |
| ← coywolf left | 13:43 |
| → yashi joined | 13:49 |
| → GeertB joined | 13:57 |
|
ShadeHawk
| ermm... most of this is copied from Wikipedia article... | 13:58 |
| → benlau joined | 14:06 |
|
laj_
| as i read it "type bit" refers to tree_entry_list i tree.h, as in filemode and type{file,dir,symlink} | 14:07 |
|
| bits* | 14:07 |
|
fonseca
| Yes, ok. | 14:19 |
|
| jdl blinks | 14:46 |
| → lyy_ joined | 14:54 |
| → BearPerson joined | 15:28 |
| → mcheha1 joined | 15:41 |
| → benlau joined | 16:05 |
| → lkj1 joined | 16:33 |
|
lkj1
| why won't git compile? | 16:33 |
|
| I get these errors: http://pastebin.com/ | 16:33 |
|
ShadeHawk
| lkj1: Erm, perhaps you could give pastebin numer? | 16:36 |
|
lkj1
| oops | 16:55 |
|
| sorry | 16:55 |
|
| http://pastebin.com/757914 | 16:56 |
|
| lol, ShadeHawk, sorry | 16:56 |
|
| :) | 16:56 |
|
jdl
| Can someone reminde me what the "git clone git:..." pipeline ends up looking like on the remote end? What is the actual executable started by ssh that is serving up the packs and objects? | 16:57 |
|
lkj1
| git won't compile... http://pastebin.com/757914 | 17:08 |
|
jdl
| Do you have a zlib installed and usable somewhere? | 17:09 |
|
| undefined reference to `deflate' | 17:10 |
|
| undefined reference to `inflate' | 17:10 |
|
lkj1
| oops, no. | 17:10 |
| → cworth joined | 17:11 |
|
jdl
| Can someone reminde me what the "git push git:..." pipeline ends up looking like on the remote end? What is the actual executable started by ssh that is serving up the packs and objects? | 17:12 |
|
lkj1
| I just installed zlib, but it still won't compile: http://pastebin.com/757948 | 17:14 |
|
jdl
| What version of git are you trying to build? | 17:17 |
|
| update-cache? | 17:17 |
|
| Git 0.01? | 17:17 |
|
| Really? | 17:17 |
|
| Um, find a current tarball...? | 17:18 |
|
| Like, 1.3.3 or so. | 17:18 |
|
| lkj1? | 17:27 |
|
lkj1
| jdl: I just compiled 1.3.3, it looked like it worked, but when I try to run it.. bash: git: command not found | 17:27 |
|
jdl
| What was the commandline you used to compile it? | 17:28 |
|
| Did you install it too? | 17:28 |
|
lkj1
| make && make install | 17:28 |
|
jdl
| Is $HOME/bin in your path? | 17:28 |
|
| is git properly installed in $HOME/bin/git now? | 17:29 |
|
lkj1
| Um, I don't see a /home/bin/ | 17:29 |
|
| huh, I installed it as root, so it installed to /.root/bin/git | 17:30 |
|
jdl
| Normally, a default build compiles for an install into ~/bin. | 17:30 |
|
| Don't build it as root. | 17:30 |
|
lkj1
| do I just mv that dir to /usr/bin ? | 17:30 |
|
jdl
| Where do you want it installed? | 17:30 |
|
ShadeHawk
| read the INSTALL and options you should give to 'make install' to see where git is installed (and what to put in PATH) | 17:30 |
|
lkj1
| just to where I can run it as normal user from command line | 17:31 |
|
jdl
| And if you rebuild, "make clean" first. | 17:31 |
|
lkj1
| Ok. I just ran make clean and the make as my regular user, but it gets the zlib errors again | 17:32 |
|
ShadeHawk
| what to name 'filesystem directory hierarchy', i.e. that what is covered by tree objects in git? | 17:33 |
|
jdl
| Did the link line try to include zlib or not? Is it in your link line properly? Is zlib readable by you? | 17:34 |
|
lkj1
| How do I find out? | 17:36 |
|
jdl
| Read the "make" output for starters. | 17:36 |
|
lkj1
| it says: /home/junz/.local/share/Trash/files/git-0.01/update-cache.c:95: undefined reference to `deflateInit_' | 17:37 |
|
| update-cache.o(.text+0x37b):/home/junz/.local/share/Trash/files/git-0.01/update-cache.c:104: undefined reference to `deflate' | 17:37 |
|
jdl
| Yeah. But before those. The link line. | 17:37 |
|
lkj1
| http://pastebin.com/757999 | 17:38 |
|
jdl
| You are compiling the 0.01 sources again! | 17:43 |
| → ferdy joined | 17:51 |
| → gittus joined | 18:01 |
|
gittus
| njs: re: the index.. You're probably long gone, but maybe you read the logs like I do | 18:01 |
|
| the "index" is the thing that encodes what the current state of the tree is as far as git is concerned. | 18:02 |
|
| Now, quite often you can basically not have an index, and instead just read the HEAD information directly. That is, I think, how monotone works. | 18:03 |
|
| Now, the reason I say you need an index during in-workspace merges is that at that point you obviously don't /have/ a valid HEAD | 18:04 |
|
| So what the index gives you in that situation is a way to encode what all the SCM state is wrt the files that were merged | 18:05 |
|
jdl
| gittus, do you have time for a few questions? | 18:06 |
|
gittus
| Now, you can avoid having an index, but I'll argue that you need _something_ equivalent, so that you can easily do a "diff" etc against either of the parents etc | 18:06 |
|
| jdl, sure. | 18:06 |
|
jdl
| Thanks. RE: git daemon mapping hostnames. | 18:06 |
|
gittus
| Ahh. Don't use my patch as-is. | 18:06 |
|
jdl
| Saw your suggestion. Thanks! (Right.) | 18:06 |
|
gittus
| The reason I say that is that I think it should be done in a way that you can extend it with _other_ environment variables later. | 18:07 |
|
| And yeah, Junio was right that nobody cares about the port number. | 18:07 |
|
jdl
| OK. | 18:07 |
|
| Want named variables as follow ons instead? | 18:07 |
|
gittus
| So, I'd suggest instead just putting a "HOST=%s" there hidden behind the NUL byte. | 18:07 |
|
jdl
| Right. | 18:07 |
|
| Wanting to make sure I get both halfs upload and download too. | 18:08 |
|
gittus
| Then, later on, if we want to expose other things, we just add them as other "variables" after another NUL bute. | 18:08 |
|
jdl
| Yes. | 18:08 |
|
gittus
| Umm. The git:// protocol only does read (download). | 18:08 |
|
jdl
| Right, so where can I find the bits to get the push part too? | 18:09 |
|
gittus
| For uploads, you'll have ssh://, and I think ssh will already set some magi cvariables. | 18:09 |
|
| But I don't actually know ssh/sshd that well. | 18:09 |
|
| Maybe you do end up needing to send things by hand there too. | 18:10 |
|
jdl
| Hmmm.. Who gets to do the path swizzling then? And would that mapping be specified? | 18:10 |
|
| Er, _where_ would... | 18:10 |
|
gittus
| ssh does set _some_ environment variables already, but yeah, host doesn't seem to be one of them. | 18:11 |
|
| See SSH_CONNECTION, for example. | 18:11 |
|
| (actually, just do "ssh some-host printenv | less -S" to see what ssh sets up for a non-interactive thing. | 18:12 |
|
| That SSH_CONNECTION thing ends up having the IP address, but not the /name/ dammit | 18:12 |
|
jdl
| Exactly a problem. | 18:12 |
|
| What is the name of the executable that is run on the remote end for us? Is it git-receive-pack? Would it have to be handed a new argument? | 18:14 |
|
gittus
| It is indeed git-receive-pack | 18:15 |
|
| Right now we don't give it any arguments at all, see connect.c | 18:16 |
|
| It's that "execlp(ssh, ssh_basename, host, command, NULL);* thing | 18:17 |
|
jdl
| OK. | 18:17 |
|
| SO, big question: Does this even seem like a reasonable feature request to you? | 18:17 |
|
gittus
| I think that for reading, in particular, it's reasonable. | 18:18 |
|
| For the ssh/writing side, I dunno. I'm thinking it migth not be worth it. | 18:18 |
|
jdl
| A Push: required an explicit path too. | 18:18 |
|
gittus
| It's not like you couldn't just give the right path. | 18:18 |
|
jdl
| Right -- And you presumably have perms and knowledge to do so. :-) | 18:19 |
|
gittus
| (The reason I think it's more reasonable on the readign side is that you expect anonymous readers to be less well acqainted with the repo. | 18:19 |
|
jdl
| It's the public reading side that is really inconsistent... | 18:19 |
|
gittus
| Right. The writer is much more likely to have the knowledge | 18:19 |
|
| (And if you have ssh access, at worst you just log in and _search_ ;) | 18:20 |
|
jdl
| Heh. | 18:20 |
|
| I"ll continue to hack up the reading side then... | 18:20 |
|
gittus
| k | 18:20 |
|
jdl
| And I'm thinking of a simple mapping, no wild cards, parameter substitutions,etc. | 18:20 |
|
gittus
| It would be nice if it was something really trivial for the site maintainer to set up. | 18:21 |
|
jdl
| What do you mean? | 18:21 |
|
| Example? | 18:21 |
|
gittus
| Well, different sites migth have different policies on how the mapping is done | 18:22 |
|
| Some might not want to do anything at all, and just ignore the HOST=xyzzy info | 18:22 |
|
jdl
| That we get today already... :-) | 18:22 |
|
gittus
| And since this is oftesecurity-conscious, you want to make people feel good about the fact that strange HOST=.. things cannot cause problems | 18:22 |
|
| Yeah, I'm not worried about the _current_ git daemon doing something strange with HOST= | 18:23 |
|
| I'm just saying that if you hack up the git daemon to use it, you need to think of the poor site maintainers that are afraid of running yet another daemon | 18:24 |
|
jdl
| Right. | 18:24 |
|
gittus
| People have gotten burnt so many times with security holes in daemons that it needs to be not just safe, but /obviously/ safe | 18:24 |
|
jdl
| I'm hoping for good peer review there. :-) | 18:25 |
|
gittus
| One of the things I tried to make sure was that you could actually strace a git-deamon invocation, and I think I grepped the output and verified that every single "open)" system call was O_RDONLY | 18:25 |
|
| Or something. | 18:25 |
|
jdl
| Cool. | 18:25 |
|
gittus
| Peer review is good, but it's even better if there are things in there that make it inherently safer. | 18:25 |
|
jdl
| Do you think it would work this way?: | 18:26 |
|
gittus
| In other words, do things in a way that even if there's a bug, and you open strange directories, you can't get leakage etc | 18:26 |
|
jdl
| Rather than a mapping, allow %H substitution into the --base-path value somewhere? | 18:26 |
|
| --base-path=/pub/%H/scm | 18:27 |
|
gittus
| Yes. That sounds sane. Especially since --base-path is something the site maintainer would set explicitly anyway. | 18:27 |
|
jdl
| That seems easier and cleaner to me. | 18:27 |
|
gittus
| One thing to look out for is that you probably want some way to just take the "basename" of the hostname. | 18:27 |
|
jdl
| Strip the TLD? | 18:28 |
|
| Verify RFC hostname chars? | 18:28 |
|
| Limit to RFC hostname lenghts? | 18:28 |
|
gittus
| Yeah. I _think_ that's what people would mostly want. Maybe %H for the full hostname, and %h for just the first one. And yes, verify'for sanity, and do things like refuse to use numeric names. | 18:29 |
|
| Or somerthing. It's better to be strict at first, and then if people complain and have valid usage,say "ok, we'll allow that too". | 18:29 |
| → Beuc joined | 18:29 |
|
jdl
| Right. | 18:29 |
|
| So, at the place where you have you "Cool hidden info" comment, is that done _onec_ per connection, per-download, or per-packet? | 18:30 |
|
Beuc
| Hi. I'd like to grab a specific tab of a git repository (eg tag "v1.3.3" in git.git) and... I could not find out how to do so. Can you help me? :) | 18:31 |
|
jdl
| It's confusingly before an "git-upload-pack"... | 18:31 |
|
gittus
| Once per connection. | 18:31 |
|
jdl
| Sweet. | 18:31 |
|
Beuc
| s/tab/tag/ | 18:31 |
|
jdl
| Try: git checkout <tag> | 18:31 |
|
gittus
| jdl: that won't work. You can only check out branches. | 18:32 |
|
jdl
| Feh. | 18:32 |
|
gittus
| Beuc: "git checkout -b my-new-branch <tag>" will create a branch called "my-new-branch" and set it up to be at version <tag> and check it out | 18:33 |
|
jdl
| Try: git reset --hard <tag> | 18:33 |
|
gittus
| And jes, "git reset --hard" will work, but that will obviously blow away the current branch, which may or may not be what you want to do | 18:33 |
|
jdl
| Or, do as gittus suggests. :-) | 18:33 |
|
Beuc
| I like gittus' one :) | 18:33 |
|
gittus
| Beuc: maybe you didn't actually want to check it out, but were saying that you had not even downloaded it yet. | 18:34 |
|
| If that was the case, you've got a few choices: | 18:34 |
|
| (a) just get the whole repo with "git clone ..." and then do the above "git checkout -b ..." magic to get a particular version as your current branch | 18:34 |
|
_JusSx_
| hey i worked on my project and now instead of committing files i wonna go bask to original branch | 18:35 |
|
| how can i do that? | 18:35 |
|
jdl
| Do you have anything in your working directory that you want still? | 18:35 |
|
gittus
| or (b) if the site that exports the git tree has a "gitweb" version that allows downloading a particular tar-file, you can just get the _contents_ associated with a particular version | 18:35 |
|
_JusSx_
| jdi: no | 18:35 |
|
| jdi: so i would like to remove any modifications i did | 18:36 |
|
jdl
| _JusSx_ do you know the commit you want? Is it just the original "master" branch HEAD? | 18:36 |
|
_JusSx_
| jdi: yeah it's the original brach HEAD | 18:37 |
|
| *branch | 18:37 |
|
gittus
| _JusSx_: usually that's what "git reset --hard" really is about. | 18:37 |
|
jdl
| You could "git reset --hard master" -- it will | 18:37 |
|
| loses. | 18:37 |
|
_JusSx_
| jdl: thanx. i will look man page | 18:38 |
|
Beuc
| gittus: ok, thanks. I used (a) | 18:38 |
|
gittus
| Or "git reset --hard origin", if you've made commits to your master branch, and you literally want to reset it back to before all your hard work that you decided was sucky. | 18:38 |
|
jdl
| gittus -- OK, let me hack for a bit! Thanks! | 18:38 |
|
gittus
| I'm going off-line too. See you | 18:38 |
|
jdl
| later | 18:38 |
| ← gittus left | 18:39 |
| → GeertB joined | 18:42 |
| → GeertB joined | 18:53 |
| → DrNick joined | 19:02 |
| → netstar joined | 19:07 |
|
netstar
| okay I managed to break my remote git repository again | 19:07 |
|
| error: remote 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'. maybe you are not up-to-date and need to pull first? | 19:07 |
|
| how can I resolve this? | 19:08 |
|
| and what did I do to cause it? | 19:08 |
|
| two commits one push? | 19:08 |
|
jdl
| Something else changed the remote end that is not in your commit history for the same branch. | 19:12 |
|
| Perhaps you commited on a local tracking branch too? | 19:12 |
|
netstar
| committed as root? | 19:12 |
|
jdl
| "git show-branch" or gitk might help here. | 19:12 |
|
| Doesn't matter who the committing user is. | 19:13 |
|
netstar
| I recreated the tree locally, I had the same error | 19:13 |
|
| [master] Initial commit | 19:13 |
|
jdl
| Perhaps you reset your local HEAD back, past the remote and lost a commit too? | 19:14 |
|
ShadeHawk
| "do not commit to tracking branch"? | 19:14 |
|
netstar
| possible | 19:14 |
|
| How to fix this? | 19:15 |
|
| Without downloading the remote | 19:15 |
|
| because I have made loads of changes | 19:15 |
|
| :( | 19:15 |
|
jdl
| Find where the remote HEAD is, and find where that commit is in your working tree. | 19:15 |
|
netstar
| jdl I reset my working tree | 19:15 |
|
| i.e. rm .git -r | 19:16 |
|
jdl
| You might need to extract your changes as a patch set, then reset to the same HEAD as your remote has, and then reapply your patch set. | 19:16 |
|
netstar
| can't I just say accept this or else? | 19:16 |
|
jdl
| Is the remote's HEAD in your tree somewhere? | 19:16 |
|
| Uh oh. Food just arrived here...! | 19:17 |
|
netstar
| Just copy the remote's HEAD to my local new HEAD and commit? | 19:17 |
|
ShadeHawk
| Hmmm... aliases just appeared on git mailing list... waiting for "defaults" working ~/.gitrc... | 19:31 |
|
fonseca
| Yes, "never case sensitive" must mean case insensitive, but he uses strcmp(), no? | 19:37 |
|
| .. or maybe I missed something. | 19:38 |
|
DrNick
| can I have multiple URL: entries in a remotes file? | 19:39 |
| → chris2 joined | 19:48 |
|
fonseca
| Looking at the code, I would say yes it is possible. | 19:49 |
|
| Up to 16. | 19:50 |
|
emrys
| on the question of rolling back a working copy to the HEAD, is there value to git reset --hard vs. git checkout -f ? | 19:53 |
|
ShadeHawk
| 'git reset --hard' *will* blow away your changes to working dir. | 20:00 |
| → Tv joined | 20:00 |
|
ShadeHawk
| "case insensitive" because keys are case insensitive (although perhaps not aliases) | 20:01 |
|
| are meant | 20:01 |
|
emrys
| doesn't checkout -f also blow away changes? | 20:24 |
| → Oeje1 joined | 20:27 |
|
ShadeHawk
| Hmmm... does git reset update HEAD? | 20:37 |
|
| besides, git checkout -f isn't force write, but "Force a re-read of everything". | 20:38 |
|
emrys
| I've run them both and them seem to end up leaving the working copy in the same state, I'm pretty sure it does forced overwriting. | 20:41 |
|
loops
| emrys, you're right. and git checkout -f has the added benefit of letting you checkout a different branch if you want | 20:41 |
|
emrys
| s/them seem/they seem/ | 20:41 |
|
loops
| if you're on branch "test", git reset --hard master , and git checkout -f master do very different things. | 20:46 |
|
ShadeHawk
| let me repeat: does 'git reset --hard' update head when switching branches? | 20:46 |
|
loops
| git reset --hard doesn't switch branches | 20:47 |
|
| git reset --hard <branch> .. resets the HEAD of the __current__ branch to be equal to the head of the branch given on the command line | 20:48 |
|
ShadeHawk
| so, to summarize, they are similar but of different use. checkout -f to switch branches, throwing away lical changes, and reset --hard to rewind mainly. | 20:56 |
|
| *local | 20:56 |
| → robfitz joined | 20:56 |
|
DrNick
| that's what -f does? | 20:58 |
|
loops
| yes, but they do have similar effects on uncommitted changes in the working tree. | 20:58 |
|
DrNick
| somebody needs to fix the docs, "Force a re-read of everything." is unintelligible | 20:59 |
|
loops
| DrNick, yeah | 20:59 |
|
emrys
| The main reason I asked is that our "git for dummies" for the people that just will work in our master branch all the time and do little one liner code changes, I tell them to use 'checkout -f' if they screwed up and haven't committed yet. Sounds like that's still good advice. I don't want to give them reset --hard because it looks scarier/more unfamiliar than checkout -f. | 21:00 |
|
loops
| yes.. checkout is restricted to branches.. whereas reset can go to any branch/tag/arbitrary sha1.. so it's a little more dangerous | 21:01 |
|
emrys
| ( http://wiki.sourcemage.org/Git_Guide if any of the usage case people care to see what ends up in such a doc) | 21:03 |
|
ShadeHawk
| in GitLinks, emrys. | 21:15 |
|
| BTW. is SourceMage managed in Git, or not yet? | 21:16 |
|
| (to add to GitProjects)? | 21:16 |
|
emrys
| final decision hasn't been made yet | 21:18 |
|
njs
| gittus: to continue our uniquely inefficient conversation: monotone constructs its idea of the current workspace state by combining some stored information (e.g., list of added files) with the current state of the actual files in the workspace, modulo some restriction (e.g., if the user says "commit foo", we don't look at the current state of bar). | 21:18 |
|
emrys
| currently our ports tree is split up by groups into git, svk, and hg-managed repos, the package manager is evaluating git (after trying bzr) and the installer/iso is about to move into evaluating git (also from bzr) | 21:19 |
|
njs
| gittus: I'm not really understanding what the index does that's different from this, except for making the update-from-workspace step happen at explicit times rather than implicitly. And in particular, I still don't see what the problem with merges is. | 21:19 |
|
pasky
| isn't index just the "some stored information" part? | 21:21 |
|
njs
| ShadeHawk: btw, looking through my logs for info on what exactly an "index" has, I came across your comment about http://www.venge.net/monotone/wiki/BranchAnalogy :-) The reason they are called branches is that they enable exactly the classic branch workflow; if you have any more specific questions I'd be happy to chat about them... :-) | 21:22 |
|
| pasky: maybe! I still haven't found anything that says what exactly an index has, except maybe that it's just a tree object. | 21:22 |
|
| (or, umm, whatever you guys call those... dir object? something.) | 21:22 |
|
pasky
| njs: index is a list of (file, sha1, statinfo, mergestate, flags) n-tuples | 21:23 |
|
njs
| what are mergeinfo and flags? | 21:24 |
|
pasky
| flags are something misc and AFAIK uninteresting | 21:25 |
|
| mergestate should read "merge stage" | 21:25 |
|
ShadeHawk
| more like "manifest"-like file (of BitKeeper) than hierarchical structure of tree object | 21:25 |
|
| (although that *might* change from some rare comments) | 21:26 |
|
pasky
| that's what is used during merges - basically, when you do a merge between three trees, it is primarily done at the index level | 21:26 |
|
ShadeHawk
| 3-way merge = 3 stages? | 21:27 |
|
pasky
| oversimplified, it goes like: so for a three-way merge you take three trees, you construct three indexes from them, with stages 1, 2, 3 | 21:27 |
|
| then you throw them into a single index, and if for some fields the entries are equal for all the stages, you collapse them to a single stage 0 entry | 21:28 |
|
njs
| ShadeHawk: *shrug* manifest vs. hierarchical is just a matter of what access patterns are efficient, doesn't change what info is there. | 21:28 |
|
pasky
| (stage 0 is the default one which is used normally when you are not doing a merge) | 21:28 |
|
njs
| pasky: ah, so there may be more than one tuple with the same file slot, but at most one tuple with a given (file, merge state) 2-tuple? | 21:28 |
|
pasky
| if after this you have some non-stage 0 entries, you have conflicts you need to resolve - some conflicts will be further resolved automatically and some will be left for the user to resolve | 21:28 |
|
| njs: yes | 21:28 |
|
njs
| okay, interesting, hmm. | 21:31 |
|
ShadeHawk
| and how rename/copy detection of git (-M -C) during merges gets into index merge stages? | 21:31 |
|
pasky
| the original purpose of the index file was to just make things fast - when you do e.g. git-diff, it compares statinfo of files with the index and if the statinfo equals, it doesn't even bother looking inside | 21:32 |
|
ShadeHawk
| btw. index is just index, actual objects are (usually) in the repository, as far as I can tell. | 21:32 |
|
pasky
| njs: I wonder if Monotone also does this optimization? | 21:32 |
|
ShadeHawk
| still as the place to _prepare commit_ is quite a nice idea. | 21:32 |
|
| index that is. | 21:33 |
|
njs
| this sounds basically isomorphic to what we do, except that we haven't gotten around to adding merge-state tracking, and are planning to do it in a somewhat different (and still not fully fleshed out) way. | 21:33 |
|
| I think I still don't understand why gittus puts so much emphasis on the index; in the particular example of needing to handle conflicts when merging, yeah, you need to write down conflict state... but this is sort of obvious and you could do that with the index or not, whatever :-) | 21:35 |
| ← netstar left | 21:35 |
|
pasky
| ShadeHawk: the -M -C stuff is probably done long before the stuff hits index, but I have no idea about the details... recursive merge is still too pythonish for me ;) | 21:35 |
|
njs
| while he seemed to be saying that there was something veyr special about it, that one couldn't handle in-workspace merging without it... which seems like a stronger statement than "part of implementing workspace-merge is implementing workspace-merge-status-tracking". *shrug* :-) | 21:36 |
|
pasky
| njs: *shrug* :-) | 21:36 |
|
njs
| pasky: the stat optimization, yeah, if the user asks for it (disabled by default because it's slightly risky, and in practice irrelevant for most projects, which are small) | 21:37 |
|
pasky
| njs: I think it's kind of neat solution, though, combining the merge status information with the stat cache | 21:37 |
|
ShadeHawk
| iirc also such pesky thinkgs like deleted, added and such... | 21:43 |
|
| gittus is... opinionated... (is it right word?) | 21:44 |
|
loops
| pasky, git WHATEVER | less won't work ? | 21:48 |
|
| that seems broken.. why was that a requested feature ? | 21:49 |
|
pasky
| hmm | 21:50 |
|
| loops: well if some script does git log and you make --somethingweird log default argument, you have a problem | 21:51 |
|
| so, rather stdin? | 21:51 |
|
loops
| ahh i see.. | 21:51 |
|
pasky
| I copied that from cogito but cogito throws stuff into a pager automagically | 21:51 |
|
loops
| stdin might be better.. can't think of a bad case going that route | 21:53 |
|
pasky
| cat "i'm a weirdo and feed commit msg on stdin" | git commit | 21:56 |
|
| but that's not worth optimizing for | 21:56 |
|
loops
| pasky, what about providing a --no-alias option to git for scripts to use ? | 21:56 |
|
pasky
| that way lies madness | 21:56 |
|
loops
| yeah.. you'd have to use it on every command | 21:57 |
|
pasky
| you could also use an environment variable, but I don't like that much either.. it should DTRT in all common cases | 22:01 |
|
loops
| if you allowed the alias to operate no matter what, unless it was actually overriding a git command.... | 22:02 |
|
Beuc
| Hi again. Do any of you have a git repository/account on kernel.org? I'm experimenting with git and checking whether I could offer it at Savannah - I'd like to know if kernel.org provides full shell or git-shell access, for example :) | 22:04 |
|
pasky
| kernel.org provides full shell | 22:04 |
|
| but git-shell should work just fine for Savannah, I guess | 22:05 |
|
Beuc
| I'm wondering if that would be practical | 22:05 |
|
| for example: maybe people will need to add several git repositories in a project | 22:06 |
|
| or they will require a repository not initialized by the system, so that it share ancestry with another external repository | 22:06 |
|
| all this I think would require more than git-shell access | 22:07 |
|
pasky
| it might be enough to just let them manipulate with the directories manually over ftp or something (exclude the hooks/ directory) | 22:10 |
|
| but it would be more prudent to discuss this rather on the mailing list, if I may advise :) | 22:10 |
|
Beuc
| I guess :) | 22:13 |
|
| Another question: at kernel.org, how do you trust users not to accidentally/willingly mess with each other's repository? Do you rely on good will only? On unix group membership? :) | 22:17 |
|
pasky
| Beuc: there are actually no shared repositories, I think | 22:18 |
|
| Beuc: but for other projects people frequently rely on unix group membership | 22:18 |
|
Beuc
| mono-user repositories are popular among distributed scm | 22:19 |
|
emrys
| We've evaluating git for a while now for a mostly-shared setup, the central server uses git-shell and it works well. But our users don't really have to do repo management on that server. The few that do have regular logins. | 22:20 |
|
pasky
| Beuc: but multi-user repositories are plentiful as well... depends on your project's workflow and kernel workflow is very individualistic :) | 22:20 |
|
Beuc
| ok :) It's too bad we can't provide shell access when doing mass-hosting :/ | 22:21 |
|
pasky
| git-shell might even get extended to allow some more operations | 22:25 |
|
Beuc
| Or Savane could provide a way to spawn new empty repositories | 22:27 |
|
| (I just found out how to import local revisions in such repositories, yay) | 22:28 |
|
| Do you think people would need several repositories for a single project, or would it be enough to provide only one? | 22:29 |
|
| For example, with CVS one repository is enough. For GNU Arch it is not, because you need additional repositories to eg. mirror the archive you're based on | 22:30 |
|
| With git, maybe people would need multiple repositories so as to avoid ending with one huge repositories, instead of several ligher and independant one. I dunno.. | 22:31 |
|
ShadeHawk
| I don't think so. One repository per project, with git branches should be enough... | 22:31 |
|
| ...usually... | 22:31 |
|
emrys
| No, with git you probably just want a single repo per project, it has many benefits based on local branches. | 22:31 |
|
| (which are inside the one repo) | 22:31 |
|
pasky
| ShadeHawk: git clone's habit of cloning all branches by default makes you think twice | 22:32 |
|
ShadeHawk
| as one can se from git.git TODO branch you can use branch for what could be/should be another repository... | 22:32 |
|
pasky
| yes, but it increases useless traffic | 22:32 |
|
ShadeHawk
| still, TODO is essentially separate project... | 22:32 |
|
pasky
| probably only few project X users also want to fetch project X's website data etc. | 22:32 |
|
| (if you throw some screenshots etc. in, that can be non-trivial amount of data) | 22:33 |
|
ShadeHawk
| Well, Savane used IIRC two CVS repositories (or two modules): one for project, one for project pages. | 22:34 |
|
| web pages. | 22:34 |
|
pasky
| aha... in that case, it's hard to say :) I still quite dislike keeping unrelated stuff in branches of the same repo, personally | 22:34 |
|
| but as you can see, many people tend to differ | 22:35 |
|
Beuc
| 2 repositories is manageable by the system. Arbitrary new repositories created by users is different :) | 22:35 |
|
| Are there ancestry restrictions? For example may I import 2 unrelated repositories in a same third? | 22:36 |
|
pasky
| yes you can | 22:36 |
|
ShadeHawk
| gitweb.git was added to git.git if I'm not mistaken. | 22:49 |
|
Beuc
| I think git-shell might need to issue repack/prune as well - quite a disk-space-saver :) | 22:57 |
|
ShadeHawk
| ah, repack and prune-packed is safe now, prune isn't from what I can tell... | 23:04 |
|
Beuc
| Maybe that can be done in hooks, but we'll have to see what kind of storage mode is more efficient | 23:05 |
|
| what do you mean by "unsafe"? :) | 23:06 |
| → z3ro_ joined | 23:07 |
|
ShadeHawk
| race condition unsafe (e.g. creating commit while pruning). correct me if I'm wrong. | 23:12 |
| → GeertB joined | 23:28 |
| → Tv joined | 23:36 |
| → gittus joined | 23:44 |
|
gittus
| njs: back to our strange disjoint index discussion | 23:44 |
|
njs
| gittus: uh-oh, I'm still here... give me a sec to go do something else! | 23:44 |
|
gittus
| First off: the index isn't just a "performance optimization". At some point, lack of performance is lack of usability | 23:44 |
|
njs
| hmm, did I call it a performance optimization? | 23:44 |
|
gittus
| Somebody talked about the index as not being hugely fundamental, "just" a performance thing. Maybe pasky? | 23:45 |
|
| So for example, the index is what makes this possible: | 23:45 |
|
njs
| definitely, for large trees, you have to do some sort of stat caching, I don't think we have any disagreement on that. | 23:46 |
|
gittus
| "time git diff" in the kernel: real 0m0.071s | 23:46 |
|
| So in many ways, the index is very central just because performance is so central. | 23:46 |
|
| But when it comes to merges, it does something else too. | 23:47 |
|
| As you already found, it allows the sane name to be associated with multiple "states" | 23:47 |
|
| It's not just "this file is unmerged" either. | 23:47 |
|
| It's also "this file is unmerged, and it has <this> base version, and <that> is branch1, and <that other thing> is branch2 state | 23:48 |
|
njs
| (fwiw, monotone has had stat caching support since about 6 days after you emailed us and let us know that maybe it was time for our little research system to start growing up :-)) | 23:48 |
|
| right | 23:48 |
|
gittus
| So now, when you have a merge conflict, the workspace will contain some random partial result (which may be the normal 3-way merge result with <<<</>>>> markers, but it might be a partially fixed-up state too | 23:48 |
|
njs
| we've been planning to just stick that information in a file. | 23:49 |
|
| (ours is more complex anyway, because we have rename tracking) | 23:49 |
|
gittus
| And now having multiple entries in the index actually allows us to do "git diff --ours" or "git diff --theirs" | 23:49 |
|
| So you can literally say "what is the difference between my current half-fixed-up state to the original branch state" | 23:50 |
|
| Which is _really_ convenient when you're trying to do the resolve | 23:51 |
|
| It's _especially_ important that this works when you've already removed the 3-way markers, because when that "git diff" is most important is when you have done the manual fixup, and want to verify the end result | 23:52 |
|
| And again, since "git diff" will ignore things that are equal in the index, it also means that while doing this merge, "git diff" won't even _show_ any diffs that have already been resolved | 23:53 |
|
| Which is really really useful. Doing merge resolution with git has been _so_ much easier (not that I get a lot, but when I get them, the fact that I just do "git diff" and it shows just the conflicts, is a big deal) | 23:53 |
|
| So while the index has no "semantic" meaning normally (well, "git add" etc work in it, but it's not a huge deal), during merges, the index goes from "performance enhancer" to "life enhancer" | 23:54 |
|
njs
| so the point is that "git diff" with no arguments gives something like "diff between my current state, and the virtual state one get from doing a simple not-very-smart merge of the same parents"? | 23:54 |
|
gittus
| It means that you can keep things in a "the mereg has not been completed" state, and you can actually walk away, and come back the next day. | 23:55 |
|
| And when you come back, you don't have to remember what was going on. It's all there. | 23:55 |
|
| Now, clearly, you could do it some other way. But doing it in the index means that it's actually not even a special case to keep track of merge information. The merge | 23:55 |
|
| information is all in the place that we need to look at _anyway_ for the normal non-merge operation. | 23:56 |
|
| Ie the above "git diff --ours" is not actually a special merge case. It's what falls out of "git diff" naturally, since "git diff" is using the index anyway. | 23:56 |
|
| (And the difference between "--ours" and "--theirs" is literally just hat when you have multiple entries for one file, which one do you use to diff against?) | 23:57 |
|
| (There's also "--base", which shows the diff against the merge base, but it's less commonly used: I've used it, but it's been for sanity-checking only) | 23:58 |
|
| And no, "git diff" without any arguments always actually does the same thing: it diffs the index with the current working tree. Nothing else. | 23:59 |
|
| Even when you're not merging, that's what it does. For example, what I do at times (and I know others do too) is that they update the index by hand (so that it no longer matches HEAD). | 23:59 |