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. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fdfb50.3000...@kvr.at