[git-users] Re: [Push solved, but pull?] (was: [and remote branch tracking])
On Sat, Apr 22, 2023 at 3:02 AM Uwe Brauer wrote: > So as you can see the git hashed was not copied. > So if I wished to use that repository and push via hg-git I cannot > because hg tells me that there are commits missing and when I pull, he > just pulls everything his way (that is converting git branches into > bookmarks) and so doubling the commits! It's not hg, it's hg-git. I presume you want to pull from a git repository, not from an hg repository. It should be possible to write a script that uses git-remote-hg to clone a hg repository and then leaves it ready for the hg-git plugin to be used on top of it. But I don't understand your use-case. If you want to use hg, then use hg-git, if you want to use git, then use git-remote-hg. You can use git-remote-hg to mirror a git repository and create an hg repository, but you need to keep using git-remote-hg to keep updating that mirror, if you do "hg pull" it would have to be from that mirror, not the original git repository, as that would use hg-git, not git-remote-hg. > I see two solutions here > > 1. Your scripts copies the git hashes. That would be simply great >because it would allow a round trip. Unfortunately, you told me, >that you, stopped the development. Looking at the code my understanding is that the hg-git plugin creates that gitnode information on-the-fly, it's not stored anywhere in the hg repository. So if you remove or disable that hg-git plugin, the information disappears. git-remote-hg does create an exact replica of the hg repository itself, so you can do a round trip. But it's not an hg plugin, so it doesn't provide that gitnode extra information. That's something only an hg plugin can do. I said I stopped development in the past, but I'm working on it again. > 2. I work on the converted repository, but then pull from the git >repository and then push the pull commits to the remote server. >However some questions > >1. If I create a hg named branch and I pull it, will it be > translated into a git branch. > >2. What happens if I use the evolve extensions (which hides > certain commits), would everything pulled, or would the hidden > be ignored (as say should be). I don't know. I would need to see an example. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s1ZGvphRdogya6nob61%2BR88wJrg8TGVhGuKb9FhPwK7cw%40mail.gmail.com.
Re: [git-users] after pulling from remote, move last commit into a new branch and push
On Sat, Apr 22, 2023 at 7:53 AM Uwe Brauer wrote: > I pulled for a remote server and obtained > > * commit b7007223bd7c99b9d92911c66411b2143a791ce4 (master) (origin/master, > origin/HEAD, master) > | Author: John Ciolfi > | Date: Mon Apr 10 16:05:31 2023 -0400 > | > | matlab and org mode example > | > > > So I wanted to create a new branch org-mode so that this commit should > be in the new branch and later add other commits to that branch. > > So I run > > git branch org-mode > git checkout master > git reset --hard HEAD~1 > git checkout org-mode > git push -u origin org-mode You pushed the "org-mode" branch, but you changed the "master" branch, and you didn't push it. > * commit b7007223bd7c99b9d92911c66411b2143a791ce4 (master) (origin/master, > origin/HEAD, master) > | Author: John Ciolfi > | Date: Mon Apr 10 16:05:31 2023 -0400 > | > | matlab and org mode example > | > > So commit b7000 belongs to master not to org-mode as I hoped, what did I > miss? You changed the "master" branch locally, but you didn't update it on the remote repository. -- Felipe Contreras -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/CAMP44s3na%2BUBthjPNSx2xuuUzDYkAWn-doHS-M8iAwZ9_7QQ1w%40mail.gmail.com.
Re: [git-users] Weird merge records
On Friday, April 28, 2023 at 2:19:07 PM UTC-7 Tassilo Horn wrote: Dan Stromberg writes: > I'm getting _many_ Merge records that look like: > Merge branch 'develop' of ghosthub.whatever.net:abcd-def/ghij-jk… > > ...and I don't know where they are coming from. > > The merge records do not appear to show up in 'git log -v'. I only see > them in Ghosthub pull requests (Ghosthub being like Github, but > private). "git log" shows the log of the currently checked out branch. Maybe the merge commits are in some other branch? Try "git log --graph". "git log --graph" only showed one such entry, and it was created by someone else. > I suspect the merge records may be coming from this small bit of shell > script I've been using to pull from the master repo into my personal > repo: > git fetch upstream > git checkout "$branch" > git config pull.rebase false > git pull upstream "$branch" > git push origin "$branch" > > Does that snippet look responsible? I don't know. If you just want to update your private clone with the changes your colleagues pushed to the company's central repository, then it looks at least strange. Why are two remotes "upstream" and "origin" involved? "origin" is my repo. "upstream" is the more official repo. My script actually removes my git repo (git repos, really) entirely, before doing the above listed steps. I mean, you pull from upstream and push to origin as if you were someone integrating changes from some upstream project into a company-owned fork or something like that... Yes. I just want to get all the recent changes from upstream (the repo for the team as a whole), and add them to origin (my individual repo). Otherwise, origin keeps getting more and more stale. > If yes, how might I change it to stop creating all those merge > records? If no, any guesses what else might be causing it? Merges are unavoidable when integrating the work of people working in parallel. However, if you have set merge.ff to false, then every merge will create a merge commit even though it could be a "fast-forward" (see "man 7 gitglossary"). I believe my merge.ff is set to nothing, so false: $ git config merge.ff below cmd output started 2023 Mon May 01 08:22:13 AM PDT above cmd output done2023 Mon May 01 08:22:13 AM PDT I'll try setting it true for a while. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/d527bc01-d98a-4039-b995-4f15d30314cdn%40googlegroups.com.
Re: [git-users] Fast method to get a range diff that excludes merges
Reviving this thread, since I never quite got to my solution. Here's an interesting tool I found which attempts to solve this problem: https://git.sr.ht/~nhaehnle/diff-modulo-base However it's designed more for rebases, and it doesn't seem to produce the correct (where correct === what GitHub would show) output when looking at two commits with a merge in between. - Sam On Wednesday, 22 February 2023 at 04:58:46 UTC-8 philip...@iee.email wrote: > further example courtesy of Microsoft ... " Git history simplification can > be a confusing beast. " > > https://learn.microsoft.com/en-us/azure/devops/repos/git/git-log-history-simplification?view=azure-devops > > (ignore those '>' vs '>' html errors in the git code examples ;-) > On Wednesday, February 22, 2023 at 12:23:50 PM UTC Philip Oakley wrote: > >> I haven't tried to follow that example properly yet.. >> >> However one other thing to look at is the "History Simplification" that >> includes parent re-writing that's in the rev-list-options.txt file and then >> included in a number of man pages (log, show, short-log,..). There are >> some slippery concepts in there, often context dependent! >> >> https://git-scm.com/docs/git-log#_history_simplification >> >> On Wednesday, February 22, 2023 at 5:00:51 AM UTC s...@codeapprove.com >> wrote: >> >>> Thank you both for getting back to me. The discussion in the docs about >>> flattening was really interesting! I should note that the git clone / git >>> log command pair I provided gives me almost exactly what I want, but I need >>> to combine the diffs. It seems to contain the correct changes, and the >>> speed is pretty good too. >>> >>> Let me give an example of the situation I am optimizing for. I apologize >>> in advance I am going to use GitHub terms which I know are not pure git, >>> but in the end my question is a git question. >>> >>> Say you're a developer working in a many-developer repository. Here's >>> the sequence: >>> >>>- On Day 0 you check out "main" and create "my-topic-branch". You >>>add commits A, B, C, D to that branch. >>>- Now you open a pull request on GitHub asking to merge your branch >>>"my-topic-branch" into "master". >>>- You see a collaborator has landed a change to "main" since you >>>started. So you do "git fetch origin main && git merge main" and make a >>>merge commit in your branch. >>>- Then you add three more commits E, F, G on top of that and push >>>your branch again. So you have: A, B, C, D, (merge main), E, F, G. >>>- A coworker has already looked at commits A, B, C and wants to see >>>what you've done then. So they ask GitHub to show the diff from commits >>> D >>>through G (including the merge). >>> >>> When you do this, GitHub does something which (to me, anyway) is pretty >>> magical. You are shown only the changes that you committed to your branch >>> in D, E, F, and G. Changes which you merged in, which may or may not >>> involve the files in your Pull Request, are not shown at all since they're >>> not "yours". >>> >>> Here's a public example showing a team using this pattern. This one has >>> multiple merges, so I may need to find a cleaner example but hopefully this >>> makes sense. >>> >>>- Consider this PR: >>>https://github.com/firebase/firebase-tools/pull/5478/files >>> - This is the full diff (according to GitHub) and we can see >>> exactly one added line in CHANGELOG.md >>>- Here's a merge commit: >>> >>> https://github.com/firebase/firebase-tools/pull/5478/commits/ebce28ceb799f721d36b986705c54cbcd597a27a >>> - We can see that on the base branch, "master", a line was added >>> to the *end* of the CHANGELOG.md file. There is no such addition >>> displayed in the full diff. >>>- Here's a "magic" diff where I selected three commits (before >>>merge, merge, and after merge): >>> >>> https://github.com/firebase/firebase-tools/pull/5478/files/28b8a72561b266a2086059c0d9840ab25f03d8ae..b2d89ebd67e3f8c17c4c607c630c18096303096b >>> - We can see that the changes from the merge commit are not shown >>> as additions! But they are present as context lines. >>> >>> I need to find a sequence of git commands to produce the same exact diff >>> that GitHub produces (and ideally do it very quickly even in a large >>> repository) and I just can't figure it out. >>> >>> Thanks, >>> Sam >>> >>> >>> >>> >>> On Tuesday, 21 February 2023 at 14:12:48 UTC-8 philip...@iee.email wrote: >>> This may also be an issue of the History Simplification process and / or the 'flattening' processes for history linearisation and rebases. The flattening is a known phenomena and was currently being mentioned on the Git List, so I have noted this there. [1] https://lore.kernel.org/git/a856dd16-9876-509b...@iee.email/
