-2

I develop my app locally (in my own branch), but I can only test it on a remote dev server, by pushing to a git repo (my own branch) on the server, and then testing a working copy there.

As I can't find out why my web app crashed, I want to find the last "good" state to understand the reasons. I thought about using git bisect. But it changes just the state of local repo, not origin, and I can't test locally if it works. So what should I do then to check out different commits on remote branch easily (not putting much mess in commit history)?

Konst54
  • 175
  • 9
  • Maybe you should start by reading your error logs on your web host. `git bisect` is great for finding problems with your *code*, but it sounds like you need to identify differences between your development environment and your production one. – ChrisGPT was on strike Dec 22 '14 at 01:45
  • @Chris, thanks for your comment. The problem with differences between my development environment and production is not the one I am trying to solve right now. I had it before, and I'll solve it in future, but I was not bothered much developing in my branch on production. Until the app crashed because of some changes - as it's only my branch, I suppose it to be _code_ problem. So, you mean the only way of solving that problem is cleaning up my development environment first, and use bisect then? Or are there any other ways? – Konst54 Dec 22 '14 at 01:56
  • My point is this: *Your development environment should be as similar to production as possible.* If you have code that works in development but not production, the problem isn't with your code, it's with your environments. Why is it acceptable for code that works in development to fail in production? – ChrisGPT was on strike Dec 22 '14 at 01:58
  • 1
    Ah, I misread before. Your local version is *not* working. In that case, I don't understand what you are asking. Please make sure to clearly state the problem. – ChrisGPT was on strike Dec 22 '14 at 02:00
  • "I was not bothered much developing in my branch on production." *Ouch...* – sleske Dec 22 '14 at 02:02
  • @Chris, actually I don't mean my code works in development and fails in production, and I don't think that kind of situation is acceptable. I was just experiencing some db migration issues with my local environment before, and decided to develop in remote branch not to loose time until I fix that. So my code worked in production. But in few dates it crashed, and I'm trying to find the solution for this. Anyway, I think I catched your idea, and I'll try to fix the local issue too asap, thanks. – Konst54 Dec 22 '14 at 02:08
  • @sleske, could you please explain briefly, why developing in own branch and checking the results on remote is such a bad idea? Maybe I described the situation badly - it's not the working service, I meant just own (not main) branch on a development web server. – Konst54 Dec 22 '14 at 02:19
  • 1
    @Konst54: You wrote that you are "developing in my branch on production". Developing on a production server is generally considered a Bad Idea (tm). If by "production" you mean a dev server, that's something else. Still, you should be able to run the app locally too, as this simplifies some things (such as using `git bisect` :-) ). – sleske Dec 22 '14 at 22:00
  • @sleske , thanks for your comments&answers. I reworked the question to make it more clear & specific, could you please upvote it, or point out what else should I do to make it a good question? I am new to stackoverflow, hope I'll learn to post better questions soon :) – Konst54 Jan 17 '15 at 19:26
  • @Chris, thanks for your comments. I reworked the question to make it more clear & specific, could you please upvote it, or point out what else should I do to make it a good question? I am new to stackoverflow, hope I'll learn to post better questions soon :) – Konst54 Jan 17 '15 at 19:26
  • 1
    @Konst54: Welcome to stackoverflow. To make a good question, follow the excellent advice here: http://stackoverflow.com/help/how-to-ask . Also, make sure you describe everything accurately. For example, you write in a comment to my answer "I can only access the server by pushing there". Your question says that you "check out a working copy" on the server. That does not make sense. – sleske Jan 17 '15 at 19:42
  • @Chris: took this phrase from your answer. Changed it to "testing a working copy" to avoid confusion, slightly changed some phrases. – Konst54 Jan 17 '15 at 23:28

2 Answers2

1

If I understand correctly, you develop your app locally, but you can only test it on a remote server, by pushing to a git repo on the server (and then checking out a working copy there, I suppose).

In that case, you will have to run git bisect on the working copy on the remote system. git bisect does not create new commits or new branches, it just checks out different commits (thus putting you into "detached HEAD" state). Therefore there you cannot push the intermediate states created by git bisect to a remote (technically you could, but you'd have to force-push every time, and you'd then need to fix things up in the remote working copy anyway, so that would not help you).

But as I see (correct me if I'm not catching the idea right), git bisect changes just the state of my local repo, not origin.

Yes, exactly. To be precise, it only changes which commit is currently checked out in your local working copy.

TL;DR:

Log in to the remote server, and run git bisect there. If you can only access the server by pushing there, then you're on your own - git does not support this (at least not without a few ugly hacks).

sleske
  • 81,358
  • 34
  • 189
  • 227
  • Yes, you understood my situation correctly. Your solution seems to meet my needs. I haven't thought about it, and appreciate your idea. So I thankfully accept your answer. But I can only access the server by pushing there. Thus I solved the problem making a new branch and using several 'git reset' and force push in it, as mentioned below. – Konst54 Dec 26 '14 at 11:11
1

As I had access to server only by pushing there, finally I found the toxic commit by making a new bugsearch branch, and cutting off commits there:

git checkout -b konst54bugsearch

git reset --hard HEAD~1
git push origin +konst54bugsearch
[check the app, repeat reset and force push]

(Actually I could do something like git reset --hard HEAD~20 to approximate where the bug is, like bisect, but I knew it won't be too far).

As I found the commit, I reverted it in konst54 branch, got a working app with quite clean history in my branch, and plan to delete messed konst54bugsearch branch now.

Konst54
  • 175
  • 9