I'm totally agree with Mike,
In fact, I use that simple criterion:
make a new branch for any action and work, share, stash, commit any thing into
it
if original branch is updated, we need merge the original advances using fast
forward resolution (try to move the local pointer of our topic bran
> Your link says "Merge is perfectly fine for managing your code." The
> only drawback it mentions is a more cluttered log. It has far stronger
> warnings about misusing rebase.
>
> How could anyone read this conclusion
>
>
> 1. Merge works great, but creates lots of empty merge commits when
Hi,
> At least, nobody has gotten on my case for screwing up history.
Run gitk to view. You might be surprised. It's reasonable but it's not 100%
"clean" (for the SDK anyway).
Justin
On 4/5/13 7:22 PM, "Gordon Smith" wrote:
>
> Your link says "Merge is perfectly fine for managing your code." The only
> drawback it mentions is a more cluttered log. It has far stronger warnings
> about misusing rebase.
>
> How could anyone read this conclusion
>
>
> 1. Merge works grea
Your link says "Merge is perfectly fine for managing your code." The only
drawback it mentions is a more cluttered log. It has far stronger warnings
about misusing rebase.
How could anyone read this conclusion
1. Merge works great, but creates lots of empty merge commits when you are
worki
> Unfortunately that won't prevent it.
Please explain why not.
- Gordon
Sent from my iPad
On Apr 5, 2013, at 6:21 PM, "Michael A. Labriola"
wrote:
> Gordon and Justin,
>
>> 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
Hi,
> Incidentally, this is why is most larger open source projects... see linux
> (or even what we did on FlexUnit in git) have a very few number of people who
> knew git well that managed the actual develop and master branches.
Could that work for us? (With committers pushing to develop that i
Gordon and Justin,
>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 t
