… 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
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%
://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
%
nstead 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,
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
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:
> &
’ 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
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
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
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
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
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
12 matches
Mail list logo
