[01:18:24] *** Quits: Horwitz (~mich1@p200300ec9f011200022268fffe64e7c4.dip0.t-ipconnect.de) (Ping timeout: 258 seconds)
[01:31:33] *** Joins: Horwitz (~mich1@p200300ec9f06ab00022268fffe64e7c4.dip0.t-ipconnect.de)
[01:31:33] *** ChanServ sets mode: +o Horwitz
[04:47:03] *** Quits: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt) (Ping timeout: 260 seconds)
[05:00:32] *** Joins: mvglasow (~mvglasow@78-61-158-97.static.zebra.lt)
[09:26:13] *** Joins: bzed_ (~bzed@shell.bzed.at)
[09:26:35] *** Quits: bzed (~bzed@shell.bzed.at) (Read error: Connection reset by peer)
[09:26:39] *** bzed_ is now known as bzed
[17:49:07] *** Joins: ilovekiruna (~ilovekiru@ip1f12afe2.dynamic.kabel-deutschland.de)
[17:49:07] *** ChanServ sets mode: +v ilovekiruna
[18:31:40] <Navit> <jkoan> Hi all
[18:31:54] <mvglasow> hi there :-)
[20:17:53] <ilovekiruna> hi jkoan
[20:17:56] <ilovekiruna> hi mvglasow
[20:18:28] <mvglasow> hi
[20:18:40] <ilovekiruna> how are things?
[20:19:01] <ilovekiruna> mvglasow, can I ask you sth on git?
[20:19:13] <mvglasow> sure, ask :-)
[20:19:23] <ilovekiruna> am right now trying to rebase some code
[20:19:34] <ilovekiruna> have you seen before that one has nested <<<< HEAD
[20:19:37] <ilovekiruna> lines
[20:19:50] <ilovekiruna> or have i done a mistak
[20:20:07] <ilovekiruna> mistake*
[20:20:43] <mvglasow> yea, that's what happens when git can't figure out by itself how to apply your changes on top of the base branch
[20:20:56] <ilovekiruna> shit
[20:21:05] <mvglasow> basically, rebase works like: git checkout topic_branch; git rebase base_branch
[20:21:07] <ilovekiruna> I face such things and have no damned clue
[20:21:43] <mvglasow> which takes base_branch and, on top of that, applies every commit which is in topic_branch but not in base_branch
[20:21:57] <ilovekiruna> I know
[20:22:11] <ilovekiruna> I basically tried just to do a rebase and kill a pretty old commit
[20:22:14] <ilovekiruna> quite a mess ;-)
[20:22:55] <mvglasow> when it hts a conflict, i.e. it can't figure out how to put these two together, it adds <<< commit ------ >>>> commit lines with the conflicting code in between
[20:23:25] <mvglasow> meaning you'll have to look at the code and decide what you want the result to be
[20:23:40] <ilovekiruna> exactly and I got sth like <<< commit <<< commit ------ >>>> commit
[20:24:14] <ilovekiruna> a simple <<< commit ------ >>>> commit seems obvious
[20:24:56] <mvglasow> either you can resolve this by hand, or if you really messed up things and still have the SHA1 of the last commit (pushed it somewhere, maybe), then git reset --hard OLD_SHA1 will do the trick
[20:25:22] <ilovekiruna> am still in the rebase
[20:25:33] <ilovekiruna> can I run reset during rebase?
[20:25:41] <mvglasow> if you don' have the SHA1, maybe it is still in your local db, iirc git has some command to find those unreferenced commits
[20:26:12] <ilovekiruna> am not so worried, I work in a special branch :-)
[20:26:13] <mvglasow> during rebase, I think git somewhere has a command to abort it, it should have output it
[20:26:34] <ilovekiruna> want to avoid abort ;-), that would mean redo everything
[20:27:05] <mvglasow> git rebase --abort should go back to the topic branch as it was before the rebase
[20:27:29] <ilovekiruna> exactly, I think I am half through
[20:27:53] <mvglasow> see git help rebase for your options during rebase
[20:29:13] <mvglasow> or note down what your last commit was (you need the SHA1), then git rebase --abort, then git checkout SHA1, git checkout -b temp. git checkout topic_branch, git rebase temp
[20:29:19] <mvglasow> which essentially...
[20:29:56] <mvglasow> creates a new branch with the rebase as far as you got, then rebases your topic branch on top of that
[20:30:05] <mvglasow> no guarantee, but might work
[20:31:16] <ilovekiruna> nice idea, thanks
[20:31:25] <mvglasow> good luck
[20:32:12] <mvglasow> if it's just a handful of commits, git merge --squash might also help, or cherry-picking commits one by one
[20:50:33] <ilovekiruna> around 100 commits :-(
[20:52:10] <ilovekiruna> but I might try cherry-picking