Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[DS-1085] EPerson last_active field is defined but never filled #164
referenced this pull request
Jan 11, 2013
I'm assuming the issue that helix84 is pointing at is the fact that there's an unnecessary "Merge" commit included here.
In order to get everyone better up-to-speed with best practices around when to rebase pull requests, could someone please get our Git docs updated around Pull Requests? https://wiki.duraspace.org/display/DSPACE/Development+with+Git#DevelopmentwithGit-ContributingChanges/PatchestoDSpaceviaGitHub
As it is, I feel like we're all merging/creating pull requests differently. Would be nice to clarify things in docs (even I'm a bit fuzzy at times in this area) & refer everyone to those docs.
OK, git-noob question: where is the 'git amioutofsync' command? The branch had been out of touch with upstream for some months, and I needed a way to find out whether it had been clobbered by later work. My old SVN habits told me to pull updates from the repository before committing. What should I have done?
I'm not sure what harm the merge does? It should melt into air when merged back to upstream, since all of those commits are already in there, leaving nothing but a history record showing that someone was diligent.
I'll note that the referenced DSpace documentation, with respect to rebasing, essentially says "don't."
git fetch origin # to connect to the remote repo and download info about latest branches and revisions
alternatively, git pull origin master will also tell you that (pull = fetch + merge), or a git checkout preceded by git fetch.
There's really quite a lot written on merge vs. rebase, so I'll only address the specifics.
I hope that explains it. If you have any questions, feel free to ask.
So, maybe I didn't even begin properly. "origin" is mwoodiupui/DSpace, not dspace/DSpace. My topic branch branched off of the fork I did way back when, whose "master" gets updated once in a while.
The problem (which I stated incorrectly) remains: how do I discover conflicting commits between dspace/DSpace/master and ., so I can resolve them? Without merging upstream.
The answer seems to be: always rebase. Assuming "origin" is my GitHub repo, "upstream" is dspace/DSpace, and . cloned from "origin", I guess this would be:
This is rather scary, in light of all the "rebase considered harmful" stuff out there, but it was the only command I could find which detects conflicts but operates on local rather than a remote.
Let me split up your question into 2:
git diff --stat upstream/master mwoodiupui/DS-1085
But in this case I personally prefer gitk (or one of its many clones).
rebase is indeed the only thing I can think of, but maybe there's another solution I'm unaware of.