Re: Proposed git migration plan
On 2014-08-27 01:41, Antoine Musso wrote:
> Le 27/08/2014 10:13, Sandro Tosi a écrit :
> <snip>
>> Offline commits? how many time (for real..) you badly needed it? i
>> guess so few that if you (for one time) just do a big commit instead
>> of a storm of micro commit the world wont stop
>
> As a side effect, that also mean you don't have to use a potentially
> lagged network connection when doing simple operations. There is
> nothing I hate more than waiting for network when using the commands
> log, commit or blame.
This annoys me to no end as well.
>> is there anything else so "attractive" about git?
>
> Cheap local branches which let you pill up work in progress patches /
> rewrite without having to keep several copy of the same svn repo. The
> branches in git are just a name pointing to a commit in the tree.
I would really like to emphasize this one. The ability to work locally,
then rewrite that work, and only *then* publish it is invaluable to me.
When implementing a feature, I don't need to share the history of all
mistakes I made with the world, because to everyone else but me, those
are just noise polluting the history and unnecessarily complicating it.
Instead, I implement the feature locally, and when it works as intended,
I rewrite the entire history so that it is clean and comprehended, and
only *then* do I push.
> The stash, which let you save your uncommited changes and come back to
> them later (think of it as lightweight branches). That is really nice
> when you have to interrupt your workflow, stash it, handle the
> interrupt, reapply your stash and resume work.
>
> Tags can be signed with gpg. They are a pointer to a commit just like
> branches, and hence don't force you to do a full copy to create a tag.
>
> Switching between branches is a breeze and does not need network access
> either.
>
>> If we don't define *upfront* what are the problems we currently have
>> and that we want to solve, then we're just proposing a technical
>> exercise without a real gain. and I cant stress this point never
>> enough.
>
> I agree there, would be nice to list the problems with svn. But I guess
> most of them are related to svn being a bad (and slow) CSV system.
Reply to: