How single branch of git must be uptodate?

1
  • forked fdroiddata[ 1 ]
  • created branch to edit and make merge
    requests[ 2 ]
  • code to create local copy on my device
    [ 225 mb ]:
    git clone https://gitlab.com/jindam.vani/metadata-fdroid.git --branch graphics_june272023 --single-branch
  • questions:
    • pull from fdroiddata git?
    • pull from fork of fdroiddata git?
    • sync fork with upstream & sync with
      branch graphics_june272023?
    • pull from fdroiddata git to branch graphics_june272023?
    • sync fork with upstream & make changes
      in branch graphics_june272023?
  • i cant download 225 mb everytime, so how
    do i reduce comsumption of data?

[ 1 ] F-Droid / Data · GitLab
[ 2 ] https://gitlab.com/jindam.vani/metadata-fdroid.git --branch graphics_june272023

regards,
jindam

P.S. hope will be excused for pinging @linsui @Licaon_Kter @hans

2
1 Like
3

Instead of git merge upstream/master I use git pull --rebase upstream master.

1 Like
4

@linsui

  • thanks for merging… Is it compulsory to install fdroidserver? If yes, i will try again…
  • cloned fdroiddata git. all i need to rebase my changes for upstream changes. if you are person accepting mrs, kindly let me know about accepting future mrs and fdroidserver installation…
  • i dont want to add this noise in closed mr…
5

Generally not. The CI can check your MR and you just need to make it happy. See more in CONTRIBUTING.md · master · F-Droid / Data · GitLab.

1 Like
6

git remote add upstream gives error: fatal: not a git repository (or any of the parent directories): .git

7

Yup, amended post :slight_smile:

8

few more questions, i want mr to be correct [ reduce burden as much as possible for mergers ]

  • change of .yml after commit [ made changes locally ], if meta.yml is changed on upstream, how should i update it to latest version on fork branch, make again changes before creating mr? ( mcedit metadata/… , git commit -a -m “describe my fix” and before git push origin )
9

Yes, edit, commit, push (or use the gitlab EDIT function via the web interface)

10

I dont have much experience with git, from Pro git v 2.1.104, page 103:

If you only ever rebase commits that have never left your own computer, you’ll be just fine. If you rebase commits that have been pushed, but that no one else has based commits from, you’ll also be fine. If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble, and the scorn of your teammates.

If you or a partner does find it necessary at some point, make sure everyone knows to run git pull–rebase to try to make the pain after it happens a little bit simpler.

11

Forget about it.

If you are not quite sure what you are doing and your team is ok with occassional merge commits, it is best to stay away from rebasing.

12

Yes and no, depends on your use, I’d guess it’s mostly for keeping a fork in sync and occasionally make a MR… this fits fdroid* repos, for your other needs it might not :person_shrugging:

13

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.