>> Okay, at its heart, the danger Fred was worried about is that, using a merge >> workflow, the person who pulls the changes needs to make sure they commit >> all changes... even files they didn't touch, because they 'inherit' the >> merge.
> Do you have any advice on how to get around this issue in a simple way? I agree that it would be bad to edit 2 files, do a 'git pull' followed by a 'git status', and see changes to 200 files from other people mingling with your changes to 2. The simple way to prevent this is to commit your changes before pulling in other people's changes (I think). - Gordon -----Original Message----- From: Justin Mclean [mailto:jus...@classsoftware.com] Sent: Friday, April 05, 2013 4:07 PM To: dev@flex.apache.org Subject: Re: Git needs a KISS Hi, > Okay, at its heart, the danger Fred was worried about is that, using a merge > workflow, the person who pulls the changes needs to make sure they commit all > changes... even files they didn't touch, because they 'inherit' the merge. Do you have any advice on how to get around this issue in a simple way? I would of though that those changes would of already been in develop (99% of git pulls/git push are going to be from develop right?). Could this issue occur in the develop branch? If so is it easy to recognise that it has occurred and what would be the steps to fix it? > For those new to git, if you are using this workflow, take a look at > SmartGit. Thanks for the pointer will give it a go. Thanks, Justin
