Skip to main content

Return to Answer

removed broken link, added working link
Source Link
edit approved Nov 3, 2018 at 19:35
itsmysterybox
edit approved Nov 3, 2018 at 19:35
itsmysterybox
  • 2.8k
  • 4
  • 22
  • 26

That depends on the size of your repository and how you forked it.

If it's quite a big repository you may have wanted to manage it in a special way (e.g. drop history). Basically, you can get differences between current and upstream versions, commit them and then cherry pick back to master.

Try reading this onethis one. It describes how to handle big Git repositories and how to upstream them with latest changes.

That depends on the size of your repository and how you forked it.

If it's quite a big repository you may have wanted to manage it in a special way (e.g. drop history). Basically you can get differences between current and upstream versions, commit them and then cherry pick back to master.

Try reading this one. It describes how to handle big Git repositories and how to upstream them with latest changes.

That depends on the size of your repository and how you forked it.

If it's quite a big repository you may have wanted to manage it in a special way (e.g. drop history). Basically, you can get differences between current and upstream versions, commit them and then cherry pick back to master.

Try reading this one. It describes how to handle big Git repositories and how to upstream them with latest changes.

Active reading.
Source Link
Peter Mortensen
Peter Mortensen
  • 31.3k
  • 22
  • 109
  • 132

That'sThat depends on the size of your reporepository and how you forked it. If

If it's quite a big repository you may have wanted to manage it in a special way  (e.g. drop history). Basically you can get differences between current and upstream versions, commit them and then cherry pick back to master. Try

Try reading this one. It describes how to handle big gitGit repositories and how to upstream them with latest changes.

That's depends on size of your repo and how you forked it. If it's quite a big repository you may have wanted to manage it in a special way(e.g. drop history). Basically you can get differences between current and upstream versions, commit them and then cherry pick back to master. Try reading this one. It describes how to handle big git repositories and how to upstream them with latest changes.

That depends on the size of your repository and how you forked it.

If it's quite a big repository you may have wanted to manage it in a special way  (e.g. drop history). Basically you can get differences between current and upstream versions, commit them and then cherry pick back to master.

Try reading this one. It describes how to handle big Git repositories and how to upstream them with latest changes.

Source Link
s0nicYouth
s0nicYouth
  • 490
  • 3
  • 16

That's depends on size of your repo and how you forked it. If it's quite a big repository you may have wanted to manage it in a special way(e.g. drop history). Basically you can get differences between current and upstream versions, commit them and then cherry pick back to master. Try reading this one. It describes how to handle big git repositories and how to upstream them with latest changes.