git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
* new to git
@ 2007-08-27 19:43 Kyle Rose
  2007-08-27 20:11 ` J. Bruce Fields
                   ` (3 more replies)
  0 siblings, 4 replies; 13+ messages in thread
From: Kyle Rose @ 2007-08-27 19:43 UTC (permalink / raw)
  To: git mailing list

After many years of dissatisfaction with the limitations of CVS, and
after getting fed up with the complexity of configuring and maintaining
a SVN setup, I just started using git for my own personal projects.  I
have to say it's quite nice and fits the UNIX philosophy well: fast,
simple, powerful.

I've been playing with it for a few weeks and generally understand what
is going on, but I do have a few usage questions that I couldn't find
answered in the docs:

(1) Let's say I:

git clone something
git branch foo
git checkout foo
<make some changes>
git commit -a
git checkout master
git pull . foo
git push
git pull

what is actually happening?  The pull appears to do something (i.e., I get:

* refs/remotes/origin/master: fast forward to branch 'master' of
/home/krose/git-repository/baz/
  old..new: 7cf088c..d344f98

), but makes no changes locally since I have the latest revision. 
Another subsequent git pull does, in fact, say everything is up to date.

(2) Any way to disable this warning:

Warning: No merge candidate found because value of config option
         "branch.local.merge" does not match any remote branch fetched.

(3) I notice I can't reset --hard a single file.  So, if I want to
revert a single file to some revision, blowing away my changes, what is
the accepted way of doing this?  Is there a way to do the equivalent of
a p4 print foo@some_revision?

(4) I'm still not clear on when a dst should and should not be used in a
refspec.  It appears that one can only do non-fast forward updates to
the branch that is checked out (which makes sense, since you may need to
resolve), but other than that, what is the difference between

git checkout foo
git pull . master

and

git checkout master
git push . master:foo

?

(5) Are there any tools for managing some of the metadata (e.g., the
origin URL) or is it expected that one edit it directly?

Thanks for all your work on this: git fills a need I didn't know I had
until I actually found myself using it: a completely decentralized patch
management system.

Kyle

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 19:43 new to git Kyle Rose
@ 2007-08-27 20:11 ` J. Bruce Fields
  2007-08-27 20:22 ` Andreas Ericsson
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: J. Bruce Fields @ 2007-08-27 20:11 UTC (permalink / raw)
  To: Kyle Rose; +Cc: git mailing list

On Mon, Aug 27, 2007 at 03:43:47PM -0400, Kyle Rose wrote:
> I've been playing with it for a few weeks and generally understand what
> is going on, but I do have a few usage questions that I couldn't find
> answered in the docs:

I think I tried to cover most of this in the user-manual
(http://www.kernel.org/pub/software/scm/git/docs/user-manual.html has
the latest version, or it's in Documentation/) but some of it may be
harder to find than it should be.

> (1) Let's say I:
> 
> git clone something
> git branch foo
> git checkout foo
> <make some changes>
> git commit -a
> git checkout master
> git pull . foo
> git push
> git pull
> 
> what is actually happening?  The pull appears to do something (i.e., I get:
> 
> * refs/remotes/origin/master: fast forward to branch 'master' of
> /home/krose/git-repository/baz/
>   old..new: 7cf088c..d344f98

Git caches the value of the remote's "master" in
refs/remotes/origin/master.  That's the thing that's getting updated;
you can actually

	cat .git/refs/remotes/origin/master

before and after you'll see that it got updated from 7cf088c to d344498.

I think newer versions of git actually update that "remote-tracking
branch head" on the push as well, which would prevent you from getting
the message since by the time of the pull that thing will already have
been updated.

> (3) I notice I can't reset --hard a single file.  So, if I want to
> revert a single file to some revision, blowing away my changes, what is
> the accepted way of doing this?

	git checkout some_revision path/to/filename

> Is there a way to do the equivalent of
> a p4 print foo@some_revision?

I don't know p4, but maybe you're looking for

	git show some_revision:foo

> (4) I'm still not clear on when a dst should and should not be used in a
> refspec.  It appears that one can only do non-fast forward updates to
> the branch that is checked out (which makes sense, since you may need to
> resolve), but other than that, what is the difference between
> 
> git checkout foo
> git pull . master
> 
> and
> 
> git checkout master
> git push . master:foo

The latter should forcibly reset the branch head "foo" to point at the
same commit as "master".  The former tries to do a merge between the
two.

In the case where master is a descendant of foo (so there's no commits
in foo that isn't already in master), the two should do the same thing.

> (5) Are there any tools for managing some of the metadata (e.g., the
> origin URL) or is it expected that one edit it directly?

Maybe you want "man git-remote"?  Or see "git-config" for more general
configuration.

But editing .git/config file directly is often simplest, and won't cause
any problem.

--b.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 19:43 new to git Kyle Rose
  2007-08-27 20:11 ` J. Bruce Fields
@ 2007-08-27 20:22 ` Andreas Ericsson
  2007-08-27 20:36   ` Kyle Rose
  2007-08-27 20:39   ` Junio C Hamano
  2007-09-05  5:56 ` Jan Hudec
  2007-09-05  6:54 ` Junio C Hamano
  3 siblings, 2 replies; 13+ messages in thread
From: Andreas Ericsson @ 2007-08-27 20:22 UTC (permalink / raw)
  To: Kyle Rose; +Cc: git mailing list

First of all, welcome to git :)

Having been away from the mailing list for too long, I can't answer all
your questions. I'll take a stab at the ones I've got a clue about though.

I also recommend that you upgrade your git installation to at least 1.5.3,
as most of the people figuring on this list will most likely give advice
that matches that version.

For reference, the git documentation can be found at
http://www.kernel.org/pub/software/scm/git/docs/

J. Bruce Fields et al have written some really excellent introductory
documents which are a must to anyone who wishes to flatten the initial
learning curve a bit.

Kyle Rose wrote:
> After many years of dissatisfaction with the limitations of CVS, and
> after getting fed up with the complexity of configuring and maintaining
> a SVN setup, I just started using git for my own personal projects.  I
> have to say it's quite nice and fits the UNIX philosophy well: fast,
> simple, powerful.
> 
> I've been playing with it for a few weeks and generally understand what
> is going on, but I do have a few usage questions that I couldn't find
> answered in the docs:
> 
> (1) Let's say I:
> 
> git clone something
> git branch foo
> git checkout foo
> <make some changes>
> git commit -a
> git checkout master
> git pull . foo
> git push
> git pull
> 
> what is actually happening?  The pull appears to do something (i.e., I get:
> 

git pull = git fetch + git merge. The notation you use above is obsoleted
and no longer works in git 1.5.3. Instead you'd have to replace

	git pull . foo

with

	git merge foo

which will most likely clear up some confusion.

> * refs/remotes/origin/master: fast forward to branch 'master' of
> /home/krose/git-repository/baz/
>   old..new: 7cf088c..d344f98
> 
> ), but makes no changes locally since I have the latest revision. 
> Another subsequent git pull does, in fact, say everything is up to date.
> 

It should have made changes to your local tree, namely the ones you added
to branch foo that weren't in master before you merged.

The fact that it turned out to be a fast forward only means that you had
no additional commits on top of master, so the history in foo could be
applied on top of master without any file-level merging taking place.

> (2) Any way to disable this warning:
> 
> Warning: No merge candidate found because value of config option
>          "branch.local.merge" does not match any remote branch fetched.
> 

Yes. Edit your .git/config file to add a merge candidate for your local
branch.

> (3) I notice I can't reset --hard a single file.  So, if I want to
> revert a single file to some revision, blowing away my changes, what is
> the accepted way of doing this?  Is there a way to do the equivalent of
> a p4 print foo@some_revision?
> 

	git checkout treeish path/to/file

according to the man-page at least. "treeish" here can be substituted
for a revision, which in git is represented by a 40 byte SHA1 hash, but
also has a lot of short-hand options. See "git help rev-list" for more
info on that.

> (4) I'm still not clear on when a dst should and should not be used in a
> refspec.  It appears that one can only do non-fast forward updates to
> the branch that is checked out (which makes sense, since you may need to
> resolve), but other than that, what is the difference between
> 
> git checkout foo
> git pull . master
> 
> and
> 
> git checkout master
> git push . master:foo
> 
> ?
> 

Here I'm clueless, except that this matches old syntax which is no longer
valid. I'd recommend you to upgrade to 1.5.3 so that you get to use
git-merge for local merges. The "use push/pull for merging" has caused
enough confusion, I think.

> (5) Are there any tools for managing some of the metadata (e.g., the
> origin URL) or is it expected that one edit it directly?
> 

See the git-remote man page. It's available online if you don't have it.

> Thanks for all your work on this: git fills a need I didn't know I had
> until I actually found myself using it: a completely decentralized patch
> management system.
> 

It's more than that, but many of us share your feeling about it filling
a need we didn't know we had.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 20:22 ` Andreas Ericsson
@ 2007-08-27 20:36   ` Kyle Rose
  2007-08-27 20:39   ` Junio C Hamano
  1 sibling, 0 replies; 13+ messages in thread
From: Kyle Rose @ 2007-08-27 20:36 UTC (permalink / raw)
  To: git mailing list

Thanks for your help: your responses clear up a lot of things, and
getting to 1.5.3 will be a priority, though I will probably wait until
it appears in the Ubuntu pool, which unfortunately it has not yet. 
Differentiating merge and push as asymmetric operations (which pull and
push do not imply, sounding symmetric) is a very good idea.

FWIW, I cannot believe I hadn't found Mr. Fields' doc before this: it
seems pretty thorough, so I will read it before posting any further
questions.

Thanks,
Kyle

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 20:22 ` Andreas Ericsson
  2007-08-27 20:36   ` Kyle Rose
@ 2007-08-27 20:39   ` Junio C Hamano
  2007-08-27 21:14     ` Andreas Ericsson
  1 sibling, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2007-08-27 20:39 UTC (permalink / raw)
  To: Andreas Ericsson; +Cc: Kyle Rose, git mailing list

Andreas Ericsson <ae@op5.se> writes:

> git pull = git fetch + git merge. The notation you use above is obsoleted
> and no longer works in git 1.5.3. Instead you'd have to replace
>
> 	git pull . foo
>
> with
>
> 	git merge foo
>
> which will most likely clear up some confusion.

Huh?  "git pull . foo" has always been the same as "git merge
foo", I thought...  Have we broken anything?

>> (2) Any way to disable this warning:
>>
>> Warning: No merge candidate found because value of config option
>>          "branch.local.merge" does not match any remote branch fetched.
>>
>
> Yes. Edit your .git/config file to add a merge candidate for your local
> branch.

Or, say what branch you get from the remote you want to merge
explicitly.  You may not always merge the same branch from the
remote.  E.g.

	$ git pull origin experimental
	$ git pull origin master

>> (4) I'm still not clear on when a dst should and should not be used in a
>> refspec.  It appears that one can only do non-fast forward updates to
>> the branch that is checked out (which makes sense, since you may need to
>> resolve), but other than that, what is the difference between
>>
>> git checkout foo
>> git pull . master
>>
>> and
>>
>> git checkout master
>> git push . master:foo
>>
>> ?
>>
>
> Here I'm clueless, except that this matches old syntax which is no longer
> valid.

Huh again about "no longer valid" part.

In any case, the former says "I am on foo branch, and I want to
merge 'master' from _MY_ local repository".  The latter says "I
want to update the local branch 'foo' with what is in my
'master' branch, both local".  They are totally different.

Please do _not_ spread backward incompatibility FUD.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 20:39   ` Junio C Hamano
@ 2007-08-27 21:14     ` Andreas Ericsson
  0 siblings, 0 replies; 13+ messages in thread
From: Andreas Ericsson @ 2007-08-27 21:14 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Kyle Rose, git mailing list

Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
> 
>> git pull = git fetch + git merge. The notation you use above is obsoleted
>> and no longer works in git 1.5.3. Instead you'd have to replace
>>
>> 	git pull . foo
>>
>> with
>>
>> 	git merge foo
>>
>> which will most likely clear up some confusion.
> 
> Huh?  "git pull . foo" has always been the same as "git merge
> foo", I thought...  Have we broken anything?
> 

Possibly. I noticed some weeks ago that "pull . branch" no longer
worked and used merge instead. I shrugged it off as being of no
moment, and can't recall if there were any real reasons for
the merge to fail.

>>>
>> Here I'm clueless, except that this matches old syntax which is no longer
>> valid.
> 
> Huh again about "no longer valid" part.
> 
> In any case, the former says "I am on foo branch, and I want to
> merge 'master' from _MY_ local repository".  The latter says "I
> want to update the local branch 'foo' with what is in my
> 'master' branch, both local".  They are totally different.
> 
> Please do _not_ spread backward incompatibility FUD.

My apologies. I'll have to see if I can find what caused my own
confusion in the first place.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 19:43 new to git Kyle Rose
  2007-08-27 20:11 ` J. Bruce Fields
  2007-08-27 20:22 ` Andreas Ericsson
@ 2007-09-05  5:56 ` Jan Hudec
  2007-09-05  6:54 ` Junio C Hamano
  3 siblings, 0 replies; 13+ messages in thread
From: Jan Hudec @ 2007-09-05  5:56 UTC (permalink / raw)
  To: Kyle Rose; +Cc: git mailing list

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Mon, Aug 27, 2007 at 15:43:47 -0400, Kyle Rose wrote:
> After many years of dissatisfaction with the limitations of CVS, and
> after getting fed up with the complexity of configuring and maintaining
> a SVN setup, I just started using git for my own personal projects.  I
> have to say it's quite nice and fits the UNIX philosophy well: fast,
> simple, powerful.
> 
> I've been playing with it for a few weeks and generally understand what
> is going on, but I do have a few usage questions that I couldn't find
> answered in the docs:
> 
> (1) Let's say I:
> 
> git clone something
> git branch foo
> git checkout foo
> <make some changes>
> git commit -a
> git checkout master
> git pull . foo

git merge foo

would be probably both clearer about the intent and more efficient here.
After all, pull is just a simple wrapper for fetch + merge and you don't need
the fetch from the repository to itself.

> git push
> git pull

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: new to git
  2007-08-27 19:43 new to git Kyle Rose
                   ` (2 preceding siblings ...)
  2007-09-05  5:56 ` Jan Hudec
@ 2007-09-05  6:54 ` Junio C Hamano
  3 siblings, 0 replies; 13+ messages in thread
From: Junio C Hamano @ 2007-09-05  6:54 UTC (permalink / raw)
  To: Kyle Rose; +Cc: git mailing list

[jc: I think this is really worth saving somewhere.  Could some
kind soul make this into a patch to have under Documentation/
somewhere?]

Kyle Rose <krose@krose.org> writes:

> (1) Let's say I:
>
> git clone something

  Origin repository's history is copied and you get their master
  in remotes/origin/master (aka remotes/origin/HEAD aka
  remotes/origin), and you can call that 'origin' for brevity.
  At the same time, you get your own 'master' branch that points
  at the same commit as the 'origin'.  Your current branch
  pointed at by your HEAD is 'master'.

     ['origin' repository]
     ---A---B---C
                ^master

 ==>

     [your cloned repository]
     ---A---B---C
                ^master = HEAD
                ^remotes/origin

> git branch foo

  You create a new branch of your own 'foo' in your repository,
  initially pointing at the same commit as your current commit
  (i.e. C as you are on 'master' after the clone).

 ==>

     [your cloned repository]
     ---A---B---C
                ^master = HEAD
                ^remotes/origin
                ^foo

> git checkout foo

  You switch from your current branch (i.e. 'master') to the
  named branch (i.e. 'foo'), making the latter the current
  branch.  Your work tree will largely match the commit at the
  tip of the branch you are switching to, except that if you had
  any local changes (i.e. uncommitted) in your work tree, you
  take it along (but in this example you do not have any).

 ==>

     [your cloned repository]
     ---A---B---C
                ^master
                ^remotes/origin
                ^foo = HEAD

> <make some changes>
> git commit -a

  You build a commit whose parent is the commit your HEAD used
  to point at; the tip of your current branch advances.

 ==>

     [your cloned repository]

     ---A---B---C---D
                    ^foo = HEAD
                ^master
                ^remotes/origin

> git checkout master

  You switch from your current branch (i.e. 'foo') to the
  named branch (i.e. 'master'), making the latter the current
  branch.  Your work tree will largely match the commit at the
  tip of the branch you are switching to, except that if you had
  any local changes (i.e. uncommitted) in your work tree, you
  take it along (but in this example you do not have any).

 ==>

     [your cloned repository]

     ---A---B---C---D
                    ^foo
                ^master = HEAD
                ^remotes/origin

> git pull . foo

  This "git pull" command instructs git to "from the repository
  '.', grab the commit the repository calls 'foo', and update my
  current branch by merging that commit".  Because '.' is "the
  current directory", which in turn means "my repository", you
  do not have to really "grab the commit" --- you already have
  it locally.

  "git merge foo" is more natural way to write this since 1.5.0
  days.  The latter command instructs git "update my current
  branch by merging commit I call 'foo'".

  Now, looking at the above history graph, your current
  branch'es tip is at C (you are on 'master', remember?), and
  'foo' is at D, which is an descendant of C.  By definition, a
  merge between such commit pair is the descendant D, so your
  current branch is updated to D (this is called "fast
  forward").

 ==>

     [your cloned repository]

     ---A---B---C---D
                    ^foo
                    ^master = HEAD
                ^remotes/origin

> git push

  This is kind of "lazy" and "very not-git-like" command I
  literally *hate*.  What "git push" does, whey you do not say
  anything about "where to" nor "what", is to "push all
  corresponding branches and tags to the repository you call
  'origin'".

  If you recall the very initial picture, the 'origin'
  repository has 'master' branch but not 'foo'.  The only
  matching branch is 'master', and that is pointing at C over
  there, which is replaced by your 'master' which now points at
  'D'.

     ['origin' repository]
     ---A---B---C
                ^master

 ==>

     ['origin' repository]
     ---A---B---C---D
                    ^master

  Note that this update *MUST* be fast-forward by default.  IOW,
  if somebody worked elsewhere and updated the 'master' branch
  at the 'origin' repository before your push, your 'push' will
  be prevented with an error message that tells you that remote
  'master' is not a strict subset of what you are pushing.

> git pull

  Instruct git to "grab the history from the 'origin' repository
  and update remotes/origin/* with its branch, and then update my
  current branch by merging its tip".

  The first step of updating the remotes/origin again *MUST* be
  fast-forward by default.

 ==>

     [your cloned repository]

     ---A---B---C---D
                    ^foo
                    ^master = HEAD
                    ^remotes/origin

  If you recall, you are on 'master' branch whose tip is at D.
  Now you are telling git to update it by merging what you
  fetched, which also is D.  So nothing happens.

> (2) Any way to disable this warning:
>
> Warning: No merge candidate found because value of config option
>          "branch.local.merge" does not match any remote branch fetched.

Do as the warning says; I do not think the message can be any
clearer (see Documentation/config.txt, or even better "The
User's Manual").  Set branch.local.merge configuration variable
if you want to always merge specific branch you obtain from the
remote.

E.g.

     [branch "local"]
	remote = origin
        merge = refs/heads/master

if you want "git pull", without saying what to pull from where,
to fetch from 'origin' and merge its 'master' branch, when you
are on your 'local' branch.

> (3) I notice I can't reset --hard a single file.  So, if I want to
> revert a single file to some revision, blowing away my changes, what is
> the accepted way of doing this?  Is there a way to do the equivalent of
> a p4 print foo@some_revision?

I have no idea what p4 does, but:

	git checkout -- path

updates the work tree file with the last version of paths you
did "git add path",

	git checkout HEAD -- path

updates the work tree file with the version of paths in the HEAD
commit, and

	git checkout some_version -- path

updates the work tree file with the version of paths in the
named commit.  For various ways to name commits, see
git-rev-parse(1).

> (4) I'm still not clear on when a dst should and should not be used in a
> refspec.  It appears that one can only do non-fast forward updates to
> the branch that is checked out (which makes sense, since you may need to
> resolve), but other than that, what is the difference between
>
> git checkout foo
> git pull . master
>
> and
>
> git checkout master
> git push . master:foo

The obvious difference is which branch you end up with.

> (5) Are there any tools for managing some of the metadata (e.g., the
> origin URL) or is it expected that one edit it directly?

git-remote(1).

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: New to git
  2011-04-09 19:15   ` Marco Maggesi
  2011-04-09 19:35     ` Dmitry Potapov
@ 2011-04-09 22:41     ` Matthieu Moy
  1 sibling, 0 replies; 13+ messages in thread
From: Matthieu Moy @ 2011-04-09 22:41 UTC (permalink / raw)
  To: Marco Maggesi; +Cc: git

Marco Maggesi <marco.maggesi@gmail.com> writes:

> Hi Chris and Peff,
>
> 2011/4/8 Jeff King <peff@peff.net>:
>> But if you are just using the server as a distribution point for a
>> single repository, it can be much simpler. For example, if you always
>> just want to push and overwrite what is on the server (i.e., like a
>> mirror), you can just use plain rsync outside of git. To avoid mirror
>> lag, you do want to update the objects before the refs. So this:
>>
>>  LOCAL=/path/to/repo.git
>>  REMOTE=server:path/to/repo.git
>>  rsync -a $LOCAL/objects/ $REMOTE/objects/
>>  rsync -a $LOCAL $REMOTE
>>
>> would work. And then expose repo.git on the server via http or ftp, and
>> clients can clone directly from it.
>
> this is the solution I was looking for (but I where not sure that it
> worked).

It works, but "git push" does something that rsync can't: it will refuse
non-fast forward, i.e. refuse to override commits that you don't have
locally.

So, I'll just insist on the "if you are just using the server as a
distribution point" part. If you ever push from two different machines
to the server with rsync, you'll take the risk of loosing data.

If the server runs an HTTP server, an alternative is to push over
WebDAV, it doesn't require Git on the server. It's slow, but safer than
rsync.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: New to git
  2011-04-09 19:15   ` Marco Maggesi
@ 2011-04-09 19:35     ` Dmitry Potapov
  2011-04-09 22:41     ` Matthieu Moy
  1 sibling, 0 replies; 13+ messages in thread
From: Dmitry Potapov @ 2011-04-09 19:35 UTC (permalink / raw)
  To: Marco Maggesi; +Cc: git

On Sat, Apr 9, 2011 at 11:15 PM, Marco Maggesi <marco.maggesi@gmail.com> wrote:
>
> Well, the server is a very old machine and I didn't find easy to
> compile git on it because of many missing dependencies (but I didn't
> try very hard either).

Some time ago, I built git on an old machine running Linux (RedHat 8.0
but maybe some packages were upgraded). Here is the line that I used:

make NO_OPENSSL=1 NO_NSEC=1 NO_CURL=1 NO_TCLTK=1 NO_PYTHON=1

I needed git only to push and fetch to that repository, and it worked
well for me.

Dmitry

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: New to git
  2011-04-08 20:10 ` Jeff King
@ 2011-04-09 19:15   ` Marco Maggesi
  2011-04-09 19:35     ` Dmitry Potapov
  2011-04-09 22:41     ` Matthieu Moy
  0 siblings, 2 replies; 13+ messages in thread
From: Marco Maggesi @ 2011-04-09 19:15 UTC (permalink / raw)
  To: git

Hi Chris and Peff,

2011/4/8 Jeff King <peff@peff.net>:
> But if you are just using the server as a distribution point for a
> single repository, it can be much simpler. For example, if you always
> just want to push and overwrite what is on the server (i.e., like a
> mirror), you can just use plain rsync outside of git. To avoid mirror
> lag, you do want to update the objects before the refs. So this:
>
>  LOCAL=/path/to/repo.git
>  REMOTE=server:path/to/repo.git
>  rsync -a $LOCAL/objects/ $REMOTE/objects/
>  rsync -a $LOCAL $REMOTE
>
> would work. And then expose repo.git on the server via http or ftp, and
> clients can clone directly from it.

this is the solution I was looking for (but I where not sure that it worked).

> You didn't list your reasons, so I'll assume they're good. But note that
> you don't need to be the administrator to accept a git push. You can
> build it as a regular user, and have git connect over ssh and run the
> server side.

Well, the server is a very old machine and I didn't find easy to
compile git on it because of many missing dependencies (but I didn't
try very hard either).  A better solution would be to upgrade the
server.  But your solution is perfect meanwhile.

Thank you,
Marco

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: New to git
  2011-04-08 19:43 New " Marco Maggesi
@ 2011-04-08 20:10 ` Jeff King
  2011-04-09 19:15   ` Marco Maggesi
  0 siblings, 1 reply; 13+ messages in thread
From: Jeff King @ 2011-04-08 20:10 UTC (permalink / raw)
  To: Marco Maggesi; +Cc: git

On Fri, Apr 08, 2011 at 09:43:09PM +0200, Marco Maggesi wrote:

> Now I would like to setup a repository on a server and use it as a
> central point of distribution for a few other computers.
> As far as I can understand, the default mechanism for push / pull
> requires that git is installed on every machine, including the server.

Yes, it's the default, but there are other mechanisms that don't require
server support. For example, rsync, and dumb http and ftp support.
They're not as efficient, but they do work.

For pushing, they are not as convenient. The dumb http push support goes
over DAV, so you must have a DAV server set up. Similarly, the rsync
support does not (as far as I know) do rsync-over-ssh, but expects to
connect to the rsync daemon directly.

But if you are just using the server as a distribution point for a
single repository, it can be much simpler. For example, if you always
just want to push and overwrite what is on the server (i.e., like a
mirror), you can just use plain rsync outside of git. To avoid mirror
lag, you do want to update the objects before the refs. So this:

  LOCAL=/path/to/repo.git
  REMOTE=server:path/to/repo.git
  rsync -a $LOCAL/objects/ $REMOTE/objects/
  rsync -a $LOCAL $REMOTE

would work. And then expose repo.git on the server via http or ftp, and
clients can clone directly from it.

> My problem is that I can hardly install git on the server for several
> reasons that I will not explain here (also I'm not the administrator
> of the server).

You didn't list your reasons, so I'll assume they're good. But note that
you don't need to be the administrator to accept a git push. You can
build it as a regular user, and have git connect over ssh and run the
server side.

> For the moment I came only to the following idea: mount the remote
> repository via fuse-ssh and use the local installation of git to push
> / pull changes.
> Surely it is inefficient but I don't care too much (my repositories
> are small enough I think).
> Can you see other drawbacks of this solution?

That is inefficient, but I think it would work OK. If you are doing
that, though, you are probably better off just rsyncing the whole result
as I showed above. It's less inefficient and easier to set up (if you
have rsync on the server, of course).

-Peff

^ permalink raw reply	[flat|nested] 13+ messages in thread

* New to git
@ 2011-04-08 19:43 Marco Maggesi
  2011-04-08 20:10 ` Jeff King
  0 siblings, 1 reply; 13+ messages in thread
From: Marco Maggesi @ 2011-04-08 19:43 UTC (permalink / raw)
  To: git

Hi,
I'm considering to use git to track my sources.
So far I was able to use git on a single machine and play with its
basic features.

Now I would like to setup a repository on a server and use it as a
central point of distribution for a few other computers.
As far as I can understand, the default mechanism for push / pull
requires that git is installed on every machine, including the server.

My problem is that I can hardly install git on the server for several
reasons that I will not explain here (also I'm not the administrator
of the server).
So I am looking for other solutions.

For the moment I came only to the following idea: mount the remote
repository via fuse-ssh and use the local installation of git to push
/ pull changes.
Surely it is inefficient but I don't care too much (my repositories
are small enough I think).
Can you see other drawbacks of this solution?

Also I wonder if other kind of synchronizations are possible (rsync,
unison, ...).

Are there other obvious solutions that I'm missing?

Thanks,
Marco

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2011-04-09 22:41 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-08-27 19:43 new to git Kyle Rose
2007-08-27 20:11 ` J. Bruce Fields
2007-08-27 20:22 ` Andreas Ericsson
2007-08-27 20:36   ` Kyle Rose
2007-08-27 20:39   ` Junio C Hamano
2007-08-27 21:14     ` Andreas Ericsson
2007-09-05  5:56 ` Jan Hudec
2007-09-05  6:54 ` Junio C Hamano
2011-04-08 19:43 New " Marco Maggesi
2011-04-08 20:10 ` Jeff King
2011-04-09 19:15   ` Marco Maggesi
2011-04-09 19:35     ` Dmitry Potapov
2011-04-09 22:41     ` Matthieu Moy

Code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).