merging the super-project
I recently made a tweak to the .gitignore of the super-project on the develop branch. How do I merge that to master? The two branches have different histories, so a regular git merge balks. And when I checkout master (thinking I'll just cherry-pick), I end up with a slew of local changes (which I haven't made). Befuddled, Eric
On 16 July 2014 17:32, Eric Niebler
I recently made a tweak to the .gitignore of the super-project on the develop branch. How do I merge that to master? The two branches have different histories, so a regular git merge balks. And when I checkout master (thinking I'll just cherry-pick), I end up with a slew of local changes (which I haven't made).
Cherry picking should work. It's hard to tell what the issue with local changes is without seeing what they actually are. Are they in submodules? You need to run 'git submodule --init' when you checkout a different branch. I sometimes use a separate checkout of the super project if I want to do something separate from the submodules. Git's quite slow at handling so many modules.
Daniel James wrote:
Cherry picking should work. It's hard to tell what the issue with local changes is without seeing what they actually are.
I sometimes get inexplicable local changes when the branch has been force-pushed. git reset --hard origin/master fixes it (assuming git checkout master).
On 16 Jul 2014 at 22:57, Peter Dimov wrote:
Daniel James wrote:
Cherry picking should work. It's hard to tell what the issue with local changes is without seeing what they actually are.
I sometimes get inexplicable local changes when the branch has been force-pushed. git reset --hard origin/master fixes it (assuming git checkout master).
If you ever force push, all bets are off, and you or more likely somebody else using your repo will lose data. Never, *ever* force push. Reset/throw away history and try again. A month of critical business work of a six person team at a former employer of mine was lost by a guy doing a force git push. They should really disable that feature of git, it's too easy to use. As an aside, a few days ago I foolishly ignored my time tested knowledge that force pushing will eat data and did a force push to a repo used exclusively by my CI. Every night my CI takes my repos and merges them with the client's repos, soak unit tests them and if all passes it pushes a unified copy back. Well, you can just guess what happened next. It wasn't pretty. I thank ZFS daily snapshots for being life savers. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 16 Jul 2014 at 9:32, Eric Niebler wrote:
I recently made a tweak to the .gitignore of the super-project on the develop branch. How do I merge that to master? The two branches have different histories, so a regular git merge balks. And when I checkout master (thinking I'll just cherry-pick), I end up with a slew of local changes (which I haven't made).
I think you check out the destination branch, then do git checkout <src branch> <paths> git commit He'll copy of all the necessary history for that file and merge it with the local history. Check the log to be sure. Push as normal after. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 07/16/2014 05:08 PM, Niall Douglas wrote:
On 16 Jul 2014 at 9:32, Eric Niebler wrote:
I recently made a tweak to the .gitignore of the super-project on the develop branch. How do I merge that to master? The two branches have different histories, so a regular git merge balks. And when I checkout master (thinking I'll just cherry-pick), I end up with a slew of local changes (which I haven't made).
I think you check out the destination branch, then do
git checkout <src branch> <paths> git commit
He'll copy of all the necessary history for that file and merge it with the local history. Check the log to be sure. Push as normal after.
Why is that better than cherry-picking the commit? Seems likely to lose data, e.g. if there are other differences to the file on the two branches.
participants (4)
-
Daniel James -
Eric Niebler -
Niall Douglas -
Peter Dimov