# Advice for "pseudo public" repository on a USB key for a single contributer project 3 messages from 2010-01-23 to 2010-01-24. Participants: Maxime Lévesque, Tay Ray Chuan, Wincent Colaiuta. Thread: https://gitlist.dev/t/22358 ## Maxime Lévesque, 2010-01-23 18:27 Subject: Advice for "pseudo public" repository on a USB key for a single contributer project Message-ID: <554f5f781001231027vd322045hf84e2a16208bcc9f@mail.gmail.com> URL: https://gitlist.dev/e/554f5f781001231027vd322045hf84e2a16208bcc9f%40mail.gmail.com ```   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 ``` ## Tay Ray Chuan, 2010-01-24 02:17 Subject: Re: Advice for "pseudo public" repository on a USB key for a single contributer project Message-ID: URL: https://gitlist.dev/e/be6fef0d1001231817s265dac68v646d71b688e0ed1e%40mail.gmail.com In-Reply-To: <554f5f781001231027vd322045hf84e2a16208bcc9f@mail.gmail.com> ``` Hi, 2010/1/24 Maxime Lévesque : >  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 ``` ## Wincent Colaiuta, 2010-01-24 10:21 Subject: Re: Advice for "pseudo public" repository on a USB key for a single contributer project Message-ID: <3CFFC525-266B-4E98-9A99-83316B22978C@wincent.com> URL: https://gitlist.dev/e/3CFFC525-266B-4E98-9A99-83316B22978C%40wincent.com In-Reply-To: ``` El 24/01/2010, a las 03:17, Tay Ray Chuan escribió: > Hi, > > 2010/1/24 Maxime Lévesque : >> 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 ```