[git-users] Re: Your branch is ahead of 'origin/main' by … commits: how to 'reset' things?
… although, my GitHub repo was synchronised with the FreeBSD repo at the outset, so: - I don't understand how the pull from GitHub had an end result that differed from `pull freebsd main`. -- 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/4dbf588c-94a7-4473-92b2-ec1b2a26dee6n%40googlegroups.com.
[git-users] Re: Your branch is ahead of 'origin/main' by … commits: how to 'reset' things?
I was over-thinking. Resolved with a simple pull. % git -C /usr/src pull freebsd main >From https://git.freebsd.org/src * branch main -> FETCH_HEAD Already up to date. % git -C /usr/src pull remote: Enumerating objects: 118, done. remote: Counting objects: 100% (92/92), done. remote: Compressing objects: 100% (8/8), done. remote: Total 118 (delta 84), reused 88 (delta 84), pack-reused 26 Receiving objects: 100% (118/118), 29.13 KiB | 233.00 KiB/s, done. Resolving deltas: 100% (92/92), completed with 16 local objects. >From https://github.com/grahamperrin/freebsd-src 6062d9faf23f..bb5d6d14d81b main -> origin/main f2c8a778ca94..37e2a11f25f4 bug-261349 -> origin/bug-261349 eb6e41c32e5b..2a5324685d3a stable/12 -> origin/stable/12 Already up to date. % git -C /usr/src status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean % -- 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/274a6556-635e-421e-b9f0-ec13412cae4an%40googlegroups.com.
[git-users] Your branch is ahead of 'origin/main' by … commits: how to 'reset' things?
Below: without knowing what the 123 commits are, I'm *certain* that none of them should be pushed. In simple terms: I want my local copy of main to be no different from what's remote; for git-status(1) <https://git-scm.com/docs/git-status> to not report that something's to be pushed. % date ; gh repo sync grahamperrin/freebsd-src Mon 12 Jun 2023 02:21:09 BST ✓ Synced the "grahamperrin:main" branch from "freebsd:main" % git -C /usr/src pull --ff-only freebsd main >From https://git.freebsd.org/src * branch main -> FETCH_HEAD Already up to date. % git -C /usr/src status On branch main Your branch is ahead of 'origin/main' by 123 commits. (use "git push" to publish your local commits) It took 2.09 seconds to enumerate untracked files. See 'git help status' for information on how to improve this. nothing to commit, working tree clean % git -C /usr/src config --list | sort branch.bug-261349.merge=refs/heads/bug-261349 branch.bug-261349.remote=origin branch.main.merge=refs/heads/main branch.main.remote=origin branch.patch-4.merge=refs/heads/patch-4 branch.patch-4.remote=origin branch.pkg-stage.merge=refs/heads/pkg-stage branch.pkg-stage.remote=origin branch.prefer-ee.merge=refs/heads/prefer-ee branch.prefer-ee.remote=origin branch.releng/13.1.merge=refs/heads/releng/13.1 branch.releng/13.1.remote=origin branch.releng/13.2.merge=refs/heads/releng/13.2 branch.releng/13.2.remote=origin branch.stable/12.merge=refs/heads/stable/12 branch.stable/12.remote=origin branch.stable/13.merge=refs/heads/stable/13 branch.stable/13.remote=origin core.bare=false core.filemode=true core.logallrefupdates=true core.repositoryformatversion=0 remote.freebsd.fetch=+refs/heads/*:refs/remotes/freebsd/* remote.freebsd.fetch=+refs/notes/*:refs/notes/* remote.freebsd.pushurl=g...@repo.freebsd.org:src.git remote.freebsd.url=https://git.freebsd.org/src.git remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* remote.origin.gh-resolved=base remote.origin.url=https://github.com/grahamperrin/freebsd-src.git remote.upstream.fetch=+refs/heads/main:refs/remotes/upstream/main remote.upstream.url=https://github.com/freebsd/freebsd-src.git safe.directory= safe.directory= safe.directory=/usr/doc user.email=grahamper...@freebsd.org user.name=Graham Perrin % -- 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/142f1cd1-d183-4e78-a23a-ed6f43d8b6bbn%40googlegroups.com.
Re: [git-users] how to get list of tags on commits merged to branch X between tags Y and Z
Thanks again Konstantin. In my original message, I said "I want a list of tags attached to commits that were merged to X between Y and Z". But in my second message I said it wrongly - "list of tags produced by your command includes ones that do not belong to branch X". Instead I should have said "list of tags produced by your command includes ones that are attached to commits that do not belong to branch X". Does that make more sense? Thanks, Graham On Friday, December 16, 2022 at 10:16:43 PM UTC+11 Konstantin Khomoutov wrote: > On Thu, Dec 15, 2022 at 02:08:22PM -0800, Graham Menhennitt wrote: > > [...] > >> Note that the branches are irrelevant for traversing. You can use > branches > >> to refer to commits, but any way to refer to them would do; the > traversal > >> process itself is only concerned with commits. > [...] > > Unfortunately, that doesn't quite match my requirements - as you say > above, > > it doesn't filter by branches. So the list of tags produced by your > command > > includes ones that do not belong to branch X. I'll try to filter it > somehow. > > While it appears the snippet I have come up with actually helped, it would > reiterate that tags in Git are never "on" any branch. You can attach tags > to > any "objects" stored in a Git repository: to blobs (a blob is the data of a > particular version of a particular data), trees (they keep names of the > blobs > serving as directories on filesystems), and commits. Branches are somewhat > immaterial in this regard: when you do > > git tag mytag master > > you do not attach a tag "mytag" to the branch "master" or to a commit on > branch "master"; instead, Git takes than name "master", looks it up, > figures > out it's the name of a branch, _resolves_ it to its tip commit and finally > attaches the tag "mytag" to that commit. You could then go on and remove > the > branch "master" completely, and that would do nothing to the tag. > > When you work with Git, it really helps to stop thinking much about > branches > and start thinking of a graph of commits which refer one another and > symbilic > references to some of these commits. These references are branches and > tags. > > See, even a sort of obvious > > git log master > > does not tell Git to traverse commits on the master branch, it tells Git to > start with the tip commit on the branch "master" and traverse the history > reachable from that commit. Every commit in that subgraph may be reachable > from any number of branches - not only "master" - and any number of tags. > Reachable, bot not "belonging to" or "being on". That's actually a crucial > concept to absorb to make reasoning about Git much easier. > > -- 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/d64f5be8-5736-46b0-b093-481d075331f1n%40googlegroups.com.
Re: [git-users] how to get list of tags on commits merged to branch X between tags Y and Z
Thanks very much for replying, Konstantin. Unfortunately, that doesn't quite match my requirements - as you say above, it doesn't filter by branches. So the list of tags produced by your command includes ones that do not belong to branch X. I'll try to filter it somehow. Thanks, Graham On Friday, December 16, 2022 at 5:40:51 AM UTC+11 Konstantin Khomoutov wrote: > On Tue, Dec 13, 2022 at 08:47:49PM -0800, Graham Menhennitt wrote: > > > Our development workflow consists of: > > > > Developer: > > > > - creates private branch off project’s ‘develop’ branch > > - develops feature or fixes bug on private branch > > - merges private branch to ‘develop’ branch > > - creates tag on merge commit identifying feature/bug > > > > Project lead: > > > > - merges project’s ‘develop’ branch to project’s ‘release’ branch > > - builds release from ‘release’ branch > > - creates tag on ‘release’ branch to identify release > > > > We want to be able to give our test team a list of the features/bug > fixes > > in the new release. As such, I want to get list of tags on commits that > > have been merged to the project’s ‘release’ branch. I want it restricted > to > > tags contained in the new release tag, but not contained in the previous > > release tag. I want the list to exclude tags on other projects i.e. that > > have not been merged to this project’s ‘release’ branch. > > > > So, if this project’s ‘release’ branch is X. The previous release is Y > and > > the new release is Z. I want a list of tags attached to commits that > were > > merged to X between Y and Z. > > The closest thing I've been able to come up with is > > git rev-list --pretty='format:%D' Z ^Y | grep ^tag: > > Which basically means: > > * Traverse the subgraph of the repository's commits reachable from commit > tagged by Z... > > * ...But exclude any commits also reachable from Y, and... > > * For those commits which are referenced (have a branch or a tag pointing > at them, or both, or multiple) output them as well. > > * The output is then filtered to contain only the tags. > > > Note that the branches are irrelevant for traversing. You can use branches > to > refer to commits, but any way to refer to them would do; the traversal > process > itself is only concerned with commits. > > > You might need to further refine the incantation but this should be a > start. > > -- 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/f4172e61-a0d1-4172-96ef-ad085129d8c4n%40googlegroups.com.
Re: [git-users] how to get list of tags on commits merged to branch X between tags Y and Z [solved]
Thank you, Konstantin. That appears to do exactly what I need. Thanks, Graham On Friday, December 16, 2022 at 5:40:51 AM UTC+11 Konstantin Khomoutov wrote: > On Tue, Dec 13, 2022 at 08:47:49PM -0800, Graham Menhennitt wrote: > > > Our development workflow consists of: > > > > Developer: > > > > - creates private branch off project’s ‘develop’ branch > > - develops feature or fixes bug on private branch > > - merges private branch to ‘develop’ branch > > - creates tag on merge commit identifying feature/bug > > > > Project lead: > > > > - merges project’s ‘develop’ branch to project’s ‘release’ branch > > - builds release from ‘release’ branch > > - creates tag on ‘release’ branch to identify release > > > > We want to be able to give our test team a list of the features/bug > fixes > > in the new release. As such, I want to get list of tags on commits that > > have been merged to the project’s ‘release’ branch. I want it restricted > to > > tags contained in the new release tag, but not contained in the previous > > release tag. I want the list to exclude tags on other projects i.e. that > > have not been merged to this project’s ‘release’ branch. > > > > So, if this project’s ‘release’ branch is X. The previous release is Y > and > > the new release is Z. I want a list of tags attached to commits that > were > > merged to X between Y and Z. > > The closest thing I've been able to come up with is > > git rev-list --pretty='format:%D' Z ^Y | grep ^tag: > > Which basically means: > > * Traverse the subgraph of the repository's commits reachable from commit > tagged by Z... > > * ...But exclude any commits also reachable from Y, and... > > * For those commits which are referenced (have a branch or a tag pointing > at them, or both, or multiple) output them as well. > > * The output is then filtered to contain only the tags. > > > Note that the branches are irrelevant for traversing. You can use branches > to > refer to commits, but any way to refer to them would do; the traversal > process > itself is only concerned with commits. > > > You might need to further refine the incantation but this should be a > start. > > -- 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/fd27c629-aaad-4edd-a104-2cbc96c6964fn%40googlegroups.com.
[git-users] how to get list of tags on commits merged to branch X between tags Y and Z
Hello gitters, Our development workflow consists of: Developer: - creates private branch off project’s ‘develop’ branch - develops feature or fixes bug on private branch - merges private branch to ‘develop’ branch - creates tag on merge commit identifying feature/bug Project lead: - merges project’s ‘develop’ branch to project’s ‘release’ branch - builds release from ‘release’ branch - creates tag on ‘release’ branch to identify release We want to be able to give our test team a list of the features/bug fixes in the new release. As such, I want to get list of tags on commits that have been merged to the project’s ‘release’ branch. I want it restricted to tags contained in the new release tag, but not contained in the previous release tag. I want the list to exclude tags on other projects i.e. that have not been merged to this project’s ‘release’ branch. So, if this project’s ‘release’ branch is X. The previous release is Y and the new release is Z. I want a list of tags attached to commits that were merged to X between Y and Z. Any clues, please? Thanks in advance for any help. Regards, Graham -- 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/fca01cba-9ab9-46c0-b9fa-211c816dfd6en%40googlegroups.com.
[git-users] Re: Bug? status --porcelain only quotes spaces in added files
On Tuesday, 24 July 2012 04:19:49 UTC-7, Thomas Ferris Nicolaisen wrote:
On Tuesday, July 24, 2012 12:29:22 AM UTC+2, Graham Jans wrote:
Consider this scenario:
$ touch a 1.txt
$ touch a 2.txt
$ git add a 1.txt
$ git status --porcelain
A a 1.txt
?? a 2.txt
Note that the added file is properly quoted to account for the space, but
the unadded file is not.
This makes these scenarios incredibly troublesome to parse with scripts,
etc. As well, this behaviour just seems inconsistent.
I am using *1.7.11.msysgit.0*.
Can someone suggest a next step or an easy shell-based bandaid for this
scenario?
Can you perhaps show us the part of the script where this is causing
problems? Perhaps some script-wizard here on the list can make it work for
you.
I imagine either of those lines could be parsed into 2 columns using some
clever regular expression (first column status, and the second column
filename), and then the second column can be eval'ed somehow into a string
where the quotes are dropped.
I'm using a fairly standard one-line 'add all' bit, like this:
git status --porcelain | egrep ^\? | awk '{print $2}' | xargs git add
Also, I have solved my present issue through brute force; I'm more
concerned at this point about the general inconsistent behavior here.
--
You received this message because you are subscribed to the Google Groups Git
for human beings group.
To view this discussion on the web visit
https://groups.google.com/d/msg/git-users/-/S3r__O815ooJ.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/git-users?hl=en.
Re: [git-users] New user gets lost driving the Git Bash
On Tuesday, 24 July 2012 00:46:44 UTC-7, Konstantin Khomoutov wrote: On Mon, Jul 23, 2012 at 04:13:50PM -0700, Jeffery Brewer wrote: Aha! Figured out that after installing on windows you don't go to a command line directly, you have to go through Start All Programs Git Git Bash which gives you a different kind of command line. [...] Note that you don't *have to* use Git bash: everything just works in the regular cmd.exe. Actually, the existence of Git bash is due to some parts of Git are written as Unix shell scripts so Git for Windows has to ship with a shell implementing POSIX semantics. There's no consensus in the Git for Windows community on what shell to use for interactive work with Git. I, for one, prefer cmd.exe as I tend to use the shell not only for Git. As Konstantin says, there's no consensus. However, I recommend using Git Bash, as it makes utilizing small script snippets etc. that you find around the net more accessible (because you don't have to translate them to windows-style, can just use them in the unix-style presented. As well, getting the various bits of Git Bash to work in cmd.exe requires choosing the correct options when installing; the installer has a big red warning here so most people choose not to do that. As well, the coloring doesn't work for me in cmd.exe. So all in all I recommend using Git Bash at least for learning. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/cf-PGK6z3AUJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
[git-users] Bug? status --porcelain only quotes spaces in added files
Consider this scenario: $ touch a 1.txt $ touch a 2.txt $ git add a 1.txt $ git status --porcelain A a 1.txt ?? a 2.txt Note that the added file is properly quoted to account for the space, but the unadded file is not. This makes these scenarios incredibly troublesome to parse with scripts, etc. As well, this behaviour just seems inconsistent. I am using *1.7.11.msysgit.0*. Can someone suggest a next step or an easy shell-based bandaid for this scenario? Thanks, Graham -- You received this message because you are subscribed to the Google Groups Git for human beings group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/lYaMSRkIfMYJ. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git-svn setup advice for newbie
Thanks Thomas Your videos were helpful. One of the doubts I had was the warnings about the difficulty of simultaneously interacting with a subversion master repository and multiple git repositories - which there are several different approaches to, including yours. Am I right to think that as long as I cannot write back from my git clone of the svn master to the svn master itself, and only need the ability to keep fetching from the svn master, most of the complications disappear? So that I can just treat the git clone of the master as one branch among others? Graham On 01/02/11 17:09, Thomas Ferris Nicolaisen wrote: Hi Graham, It sounds like you should just have a go at it :) I would first start off with learning some Git basics. Don't go into git-svn before you know Git a good bit. Quick intro: http://www.spheredev.org/wiki/Git_for_the_lazy Reference: http://progit.org/book/ Now, when you feel you're comfortable with the Git command line, start off with cloning the subversion project on your development host: git svn clone [url-to-project-in-svn] That should give you a git repository with a branch master. To update with newer changes from svn: git svn rebase That should get you started. Where you go from there with branches and so on I think you need to experiment a bit, or tell us a bit more specifically what you want to do. Just a small warning: Running different branches of development for different OS sounds like a poor approach, imho. If I were you, I would rather keep development in a single branch, and then do some kind of deployment step that copies in the OS-specific parts into being part of a deployable artifact. If you want a more extensive tutorial on how to work with Git and Subversion in parallel, check out this page http://www.tfnico.com/presentations/git-and-subversion. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] Re: git-svn setup advice for newbie
On 01/02/11 23:06, Thomas Ferris Nicolaisen wrote: Hi Graham, I think you're saying, that you don't need to do any git svn dcommit in your git-svn clone. That is correct. This sounds like the Git repo is a pure read only mirror of the Subversion project. Such a setup is quite straight-forward and won't give any problems. Good! However, as far as I understand, you want to do commits in the git repo, making a few differences compared to the state in subversion (so yes, like you say, it's a branch of the code in svn). In this case, the danger lies in the regular pain of branching: Over time as you do more commits on the git side, each git svn rebase will stack your git commits historically on top of the commits that come from the Subversion side. Over time, you'll get a large set of git-commits that have to be replayed on top of the subversion updates, and chances of getting conflicts will increase, making it more and more painful to keep the git repo in sync with the latest changes from subversion (this is the same problems you run into when trying to maintain two branches in parallel, I guess). I think your description is what I'm expecting. At the moment I'm working directly on the subversion checkout (no git involved), doing a daily svn update from the remote subversion, and resolving any conflicts with my local changes manually. Periodically if I think a set of local changes will be accepted into the remote trunk I create a set of patches for them and mail them off for vetting. If they're accepted the difference between my local checkout and the remote repository shrinks for a while. This is tedious (especially creating the patch files) but does work, and I was assuming I could carry on doing this while working with git. The new thing I need, which has pushed me towards git, is that management want me to develop two different versions of the application for evaluation, so I want to combine the above situation with managing two branches, and thought this would be easier with git. Plus I want to learn it anyway. So, I'm still wondering if you really want to do what you want to do :) Well, I hope so - does the above make more sense? Graham -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To post to this group, send email to git-us...@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
