git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Wincent Colaiuta <win@wincent.com>
Date
Jan 24, 2010, 10:21 UTC
Message-ID
<3CFFC525-266B-4E98-9A99-83316B22978C@wincent.com>
In-Reply-To
<be6fef0d1001231817s265dac68v646d71b688e0ed1e@mail.gmail.com>
El 24/01/2010, a las 03:17, Tay Ray Chuan escribió:
Show 41 quoted lines
> 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

Previous: Tay Ray Chuan
Message 3 of 3 in “Advice for "pseudo public" repository on a USB key for a single contributer project”
  1. Maxime LévesqueJan 23, 2010
  2. Tay Ray ChuanJan 24, 2010
  3. Wincent ColaiutaJan 24, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.