0

There is a repo on github named A. I cloned this repo to my local from github. The original repo A has a branch named 'a', which is at a previous version from A. There was a commit from the owner of the repo which deleted the history and replaced all the files on the repo. On github if you comapre the two, it says, A and a are entirely different commit histories

My problem is I want to push a commit on a which is in sync kind of was like a back up before the owner fast forwarded the master branch. But if I git pull before commit(which is a good practise) I am sure to run into problems since it's not at all into sync.

The best solution would be to stop tracking what master does and replace it with the a branch which is not possible as to what I know. What should I do to delete the fast-forward commit and make it sync back to 'a' branch.

P.S. The owner of the repo gets ![rejected] master -> master (non-fast-forward) it he tries to do a git pull. Says "the tip of his currrent branch is behind its remote counterpart"

If any of the part is unclear please feel free to ask, I am running into this problem since continuous 2days! Thanks.

Community
  • 1
  • 1
dibs_ab
  • 723
  • 2
  • 13
  • 24

2 Answers2

1

(If you had a question hidden somewhere, I sure couldn't find it. Here's my answer based on guessing what you tried to ask:)

I'm not sure why you think that doing blind git pull is a good practice before committing stuff. Doing a git fetch followed by gitk master origin/master sure makes sense to get a sense of the current status. Then you usually want to decide between git checkout master && git rebase origin/master and git checkout master && git merge origin/master.

If your local master branch is somewhere it should not be, first make sure that you do not have uncommitted changes and then do git checkout master && git reset --hard [sha1-of-the-commit-you-want] to move the master branch anywhere you like. If you then want to overwrite the master branch on the origin with your new correct state, just do git push -f origin master. Note that if other people have checked old master from origin, the will need to rebase all their commits to follow your new master. See https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_recovering_from_upstream_rebase for details.

Mikko Rantalainen
  • 14,132
  • 10
  • 74
  • 112
  • git pull or fetch I think just has a difference of merging in local copy. Would bring in changes between your last commit and curent commit. So I use git fetch/pull always before git push. And git reset hard did not show the commit since I did not do a git pull, the commit that was on the upstream repo. Thanks though. – dibs_ab Mar 06 '13 at 14:21
  • My point was that it is easier to decide if you want to merge or rebase after seeing both the local and remote branches (usually visually but whatever suits you). Of course, if you've already published your local branch, rebase is not usually the correct choice. If you prefer pull instead of fetch followed by merge or rebase, you must decide between `pull` and `pull --rebase` unless you really prefer merging here and there. – Mikko Rantalainen Mar 07 '13 at 06:51
  • Also worth mentioning is that usually the best practice is to merge features into the master instead of merging origin/master into the current HEAD (usually some kind of a feature). In practice, if your local `master` contains a new feature or something like that, do `git checkout -b super-cool-ui && git co master && git reset --hard origin/master && git merge super-cool-ui && git push`. That is, try to make the `master` reflect the current or next `master` of `origin` (or `upstream`) and do all new development in branches labelled according to the work done. Google for `git feature branch`. – Mikko Rantalainen Mar 07 '13 at 07:04
  • Thanks Mikko. You say that pull is better than fetch. I did not much get the point you tried to make in the above comment. I learnt few things from here after doing a search on feature branch http://nvie.com/posts/a-successful-git-branching-model/ – dibs_ab Mar 07 '13 at 07:14
  • On the contrary. I'm saying that always use `fetch` and after that use either `merge` or `rebase` after seeing the results of the `fetch`. Using just `pull` without `--rebase` is equal to `fetch` and `merge` combined. In that case, you're missing the opportunity to do `rebase` instead of `merge`. – Mikko Rantalainen Mar 08 '13 at 07:12
  • I would suggest reading http://www.jillesvangurp.com/2011/07/16/using-git-and-feature-branches-effectively/ -- it's a bit advanced and targetted towards groups of software engineers working in a big project but following the same logic does work for single engineer projects, too. – Mikko Rantalainen Mar 08 '13 at 07:22
  • The only situation where I'd recommend using `pull` is if you want to do one merge from another repository that is not worth adding to git config (`git remote add`). In that case, you should first create a temporary branch, do the pull there, review the changes and then fast forward the master if the pulled code is worth keeping. – Mikko Rantalainen Mar 08 '13 at 07:24
  • 1
    @MikkoRantalainen Even in that case I would probably just do a `fetch` and then work with `FETCH_HEAD` – Max Nanasy Mar 20 '13 at 07:20
  • @MaxNanasy Thanks, I'm still learning something about git every day! Now that I know that `fetch` does support fetching any branch of any repository I no longer can recommend `pull` for anything. – Mikko Rantalainen Mar 21 '13 at 08:23
0

I solved it with a simple solution. 1. The local changes were committed with
git commit -a -m 'temp'.
2. I made a new branch with all those changes reflecting in my local machine.
3. Did a checkout on master branch.
git checkout master
4. Did a force push after committing on my original repo.
git push -f upstream master
Now my local and original repo are completey in sync. P.S. There is a lot of warning given on force push since it changes the history. So use it very carefully.

dibs_ab
  • 723
  • 2
  • 13
  • 24
  • Could you elaborate your solution? What happened to branch `temp` after you did `checkout master`? I see that your remote repository is called `upstream` and not `origin` (which I used in my answer). – Mikko Rantalainen Mar 07 '13 at 06:55
  • temp was just a snapshot of the current unpublished work. I committed it on master branch and then made a copy of master branch. After this switched back to the new branch and did a reset for head to ignore this commit. I hope I am pretty much clear than my question ;) – dibs_ab Mar 07 '13 at 07:10
  • The `temp` was a branch. However, I cannot understand what you mean by "I committed it on master branch" because one cannot `commit` a branch to another branch. Did you mean `rebase` or `merge`? – Mikko Rantalainen Mar 07 '13 at 07:17
  • I'll explain. The current work should be stored somewhere so that I dont lose it. So temp. This was all on master. Once I made this commit. Master had temp. Now when I make a new branch it has this temp commit. So my work in this new branch now. And on master I dint want it because I did a force push. Because the current work was half done(not important). So from master I did a reset and done. Then did a force push to solve the main question problem. – dibs_ab Mar 07 '13 at 07:24
  • If I understand you correctly, the half finished work is still in the `temp` branch. I'm trying to say that `rebase` is the tool you want to use to bring the work done within the `temp` branch into the master. I'd guess that technically you could `merge` it but the end result is worse that way. – Mikko Rantalainen Mar 08 '13 at 07:16
  • The `git rebase` may be a bit hard to understand at first but learning it is truly worth the effort. Just understand the difference between private and published branches before using `rebase` too much. – Mikko Rantalainen Mar 08 '13 at 07:28