Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
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. -
@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 -
@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
-
@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.
-
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.
-
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. -
@netikras I'm so glad I work at something where "force push" exists.
-
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/...
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?
question
git