Re: Git Basics Episode 1 GUI
On Fri, 4 Oct 2019 at 12:14, Philip Oakley wrote: > On 04/10/2019 08:19, Colin Agnew wrote: > > Could you confirm which GUI is featured in the first video? > > Please advise - thanks > Dunno, > > Do you have a web reference for the "Git Basics Episode 1" and then > which video you are watching? I guess, Colin's question meant to be this: What is the GUI presented in the "Git Basics Episode 1 " video [1] at 3min40sec? [1] https://git-scm.com/video/what-is-version-control Colin, I suggest next time you include all the necessary details, links, etc. to not to make anyone web search anything for you. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Suggestion: git clone should warn if repository has submodules
On Tue, 6 Aug 2019 at 16:04, Jason Sewall wrote: > > Submodules are great, and I used them at work. The problem is, people > wind up cloning my repos without --recursive and then nothing works > for them, because the submodules weren't populated and those > ultimately are needed to build my code. What you need is a simple document for your team that outlines the common Git workflow or README.md in root directory of your repositories with fat heading: ## Clone ``` git clone --recursive ... ``` A team in another company may require non-recursive clones by default and warnings from git may be quite annoying. Given the fact there is not one but may valid "my way"-s available, acceptable and supported by Git, I think, babysitting behaviour is not quite aligned with its philosophy, is it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: cherry-pick merge commit with log message populated
On 19-08-01 13:24:00, Junio C Hamano wrote: Mateusz Loskot writes: Is there any other way, without remembering to `git merge` with `--log`? "git config merge.log true"? That's sweet! Thank you Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Fingerprint=C081 EA1B 4AFB 7C19 38BA 9C88 928D 7C2A BB2A C1F2
cherry-pick merge commit with log message populated
Hi, When cherry-picking a merge with `cherry-pick -x -m 1 `, is it possible to populate the log message with (short) log of all commits that have been merged by the merge commit ? The only workaround to copy the log messages along with cherry-picked changes is to always merge copying all log messages of intermediate commits into merge commit message using `git merge --log feature1`. Is there any other way, without remembering to `git merge` with `--log`? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Handling text files encoded in little-endian UTF-16 with BOM
On Fri, 5 Jul 2019 at 18:25, Torsten Bögershausen wrote: > On Fri, Jul 05, 2019 at 01:35:13PM +0200, Mateusz Loskot wrote: > > > > Using git version 2.22.0.windows.1 > > > > I have a repository with number of .txt files encoded in > > little-endian UTF-16 with BOM. > > > > What are the best practice and recommended configuration to > > manage such files with Git to avoid unexpected re-encoding to > > UTF-8 or others? > > > > Currently, there is .gitattriuts with entries like > > > >resource/*.txt working-tree-encoding=UTF-16LE-BOM -text > > > > Despite that some of team members have noticed that the files > > occacionally get re-encoded to UTF-8. It is unknow what are > > actual steps leading to that. BTW, there a few Git clients > > in use: git in Git Bash, VSCode, Fork. > > If possible, I don't want to comment on this kind of > "sometimes something happens something on someones computer" thing. Perfectly understood. > A little bit more information could be helpful. If there was more, I'd have provided. > > What bothers me in the .gitattributes is this `-text` attribute. > > > > Is the use of `working-tree-encoding` and `-text` together a > > valid combination at all? > > Yes, it means that the content re-encoded between the repo and the working > tree, > (that is what you want) > And the "-text" means "leave the line endings" (LF or CRLF) as is, don't > convert them. That's quite a useful insight. I understood "-text" means content is not a text, but binary. > In that sense you can call that a legal combination, but may be not a > recommended one. Right. > > The documentation at https://git-scm.com/docs/gitattributes > > does not seem to touch on that. > > > > I'll appreciate any suggestions on those UTF-16LE-BOM files. > > > > My suggestion would be to use the "text" attribute: > resource/*.txt working-tree-encoding=UTF-16LE-BOM text > > And depending on your application: Do the resource files need a special line > ending ? I need CRLF. > The use either > resource/*.txt working-tree-encoding=UTF-16LE-BOM text eol=LF > or > resource/*.txt working-tree-encoding=UTF-16LE-BOM text eol=CRLF This is very helpful. Thanks! -- Mateusz Loskot, http://mateusz.loskot.net
Handling text files encoded in little-endian UTF-16 with BOM
Hi, Using git version 2.22.0.windows.1 I have a repository with number of .txt files encoded in little-endian UTF-16 with BOM. What are the best practice and recommended configuration to manage such files with Git to avoid unexpected re-encoding to UTF-8 or others? Currently, there is .gitattriuts with entries like resource/*.txt working-tree-encoding=UTF-16LE-BOM -text Despite that some of team members have noticed that the files occacionally get re-encoded to UTF-8. It is unknow what are actual steps leading to that. BTW, there a few Git clients in use: git in Git Bash, VSCode, Fork. What bothers me in the .gitattributes is this `-text` attribute. Is the use of `working-tree-encoding` and `-text` together a valid combination at all? The documentation at https://git-scm.com/docs/gitattributes does not seem to touch on that. I'll appreciate any suggestions on those UTF-16LE-BOM files. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: [Git 2.22.0] git submodule foreach now requires quoted command?
On Mon, 1 Jul 2019 at 14:33, Johannes Schindelin wrote: > On Sat, 29 Jun 2019, Mateusz Loskot wrote: > > > I have a script which I have used for long time, with numerous > > git commands and one of commands is this trivial: > > > > git submodule foreach --recursive git clean -ffd > > > > I updated to Git 2.22.0 and noticed Git started to complain: > > > > ``` > > $ cd /d/boost > > $ git submodule foreach --recursive git clean -ffd > > Entering 'libs/accumulators' > > error: unknown switch `f' > > usage: git submodule--helper foreach [--quiet] [--recursive] [--] > > > > -q, --quiet Suppress output of entering each submodule command > > --recursive Recurse into nested submodules > > > > fatal: run_command returned non-zero status while recursing in the > > nested submodules of libs/accumulators > > ``` > > > > Apparently, I have to quote the command to avoid the error > > > > git submodule foreach --recursive 'git clean -ffd' > > > > Is this expected behaviour? > > Could anyone help me to understand what has changed? > > I can't find any related changes in the release notes. > > Probably fixed in https://github.com/gitgitgadget/git/pull/263 Johannes, Thank you for the pointer. It does seem related indeed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
[Git 2.22.0] git submodule foreach now requires quoted command?
Hi, I have a script which I have used for long time, with numerous git commands and one of commands is this trivial: git submodule foreach --recursive git clean -ffd I updated to Git 2.22.0 and noticed Git started to complain: ``` $ cd /d/boost $ git submodule foreach --recursive git clean -ffd Entering 'libs/accumulators' error: unknown switch `f' usage: git submodule--helper foreach [--quiet] [--recursive] [--] -q, --quiet Suppress output of entering each submodule command --recursive Recurse into nested submodules fatal: run_command returned non-zero status while recursing in the nested submodules of libs/accumulators ``` Apparently, I have to quote the command to avoid the error git submodule foreach --recursive 'git clean -ffd' Is this expected behaviour? Could anyone help me to understand what has changed? I can't find any related changes in the release notes. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Repositories stucture
On Sat, 13 Apr 2019 at 07:32, Mgr Georg Black wrote: > People from big company(BC) wanna to have only one big repository with all > code in it. BC wanna have to folders structure for language and projects. But > for us is that idea bit uncomfortable because we rather have more > repositories by language, maybe by project (in BC folders). It's useless for > us that every developer on specific project and language have all other > sources in their local repository. Is it the solvable? Show the BC how Boost libraries structure the repositories with submodules There is single superproject https://github.com/boostorg/boost/ and large number of libraries (each with dedicated team of developers). Periodically, everything is synchronised into the superproject repo and prepared for release in single bundle. Then, you may want to learn about submodule and subtree features of Git, and choose the one that suits best your workflow(s) to implement your repositories structure. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: "Submodule registered for path" output with config aliases mixed in
On Thu, 21 Feb 2019 at 05:17, Jeff King wrote: > On Thu, Feb 21, 2019 at 10:47:45AM +0700, Duy Nguyen wrote: > > > > > I managed to identify where that garbage injections come from: > > > > from git aliases I've got configured [1] > > > > > > > > Could anyone explain what is happening here? > > > > Is there anything wrong with my ~/.gitconfig [1] ? > > > > > > I see the right behavior on my system (Debian amd64/sid) with > > > 2.21.0.rc0.258.g878e2cd30e and with master. I've built with ASan and > > > don't see any memory warnings on my system. > > > > I ran valgrind yesterday (gentoo amd64) and didn't find the problem > > either even though it clearly looked like some dangling pointers. I > > also audited this code and couldn't find anything obviously wrong. My > > only suspicion is maybe some strange getenv() behavior on Windows > > (_if_ the super prefix is used, but I can't see how...) and that's > > just a dead end for me. > > Certainly we fixed a bunch of getenv() problems in the upcoming 2.21 > release, including 8aac69038f (get_super_prefix(): copy getenv() result, > 2019-01-11). > > Mateusz, can you try with the one of the v2.21.0 release candidates (or > the current tip of "master")? Jeff, I have just tried git version 2.21.0.rc2.windows.1 and I no longer see the problem. It seems like a bug in earlier version indeed, that has been fixed now. Brian, yes, the .gitmodules was perfectly correct. Brian, Duy, Jeff, thank you all for responding; the problem has been solved for me now. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: "Submodule registered for path" output with config aliases mixed in
Hmm, sorry for pushing, but no ideas, really?
Doesn't it seem like a bug?
Matz
On Tue, 19 Feb 2019 at 17:51, Mateusz Loskot wrote:
>
> Hi,
>
> $ git version
> git version 2.20.1.windows.1
>
> I'm running `git clone --recurse-submodules https://...`
> The command seems to run well and completes with success.
>
> However, I noticed strange output from git:
>
> ```
> Submodule 'Binary/A' (https://...) registered for path '!f() {
> ~/AppData/Local/Fork/Fork.exe $PWD; }; fBinary/A'
> Submodule 'Binary/B' (https://...) registered for path 'À
> ♂♦Binary/Intergraph'
> Submodule 'Binary/C' (https://) registered for path '!sh -c 'git log
> $1@{1}..$1@{0} $@'Binary/C'
> Submodule 'Binary/D' (https://...) registered for path 'ls-files -o -i
> --exclude-standardBinary/D'
> Submodule 'Binary/E' (https://...) registered for path
> 'mergetool.TortoiseGitMerge.trustexitcodeBinary/E'
> ```
>
> I managed to identify where that garbage injections come from:
> from git aliases I've got configured [1]
>
> Could anyone explain what is happening here?
> Is there anything wrong with my ~/.gitconfig [1] ?
>
>
> [1] https://github.com/mloskot/wsl-config/tree/master/git
>
> --
> Best regards,
> Mateusz Łoskot, http://mateusz.loskot.net
--
Mateusz Loskot, http://mateusz.loskot.net
"Submodule registered for path" output with config aliases mixed in
Hi,
$ git version
git version 2.20.1.windows.1
I'm running `git clone --recurse-submodules https://XXX`
The command seems to run well and completes with success.
However, I noticed strange output from git:
```
Submodule 'Binary/A' (https://XXX) registered for path '!f() {
~/AppData/Local/Fork/Fork.exe $PWD; }; fBinary/A'
Submodule 'Binary/B' (https://XXX) registered for path 'À ♂♦Binary/Intergraph'
Submodule 'Binary/C' (https://XXX) registered for path '!sh -c 'git
log $1@{1}..$1@{0} $@'Binary/C'
Submodule 'Binary/D' (https://XXX) registered for path 'ls-files -o -i
--exclude-standardBinary/D'
Submodule 'Binary/E' (https://XXX) registered for path
'mergetool.TortoiseGitMerge.trustexitcodeBinary/E'
```
I managed to identify where that garbage injections come from:
from git aliases I've got configured [1]
Could anyone explain what is happening here?
Is there anything wrong with my ~/.gitconfig [1] ?
[1] https://github.com/mloskot/wsl-config/tree/master/git
--
Best regards,
Mateusz Łoskot, http://mateusz.loskot.net
Re: Git - logo commercial use
On Wed, 13 Feb 2019 at 20:34, Agnieszka Borcz wrote: > > Dear Sir/Madam, > > My partner and I are in the initial stages of setting up an e-commerce > business selling high-quality stickers of logos of popular software and > libraries. We would mainly be marketing towards software developers, as there > are many who enjoy placing stickers of their favorite tech on their laptops > for display. > > We would love to be able to include your logo as part of our inventory but > aren’t sure of the restrictions regarding its use for commercial purposes, so > we would like to find out what your policy is regarding this and if this > would be a possibility? > > We do not plan to modify or alter the logo in any way or claim that it is > ours. To get a better idea of how we plan to use the logo, please see the > following website, as this is very similar to what we plan to do: > https://www.stickermule.com/unixstickers. I'd follow the following steps: Go to https://git-scm.com/downloads/logos Scroll to the bottom Follow link to Creative Commons Attribution 3.0 Unported License Read and understand it, or hire a lawyer. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Submodules & worktree
On Fri, 1 Feb 2019 at 15:00, Ole Pinto wrote: > > Adding a worktree from a working copy with submodules doesn't work. > > In the config file I have > [submodule] > recurse = true > FYI, https://git-scm.com/docs/git-worktree#_bugs "Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject." Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Checkout branch and prune everything related to previous checkout (incl. LFS remains)
Hi, I have a repo of a superproject with number of submodules. lots of files of both are in Git LFS. The repo comes with multiple long-lived release branches. The complete clone transfers 20 GB of Git and Git LFS objects. Checkout of master deflates the total repo to 40 GB in total, that is the objects and the working tree files together. Let's consider three separate clones as canonical way to create three working copies, one per the long-lived branch: ``` git clone --branch master --recursive --jobs 8 https://repo repo_master git clone --branch release/1.0 --recursive --jobs 8 https://repo repo_release1 git clone --branch release/2.0 --recursive --jobs 8 https://repo repo_release2 ``` I'm trying to work out a network-optimised equivalent of the above: - clone once with the default master checked out - make multiple copies of the cloned repo - checkout release branches How to checkout an existing branch fetched from remote, delete the previous branch and clean up any remains? How to clean up everything related to the previously checked out master and its working tree, any cached previous LFS downloads etc.? But, to keep the history of origin/master. Here is what I have come up with for the the network-optimised workflow: ``` git clone --branch master --recursive --jobs 8 https://repo repo_master cp -a repo_master repo_release1 cp -a repo_master repo_release2 cd repo_release1 git checkout -b release/1.0 --track origin/release/1.0 git pull git submodule update --init --recursive --jobs 8 git branch -D master git lfs prune git submodule foreach --recursive git lfs prune git lfs checkout git submodule foreach --recursive git lfs checkout ``` Does it look correct or any steps are missing/redundant? Does it make sense to run any of these, at which point? git gc --aggressive --prune=now git submodule foreach --recursive git gc --aggressive --prune=now Please, assume, no new commits will happen locally between the `git clone --branch master ...` and `cp -a repo_master ...`. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: How to perform efficient incremental update of a git repo from a large SVN repo? Bug or clueless user?
On Wed, 12 Dec 2018 at 21:13, James Mason wrote: > > I have a large and active SVN repository. More than 36,000 revisions, > thousands of branches - new ones created daily - and a non-standard > layout. Also, a secondary git repository that serves as a faithful > "git" copy of the work accumulating in SVN (git version 2.9.5). I seek > an efficient way to routinely (nightly?) update the git repo with new > changes accumulating in SVN. SubGit [1] I've been using it to translate SVN repository with ~40K revisions, producing ~25GB Git bare repo. SubGit is x10-x100... faster than `git svn`. [1] https://subgit.com/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Simple git push --tags deleted all branches
On Thu, 29 Nov 2018 at 16:39, Ævar Arnfjörð Bjarmason wrote: > On Thu, Nov 29 2018, Mateusz Loskot wrote: > > On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason > > wrote: > >> On Wed, Nov 28 2018, Mateusz Loskot wrote: > >> > > >> > (using git version 2.19.2.windows.1) > >> > > >> > I've just encountered one of those WTH moments. > >> > > >> > I have a bare repository > >> > > >> > core.git (BARE:master) $ git branch > >> > 1.0 > >> > 2.0 > >> > * master > >> > > >> > core.git (BARE:master) $ git tag > >> > 1.0.1651 > >> > 1.0.766 > >> > 2.0.1103 > >> > 2.0.1200 > >> > > >> > I published the repo using: git push --all --follow-tags > >> > > >> > This succeeded, but there seem to be no tags pushed, just branches. > >> > So, I followed with > >> > > >> > core.git (BARE:master) $ git push --tags > >> > To XXX > >> > - [deleted] 1.0 > >> > - [deleted] 2.0 > >> > ! [remote rejected] master (refusing to delete the current > >> > branch: refs/heads/master) > >> > error: failed to push some refs to 'XXX' > >> > > >> > And, I've found out that all branches and tags have been > >> > wiped in both, local repo and remote :) > >> > > >> > I restored the repo and tried out > >> > > >> > git push origin 1.0 > >> > git push origin --tags > >> > > >> > and this time both succeeded, without wiping out any refs. > >> > > >> > Could anyone help me to understand why remote-less > >> > > >> > git push --tags > >> > > >> > is/was so dangerous and unforgiving?! > >> > >> Since nobody's replied yet, I can't see what's going on here from the > >> info you've provided. My guess is that you have something "mirror" set > >> on the remote. > > > > Thank you for responding. > > > > The git push --tags hugely surprised me, and here is genuine screenshot > > https://twitter.com/mloskot/status/1068072285846859776 > > > >> It seems you can't share the repo or its URL, but could you share the > >> scrubbed output of 'git config -l --show-origin' when run inside this > >> repository? > > > > Here is complete output. I have not stripped the basics like aliases, > > just in case. > > Right, it's because you used --mirror, the important bit: > > > file:config remote.origin.url=https://xxx.com/core-external-metadata.git > > file:config remote.origin.fetch=+refs/*:refs/* > > file:config remote.origin.mirror=true > > file:config > > I.e. you have cloned with the --mirror flag, this is what it's supposed > to do: https://git-scm.com/docs/git-clone#git-clone---mirror > https://git-scm.com/docs/git-fetch#git-fetch---prune > > I.e. you push and git tries to mirror the refs you have locally to the > remote, including pruning stuff in the remote. Thank you very much for diagnosing my issue. I was not aware about how --mirror affects the workflow. It all makes perfect sense now. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Simple git push --tags deleted all branches
On Thu, 29 Nov 2018 at 16:03, Ævar Arnfjörð Bjarmason wrote: > On Wed, Nov 28 2018, Mateusz Loskot wrote: > > > > (using git version 2.19.2.windows.1) > > > > I've just encountered one of those WTH moments. > > > > I have a bare repository > > > > core.git (BARE:master) $ git branch > > 1.0 > > 2.0 > > * master > > > > core.git (BARE:master) $ git tag > > 1.0.1651 > > 1.0.766 > > 2.0.1103 > > 2.0.1200 > > > > I published the repo using: git push --all --follow-tags > > > > This succeeded, but there seem to be no tags pushed, just branches. > > So, I followed with > > > > core.git (BARE:master) $ git push --tags > > To XXX > > - [deleted] 1.0 > > - [deleted] 2.0 > > ! [remote rejected] master (refusing to delete the current > > branch: refs/heads/master) > > error: failed to push some refs to 'XXX' > > > > And, I've found out that all branches and tags have been > > wiped in both, local repo and remote :) > > > > I restored the repo and tried out > > > > git push origin 1.0 > > git push origin --tags > > > > and this time both succeeded, without wiping out any refs. > > > > Could anyone help me to understand why remote-less > > > > git push --tags > > > > is/was so dangerous and unforgiving?! > > Since nobody's replied yet, I can't see what's going on here from the > info you've provided. My guess is that you have something "mirror" set > on the remote. Thank you for responding. The git push --tags hugely surprised me, and here is genuine screenshot https://twitter.com/mloskot/status/1068072285846859776 > It seems you can't share the repo or its URL, but could you share the > scrubbed output of 'git config -l --show-origin' when run inside this > repository? Here is complete output. I have not stripped the basics like aliases, just in case. ``` core-external-metadata.git (BARE:master) $ git config -l --show-origin file:"C:\\ProgramData/Git/config" core.symlinks=false file:"C:\\ProgramData/Git/config" core.autocrlf=true file:"C:\\ProgramData/Git/config" color.diff=auto file:"C:\\ProgramData/Git/config" color.status=auto file:"C:\\ProgramData/Git/config" color.branch=auto file:"C:\\ProgramData/Git/config" color.interactive=true file:"C:\\ProgramData/Git/config" help.format=html file:"C:\\ProgramData/Git/config" http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt file:"C:\\ProgramData/Git/config" diff.astextplain.textconv=astextplain file:"C:\\ProgramData/Git/config" rebase.autosquash=true file:C:/Program Files/Git/mingw64/etc/gitconfig http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt file:C:/Program Files/Git/mingw64/etc/gitconfig http.sslbackend=openssl file:C:/Program Files/Git/mingw64/etc/gitconfig diff.astextplain.textconv=astextplain file:C:/Program Files/Git/mingw64/etc/gitconfig filter.lfs.clean=git-lfs clean -- %f file:C:/Program Files/Git/mingw64/etc/gitconfig filter.lfs.smudge=git-lfs smudge -- %f file:C:/Program Files/Git/mingw64/etc/gitconfig filter.lfs.process=git-lfs filter-process file:C:/Program Files/Git/mingw64/etc/gitconfig filter.lfs.required=true file:C:/Program Files/Git/mingw64/etc/gitconfig credential.helper=manager file:C:/Users/mateuszl/.gitconfig user.name=Mateusz Łoskot file:C:/Users/mateuszl/.gitconfig user.email=mate...@loskot.net file:C:/Users/mateuszl/.gitconfig github.user=mloskot file:C:/Users/mateuszl/.gitconfig core.editor=vim file:C:/Users/mateuszl/.gitconfig color.branch=auto file:C:/Users/mateuszl/.gitconfig color.diff=auto file:C:/Users/mateuszl/.gitconfig color.status=auto file:C:/Users/mateuszl/.gitconfig color.ui=auto file:C:/Users/mateuszl/.gitconfig alias.br=branch file:C:/Users/mateuszl/.gitconfig alias.bv=branch -vv file:C:/Users/mateuszl/.gitconfig alias.brv=branch -vv file:C:/Users/mateuszl/.gitconfig alias.bra=branch -a file:C:/Users/mateuszl/.gitconfig alias.ci=commit --verbose file:C:/Users/mateuszl/.gitconfig alias.cia=commit --verbose --amend file:C:/Users/mateuszl/.gitconfig alias.ciae=commit --verbose --amend --no-edit file:C:/Users/mateuszl/.gitconfig alias.co=checkout file:C:/Users/mateuszl/.gitconfig alias.dc=diff --cached file:C:/Users/mateuszl/.gitconfig alias.df=diff file:C:/Users/mateuszl/.gitconfig alias.gf=flow file:C:/Users/mateuszl/.gitconfig alias.lg=log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Cre
Re: Git Tags
On Thu, 29 Nov 2018 at 14:40, Randall S. Becker wrote: > On November 29, 2018 6:56, Mateusz Loskot wrote: > > On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler > > wrote: > > > > > > git tag -a 0.9.0 > > > git push origin master > > > > > > In my local repository, when I run "git tag" it is showing me "0.9.0". > > > > > > Then I did (on box B) > > > git clone ssh://user@host:/path/project.git cd project git tag > > > > > > Now git tag is showing nothing. > > > > > > Why is the tag only available in my local repository? > > > > >From https://git-scm.com/book/en/v2/Git-Basics-Tagging > > "By default, the git push command doesn’t transfer tags to remote servers. > > You will have to explicitly push tags to a shared server after you have > > created > > them." > > git push --tags > After my yesterday experience [1], I'd be careful with git push --tags :) [1] genuine screenshot and link to related thread at https://twitter.com/mloskot/status/1068072285846859776 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Git Tags
On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler wrote: > > git tag -a 0.9.0 > git push origin master > > In my local repository, when I run "git tag" it is showing me "0.9.0". > > Then I did (on box B) > git clone ssh://user@host:/path/project.git > cd project > git tag > > Now git tag is showing nothing. > > Why is the tag only available in my local repository? >From https://git-scm.com/book/en/v2/Git-Basics-Tagging "By default, the git push command doesn’t transfer tags to remote servers. You will have to explicitly push tags to a shared server after you have created them." Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Simple git push --tags deleted all branches
On Wed, 28 Nov 2018 at 17:50, Mateusz Loskot wrote: > > (using git version 2.19.2.windows.1) > [...] > I restored the repo and tried out > > git push origin 1.0 > git push origin --tags > > and this time both succeeded, without wiping out any refs. And, to my surprise, this pushed all branches and all tags: git push --all origin So, I did not have to run follow with tags push only using git push --tags origin Has anything changes in [1] that now --all Push all branches ...AND tags? [1] https://git-scm.com/docs/git-push#git-push---all Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Simple git push --tags deleted all branches
Hi, (using git version 2.19.2.windows.1) I've just encountered one of those WTH moments. I have a bare repository core.git (BARE:master) $ git branch 1.0 2.0 * master core.git (BARE:master) $ git tag 1.0.1651 1.0.766 2.0.1103 2.0.1200 I published the repo using: git push --all --follow-tags This succeeded, but there seem to be no tags pushed, just branches. So, I followed with core.git (BARE:master) $ git push --tags To XXX - [deleted] 1.0 - [deleted] 2.0 ! [remote rejected] master (refusing to delete the current branch: refs/heads/master) error: failed to push some refs to 'XXX' And, I've found out that all branches and tags have been wiped in both, local repo and remote :) I restored the repo and tried out git push origin 1.0 git push origin --tags and this time both succeeded, without wiping out any refs. Could anyone help me to understand why remote-less git push --tags is/was so dangerous and unforgiving?! Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: How to propagate critical fixs from master to develope branch.
On Thu, 22 Nov 2018 at 07:39, Mgr Georg Black wrote: > Hello everyone.I red git manual but I can't figure out how to propagate > critical change from master branch to long live develop branch. Have you considered "using git cherry-pick can be used to backport changes one by one" [1] > I red chapter about rebasing that I think could solve it but at the end of > this chapter is written that it's not recommended for pubic repositories. I > don't know how to do it without merging develop branch to master. rebase vs merge vs cherry-pick is a topic of constant debates and opinionated practices indeed [2] The cherry-pick has its cons, like duplicate commits (BTW, it is a good idea to learn more about pros and cons of cherry-pick before you apply this technique). That is why workflows like GitFlow require to prepare a hotfix in a topic branch which is merged back to long-lived branch. In your case, I assume, you've done your work in long-lived master, so I think easiest is to pick that change from master and port it to the develop branch [3]. I would cherry-pick. [1] https://www.atlassian.com/blog/git/the-essence-of-branch-based-workflows [2] https://www.atlassian.com/git/articles/git-team-workflows-merge-or-rebase [3] https://reallifeprogramming.com/git-process-that-works-say-no-to-gitflow-50bf2038ccf7 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Migration to Git LFS inflates repository multiple times
On Mon, 12 Nov 2018 at 00:47, Mateusz Loskot wrote: > > Hi, > > I'm posting here for the first time and I hope it's the right place to ask > questions about Git LFS. > > TL;TR: Is this normal a repository migrated to Git LFS inflates multiple times > and how to deal with it? FYI, answers to my questions have been completed via GitHub https://github.com/git-lfs/git-lfs/issues/3374 I'd like to thank Jeff and Ævar here for help too. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Re: Migration to Git LFS inflates repository multiple times
On Mon, 12 Nov 2018 at 13:31, Jeff King wrote: > On Mon, Nov 12, 2018 at 12:47:42AM +0100, Mateusz Loskot wrote: > > > > TL;TR: Is this normal a repository migrated to Git LFS inflates multiple > > times > > and how to deal with it? > > That does sound odd to me. People with more LFS experience can probably > give you a better answers FYI, I forwarded my question to https://github.com/git-lfs/git-lfs/issues/3374 > but one thought occurred to me: does LFS > store backup copies of the original refs that it rewrites (similar to > the way filter-branch stores refs/original)? I don't think I see any backup refs (see below for full list). But, I may be misunderstanding what they are, how to look for them. > history. Which might mean storing those large blobs both as Git objects > (for the old history) and in an LFS cache directory (for the new > history). Yes, it makes sense. > And the right next step is probably to delete those backup refs, and > then "git gc --prune=now". Hmm, actually thinking about it, reflogs > could be making the old history reachable, too. > > Try looking at the output of "git for-each-ref" and seeing if there are > any backup refs. I see. Here is the list (long!) of all I found: proj.git (BARE:master) $ git for-each-ref c718eadcf8d09d68c385f0a9355a2c871474fb43 commit refs/heads/1.0 daa75889053b70515179e334cbe3fe6fc7873ff3 commit refs/heads/1.1 cb70db292c1f0c62170d05ffa8dad3c87a6f8ebd commit refs/heads/2.0 f1597e80fcea16bec96dc43f7ab706616126305b commit refs/heads/3.0 1d9e4813ae2fdc5c2b52f7115facda9059b009dc commit refs/heads/master f41edf37e9a4120bc5d5d66b29d110d403b8db9b commit refs/svn/attic/tags/1.0.1006/6674 850166b21f27447c6b503bb753c454ccedcea8ef commit refs/svn/attic/tags/1.0.216/1291 8a24407f2df0ea7a401fbc08b387387538912642 commit refs/svn/attic/tags/1.0.252/1543 771d81b0756d6ff7d73779ed79f49a607bffb80e commit refs/svn/attic/tags/1.0.299/1883 10925d0fe0de090d4de109fd6403b86d014d6a21 commit refs/svn/attic/tags/1.0.342/2288 ca8dc7b243d002ac6b27f219a6172d36e7885ac1 commit refs/svn/attic/tags/1.0.391/2470 79ebabed25d31dfa34ad68e58fa9327f71928df1 commit refs/svn/attic/tags/1.0.433/2657 d3ed45804843c5aa153810b7494e2c7c0b842c82 commit refs/svn/attic/tags/1.0.450/2724 088af5dbb225cb8dfbeafb5b63158234f4e4017d commit refs/svn/attic/tags/1.0.502/2967 5da8598ed98a5a6610108d67849955da14f9d5b8 commit refs/svn/attic/tags/1.0.546/3212 c3463397337f9f6e5f9d8e64cd79c013fd798bc8 commit refs/svn/attic/tags/1.0.615/3470 673b2f93fda830cc8f28d436abead5fd54baa361 commit refs/svn/attic/tags/1.0.657/3704 247cf24b90afd39f4f5dd7a27cf6b74483215285 commit refs/svn/attic/tags/1.0.662/3725 e2a1609bb6b15ee767565ca0ff152eae3f72a76b commit refs/svn/attic/tags/1.0.673/3820 48033fb9046b1ee60ad9b73073e9185c31ee4568 commit refs/svn/attic/tags/1.0.742/4325 d7b566a275209d0aebba39c7a4028c9dcfb8a468 commit refs/svn/attic/tags/1.1.1141/13525 80f922becfc406420d2f14543e6da684f7377504 commit refs/svn/attic/tags/1.1.1535/16534 252481191cacdef0e77eb6ec02c98b07fca7bc77 commit refs/svn/attic/tags/1.1.1582/16435 601f072d559b664c101d89f3445ed3d00f4ef5dd commit refs/svn/attic/tags/1.1.939/12077 417fb23d71cab30e2c6218faed6f86021b67ca25 commit refs/svn/attic/tags/2.0.1156/21143 5539fbbe0078b782af02d46e0c1abc86ce3d5902 commit refs/svn/map c718eadcf8d09d68c385f0a9355a2c871474fb43 commit refs/svn/root/branches/1.0 daa75889053b70515179e334cbe3fe6fc7873ff3 commit refs/svn/root/branches/1.1 cb70db292c1f0c62170d05ffa8dad3c87a6f8ebd commit refs/svn/root/branches/2.0 f1597e80fcea16bec96dc43f7ab706616126305b commit refs/svn/root/branches/3.0 e946e96ce2b37a771769196027ae87b8f24181e0 commit refs/svn/root/tags/1.0.1058 06928f42664384bd5e24c115f9c23acc2fd949da commit refs/svn/root/tags/1.0.1240 9f059337974aa195386c5f3ee21957551624aa27 commit refs/svn/root/tags/1.0.1653 db98d68f93d2e9127ab766d3bbe6c933ec169d29 commit refs/svn/root/tags/1.0.764 20ad69c6b94bc8b73b613b5c21d367f22f423501 commit refs/svn/root/tags/1.1.1163 458be535d7f0bc512e800759759e86a211a418b6 commit refs/svn/root/tags/1.1.1290 df045ab97bee94e8cfe72b70802b837719899587 commit refs/svn/root/tags/1.1.1556 cd8ce83868016a0854c0f3cf1b23ea68a32674a2 commit refs/svn/root/tags/1.1.1706 fcd0801b93f48bd46b276ccb82678a70f11fc3ca commit refs/svn/root/tags/1.1.1809 5df0902cfe973b0a041409ec2e8d2314f2b8031e commit refs/svn/root/tags/1.1.2368 c9a06b4f43bab77ed283fe2736ab5c865e03026e commit refs/svn/root/tags/1.1.2417 32e505f8c4deadb73c63bd20a598481cd164541d commit refs/svn/root/tags/1.1.947 ef9c3667ec419bcb6d5eb5b9dbacb1cff0b1051e commit refs/svn/root/tags/2.0.1187 a1a6a5bedb8949eb91f3509929edb9efa9ad2875 commit refs/svn/root/tags/2.0.1198 33a8f49da311caecdb5521759251bbcb78e3bff2 commit refs/svn/root/tags/2.0.1338 63e59278131281858296b56f4ef5dd91c332941a commit refs/svn/root/tags/2.0.1481 d23a1c662f772a7fc0d23a07794b57cfd9eff064 commit refs/svn/root/tags/2.0.1835 c53e2cc4660a9e3121dff33c28c1383
Migration to Git LFS inflates repository multiple times
Hi, I'm posting here for the first time and I hope it's the right place to ask questions about Git LFS. TL;TR: Is this normal a repository migrated to Git LFS inflates multiple times and how to deal with it? I'm migrating a big SVN repository to Git. In SVN, a collection of third-party SDKs is maintained along with codebase. Many of the third-party libraries come in binary form. So, I'm migrating binary files of those to Git LFS. I'm following the Git LFS tutorial, section "Migrating existing repository data to LFS" https://github.com/git-lfs/git-lfs/wiki/Tutorial First, I run initial translation of the SVN reoi into Git.. The new repository is a Git bare repository. There are 5 branches and 10+ tags in the proj.git repo. It is quite large: proj.git (BARE:master) $ du -sh 19G Next, I performed the following sequence of steps to optimise it and migrate to Git LFS: 1. Optimise the repo proj.git (BARE:master) $ git gc Enumerating objects: 1432599, done. Counting objects: 100% (1432599/1432599), done. Delta compression using up to 48 threads Compressing objects: 100% (864524/864524), done. Writing objects: 100% (1432599/1432599), done. Total 1432599 (delta 541698), reused 1405922 (delta 525738) Removing duplicate objects: 100% (256/256), done. Checking connectivity: 1432599, done. proj.git (BARE:master) $ du -sh 11G 2. List the file types taking up the most space in the repo proj.git (BARE:master) $ git lfs migrate info --everything migrate: Sorting commits: ..., done migrate: Examining commits: 100% (29412/29412), done *.lib 27 GB 3524/3524 files(s) 100% *.pdb 5.6 GB 1412/1412 files(s) 100% *.cpp 4.8 GB 131848/131854 files(s) 100% *.exe 2.3 GB798/798 files(s) 100% *.dll 2.0 GB 1000/1000 files(s) 100% 3. Migrate the repo to Git LFS proj.git (BARE:master) $ git lfs migrate import --include="*.exe,*.dll,*.lib,*.pdb,*.zip" --everything 4. Check size of the repo after migration to Git LFS proj.git (BARE:master) $ du -sh 47G 5. Cleaning up the `.git` directory after migration to Git LFS proj.git (BARE:master) $ git reflog expire --expire-unreachable=now --all proj.git (BARE:master) $ git gc --prune=now --aggressive Enumerating objects: 1462310, done. Counting objects: 100% (1462310/1462310), done. Delta compression using up to 48 threads Compressing objects: 100% (1422322/1422322), done. Writing objects: 100% (1462310/1462310), done. Total 1462310 (delta 577640), reused 845097 (delta 0) Removing duplicate objects: 100% (256/256), done. Checking connectivity: 1462310, done. 6. Check final disk size of the repo proj.git (BARE:master) $ du -sh 39G 7. List the file types taking up the most space in the repository after migration to Git LFS proj.git (BARE:master) $ git lfs migrate info --everything migrate: Sorting commits: ..., done migrate: Examining commits: 100% (29412/29412), done *.cpp 4.8 GB 131848/131854 files(s) 100% *.png 1.1 GB 696499/696499 files(s) 100% *.h 828 MB86386/86471 files(s) 100% *.csv 820 MB939/939 files(s) 100% *.html 686 MB34126/34126 files(s) 100% Now, I'm looking for anaswers to the following questions: 1. Is the procedure presented above correct to migrate (SVN ->) Git -> Git LFS? 2. Given the initial translation to Git generated 19 GB repo (optimised to 11 GB) is this normal Git LFS migration inflates the repository to 47 GB (optimised ot 39 GB)? 3. Why the inflation happens? Is this a function of number of branches? How to understand the jump from 11 GB to 39 GB? 4. How to optimise the repository to cut the size down further? My next step is to somehow push the fat pig into GitHub, Bitbucket or Azure DevOps ;-) I've used Git for a few years, but I'm pretty newbie regarding low-level or administration tasks, so I might have made basic errors. I'll be thankful for any feedback. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
