0

This is the structure of two separate Repos- Foo and Bar:

Repo[Foo]

  • [branch]Foo1
  • [branch]Foo2

Repo [Bar]

  • [branch] Bar1
  • [branch] Bar2

I wanted to add Bar/Bar2 as a branch-"Foo3" in Repo Foo. And consequently push any changes/commits made in Bar/Bar2 into Foo3 whenever I wanted to.

I did the following: (In the Foo repo dir)

git remote add Bar ../Bar
git remote update
git checkout Foo3
git merge --allow-unrelated-histories Bar/Bar2
git push --set-upstream origin Foo3

Later I added some files in Bar/Bar2, and did a git merge and git push. But what I'm seeing on the terminal is "Everything up-to-date", and the new files aren't reflected in Foo/Foo3. I have referred this question that has done this

RyomenSukuna
  • 63
  • 8
  • 1
    A repository is a kind of container. What it contains are *commits*. *Branch names*, within the repository, are simply ways to locate specific commits. If you make a separate repository, this separate repository is a container for commits. You can put the same commits into it, or different commits. The second repository has its own branch names, which locate commits in the second repository. Folder structures are not relevant: each branch name merely locates *one commit* in the given repository. – torek Jun 01 '21 at 06:11
  • 1
    Note that adding commits to one container (one repo) has no effect on any other container. You can, however, connect two containers to each other—for the duration of one connection, i.e., one `git fetch` or `git push`—and *transfer commits* from one repository to another. This allows the repository that lacks some commit(s) to get those commit(s) from the repository that has the commits. That's what fetch and push are about: obtaining commits. – torek Jun 01 '21 at 06:13
  • 1
    In the end, everything is really all about the *commits*. Folders don't matter, only *commits* matter. – torek Jun 01 '21 at 06:13
  • Thank you for the explanation! If I can reframe my issue, I made additional commits in Bar/Bar2, but after doing a git push to Foo/Foo3, I'm getting a "everything is up-to-date", with none of the additional commits being seen in Foo/Foo3. Does this mean that it does not recognise the new commits as "commits"? – RyomenSukuna Jun 01 '21 at 06:33
  • Well, now we get into how Git *finds* commits: `git push` has your Git call up some other Git, so as to send commits. The other Git has some branch name(s) and/or other names (tag names, whatever) that find some commits, and has some commits. Your Git offers the Git you tell it to offer, by hash ID. Their Git either *has* the commit and says "no thanks I already have it" or "I don't have that one, gimme!" (Git is greedy for new commits!). Your Git is then obligated to offer the parent(s) of the new-to-them commit; repeat until they have all the commits, or you've run out of commits. **Then**: – torek Jun 01 '21 at 06:45
  • Having sent commits or not sent commits, your Git asks (plain `git push`) or commands (`git push --force` or similar) that their Git should set some of *their* names (branch names, tags names, whatever) to remember particular commit hash IDs. They either say "ok I did that" or "no I won't do that", or—in some cases—"that's where it is now". – torek Jun 01 '21 at 06:46
  • Suppose, then, that you run `git push` and your Git offers commit `a123456`. This commit is new to the other Git. They take it; your Git offers its parent, `a000000` or whatever, and they say "no thanks, I already have that one". This finishes the commit-sending process. Then your Git says: "now I would like you, other Git, to set your branch name `dev` to `a123456`." They say OK; your Git says that you successfully pushed to their `dev`. – torek Jun 01 '21 at 06:47
  • If you now *repeat this same command*, `git push :dev` or similar, your Git offers `a123456` and they say "no thanks, already have that one"; your Git says "please set your `dev` to `a123456`" and they say "it already is" and all is done. Your Git says *everything up to date*. – torek Jun 01 '21 at 06:48
  • So, if you're getting *everything up to date*, look at which hash ID you are having your Git offer, and what name you are asking the other Git to set. `git push ` is how you have your Git send. The URL or remote specifies how to call up the other Git; the refspec, which can be `:` or simply ``, says what to send and what to set. The simple `` form means `:`: your Git parses the left side name to get a hash ID, sends that commit, and asks their Git to set the *same name* in their Git. – torek Jun 01 '21 at 06:51
  • I loved the explanation! Thank you for taking your time to explain it all :) It was a good start to read and dig deep – RyomenSukuna Jun 04 '21 at 04:35

0 Answers0