First of all i'd like to thank you for your suggestions. I think that i'll 
follow Philip Oakley's suggestions, so i'll keep the repository clean but 
complete. I'm using TortoiseGit to manage my local repos, so i just have to 
do

   - "Show log"
   - Select two or more commits, then right click and "Combine to one 
   commit" (i don't know what commands this procedure equals to)
   - "Git Sync", then push after having ticked the box "Force" (otherwise 
   it will ask for a pull before)
   
Then, from the other local repos on other PCs, i do a pull with force 
enabled and.. i get everything.

If, in the future, i will get bigger local repos, i think i'll use the 
depth parameter as suggested by Manlio Perillo.

Konstantin Khomoutov's solution seems a bit too complicated to me, and the 
remarks on the fact that this can be an unneccesary operation made me 
reconsider this option.

Anyway, thank you all for these replies.

Il giorno lunedì 24 dicembre 2012 01:31:37 UTC+1, Philip Oakley ha scritto:
>
> Why do you need 'small'? and how small?  There are a few different reasons 
> that may affect what you choose.
> 1. You have big different binary files in each commit - it is good to get 
> rid of these - perhaps set a better gitignore file.
> 2. You have lots of small partial fixes, such as work in progress (WIP) 
> commits - You should 'squash' the WIP commits using 'rebase -i', once you 
> are satisfied with your branch. This will mean the new commit sequence 
> moves steadily form one working code base to the next in small well 
> explained steps - this is good.
> 3. You have a lot of steps in you development on big source files and are 
> worried about storage - Don't. Git is very good at it's repository 
> compression, so the 'many steps' will fit in a small space, and you will 
> still have a better history.
>


Il giorno lunedì 24 dicembre 2012 15:52:01 UTC+1, Konstantin Khomoutov ha 
scritto:

> I'm not sure it would work for you, but look at `git replace` [1]. 
> Basically, using this feature, you might pretend that A->B->C 
> line exists in the PC1 and PC2 repos, but is in fact absent. 
> To do this, you first record an empty commit object and then 
> create a "replacement record" for it as described in the `git replace` 
> manual.  Such a record has to replace the SHA-1 name of the D's parent 
> with the SHA-1 name of your empty bogus commit. 
>


Il giorno lunedì 24 dicembre 2012 16:05:35 UTC+1, Manlio Perillo ha scritto:

> You can also try with git clone --depth=1 <remote-repository>, but read 
> the manual page carefully. 
>
> If you want full history again, you can just 
> git clone <remote-repository>. 
>

-- 


Reply via email to