IRCloggy #git 2008-05-04

Provider of IRC logs since 2005.

WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

	2008-05-04
	→ cousin_it joined	00:01
	← dadark left	00:02
	→ eternaleye joined	00:04
	← ehamberg left	00:07
	← charon left	00:07
	← maier left	00:08
	← nud left	00:10
	→ clsdaniel joined	00:13
	← tcoppi left	00:15
	→ ehamberg joined	00:15
	← ehamberg left	00:16
	→ ehamberg joined	00:17
	→ tcoppi joined	00:18
	← peeja left	00:18
	← brosner left	00:19
	→ maier joined	00:22
	← maier left	00:29
	→ peeja joined	00:33
	← cousin_it left	00:34
	← a-priori left	00:35
	← peeja left	00:35
	→ peeja joined	00:37
	→ a-priori joined	00:37
	← Jerdent left	00:43
	→ bradleyjames joined	00:48
	← cliffstah left	00:54
	← kipras left	00:54
bradleyjames	is there a way to configure a git repository to say that the initial branch should be named something other than 'master'?	00:54
	→ kipras joined	00:54
vmiklos	just edit .git/HEAD before the first commit	00:56
	← a-priori left	00:56
bradleyjames	k, i'll try that. thanks.	00:57
	← peeja left	00:57
	→ a-priori_ joined	01:01
	← a-priori_ left	01:14
	← ebel left	01:14
	← kanru left	01:14
	→ ctennis joined	01:14
ctennis	join #cisco	01:14
	← markkalderon left	01:21
	← kipras left	01:23
paulproteus	I accidentally made some changes on top of the latest version of some git code, but I really would rather have made changes on top of a different branch that's a few weeks behind the current master.	01:24
	git-rebase seems to only want to forward-port changes, not backport them.	01:24
	Is there a way to use it to backport changes instead?	01:25
	Or to otherwise backport changes instead of forward-porting them?	01:26
RandalSchwartz	cherry pick it	01:26
	how many commits are you talking about	01:27
paulproteus	Guess I'll read up on cherry picking.	01:27
RandalSchwartz	git checkout old other branch	01:27
	wait let me try that again	01:27
	git checkout oldbranch	01:27
	git cherry-pick otherbranch	01:28
	that'll pick the top commit from otherbranch and apply it to your current branch	01:28
	if you have more than one, apply them oldest to newest:	01:29
	git cherry-pick otherbranch~2	01:29
	git cherry-pick otherbranch~1	01:29
	git cherry-pick otherbranch	01:29
	although - rebase shoudl actually let you do that	01:30
paulproteus	I'm using a git-svn mirror, so it's possible there's fruity things going on with branch history here.	01:30
RandalSchwartz	git rebase otherbrnach~2 otherbranch --onto oldbranch	01:30
	RandalSchwartz averts his eyes upon seeing the deadly "git-svn"	01:30
	RandalSchwartz runs away screaming	01:30
	← pygi left	01:34
paulproteus	RandalSchwartz, Thanks, now I see how git-cherry-pick works. (-:	01:35
RandalSchwartz	cool	01:37
	→ a-priori joined	01:39
	← a-priori left	01:43
	← schacon_ left	01:45
	← strangy left	01:48
	← bradleyjames left	01:50
	→ jacqui joined	01:52
	→ destruct1 joined	01:52
	← jacqui left	01:53
	← [tla] left	01:53
	→ jacqui joined	01:53
	→ dysinger joined	01:57
	→ schacon joined	01:58
	← KiWiB0RG left	02:00
	← destruct left	02:03
	→ elkmoose joined	02:13
	→ brazilian joined	02:23
	→ johnw joined	02:27
	→ samgranieri joined	02:30
	← jacqui left	02:31
	← schacon left	02:33
	→ harinath joined	02:36
	← samgranieri left	02:38
	← BabelO left	02:39
	→ leachim6 joined	02:42
	← elkmoose left	02:42
leachim6	Where can I get the ruby bindings for git ?	02:42
	→ nkallen joined	02:43
Eridius	leachim6: http://github.com/mojombo/grit/tree/master	02:43
leachim6	lovely...	02:44
	thank you	02:44
	← johnw left	02:44
	→ johnw joined	02:44
	← johnw left	02:44
leachim6	wow ... how any trees does mojombo have on github ... well I guess he's allowed to have as many as he wants :)	02:44
	→ johnw joined	02:44
leachim6	how do I set my name and email ... I forget ... git-config what	02:46
	← brazilian left	02:47
	← Ramune left	02:47
loops	git config --global user.email "you@where.com" ; git config --global user.name "Your Name"	02:47
	← jbunster left	02:48
	→ jbunster joined	02:48
leachim6	thanks	02:49
	← warthog9 left	02:53
	→ Ramune joined	02:53
	→ csc` joined	03:13
	← csc` left	03:17
	→ csc` joined	03:17
	→ warthog9 joined	03:18
	→ ironfroggy joined	03:19
	← ggeecko_ left	03:20
	→ ggeecko_ joined	03:20
	← ggeecko left	03:20
	← ironfroggy left	03:20
	→ ggeecko joined	03:20
	→ agib joined	03:22
	→ a-priori joined	03:23
	← kukks left	03:31
	← a-priori left	03:45
	← Ademan_ left	03:52
	→ Ademan_ joined	03:53
	→ ironfroggy joined	03:54
	→ tjafk2 joined	04:14
	→ WALoeIII joined	04:18
	← madewokherd left	04:20
	← WALoeIII left	04:23
	← johnw left	04:24
	← tjafk1 left	04:30
	← PerlJam left	04:34
	→ brazilian joined	04:51
	← dysinger left	04:58
	→ Jerdent joined	05:04
	→ ajonat joined	05:09
	← Jerdent left	05:13
	→ angasule_ joined	05:14
	→ WALoeIII joined	05:24
	→ wagle_home joined	05:24
	← angasule left	05:31
	→ pygi joined	05:41
	← Sho_ left	05:51
	← ajonat left	05:53
	→ ajonat joined	05:53
	← bobesponja left	06:05
	→ xjunior joined	06:05
xjunior	I''m starting to use git now, and I made my first commit (commit; push). but I had a problem: the new files were sent to the remote server, but the files that I modified weren't sent to central repository.... what did I do wrong?	06:06
	← zdennis left	06:06
	→ zdennis joined	06:06
Pieter	what is a central repository?	06:07
xjunior	Pieter: hum... ahh... I think I said something wrong... well... I'm using github	06:08
	Pieter: oh, I think that I know where I missed....	06:12
	I need to "add" every file I'll commit	06:12
WildPikachu	yey	06:18
	my repo is imported!	06:18
	9hrs :(	06:18
	← WALoeIII left	06:18
Eridius	xjunior: you can also use `git add -u` to add all modified files (but not new files)	06:21
	and `git add .` to add everything in the current directory	06:21
	→ morphir joined	06:21
xjunior	Eridius: current recursively?	06:22
	→ brosner joined	06:24
Eridius	xjunior: of course	06:24
xjunior	Eridius: hum.. good :D thanks!	06:24
	bye!	06:24
Eridius	bye	06:24
	→ ph^ joined	06:29
	← xjunior left	06:30
	← ph^ left	06:44
	← ajonat left	06:45
	→ ajonat joined	06:45
	← ajonat left	06:45
	→ ajonat joined	06:47
	→ ph^ joined	06:48
	← ajonat left	06:48
	→ janm joined	06:50
	→ ajonat joined	06:54
	← ph^ left	07:01
	→ aLone joined	07:02
	→ ph^ joined	07:03
	→ johnw joined	07:07
	→ Jerdent joined	07:09
	← Jerdent left	07:11
	← statim left	07:14
	← unreal left	07:14
	→ unreal joined	07:15
	← dsaxena left	07:20
	→ deavid joined	07:26
	→ kmag joined	07:27
kmag	Ilari: it turns out that the problem was Fink's ancient version of git.	07:28
	Thanks for your help everyone.	07:28
	← kmag left	07:30
	→ Sho_ joined	07:32
	→ rofrol joined	07:33
	← rofrol left	07:33
	← csc` left	07:47
dadark_	Hey folks	07:49
	← kmap left	07:49
dadark_	How would you move out stuff from an existing repo into a submodule?	07:49
	Is that even possible without losing all commit information etc?	07:49
	→ devogon joined	07:50
	← ironfroggy left	07:55
	← ph^ left	07:55
	→ ph^ joined	07:58
	← sverrej left	08:00
	→ statim joined	08:01
Ilari	dadark_: Use split/filter-branch (split is not standard) to get the history, remove from newest version and put submodule in its place?	08:01
	→ charon joined	08:01
WildPikachu	ok ... now, time to port our scripts to git	08:02
	Ilari, my import worked :)	08:02
dadark_	Sorry, I'm quite new to git, Ilari ;)	08:02
	← warthog9 left	08:03
dadark_	Ilari: Would you mind, only if you have some secs, explaining me how that filter-branch works? I have the docs, but I don't understand that much, yet	08:05
Ilari	WildPikachu: It tends to be that for any git subcommand, it is either scripting-grade, or it was once/is still some sort of script (usually shell or perl)...	08:05
WildPikachu	i love perl :)	08:05
	easiest to do what i want to in this case	08:05
	just need to get 3 functions ported to git and i should be back on track	08:06
	→ sverrej joined	08:07
	← sverrej left	08:07
Ilari	dadark_: Basically, make a clone of the repository, then create new branches on clone that only contain the submodule (--subdirectory-filter).	08:07
	← Zycon_ left	08:07
dadark_	Ah, cool	08:07
	Will check that out, thanks	08:07
	→ sverrej joined	08:10
	← brazilian left	08:13
	→ kumbayo joined	08:17
	→ cliffstah joined	08:17
	→ thiago_home joined	08:24
	→ ph^_ joined	08:26
	→ warthog9 joined	08:31
Pieter	what is a central repository?	08:33
	oh	08:33
	scrap that	08:33
	→ rraasch joined	08:36
	← ph^ left	08:41
	← johnw left	08:52
	← ajonat left	08:53
	← igorgue left	08:56
	← ph^_ left	09:09
	→ ph^ joined	09:12
	→ kmap joined	09:17
	← nkallen left	09:17
	→ vbgunz joined	09:25
	← rraasch left	09:26
	← fhobia left	09:28
	→ kipras joined	09:39
	→ ajonat joined	09:44
	→ stillLotR joined	09:50
	← ph^ left	09:52
	→ ph^ joined	09:54
	→ ShKodRanI joined	09:56
	→ prl789 joined	10:01
	→ ph^_ joined	10:03
	← ph^_ left	10:03
	→ Eludias joined	10:04
	→ ph^_ joined	10:04
	← LotR left	10:07
	← ph^ left	10:19
dadark_	I love git! ;)	10:22
	I really does everything right that I hated svn for	10:22
cliffstah	lol, welcome to the revolution =P	10:24
dadark_	Hah	10:26
prl789	I'm converting some svn repos to git... have a Q about branches. I do git-svn init file:///Users/phil/devel/gitted/ezor/ --no-metadata -T trunk -b branches -t tags from inside my new git dir, but all the branches are visible only with git branch -a because they are "remote". And after I git clone that new git dir to "remove svn cruft" the branches seem to be entirely gone. How can I migrate an svn repo including all its branches?	10:32
	← Fullmoon left	10:33
Ramune	prl789: check those branches out via "git checkout -b localname remotebranch"	10:33
prl789	Ramune: ok, thank you	10:33
Ilari	prl789: 'git branch foo foo' for each of them would probably be faster.	10:34
loops	prl789, when you clone Git copies all of the branches and sets them up as remote tracking branches (rather than local branches), git branch -r should list them all for ya	10:34
Ilari	Since new branch creation means creating and writing two small files, where checkout with branch create updates/creates four + all working tree files to modify.	10:36
	→ alb joined	10:37
prl789	all: so that means I first need to 'git branch foo foo' or "git checkout -b localname remotebranch" from within the first git repo I make from svn, and then also do the same thing again to re-local the branches from the 2nd git repo I clone from the 1st (the 2nd repo clone is to "remove svn cruft). Correct?	10:39
	→ thijso joined	10:39
	→ Vanduror joined	10:40
Ilari	prl789: Or maybe make bare repo and push all the stuff there?	10:40
loops	prl789, it sounds like you are happy with the results of your initial repo, where you have imported from svn. There's probably nothing to do there	10:42
	← reaVer left	10:42
	← johan-s left	10:42
	→ chris2 joined	10:42
loops	prl789, the issue with your branches not showing up when you clone that repo, is a standard Git feature	10:42
	prl789, when you clone with Git, it will appear to only clone one branch, unless you do "git branch -r" to see that in fact all your branches were cloned, and put under the origin/* namespace rather than being setup as local branches	10:43
prl789	loops: right, I was just reading about that at: http://lwn.net/Articles/222086/. but since this is to be the canonical repo (er, the only repo) I thought it should have all branches local	10:43
	→ _graham_ joined	10:44
loops	prl789, well you can do that.. by following Ilari or Ramune's advice on creating a local branch for each remote.. (you might also look at the --mirror option to clone instead)	10:45
Ilari	prl789: 'canonical repo' probably should not have working tree, as repos with working trees should not be fetched from or pushed to unless one is aware of the pitfalls involved.	10:45
	→ trochala joined	10:45
loops	prl789, hmm.. maybe clone doesn't have --mirror after all, you may have to resort to "git init; git remote add" .. to get mirror feature.. odd	10:47
dadark_	Hum, what happens when I change stuff in a submodule in the parent repo? Can I commit it just like it was the working directory?	10:47
	Hope you get that, dunno how to explain	10:47
prl789	Ilari: sounds like I've got more googling to do.	10:47
	all: thanks for the info, I'll keep this window open and go play some more.	10:48
Ilari	prl789: Nah. Just make the canonical repo to be without working tree.	10:48
loops	Ilari, to be fair to prl789 that's kinda a separate issue from what he was originally asking about, ie. trying to understand where his branches were going etc..	10:49
Ilari	prl789: 'git --bare init' (note: NOT, 'git init --bare' or 'git-init --bare'). And if init-db is mentioned in some tutorial, that tutorial is virtually certainly obsolete.	10:50
	prl789: (well, aside of mentioning that it is obsolete and one should use init instead).	10:50
loops	dadark_, nothing happens in the parent until you manually commit the changes.	10:50
dadark_	Okay, see.. Can I commit changes to a submodule from the repo where is is included at all?	10:51
loops	dadark_, no, you need to make the commit in the submodule first, then you can commit the parent repo.	10:52
dadark_	Okay, but it's kept there as a separate repository, that was what I wanted to know	10:54
	Cool	10:54
	Loving git more and more	10:54
	← albertito left	10:54
prl789	Ilari: actually I was kind of excited about having a working tree in the same place as my repo, unlike svn where I had the repo in one place and then my working copy elsewhere. Since I'm the only dev on the projects I'm playing with this morning it seemed cleaner. But you say there are "pitfalls" involved. Would those pitfalls be associated with publishing/sharing the repo? If that's the case I wouldn;t need to worry about it unti	10:54
Ilari	prl789: Message cuts off: "that's the case I wouldn;t need to worry about it unti"...	10:55
	← aLone left	10:55
prl789	"If that's the case I wouldn;t need to worry about it until/if these reached a point where I put them out on a git server womewhere, in which case I would then of course have my working tree seperate."	10:55
Ilari	prl789: In pushing to that repo, there's push-to-HEAD problem. In fetching, problem is lack of buffer to fix mistakes.	10:56
	prl789: Well, you could create the second repo with working tree as follows: 'git init', 'git fetch ../old-repo refs/heads/:refs/heads/', 'git checkout master'...	10:57
	prl789: That checkout might additionally need '-f'...	10:58
loops	prl789, As a single developer with a single repo on a single machine, there's really no reason to worry about it. It's only when you start pushing and pulling between machines where it's better to use a bare intermediary	10:58
Ilari	prl789: Also, have you checked that the committer/author information recorded is reasonable?	11:00
	prl789: And if you have used 'svn merge' in the SVN repo, merges could need fixing...	11:00
prl789	oh, i just realized I had better worry about it, becasue i'm planning to cross-platform test the projs across various VMs on my box. So I will need a bare intermediary after all.	11:01
Ilari	prl789: 'mkdir path/to/repo.git', 'cd path/to/repo.git', 'git --bare init', 'cd path/to/svn/import', 'git remote origin path/to/repo.git', 'git push origin --all' maybe...	11:03
	Oops. 'git remote add origin path/to/repo.git'.	11:03
	→ ebel joined	11:03
prl789	Ilari: actually, the committer/author information is problematic, I was going to ignore the difficulty, but... I succesfully migrated a very large (by my standards) project we have at work , multiple devs, etc, by using the `git config svn.authorsfile ../ubp_users.txt` command. but that same method faied to work for these little ones only I dev on. Kept saying prlfoo is not in the file.	11:04
	← cliffstah left	11:05
Ilari	prl789: filter-branch can be used to create new history with different committer/author info. It's not even difficult if there is just one committer/author.	11:05
prl789	Ilari: well, there were three of me ;-) but I'll give it a try.	11:06
Ilari	prl789: It only gets sightly more complicated when one has to look at the old value to decide what new value to use...	11:07
	ruphy → klogger	11:09
Ilari	prl789: Something like "--env-filter 'unset GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL'" (assuming user.name and user.email are set).	11:09
	klogger → ruphy	11:10
prl789	all: thanks for the friendly IRC. real life intrudes, cya.	11:11
	← prl789 left	11:11
comp	greetings, anyone tested git performance with 100 or more branches?	11:18
	as I've seen, branches (their SHA-1s) are stored line by line in a single file	11:20
	so I suppose it could be possible to have 100 branches without major problems	11:21
Tv	comp: I'd even ask, why do you expect to see trouble	11:22
comp	I don't know, just because "typical" work with git expect about 10-20 branches ..	11:22
Mikachu	usually there are more tags than branches	11:23
	and i don't think there's any code in git that expects any specific number of branches	11:23
	→ reaVer joined	11:23
comp	well ... I'll try it	11:24
	← kipras left	11:24
	→ kipras joined	11:25
Pieter	comp: make sure you git-gc after creating the branches though	11:26
chris2	are there code review tools that can make use of git other than review-board?	11:26
comp	I know	11:26
	Pieter: so duplicated data get compressed	11:26
Pieter	comp: a lot of things slow down in my repo with 5000 branches without packed refs	11:27
Tv	pfft 100 files isn't that much, don't really need packed-refs for that	11:27
comp	naah, I suppose about 300 max	11:27
	but thanks for the info	11:27
Mikachu	where are you getting these numbers from?	11:28
chris2	i think there was a discussion on adding arbitrary metadata to git objects, what happened to it?	11:35
Pieter	some people are still against it	11:35
	so it's dropped	11:35
chris2	okay :/	11:36
	→ Yuuhi joined	11:42
	→ strangy joined	11:43
	→ cncfanatics joined	11:44
cncfanatics	hello, could anyone explain to me how to remove a branch on a remote ?	11:44
vmiklos	git push origin :refs/heads/foo?	11:44
	← ShKodRanI left	11:45
cncfanatics	nvm, found it, git branch -r -d origin/BranchName	11:45
	thanks nayway vmiklos :)	11:45
	← strangy left	11:48
	← FunkeeMonk left	11:56
	→ PerlJam joined	11:57
	→ johan-s joined	11:57
	← reaVer left	11:58
	→ reaVer joined	11:58
jast	cncfanatics, in fact that only deletes the tracking branch and not the actual remote branch afaik	12:02
cncfanatics	:o	12:02
	I'd have to run git push origin :refs/heads/BranchName too then ?	12:02
jast	i suppose so	12:03
cncfanatics	okay, thanks :)	12:03
fujin	is there a better way to delete remote branches?	12:03
	I would have guessed git branch to be able to take care of it somehow	12:04
	→ Pupeno joined	12:04
	→ bentob0x joined	12:05
jast	git branch deals with local stuff only	12:05
	if anything, i think git remote should handle that	12:05
cncfanatics	wouldn't it be possible to add that as extra argument for git remote rm ?	12:07
	if a branch is supplied only delete that branch	12:07
loops	git remote rm doesn't do anything to the remote repository.	12:08
	← ruphy left	12:08
Pupeno	how do I get rid of all current changes (and go back to the last submit)?	12:08
cncfanatics	revert the modified files ?	12:08
loops	All it does is remove local information about the remote repo	12:08
Pupeno	cncfanatics: yes.	12:09
loops	Pupeno, if you want to throw away all your local changes, and you're not worried about ever getting them back: git reset --hard but be careful it throws away all uncommitted local changes irretrievably	12:09
Pupeno	thanks.	12:10
	→ FunkeeMonk joined	12:12
	← FunkeeMonk left	12:13
Pupeno	Is there any command to check if a repo is ok? that is, not corrupt?	12:18
	← cncfanatics left	12:20
fujin	corrupt? heh - are you having issues?	12:20
	← PerlJam left	12:20
Tv	Pupeno: git fsck	12:20
Pupeno	Tv: that gave me two dangling trees, is that ok?	12:22
Tv	Pupeno: nothing serious	12:22
	Pupeno: stuff waiting to be garbage collected	12:22
Pupeno	fujin: I've got some weird messages when doing git svn rebase, and my management of the repo was not the best.	12:22
	Tv: that was just after gcing.	12:23
Tv	Pupeno: it doesn't gc them until they're old enough	12:23
Pupeno	Oh, ok.	12:24
	→ d0k joined	12:25
Pupeno	Is there an easier way of getting a diff of the last change than git diff previous_hash..last_hash?	12:31
Tv	git show	12:33
	← brosner left	12:35
	→ cncfanatics joined	12:39
	← Husio left	12:39
	→ thannoy joined	12:39
	← cncfanatics left	12:39
	→ BabelO joined	12:41
WildPikachu	which git command would one use to restore a deleted file?	12:41
Tv	did you commit it?	12:42
WildPikachu	nope	12:42
Tv	then read git status more carefully	12:42
WildPikachu	i'm blind ;)	12:43
	thanks	12:43
	hrmmmmmmm	12:44
	→ SuttoL joined	12:52
	← SuttoL left	12:53
	← z3ro_ left	12:55
	← Lemurnomicon left	12:56
	→ cncfanatics joined	12:58
	← cncfanatics left	13:04
	← janm left	13:19
ehamberg	I'm on the branc "(no branch)" for some reason. How can I make this replace my "master" branch?	13:20
	→ shaftyy joined	13:21
	← gcarrier left	13:24
Mikachu	ehamberg: one way is git branch -d master; git checkout -b master	13:26
	another way is git rev-parse HEAD; git checkout master; git reset --hard <paste the number from the first command here>	13:28
	→ GyrosGeier joined	13:30
chris2	http://www.gnu.org/software/gnuit/ <- hehe	13:34
	→ [tla] joined	13:35
	dadark_ → dadark	13:36
Mikachu	they renamed?	13:37
Pieter	yes	13:38
	a while back I think	13:38
	→ knurd joined	13:38
	→ a-priori joined	13:38
Pieter	in february apparently	13:39
	→ aroben joined	13:44
ehamberg	Mikachu: Thanks!	13:51
	← d0k left	13:57
	→ a-priori_ joined	13:57
	→ rmh3093 joined	13:59
rmh3093	can someone assist me, im having a brain fart... i need to seed an empty remote repo	14:00
	cant remember the push command i need to make a new branch	14:00
	its 'git push -f origin master'	14:01
	right?	14:01
deavid	git push origin master	14:01
	you don't need to --force	14:01
rmh3093	yeah ok.... my url must be fubar then	14:02
	→ bdiego joined	14:02
	← shaftyy left	14:02
	→ PerlJam joined	14:02
	→ shaftyy joined	14:02
	← aroben left	14:03
	→ zachinglis joined	14:08
bentob0x	why does a git-pull in an empty git repository only brings the current branch?	14:09
	→ ArteK joined	14:11
Mikachu	if it's an empty repo, how can there be a current branch?	14:11
	ph^_ → ph^	14:11
	← a-priori left	14:12
bentob0x	I'm very confused, I want to get the current version of a full existing git repository (with branches, commits etc), work on it and pull the changes back in the source repository	14:14
	basically working from laptop	14:14
thiago_home	clone it	14:14
bentob0x	ah	14:14
	going to try this right now	14:14
	→ aroben joined	14:15
	→ doener joined	14:17
	← aroben left	14:17
	→ aroben joined	14:18
bentob0x	ok, that's what I was looking for thiago_home, but it doesn't seem to have linked to the right directory	14:20
	on server, folder with git was: /var/www/folder, and I pulled locally in /var/www/new_folder, I expected the content of folder to be in /var/www/new_folder but it was in /var/www/new_folder/folder	14:22
	(I meant cloned)	14:22
Pieter	yes, that's how it works	14:22
	otherwise, user "git clone folder new_folder" from /var/www	14:22
	s/user/use/	14:22
bentob0x	so I should have typed: git clone var/www/folder .	14:23
	?	14:23
Pieter	no	14:24
	I don't think that works	14:24
bentob0x	I'll try	14:24
	doesn't work no	14:25
Tv	bentob0x: no scm i'm familiar with works the way you expected; they all like to checkout new subdirectories	14:25
	bentob0x: which is smart, because the potential for damage is much smaller	14:26
bentob0x	by damage you mean to overwrite the current git directory?	14:26
Tv	and files in the current dir etc	14:26
bentob0x	so git-pull won't overwrite anything?	14:27
Tv	how about i publish a repo with .bashrc that installs a backdoor on your machine, and you clone it in your ~	14:27
bentob0x	ah	14:27
thiago_home	we're talking about clone, not pull	14:29
	rmh3093 → zenbot	14:29
	zenbot → ricer4	14:30
	ricer4 → ricer4bot	14:31
	ricer4bot → ricer4ftw	14:31
	→ brosner joined	14:32
	ricer4ftw → rmh3093	14:32
knurd	hi all; just noticed that "git diff v2.6.23..v2.6.24 \| diffstat \| tail -n 1" and "git diff v2.6.23..v2.6.24 --shortstat" give different results (off by ten lines in fact)? is that a bug or amd I missing something here?	14:34
drizzd	knurd: git diffstat is smarter than diffstat, it can detect renames, for example	14:35
	not sure if that's the case in your example though	14:35
	← a-priori_ left	14:36
	→ a-priori joined	14:37
	← _graham_ left	14:40
bentob0x	ok now, git clone worked perfect, I did a commit locally and I would like that commit to be on the server too	14:42
knurd	drizzd, thx for the hint, but renames are definitely not the root for this off-by-ten, as there were a lot of renames between linux .23 and .24 with results in more then a ten-line difference (running "git diff -M" confirms this)	14:42
bentob0x	(sorry for my newbie questions)	14:42
knurd	drizzd, but yeah, maybe it's something other where git is smarter	14:42
Tv	different diff algorithms and settings will also make the numbers differ	14:52
	→ zachinglis_ joined	14:52
	← zachinglis_ left	14:53
	← kumbayo left	14:53
	← a-priori left	14:56
drizzd	well, the diff algorithm is the same	14:56
	→ a-priori joined	14:57
	→ cncfanatics joined	15:00
	← bdiego left	15:07
	→ ckknight joined	15:07
ckknight	hey all. What's the best way to prevent people from pushing a commit that has certain filetypes in it, e.g. .exe, .bat? (I'd actually prefer a whitelist over a blacklist)	15:08
	← ggeecko left	15:09
	← zachinglis left	15:09
drizzd	ckknight: .gitignore	15:09
	← ggeecko_ left	15:09
drizzd	actually, that won't help against pushing	15:09
ckknight	yea, was thinking that	15:09
	→ brazilian joined	15:10
ckknight	basically, if someone tries to push an exe (or whatever), it should stop the push and give an error	15:10
Mikachu	ckknight: find a good hook in documentation/hooks.txt and write a script that detects them	15:10
	← knurd left	15:17
	← a-priori left	15:17
	→ a-priori joined	15:17
	← lu_zero left	15:24
ckknight	I think a pre-receive hook is my best bet	15:25
	but I'm not sure how I'd get info on the commit in there...	15:25
	→ shaftyyy joined	15:26
WildPikachu	will git-rm remove the dir if there are no files in it?	15:27
Mikachu	ckknight: i think for each line of input, you have to loop over the git rev-list $1..$2 and check if any of the commits within contain the banned filetypes	15:28
	(pseudo code variable names)	15:28
ckknight	okay	15:28
	→ csc` joined	15:29
Mikachu	there are fun special cases when new branches are created though	15:29
WildPikachu	i wonder why my dir is being removed when it becomes empty :(	15:32
doener	WildPikachu: git doesn't track directories	15:33
cncfanatics	create an empty file in your dir WildPikachu	15:33
WildPikachu	so it does remove it if all files in it are gone?	15:33
Mikachu	it won't be created on a new checkout of the branch anyway	15:33
WildPikachu	ah	15:34
	cause i have 3 files in the dir	15:34
	i call rm in perl	15:34
RandalSchwartz	happy star wars day! may the fourth be with you!	15:34
WildPikachu	to remove the 3 files and WHAM dir dissapears ... which is not bad, I just want to make sure I understand this	15:34
Mikachu	the fourth?	15:34
	if it was a pun i completely missed the joke :)	15:35
RandalSchwartz	today is May the Fourth.	15:35
	"May the Force be with you"	15:35
Mikachu	ah	15:35
RandalSchwartz	but if you have to explain a joke... oh well.	15:35
Mikachu	i didn't think to look at the date	15:35
	→ madewokherd joined	15:37
doener	Mikachu, ckknight: I guess instead of iterating, you could do "git log --name-only --pretty=format: $1..$2", generates some empty line noise, but might be a bit faster	15:38
ckknight	I think using the update hook is better, not sure	15:38
Mikachu	doener: that's possible, the problem is still when 1==0	15:39
	that is less confusing if i write it as $1=="0"	15:39
doener	Mikachu: hm, then "git log --name-only --pretty=format: $2 --not --branches"?	15:41
	or --not --all, or whatever	15:41
Mikachu	aha, that looks nice :)	15:42
	← shaftyy left	15:42
Mikachu	i was having nightmares about looping over all local branches manually	15:43
	shaftyyy → shaftyy	15:43
doener	yeah, it's neat that log (and some others) take rev-list's options :-)	15:43
Mikachu	even so, i didn't know you could use --not and --branches together	15:44
	← shaftyy left	15:45
	→ shaftyy joined	15:46
doener	hm, yeah, the documentation is a bit unclear there, prefixing --branches with ^ makes little sense	15:46
	← harinath left	15:49
	→ harinath joined	15:50
	alb → albertito	15:51
	← bentob0x left	15:55
	← siprbaum left	15:56
	→ siprbaum joined	15:56
	← reaVer left	16:03
	← shaftyy left	16:03
	→ shaftyy joined	16:03
	→ kukks joined	16:04
	→ Jerdent joined	16:07
	→ brazilian_ joined	16:08
	← aroben left	16:13
	angasule_ → angasule	16:15
	→ peeja joined	16:16
	← niki left	16:18
	← johntramp left	16:19
	→ johntramp joined	16:19
	→ Oejet joined	16:20
	← brazilian left	16:20
	→ threeve joined	16:20
	→ ggeecko joined	16:21
	→ niki joined	16:21
	← eternaleye left	16:23
	→ johan-s_ joined	16:24
	← threeve left	16:26
	← shaftyy left	16:29
	→ shafty joined	16:29
	→ cooloney joined	16:31
eMBee	good evening	16:32
	→ ggeecko_ joined	16:32
	← ggeecko_ left	16:32
	→ KirinDav joined	16:32
eMBee	what exactly does git-mv do besides mv file; git add file; ?	16:33
	→ nostromo joined	16:33
	→ shaftyy joined	16:33
	→ a-priori_ joined	16:34
nostromo	I'm seeing a problem with git. Since last update "-C -C" gives an error about too many files to detect moves	16:35
aniero	eMBee: git elete oldfile	16:35
	eMBee: but that's really it	16:35
nostromo	and rebase or merge fail to follow moves correctly	16:35
	is it known? 1.5.5.1 here	16:35
	→ reaVer joined	16:36
	→ tobij joined	16:37
	← KirinDav left	16:37
	← yann left	16:38
	← johan-s left	16:38
	→ dsaxena joined	16:42
	eMBee is having an argume, erm, i mean a discussion about gits support for moving files.. is there any concise writeup on that topic?	16:43
aniero	eMBee: git doesn't track moving files. that's it.	16:44
eMBee	exactly, that is the issue	16:44
aniero	eMBee: git doesn't track files, per se, either, it's just content	16:44
	eMBee: the thing is, after the fact, you can figure out that oh, this new file is the same as what was in the old file, so it's a move	16:44
	→ asdx joined	16:45
aniero	eMBee: at that point it's "just" a matter of computation	16:45
	asdx → diego	16:45
aeruder	and frankly it works much better that way	16:45
aniero	yeah, agreed	16:45
aeruder	git blame with -M is a beautiful thing	16:45
	(for example) :)	16:45
aniero	ooh :D	16:45
	eMBee is looking for an explanation as to why it is not necessary to track moves, and what features there are (like -M) to find moves late	16:46
eMBee	later	16:46
Oejet	eMBee: There is a bit in the FAQ on git.or.cz.	16:46
aniero	eMBee: -M and -C for detecting moved lines and copiedl ines	16:46
	← kukks left	16:46
aniero	eMBee: it's not necessary to track moves because git only tracks filenames incidentally. it only really cares about contents, and if some blob (that's git's term) happens to be called one thing one day and something else another day, it doesn't matter	16:47
eMBee	i know that, but stating that unfortunately does not convince people who think it is important to track moves	16:47
	→ a-priori__ joined	16:47
	← shafty left	16:47
aniero	eMBee: the thing about tracking content is that you can reconstruct the moves after the fact	16:48
	→ shafty joined	16:48
aniero	you don't hae to tell the SCM about moves anymore because of the way it stores things. that information is just there waiting to be discovered/calculated	16:48
	so why bother with it up front if you can discover it after the fact if you really need to?	16:49
	← a-priori left	16:49
tobij	what if you edit and rename in one step, then commit?	16:49
	that'd be a bad idea then, right?	16:49
aniero	tobij: then it's a little harder to detect :p	16:49
aeruder	it has a similarity factor it considers when finding moves	16:49
	tobij: so unless you completely rewrite and move	16:50
	it'll still pick it up	16:50
aniero	if you completely rewrite it, is it really a move anyway? heh	16:50
cncfanatics	if you completely rewrite and move its not really a move is it ?	16:50
aeruder	and if you've rewritten it, then the merges will fail anyway	16:50
aniero	eMBee: i'm curious to hear why your friend thinks it's important to track moves	16:51
aeruder	tracking moves also adds all sorts of complexity to the repo itself	16:51
aniero	eMBee: (strictly out of curiosity, not looking to argue)	16:51
eMBee	i am still in the process of finding that out	16:51
aeruder	for example, let's say you want to get rid of a file in the history (purge it), try doing an svnadmin dump and editing out a file that gets copied/moved around	16:52
	the series of snapshots method of git just makes tons of stuff easier	16:52
	← aeruder left	16:53
	← nostromo left	16:55
	→ rofrol joined	16:58
	→ ggeecko_ joined	17:03
	← ggeecko_ left	17:03
	→ ggeecko_ joined	17:04
	← a-priori_ left	17:04
	← ggeecko_ left	17:04
	← ggeecko left	17:04
	← shaftyy left	17:05
	→ Sigurd joined	17:06
	→ ggeecko joined	17:06
	→ nostromo joined	17:07
	→ lu_zero joined	17:09
	← shafty left	17:16
	→ kristoffer joined	17:16
	← jbunster left	17:18
	→ a-priori joined	17:18
	→ threeve joined	17:21
	← brosner left	17:21
WildPikachu	hrmm ... the --all flag in git-commit	17:24
	would I use that if I add, remove, change files in a dir?	17:24
	or would i not use --all	17:24
	→ igorgue joined	17:26
	← niki left	17:26
	→ schacon joined	17:26
	→ brosner joined	17:29
	← cooloney left	17:31
	→ yann joined	17:33
	← thiago_home left	17:33
	← a-priori__ left	17:34
	← reaVer left	17:40
	→ reaVer joined	17:41
Ilari	WildPikachu: --all means to stage current versions of all tracked files before commit actually takes place.	17:41
	WildPikachu: Which results behaviour like default of pretty much any other VCS (including SVN).	17:42
	→ cliffstah joined	17:42
	← cliffstah left	17:44
Ilari	WildPikachu: The default is to commit currently staged files. New files need to be added in any case.	17:45
	→ cliffstah joined	17:45
	← cliffstah left	17:45
Ilari	WildPikachu: If you want to experiment, replace 'commit' by 'status', and it performs dry run...	17:45
	→ cliffstah joined	17:47
	→ kukks joined	17:48
	← cliffstah left	17:48
	→ cliffstah joined	17:48
	← cliffstah left	17:49
	→ cliffstah joined	17:49
WildPikachu	aha	17:50
	hrmmm, lock file exists	17:52
	← reaVer left	17:53
	→ reaVer joined	17:53
	→ malc_ joined	17:54
	← malc_ left	17:54
Ilari	WildPikachu: What command?	17:54
WildPikachu	git-status	17:55
	i killed a git-commit with ctrl-c	17:55
	well, may of been a kill -9	17:55
	happened because my script went mad :(	17:55
	safe to remove the lock file and try again?	17:55
Ilari	WildPikachu: Should be safe...	17:55
WildPikachu	cool	17:56
	→ ruphy joined	17:56
bryanray	For future reference you can just commit with no message and git will "cancel" the changes ... rather than kill -9'ing.	17:56
WildPikachu	well, my perl script went bonkers, so i ctrl-z'd it and kill %1 , then kill -9 %1 it :)	17:57
	omg .... i think it worked!	17:57
	→ thiago_ joined	18:00
WildPikachu	now, let me try and figure out how to do the rest :)	18:00
	← brosner left	18:01
	thiago_ → thiago_home	18:01
WildPikachu	omg x 2	18:01
	git-diff-tree --summary refs/heads/master refs/remotes/origin/master	18:02
	just what i wanted!	18:02
	not sure how right that is, but it looks really cool	18:02
	← ggeecko left	18:02
cncfanatics	compares the local & remote versions ? :o	18:02
WildPikachu	yep	18:03
Mikachu	is there any advantage over git diff --summary refs/heads/master refs/remotes/origin/master ?	18:03
doener	WildPikachu: git diff --summary master origin/master -- that's a bit more readable	18:03
Mikachu	it's fun to throw in -C too	18:03
	hm, why this syntax difference?	18:04
WildPikachu	oooooo	18:04
Mikachu	rename {obt => openbox}/mainloop.c (75%)	18:04
	rename obt/keyboard.c => openbox/modkeys.c (64%)	18:04
doener	WildPikachu: "... origin/master master" is more common for me though. or rather even "origin/master...master"	18:04
	WildPikachu drules	18:04
Mikachu	doener: uh, does ... mean anything with empty sides?	18:05
doener	Mikachu: hm? what do you mean? like origin/master...?	18:05
Mikachu	doener: you wrote "... origin/master master"	18:06
WildPikachu	now i need to see how i can push only a specific changeset	18:06
doener	Mikachu: ah, in that case, the ... meant to replace the "git diff --summary" part	18:06
Mikachu	ah	18:06
doener	too lazy to type :-/	18:06
	Mikachu: the syntax difference just makes it more visible that in one case, you moved a file from directory A to B, while in the other case, you also renamed the file along the way	18:07
	← madewokherd left	18:07
Mikachu	oh right, i didn't even notice the filename changed	18:07
Ilari	Isn't diff-tree output more suitable for scripting than diff output?	18:08
doener	at least that's how I always read it, and it was even useful a few times	18:08
WildPikachu	ok ... for now ... git-push without args will work for me	18:10
	→ fhobia joined	18:10
WildPikachu	oh man this is sooooo cool!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!	18:10
doener	Ilari: does that make a difference with --summary? But yeah, you shouldn't parse porcelain anyway, so diff-tree it is for scripts	18:11
	→ madewokherd joined	18:12
xenoterracide	if one does a remote fetch and then needs to merge the remote branch (origin/master) into local master. how do you do it?	18:15
Ilari	xenoterracide: 'git merge <branch-to-merge>'?	18:15
	→ ggeecko joined	18:16
	→ ggeecko_ joined	18:16
xenoterracide	k	18:17
	still trying to understand what the purpose of rebase is	18:17
	← lu_zero left	18:18
deavid	xenoterracide: rebase is for rewriting some changes on top of other ones; for example, if you are doing some kind of patch and the provider released a newer version of the code	18:18
	→ coderdad_ joined	18:19
	→ johnw joined	18:19
WildPikachu	hrmmm deavid	18:19
	so its like svn up ?	18:19
deavid	I don't know what svn up does	18:19
	WildPikachu thinks ...	18:20
WildPikachu	xenoterracide, http://eagain.net/articles/git-for-computer-scientists/	18:20
johnw	it's svn up = git fetch + git reset --soft HEAD	18:20
	s/it's/isn't	18:20
	→ mahmoud2 joined	18:21
johnw	(with no local checkins on master, of course)	18:21
WildPikachu	whats the diff between git-fetch and git-pull?	18:21
johnw	git-fetch doesn't change your local HEAD	18:21
WildPikachu	ah	18:21
johnw	git-pull will merge your local changes with the remote if necessary	18:21
WildPikachu	how would you update HEAD if you use git-fetch?	18:21
deavid	with fetch + merge	18:21
johnw	yep	18:22
deavid	fetch + merge ~= pull	18:22
xenoterracide	WildPikachu: thanks will look at it in a bit	18:22
WildPikachu	just plain git-merge with no args?	18:22
johnw	git-merge master	18:22
WildPikachu	aha!	18:22
johnw	um, git-merge origin/master	18:22
WildPikachu	sorry for all my q's :)	18:22
	my eyes are as wide as saucers	18:22
doener	or "git merge FETCH_HEAD", depends	18:23
johnw	you could also git-rebase at this point, since you haven't published your commits, if you wished to	18:23
	WildPikachu: check out http://newartisans.com/blog_files/git.from.bottom.up.php	18:23
	it doesn't talk about fetch, but it does talk about merge and such	18:24
WildPikachu	i'm still trying to understand under exactly what scenario i'd use rebase :)	18:24
	← zdennis left	18:24
	→ etnt joined	18:24
johnw	rebase transplants commits	18:24
WildPikachu	so say i commit a change to foobar	18:24
johnw	it cuts them off the common ancestor, and moves them to another base commit	18:24
WildPikachu	aha	18:25
	so it moves the patch along to a new base	18:25
johnw	yep	18:25
	patch or patches	18:25
	git-rebase -i can also edit patch history	18:25
	but it rewrites commits, so this is for local only	18:25
WildPikachu	so i guess if the same thing is changed in the remote repo, and i rebase .... the diff won't show anything?	18:25
johnw	yes, and the commit is dropped	18:25
	I always rebase in local branches, and merge in remote ones	18:26
	→ niki joined	18:26
WildPikachu	now ... i've made some changes to my "master" I have a few commit ID's ... how do I merge them into a branch v4.0.x?	18:30
	WildPikachu reads	18:30
	→ nkallen joined	18:31
johnw	checkout v4.0.x and then "git merge master"	18:33
	or git merge origin/master, if you haven't actually updated your local master yet	18:33
WildPikachu	do I need to checkout v4.0.x?	18:36
johnw	yes	18:36
	you need a working tree available for merge conflicts to be placed into	18:36
WildPikachu	cool ... i have 2 boxes, one with master checked out, other with v4.0.x checked out :)	18:36
johnw	local clones are extremely cheap	18:36
	if you can't afford to checkout something, just "git clone -l DIR NEWDIR" and then checkout there	18:37
WildPikachu	ah, hardlinks	18:37
	is there a way to merge in a specific set of files from master into v4.0.x?	18:37
	i guess i just specify them at the end of the command	18:38
johnw	no, because a merge must result in a new commit based on two or more existing ones	18:38
	to merge "only some files" will result in deleting the changes to all the other files	18:38
WildPikachu	hrmmm	18:38
johnw	you can git-cherry-pick to pull out a commit, then just use git checkout to wipe out changes to other files	18:38
	← schacon left	18:38
WildPikachu	can I specify the commit id to merge in?	18:38
johnw	git merge COMMIT	18:39
	git cherry-pick COMMIT	18:39
	git rebase COMMIT	18:39
WildPikachu	aha	18:39
	all 3?	18:39
johnw	those are your three options, each results in a different parent	18:39
WildPikachu	ah!	18:39
johnw	merge parent = COMMIT + old parent	18:39
	cherry-pick parent = old parent	18:39
	rebase parent = COMMIT	18:39
WildPikachu	and all 3 would only only pull in that commit id?	18:40
johnw	when you say "only pull in that commit id", I get nervous	18:40
	it would change your current branch based on the content tree represented by COMMIT	18:41
WildPikachu	see ... i made changes to 3 files, which were in one commit to my master	18:41
	i want to now merge that into my stable	18:41
johnw	use git merge	18:41
WildPikachu	argh, my v4.0.x branch	18:41
	cool, just making sure :)	18:41
johnw	git merge preserves the most history, at the cost of making it non-linear	18:41
	← cliffstah left	18:41
	→ cliffstah joined	18:41
WildPikachu	non-linear?	18:42
johnw	yes, let's say I had a master with X Y Z in it (commit names)	18:42
	and a branch with A B C	18:42
	and that I had merged every time either one changed	18:42
	then my local branch would be A A+X B B+Y C C+Z	18:42
	(and it is now based on the new Z)	18:43
	if I'd rebased, my local branch would always be A + B + C	18:43
	it's just the parent commit of A that would be changing	18:43
	← mahmoud2 left	18:43
johnw	(well, technically speaking A B C keep changing too, but that fact isn't adding new commits to the history)	18:44
	→ eternaleye joined	18:44
johnw	read that link I posted, it explains this difference in detail	18:44
WildPikachu	hrmmmmm	18:44
	cool	18:44
	→ mahmoud2 joined	18:44
johnw	if you always use git-merge, then you are on a par with svn	18:45
	→ dysinger joined	18:45
doener	johnw: technically speaking A, B and C don't change. You get _new_ commits A', B' and C'	18:45
Ilari	WildPikachu: Commit can have up to 16 (well, actually it could have even more) commits listed as its precessors...	18:45
doener	the old A, B and C will still be around	18:45
	→ Beket joined	18:46
johnw	doener: yeah, I tried to update what I said, but I thought i'd get more confusing as I went. thanks :)	18:46
Ilari	WildPikachu: Through normally one sees 0-2 precessors (0 being initial commit, 1 being ordinary commt and 2 being merge commit).	18:46
WildPikachu	hrmmm	18:46
	← igorgue left	18:46
johnw	WildPikachu: the trick here is becoming able to visualize your repository in terms of commits, rather than thinking in terms of "changes"	18:46
WildPikachu	ok ...	18:47
doener	johnw: yeah, transferring the dag-model to words can be hard when it comes to rebasing, I regularly fail at that ;-)	18:47
johnw	changes are the diff between two commits	18:47
doener	exactly because rebasing more or less deals with diffs rather than with commits directly	18:48
johnw	so when you cherry pick, for example, Git will take the diff between your HEAD and the commit you're cherry picking, will apply that diff as a patch to your HEAD, and then create a new commit that represents the application of those changes to your HEAD	18:48
	← coderdad_ left	18:48
doener	johnw: argh! no!	18:48
johnw	no?	18:48
doener	johnw: it takes the diff between the commit's parent and the commit	18:48
johnw	oops, johnw thinks he's wrong	18:48
doener	not the diff between HEAD and the commit	18:49
johnw	ok, since I'm confusing things even more at this point, I'll stop!	18:49
	doener: yes, you're right of course, I confused myself!!!	18:49
	→ fadec_ joined	18:49
doener	"git cherry-pick $sha1" is like "git diff $sha1^..$sha1 \| git apply"	18:49
	(roughly)	18:49
	→ d0k joined	18:50
johnw	see, even I just got bit by thinking about changes instead of commits	18:50
	johnw strives to retrain his CVS-addled mind	18:50
WildPikachu	hrmmmm	18:50
	if i cherry-pick a commit, i don't have to commit the cherry-pick? if i'm making any sense?	18:51
doener	WildPikachu: cherry-pick automatically creates a commit, unless there are conflicts	18:52
WildPikachu	aha!	18:52
reuss	or unless you use -n	18:52
WildPikachu	ok, i just resolved a conflict ...	18:52
doener	reuss: ah, right	18:52
WildPikachu	ok ... how do i get a file back that i just deleted using rm?	18:54
	one that had conflicts ... heh	18:54
doener	the version with the conflicts? Start over with the cherry-pick	18:55
WildPikachu	i did a cherry pick, it failed with conflicts, so I rm'd the file by mistake	18:55
	i would rather now go back and just copy the file from my master instead of merging in changes	18:56
doener	git checkout master -- file	18:56
WildPikachu	aha	18:56
doener	checkout is the almighty "get something from the repo" tool	18:56
johnw	doener: will git checkout master:file do the same thing?	18:56
	→ alley_cat joined	18:56
WildPikachu	ok, that restored the file	18:57
doener	johnw: no, that will error out	18:57
WildPikachu	how would I suck in the file from another branch?	18:57
johnw	git checkout branch -- file	18:57
	← d0k left	18:57
doener	WildPikachu: s/master/other_branch/	18:57
WildPikachu	aha	18:57
doener	whether you actually would want to do that is a different question	18:57
WildPikachu	so .... checkout can restore the files i remove by mistake	18:57
	and also suck in files from other branches	18:58
johnw	WildPikachu: checkout says "get X out of the repository"	18:58
	if you say "git checkout file", it will use your current HEAD	18:58
WildPikachu	ok ... I did a git-fetch, so obviously i must bring my head up to date first	18:58
doener	johnw: no, it will use the index	18:58
johnw	doener: damn	18:58
WildPikachu	hrmmmm	18:58
johnw	ah yes, git reset uses HEAD, not git checkout	19:00
doener	johnw: often enough that ends up the same, but if it doesn't you'll scream at your screen trying to get a file back ;-)	19:00
johnw	that's a thing I recently learned	19:00
doener	been there, done that	19:00
johnw	haha	19:00
	i've found gibak to be very handy for that case :)	19:00
WildPikachu	after a git-fetch, would i use git-merge to bring my local copy up to date?	19:00
	git-merge origin/v4.0.x?	19:01
johnw	or just say git-pull again	19:01
	and let it do that part for you	19:01
	← a-priori left	19:01
WildPikachu	i think i'm doing something wrong ..... i am trying git-checkout master -- repoUtil.c but under my branch to try suck in repoUtil.c	19:03
doener	johnw: hm? how would gibak help there? I don't need yet _another_ backup (.git/ already has one). It's just that "git rm file; git checkout file" won't restore the file, only "git checkout HEAD --file" will	19:03
	← Jerdent left	19:03
WildPikachu	it returns without error, but the files contents is still the branch contents	19:03
johnw	doener: gibak will save your repo, index and working tree all together	19:03
	so whatever you lose, you can get it back	19:03
	but if what you want to recover is in the repo somewhere, then yeah, you don't need it	19:04
doener	johnw: well, I was solely talking about the case where "git checkout file" doesn't work, because the file is also gone from the index	19:04
johnw	oh, I see what you mean	19:05
	← eternaleye left	19:05
doener	and stuffing git repos into a git repo doesn't make much sense to me, I can just push them to some other box ;-)	19:05
	→ krawek joined	19:05
johnw	well, i'm using it for the non Git-controlled stuff too	19:06
doener	yeah, for that, different issue, obviously ;-)	19:06
	johnw: btw, in your bottom-up pdf you say "The word HEAD refers to the most recent commit of the last branch you checked out"	19:07
WildPikachu	this is very weird	19:07
	← Oejet left	19:07
johnw	doener: hmm.. that does sound a bit unclear; how would you word it?	19:08
doener	johnw: actually, HEAD is a reference (.git/HEAD), either symbolic, pointing to the currently checked out branch, or non-symbolic pointing to the currently checked out commit (detached HEAD)	19:08
	← ggeecko left	19:08
	← ggeecko_ left	19:08
	→ eternaleye joined	19:08
	→ kumbayo joined	19:08
johnw	i was trying to describe it from just a usage point of view; usually when we say HEAD we mean "the tip of the current branch as known to your machine" -- even though yes, it really just refers to whatever the person decided to checkout	19:09
doener	"HEAD is a reference to the currently checked out branch or commit. If it references a commit, it is called detached HEAD."	19:14
	→ bdiego joined	19:14
doener	hm, that sucks	19:15
WildPikachu	if i have checked out my branch .... and another developer updates master .... and I do a git-pull on the branch, is it going to pull in his changes locally into my master?	19:15
	or only my branch?	19:15
johnw	well, it always references a commit, you mean a commit != tip of current branch	19:15
doener	johnw: no. Try this: "git checkout master && cat .git/HEAD" vs. "git checkout master^{}; cat .git/HEAD"	19:16
	in the first case, it's a symbolic reference, in the second case, it's not	19:16
johnw	i see what you mean	19:16
	← bdiego left	19:17
WildPikachu	AHA	19:17
deavid	HEAD always point to the commit where your Working copy is (based). It can have a symbolic ref, or a commit id.	19:17
WildPikachu	checkout origin/master -- filename	19:18
	that worked for me	19:18
doener	deavid: it's not pointing to a commit most of the time. It's pointing to a branch.	19:19
	unless you happen to work on detached HEADs all the time ;-)	19:19
deavid	doener: a branch is pointing to a commit too	19:19
	→ ggeecko joined	19:19
	← mahmoud2 left	19:19
	→ mahmoud2 joined	19:19
deavid	but it is not the same to point a branch as point a commit.	19:20
	because if you point a branch, you will update that branch;	19:20
doener	deavid: sure, but HEAD is _not_ pointing to that commit directly. If it was, how would you tell which branch you're currently on? ;-)	19:20
deavid	doener: right.	19:20
	then, in HEAD are two types of info avaliable; 1. the commit where you are 2. the branch (if you are on one)	19:21
	it is only another way of understanding the HEAD ref :-)	19:23
tobij	is there a specific reason why git-ls-tree would only work in the project root directory?	19:24
doener	tobij: works in subdirectories just fine here	19:25
	tobij: how is it failing for you?	19:25
tobij	doener: no output, strace suggests that it looks in $CWD/.git	19:26
	git version 1.5.3.7	19:26
WildPikachu	ooo ... how would i fast forward my master if i'm currently in a branch?	19:26
	checkout master, and pull?	19:26
doener	WildPikachu: fast-forward to your current branch?	19:26
WildPikachu	master updated while i was working on branch	19:27
tobij	doener: ok, narrowed it down... i'm in an untracked directory	19:27
	still, might one consider that a bug?	19:27
WildPikachu	i'd like everything up to date	19:27
tobij	hmm, probably not	19:28
	whatever.	19:28
	→ lu_zero joined	19:29
	→ igorgue joined	19:29
	→ doener_ joined	19:33
	← doener left	19:35
	← brazilian_ left	19:40
	← jjuran left	19:40
	← ggeecko left	19:43
	→ djwonk joined	19:45
	← djwonk left	19:46
	→ djwonk joined	19:46
djwonk	looking for some pointers on how to automatically create human-friendly build numbers from a git hash (i.e. for inclusion in hidden fields in bug reports on a Web app)	19:50
	i guess if the hash will be internal, i don't care if it is human friendly or not	19:50
	i guess this will work: git rev-parse HEAD	19:51
drizzd	djwonk: git describe	19:51
cehteh	tried 'git describe'	19:51
djwonk	fatal: cannot describe '22.......'	19:52
doener_	no annotated tags yet?	19:52
	← etnt left	19:52
doener_	try with --tags	19:52
	→ jjuran joined	19:53
djwonk	i embraced git on Friday, no tags yet :)	19:53
doener_	then there's --all	19:54
	although that's less useful in your case	19:54
djwonk	doener_: thanks, i'm learning more about git-tag, trying to figure out a good workflow	19:55
drizzd	djwonk: you need some kind of tag to get human-readable version numbers	19:55
djwonk	it would be super cool to use a tag for the "major" revision and then have git count the distance from the closest major tag for the minor	19:56
	could be some ambiguity perhaps, in which case it could just pick the closest in the "graph"	19:56
cehteh	thats what git describe actually does	19:56
djwonk	cehteh: nice!	19:56
	← dysinger left	19:56
	→ ggeecko joined	19:57
djwonk	thanks everybody	19:58
	← kristoffer left	20:03
	→ dysinger joined	20:06
WildPikachu	is there an easy way I can generate commit emails?	20:07
doener_	format-patch	20:08
WildPikachu	to one of our mailing lists	20:08
	preferably by the server i'm pushing to	20:08
doener_	ah, so you want push notifications	20:09
WildPikachu	yea	20:09
	that would be a post-receive-hook, right?	20:09
doener_	yeah, there's an example hook in contrib/hooks/	20:10
WildPikachu	aha	20:11
	→ schlurchz joined	20:13
	→ _graham_ joined	20:23
	← johntramp left	20:25
	→ johntramp joined	20:25
WildPikachu	ok .... if I have a master and a stable	20:26
	i beleive its possible to move stable to point to the master copy of a file	20:27
	wait, maybe is should read more :)	20:27
	← johnw left	20:31
	← cncfanatics left	20:31
	← Beket left	20:33
	← niki left	20:35
	→ tflsh joined	20:36
tflsh	is there a recommended way of doing a backup of the main repository for a project?	20:36
jengelh	rsync :p	20:37
Mikachu	get a large userbase	20:37
tflsh	hehe	20:37
	oh rsync, so just copy it all, preserving the file structure?	20:37
jengelh	of the .git dir (in case of a non-bare) yes	20:37
	← rofrol left	20:38
tflsh	hm	20:38
	well my "main" repository is not a working copy	20:38
jengelh	then just tar that	20:38
tflsh	it's set up via gitosis (awesome package)	20:38
	ok	20:38
jengelh	well or rsync	20:38
	just the git repository, and not the cehckout (if any)	20:38
tflsh	ok,makes sense	20:39
	i wanted to know if that was sufficient	20:39
	because i am aware of svn having svnadmin dump	20:39
	and mysqdump, things like that. i wondered if anything like that was needed here	20:39
jengelh	you might wnat to run git gc before	20:39
Mikachu	just be sure you don't push to the repo while taring/rsyncing	20:39
jengelh	you can rsync while it pushes	20:40
	you just have to rerun rsync again to update HEAD and so	20:40
tflsh	hmm didn't even know about git gc	20:40
Mikachu	jengelh: you'd need to do that indefinitely until you rsynced while there wasn't a push then.. :)	20:40
tflsh	well push and pull on my projects run very fast anyawy	20:40
jengelh	so just use btrfs	20:41
Mikachu	jengelh: i think the problem is rsync gets the objects dir, then some objects are written and head is updated, then rsync gets the head ref	20:41
	← kipras left	20:41
jengelh	snapshot it, rsync off, and then :)	20:41
tflsh	snapshot?	20:41
Mikachu	btrfs feature	20:41
tflsh	hmm time to google	20:41
	never heard of this fs	20:41
	is it like ext3, reiser?	20:42
Mikachu	it's very experimental	20:42
jengelh	better than any	20:42
tflsh	hmm cool	20:42
	surprised i hadnt heard of it yet	20:42
	about this git gc... is that something i run on my checked out repository or on the main (non working copy) repository (at the gitosis host) ?	20:42
jengelh	either	20:43
	it's for repacking the thing into few files	20:43
gebi	there is a network related fs too, crfs which uses the uniq features of brtfs	20:43
Mikachu	the one you are rsyncing/taring :)	20:43
tflsh	ok	20:43
	jengelh: is there any downside to running git gc, or can i safely do that now and then to keep the entire package size minimal?	20:44
Mikachu	the only i know of is if you're playing symlink tricks with refs	20:44
tflsh	oh ok	20:44
	well i am not doing that deliberately, so unless git does it for somme reason...	20:44
Mikachu	it doesn't :)	20:44
tflsh	cool thanks for answering all my questions guys	20:45
	destruct1 → destruct	20:45
	→ drizzd_ joined	20:47
	← glommer left	20:51
WildPikachu	how would I push only master?	20:52
jengelh	uh, git push r master?	20:52
	← fhobia left	20:53
djwonk	doener_: after some experimentation, it seems that git describe only works with annotated tags	20:53
	← schlurchz left	20:53
WildPikachu	fatal: 'master': unable to chdir or not a git archive	20:53
	hrmmmm	20:53
djwonk	if I leave off the -a then it doesn't seem to find the tag	20:53
	i mean if I do "git tag v0.4 abcd..." and leave off the -a	20:54
WildPikachu	aha	20:54
	git push origin master	20:54
	is that right?	20:54
	→ niki joined	20:54
	← johntramp left	20:55
	→ johntramp joined	20:56
	← statim left	20:58
doener_	djwonk: yeah, non-annotated tags are only considered if you use --tags (or --all)	21:00
djwonk	doener_: aha. is there some significance to annotated tags (i.e. taking the time to make a commit message gives them special significance?)	21:00
doener_	djwonk: you might use some tags locally, just to "mark" a few commits temporarily, for whatever purpose, and then drop those tags again. Having git describe use them is pretty useless then	21:01
	djwonk: an annotated tag is a first class object, a plain tag is just a reference.	21:01
djwonk	doener_: ok, so making an annotated tag signifies more -- and is represented differently internally	21:02
doener_	yeah. Annotated tags have a tagger, a message and can be signed	21:02
	and of course a tag date	21:02
	plain tags have none of that	21:02
	← drizzd left	21:03
	→ sd_ joined	21:03
	← igorgue left	21:04
	← krawek left	21:08
	→ igorgue joined	21:08
	← chris2 left	21:11
	→ cousin_it joined	21:12
	← johntramp left	21:13
	← trochala left	21:13
	→ johntramp joined	21:13
	→ eternaleye_ joined	21:14
	← cliffstah left	21:15
	← eternaleye left	21:16
RandalSchwartz	heh - the email I just sent to git@vger is marked text/us-ascii, but clearly has a utf8 char in it. :)	21:16
	stupid emailer	21:17
jengelh	RandalSchwartz: did you use git-send-email?	21:17
RandalSchwartz	no	21:17
	GNUS	21:17
	it should have noticed there was utf8 in there	21:17
jengelh	probably was not gnu enough	21:17
RandalSchwartz	no GNUS is good GNUS!	21:18
jengelh	ha	21:19
	"You space bastard! You killed my pine!!!"	21:20
	→ Jerdent joined	21:20
jengelh	1/msg #perl mauke: not in the default distribution :) but ok	21:21
	← kumbayo left	21:21
jengelh	blargh	21:21
doener_	RandalSchwartz: did the "reset --hard" restore the other version of Märchen?	21:21
	ie. the one with \314\210	21:21
	oh wait... nwm	21:22
	nvm... argh	21:22
	← johntramp left	21:24
	→ bobesponja joined	21:24
	→ aroben joined	21:24
	→ johntramp joined	21:24
	→ lolage0 joined	21:27
	← dysinger left	21:27
	→ dysinger joined	21:28
comp	is there some switch for git-rebase so it won't generate new hashes for "custom changes" once re-applied at top ?	21:28
	just like backup those things and cherry-pick them at top	21:29
doener_	comp: hm? new commit -> new hash. The ancestry changed.	21:29
comp	but that's the same commit	21:29
	no change was made "inside" it	21:30
wagle_home	it does recognize when two commits (with different sha1's) do "the same thing"	21:30
comp	not for me it seems	21:30
	git version 1.5.5.1	21:30
doener_	comp: so all files are the same, the parents are the same, the dates are the same, etc? Then your rebase did absolutely nothing ;-)	21:31
wagle_home	sorry, second hand info, i cant help more	21:31
comp	This caused me lots of problems with pushing to remote repo	21:31
	doener_: so better use merge then	21:31
	even when applying "base" updates from upstream	21:31
	well imagine a two branches, master and custom for example	21:32
	custom and master contains the same data	21:33
	you make ... let's say.. 5 commits in custom	21:33
	meanwhile, somebody else updates master from a remote master (fast-forward)	21:33
	and when I make a rebase from master to custom, all works fine except that those 5 commits will gain newly generated sha-1s	21:34
doener_	you rather get 5 new commits	21:34
	a commit is _not_ just a delta	21:35
comp	if I could make a new branch from the updated master and then cherry-picked those 5 from custom, this would'n happen	21:35
	well	21:35
doener_	comp: of course that would heppen	21:35
jast	cherry-picking changes the commit id, too	21:35
doener_	s/heppen/happen/	21:35
	cherry-pick creates new commits, just like rebase	21:36
	(in fact, rebase -i uses cherry-pick)	21:36
comp	it changes the commiter so it has to rehash	21:36
jast	that's probably a better way to look at things, yeah	21:36
	even if it didn't the id would change	21:36
	you can verify this by cherry-picking your own commit	21:36
	s	21:36
doener_	comp: the new commit has a different parent as well	21:36
comp	doener_: that explains why there were no errors with -i and conflicts with no parameters	21:37
	so in my scenario, if I want ever push those things, I should use merge instead of rebase	21:38
doener_	you can rebase as much as you want, until you push.	21:38
comp	exactly	21:39
	→ spearce joined	21:40
jengelh	but all your base still belong to us :)	21:40
comp	hehe	21:40
jengelh	once pushed, its ours	21:40
doener_	comp: http://git.pastebin.com/m65a1763e	21:42
Mikachu	all you'rebase? :)	21:42
doener_	comp: the B', C' and D' commits are the newly created commits.	21:42
	comp: B and B' have different parents, and most likely, their trees differ as well (due to the changes introduced in E, F and G)	21:42
jast	Mikachu, i think i may want to cry now. :(	21:42
	← sd_ left	21:43
doener_	comp: if you pushed "foo" before the rebase, you had B, C and D there. But pushing foo after the rebase, would then remove those from foo's history	21:43
	→ ljlane joined	21:44
	→ kristoffer joined	21:44
comp	I'm not sure if I understand your scenario, but in manpage there's a one also	21:44
	and if I undo custom changes, update and then apply them again, I'm applying them on a different parent	21:45
doener_	comp: foo forked from master at A and three commits were made on foo (B,C,D). In the meantime, 3 commits on master were made as well (E,F,G)	21:45
	the command to get the second history was just "git rebase master foo"	21:46
	← Eludias left	21:46
	← pygi left	21:46
comp	doener_: I now understand	21:47
	so it's basically a similar example as the one from manpage	21:47
	doener_: thank you	21:47
	RandalSchwartz hopes someone with ZFS on Solaris is nearby	21:47
	← johntramp left	21:47
	→ johntramp joined	21:48
	→ pygi joined	21:50
comp	so it can look like http://rafb.net/p/xo14Za17.html	21:50
	(i know, not a really good example)	21:51
	→ wheels_ joined	21:51
comp	because they will be different actually	21:51
	← morphir left	21:52
wheels_	i'm trying to commit a jquery js file to git and it splits back an error	21:52
	error: pathspec 'public/javascripts/ui-tabs-ext.js' did not match any file(s) known to git.	21:52
WildPikachu	how do i get the last commit that affected each file recursively?	21:52
Ilari	WildPikachu: Ah, that last commit that affected each file. That's pretty expensive thing to compute...	21:53
WildPikachu	is it possible?	21:54
	wait ... anything is possible	21:54
	is it easy?	21:54
	or is there some other way? ....	21:55
Ilari	WildPikachu: And no, there isn't any very easy way to do that. And if you want stuff like that, you should keep some kind of cache. Also, define 'latest commit'.	21:55
WildPikachu	well .... i have a list of files in the repo ... now ... we export certain part of our repo to mirrors	21:55
	think a website	21:55
doener_	comp: yeah, that would be two rebases (one for each topic). But you actually have E' and H'' and so on in the "AFTER" history.	21:55
WildPikachu	currently we cache the SVN commit rev's of each file	21:56
Pieter	RandalSchwartz: your problem with ZFS, I have that too with just HFS	21:56
WildPikachu	we then pull a recent list of files and their id's to see what changed	21:56
doener_	comp: ... as rebase creates new commits. The old E, F, G and H', I', J' are still araound	21:56
	s/araound/around/	21:56
WildPikachu	pull those files out the repo, remove the deleted ones, and update the mirrors	21:56
jast	WildPikachu, you can do a separate git log on every file	21:56
WildPikachu	cannot export the repo every time, because most files are gpg signed	21:57
	and i don't want to sit rsyncing every file each time :)	21:57
	only what changed	21:57
Ilari	WildPikachu: If you know the base state, use diff-tree to see what changed?	21:57
WildPikachu	yes ... i was looking at that aswell, which i'm very sure will actually work better	21:58
	for the base i can just export	21:58
	and for everything after that, i can do a diff-tree?	21:58
Ilari	WildPikachu: diff-tree is by far faster, since it only needs to consider two trees and can perform subtree pruning.	21:59
comp	doener_: thanks, that make things really more brighter	21:59
WildPikachu	and ....	21:59
	it tells me what to delete!	21:59
	and crate	21:59
	*create	21:59
Ilari	WildPikachu: Also, it tells what was modified.	21:59
comp	this is why is the tool called "re-base" after all	21:59
WildPikachu	exactly!	21:59
	← clsdaniel left	21:59
WildPikachu	let me see what i can do about that, it looks like a much better solution	22:00
	← alley_cat left	22:00
	← aroben left	22:00
doener_	comp: for rebase, it's IMHO better to think in terms of changes, instead of states.	22:01
Ilari	That kind of subtree pruning is the reason Git can do merges as fast as it does (which is very fast compared to pretty much everything else).	22:01
WildPikachu	yea	22:01
doener_	comp: commits represent states. What rebase does is looking at the changes between commits and reapplying those changes to some other commit. Thereby creating new commits	22:01
WildPikachu	ok, so my one set of scripts is now updated to git	22:02
	got email notifications	22:02
	gitweb ... etc	22:02
	and ssh accounts for all developers	22:02
	next is to do the scripts which control all the exports :)	22:02
comp	doener_: re-applying "static" changes making a new "commit header" on them	22:03
doener_	comp: hmhm, "commit header" makes no sense to me in that context	22:03
comp	well	22:03
doener_	comp: a commit records a certain _state_, the full contents of all files.	22:04
	A commit does not record a diff against its parent or so.	22:04
mugwump	that's quite an academic distinction	22:05
	given they are quite equivalent, modulo implementation bugs	22:05
comp	doener_: no, I didn'n though so	22:05
	thought	22:05
	→ statim joined	22:08
doener_	mugwump: well, unless I got it wrong from the beginning, this discussion started from the question why a commit got a new hash from a rebase, although it still introduced the same changes.	22:08
comp	so I'm a bit network man so I've imagined a commit as a packet header and actual changes as a packet payload, so much for confussion	22:08
	→ brosner joined	22:08
doener_	mugwump: And the fact that a commit does not consist of changes is at least part of the explanation, especially when you argue that the hash should be the same if the diff is the same	22:09
mugwump	the git-patch-id is the same	22:09
	← dysinger left	22:09
	→ dysinger joined	22:10
	← dysinger left	22:11
comp	As i get it - a commit represents a certain state and some aditional information like commiter, author, (gpg signature), ...	22:11
	so I'm going to read the manual again	22:12
RandalSchwartz	even if you made the exact same changes to a parent, and made a new commit from it, the commit sha1 includes the metainfo, which includes the timestamp	22:13
mugwump	try the user manual, chapter 7	22:13
RandalSchwartz	so you'll never get the same commit twice	22:13
	← brosner left	22:13
	→ brosner joined	22:14
comp	so, well, it can't be used as an identifier	22:15
	if you want to move your data	22:16
	← cousin_it left	22:16
	→ johnw joined	22:16
mugwump	you can move things around fine, it's just rewinding and reapplying changes that has the issue	22:17
	it's more of a caveat really	22:17
	again, see git-patch-id - it calculates an identifier based on the actual changes	22:18
	If any of this is not good enough, you can always throw some identifier you generated somewhere else in the commit message	22:18
	this is called a "surrogate"	22:18
	if you put them at the start of the commit message, you can refer to them as if they were regular commit IDs with :/blah	22:19
	→ sbeyer joined	22:19
	← thannoy left	22:20
comp	mugwump: thanks, will be useful	22:20
	← tcoppi left	22:20
	→ tcoppi joined	22:20
	← eternaleye_ left	22:24
	→ eternaleye_ joined	22:24
	← kristoffer left	22:29
	→ gcv joined	22:32
	← gcv left	22:34
	← Jerdent left	22:35
	← spearce left	22:38
	← thiago_home left	22:38
	← wheels_ left	22:39
	← jmspeex left	22:44
	← deavid left	22:45
	→ jmspeex joined	22:45
	→ wheels_ joined	22:46
	← igorgue left	22:47
wheels_	hi, i'm trying to push my changes to my github account and i'm getting : "error: failed to push some refs "	22:49
	any ideas how to fix?	22:49
mugwump	read more of the error message, then compare with the advice on the man page ? :)	22:50
wheels_	" ! [rejected] master -> master (non-fast forward)"	22:51
	this is all it says	22:51
Mikachu	do more people than you have push access to this account?	22:52
wheels_	yea, one other	22:52
	i did a pull first	22:52
Mikachu	he pushed something thne	22:52
drizzd_	wheels_: search for 'fast forward' in man git-push and the first thing you'll find is a paragraph which explains the error	22:52
	I think you can see if it's a fast forward by checking that git rev-list remote/master..master is empty	22:54
	→ Gitzilla joined	22:55
mugwump	similarly, you can look at 'gitk master...github/master', to see what's happening	22:55
	(assuming the remote is called 'github'	22:55
drizzd_	mugwump: that really works? I thought gitk only takes tips, no ranges?	22:55
	← ebel left	22:55
mugwump	sure, it accepts the full glory of git-rev-list options	22:56
	see also the "view" menu	22:56
	intersecting views is pretty cool	22:56
drizzd_	uh, which version?	22:56
wheels_	ok, did the git rev-list remove/master master and it shows the same error	22:56
	the rejected master -> non-fast forward	22:57
mugwump	that was in the version in 1.4, at least	22:57
wheels_	is there a way to overrwite everything in the remote gitbhub master with my master?	22:57
mugwump	that's called forcing	22:58
	the git-rev-list command wasn't going to change anything	22:58
Mikachu	it's also a little bit impolite to your friend	22:58
mugwump	try git merge remote/master	22:58
drizzd_	ok, I have 1.5.5.1 and it gives me "Bad agruments to gitk: ambiguous argument master...mybranch': unkown revision or path not in the working tree.	22:58
mugwump	then, git log remote/master..master will show nothing	22:58
Mikachu	drizzd_: do you have a branch called "mybranch"?	22:58
drizzd_	no, it's actually called fix-empty-merge, but I didn't want to cause confusion, which I managed to do anyway...	22:59
mugwump	you checked it with git-rev-list first?	22:59
	I use it all the time, so I'm pretty sure it works :)	23:00
	→ spearce joined	23:00
drizzd_	mugwump: oops, my bad	23:00
	I have no master, apparently	23:01
Mikachu	hooray, you're free	23:01
drizzd_	hehe	23:01
	→ cliffstah joined	23:03
	← [tla] left	23:03
	← nkallen left	23:05
	← johntramp left	23:11
	→ johntramp joined	23:12
	→ igorgue joined	23:17
	← wheels_ left	23:17
	← ph^ left	23:24
	← charon left	23:28
	→ cousin_it joined	23:28
	← _graham_ left	23:35
	→ spearce` joined	23:39
	→ dadark_ joined	23:46
	← cousin_it left	23:48
	← tcoppi left	23:51
	→ tcoppi joined	23:53
	← spearce left	23:54
	spearce` → spearce	23:56

Logs Search ←Prev date Next date→

Channels Documentation