1 |
On Sat, 25 Jul 2009 13:10:41 -0400 |
2 |
Simon <turner25@×××××.com> wrote: |
3 |
|
4 |
> I have tried using git in the past and found that it doesnt work in my |
5 |
> 'space constrained' scenario. The need for a repository is a problem. |
6 |
> The use of the usbkey however is nice since it allows git to work |
7 |
> without having each computer maintain its own repository... but |
8 |
> still... i dont currently have a usbkey that's large enough to hold |
9 |
> all my data, even if i could compress it i doubt it would fit. |
10 |
> |
11 |
> Another thing is, i wonder if it retains the attributes of the file |
12 |
> (creation date, mod date, owner/group, permissions)? As this can be |
13 |
> important on some aspects of my synchronisation needs. |
14 |
|
15 |
Vanilla git doesn't, apart from executable bit. |
16 |
|
17 |
Due to highly-modular structure of git, one can easily implement it |
18 |
as a wrapper or replacement binary at some level, storing metadata in |
19 |
some form (plain list, mirror tree or just alongside each file) when |
20 |
pushing changes to repo, applying on each pull. |
21 |
Then there are also git-hooks, which should be a better way than |
22 |
wrapper in theory, but I found them much harder to use in practice. |
23 |
|
24 |
|
25 |
> Still, git is a very good solution that works incrementally in a |
26 |
> differential manner (makes patches from previous versions). But when |
27 |
> i tried it, i found to suit my needs it would require the programming |
28 |
> of a big wrapper that would interface git to make some daily quick |
29 |
> actions simpler than a few git commands. |
30 |
|
31 |
That's another advantage of wrapper, but note that git-commands |
32 |
themselves can be quite extensible via aliases, configurable in |
33 |
gitconfig at any level (repo, home, system-wide). |
34 |
|
35 |
[alias] |
36 |
ci = commit -a |
37 |
co = checkout |
38 |
st = status -a |
39 |
br = branch |
40 |
ru = remote update |
41 |
ui = update-index --refresh |
42 |
cp = cherry-pick |
43 |
|
44 |
Still, things such are "git ui && git cp X" are quite common, so |
45 |
wrapper, or at least a set of shell aliases is quite handy. |
46 |
|
47 |
|
48 |
>> I apologize if the existence of a bare repo as an intermediary is a problem. |
49 |
>> This can be done on a server as well. |
50 |
> |
51 |
> It is... it makes all my computer dependant on that repo... sync'ing |
52 |
> computers at home can be done alright, but will still require walking |
53 |
> around pluging/unpluging. Makes this practically impossible to do |
54 |
> over the network (or to sync my host on the internet, not all my pc |
55 |
> are connected to the internet so the repo cant be just on the server, |
56 |
> i would have to maintain several repositories to work this out...). |
57 |
> It may be possible to adapt it to my scenario, but i think it will |
58 |
> require a lot of design in advance... but i'll check it out... at |
59 |
> worst it will convince me i should program my own, better it will give |
60 |
> me some good ideas or fortify some of my own good ideas and at best it |
61 |
> will be the thing i've been looking for! |
62 |
|
63 |
Why keep bare repo at all? That's certainly not a prequisite with |
64 |
distributed VCS like git. |
65 |
|
66 |
You can fetch / merge / rebase / cherry-pick commits with git via ssh |
67 |
just as easy as with rsync, using some intermediate media only if |
68 |
machines aren't connected at all, but then there's just no way around |
69 |
it. |
70 |
And even here, knowing approximate date of last sync, you can use |
71 |
commands like git-bundle to create single pack of new objects, which |
72 |
remote(s) can easily import, transferring this via any applicable method |
73 |
or protocol between / to any number of hosts. |
74 |
|
75 |
|
76 |
As you've noted already, git is quite efficient when it comes to |
77 |
storage, keeping the changes alone. |
78 |
When this will become a problem due to long history of long-obsoleted |
79 |
changes, you can drop them all, effectively 'sqashing' all the commits |
80 |
in one of the repos, rebasing the rest against it. |
81 |
So that should cover requirement one. |
82 |
|
83 |
Cherry-picking commits or checking out individual files / dirs on top |
84 |
of any base from any other repo/revision is pretty much what is stated |
85 |
in the next three requirements. |
86 |
One gotcha here is that you should be used to making individual commits |
87 |
consistent and atomic, so each set of changes serves one purpose and |
88 |
you won't be in situation when you'll need "half of commit" anywhere. |
89 |
|
90 |
Conflict resolution is what you get with merge / rebase (just look at |
91 |
the fine "git-merge" man page), but due to abscence of "ultimate AI" |
92 |
these better used repeatedly against the same tree. |
93 |
|
94 |
About the last point of original post... I don't think git is |
95 |
"intuitive" until you understand exactly how it works - that's when it |
96 |
becomes one, with all the high-level and intermediate interfaces having |
97 |
great manpage and sole, clear purpose. |
98 |
|
99 |
|
100 |
That said, I don't think git is the best way to sync everything. |
101 |
I don't mix binary files with configuration, because just latter suffice |
102 |
with gentoo: you have git-synced portage (emerge can sync via VCS |
103 |
out-of-the-box), git-controlled overlay on top of it and pull the |
104 |
world/sets/flag/etc changes... just run emerge and you're set, without |
105 |
having to worry about architectural incompatibilities of binaries or |
106 |
missing misc libs, against which they're linked here and there. That's |
107 |
what portage is made for, after all. |
108 |
Just think of trendemous space efficiency here - no binaries are backed |
109 |
up at all, and all you need to do to restore 3G root from 2M pack is |
110 |
"git clone (or receive-pack) && emerge -uDN @world" ;) |
111 |
|
112 |
|
113 |
-- |
114 |
Mike Kazantsev // fraggod.net |
115 |
|
116 |
-- |
117 |
Mike Kazantsev // fraggod.net |