5

noobie git question:

i was working on a branch A. i made changes to file x,y,z. so now these files are changed, and i need to commit them, but before commit , i need to pull changes from the remote version of A as other people might have changed files x/y/z or added some more files. what should be my approach ?

usually what i do is git add and commit all my files, followed by git pull. this makes my commit go below the merge commit, but i want my commit to be on top. also, how would i deal with conflicts if this is possible?

Comments
  • 3
    You should've pulled first before making any changes
  • 3
    there is nothing wrong in having your commits below theirs. Developments can happen in whatever manner they can happen. There is no strict sequential or any order

    If you still want that way, use the stash, pull from remote, pop the stash and go further
  • 5
    Pull and resolve all the conflicts manually. I don't think there's any other way :) unless ofc you want to be hated for force pushs
  • 0
    I think what you want is a rebase.
    That said if you really want ti have your commits in top no matter what, you can commit (not push), rebase on origin/A (and resolve any conflicts) then force push over it.
    Careful though, a force push can do a lot of damage, make sure your local state is what is actually desired.
  • 13
    Stash, pull, pop stash, fix conflicts, commit.
  • 1
    @Root yes! stash was the thing that i wanted. 2 minor caveats: (1) i had to uncommit my topmost local commit (reset HEAD~1) from 3 days ago to stash the changes. this made it loose the timestamp and my TL is gonna think i was lying when i told that i have done this task 3 days ago (he's cool tho, will not make adeal out of it)

    and (2) it kinda reverses the meaning of server and local changes while fixing resolve conflicts
  • 0
    @cabbybaby i pull before the start of any task and before pushing. by the time my task is done, someone usually changes those files. happens mostly with base classes, but that extra merge comment always irritates me
  • 1
    @yowhatthefuck If you want appropriate timestamps you obviously can't avoid merging, as commits must always descend from the previous local commit. Anyway, if you want the tree to represent what really happens (eg. so bisect works properly) merge commits are invaluable.
  • 0
    Does the extra merge commit irritate your TL or anyone else? Maybe they prefer the merge commit on top, as it shows the correct order of commits. Your changes were made whenever they were, timestamps match. The merge commit on top shows that the merge was done after your changes, in other words you are merging your past changes with current server state at that time.
  • 0
    git pull --rebase origin master

    or to do that one manually, then do:

    git fetch origin master
    git rebase FETCH_HEAD

    or if you haven't committed yet and don't want to, but you still want to update the current branch to the latest remote and apply your work on top of it:

    git add -A
    git stash
    git pull origin master
    git stash pop

    EDIT: @root already answered exactly the same; the second set of commands above are her answer verbatim.
  • 0
    git stash
  • 1
    @netikras I'm so glad I work at something where "force push" exists.
  • 0
    @cabbybaby yeah. Should have always pulls first
  • 0
    consider using git rebase

    that way you don't need a merge commit

    Personally I prefer git pull to be set to ff-only

    edit: atlassian has a decent help page for it

    https://atlassian.com/git/...
Add Comment