Advice for "pseudo public" repository on a USB key for a single contributer project

Advice for "pseudo public" repository on a USB key for a single contributer project

[Maxime Lévesque]

   Hello Gitsers,

  I'm a Git newbee, and I have started a project, with a few month's of code
 in
 a local git repository.

 I am the only develloper/contributor to this repo. I have a clone of my
 repository
 on a USB key, for back up purposes. Once in a while I work on another
 machine
 where I have cloned a repo from the USB key.

 Since there are no servers involved, I have used pull command
 to move my 'HEAD' around :

 after working on machine1 I do :

   commit to machine1Repo
   machine1Repo  --pull--> USBKeyRepo


 when I switch on machine2 I start by bringing it up to date from the key :


   machine2Repo  <--pull-- USBKeyRepo

  and when I'm finished  :

  commit to machine2Repo
  machine1Repo  --pull--> USBKeyRepo

  So far I have done all of this using the master branch,
 and things don'g always go smoothly I sometimes have
 conflicts that don't seem logical, since I'm the only
 contrbutor, I should never need to do merges.

  From what I have read my USBKey repo is like a public repo,
 so I have tried using a bare repo, because since I never work
 directly on the usb key, the souces on this repo are just
 adding unnecessary complexity. So far I had no success,
 because the pull command doesn't recognize my bare repo,
 it seems that bare repos must me accessed via a daemon process.

  I suspect that I'm probably not using Git correctly (or optimally),
 which is why I am inquiring here.

 Should I be using a dedicated branch
 on each machine (as if I were two contributors) ?
 Is it wise to use pulls instead of pushes ?
 Should I be using a bare repo on my key ?


  Any insight would be appreciated.

 Thank you all

Re: Advice for "pseudo public" repository on a USB key for a single contributer project

[Tay Ray Chuan]

Hi,

2010/1/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>  Since there are no servers involved, I have used pull command
>  to move my 'HEAD' around :
>
>  after working on machine1 I do :
>
>    commit to machine1Repo
>    machine1Repo  --pull--> USBKeyRepo

I think you mean "push", since what you want is to make the changes in
machine1Repo available in USBKeyRepo.

>  when I switch on machine2 I start by bringing it up to date from the key :
>
>
>    machine2Repo  <--pull-- USBKeyRepo
>
>   and when I'm finished  :
>
>   commit to machine2Repo
>   machine1Repo  --pull--> USBKeyRepo

I think you mean "push" here and s/machine1/machine2/ too, so that would read

  machine2Repo --push--> USBKeyRepo

When you make changes on machine2 and go back to machine1, you need to
fetch/pull in your changes, just like you do for machine2Repo:

  machine1Repo  <--pull-- USBKeyRepo

>   From what I have read my USBKey repo is like a public repo,
>  so I have tried using a bare repo, because since I never work
>  directly on the usb key, the souces on this repo are just
>  adding unnecessary complexity. So far I had no success,
>  because the pull command doesn't recognize my bare repo,
>  it seems that bare repos must me accessed via a daemon process.

What's your config?

Assuming you use master everywhere, I think you could use this in your config:

  [remote "USBKeyRepo"]
    url = /path/to/repo
    fetch = master
  [branch "master"]
    remote = USBKeyRepo
    merge = master

>  Is it wise to use pulls instead of pushes ?

See above. You can't use one "instead of" another - they serve
different purposes and don't replace one another.

>  Should I be using a bare repo on my key ?

Definitely, or else you would have a working tree in that repo too but
it never gets updated - not to mention all the warnings git would
show.

-- 
Cheers,
Ray Chuan

Re: Advice for "pseudo public" repository on a USB key for a single contributer project

[Wincent Colaiuta]

El 24/01/2010, a las 03:17, Tay Ray Chuan escribió:

> Hi,
>
> 2010/1/24 Maxime Lévesque <maxime.levesque@gmail.com>:
>>  Since there are no servers involved, I have used pull command
>>  to move my 'HEAD' around :
>>
>>  after working on machine1 I do :
>>
>>    commit to machine1Repo
>>    machine1Repo  --pull--> USBKeyRepo
>
> I think you mean "push", since what you want is to make the changes in
> machine1Repo available in USBKeyRepo.
>
>>  when I switch on machine2 I start by bringing it up to date from  
>> the key :
>>
>>
>>    machine2Repo  <--pull-- USBKeyRepo
>>
>>   and when I'm finished  :
>>
>>   commit to machine2Repo
>>   machine1Repo  --pull--> USBKeyRepo
>
> I think you mean "push" here and s/machine1/machine2/ too, so that  
> would read
>
>  machine2Repo --push--> USBKeyRepo
>
> When you make changes on machine2 and go back to machine1, you need to
> fetch/pull in your changes, just like you do for machine2Repo:
>
>  machine1Repo  <--pull-- USBKeyRepo
>
>>   From what I have read my USBKey repo is like a public repo,
>>  so I have tried using a bare repo, because since I never work
>>  directly on the usb key, the souces on this repo are just
>>  adding unnecessary complexity. So far I had no success,
>>  because the pull command doesn't recognize my bare repo,
>>  it seems that bare repos must me accessed via a daemon process.

For this kind of workflow I generally use pull in both directions.  
Push works only if it results in fast-forward merges in both  
directions, and if you are a little forgetful like me it's fairly easy  
to sooner or later forget to update one of the repos and end up making  
commits in both of them, leading to a situation in which at least one  
of the merges would have to be a non-fast-forward.

If you always pull, you are at least working in a non-bare repo at  
that point and you can choose to either (non-fast-forward) merge or  
rebase.

Unless you are really disciplined about synchronizing the repos before  
you ever start any work, then I think "pull" in both directions is the  
way to go.

Cheers,
Wincent