Povilas Kanapickas

@Gugli thanks for the bug report. I think this was simply an oversight. The old console view does not set `compact` at all. Probably this means that the `compact` was...

The problem with the current solution is that it does not check what branch the existing codebase is on. It just blindly does `git reset --hard `. In many cases...

> the problem with your proposal is that it will checkout the tip of the branch and not the wanted I don't think this is the case. The sequence of...

Thanks, now I understand why we arrive to different conclusions. > The original git clone -b already bring us to the correct branch The issue is that `Git` step supports...

> such a mistake will lead to loud failure. In incremental mode the failure may not happen because the step reuses existing git repository, so the commit may exist even...

> so maybe we need git checkout + git reset --hard I agree that this is more correct due to the reasons you've outlined. My concern is that if ``...

> I'd say the simpler strategy is first making sure we're on the wanted (and refreshed if needed) and the last thing would be to reset our position back to...

> But then it will branch to a local which is different from origin/ (only has the same name, but not the same hash -- this is totally misleading Isn't...

> I think that if the tip of and are far apart, the file operations are unavoidable, otherwise we do a wrong semantics trying to adapt to the wanted Yes,...

I would say that `git reset --hard ` does not guarantee that commit is on branch either. It only guarantees that commit `` exists in repository (`` actually can be...