[git-users] Re: Git and Basic authentication

[Artem]

Hello again. It seems I found the answer to my question. Yes, really Git 
client requires 'WWW-Authenticate: Basic' when gets 401 response. Without 
this, Git won't send credentials.

воскресенье, 15 октября 2023 г. в 12:24:13 UTC+3, Artem: 

> Hello everyone!
>
> I'm playing with the JGit library over the Jetty server and can't 
> understand why Git cannot send basic authentication credentials.
>
> $ git push
> Username for 'http://localhost:8080': qwerty
> Password for 'http://qwerty@localhost:8080':
> fatal: Authentication failed for 'http://localhost:8080/repo1/'
>
> Wireshark captures such HTTP request that does not contain the 
> Authorization header:
>
> GET /repo1/info/refs?service=git-receive-pack HTTP/1.1
> Host: localhost:8080
> User-Agent: git/2.39.3 (Apple Git-145)
> Accept: */*
> Accept-Encoding: deflate, gzip
> Pragma: no-cache
>
> I thought it could be related to insecure HTTP, but upgrading to HTTPS 
> changes nothing. Am I doing something wrong? Should my server send the 
> correct headers with a 401 response?
>
> Thanks in advance,
> Artem
>

-- 
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/3a795066-0072-4f31-9c25-206d552af798n%40googlegroups.com.

Re: [git-users] Re: Git new branch listed in 'git branch' command only after 'git checkout '

[Konstantin Khomoutov]

On Fri, Sep 29, 2023 at 04:45:13AM -0700, Leonardo D'Alimonte wrote:

> so basically the command "git branch" without params lists local branches 
> that are not yet checked out.

This statement is a bit strange.
A Git repository may only have a single branch checked out at any given time.
The command `git branch` lists your local branches - those you can work on in
your repository. Of these branches, one or none can be checked out right now,
but the fact whether any of those branches has previously been checked out or
not makes absolutely no difference.

I think you might want to elaborate on what you had in mind because you might
maintain some serious misconception about these matters, and this will bite
you in the neck later.

> What I actually didn't know is "-a" params which lists *all *branches, 
> local and remotes included :)

There is also the "-r" command-line flag which makes the command list only the
remote branches.

As usually, it never hurts to run `git help ` and squint at what it
shows; in this case that'd be `git help branch` ;-)

-- 
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/20230929120438.nolqvhq4co4gppbu%40carbon.

[git-users] Re: Git new branch listed in 'git branch' command only after 'git checkout '

[Leonardo D'Alimonte]

Hi Philip,
so basically the command "git branch" without params lists local branches 
that are not yet checked out.
What I actually didn't know is "-a" params which lists *all *branches, 
local and remotes included :)

Thanks for your reply, as I'v learnt something new!
Bye

Leonardo

On Thursday, September 28, 2023 at 5:36:59 PM UTC+2 philip...@iee.email 
wrote:

> I guess you haven't yet grasped the full effects of the decentralised 
> nature of Git yet ;-)
> When you 'pull' you first 'fetch' the [selected branches of the] remote 
> repository and store it under the remote's name (often 'origin'),
> so you get an 'origin/master' (as well as your own 'master'), and then the 
> second part of the 'pull' comes into play, and for most it's a 'merge' 
> (config options available), and for newbies that's commonly a simple fast 
> forward merge, so your master is advanced to point at the same commit that 
> origin/master points at.
>
> However if your [implicit / configurable] selection for the fetch also 
> fetched the "new" branch it will also be in the local copy of the remote 
> (tracking branch) called 'origin/new' which isn't yours yet. 
>
> If you use the -a option for the branch command you will then see all 
> those other 'remotes/' branches which you should never checkout directly 
> (at least not until you know how to run & juggle scissors). Though what you 
> are likely to do is instead use the branch command to start a fresh 
> personal branch (with the name you want to use: my_new) starting at the 
> origin/new starting point. This will mean that you can do as you wish with 
> your version without compromising the copy of what's on the "server" [but 
> start to think 'remote', as you can also have colleagues as remotes].
>
> Hope that helps you unpick the mental model of a *D*VCS.
>
>
>
> On Thursday, September 28, 2023 at 2:07:03 PM UTC+1 
> leonardo@logintranet.com wrote:
>
>> Good afternoon everyone,
>> I'm a bit new of Git mechanisms and commands so maybe this topic can be 
>> already discussed.
>>
>> Practically, I see that once a branch has been created remotely from 
>> 'master' (eg. directly from Atlassian JIRA through 'Create branch'), 
>> performing a 'git pull' command on the 'master' branch correclty download 
>> the new branch from the remote repository.
>>
>> However, if we perform the "git branch" command from master after the 
>> pull, the new branch is not listed into the branches available on the 
>> project.
>>
>> Once we check out the new branch, if we execute "git branch" command 
>> again the new branch appears in the list..
>>
>> In my opinion, It would be quite useful if the new branch displays in the 
>> list once it's been synchronized with 'pull' command.
>> Can it be a bug or a desired behaviour?
>>
>> Let me know what you think about that, thanks in advance :)
>> Leonardo D'Alimonte
>> Loginet srl
>>
>

-- 
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/7479ec19-8dcd-4c73-a4cf-08a4dc7568a5n%40googlegroups.com.

[git-users] Re: Git new branch listed in 'git branch' command only after 'git checkout '

[Philip Oakley]

I guess you haven't yet grasped the full effects of the decentralised 
nature of Git yet ;-)
When you 'pull' you first 'fetch' the [selected branches of the] remote 
repository and store it under the remote's name (often 'origin'),
so you get an 'origin/master' (as well as your own 'master'), and then the 
second part of the 'pull' comes into play, and for most it's a 'merge' 
(config options available), and for newbies that's commonly a simple fast 
forward merge, so your master is advanced to point at the same commit that 
origin/master points at.

However if your [implicit / configurable] selection for the fetch also 
fetched the "new" branch it will also be in the local copy of the remote 
(tracking branch) called 'origin/new' which isn't yours yet. 

If you use the -a option for the branch command you will then see all those 
other 'remotes/' branches which you should never checkout directly (at 
least not until you know how to run & juggle scissors). Though what you are 
likely to do is instead use the branch command to start a fresh personal 
branch (with the name you want to use: my_new) starting at the origin/new 
starting point. This will mean that you can do as you wish with your 
version without compromising the copy of what's on the "server" [but start 
to think 'remote', as you can also have colleagues as remotes].

Hope that helps you unpick the mental model of a *D*VCS.



On Thursday, September 28, 2023 at 2:07:03 PM UTC+1 
leonardo@logintranet.com wrote:

> Good afternoon everyone,
> I'm a bit new of Git mechanisms and commands so maybe this topic can be 
> already discussed.
>
> Practically, I see that once a branch has been created remotely from 
> 'master' (eg. directly from Atlassian JIRA through 'Create branch'), 
> performing a 'git pull' command on the 'master' branch correclty download 
> the new branch from the remote repository.
>
> However, if we perform the "git branch" command from master after the 
> pull, the new branch is not listed into the branches available on the 
> project.
>
> Once we check out the new branch, if we execute "git branch" command again 
> the new branch appears in the list..
>
> In my opinion, It would be quite useful if the new branch displays in the 
> list once it's been synchronized with 'pull' command.
> Can it be a bug or a desired behaviour?
>
> Let me know what you think about that, thanks in advance :)
> Leonardo D'Alimonte
> Loginet srl
>

-- 
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/e1df8d07-f37f-4d2e-87a1-cc5a3e4d75a9n%40googlegroups.com.

[git-users] Re: git - controlling user access to specific git repositories

[Philip Oakley]

Git itself is all about collaboration in an open source environment (cf 
Linux!)

So any restrictions on access need to be implemented elsewhere, rather than 
Git itself.

Access control is a big subject riddled with admin, political and corporate 
issues. In that sense, Git repos are 'just another file / directory' ;-)

On Monday, July 24, 2023 at 8:58:49 AM UTC+1 aksrin...@gmail.com wrote:

> Hello,
>
> I am new to the implementation of git and i had a requirement where i need 
> to control user access to specific git repositories. 
>
> For ex: I have 3 different projects for which i create 3 different git 
> repositories and grant access permissions to specific users based on the 
> projects they are working. I have tried the following way but all the users 
> created on Linux server are able to access all the repositories created 
> under each user. It is not getting restricted to specific Linux User.
>
>
>1. Create three Linux users, one for each repository:  Proejct1, 
>Project2, and Project 3
>2. Login into each user and create the bare Git repository
>3. For each user, create ~/.ssh/authorized_keys 
> (/home/Project1/.ssh/authorized_keys) and add the public SSH key for each 
>user that should have access 
>
> I am not sure what needs to be done to provide access to the user for the 
> git repository created under his user and do not allow other users to 
> access the Git repository created under another user
>
> Please suggest me the list of steps that needs to be implement to control 
> access to specific Git repositories or any git commands that needs to be 
> executed for this implementation?
>
>
>

-- 
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/3093cd78-a2e4-475d-a4cc-a18c86dcde4fn%40googlegroups.com.

Re: [git-users] Re: `git gc` error: fatal: could not find pack

[Lyndon Gingerich]

In further messing around, I lost one of the pack files. :( Now I'm
re-cloning the repository from the remote. I'm keeping the old .git folder
backed up, though, in case anyone has suggestions.

On Mon, Jun 5, 2023 at 4:26 PM Lyndon Gingerich 
wrote:

> `git verify-pack -v ` returns:
>
> fatal: Cannot open existing pack file '.idx'
> : bad
>
> On Mon, Jun 5, 2023 at 3:54 PM Lyndon Gingerich 
> wrote:
>
>> The packfile is only ~52kb, so its size is probably not an issue.
>>
>> I successfully ran `git gc` on two other repositories, so the issue is
>> not global.
>>
>> On Monday, June 5, 2023 at 3:48:03 PM UTC-5 Lyndon Gingerich wrote:
>>
>>> I discovered this problem from investigating the Git console in
>>> JetBrains Rider, noticing that it was taking excessively long to create
>>> commits. I'm running Git for Windows.
>>>
>>> When I run `git gc`, I get this output:
>>>
>>> Enumerating objects: 152755, done.
>>> Counting objects: 100% (152755/152755), done.
>>> Delta compression using up to 16 threads
>>> Compressing objects: 100% (70481/70481), done.
>>> Writing objects: 100% (152755/152755), done.
>>> Total 152755 (delta 83181), reused 150956 (delta 81540), pack-reused 0
>>> fatal: could not find pack 
>>> fatal: failed to run repack
>>>
>>> Steps I have tried (mostly suggested by ChatGPT):
>>>
>>>- Closing all programs with Git integrations
>>>- Hunting down ; it exists in .git/objects/pack and I
>>>have the permissions "Full control", "Modify", "Read & execute", "Read",
>>>and "Write" (though not "Special permissions")
>>>- Running the command as administrator in case permissions were the
>>>issue
>>>- Checking for file locks on the packfile
>>>- Running `git fsck` on the repository
>>>- Running `git gc --no-prune` for testing (still failed)
>>>- Checking for Git updates
>>>- Restarting my computer
>>>
>>> Googling (at my level of skill, anyway) isn't finding any help. What can
>>> I do?
>>>
>>> Many thanks!
>>> Lyndon Gingerich
>>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Git for human beings" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/git-users/zAIO4Ltrprk/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/6f2c3ea2-ec3a-4002-8c10-258995bacc09n%40googlegroups.com
>> 
>> .
>>
>

-- 
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/CAJ4Y%3DGnZbt%3DfB8b2m7ZfV70XnYbhcVgB2U8HKgWZVZq%2B_dBnzg%40mail.gmail.com.

Re: [git-users] Re: `git gc` error: fatal: could not find pack

[Lyndon Gingerich]

`git verify-pack -v ` returns:

fatal: Cannot open existing pack file '.idx'
: bad

On Mon, Jun 5, 2023 at 3:54 PM Lyndon Gingerich 
wrote:

> The packfile is only ~52kb, so its size is probably not an issue.
>
> I successfully ran `git gc` on two other repositories, so the issue is not
> global.
>
> On Monday, June 5, 2023 at 3:48:03 PM UTC-5 Lyndon Gingerich wrote:
>
>> I discovered this problem from investigating the Git console in JetBrains
>> Rider, noticing that it was taking excessively long to create commits. I'm
>> running Git for Windows.
>>
>> When I run `git gc`, I get this output:
>>
>> Enumerating objects: 152755, done.
>> Counting objects: 100% (152755/152755), done.
>> Delta compression using up to 16 threads
>> Compressing objects: 100% (70481/70481), done.
>> Writing objects: 100% (152755/152755), done.
>> Total 152755 (delta 83181), reused 150956 (delta 81540), pack-reused 0
>> fatal: could not find pack 
>> fatal: failed to run repack
>>
>> Steps I have tried (mostly suggested by ChatGPT):
>>
>>- Closing all programs with Git integrations
>>- Hunting down ; it exists in .git/objects/pack and I
>>have the permissions "Full control", "Modify", "Read & execute", "Read",
>>and "Write" (though not "Special permissions")
>>- Running the command as administrator in case permissions were the
>>issue
>>- Checking for file locks on the packfile
>>- Running `git fsck` on the repository
>>- Running `git gc --no-prune` for testing (still failed)
>>- Checking for Git updates
>>- Restarting my computer
>>
>> Googling (at my level of skill, anyway) isn't finding any help. What can
>> I do?
>>
>> Many thanks!
>> Lyndon Gingerich
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/git-users/zAIO4Ltrprk/unsubscribe.
> To unsubscribe from this group and all its topics, 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/6f2c3ea2-ec3a-4002-8c10-258995bacc09n%40googlegroups.com
> 
> .
>

-- 
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/CAJ4Y%3DGkgNEKsxZeat%3DO5G9jsmrDV7kcqufGBc%3DA5S0vAeHUWzg%40mail.gmail.com.

[git-users] Re: `git gc` error: fatal: could not find pack

[Lyndon Gingerich]

The packfile is only ~52kb, so its size is probably not an issue.

I successfully ran `git gc` on two other repositories, so the issue is not 
global.

On Monday, June 5, 2023 at 3:48:03 PM UTC-5 Lyndon Gingerich wrote:

> I discovered this problem from investigating the Git console in JetBrains 
> Rider, noticing that it was taking excessively long to create commits. I'm 
> running Git for Windows.
>
> When I run `git gc`, I get this output:
>
> Enumerating objects: 152755, done.
> Counting objects: 100% (152755/152755), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (70481/70481), done.
> Writing objects: 100% (152755/152755), done.
> Total 152755 (delta 83181), reused 150956 (delta 81540), pack-reused 0
> fatal: could not find pack 
> fatal: failed to run repack
>
> Steps I have tried (mostly suggested by ChatGPT):
>
>- Closing all programs with Git integrations
>- Hunting down ; it exists in .git/objects/pack and I 
>have the permissions "Full control", "Modify", "Read & execute", "Read", 
>and "Write" (though not "Special permissions")
>- Running the command as administrator in case permissions were the 
>issue
>- Checking for file locks on the packfile
>- Running `git fsck` on the repository
>- Running `git gc --no-prune` for testing (still failed)
>- Checking for Git updates
>- Restarting my computer
>
> Googling (at my level of skill, anyway) isn't finding any help. What can I 
> do?
>
> Many thanks!
> Lyndon Gingerich
>

-- 
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/6f2c3ea2-ec3a-4002-8c10-258995bacc09n%40googlegroups.com.

[git-users] Re: Git log --reverse gives less results. Is it a bug?

[Alexander Anisfeld]

Aha, I see. So, it's a known bug. Thanks!

On Friday, May 5, 2023 at 4:56:20 PM UTC+2 philip...@iee.email wrote:

> The `--reverse` problem pops up moderately often (OK occasionally). 
> Usually it's not doing what you expect as to _when_ the reversal is 
> applied. 
>
>
> https://stackoverflow.com/questions/35379277/why-does-git-log-with-follow-and-reverse-return-only-last-commit
>
> On Friday, May 5, 2023 at 12:29:56 AM UTC+1 aalexa...@gmail.com wrote:
>
>> 0.md was moved into sub directory and now git log --reverse  can't find 
>> its commits behind it, but works without --reverse. Is it a bug or I miss 
>> something?
>>
>> $ git log --follow -M --format=%ai "0.md" 
>> 2023-05-04 10:25:41 +0200 
>> 2023-03-01 02:00:51 +0100 
>> 2023-03-01 02:00:21 +0100 
>> 2023-03-01 01:59:51 +0100 
>> 2023-03-01 01:59:21 +0100 
>> 2023-03-01 01:57:51 +0100 
>> 2023-03-01 01:56:51 +0100 
>> 2023-03-01 01:37:06 +0100 
>> 2022-03-07 00:56:29 +0100 
>> $ git log --reverse --follow -M --format=%ai "0.md" 
>> 2023-05-04 10:25:41 +0200
>>
>>

-- 
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/e912d9a5-6f4c-454d-b6c4-c4cfb469f9bfn%40googlegroups.com.

[git-users] Re: Git log --reverse gives less results. Is it a bug?

[Philip Oakley]

The `--reverse` problem pops up moderately often (OK occasionally). Usually 
it's not doing what you expect as to _when_ the reversal is applied. 

https://stackoverflow.com/questions/35379277/why-does-git-log-with-follow-and-reverse-return-only-last-commit

On Friday, May 5, 2023 at 12:29:56 AM UTC+1 aalexa...@gmail.com wrote:

> 0.md was moved into sub directory and now git log --reverse  can't find 
> its commits behind it, but works without --reverse. Is it a bug or I miss 
> something?
>
> $ git log --follow -M --format=%ai "0.md" 
> 2023-05-04 10:25:41 +0200 
> 2023-03-01 02:00:51 +0100 
> 2023-03-01 02:00:21 +0100 
> 2023-03-01 01:59:51 +0100 
> 2023-03-01 01:59:21 +0100 
> 2023-03-01 01:57:51 +0100 
> 2023-03-01 01:56:51 +0100 
> 2023-03-01 01:37:06 +0100 
> 2022-03-07 00:56:29 +0100 
> $ git log --reverse --follow -M --format=%ai "0.md" 
> 2023-05-04 10:25:41 +0200
>
>

-- 
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/511d43f6-354e-439f-8208-8f90f21672fcn%40googlegroups.com.

[git-users] Re: Git rules not being ignored from file that itself is ignored

[Peter Belbin]

Reading the post, this might have been not quite what I wanted to describe, 
so I'll take another run at it, with this:

Locally (not in the repo yet), I have the following files:

README.md
package.json
src
src/things1
src/things.ts
src/.eslintrc.json
src/thing1.js
src/things1/.gitignore
src/things1/things2
src/things1/things2/test.js
src/things1/things2/.gitignore
src/things1/things2/things3
src/things1/things2/test2.js
src/things1/things2/things3/test3.js

Within src/things1/things2/.gitignore I have the following rule:

/test2.js

*but*, within src/things1/.gitignore, I have the following rule:

things2/.gitignore

Using 

git status --untracked-files --porcelain

I see in the results that src/things1/things2/.gitignore is *not* included 
in the list, which agrees with what I expected to see.

However, I *also* do not see src/things1/things2/test2.js which is *not* 
what I expected.

Somehow, the *rules* from src/things1/things2/.gitignore have been applied 
even though this file will not be checked in.

How can this be??

Should not the rules in src/things1/things2/.gitignore have been *ignored*, 
since it's not going to be checked in?

Please advise.

Best Regards
Peter

-- 
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/d93e78cd-eb7a-483c-90bf-e1e886707591n%40googlegroups.com.

Re: [git-users] Re: Git Business Model?

['Sarah GOMEY' via Git for human beings]

Hi Konstantin,

Thank you so much for your answer! It's really clear now.

Have a nice day,
Sarah

Le mer. 1 mars 2023 à 17:34, Konstantin Khomoutov  a
écrit :

> On Wed, Mar 01, 2023 at 01:45:08AM -0800, 'Sarah GOMEY' via Git for human
> beings wrote:
>
> Disclaimer (which might get a bit more obvious later on): I (and anyone
> else
> on this mailing list) do not "represent Git" in any way; anything written
> below is my personal opinion.
>
> > Hope this email finds you well.
> > I'm a master student at ESSEC working on a research project on open
> source
> > and the business models built around it. We'd like to know more about
> Git:
>
> First thing first. Git is a piece of so-called free software [1], and as
> such,
> quite many things which are taken for granted when we discuss commercial
> software projects simply do not apply to Git.
>
> > How is it maintained?
>
> There exists an official "tree" (a regularly updated snapshot of the
> project)
> published using multiple venues including Github [2]. Most of the features
> there get integrated by the official maintainer - Junio Hamano [3], but
> other
> folks among the active developers have commit access to.
>
> Changes to Git gets discussed on a dedicated mailing list. Proposed code
> changes (patches and patch series) are supposed to be submitted directly to
> the mailing list as well, but there exist a helper Github-hosted tool to
> assist with drive-by contributions [4].
>
> Anyone if free to submit patches, report bugs and propose features. Patches
> and propositions are discussed - again, by anyone, - on the mailing list.
> Code reviews are usually made by the set of core developers - basically
> those
> who are active on the project.
> Some, but not all, of these developers are actually working in different
> commercial entities making use of Git (including, but not limited to,
> Microsoft and Google).
>
> Also note that there exist an "official" (in the sense of "being blessed"
> as
> such) "continuous fork" of Git intended to make Git work on Windows; it's
> called Git for Windows, is maintained separately but has similar licensing
> terms to Git. Some Windows-related code gets integrated into the baseline
> Git
> from time to time, and GfW generally closely follows the Git's release
> schedule. Some of the GfW developers are also Git's core developers.
>
> > Do you generate any revenue or is it solely based on
> > donations through the Software Freedom Conservancy?
>
> I would say this point does not apply to Git as it is not a so-called
> "open-core" project in the spirit of MySQL/MariaDB or GitLab - where the
> code
> is mainly controlled by a commercial entity which gives "the core part" for
> free, but you can pay for extra features. Git is fully free in this sense,
> and
> as such I would posit it does not generate any revenue "for itself". It may
> generate revenue for its commercial users - such as via paid plans on
> Github,
> but there it's Github which is "receiving" that revenue.
>
> > Since GitHub is built on Git, does Git have an agreement with them?
>
> The Git's license does not oblige any entity which uses it to participate
> in
> any agreement. Note that F/OSS licensing is about protecting the code (and
> its
> users) - as opposed to protecting intellectual property of an entity owning
> the code.
>
>  [1] https://en.wikipedia.org/wiki/Free_software
> 
>  [2] https://github.com/git/git
> 
>  [3] https://gitster.livejournal.com/
> 
>  [4] https://gitgitgadget.github.io/
> 
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/git-users/G8ibfZh5uQ4/unsubscribe
> 

[git-users] Re: Git Business Model?

[Konstantin Khomoutov]

On Wed, Mar 01, 2023 at 01:45:08AM -0800, 'Sarah GOMEY' via Git for human 
beings wrote:

Disclaimer (which might get a bit more obvious later on): I (and anyone else
on this mailing list) do not "represent Git" in any way; anything written
below is my personal opinion.

> Hope this email finds you well.
> I'm a master student at ESSEC working on a research project on open 
source 
> and the business models built around it. We'd like to know more about 
Git: 

First thing first. Git is a piece of so-called free software [1], and as 
such,
quite many things which are taken for granted when we discuss commercial
software projects simply do not apply to Git.

> How is it maintained?

There exists an official "tree" (a regularly updated snapshot of the 
project)
published using multiple venues including Github [2]. Most of the features
there get integrated by the official maintainer - Junio Hamano [3], but 
other
folks among the active developers have commit access to.

Changes to Git gets discussed on a dedicated mailing list. Proposed code
changes (patches and patch series) are supposed to be submitted directly to
the mailing list as well, but there exist a helper Github-hosted tool to
assist with drive-by contributions [4].

Anyone if free to submit patches, report bugs and propose features. Patches
and propositions are discussed - again, by anyone, - on the mailing list.
Code reviews are usually made by the set of core developers - basically 
those
who are active on the project.
Some, but not all, of these developers are actually working in different
commercial entities making use of Git (including, but not limited to,
Microsoft and Google).

Also note that there exist an "official" (in the sense of "being blessed" as
such) "continuous fork" of Git intended to make Git work on Windows; it's
called Git for Windows, is maintained separately but has similar licensing
terms to Git. Some Windows-related code gets integrated into the baseline 
Git
from time to time, and GfW generally closely follows the Git's release
schedule. Some of the GfW developers are also Git's core developers.

> Do you generate any revenue or is it solely based on 
> donations through the Software Freedom Conservancy?

I would say this point does not apply to Git as it is not a so-called
"open-core" project in the spirit of MySQL/MariaDB or GitLab - where the 
code
is mainly controlled by a commercial entity which gives "the core part" for
free, but you can pay for extra features. Git is fully free in this sense, 
and
as such I would posit it does not generate any revenue "for itself". It may
generate revenue for its commercial users - such as via paid plans on 
Github,
but there it's Github which is "receiving" that revenue.

> Since GitHub is built on Git, does Git have an agreement with them?

The Git's license does not oblige any entity which uses it to participate in
any agreement. Note that F/OSS licensing is about protecting the code (and 
its
users) - as opposed to protecting intellectual property of an entity owning
the code.

 [1] https://en.wikipedia.org/wiki/Free_software
 [2] https://github.com/git/git
 [3] https://gitster.livejournal.com/
 [4] https://gitgitgadget.github.io/


-- 
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/9b843fa2-de88-4207-9d67-7beb6af75093n%40googlegroups.com.

Re: [git-users] Re: git gc error with git 2.37.2?

[Konstantin Khomoutov]

On Tue, Jan 10, 2023 at 01:22:13PM -0800, Paul Wagland wrote:

> Did this patch ever end up getting merged in? I am seeing the problem again 
> in my repo with git 2.39.0, so was just wondering if this managed to make 
> it upstream
[...]

I think it did not manage to come through yet [1].
You might want to chime in on this, and if you will, be sure to read [2].

[...]
> >> I prepared a patch that should fix the issue for all users without any 
> >> workaround: 
> >> https://github.com/git/git/compare/master...Mortal:git:revision_resolve_undo_missing_blobs?expand=1
> >>
> >> I'll submit this patch shortly.

 1. https://lore.kernel.org/git/20221018175530.086c8c74@apus/
 2. 
https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list

-- 
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/20230110232146.yp77mol6bj6k6cgo%40carbon.

[git-users] Re: git gc error with git 2.37.2?

[Paul Wagland]

Hi Mathias,

Did this patch ever end up getting merged in? I am seeing the problem again 
in my repo with git 2.39.0, so was just wondering if this managed to make 
it upstream

Cheers,
Paul

On Wednesday, October 19, 2022 at 9:10:55 AM UTC+2 Paul Wagland wrote:

> Thanks Mathias!
>
> This patch seems to have gained some traction as well, so I am glad that 
> my pain lead to some improvement :-)
>
> Cheers,
> Paul
>
> On Tuesday, October 18, 2022 at 5:42:47 PM UTC+2 Mathias Rav wrote:
>
>> On Monday, October 17, 2022 at 8:27:44 PM UTC+2 Paul wrote:
>>
>>> Based on the above, I contacted the git list, and got a response from 
>>> Jeff:
>>> > It sounds like there's a resolve-undo extension in your index 
>>> that references that blob, but the blob was removed from the 
>>> repository (probably by a gc prior to 5a5ea141e7, which was trying to 
>>> prevent this corruption).
>>> >
>>> > I'd expect that the resolve-undo extension would eventually be 
>>> dropped once a merge is finished, but I'm not very familiar with that code. 
>>> Is the repository in question mid-merge, or does it happen all the time?
>>> >
>>> > If there are no changes you need to keep in the index or working 
>>> tree, I expect that a workaround would be:
>>> > 
>>> >  rm -f .git/index
>>> >  git reset
>>> >  git update-index --refresh
>>> >
>>> > to rewrite the index from scratch. Then the problem should not recur, 
>>> as you'd be using a version with 5a5ea141e7 from here on out.
>>>
>>> I did this, and my problem is now solved.
>>>
>>
>> That's a nice workaround - thanks!
>>
>> I prepared a patch that should fix the issue for all users without any 
>> workaround: 
>> https://github.com/git/git/compare/master...Mortal:git:revision_resolve_undo_missing_blobs?expand=1
>>
>> I'll submit this patch shortly.
>>
>> Cheers,
>> Mathias
>>
>

-- 
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/63a72056-5225-4c99-83c0-98fb6caaad39n%40googlegroups.com.

[git-users] Re: git gc error with git 2.37.2?

[Paul Wagland]

Thanks Mathias!

This patch seems to have gained some traction as well, so I am glad that my 
pain lead to some improvement :-)

Cheers,
Paul

On Tuesday, October 18, 2022 at 5:42:47 PM UTC+2 Mathias Rav wrote:

> On Monday, October 17, 2022 at 8:27:44 PM UTC+2 Paul wrote:
>
>> Based on the above, I contacted the git list, and got a response from 
>> Jeff:
>> > It sounds like there's a resolve-undo extension in your index 
>> that references that blob, but the blob was removed from the 
>> repository (probably by a gc prior to 5a5ea141e7, which was trying to 
>> prevent this corruption).
>> >
>> > I'd expect that the resolve-undo extension would eventually be 
>> dropped once a merge is finished, but I'm not very familiar with that code. 
>> Is the repository in question mid-merge, or does it happen all the time?
>> >
>> > If there are no changes you need to keep in the index or working 
>> tree, I expect that a workaround would be:
>> > 
>> >  rm -f .git/index
>> >  git reset
>> >  git update-index --refresh
>> >
>> > to rewrite the index from scratch. Then the problem should not recur, 
>> as you'd be using a version with 5a5ea141e7 from here on out.
>>
>> I did this, and my problem is now solved.
>>
>
> That's a nice workaround - thanks!
>
> I prepared a patch that should fix the issue for all users without any 
> workaround: 
> https://github.com/git/git/compare/master...Mortal:git:revision_resolve_undo_missing_blobs?expand=1
>
> I'll submit this patch shortly.
>
> Cheers,
> Mathias
>

-- 
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/579c0c45-983f-44cd-b154-99ca8c224020n%40googlegroups.com.

[git-users] Re: git gc error with git 2.37.2?

[Mathias Rav]

On Monday, October 17, 2022 at 8:27:44 PM UTC+2 Paul wrote:

> Based on the above, I contacted the git list, and got a response from Jeff:
> > It sounds like there's a resolve-undo extension in your index 
> that references that blob, but the blob was removed from the 
> repository (probably by a gc prior to 5a5ea141e7, which was trying to 
> prevent this corruption).
> >
> > I'd expect that the resolve-undo extension would eventually be 
> dropped once a merge is finished, but I'm not very familiar with that code. 
> Is the repository in question mid-merge, or does it happen all the time?
> >
> > If there are no changes you need to keep in the index or working tree, I 
> expect that a workaround would be:
> > 
> >  rm -f .git/index
> >  git reset
> >  git update-index --refresh
> >
> > to rewrite the index from scratch. Then the problem should not recur, 
> as you'd be using a version with 5a5ea141e7 from here on out.
>
> I did this, and my problem is now solved.
>

That's a nice workaround - thanks!

I prepared a patch that should fix the issue for all users without any 
workaround: 
https://github.com/git/git/compare/master...Mortal:git:revision_resolve_undo_missing_blobs?expand=1

I'll submit this patch shortly.

Cheers,
Mathias

-- 
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/9fe60708-008f-4bfa-bfa5-a7406ba9dc04n%40googlegroups.com.

[git-users] Re: git should not allow commit while in middle of rebase

[Philip Oakley]

I use it often to split a complex commit into independent parts, maybe even 
make one of those parts be a `fixup! ` commit.

If purposeful (first case) then you are already interactive and it feels 
sensible.

If it was an 'automatic' rebase (non-interactive until conflict) then you 
may find you still need to rearrange and split the commit into sensible 
parts, or even stash parts. [That reminds me, the git-gui doesn't have an 
easy stash option, which can also be useful]


On Tuesday, October 18, 2022 at 11:44:48 AM UTC+1 sameer.s...@gmail.com 
wrote:

> Hello,
>
> git should not allow commit while in middle of rebase but allow only 
> rebase --continue until all conflicts are resolved.
>
> are there any use cases where someone may want to commit in middle of 
> rebase before rebase --continue? 
>
> I know I shouldn't have done it but it has been a means of agony for me 
> some times :)
>
> thanks,
> Sameer
>

-- 
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/41cb6fe4-73e4-49dc-949e-fccc9dadf392n%40googlegroups.com.

[git-users] Re: git gc error with git 2.37.2?

[Paul Wagland]

Hi Mathias,

Based on the above, I contacted the git list, and got a response from Jeff:
> It sounds like there's a resolve-undo extension in your index 
that references that blob, but the blob was removed from the 
repository (probably by a gc prior to 5a5ea141e7, which was trying to 
prevent this corruption).
>
> I'd expect that the resolve-undo extension would eventually be 
dropped once a merge is finished, but I'm not very familiar with that code. 
Is the repository in question mid-merge, or does it happen all the time?
>
> If there are no changes you need to keep in the index or working tree, I 
expect that a workaround would be:
> 
>  rm -f .git/index
>  git reset
>  git update-index --refresh
>
> to rewrite the index from scratch. Then the problem should not recur, 
as you'd be using a version with 5a5ea141e7 from here on out.

I did this, and my problem is now solved.

Cheers,
Paul
On Monday, October 17, 2022 at 7:00:44 PM UTC+2 Paul Wagland wrote:

> Hi Mathias,
>
> I have not figured out a solution yet, I have just pinned my git to 2.37.1 
> and continued on, I haven't circled back to look at this yet.
>
> In the meantime 2.38.0 is also released, and that has the same issue for 
> me.
>
> I did some further testing based on your feedback, and building git 
> locally, I can confirm that git built with dc8c8deaa6 works for me, while 
> git built with 5a5ea141e7 fails with the aforementioned error.
>
> Cheers,
> Paul
>
> On Monday, October 17, 2022 at 4:49:58 PM UTC+2 Mathias Rav wrote:
>
>> On Friday, September 16, 2022 at 12:35:24 AM UTC+2 Paul wrote:
>>
>>> However, when I upgrade to git 2.37.2, or 2.37.3, git gc suddenly starts 
>>> to fail:
>>
>> fatal: unable to read 1d0f34d1c4314efcff527847755e4ccc77d44fb6
>>>
>>> fatal: failed to run repack
>>>
>> How can I work out what reference is causing this hash to be referenced? 
>>> I would most likely be perfectly happy to drop whatever reference it is, if 
>>> I could just move to a newer version of git, and continue using git gc.
>>>
>>
>> Hi Paul
>>
>> I have the same issue - did you figure this out yet?
>>
>> I suspect that this issue comes from the following commit:  
>> https://github.com/git/git/commit/5a5ea141e7 ("revision: mark blobs 
>> needed for resolve-undo as reachable", 2022-06-09)
>>
>> For me, a similar error message also appears when I simply run `git 
>> rev-list --objects --indexed-objects`.
>>
>> Commit 5a5ea141e7 added a function add_resolve_undo_to_pending(), which 
>> calls lookup_blob() and checks if that returns NULL. However as far as I 
>> can tell, lookup_blob() almost never returns NULL - it especially doesn't 
>> return NULL for arbitrary non-existent object ids.
>>
>> This is as far as I've gotten in my debugging of this error so far - I 
>> thought I'd share it here.
>>
>> Kind regards
>> Mathias Rav
>>
>

-- 
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/c2704644-91ea-45c4-a6b5-49767532ea43n%40googlegroups.com.

[git-users] Re: git gc error with git 2.37.2?

[Paul Wagland]

Hi Mathias,

I have not figured out a solution yet, I have just pinned my git to 2.37.1 
and continued on, I haven't circled back to look at this yet.

In the meantime 2.38.0 is also released, and that has the same issue for me.

I did some further testing based on your feedback, and building git 
locally, I can confirm that git built with dc8c8deaa6 works for me, while 
git built with 5a5ea141e7 fails with the aforementioned error.

Cheers,
Paul

On Monday, October 17, 2022 at 4:49:58 PM UTC+2 Mathias Rav wrote:

> On Friday, September 16, 2022 at 12:35:24 AM UTC+2 Paul wrote:
>
>> However, when I upgrade to git 2.37.2, or 2.37.3, git gc suddenly starts 
>> to fail:
>
> fatal: unable to read 1d0f34d1c4314efcff527847755e4ccc77d44fb6
>>
>> fatal: failed to run repack
>>
> How can I work out what reference is causing this hash to be referenced? I 
>> would most likely be perfectly happy to drop whatever reference it is, if I 
>> could just move to a newer version of git, and continue using git gc.
>>
>
> Hi Paul
>
> I have the same issue - did you figure this out yet?
>
> I suspect that this issue comes from the following commit:  
> https://github.com/git/git/commit/5a5ea141e7 ("revision: mark blobs 
> needed for resolve-undo as reachable", 2022-06-09)
>
> For me, a similar error message also appears when I simply run `git 
> rev-list --objects --indexed-objects`.
>
> Commit 5a5ea141e7 added a function add_resolve_undo_to_pending(), which 
> calls lookup_blob() and checks if that returns NULL. However as far as I 
> can tell, lookup_blob() almost never returns NULL - it especially doesn't 
> return NULL for arbitrary non-existent object ids.
>
> This is as far as I've gotten in my debugging of this error so far - I 
> thought I'd share it here.
>
> Kind regards
> Mathias Rav
>

-- 
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/ebb035c1-d313-4f8e-b850-a6e11eeb374bn%40googlegroups.com.

[git-users] Re: git gc error with git 2.37.2?

[Mathias Rav]

On Friday, September 16, 2022 at 12:35:24 AM UTC+2 Paul wrote:

> However, when I upgrade to git 2.37.2, or 2.37.3, git gc suddenly starts 
> to fail:
> fatal: unable to read 1d0f34d1c4314efcff527847755e4ccc77d44fb6
>
> fatal: failed to run repack
> How can I work out what reference is causing this hash to be referenced? I 
> would most likely be perfectly happy to drop whatever reference it is, if I 
> could just move to a newer version of git, and continue using git gc.
>

Hi Paul

I have the same issue - did you figure this out yet?

I suspect that this issue comes from the following commit:  
https://github.com/git/git/commit/5a5ea141e7 ("revision: mark blobs needed 
for resolve-undo as reachable", 2022-06-09)

For me, a similar error message also appears when I simply run `git 
rev-list --objects --indexed-objects`.

Commit 5a5ea141e7 added a function add_resolve_undo_to_pending(), which 
calls lookup_blob() and checks if that returns NULL. However as far as I 
can tell, lookup_blob() almost never returns NULL - it especially doesn't 
return NULL for arbitrary non-existent object ids.

This is as far as I've gotten in my debugging of this error so far - I 
thought I'd share it here.

Kind regards
Mathias Rav

-- 
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/9bfb2684-2e07-4ade-92bb-21853ab361bfn%40googlegroups.com.

[git-users] Re: git clone ssh key -i error

[Philippe Couas]

i,

I use git 2.37 on Windows 10 and i have an problem with git clone ssh

This command is Ok

ssh g...@127.0.0.1  -v -p 2223 -i 
Z:\zpoubelle\tssh4\id_rsa
But following command failed

set GIT_SSH_COMMAND="ssh -p 2223-i Z:\zpoubelle\tssh4\id_rsa"
git clone g...@127.0.0.1:2223/srv/git/your-repo.git 
 --verbose

"ssh -p 2223-i Z:\zpoubelle\tssh4\id_rsa": line 1: ssh -p 2223-i 
Z:\zpoubelle\tssh4\id_rsa: No such file or directory


Regards
Le mardi 4 octobre 2022 à 07:24:39 UTC+2, Philippe Couas a écrit :

> Hi,
>
> I use git 2.37 on Windows 10 and i have an problem with git clone ssh
>
> This command is Ok
>
> ssh g...@127.0.0.1 -v -p 2223 -i Z:\zpoubelle\tssh4\id_rsa
> But following command failed
>
> set GIT_SSH_COMMAND="ssh -p2223-i Z:\zpoubelle\tssh4\id_rsa"
> git clone g...@127.0.0.1:2223/srv/git/your-repo.git 
>  --verbose
>
> "ssh -p2223-i Z:\zpoubelle\tssh4\id_rsa": line 1: ssh -p2223-i 
> Z:\zpoubelle\tssh4\id_rsa: No such file or directory
>
>
> Regards
>

-- 
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/c616e2bc-1441-4eb2-a504-26604c899e22n%40googlegroups.com.

[git-users] Re: git fetch creates many threads

[xin ma]

Hello
is operating system thread
No specific amount will be created if not manually terminated
I have this problem on mac os or ubuntu
mac os version 10.14 
ubuntu 18.04
在2022年7月1日星期五 UTC+8 18:42:07 写道：

> How many is lots? Is it a case of just using the available processor 
> threads, or is it hundreds and thousands of OS threads?
>
> Some of the tasks can have elements that are run in parallel, so this 
> might be part of it.  
> Also do you have any of the File System monitor capability enabled 
> (haven't look if it was active in that version)
>
> Do the processes terminate when the fetch is complete?
>
> Which OS and version are you on?
> On Friday, July 1, 2022 at 11:21:18 AM UTC+1 zaodi...@gmail.com wrote:
>
>> hi everyone
>>   I am using git fetch under one repository and it will create a lot of 
>> threads, does anyone know about this problem?
>> git version 2.33.0
>>
>>

-- 
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/1afca7aa-0362-4b55-87ef-b9222710c5edn%40googlegroups.com.

[git-users] Re: git fetch creates many threads

[Philip Oakley]

How many is lots? Is it a case of just using the available processor 
threads, or is it hundreds and thousands of OS threads?

Some of the tasks can have elements that are run in parallel, so this might 
be part of it.  
Also do you have any of the File System monitor capability enabled (haven't 
look if it was active in that version)

Do the processes terminate when the fetch is complete?

Which OS and version are you on?
On Friday, July 1, 2022 at 11:21:18 AM UTC+1 zaodi...@gmail.com wrote:

> hi everyone
>   I am using git fetch under one repository and it will create a lot of 
> threads, does anyone know about this problem?
> git version 2.33.0
>
>

-- 
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/c7de178b-c653-4fb7-9f0d-d16d444117een%40googlegroups.com.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[Philip Oakley]

GfW is an abbreviation for Git for Windows' - I think I'd introduced it
earlier in one of the posts.

The "Native" size for Windows, in backwards compatibility terms (which
is at the "compiled binary" level") is 32 bits, i.e. old code runs
without change. Hence the addition of "long long" by Microsoft on Windows.

Linux took the opposite view of backwards compatibility (which is at the
source code level), so to a full step up to 64 bit long (it's in the
POSIX spec).

Horses for courses. Clydesdale vs Arabian/Thoroughbred.

On 04/03/2022 06:35, skybuck2000 wrote:
>
>
> On Thursday, March 3, 2022 at 11:42:54 AM UTC+1 Konstantin Khomoutov
> wrote:
>
> On Wed, Mar 02, 2022 at 06:03:46PM +, Skybuck Flying wrote:
>
> >> Search for "4GB" in this blog post [1] which discusses the GfW
> 2.35 release
> >> notes.
> >>
> >> 1. https://github.blog/2022-01-24-highlights-from-git-2-35/
>
> > Thanks for the update, however I don't see how this could effect
> git
> > checkout of linux kernel, since most linux source files are only
> a few
> > kilobytes...
>
> Because Git has several data storage/transfer optimization tricks.
> One of them
> is using of so-called "pack files" (basically that's the
> behind-the-scenes
> mechanism that allows Git to remain fast and have modest storage
> requirements
> while its data model states that each commit is a snapshot of the
> whole
> project). Pack files are used for both storing stuff on the
> filesystem, and
> for data transfer; they basically are gzipped archives with added
> index files
> for fast random access to the contained data.
>
>
> Depends on how these pack files are used, if only parts of them are
> read/written then it does not need to be a problem :)
>
> Also I did not see any big spikes in memory consumption, at least when
> I was paying attention.
>  
>
>
> My take is that processing of such a pack file hits some limit of
> the current
> GfW implementation, which has nothing to do with the OS limits
> (given that
> up-to-date API calls are used).
>
>
> What is GfW ?
>
> Firefox also fails regularly when many tabs open, it only does this
> when pagefile.sys is off.
>
> So as far as I am concerned it clearly has something to do with the
> memory system in windows which is probably less well tested when
> pagefile.sys is off because most systems/default installation have a
> pagefile.sys, therefore I recommend any serious programmer working on
> serious project to turn off pagefile.sys or swap space and observe the
> memory system ! I am sure you will be surprised ! =D
>  
>
>
> While I think such problems were actually solved some time ago,
> some may still
> remain. In any case, it's hard to say something w/o proper bug
> report - either
> in the project's tracker of at least on the git-for-windows
> mailing list.
>
>
> Why would that make any difference ? Are you hoping for developer
> feedback on this issue ?
>
> I did mention the error message but in case you missed it here it is
> one more time:
>
> fatal: Out of memory, malloc failed (tried to allocate 214601 bytes)
> fatal: index-pack failed 
>
> So from this I can see two things:
>
> 1. It was trying to allocate a 214 kilobyte block which is quite large
> and makes the fragmentation hypothesis somewhat believable since
> windows uses 4 kilobyte pages as far as I know and these are stored in
> "lists". So to forfill this request it needs  214601 / 4096 = 53
> pages. Now maybe a statiscian can somehow calculate the chance of 53
> consequetive pages being present without any gaps/missing ones,
> especially when the system is under heavy use trying to create many
> little C files or whatever it was doing. From what I remember it was
> resolving deltas... so it seems git was "replaying" changes and these
> could be made out of many many many little changes, hence this makes
> the memory fragmentation hypothesis believeable.
>
> Also what kind of file would need 214 kilobytes ? Perhaps linux has a
> file of that size, maybe some documentation or so, though I have also
> seen big lookup tables in other software like bitcoin 256psek or
> something and pascalcoin and regex/unicode lookup table which is
> slowing down or freezing analysis tools so this is not good.
>
> 2. Indeed it's doing something with an index-pack file... so this is
> probably what you based your analysis on so you did read the bug/error
> report that I posted :)
> So this could mean it was extracting something or maybe indeed packing
> something up, but it wasn't that big... and it was computing some
> index file.
>
> For now the easy assumption is to assume the system simply run out of
> memory, but this is a suspicious/somewhat bad conclusion because the
> chart in the video does not really back that hypothesis up, and also
> as far as I can re-call the browser was not crashing and seemed to be
> doing 

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

On Thursday, March 3, 2022 at 3:54:25 PM UTC+1 philip...@iee.email wrote:

> > Am I correct in that the work to make mainline Git use size_t where 
> applicable 
> is ongoing? 
>
> It's currently a little stalled, because it's been hard to partition the 
> problem into small chunks that fit everyone's expectations about what 
> should be in or out for tidying up consequences (e.g. large call chains). 
>
> It's not really clear if "size_t" is considered a nice data type, along 
> with `ssize_t` to be replacing `ulong` and `long`, as they tend to make the 
> code feel "ugly". 
>

Consider porting git to Delphi =D

Anyway here is a tip from the Delphi world, in Delphi there is this type 
called:

NativeInt

and

NativeUInt

These two types auto-adjust to the maximum/natural integer size of the 
system.

So if it's 32 bit NativeInt would be 4 bytes.
So if it's 64 bit NativeInt would be 8 bytes

I think this is a much nicer description than size_t or ssize_t LOL.

Bye,
  Skybuck =D

-- 
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/d837f25f-61b9-454a-a6ee-f0694da73575n%40googlegroups.com.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

On Thursday, March 3, 2022 at 11:42:54 AM UTC+1 Konstantin Khomoutov wrote:

> On Wed, Mar 02, 2022 at 06:03:46PM +, Skybuck Flying wrote: 
>
> >> Search for "4GB" in this blog post [1] which discusses the GfW 2.35 
> release 
> >> notes. 
> >> 
> >> 1. https://github.blog/2022-01-24-highlights-from-git-2-35/ 
>
> > Thanks for the update, however I don't see how this could effect git 
> > checkout of linux kernel, since most linux source files are only a few 
> > kilobytes... 
>
> Because Git has several data storage/transfer optimization tricks. One of 
> them 
> is using of so-called "pack files" (basically that's the behind-the-scenes 
> mechanism that allows Git to remain fast and have modest storage 
> requirements 
> while its data model states that each commit is a snapshot of the whole 
> project). Pack files are used for both storing stuff on the filesystem, 
> and 
> for data transfer; they basically are gzipped archives with added index 
> files 
> for fast random access to the contained data. 
>

Depends on how these pack files are used, if only parts of them are 
read/written then it does not need to be a problem :)

Also I did not see any big spikes in memory consumption, at least when I 
was paying attention.
 

>
> My take is that processing of such a pack file hits some limit of the 
> current 
> GfW implementation, which has nothing to do with the OS limits (given that 
> up-to-date API calls are used). 
>

What is GfW ?

Firefox also fails regularly when many tabs open, it only does this when 
pagefile.sys is off.

So as far as I am concerned it clearly has something to do with the memory 
system in windows which is probably less well tested when pagefile.sys is 
off because most systems/default installation have a pagefile.sys, 
therefore I recommend any serious programmer working on serious project to 
turn off pagefile.sys or swap space and observe the memory system ! I am 
sure you will be surprised ! =D
 

>
> While I think such problems were actually solved some time ago, some may 
> still 
> remain. In any case, it's hard to say something w/o proper bug report - 
> either 
> in the project's tracker of at least on the git-for-windows mailing list. 
>

Why would that make any difference ? Are you hoping for developer feedback 
on this issue ?

I did mention the error message but in case you missed it here it is one 
more time:

fatal: Out of memory, malloc failed (tried to allocate 214601 bytes)
fatal: index-pack failed  

So from this I can see two things:

1. It was trying to allocate a 214 kilobyte block which is quite large and 
makes the fragmentation hypothesis somewhat believable since windows uses 4 
kilobyte pages as far as I know and these are stored in "lists". So to 
forfill this request it needs  214601 / 4096 = 53 pages. Now maybe a 
statiscian can somehow calculate the chance of 53 consequetive pages being 
present without any gaps/missing ones, especially when the system is under 
heavy use trying to create many little C files or whatever it was doing. 
>From what I remember it was resolving deltas... so it seems git was 
"replaying" changes and these could be made out of many many many little 
changes, hence this makes the memory fragmentation hypothesis believeable.

Also what kind of file would need 214 kilobytes ? Perhaps linux has a file 
of that size, maybe some documentation or so, though I have also seen big 
lookup tables in other software like bitcoin 256psek or something and 
pascalcoin and regex/unicode lookup table which is slowing down or freezing 
analysis tools so this is not good.

2. Indeed it's doing something with an index-pack file... so this is 
probably what you based your analysis on so you did read the bug/error 
report that I posted :)
So this could mean it was extracting something or maybe indeed packing 
something up, but it wasn't that big... and it was computing some index 
file.

For now the easy assumption is to assume the system simply run out of 
memory, but this is a suspicious/somewhat bad conclusion because the chart 
in the video does not really back that hypothesis up, and also as far as I 
can re-call the browser was not crashing and seemed to be doing fine, now 
maybe it simply had enough memory to do it's thing, but usually the browser 
can suddenly take up a lot of memory and crash quite easily... then 
again... since git is using many little files... maybe it just hit it 
sooner and is more sensitive to out of memory or something, though it could 
also be memory fragmentation or a combination. For now the memory 
fragmentation or in combination with system cache taking up precious memory 
is believeable because other people have noticed strange behaviour with 
windows 7.


> By the way, do you use a 64-bit install? If, for some reason, you're using 
> a 
> 32-bit version, the limit of circa 4 GB (actaually lower) will be 
> "native". 
>
>
new@new-PC MINGW64 /
$ file $( which git )
/mingw64/bin/git: PE32+ executable 

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[Philip Oakley]

> Am I correct in that the work to make mainline Git use size_t where 
applicable 
is ongoing? 

It's currently a little stalled, because it's been hard to partition the 
problem into small chunks that fit everyone's expectations about what 
should be in or out for tidying up consequences (e.g. large call chains). 

It's not really clear if "size_t" is considered a nice data type, along 
with `ssize_t` to be replacing `ulong` and `long`, as they tend to make the 
code feel "ugly". 

On Thursday, March 3, 2022 at 1:44:19 PM UTC Konstantin Khomoutov wrote:

> On Thu, Mar 03, 2022 at 03:03:34AM -0800, Philip Oakley wrote:
>
> >> By the way, do you use a 64-bit install? If, for some reason, you're 
> using
> >> a 32-bit version, the limit of circa 4 GB (actaually lower) will be
> >> "native". 
> > 
> > The Git code is merely POSIX compliant (long == size_t; LP64), while Git 
> > for Windows uses LLP64 (long=32bits; long long == size_t).
> > Vast swathe's of the Git code use long and size_t interchangeably, 
> meaning 
> > that GfW is limited, in the main, to 4GB file sizes and 2GB if (signed) 
> int 
> > is used. The Git LFS implementation part has been fixed, as long as the 
> >2GB
> > files are stored in LFS, which does handle the large files. However 
> > that isn't pure Git, so hash oids change, etc.
> > 
> > Hope that clarifies.
>
> Thanks!
>
> Am I correct in that the work to make mainline Git use size_t where 
> applicable
> is ongoing?
>
>

-- 
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/76c52864-b8f9-43ef-9f66-bf7f5edc2830n%40googlegroups.com.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[Konstantin Khomoutov]

On Thu, Mar 03, 2022 at 03:03:34AM -0800, Philip Oakley wrote:

>> By the way, do you use a 64-bit install? If, for some reason, you're using
>> a 32-bit version, the limit of circa 4 GB (actaually lower) will be
>> "native". 
> 
> The Git code is merely POSIX compliant (long == size_t; LP64), while Git 
> for Windows uses LLP64 (long=32bits; long long == size_t).
> Vast swathe's of the Git code use long and size_t interchangeably, meaning 
> that GfW is limited, in the main, to 4GB file sizes and 2GB if (signed) int 
> is used. The Git LFS implementation part has been fixed, as long as the >2GB
> files are stored in LFS, which does handle the large files. However 
> that isn't pure Git, so hash oids change, etc.
> 
> Hope that clarifies.

Thanks!

Am I correct in that the work to make mainline Git use size_t where applicable
is ongoing?

-- 
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/20220303134412.6lr2qr3p5x2agio7%40carbon.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[Philip Oakley]

> By the way, do you use a 64-bit install? If, for some reason, you're 
using a 
32-bit version, the limit of circa 4 GB (actaually lower) will be "native". 

The Git code is merely POSIX compliant (long == size_t; LP64), while Git 
for Windows uses LLP64 (long=32bits; long long == size_t).
Vast swathe's of the Git code use long and size_t interchangeably, meaning 
that GfW is limited, in the main, to 4GB file sizes and 2GB if (signed) int 
is used. The Git LFS implementation part has been fixed, as long as the 
>2GB files are stored in LFS, which does handle the large files. However 
that isn't pure Git, so hash oids change, etc.

Hope that clarifies.

On Thursday, March 3, 2022 at 10:42:54 AM UTC Konstantin Khomoutov wrote:

> On Wed, Mar 02, 2022 at 06:03:46PM +, Skybuck Flying wrote:
>
> >> Search for "4GB" in this blog post [1] which discusses the GfW 2.35 
> release
> >> notes.
> >> 
> >> 1. https://github.blog/2022-01-24-highlights-from-git-2-35/
>
> > Thanks for the update, however I don't see how this could effect git
> > checkout of linux kernel, since most linux source files are only a few
> > kilobytes...
>
> Because Git has several data storage/transfer optimization tricks. One of 
> them
> is using of so-called "pack files" (basically that's the behind-the-scenes
> mechanism that allows Git to remain fast and have modest storage 
> requirements
> while its data model states that each commit is a snapshot of the whole
> project). Pack files are used for both storing stuff on the filesystem, and
> for data transfer; they basically are gzipped archives with added index 
> files
> for fast random access to the contained data.
>
> My take is that processing of such a pack file hits some limit of the 
> current
> GfW implementation, which has nothing to do with the OS limits (given that
> up-to-date API calls are used).
>
> While I think such problems were actually solved some time ago, some may 
> still
> remain. In any case, it's hard to say something w/o proper bug report - 
> either
> in the project's tracker of at least on the git-for-windows mailing list.
>
> By the way, do you use a 64-bit install? If, for some reason, you're using 
> a
> 32-bit version, the limit of circa 4 GB (actaually lower) will be "native".
>
>

-- 
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/45c2c1e3-18e7-4af8-87c9-123544b7699en%40googlegroups.com.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[Konstantin Khomoutov]

On Wed, Mar 02, 2022 at 06:03:46PM +, Skybuck Flying wrote:

>> Search for "4GB" in this blog post [1] which discusses the GfW 2.35 release
>> notes.
>> 
>> 1. https://github.blog/2022-01-24-highlights-from-git-2-35/

> Thanks for the update, however I don't see how this could effect git
> checkout of linux kernel, since most linux source files are only a few
> kilobytes...

Because Git has several data storage/transfer optimization tricks. One of them
is using of so-called "pack files" (basically that's the behind-the-scenes
mechanism that allows Git to remain fast and have modest storage requirements
while its data model states that each commit is a snapshot of the whole
project). Pack files are used for both storing stuff on the filesystem, and
for data transfer; they basically are gzipped archives with added index files
for fast random access to the contained data.

My take is that processing of such a pack file hits some limit of the current
GfW implementation, which has nothing to do with the OS limits (given that
up-to-date API calls are used).

While I think such problems were actually solved some time ago, some may still
remain. In any case, it's hard to say something w/o proper bug report - either
in the project's tracker of at least on the git-for-windows mailing list.

By the way, do you use a 64-bit install? If, for some reason, you're using a
32-bit version, the limit of circa 4 GB (actaually lower) will be "native".

-- 
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/20220303104249.7b2ckatvx52rg4mj%40carbon.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

Hi,

My latest hypothesis what might have happened during that normal git 
checkout on linux kernel is that there was some kind of memory 
fragmentation and windows could not return enough memory.

Test programs could be written to test this hypothesis but I have no time 
for this.

Bye,
  Skybuck.

-- 
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/5d96ea15-0a25-4b45-a434-030703157853n%40googlegroups.com.

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

['Salvador Garcia' via Git for human beings]

Skybuck, maybe this will help clear up this issue:
https://www.helpndoc.com/documentation/html/Windowsreservedfilenames.html
Saga


-Original Message-
From: skybuck2000 
To: Git for human beings 
Sent: Mon, Feb 28, 2022 12:47 am
Subject: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB 
system

Oh, Oh...
So while I was waiting for the linux kernel to checkout I was reading some 
random stuff about operating systems, or mostly linux boot loaders other os 
loaders and some people on github involved with linux and then I switch back to 
the linux checkout and I notice this:
new@new-PC MINGW64 /e/SourceCode/LinuxKernelWorkAround
$ git clone https://github.com/SkybuckFlying/linux.git
Cloning into 'linux'...
remote: Enumerating objects: 8590563, done.
remote: Counting objects: 100% (23/23), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 8590563 (delta 9), reused 0 (delta 0), pack-reused 8590540
Receiving objects: 100% (8590563/8590563), 3.49 GiB | 9.28 MiB/s, done.
fatal: Out of memory, malloc failed (tried to allocate 214601 bytes)
fatal: index-pack failed
BM... failed.
SUCKS.
My recommendation is to PAUSE git if it runs out of memory cause enabling 
pagefile.sys is a big fat no-no as far as I am concerned and I am never ever 
going back to pagefile.sys or any other disk caching technology cause it SLOWS 
down my SYSTEM(S) incredibly and therefore IT SUCKS.
This crash of git was probably caused by the memory consumption of firefox and 
webpages and blabla.
But fear not I will try again over"night" when I go to "sleep" (don't hack me 
bro hahaha !) and then my poor little laptop with 6 GBs of RAM can try one more 
time without me fucking up the process by taking up RAM bleh.
And if that fails... well holy fok ! At least the shallow clone trick worked 
but common THIS IS GIT.
So FAR GIT was pretty good, but this is the first time GIT massively FAILS and 
is not capable of copeing with THE SKYBUCK LOL.
You know I have better things to do then wait 6 hours for a linux git checkout 
?! Do you see my point ?!
This is definetly something where GIT should be made more reliable !
Don't give me wrong, GIT impresses me many times, but this one 
NPPPE p: p: p: THUMBS DOWN.
Invest some of your time writing out of memory resistant computer programs/GIT 
versions it may be worth it someday when we hit BIG FAT TRANSISTOR scaling 
down/up issues whatever. HAHA.
Memory does not grow on trees lol. SOME DAY moore's lllaw will come to an 
END... start preparing for it ! 

Here is some helpfull hints:
TryAlloc
instead
of Alloc
write it like
if TryAlloc(...){
}
OK ?
Believe me it's not that hard, it just requires some time.
And in case you didn't get it here is how you may implement TryAlloc
int TryAlloc( ...){  try
 Alloc return true
  catch exptions
    return false
}

Something like that.
Good luck !
One last tip, also check for storage space if git runs out of storage space.
Pause the program, possibly with a dialog screen or even better, terminate the 
command and make it possible to continue the command later... if that is too 
difficult... at least pausethe command and make the user hit a button to 
continue and try again.
Again not that hard and well worth it.
This allows the users to free up space, to continue these kinds of long 
processes.
And let's be honest there is no indicator how much space a checkout requires so 
sooner or later people will run out of space.
For now with big terrabyte disks, not yet a problem... then again... my disks 
after a few years pretty full, cause there is so much fun toy stuff out 
there... and again moore's law will strike the harddisk world as well someday ! 
Prepare for it ! Yeah
And in cause you don't believe me my own UDP File Transfer already does all of 
it that I wrote above :P*
Yes and I have also have an unreleased version which can do 64 bit file 
transfer instead of just 32 bits.
Perhaps a simpler program then again it's also complex enough that it proves it 
can be done (in Delphi and I am sure C/C++ can do it as well, cause Delphi is 
mostly a subset of C/C++)

Bye,  Skybuck.  (I mean it, get this done !)-- 
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/e600184e-911a-4647-9fd9-d596976f9093n%40googlegroups.com.

-- 
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/453361847.3453961.1646063763468%40mail.yahoo.com.

[git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

Oh, Oh...

So while I was waiting for the linux kernel to checkout I was reading some 
random stuff about operating systems, or mostly linux boot loaders other os 
loaders and some people on github involved with linux and then I switch 
back to the linux checkout and I notice this:

new@new-PC MINGW64 /e/SourceCode/LinuxKernelWorkAround
$ git clone https://github.com/SkybuckFlying/linux.git
Cloning into 'linux'...
remote: Enumerating objects: 8590563, done.
remote: Counting objects: 100% (23/23), done.
remote: Compressing objects: 100% (23/23), done.
remote: Total 8590563 (delta 9), reused 0 (delta 0), pack-reused 8590540
Receiving objects: 100% (8590563/8590563), 3.49 GiB | 9.28 MiB/s, done.
fatal: Out of memory, malloc failed (tried to allocate 214601 bytes)
fatal: index-pack failed

BM... failed.

SUCKS.

My recommendation is to PAUSE git if it runs out of memory cause enabling 
pagefile.sys is a big fat no-no as far as I am concerned and I am never 
ever going back to pagefile.sys or any other disk caching technology cause 
it SLOWS down my SYSTEM(S) incredibly and therefore IT SUCKS.

This crash of git was probably caused by the memory consumption of firefox 
and webpages and blabla.

But fear not I will try again over"night" when I go to "sleep" (don't hack 
me bro hahaha !) and then my poor little laptop with 6 GBs of RAM can try 
one more time without me fucking up the process by taking up RAM bleh.

And if that fails... well holy fok ! At least the shallow clone trick 
worked but common THIS IS GIT.

So FAR GIT was pretty good, but this is the first time GIT massively FAILS 
and is not capable of copeing with THE SKYBUCK LOL.

You know I have better things to do then wait 6 hours for a linux git 
checkout ?! Do you see my point ?!

This is definetly something where GIT should be made more reliable !

Don't give me wrong, GIT impresses me many times, but this one 
NPPPE p: p: p: THUMBS DOWN.

Invest some of your time writing out of memory resistant computer 
programs/GIT versions it may be worth it someday when we hit BIG FAT 
TRANSISTOR scaling down/up issues whatever. HAHA.

Memory does not grow on trees lol. SOME DAY moore's lllaw will come to an 
END... start preparing for it ! 

Here is some helpfull hints:

TryAlloc

instead

of Alloc

write it like

if TryAlloc(...)
{

}

OK ?

Believe me it's not that hard, it just requires some time.

And in case you didn't get it here is how you may implement TryAlloc

int TryAlloc( ...)
{
  try
 Alloc
 return true
  catch exptions
return false
}

Something like that.

Good luck !

One last tip, also check for storage space if git runs out of storage space.

Pause the program, possibly with a dialog screen or even better, terminate 
the command and make it possible to continue the command later... if that 
is too difficult... at least pause
the command and make the user hit a button to continue and try again.

Again not that hard and well worth it.

This allows the users to free up space, to continue these kinds of long 
processes.

And let's be honest there is no indicator how much space a checkout 
requires so sooner or later people will run out of space.

For now with big terrabyte disks, not yet a problem... then again... my 
disks after a few years pretty full, cause there is so much fun toy stuff 
out there... and again moore's law will strike the harddisk world as well 
someday ! Prepare for it ! Yeah

And in cause you don't believe me my own UDP File Transfer already does all 
of it that I wrote above :P*

Yes and I have also have an unreleased version which can do 64 bit file 
transfer instead of just 32 bits.

Perhaps a simpler program then again it's also complex enough that it 
proves it can be done (in Delphi and I am sure C/C++ can do it as well, 
cause Delphi is mostly a subset of C/C++)

Bye,
  Skybuck.  (I mean it, get this done !)

-- 
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/e600184e-911a-4647-9fd9-d596976f9093n%40googlegroups.com.

[git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

It doesn't hurt to have a little bit of redundancy, especially for 
something as "important" as the linux kernel lol:

(Copy & Pasting this posting/solution to this thread as well)

For now the solution I came up with is to:

1. Trust that this github repository is from "official sources":

https://github.com/torvalds/linux

2. Clone it.

3. Rename these 3 files remotely/on the repository via github and it's file 
editing feature, which fortunately also allows a rename of file.

error: invalid path 'drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c'
error: invalid path 'drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h'
error: invalid path 'include/soc/arc/aux.h' 

To 

WorkAroundAux.c and such.

By the way, this "aux" is a limitation inside NTFS file system, so linux 
can be affected as well. Also directories with aux in it will have the same 
problem.
Not sure if "auxbla" or 'blaaux" will cause it. For now I assume that if it 
starts with "aux" it's illegal.

I haven't tried yet, but I am pretty sure this is going to work. If not 
then I will report back here. If I run into any other problem, then maybe 
too or I go into that other thread if 6 GB of RAM is not enough to checkout 
the linux kernel ;) ;) ;) yes winks... that could be another reason, to 
never use one of these systems for any serious source code work, because 
again that would be horrible not to be able to access your source code :P*

Oh yeah before I forget, why is this:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

It does not mention the linux repository on github ?

Is the Linus Torvalds account on github REAL ? Or is it fake ? Is there 
anyway to be sure ? Maybe some kind of signature check from a mailing list 
or something where he announces he joined github ?

This is supposed to be his account: is it real ?

https://github.com/torvalds

If it is real then why does it not mention so on this page ?:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

Bye for now,
  Skybuck =D

-- 
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/978dd2b3-372c-44fd-b214-8fcbcec9bfeen%40googlegroups.com.

[git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

Hello,

I am back in this thead on 28 february 2022. I read that linux will soon 
move to a new compiler/c language version, from C89 to C11 so I thought I 
would try again to checkout the linux kernel so that I can see what it 
looks like.

But surprise surprise, it fails again.

This time I record it on video, since nowadays I have streaming software on 
this 6 GB RAM toshiba laptop that can stream directly to youtube saving me 
a lot of time.

So it turns out that 3 files cannot be checked out because they start with 
the filename: "aux" and this is forbidden on windows 7 at least and also 
windows 10 according to other people.

Link to youtube video that shows the problem at timestamp 8 minutes and 20 
seconds: 

https://youtu.be/n15JnFgaxKs

I think this is what might have happened the first time I tried this, 
making me believe it may have been some out of memory situation or maybe I 
was running a virtual machine and the memory was divided in two pieces 3 
gigabyte each. But this time the laptop had 6 GB of RAM. Still 2 gigabyte 
free when this error occured.

So I no longer believe it's an out of memory situation, but something 
entirely else. Some kind of bug possibily deep within git, git may have to 
work around this and simply skip over files that have illegal file names on 
windows. or should try and rename it.

Anyway is there a solution that would allow me to checkout most of it ? 
Cause I just want to have a looksy that is all for now.

Bye,
  Skybuck.



-- 
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/b2e43080-9b6a-4fa6-a322-f86261226447n%40googlegroups.com.

[git-users] Re: git bash undo paste

[skybuck2000]

NOW IT SUDDENLY DOES WORK CONTROL-U

I HAVE NO IDEA WHY...

WHAT AN INCONSISTENT BEHAVING PIECE OF SHIT SOFTWARE.

BYE,
  SKYBUCK.

-- 
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/5435b6c9-e51d-43f7-8e6e-0836df98e87bn%40googlegroups.com.

[git-users] Re: git bash undo paste

[skybuck2000]

THIS SHIT DONT WORK, NOTHING WORSE THAN MANUAL WRONG TOO:

https://gist.github.com/tuxfight3r/60051ac67c5f0445efee

DOES NOT WORK WHEN IN INSERT MODE

HAVE TO BE IN INSERT MODE TO TYPE SHIT.


HAS THE WORLD GONE INSANE OH MY GOD..


I HATE THE FUCKERS THAT CREATE THIS BULLSHIT

CONTROL _ FOR UNDO ARE YOU INSANE ?! HOW THE FUCK ARE MY HANDS TO MAKE THAT 
COMBO ?! HOLYSHIT.

YOU WANT ME TO HOLD SHIFT TOO ?! FUCK YOU.

SORRY.

BYE,
  SKYBUCK.

-- 
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/b74fe9ba-da81-499a-84e6-f58ebf1320e7n%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

This may solve the white commit hash id problem:

https://stackoverflow.com/questions/11515089/why-no-yellow-in-powershell-and-posh-git

"
It turns out PowerShell's console renders System.ConsoleColor.DarkYellow as 
white:
[Enum]::GetValues([ConsoleColor]) | %{ Write-Host $_ -ForegroundColor $_ } 

Using bold yellow instead, which renders with System.ConsoleColor.Yellow, 
works:
git log --pretty='%C(bold yellow)%h%Creset %s' --abbrev-commit 
"

I will investigate this soon/probably tomorrow.

Bye,
  Skybuck.

-- 
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/a87e01fb-7a2d-4fd4-926a-e32b4b8bea07n%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

I am getting a small smile on my face ! =D

Powershell now looks pretty beautifull and distinsquashed.

I did it as follows:

changed the font to lucida console point size 12
changed screen background color to black
changed screen text to silver

the last change makes the commit hashes pop-out in white and the rest of 
the text in fainter white/grayish/silverish...

looks very beautifull.

Perhaps later I might investigate if it's possible to make the git commit 
hashes look yelllow, but I kinda like this white-ish look... it  feels more 
valuable... yellow feels more like PISS lol.

The only thing I still dislike somewhat is the red it's a bit too dark for 
origin/remote and such... but liveable.

Bye for now,
  Skybuck.

On Thursday, December 30, 2021 at 9:19:20 AM UTC+1 skybuck2000 wrote:

> LOLOLOLOLOLOLOL.
>
> POWERSHELL + GIT-POSH SOLVES IT !!!
>
> Q stays on the same line !
>
> HAHAHAHAHAHA MICROSOFT+POSH JUST OWNED YOU LINUX BITCHES.
>
> BUT NOW ALL IS WELL THE COLORS ARE A LITTLE BIT LESS BEAUTIFULL 
> CYBERPUNKY...
>
> MAYBE I CHANGE THAT LATER MAYBE NOT...
>
> CONTINUEING.
>
> BYE,
>   SKYBUCK.
>

-- 
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/9d5f43ec-18f9-4107-ab20-bd869c418fbfn%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

LOLOLOLOLOLOLOL.

POWERSHELL + GIT-POSH SOLVES IT !!!

Q stays on the same line !

HAHAHAHAHAHA MICROSOFT+POSH JUST OWNED YOU LINUX BITCHES.

BUT NOW ALL IS WELL THE COLORS ARE A LITTLE BIT LESS BEAUTIFULL 
CYBERPUNKY...

MAYBE I CHANGE THAT LATER MAYBE NOT...

CONTINUEING.

BYE,
  SKYBUCK.

-- 
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/0c83eaee-a8c4-4c91-b51e-16812de36cb8n%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

For today I am fed up with mintty/git bash which is slow, and buggy as 
hell, and cmd.exe looks terrible and has no nice colors.

Time to try something else:

Windows 11 powershell and this:

posh-git by dahlbyk 

Maybe this will be better, time to find out ! =D

Bye,
  Skybuck.

-- 
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/1c3a0f6d-9d2f-4b72-9cad-4201bf222665n%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

pascalcoin change " into '

still don't work when rlog or olog types,

output:


Skybuck@DESKTOP-0T9FP82 MSYS /usr/bin
$ alias
cd..='cd ..'
e:='cd e:'
ll='ls -l'
ls='ls -F --color=auto --show-control-chars'
olog='git --no-pager log --all --graph --decorate --oneline --color=always 
| tac | sed -e "s/[\\]/aa/g" -e "s/[/]//g" -e 
"s/aa///g" | less -r +G -X'
pascalcoin='cd e:\SourceCode\PascalCoinGit\PascalCoin'
rlog='git --no-pager log --all --graph --decorate --color=always | tac | 
sed -e "s/[\\]/aa/g" -e "s/[/]//g" -e 
"s/aa///g" | less -r +G -X'

Skybuck@DESKTOP-0T9FP82 MSYS /usr/bin
$ pascalcoin
sh: cd: e:SourceCodePascalCoinGitPascalCoin: No such file or directory

Skybuck@DESKTOP-0T9FP82 MSYS /usr/bin
$ e:

Skybuck@DESKTOP-0T9FP82 MSYS /e
$ cd SourceCode

Skybuck@DESKTOP-0T9FP82 MSYS /e/SourceCode
$ cd PascalCoinGit

Skybuck@DESKTOP-0T9FP82 MSYS /e/SourceCode/PascalCoinGit
$ cd PascalCoin

Skybuck@DESKTOP-0T9FP82 MSYS /e/SourceCode/PascalCoinGit/PascalCoin 
(ReCommit)
$ olog
sed: -e expression #3, char 17: unknown option to `s'
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
...skipping...
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~

Skybuck@DESKTOP-0T9FP82 MSYS /e/SourceCode/PascalCoinGit/PascalCoin 
(ReCommit)
$ rlog
sed: -e expression #3, char 17: unknown option to `s'
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
...skipping...
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~

Skybuck@DESKTOP-0T9FP82 MSYS /e/SourceCode/PascalCoinGit/PascalCoin 
(ReCommit)
$

Almost always something... to bad would have loved for this to work.. 
another 11 minutes wasted.

Bye,
  Skybuck.

-- 
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/e917721e-cc9f-40a2-aeb0-f082d92e732an%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

Unfortunately can't get this shit working, tried a whole bunch of things, 
another 30 minutes of my life wasted:

alias pascalcoin='cd e:\SourceCode\PascalCoinGit\PascalCoin"
alias rlog='git --no-pager log --all --graph --decorate --color=always | 
tac | sed -e "s/[\\]/aa/g" -e "s/[/]//g" -e 
"s/aa///g" | less -r +G -X'
alias olog='git --no-pager log --all --graph --decorate --oneline 
--color=always | tac | sed -e "s/[\\]/aa/g" -e "s/[/]//g" 
-e "s/aa///g" | less -r +G -X'


^ last attemptI tried to invert ' and "

sh: alias: --no-pager: not found
sh: alias: log: not found
sh: alias: --all: not found
sh: alias: --graph: not found
sh: alias: --decorate: not found
sed: -e expression #3, char 17: unknown option to `s'
There is no -^J option ("less --help" for help)
There is no no-pager option ("less --help" for help)
sed: -e expression #3, char 17: unknown option to `s'
There is no -^J option ("less --help" for help)
launch: No such file or directory
them: No such file or directory
through: No such file or directory
"winpty" may be a binary file.  See it anyway?
sh: /etc/profile.d/aliases.sh: line 25: syntax error near unexpected token 
`;;'
sh: /etc/profile.d/aliases.sh: line 25: `   ;;'

Skybuck@DESKTOP-0T9FP82 MSYS /usr/bin
$

Bye,
  Skybuck.
On Thursday, December 30, 2021 at 8:38:53 AM UTC+1 skybuck2000 wrote:

> Oops messed up that important alias, remove one line:
>
> was:
> [alias] 
> rlog = !"git --no-pager log --all --graph --decorate --oneline 
> --color=always | tac | sed -e 's/[\\]/aa/g' -e 's/[/]//g' 
> -e 's/aa///g' | less -r +G -X"
>
> should be:
> [alias] 
> rlog = !"git --no-pager log --all --graph --decorate --color=always | tac 
> | sed -e 's/[\\]/aa/g' -e 's/[/]//g' -e 
> 's/aa///g' | less -r +G -X"
>
> Bye,
>   Skybuck.
>
>

-- 
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/0253e969-3992-4d6e-a9e8-34a62b43758an%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

Oops messed up that important alias, remove one line:

was:
[alias] 
rlog = !"git --no-pager log --all --graph --decorate --oneline 
--color=always | tac | sed -e 's/[\\]/aa/g' -e 's/[/]//g' 
-e 's/aa///g' | less -r +G -X"

should be:
[alias] 
rlog = !"git --no-pager log --all --graph --decorate --color=always | tac | 
sed -e 's/[\\]/aa/g' -e 's/[/]//g' -e 
's/aa///g' | less -r +G -X"

Bye,
  Skybuck.

-- 
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/d02b064e-e534-4645-b34d-f8280d784bcan%40googlegroups.com.

[git-users] Re: git log --graph --all makes top line fall of screen.

[skybuck2000]

Reversing the log is a possible solution, it does look a little bit weird, 
commit hashes at the bottom and commit comments at the top per commit, but 
could be interesting:

git --no-pager log --all --graph --decorate --color=always | tac | sed -e 
's/[\]/aa/g' -e 's/[/]/\\/g' -e 's/aa/\//g' | less -r +G -X

for one line version:

git --no-pager log --all --graph --oneline --decorate --color=always | tac 
| sed -e 's/[\]/aa/g' -e 's/[/]/\\/g' -e 's/aa/\//g' | less 
-r +G -X

Found it here:

terminal - How to make git-log scroll up instead of down - Stack Overflow 


I wish I did not have to spent so much time fixing stupid bugs like this :P

Oh yeah and the aliases:

The corresponding git alias is

[alias] 

orlog = !"git --no-pager log --all --graph --decorate --oneline 
--color=always | tac | sed -e 's/[\\]/aa/g' -e 's/[/]//g' 
-e 's/aa///g' | less -r +G -X"
[alias] 
rlog = !"git --no-pager log --all --graph --decorate --oneline 
--color=always | tac | sed -e 's/[\\]/aa/g' -e 's/[/]//g' 
-e 's/aa///g' | less -r +G -X"

orlog for one line and reverse
rlog for reverse

or choose whatever alias you like ! ;)

Bye,
  Skybuck.



-- 
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/17a89fdb-a710-46f5-b321-72ef0c1a8fc0n%40googlegroups.com.

[git-users] Re: git grep --no-index

[Erik Cervin Edin]

  printf 'bar\nboo\nbzz\n' > foo
  git grep --no-index --files-with-matches --all-match -e -bar -e boo -e 
bzz -- foo
  cd ../
  git grep --no-index --files-with-matches --all-match -e -bar -e boo -e 
bzz -- git/foo
  git grep --no-index --files-with-matches --all-match -e -bar -e boo -e 
bzz git

All work for me.
Git 2.25.1
Ubuntu 20.04.3 LTS

On Tuesday, December 28, 2021 at 4:36:30 PM UTC+1 kevi...@gmail.com wrote:

>
> Exit status: 134
> BUG: environment.c:202: git environment hasn't been setup
> Aborted
>
> I can see the code here: 
> https://github.com/git/git/blob/master/environment.c#L203
>

This is a result of calling 
get_git_dir
樂
possibly (?) from 
init_path_spec_item

> $ git grep --all-match --no-index --files-with-matches -e abc -e def 
/path/to/data.txt

Are you using a more complicated pathspec than just /path/to/data.txt?
Are you running inside or outside a git repo?

What's the output when running:
  GIT_TRACE=1 git grep ...
?

 

-- 
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/51d71b8e-27b3-4131-a842-fea715bd7e94n%40googlegroups.com.

[git-users] Re: GIT FUCKING SUCKS, ONE WORKING COPY IS NOT ENOUGH.

[skybuck2000]

NOW YOU UNDERSTAND WHY:

A more advanced git system with working trees per commit.

A more advanced git system with working trees per commit.

Now this is something to my liking.

A git system where each commit and each branch has it's own working tree ?!

A tool which automates this would be great !

It should work as follows:

1. when a new branch is created create work tree for it in a sub folder
2. when a new commit is created or even before it a new folder is created.
3. commits should be split up in a pre-commit and post-commit.

the pre-commit states the programmers intention in the current working tree
the post-commit states the programmers work done.

4. each working tree/folder should automatically version if possible
version 0.01
version 0.02
version 0.03

5. the commit message should be recorded in the folder name above
version 0.01 post-commit message
version 0.02 post-commit message
version 0.03 pre-commit message

version 0.01-branch-feature-a
version 0.01-branch-feature-b

I know this system has limitations but it would integrate really well with 
my existing application development experience...

and it has then the best of both worlds.

Fast application development.
Redundancy
Build anything at any time
Run anything at any time.
Access to anything.
Can very quickly look back at older versions.
+
Git co-operation / team development.
Git distribution stuff
Git integrity checking maybe.

Git should and will evolve into something like this.

Better versioning information, more stability, more backwards 
compatibility, not one code for all, code for all times.

Let me know if such a system already exists.

Yes it may  not be suited for linux big 2 gigabyte kernel development, 
because of copies in working trees, but we are not all developing big 
kernels.

Bye,
  Skybuck.


-- 
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/5b89440a-e47e-43b2-9c7d-3182e9f16544n%40googlegroups.com.

[git-users] Re: GIT FUCKING SUCKS, ONE WORKING COPY IS NOT ENOUGH.

[skybuck2000]

SOME IDIOT ON THE INTERNET MENTIONED TO USE WORKTREE COMMAND I BET THAT 
OVERWRITES THE DEFAULT AND FUCKS UP PEOPLE REPOSITORY, PRETTY FUCKING 
STUPID...

BUT IT DOES APPEAR GIT HAS SUPPORT FOR MULTIPLE WORKING TREES:

Git - git-worktree Documentation (git-scm.com) 


FINALLY.

NAME

git-worktree - Manage multiple working trees
SYNOPSIS
git worktree add [-f] [--detach] [--checkout] [--lock [--reason ]] 
[-b ]  [] git worktree list [--porcelain] git 
worktree lock [--reason ]  git worktree move  
 git worktree prune [-n] [-v] [--expire ] git worktree 
remove [-f]  git worktree repair […​] git worktree unlock 

DESCRIPTION

Manage multiple working trees attached to the same repository.

A git repository can support multiple working trees, allowing you to check 
out more than one branch at a time. With git worktree add a new working 
tree is associated with the repository. This new working tree is called a 
"linked working tree" as opposed to the "main working tree" prepared by 
git-init[1]  or git-clone[1] 
. A repository has one main working 
tree (if it’s not a bare repository) and zero or more linked working trees. 
When you are done with a linked working tree, remove it with git worktree 
remove.

In its simplest form, git worktree add  automatically creates a new 
branch whose name is the final component of , which is convenient if 
you plan to work on a new topic. For instance, git worktree add 
../hotfix creates new branch hotfix and checks it out at path ../hotfix. To 
instead work on an existing branch in a new working tree, use git worktree 
add  . On the other hand, if you just plan to make some 
experimental changes or do testing without disturbing existing development, 
it is often convenient to create a throwaway working tree not associated 
with any branch. For instance, git worktree add -d  creates a new 
working tree with a detached HEAD at the same commit as the current branch.

If a working tree is deleted without using git worktree remove, then its 
associated administrative files, which reside in the repository (see 
"DETAILS" below), will eventually be removed automatically 
(see gc.worktreePruneExpire in git-config[1] 
), or you can run git worktree 
prune in the main or any linked working tree to clean up any stale 
administrative files.

If a linked working tree is stored on a portable device or network share 
which is not always mounted, you can prevent its administrative files from 
being pruned by issuing the git worktree lock command, optionally 
specifying --reason to explain why the working tree is locked.
COMMANDS
add
 
 []

Create  and checkout  into it. The new working directory 
is linked to the current repository, sharing everything except working 
directory specific files such as HEAD, index, etc. As a 
convenience,  may be a bare "-", which is synonymous with @{-1}.

If  is a branch name (call it ) and is not found, and 
neither -b nor -B nor --detach are used, but there does exist a tracking 
branch in exactly one remote (call it ) with a matching name, treat 
as equivalent to:
$ git worktree add --track -b   /

If the branch exists in multiple remotes and one of them is named by 
the checkout.defaultRemote configuration variable, we’ll use that one for 
the purposes of disambiguation, even if the  isn’t unique across 
all remotes. Set it to e.g. checkout.defaultRemote=origin to always 
checkout remote branches from there if  is ambiguous but exists on 
the origin remote. See also checkout.defaultRemote in git-config[1] 
.

If  is omitted and neither -b nor -B nor --detach used, then, 
as a convenience, the new working tree is associated with a branch (call 
it ) named after $(basename ). If  doesn’t exist, a 
new branch based on HEAD is automatically created as if -b  was 
given. If  does exist, it will be checked out in the new working 
tree, if it’s not checked out anywhere else, otherwise the command will 
refuse to create the working tree (unless --force is used).

list

List details of each working tree. The main working tree is listed first, 
followed by each of the linked working trees. The output details include 
whether the working tree is bare, the revision currently checked out, the 
branch currently checked out (or "detached HEAD" if none), "locked" if the 
worktree is locked, "prunable" if the worktree can be pruned 
by prune command.

lock

If a working tree is on a portable device or 

[git-users] Re: GIT FUCKING SUCKS, ONE WORKING COPY IS NOT ENOUGH.

[skybuck2000]

ANOTHER NICE EXAMPLE WHY GIT SUCKS.

IT'S NOW COPIEING THE ENTIRE HISTORY.

NOOO MOTHERFUCKERS

I JUST NEED ONE FUCKING VERSION FUCKING IDIOTS LOL.

BYE,
  SKYBUCK.

-- 
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/c3f51839-a549-48e0-8ca6-84aacab2b7dan%40googlegroups.com.

[git-users] Re: GIT FUCKING SUCKS, ONE WORKING COPY IS NOT ENOUGH.

[skybuck2000]

MIGHT AS WELL COPY THE ENTIRE REPO... IDIOTS ON THE INTERNET TELLING PEOPLE 
TO USE GIT CLONE FOR THAT HAHAHAH STUPID.


DO YOU SEE NOW WHY COPY & PASTE IS SUPERIOR.

I BET YOU DONT EVEN HAVE A COMMAND FOR IT IN GIT

GIT COPY
GIT PASTE

FUCK YOU

BYE,
  SKYBUCK.

-- 
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/2190b8b3-702e-423c-a85e-64d6ab9f539en%40googlegroups.com.

[git-users] Re: GIT FUCKING SUCKS, ONE WORKING COPY IS NOT ENOUGH.

[skybuck2000]

ANOTHER REASON WHY GIT CLONE SUCKS IS IT IMPLIES A SERVER/GITHUB SOMEWHERE

FUCK THAT.

I SHOULD BE ABLE TO WORK LOCAL ONLY.

HOW THE FUCK I CLONE A GIT REPOSITORY

FROM LOCAL TO LOCAL

NEED MORE COMMANDS HAHAHAHAHAHAH

BYE,
  SKYBUCK.

-- 
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/d6b35813-f310-445c-982b-d57b310d3553n%40googlegroups.com.

[git-users] Re: GIT FUCKING SUCKS, ONE WORKING COPY IS NOT ENOUGH.

[skybuck2000]

LISTEN UP YOU MOTHERFUCKERS

I JUST CREATED THIS FOLDER ON MY WINDOWS:

PascalCoinGit(For Copy Operations)

NOW BECAUSE LINUX/SH/BASH SUCKS SO MUCH I HAVE TO TYPE THIS COMPLETELY IN 
GIT BASH AND SHIT.

WORK ON TAB FEATURE SO IT IS AUTO-COMPLETED

OR UPGRADE/UPDATE GIT TO HAVE MULTIPLE WORKING TREES/FOLDERS

SOME LIKE:

WORKTREE1: Skybuck@DESKTOP-0T9FP82 MSYS 
/e/SourceCode/PascalCoinGit/PascalCoin (PascalCoinReducedAndSecured)
WORKTREE2: Skybuck@DESKTOP-0T9FP82 MSYS /e/SourceCode/PascalCoinGit(For 
Copy Operations)/PascalCoin (PascalCoinReducedAndSecured)
$

ALSO WHY THE FUCK YOU CALL IT TREE AND NOT FOLDER LIKE NORMAL PEOPLE LOL 
HAHAHA BUT OK.

TREE ACTUALLY MEANS A WHOLE BUNCH OF BRANCHES AND SHIT...

FOLDER ONLY SHOWS THE CURRENT ONE... NOT THE SUBFOLDERS DUH...

WORKTREE IS TOO ABSTRACT.


NOW I SHOULD BE ABLE TO SWITCH BETWEEN WORK TREES EASILY OR SOMETHING

GIT SWITCH TREE WORKTREE1
DO SOMETHING
GIT SWITCH TREE WORKTREE2
DO SOMETHING

BUT THE POINT IS... I MUST SEE BOTH WORKTREES 

WHY ?!

BECAUSE I DONT USE BEYOND COMPARE YET OR ANY OTHER ADVANCED EDITING TOOL.

A SIMPLE EDITOR SHOULD BE JUST FINE FOR SOURCE CODE AND SIMPLE OPERATIONS 
IN CASE COMPLEX EDITORS CRASH.

OKIDOKIE ?!

BYE,
  SKYBUCK.



-- 
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/b0f30a25-dcfd-4297-8e19-291030054603n%40googlegroups.com.

[git-users] Re: Git branches vs Mercurial branches

[Mikko Rantalainen]

Was: [Mystery solved, I owe you an apology] (was: [git-users] how to
remove two commits from a remote server)

On Wed, Dec 1, 2021 at 12:18 PM Uwe Brauer  wrote:
> As I said I am one of the maintainer of
> matlab-mode(emacs), a git repository in sourceforge. Since I know
> mercurial relatively well but don't really understand git (to put it
> [...]
> It never occurred to me, that there would be two
> type of branches (in mercurial there is only one type of branch, it
> commits can be on remote or on local or on both but there is no need to
> distinguish both).
> Yes I know git branch -a shows branches, I never really understand them
> all.

I think this point deserves a bit further discussion.

As I wrote at https://stackoverflow.com/a/11223644/334451 it's
actually the other way around. Mercurial has multiple things that are
logically branches: unnamed branches, named branches and bookmarks.
Git only has branches but it uses namespaces for branch names
(basically path for a branch + the name). Git users often speak about
"master" branch (or "main" nowadays) and you have to decipher from the
context if they actually mean refs/heads/master or
refs/remotes/origin/master or something else. Git is also smart enough
to guess the correct path if you use just the last part of the full
name and in some context the interpretation of short names is
explicitly defined. For example, when you say

git push origin foo:bar

it will actually execute (assuming foo is local branch and not a tag)

git push origin refs/heads/foo:refs/heads/bar

which means 'take the local "refs/heads/foo" and push it to remote
server "origin" using name "refs/heads/bar" on the remote server'. You
can use commit SHA-1 for the source as long as the target is a branch
that already exists (otherwise git cannot know if you want to create a
new tag or branch). I prefer to use this syntax if I ever need to
force (overwrite) things on the remote server so that I can accurately
specify the new state of the target branch.

As everything actually has full namespaced name ("refname"), you can
also do stuff like having branch master (actually refs/heads/master)
and tag master (actually refs/tags/master) but that's just asking for
trouble. Git always uses the full refnames under the hood but allows
using shorter names in the user interface.

By default, when you run "git branch" it lists only refs/heads/*
without the full "refname". For full branch names you have to run
something like

git branch --format="%(refname)"

or for all branches, local or remote no matter how many remote servers
you've configured

git branch -a --format="%(refname)"

which will list full names of all the known branches. All those names
are actually file paths under the directory .git/refs/ in your working
directory so the whole system is actually really simple (the file at
the end of that path contains just the SHA-1 of the commit that's the
tip of that branch). When you "create a new branch" in Git, you
literally create one new file with 41 bytes containing the currently
checked out commit SHA-1 (output of "git rev-parse HEAD") with
trailing linefeed and the name of the file is the name of the branch
you created. The file .git/HEAD contains textual reference to
currently checked out commit or head or tag in your working directory.

Git tags are implemented similarly but those are stored in
.git/refs/tags/ and will not be automatically modified when you create
new commits. Note that tags are not kept in separate namespaces but
when you fetch changes, you automatically get all the tags, too, and
those are always in the prefix refs/tags/.

You can list all known tags with full refnames using command

git tag --format='%(refname)'

Note that "git tag -a" does exist but it doesn't mean "list all" but
"create annotated tag" (a tag that has more info attached to it
instead of just the name) because tags do not have namespaces, so
there's no need for "list all tags".

The branches starting with refs/remote/ will be updated automatically
when you run "git fetch" (or do "git pull" which will run "git fetch"
behind your back).

Git will be much easier to understand if you never ever use "git pull"
for anything.  Always run "git fetch" (or "git fetch --all" if you
have multiple remote servers) instead and it will only update the
refs/remote/ hierarchy only and download the required pack/object
files to actually know what all those SHA-1's mean. After you have
executed "git fetch" you can use "gitk --all", "gitg" or some other
repository viewer that can show both local and remote branches. If you
don't have any GUI tools, you can run something like

git log --oneline --decorate --graph --all

or (everything on one line)

git log --graph --all --pretty=format:"%C(auto)%h%d%Creset %s
%Cgreen(%cr)%Creset"

Then you can sanely decide if you want to merge, rebase or do something else.


As a party trick, you can also do stuff like

git push . HEAD:foo

which means 

Re: [git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[Konstantin Khomoutov]

On Wed, Dec 01, 2021 at 09:32:56PM -0800, skybuck2000 wrote:

>  It would be nice if GIT would respect the following limits:
> 
> new@new-PC MINGW64 /
> $ ulimit -a
> core file size  (blocks, -c) unlimited
> data seg size   (kbytes, -d) unlimited
> file size   (blocks, -f) unlimited
> open files  (-n) 256
> pipe size(512 bytes, -p) 8
> stack size  (kbytes, -s) 2036
> cpu time   (seconds, -t) unlimited
> max user processes  (-u) 256
> virtual memory  (kbytes, -v) unlimited

I doubt it could: what you see is Git Bash - being a port of Bash to Windows -
is implementing the shell built-in command `ulimit`. This shell builtin only
has sense on Unix-like systems because there it interacts with the POSIX
syscalls getrlimit/setrlimit which do not exist on Windows, where Git Bash
works. (And even there on POSIX-like systems, not all features exposed by
`ulimit` are actually enforced; for instance, on Linux, you can tweak the
"maximum RSS" limit but it is ignored; other systems have their own quirks).

> Then I could try and set these limits, however I fear if I set them now it 
> will limit GIT even more and it will lead to even sooner crashes... though 
> it's worth a try to see what happens.

I would guess tweaking them would not affect anything.

[...]

-- 
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/20211202101456.aznmgbjir773ldma%40carbon.

[git-users] Re: GIT failed to checkout the linux kernel on a 6 GB system

[skybuck2000]

 It would be nice if GIT would respect the following limits:

new@new-PC MINGW64 /
$ ulimit -a
core file size  (blocks, -c) unlimited
data seg size   (kbytes, -d) unlimited
file size   (blocks, -f) unlimited
open files  (-n) 256
pipe size(512 bytes, -p) 8
stack size  (kbytes, -s) 2036
cpu time   (seconds, -t) unlimited
max user processes  (-u) 256
virtual memory  (kbytes, -v) unlimited

new@new-PC MINGW64 /
$

Then I could try and set these limits, however I fear if I set them now it 
will limit GIT even more and it will lead to even sooner crashes... though 
it's worth a try to see what happens.

Right now I have no time to experiment with this, but could be an idea for 
the future.

Setting limitations for GIT itself does not seem to be well documented or 
at least google don't take me there, I found this via google:

Not sure if this will help or what it does exactly:

git config --global pack.windowMemory "100m" 
git config --global pack.packSizeLimit "100m" 
git config --global pack.threads "1"

How this is related to checkout I don't know, could try it out, but kinda 
hate to try things out and waste my time if it doesn't work. Things like 
this should be tested by git developers.

Here is official documentation, many commands and settings to go through, 
low on time right now:

https://git-scm.com/docs/git-config

Searching for limit gives:

core.packedGitLimit 

Maximum number of bytes to map simultaneously into memory from pack files. 
If Git needs to access more than this many bytes at once to complete an 
operation it will unmap existing regions to reclaim virtual address space 
within the process.

Default is 256 MiB on 32 bit platforms and 32 TiB (effectively unlimited) 
on 64 bit platforms. This should be reasonable for all users/operating 
systems, except on the largest projects. You probably do not need to adjust 
this value.

Common unit suffixes of *k*, *m*, or *g* are supported.

core.deltaBaseCacheLimit 

Maximum number of bytes per thread to reserve for caching base objects that 
may be referenced by multiple deltified objects. By storing the entire 
decompressed base objects in a cache Git is able to avoid unpacking and 
decompressing frequently used base objects multiple times.

Default is 96 MiB on all platforms. This should be reasonable for all 
users/operating systems, except on the largest projects. You probably do 
not need to adjust this value.

Common unit suffixes of *k*, *m*, or *g* are supported.


core.bigFileThreshold 

Files larger than this size are stored deflated, without attempting delta 
compression. Storing large files without delta compression avoids excessive 
memory usage, at the slight expense of increased disk usage. Additionally 
files larger than this size are always treated as binary.

Default is 512 MiB on all platforms. This should be reasonable for most 
projects as source code and other text files can still be delta compressed, 
but larger binary media files won’t be.

Common unit suffixes of *k*, *m*, or *g* are supported.

THIS COULD BE INTERESTING:

core.sparseCheckout 

Enable "sparse checkout" feature. See git-sparse-checkout[1] 
 for more information.
core.sparseCheckoutCone 

Enables the "cone mode" of the sparse checkout feature. When the 
sparse-checkout file contains a limited set of patterns, then this mode 
provides significant performance advantages. See git-sparse-checkout[1] 
 for more information.


iff.statGraphWidth 

Limit the width of the graph part in --stat output. If set, applies to all 
commands generating --stat output except format-patch.


diff.renameLimit 

The number of files to consider in the exhaustive portion of copy/rename 
detection; equivalent to the *git diff* option -l. If not set, the default 
value is currently 1000. This setting has no effect if rename detection is 
turned off.


fastimport.unpackLimit 

If the number of objects imported by git-fast-import[1] 
 is below this limit, then the 
objects will be unpacked into loose object files. However if the number of 
imported objects equals or exceeds this limit then the pack will be stored 
as a pack. Storing the pack from a fast-import can make the import 
operation complete faster, especially on slow filesystems. If not set, the 
value of transfer.unpackLimit is used instead.


gc.auto 

When there are approximately more than this many loose objects in the 
repository, git gc --auto will pack them. Some Porcelain commands use this 
command to perform a light-weight garbage collection from time to time. The 
default value is 6700.

Setting this to 0 disables not only automatic packing based on the number 
of loose objects, but any other heuristic git gc --auto will otherwise use 
to determine if there’s work to do, such as 

[git-users] Re: GIT: Split file into multiple files, then detect changes in updated original file and apply to multiple files.

[skybuck2000]

Split all at once so far not succeeded, individual branches offer some 
help, by allowing git -mv to indicate to git that a big file was 
renamed/reduced to a small file.

Then later all individual branches can be merged to produce a build.

The problem with this is if changed are done to  the new build, and later 
to old build, changes from new build get lost or have to be re-applied to 
individual branches again.

What I would need here is a way to tell git that a big file should be 
copied/applied multiple times to individual parts/files ?

So for example:

Apply BigFile to LittleFile1 LittleFile2 LittleFile3

There seem to be some git plumbing commands.

Maybe there is some plumbing command that can help with this.

Bye for now,
  Skybuck.

On Tuesday, November 23, 2021 at 1:30:48 AM UTC+1 skybuck2000 wrote:

> GIT: Split file into multiple files, then detect changes in updated 
> original file and apply to multiple files.
>
> File Original contains:
>
> ObjectA
>
> Some funtions for Object A
>
> some more functions for Object A
>
> ObjectB
>
> Some functions for Object B
>
> some more functions for Object B
>
> ObjectC
>
> Some functions for Object C
>
> some more functions for Object C
>
>
> This should be split up into three files:
>
> ObjectA
>
> ObjectB
>
> ObjectC
>
>
> Such that File ObjectA contains:
>
> ObjectA
>
> Some funtions for Object A
>
> some more functions for Object A
>
>
> Such that File ObjectB contains:
>
> ObjectB
>
> Some funtions for Object B
>
> some more functions for Object B
>
>
> Such that File ObjectC contains:
>
> ObjectC
>
> Some funtions for Object C
>
> some more functions for Object C
>
>
> Later file Original is updated:
>
> ObjectA
>
> Some funtions for Object A
>
> some more functions for Object A
>
> even more functions for Object A
>
> ObjectB
>
> Some functions for Object B
>
> some more functions for Object B
>
> even more functions for Object B
>
> ObjectC
>
> Some functions for Object C
>
> some more functions for Object C
>
> even more functions for Object C
>
>
> Is it somehow possible to use git to automate the updating of File 
> ObjectA, File ObjectB File ObjectC so that all three files contain the new 
> line such that:
>
>
> Such that File ObjectA contains:
>
> ObjectA
>
> Some funtions for Object A
>
> some more functions for Object A
>
> even more functions for Object A
>
>
> Such that File ObjectB contains:
>
> ObjectB
>
> Some funtions for Object B
>
> some more functions for Object B
>
> even more functions for Object B
>
>
> Such that File ObjectC contains:
>
> ObjectC
>
> Some funtions for Object C
>
> some more functions for Object C
>
> even more functions for Object C
>
>
> This is a scenerio where the original file is updated by a different user.
>
> It would be very nice if a feature git had this detection capability for 
> two reasons:
>
>1. 
>
>Big teams/projects that might not want to freeze such a big fle.
>2. 
>
>No-cooperating teams/repository that don't want to split the file.
>
>
> Now that I understand git a little bit better, very maybe this will work:
>
> What could be tried for the split dilemma, is the following idea:
>
>
> 1. The original document.txt is splitted in a "split commit" such that 
> objecta.txt objectb.txt and objectc.txt exist.
>
> 2. This "split commit" can be isolated on top of original document.txt or 
> anywhere basically.
>
> 3. Then when original document.txt is updated, try and reapply the "split 
> commit", by basically re-basing it on top of the updated document.txt
>
> So in git terms the idea is as follows:
>
> BranchOriginalDocument   commit 1
> document.txt
> BranchSplittedDocument commit 2
> objecta.txt
> objectb.txt
> objectc.txt
> (could even be placed on their own sub branch if necessary because one 
> branch might not be enough)
> BranchUpdatedDocumentcommit 3
> document.txt
> 
> now after after commit 3 is done, commit 2 could be rebased onto commit 3 
> in the hopes that git will recgonize the split operation and maybe
> repeat it on top of document.txt with updated contents.
>
> the git command for this would like something like:
>
> git rebase --onto BranchUpdatedDocument BranchOriginalDocument 
> BranchSplittedDocument
>
> tomorrow I will give this a try to see how far I get with this.
>
> If it fails one more try would be to create additional branches or so, I 
> saw somebody mention in the past that that might work.
> not sure if they should be based on each other, but maybe... or seperate 
> branches could be tried as well, all based on branch splitted document.
>
> BranchSplittedDocument
> BranchA
> BranchB
> BranchC  
> BranchUpdatedDocument
>
> (I am not sure if I have tried this before, maybe, but I understand git 
> rebase a little bit better now, and git in general ! ;))
>
> Any suggestions are welcome !
>
> Bye,
>   Skybuck.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for 

[git-users] Re: git --amend doesn't seem to work as I anticipated

[SJW]

I amended the commit and then re-merged and the amended commit did not merge

On Thursday, 2 September 2021 at 19:02:01 UTC+10 philip...@iee.email wrote:

> > Do amends not merge? 
>
> In general, don't try to `--amend` a merge. It would produce an evil merge 
> (i.e. something in a notionally clean merge that wasn't actually present in 
> either branch). As best I remember, if you try to amend a merge you only 
> get an updated single parent commit, rather than a merge. (try a bit of 
> experimentation to check)
>
> If the merge was clean (make this easier), it's better to rewind/rollback 
> to just before the 'merge', apply the --amend to the branch, and then 
> remerge. (--amend is a squash for a single commit rebase ;-)
>
> The 'rerere' database (if enabled) can help with tricky merges (it 
> remembers the previous conflict resolutions!), but it's documentation is 
> horrendous/next to useless, despite it being real magic [sufficiently 
> advanced technology]
> On Thursday, September 2, 2021 at 12:21:06 AM UTC+1 SJW wrote:
>
>> I have been working on a feature-branch - made a few commits and ready 
>> for testing.
>>
>> I `git checkout staging` branch, merge in feature-branch and then push it 
>> to the staging server.
>>
>> While testing in staging I realise I have left some logging on or 
>> something else minor.
>>
>> I checkout feature-branch again and remove the logging BUT this time when 
>> committing, instead of a brand new commit, I use `git commit --amend`
>>
>> I `git checkout staging` branch again, merge in feature-branch again and 
>> then push it to the staging server. BUT ... the last changes committed via 
>> `--amend` are not present.  This isn't the first time this has happened so 
>> I am guessing it's not something I have done, it's actually a "feature" of 
>> git. Is this correct? 
>>
>> Do amends not merge?
>>
>

-- 
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/b4a20183-c010-44b8-bd08-451edb988d89n%40googlegroups.com.

[git-users] Re: git --amend doesn't seem to work as I anticipated

[Philip Oakley]

> Do amends not merge? 

In general, don't try to `--amend` a merge. It would produce an evil merge 
(i.e. something in a notionally clean merge that wasn't actually present in 
either branch). As best I remember, if you try to amend a merge you only 
get an updated single parent commit, rather than a merge. (try a bit of 
experimentation to check)

If the merge was clean (make this easier), it's better to rewind/rollback 
to just before the 'merge', apply the --amend to the branch, and then 
remerge. (--amend is a squash for a single commit rebase ;-)

The 'rerere' database (if enabled) can help with tricky merges (it 
remembers the previous conflict resolutions!), but it's documentation is 
horrendous/next to useless, despite it being real magic [sufficiently 
advanced technology]
On Thursday, September 2, 2021 at 12:21:06 AM UTC+1 SJW wrote:

> I have been working on a feature-branch - made a few commits and ready for 
> testing.
>
> I `git checkout staging` branch, merge in feature-branch and then push it 
> to the staging server.
>
> While testing in staging I realise I have left some logging on or 
> something else minor.
>
> I checkout feature-branch again and remove the logging BUT this time when 
> committing, instead of a brand new commit, I use `git commit --amend`
>
> I `git checkout staging` branch again, merge in feature-branch again and 
> then push it to the staging server. BUT ... the last changes committed via 
> `--amend` are not present.  This isn't the first time this has happened so 
> I am guessing it's not something I have done, it's actually a "feature" of 
> git. Is this correct? 
>
> Do amends not merge?
>

-- 
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/f7f2ea54-3433-42fa-a05c-f560efae0f53n%40googlegroups.com.

[git-users] Re: Git locking directories (not closing handles)

[Konstantin Khomoutov]

On Tuesday, July 6, 2021 at 12:15:16 AM UTC+3 vind...@gmail.com wrote:
Git prevents me from modifying the repository folder unless I reboot the 
PC. It started happening to me after fresh-installing Windows 10 
today. During the setup, I enabled some experimental feature called "file 
watcher". Is it related to the issue? How do I fix this?
 
Looks like it's a new feature of GfW 2.31.
It appeas that Git automatically spawns a monitor process which opens the 
directory
with the repository to ask the OS kernel to get notified about specific 
changes
made to the files in that directory.
Due to how Windows handles opened files and directories (which is an MS-DOS 
legacy,
actually), if a process has a file or a directory open, another process 
cannot move or
delete it, and that's what you're observing.

Hence basically I think it's a "take it or leave it" feature: if you want 
to enjoy fast
`git stat` operations, you have to trade the inability to move Git 
repositories which are
in active use arount on a filesystem.

Looks like to disable the feature, one needs to do

  git config --global --add core.useBuiltinFSMonitor false

and reboot (or kill the running watcher processes).



On Thursday, July 8, 2021 at 1:22:32 PM UTC+3 philip...@iee.email wrote:

> what sort of " modifying the repository folder " were you attempting to do?
>
> Also which version are you running? There has been an update in the last 
> few days which included changes to the file watcher (fsmonitor).
>
> If the update solves you problem, simply report that. If not, add a few 
> more details.
>
> thank you in advance...
>
> On Monday, July 5, 2021 at 10:15:16 PM UTC+1 vind...@gmail.com wrote:
>
>> Git prevents me from modifying the repository folder unless I reboot the 
>> PC. It started happening to me after fresh-installing Windows 10 
>> today. During the setup, I enabled some experimental feature called "file 
>> watcher". Is it related to the issue? How do I fix this?
>> [image: Screenshot 2021-07-05 230917.png]
>
>

-- 
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/9410890f-9ca9-4255-82c2-bd989fb3bbfdn%40googlegroups.com.

[git-users] Re: Git locking directories (not closing handles)

[Philip Oakley]

what sort of " modifying the repository folder " were you attempting to do?

Also which version are you running? There has been an update in the last 
few days which included changes to the file watcher (fsmonitor).

If the update solves you problem, simply report that. If not, add a few 
more details.

thank you in advance...

On Monday, July 5, 2021 at 10:15:16 PM UTC+1 vind...@gmail.com wrote:

> Git prevents me from modifying the repository folder unless I reboot the 
> PC. It started happening to me after fresh-installing Windows 10 
> today. During the setup, I enabled some experimental feature called "file 
> watcher". Is it related to the issue? How do I fix this?
> [image: Screenshot 2021-07-05 230917.png]

-- 
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/49a7e7a9-cf2b-411f-8690-5b601ec6839cn%40googlegroups.com.

[git-users] Re: Git signs with gpg-key whose email matching author email instead of gpg-key that matches user.signingkey?

[x10an14]

Example of bug:

```
[2021-06-28 11:45:09] 0 x10an14@x10-laptop:~/.password-store
-> $ gpg -k 40342E76F04C8890B58CB9FA321FC44B567B28FA
pub   ed25519 2021-06-22 [C]
  40342E76F04C8890B58CB9FA321FC44B567B28FA
uid   [ultimate] x10an14 
sub   ed25519 2021-06-22 [S] [expires: 2023-01-01]
sub   cv25519 2021-06-22 [E] [expires: 2023-01-01]
sub   ed25519 2021-06-22 [A] [expires: 2023-01-01]
[2021-06-28 11:45:18] 0 x10an14@x10-laptop:~/.password-store
-> $ bat ~/.config/git/config
   1   [user]
   2   signinkey = 40342E76F04C8890B58CB9FA321FC44B567B28FA
   3   email = x10a...@users.noreply.github.com
   4   name = x10an14
   5   [gpg]
   6   program = gpg
   7   [commit]
   8   gpgsign = true
   9   [tag]
  10   gpgsign = true
[2021-06-28 11:46:30] 0 x10an14@x10-laptop:~/.password-store
-> $ git config --list | grep user
user.signinkey=40342E76F04C8890B58CB9FA321FC44B567B28FA
user.email=x10a...@users.noreply.github.com
user.name=x10an14
[2021-06-28 11:46:45] 0 x10an14@x10-laptop:~/.password-store
-> $ git config --list | grep gpg
gpg.program=gpg
commit.gpgsign=true
tag.gpgsign=true
[2021-06-28 11:46:50] 0 x10an14@x10-laptop:~/.password-store
-> $ pwd
/home/x10an14/.password-store
[2021-06-28 11:46:58] 0 x10an14@x10-laptop:~/.password-store
-> $ GIT_TRACE=1 git commit -S -m "Add given password for 
x10an14@email1.example/password to store." --amend
11:47:04.657284 git.c:442   trace: built-in: git commit -S -m 
'Add given password for x10an14@email1.example/password to store.' --amend
11:47:04.658591 run-command.c:663   trace: run_command: gpg 
--status-fd=2 -bsau 'x10an14 '
error: gpg failed to sign the data
fatal: failed to write commit object
[2021-06-28 11:47:04] 128 x10an14@x10-laptop:~/.password-store
-> $
```

On Sunday, June 27, 2021 at 12:18:38 AM UTC+2 x10an14 wrote:

> As the subject describes, yesterday I experienced my git client attempting 
> to sign my commits with gpg-key X, when I had specified gpg-key Z as such;
> `git config user.signinkey `
>
> I am using the email associated with gpg-key X as my `git config 
> user.email`, and not the email that my gpg-client has associated with 
> gpg-key Z.
>
> Using `GIT_TRACE=1`, I get output like this;
> ` trace: run_command: gpg --status-fd=2 -bsau  with gpg-key X>`
>
> Does git ignore `git config user.signingkey` when it finds a gpg-key in 
> the local gpg-agent whose email matches `git config author.email`?
>
> I'd be grateful for any experience or pointers here. I was really hoping 
> the `GPG_TRACE=1` output show the `gpg --status-fd=2` command to reference 
> the key-id, not the email.
>

-- 
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/5f49a4c4-ecd4-46bf-9713-641162ce2eb6n%40googlegroups.com.

[git-users] Re: git merge problems

[mss...@gmail.com]

Hi Thomas,

I have had similar problems with some public repositories and in each case, 
it has been due to the repository owner abandoning/discontinuing the 
"master" branch and using  "main" instead.  I too have been forced to 
reclone and, after doing so, have seen "main" as the default branch. 

I sometimes have a local branch with personal customizations that I don't 
want to lose  so if anyone knows another approach, I, and I'm sure there 
are/will be others, would be interested as well.  

-mike

On Friday, February 12, 2021 at 8:46:23 PM UTC-5 tschw...@gmail.com wrote:

> Hi!
>
> I am more or less downloading sources within an automated process:
>
> cd /pathtosoures
> git reset --hard
> git clean -ffdx
> git pull
>
> now git pull has problems merging what it found. At the moment I am 
> resolving these merge errors with
>
> rm -rf /pathtosources
> git clone https://pathtoremote
>
> any other, better , way to get what I want: an exact copy of the 
> repository found at https://pathtoremote?
>
> -- 
> Thomas
>

-- 
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/dc9ce832-920e-4a8c-80ec-321f06112431n%40googlegroups.com.

[git-users] Re: git amend wont merge

[Philip Oakley]

Roughly speaking, this is a "feature". 

Could you do a diagram of the merge - amend - merge process. Its not 
obvious which parts merged which at the second pass.

In the first merge you had the code growing so it accepted the left over 
code as part of the mainline. 
Then when you tried the second time (IIUC) the new merge looked back to the 
old bases and decided that it should stick with what it had (reverting a 
fix). The problem is asked fairly often (couple times a year?) on the main 
list and depends on the careful sequencing of the fix reversion, and which 
line of code gets priority.

On Wednesday, December 2, 2020 at 3:38:35 AM UTC SJW wrote:

> I had a bug in my code so I branched master to `bugfix-333` and I added a 
> `var_dump();` in the code to debug.
> I then found the problem, fixed it, committed and merged `bugfix-333` into 
> `staging` branch.
> I then realised that I'd left the `var_dump();` in the code so i checked 
> out the `bugfix-333` again and deleted the `var_dump()`
> I again committed the code this time using `git commit --amend`
> Then I checked out `staging` and merged `bugfix-333` again
>
> BUT ... the var_dump() is still there in staging?  I checked out 
> `bugfix-333` and the code is gone. I tried again, checked out `staging` and 
> ran `git merge bugfix-333` but now I get:
>
> Already up to date.
>
> But it's not??? Is this a bug or a "feature"?
>

-- 
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/78093a75-5677-4ef6-b4bc-d308891ca092n%40googlegroups.com.

[git-users] Re: git config autocrlf true

[Philip Oakley]

When working in a multi-OS team, there needs to be a common standard for 
the text file line endings. 

Given that Git was designed as the version control system for Linux, the 
Unix LF line ending was chosen as the default setting for storage _within_ 
the repository.

This means that users on Windows should (it's a choice;-) get Git to 
convert any CRLF line endings in text files to the standard LF ending when 
stored into the repository, and convert them back to CRLF when extracting 
from the respository for local use.

There are some more discussions in the git attributes and config man pages 
regarding how text files and binary files are determined for the end of 
lince conversion.

Philip

On Saturday, October 10, 2020 at 1:43:20 PM UTC+1 tusharr...@gmail.com 
wrote:

> Why we need to setup the 
> git config --global autocrlf true 
> in windows and 
> git config --global autocrlf input
> in macOS/linux.
>
> What's the significance of these two different commands ? and Why are they 
> important

-- 
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/d1f72932-bb25-4c2e-836b-41b2e61d88can%40googlegroups.com.

Re: [git-users] Re: Git - how to determine what files changes

[Philip Oakley]

Do check the history simplification which may means some things you may
expect are not actually treated that way.

Do you have the actual commands & results (copy & paste, with redactions
marked)

What specific software (both Git & Operating system) versions are you
using in the cases. You say it works on Win10. Is that WSl & (linux)
Git; or Git for Windows (again which version)?

Are any of the repositories on server or network drives (i.e what is the
network connectivity - some network software does not always pass the
correct status bits, and some Git versions have interesting ideas about
handling mode bits for compatibility).

What is the actual "invalid" result for the full diff of the
--name-stat'ed file(s) (is it mode bits, or file content difference!)

Can you create a simplified reproducible version (maybe even the
fast-export --anonymize)

finally, not knowing Rocket Port, could this
https://forum.rocketsoftware.com/t/important-notice-for-users-of-the-rocket-port-of-git-for-z-os/1102
be part of the issue?

Philip

On 22/06/2020 17:53, lbd...@gmail.com wrote:
>
> The scenario is this:
> Create a master branch - make updates - add/commit
> New branch to branchB - make changes/updates - add/commit
> New branch to branch C (from branchB) - make changes/updates - add/commit
>
> issue git diff --name-status master branchB and all is good
> issue git diff --name-status branchB branchC and all is good
> issue git diff --name-status master branchC and get invalid results (
>
> When I do this on my windows 10 pc everything works and no invalid
> results.
>
> Using Rocket Port of git at git version 2.14.4_zos_b09
> and Windows version at git version 2.17.1
>
> Is this a known issue?
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is
> what you are, reputation merely what others think you are." - John Wooden
>
>  
>
> From: git-users@googlegroups.com  On
> Behalf Of Philip Oakley
> Sent: Saturday, June 20, 2020 5:01 PM
> To: Git for human beings 
> Subject: [git-users] Re: Git - how to determine what files changes
>
>  
>
> Do you mean that you simply need to get the direct difference between
> A and B.
>
>  
>
> Or do you mean you want to see hwat changed in A since B was forked,
> and like wise what changed in B since that same fork point?
>
>  
>
> Have a look for the three dot `...` notation to get a fork point and
> also the boundary (`<, >`) indications of left side and right side.
>
>  
>
> Hope that helps for a hint when cross checking with the various man pages.
>
>  
>
> Philip.
>
>
> On Saturday, June 20, 2020 at 5:12:18 PM UTC+1, lbd...@gmail.com
> <mailto:lbd...@gmail.com> wrote:
>
> Is there a command that will show the files that changed when
> changing branches?
>
>  
>
> I want to have an easy way to tell which files have changed when I
> switch from Branch A to Branch B, or vice versa.
>
>  
>
> This seems to work but I can’t easily tell which files changed in
> which branch (or I’m just not seeing it):
>
>  
>
> git diff --name-status branch1 branch2
>
>  
>
>  
>
> Thank you
>
>  
>
>  
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character
> is what you are, reputation merely what others think you are." -
> John Wooden
>
>  
>
>

-- 
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/fd81b1fd-47fc-340f-a9f0-a6ffcb1013d2%40iee.email.

RE: [git-users] Re: Git - how to determine what files changes

[lbdyck]

The scenario is this:
Create a master branch - make updates - add/commit
New branch to branchB - make changes/updates - add/commit
New branch to branch C (from branchB) - make changes/updates - add/commit

issue git diff --name-status master branchB and all is good
issue git diff --name-status branchB branchC and all is good
issue git diff --name-status master branchC and get invalid results (

When I do this on my windows 10 pc everything works and no invalid results.

Using Rocket Port of git at git version 2.14.4_zos_b09
and Windows version at git version 2.17.1

Is this a known issue?

Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

 

From: git-users@googlegroups.com  On Behalf Of 
Philip Oakley
Sent: Saturday, June 20, 2020 5:01 PM
To: Git for human beings 
Subject: [git-users] Re: Git - how to determine what files changes

 

Do you mean that you simply need to get the direct difference between A and B.

 

Or do you mean you want to see hwat changed in A since B was forked, and like 
wise what changed in B since that same fork point?

 

Have a look for the three dot `...` notation to get a fork point and also the 
boundary (`<, >`) indications of left side and right side.

 

Hope that helps for a hint when cross checking with the various man pages.

 

Philip.


On Saturday, June 20, 2020 at 5:12:18 PM UTC+1, lbd...@gmail.com 
<mailto:lbd...@gmail.com>  wrote:

Is there a command that will show the files that changed when changing branches?

 

I want to have an easy way to tell which files have changed when I switch from 
Branch A to Branch B, or vice versa.

 

This seems to work but I can’t easily tell which files changed in which branch 
(or I’m just not seeing it):

 

git diff --name-status branch1 branch2

 

 

Thank you

 

 

Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

 

-- 
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 
<mailto:git-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/454e6368-6c62-4bbd-a953-65c8c1604b48o%40googlegroups.com
 
<https://groups.google.com/d/msgid/git-users/454e6368-6c62-4bbd-a953-65c8c1604b48o%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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/02f601d648b5%24b1eeb560%2415cc2020%24%40gmail.com.

RE: [git-users] Re: Git - how to determine what files changes

[lbdyck]

I don’t see three dots when I do the “git diff –name-status branch-1 branch-2”

 

But what I’m also finding is that the diff report is not accurate in this case:

 

   Master –> Branch-1

   Branch-1 --> Branch-2

 

The diff for master to and from branch-1 is accurate

 

The diff for branch-1 to and from branch-2 is accurate

 

The diff for master to and from branch-2 is completely wrong

 

Is there a better way to find the changes/diff between 2 branches?

 

Thanks very much

 

 

Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

 

From: git-users@googlegroups.com  On Behalf Of 
Philip Oakley
Sent: Saturday, June 20, 2020 5:01 PM
To: Git for human beings 
Subject: [git-users] Re: Git - how to determine what files changes

 

Do you mean that you simply need to get the direct difference between A and B.

 

Or do you mean you want to see hwat changed in A since B was forked, and like 
wise what changed in B since that same fork point?

 

Have a look for the three dot `...` notation to get a fork point and also the 
boundary (`<, >`) indications of left side and right side.

 

Hope that helps for a hint when cross checking with the various man pages.

 

Philip.


On Saturday, June 20, 2020 at 5:12:18 PM UTC+1, lbd...@gmail.com 
<mailto:lbd...@gmail.com>  wrote:

Is there a command that will show the files that changed when changing branches?

 

I want to have an easy way to tell which files have changed when I switch from 
Branch A to Branch B, or vice versa.

 

This seems to work but I can’t easily tell which files changed in which branch 
(or I’m just not seeing it):

 

git diff --name-status branch1 branch2

 

 

Thank you

 

 

Lionel B. Dyck <
Website: https://www.lbdsoftware.com

"Worry more about your character than your reputation.  Character is what you 
are, reputation merely what others think you are." - John Wooden

 

-- 
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 
<mailto:git-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/454e6368-6c62-4bbd-a953-65c8c1604b48o%40googlegroups.com
 
<https://groups.google.com/d/msgid/git-users/454e6368-6c62-4bbd-a953-65c8c1604b48o%40googlegroups.com?utm_medium=email_source=footer>
 .

-- 
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/023701d6489a%24e86d02b0%24b9470810%24%40gmail.com.

[git-users] Re: Git - how to determine what files changes

[Philip Oakley]

Do you mean that you simply need to get the direct difference between A and 
B.

Or do you mean you want to see hwat changed in A since B was forked, and 
like wise what changed in B since that same fork point?

Have a look for the three dot `...` notation to get a fork point and also 
the boundary (`<, >`) indications of left side and right side.

Hope that helps for a hint when cross checking with the various man pages.

Philip.

On Saturday, June 20, 2020 at 5:12:18 PM UTC+1, lbd...@gmail.com wrote:
>
> Is there a command that will show the files that changed when changing 
> branches?
>
>  
>
> I want to have an easy way to tell which files have changed when I switch 
> from Branch A to Branch B, or vice versa.
>
>  
>
> This seems to work but I can’t easily tell which files changed in which 
> branch (or I’m just not seeing it):
>
>  
>
> git diff --name-status branch1 branch2
>
>  
>
>  
>
> Thank you
>
>  
>
>  
>
> Lionel B. Dyck <
> Website: https://www.lbdsoftware.com
>
> "Worry more about your character than your reputation.  Character is what 
> you are, reputation merely what others think you are." - John Wooden
>
>  
>

-- 
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/454e6368-6c62-4bbd-a953-65c8c1604b48o%40googlegroups.com.

[git-users] Re: Git with Samba: "Unlink of file"

[Roberto Marzialetti]

I comment on my post hoping that it will help someone who has the same 
problem.

I reinstalled the machine with Samba and Linux:

- with Ubuntu Server 20.0 -> still problem
- with Ubuntu Desktop 20.0 -> still problem
- with Centos 8 -> Solved


Il giorno giovedì 18 giugno 2020 18:44:10 UTC+2, Roberto Marzialetti ha 
scritto:
>
> Please, this is not the classic problem about that process still blocking 
> that file :-)
>
>
> *My configuration:*
>
> - remote repository on Gitlab.
>
> - Windows 10 machine
> with git (v. 2.25.1.windows.1)
>
> - Linux machine (Ubuntu) for local repositories (S:)
> with Samba (v. 4.11.6-Ubuntu)
>
> *The problem*
>
> From the Windows 10 machine CLI:
>
> git clone -v --recurse-submodules --progress --verbose "
> https://gitlab.com/my-org/my-project.git; "S:/workspace/my-project/code"
>
> I'm getting this error:
>
> POST git-upload-pack (175 bytes)
> remote: Enumerating objects: 1591, done.
> remote: Counting objects: 100% (1591/1591), done.
> remote: Compressing objects: 100% (1259/1259), done.
> remote: Total 1591 (delta 318), reused 1543 (delta 270), pack-reused 0
> Receiving objects: 100% (1591/1591), 6.60 MiB | 5.46 MiB/s, done.
> Resolving deltas: 100% (318/318), done.
>
>
> Unlink of file 'assets/main/packs/fancybox' failed. Should I try again? (y
> /n)
>
>
>
> *Troubleshooting*
>
> The problem is not always related to the same directory (in this example: 
> "fancybox").
> But it **always** occurs after the download is complete (100%)
>
> From my Windows machine, with ProcessExplorer, I don't see any process 
> blocking that folder.
> Likewise, the same from the Linux machine with Samba.
>
> This is my smbstatus -L:
>
>
> 28971  65534  DENY_NONE  0x120089RDONLY  LEASE(RWH)  /home/htdocs   
> workspace/my-project/code/.git/objects/pack/pack-
> 3f0aa70acd802c42ee978f95bc62f61f24dc07d6.idx
> 28971  65534  DENY_NONE  0x12019fRDWRLEASE(RWH)  /home/htdocs   
> workspace/my-project/code/.git/index.lock
> 28971  65534  DENY_NONE  0x120089RDONLY  LEASE(RWH)  /home/htdocs   
> workspace/my-project/code/.git/objects/pack/pack-
> 3f0aa70acd802c42ee978f95bc62f61f24dc07d6.pack
>
>
> On request:
>
> Unlink of file 'assets/main/packs/fancybox' failed. Should I try again? (y
> /n)
>
> I tried to unlock this locked folder:
>
> - to assign permissions 777 to all respository
> - to kill the Samba process 28971 about my folder
>
> but git keeps asking me if i want to try again :-(
>
>
> I also tried setting up to have multiple debug messages:
>
> GIT_CURL_VERBOSE = 2
> and
> GIT_TRACE=1
>
>
> but I didn't get the info I need.
>
> This problem occurs to me and to another user.
> While to another colleague (same configuration), never.
>
> In my office, for everything else, the network works well: we have no 
> problems for copying, moving files from Win to Linux machine on the network.
>
> Some idea?
>

-- 
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/bdb5dac3-00ef-435d-b64e-4b48cb4f5b04o%40googlegroups.com.

[git-users] Re: git reports conflicts for files not mutually changed

[Guilherme Cavalcanti]

Hi Philip! Thanks for the response.

You are talking about different files: the file with (2+-) changes is 
"OutOfTimerCrossValidator.java" and the file in conflict is 
"OutOfTimeCrossValidator*Runner*.java". 

I found this on the documentation 
(https://git-scm.com/docs/merge-strategies), perhaps this is the case:

>
> *With the strategies that use 3-way merge (including the default, 
> recursive), if a change is made on both branches, but later reverted on one 
> of the branches, that change will be present in the merged result; some 
> people find this behavior confusing. It occurs because only the heads and 
> the merge base are considered when performing a merge, not the individual 
> commits. The merge algorithm therefore considers the reverted change as no 
> change at all, and substitutes the changed version instead.*
>


Em segunda-feira, 25 de maio de 2020 13:46:26 UTC-3, Philip Oakley escreveu:
>
> In the Merge Left marker it shows a very small change (2+-) for that file, 
> at least I think that's the file. 
>
> Did you expect that? What was the change? Was it a white space or end of 
> line (eol) change)?
>
> You may have a 3-way merge (mergebase, left and right commits) detecting 
> the white space anomaly.
>
> P.
>
> On Monday, May 25, 2020 at 5:05:21 PM UTC+1, Guilherme Cavalcanti wrote:
>>
>> Dears, 
>>
>> I am facing situations in which only one of the developers/branches 
>> changes a specific file, but git merge reports a merge conflict for that 
>> file. So, why is git reporting conflict for files not mutually changed? 
>> In the example below, the file "OutOfTimeCrossValidatorRunner.java" 
>> (underlined in red) is changed by only one of the parents of a merge 
>> commit, but git merge still reports a conflict for that file as you can see 
>> in the bottom of the image.
>> As further observation, I printed the temporary files used/passed to git 
>> merge, and I noted that they are different from the files present in the 
>> commits.
>> Thanks in advance.
>>
>>

-- 
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/86dc5f99-fd0a-4b5a-a087-704103e02fde%40googlegroups.com.

[git-users] Re: git reports conflicts for files not mutually changed

[Philip Oakley]

In the Merge Left marker it shows a very small change (2+-) for that file, 
at least I think that's the file. 

Did you expect that? What was the change? Was it a white space or end of 
line (eol) change)?

You may have a 3-way merge (mergebase, left and right commits) detecting 
the white space anomaly.

P.

On Monday, May 25, 2020 at 5:05:21 PM UTC+1, Guilherme Cavalcanti wrote:
>
> Dears, 
>
> I am facing situations in which only one of the developers/branches 
> changes a specific file, but git merge reports a merge conflict for that 
> file. So, why is git reporting conflict for files not mutually changed? 
> In the example below, the file "OutOfTimeCrossValidatorRunner.java" 
> (underlined in red) is changed by only one of the parents of a merge 
> commit, but git merge still reports a conflict for that file as you can see 
> in the bottom of the image.
> As further observation, I printed the temporary files used/passed to git 
> merge, and I noted that they are different from the files present in the 
> commits.
> Thanks in advance.
>
>

-- 
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/6ddc1dc8-20e8-4fd8-8119-dca8a740f199%40googlegroups.com.

Re: [git-users] Re: Git completely thrown a curveball now...

[Philip Oakley]

Hi Shannon,

>I think I know what happened now after analysis.

That's good news. A chance to mark it all up as a 'learning experience'
after the initial frustrations.

I hadn't realised that you could get into that issue on GitLab. Maybe as
the repo owner, the "request" was automatically accepted, even though
you got to cancel it later. dunno.

Glad it's resolved.
P.

On 19/05/2020 00:31, SJW wrote:
> I think I know what happened now after analysis.
> I followed the message I received when I pushed the branch to origin: 
>
> remote:
> remote: To create a merge request for payment-gateway, visit:
> remote: 
>  
> https://gitlab.com/SJW/absee/-/merge_requests/new?merge_request%5Bsource_branch%5D=aftersales
> remote:
>
> I then realised that I should do be doing it on local machine so I
> cancelled and deleted the merge request BUT, looking at the GitLab
> history, it shows in the merge history so I am guessing that this was
> the problem... 
>
> I found that it was only the one line that didn't get included which
> was the last change I made which lead me to the above assumption. So I
> manually added it to master an moved on
>
> On Monday, 18 May 2020 18:28:56 UTC+10, Philip Oakley wrote:
>
> Which way did you merge? did you merge the what was in master into
> aftersales, or the other way around?
>
> Have you used a repository viewer like gitk which will show where
> the two branches are pointing to and the changes that each commit
> / merge has?
>
> Can you show a small extract of you difficultly, such as a diff of
> one erroneous file between master and aftersales, with a
> description of why it is 'wrong'.
>
>
> P.
>
> On Monday, May 18, 2020 at 3:06:04 AM UTC+1, SJW wrote:
>
> I have my `master`
>
> I created a branch `aftersales`
>
> Today I finalised `aftersales` and commenced a merge.  There
> were a few conflicts which I worked through and fixed,
> committed and finished merge.
>
> When I published to my staging server, it wasn't working so I
> went back and checked the code... A part of the code was
> missing... So I checked out `aftersales` again to find out
> what happened...
>
> I checked and the code was there in the `aftersales` branch...
> I went back to `master` and the code wasn't there... How could
> this be? I merged a branch and there was code sitting on the
> branch but not in the `master`
>
> I tried to merge again ... 
>
> $ git merge aftersales
> Alreadyup-to-date.
>
> WTF? What do I do now?
>
> Biggest concern: How much other code was "ignored" in the merge...
> How do I get the code into master??? (Obviously I can make
> changes directly into master, copying the changes in but...
> I'm sure that is not the intended git process???)
>
>

-- 
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/ebf390e5-3303-567e-102d-41dbb503c7e7%40iee.email.

[git-users] Re: Git completely thrown a curveball now...

[SJW]

I think I know what happened now after analysis.
I followed the message I received when I pushed the branch to origin: 

remote:
remote: To create a merge request for payment-gateway, visit:
remote:  
 
https://gitlab.com/SJW/absee/-/merge_requests/new?merge_request%5Bsource_branch%5D=aftersales
remote:

I then realised that I should do be doing it on local machine so I 
cancelled and deleted the merge request BUT, looking at the GitLab history, 
it shows in the merge history so I am guessing that this was the problem... 

I found that it was only the one line that didn't get included which was 
the last change I made which lead me to the above assumption. So I manually 
added it to master an moved on

On Monday, 18 May 2020 18:28:56 UTC+10, Philip Oakley wrote:
>
> Which way did you merge? did you merge the what was in master into 
> aftersales, or the other way around? 
>
> Have you used a repository viewer like gitk which will show where the two 
> branches are pointing to and the changes that each commit / merge has?
>
> Can you show a small extract of you difficultly, such as a diff of one 
> erroneous file between master and aftersales, with a description of why it 
> is 'wrong'.
>
>
> P.
>
> On Monday, May 18, 2020 at 3:06:04 AM UTC+1, SJW wrote:
>>
>> I have my `master`
>>
>> I created a branch `aftersales`
>>
>> Today I finalised `aftersales` and commenced a merge.  There were a few 
>> conflicts which I worked through and fixed, committed and finished merge.
>>
>> When I published to my staging server, it wasn't working so I went back 
>> and checked the code... A part of the code was missing... So I checked out 
>> `aftersales` again to find out what happened...
>>
>> I checked and the code was there in the `aftersales` branch... I went 
>> back to `master` and the code wasn't there... How could this be? I merged a 
>> branch and there was code sitting on the branch but not in the `master`
>>
>> I tried to merge again ... 
>>
>> $ git merge aftersales
>> Already up-to-date.
>>
>> WTF? What do I do now?
>>
>> Biggest concern: How much other code was "ignored" in the merge...
>> How do I get the code into master??? (Obviously I can make changes 
>> directly into master, copying the changes in but... I'm sure that is not 
>> the intended git process???)
>>
>

-- 
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/67d1c241-848a-4713-941b-e3faf1df4df5%40googlegroups.com.

[git-users] Re: Git completely thrown a curveball now...

[Philip Oakley]

Which way did you merge? did you merge the what was in master into 
aftersales, or the other way around? 

Have you used a repository viewer like gitk which will show where the two 
branches are pointing to and the changes that each commit / merge has?

Can you show a small extract of you difficultly, such as a diff of one 
erroneous file between master and aftersales, with a description of why it 
is 'wrong'.


P.

On Monday, May 18, 2020 at 3:06:04 AM UTC+1, SJW wrote:
>
> I have my `master`
>
> I created a branch `aftersales`
>
> Today I finalised `aftersales` and commenced a merge.  There were a few 
> conflicts which I worked through and fixed, committed and finished merge.
>
> When I published to my staging server, it wasn't working so I went back 
> and checked the code... A part of the code was missing... So I checked out 
> `aftersales` again to find out what happened...
>
> I checked and the code was there in the `aftersales` branch... I went back 
> to `master` and the code wasn't there... How could this be? I merged a 
> branch and there was code sitting on the branch but not in the `master`
>
> I tried to merge again ... 
>
> $ git merge aftersales
> Already up-to-date.
>
> WTF? What do I do now?
>
> Biggest concern: How much other code was "ignored" in the merge...
> How do I get the code into master??? (Obviously I can make changes 
> directly into master, copying the changes in but... I'm sure that is not 
> the intended git process???)
>

-- 
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/6e134c95-a144-4d09-81db-8351d2cc2e34%40googlegroups.com.

[git-users] Re: git-recent: Quickly check out your favorite branches

[Philip Oakley]

my aliases are:

alias.bsort for-each-ref --sort=committerdate --format='%(refname:short) 
%(committerdate:short) %(authorname)' refs/heads
alias.bsort2 for-each-ref --sort=authordate --format='%(refname:short) 
%(committerdate:short) %(authorname)' refs/heads
alias.bsort-rem for-each-ref --sort=authordate --format='%(refname:short) 
%(committerdate:short) %(authorname)' refs/remotes/my

so `git bsort` list my branches in commit date order, so the most recent is 
right next to the (next) command prompt.
v2 is author date order, should I have rebased my work
bsort-rem looks at the remote called "my", which is... obviously mine...

On Sunday, May 17, 2020 at 12:15:33 PM UTC+1, Ram Rachum wrote:
>
> Hi everyone!
>
> I just released a new Git command: https://github.com/cool-RR/git-recent/
>
> git-recent is a tool for quickly checking out your favorite branches.
>
> Typing `git recent` shows you the last 5 branches you were on, and lets 
> you check them out with 2 keystrokes.
>
>
> Enjoy!
> Ram.
>

-- 
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/0a372704-1e52-47da-a09c-f1edac15d17d%40googlegroups.com.

[git-users] Re: Git keeps getting out of sync and I cant figure it out

[Philip Oakley]

You mention  that you think you are "overwriting changes". While that is 
what it looks like on the surface, it isn't actually true below the surface 
in the repository. The repository is a Write Once Read Many (WORM) type 
storage, so all your previous writings are still there, waiting to be 
re-used and brought back.

Things take weeks to be removed by the garbage collector (gc) and perhaps 
an explicit --prune command. (also search for 'git lost & found' for ways 
of discovering apparently abandoned work)

The gitk visualiser tool can be useful for investigating what you have 
stored. There is also the recent blog 
https://dev.to/lydiahallie/cs-visualized-useful-git-commands-37p1 which 
shows some nice graphics of how the repo storage extends.

The most common problem, as a beginner, is forgetting to create a fresh 
branch (which is simply a pointer to the 'WORM' storage), so that your new 
work isn't confused with what was on the 'master' branch.

The second thing is then to suddenly realise that "remotes" aren't really 
remote, but actually a local copy of what was on the true remote server 
last time you looked. This means that you should "never" use 'master' 
because really what you wanted to refer to was the branch called 
'origin/master' (other remote names are possible, not just 'origin)  when 
you created your new branch (i.e. work on top of what was at the 
remote!!).  

This is why the 'pull' got confused. It fetch the remote server (to 
origin//master) and then found that you'd done some extra work on the side 
having been asked to merge as a fact forward.. tut tut.. (pull = fetch + 
merge)

Usually, after your mistake of extra work on the wrong branch (such as 
master):

try `git switch -c my_new_branch master` (This assumes you are 'clean', if 
not stash your changes)
then later you can `git switch -C master origin/master`  (this puts you 
back on master, back at the point it should have been)
finally `git switch my_new_branch`  (back to your work, un-stashing any 
changes you needed to hide away while doing the shuffle)

[Note the small c and big C in the two commands, check the manual `git help 
switch` to see why the second command needed the big C)]

Hope that helps.  

On Monday, April 27, 2020 at 3:48:22 AM UTC+1, SJW wrote:
>
> I keep trying to learn and use git but I keep screwing up my work - 
> overwriting changes and creating duplicate efforts.
>
> I made some changes today, but was on the wrong branch - when trying to 
> change branch I screwed up 
> I made the changes again and then tried to push to master and I get this:
>
> $ git push origin master
> To https://gitlab.com/SJWGitLab/absee.net.au.git
>  ! [rejected]master -> master (non-fast-forward)
> error: failed to push some refs to '
> https://gitlab.com/SJWGitLab/absee.net.au.git'
> hint: Updates were rejected because the tip of your current branch is 
> behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
>
> It says do a git pull BUT, my understanding is that doing a pull will 
> overwrite my code with the origin and delete my recent changes.
>
> I did a git diff but it gave me nothing... I dont want the origin to be 
> the master - my local is the master... 
>
> I'm having a real hard time with git and dont understand how it is so 
> popular - it has added an extra layer of complexity and confusion on top of 
> managing code that is creating so much rework and recoding... What am I 
> missing? 
>

-- 
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/7a484341-257c-48b6-9039-75f74e3605e1%40googlegroups.com.

[git-users] Re: git-bash (Windows) displays the wrong version.

[Ahmet Karahan]

Thank you Philip, your guidence helped me to find the correct path. I 
couldn't find with cmd.exe, that I had 3 versions of Git on my machine.  
But I could find them using git-bash. One of them is found inside Anaconda, 
the other one came with C++ and Codelite installaiton and the one that I've 
updated was in "Program files/Git". I've changed the wrong paths editing 
the PATH environment variable and now it shows the correct version. This 
was a 2 weeks headache, thank you very much.

26 Nisan 2020 Pazar 23:35:34 UTC+3 tarihinde Philip Oakley yazdı:
>
> Hi Ahmet,
>
> I presume you know that you can have multiple copies of git, at different 
> versions, on the same machine. And they 'look' the same, because each has a 
> different fake root directory.
>
> IN each of the two tests, 
> `cd / # to get to the root dir
> pwd -W # to get the windows path of the current directory.
> git --version # what have I got here?
>
> 
> I've got both the SDK and the regular Git-for-Windows download, which 
> currently are the same version, but often not. (as below.)
> You may have a separate version for the VS code install.
>
>
> phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/build-extra (relnoteicon)
> $ cd / # get to the root dir
>
> phili@Philip-Win10 MINGW64 / ((685647a82...))
> $ pwd -W # to get the windows path of the current directory.
> C:/git-sdk-64
>
> phili@Philip-Win10 MINGW64 / ((685647a82...))
> $ git --version # what have I got here?
> git version 2.26.2.windows.1
>
> phili@Philip-Win10 MINGW64 / ((685647a82...))
> $
> --
>
> phili@Philip-Win10 MINGW64 ~
> $ cd / # get to the root dir
>
> phili@Philip-Win10 MINGW64 /
> $ pwd -W # to get the windows path of the current directory.
> C:/Program Files/Git
>
> phili@Philip-Win10 MINGW64 /
> $ git --version # what have I got here?
> git version 2.26.2.windows.1
> ---
>
> Philip
>
> On Sunday, April 26, 2020 at 1:31:24 PM UTC+1, Ahmet Karahan wrote:
>>
>> I installed Git on my Windows machine months ago but had no time to start 
>> with Git. Finally 2 weeks ago I started to learn Git, when it committed an 
>> update request. 
>> I updated to version 2.26.1. I started Windows cmd.exe and typed git 
>> --version. Perfect! the updated version number was displayed, 'git version 
>> 2.26.1.windows.1'
>>
>> Problem:
>> And then I runned git-bash, typed again git --version,  but it did not 
>> display the actual version that I've installed 5 mins ago, instead it 
>> displayed 'git version 2.20.1.windows.1'. 
>>
>> What I did?
>> I uninstalled and reinstalled version 2.26.1, and I tested git-bash after 
>> new installation. The same happened, git-bash displayed 2.20.
>> A week after, I typed in Windows cmd.exe 'git update-git-for-windows'. It 
>> updated to 2.26.2 successfuly. But the problem didn't solved.
>> Suspecting that the path connected to the git-bash icon may have been 
>> linked to an older version, I went to the folder where Git was located and 
>> ran git-bash.exe inside the last installation folder. And again nothing has 
>> changed. Now I doubt that this is a bug. Can you test this possibility on 
>> your machines, please? Or something is wrong/missing with my Windows 
>> installation, what can it be?
>>
>>
>> I send you screen capture of both windows, above the cmd.exe below the 
>> git-bash.exe after the installation.
>>
>> [image: git-bash.JPG]
>>
>>

-- 
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/23015ed3-ae21-4731-93a9-f329fd996248%40googlegroups.com.

[git-users] Re: git-bash (Windows) displays the wrong version.

[Ahmet Karahan]

Thank you Philip, your guidence helped me to find the correct path. I 
couldn't find with cmd.exe, that I had 3 versions of Git on my machine.  
But I could find them using git-bash. One of them is found inside Anaconda, 
the other one came with C++ and Codelite installaiton and the one that I've 
updated was in "Program files/Git". I've changed the wrong paths editing 
the PATH environment variable and now it shows the correct version. This 
was a 2 weeks headache, thank you very much.

26 Nisan 2020 Pazar 23:35:34 UTC+3 tarihinde Philip Oakley yazdı:
>
> Hi Ahmet,
>
> I presume you know that you can have multiple copies of git, at different 
> versions, on the same machine. And they 'look' the same, because each has a 
> different fake root directory.
>
> IN each of the two tests, 
> `cd / # to get to the root dir
> pwd -W # to get the windows path of the current directory.
> git --version # what have I got here?
>
> 
> I've got both the SDK and the regular Git-for-Windows download, which 
> currently are the same version, but often not. (as below.)
> You may have a separate version for the VS code install.
>
>
> phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/build-extra (relnoteicon)
> $ cd / # get to the root dir
>
> phili@Philip-Win10 MINGW64 / ((685647a82...))
> $ pwd -W # to get the windows path of the current directory.
> C:/git-sdk-64
>
> phili@Philip-Win10 MINGW64 / ((685647a82...))
> $ git --version # what have I got here?
> git version 2.26.2.windows.1
>
> phili@Philip-Win10 MINGW64 / ((685647a82...))
> $
> --
>
> phili@Philip-Win10 MINGW64 ~
> $ cd / # get to the root dir
>
> phili@Philip-Win10 MINGW64 /
> $ pwd -W # to get the windows path of the current directory.
> C:/Program Files/Git
>
> phili@Philip-Win10 MINGW64 /
> $ git --version # what have I got here?
> git version 2.26.2.windows.1
> ---
>
> Philip
>
> On Sunday, April 26, 2020 at 1:31:24 PM UTC+1, Ahmet Karahan wrote:
>>
>> I installed Git on my Windows machine months ago but had no time to start 
>> with Git. Finally 2 weeks ago I started to learn Git, when it committed an 
>> update request. 
>> I updated to version 2.26.1. I started Windows cmd.exe and typed git 
>> --version. Perfect! the updated version number was displayed, 'git version 
>> 2.26.1.windows.1'
>>
>> Problem:
>> And then I runned git-bash, typed again git --version,  but it did not 
>> display the actual version that I've installed 5 mins ago, instead it 
>> displayed 'git version 2.20.1.windows.1'. 
>>
>> What I did?
>> I uninstalled and reinstalled version 2.26.1, and I tested git-bash after 
>> new installation. The same happened, git-bash displayed 2.20.
>> A week after, I typed in Windows cmd.exe 'git update-git-for-windows'. It 
>> updated to 2.26.2 successfuly. But the problem didn't solved.
>> Suspecting that the path connected to the git-bash icon may have been 
>> linked to an older version, I went to the folder where Git was located and 
>> ran git-bash.exe inside the last installation folder. And again nothing has 
>> changed. Now I doubt that this is a bug. Can you test this possibility on 
>> your machines, please? Or something is wrong/missing with my Windows 
>> installation, what can it be?
>>
>>
>> I send you screen capture of both windows, above the cmd.exe below the 
>> git-bash.exe after the installation.
>>
>> [image: git-bash.JPG]
>>
>>

-- 
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/8e28e399-69c3-49ed-9399-5f57ee9d1a4e%40googlegroups.com.

[git-users] Re: git-bash (Windows) displays the wrong version.

[Ahmet Karahan]

Thank you Philip, your guidence helped me to find the correct path. I 
couldn't find with cmd.exe, that I had 3 versions of Git on my machine.  
But I could find them using git-bash. One of them is found inside Anaconda, 
the other one came with C++ and Codelite installaiton and the one that I've 
updated was in "Program files/Git". I've changed the wrong paths editing 
the PATH environment variable and now it shows the correct version. This 
was a 2 weeks headache, thank you very much.

26 Nisan 2020 Pazar 15:31:24 UTC+3 tarihinde Ahmet Karahan yazdı:
>
> I installed Git on my Windows machine months ago but had no time to start 
> with Git. Finally 2 weeks ago I started to learn Git, when it committed an 
> update request. 
> I updated to version 2.26.1. I started Windows cmd.exe and typed git 
> --version. Perfect! the updated version number was displayed, 'git version 
> 2.26.1.windows.1'
>
> Problem:
> And then I runned git-bash, typed again git --version,  but it did not 
> display the actual version that I've installed 5 mins ago, instead it 
> displayed 'git version 2.20.1.windows.1'. 
>
> What I did?
> I uninstalled and reinstalled version 2.26.1, and I tested git-bash after 
> new installation. The same happened, git-bash displayed 2.20.
> A week after, I typed in Windows cmd.exe 'git update-git-for-windows'. It 
> updated to 2.26.2 successfuly. But the problem didn't solved.
> Suspecting that the path connected to the git-bash icon may have been 
> linked to an older version, I went to the folder where Git was located and 
> ran git-bash.exe inside the last installation folder. And again nothing has 
> changed. Now I doubt that this is a bug. Can you test this possibility on 
> your machines, please? Or something is wrong/missing with my Windows 
> installation, what can it be?
>
>
> I send you screen capture of both windows, above the cmd.exe below the 
> git-bash.exe after the installation.
>
> [image: git-bash.JPG]
>
>

-- 
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/71814638-1af3-464a-9092-16e1bd186480%40googlegroups.com.

[git-users] Re: Git keeps getting out of sync and I cant figure it out

[SJW]

Ok, I just went ahead and did a pull... It shows me the changes...
I realised that on Friday I modified the README.md...
It's way too hard to keep up... I think git is too complicated for me...
thanks anyway

On Monday, 27 April 2020 12:48:22 UTC+10, SJW wrote:
>
> I keep trying to learn and use git but I keep screwing up my work - 
> overwriting changes and creating duplicate efforts.
>
> I made some changes today, but was on the wrong branch - when trying to 
> change branch I screwed up 
> I made the changes again and then tried to push to master and I get this:
>
> $ git push origin master
> To https://gitlab.com/SJWGitLab/absee.net.au.git
>  ! [rejected]master -> master (non-fast-forward)
> error: failed to push some refs to '
> https://gitlab.com/SJWGitLab/absee.net.au.git'
> hint: Updates were rejected because the tip of your current branch is 
> behind
> hint: its remote counterpart. Integrate the remote changes (e.g.
> hint: 'git pull ...') before pushing again.
> hint: See the 'Note about fast-forwards' in 'git push --help' for details.
>
>
> It says do a git pull BUT, my understanding is that doing a pull will 
> overwrite my code with the origin and delete my recent changes.
>
> I did a git diff but it gave me nothing... I dont want the origin to be 
> the master - my local is the master... 
>
> I'm having a real hard time with git and dont understand how it is so 
> popular - it has added an extra layer of complexity and confusion on top of 
> managing code that is creating so much rework and recoding... What am I 
> missing? 
>

-- 
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/1d3bbbca-ee74-4239-a1b9-0d188859a894%40googlegroups.com.

[git-users] Re: git-bash (Windows) displays the wrong version.

[Philip Oakley]

Hi Ahmet,

I presume you know that you can have multiple copies of git, at different 
versions, on the same machine. And they 'look' the same, because each has a 
different fake root directory.

IN each of the two tests, 
`cd / # to get to the root dir
pwd -W # to get the windows path of the current directory.
git --version # what have I got here?


I've got both the SDK and the regular Git-for-Windows download, which 
currently are the same version, but often not. (as below.)
You may have a separate version for the VS code install.


phili@Philip-Win10 MINGW64 /c/git-sdk-64/usr/src/build-extra (relnoteicon)
$ cd / # get to the root dir

phili@Philip-Win10 MINGW64 / ((685647a82...))
$ pwd -W # to get the windows path of the current directory.
C:/git-sdk-64

phili@Philip-Win10 MINGW64 / ((685647a82...))
$ git --version # what have I got here?
git version 2.26.2.windows.1

phili@Philip-Win10 MINGW64 / ((685647a82...))
$
--

phili@Philip-Win10 MINGW64 ~
$ cd / # get to the root dir

phili@Philip-Win10 MINGW64 /
$ pwd -W # to get the windows path of the current directory.
C:/Program Files/Git

phili@Philip-Win10 MINGW64 /
$ git --version # what have I got here?
git version 2.26.2.windows.1
---

Philip

On Sunday, April 26, 2020 at 1:31:24 PM UTC+1, Ahmet Karahan wrote:
>
> I installed Git on my Windows machine months ago but had no time to start 
> with Git. Finally 2 weeks ago I started to learn Git, when it committed an 
> update request. 
> I updated to version 2.26.1. I started Windows cmd.exe and typed git 
> --version. Perfect! the updated version number was displayed, 'git version 
> 2.26.1.windows.1'
>
> Problem:
> And then I runned git-bash, typed again git --version,  but it did not 
> display the actual version that I've installed 5 mins ago, instead it 
> displayed 'git version 2.20.1.windows.1'. 
>
> What I did?
> I uninstalled and reinstalled version 2.26.1, and I tested git-bash after 
> new installation. The same happened, git-bash displayed 2.20.
> A week after, I typed in Windows cmd.exe 'git update-git-for-windows'. It 
> updated to 2.26.2 successfuly. But the problem didn't solved.
> Suspecting that the path connected to the git-bash icon may have been 
> linked to an older version, I went to the folder where Git was located and 
> ran git-bash.exe inside the last installation folder. And again nothing has 
> changed. Now I doubt that this is a bug. Can you test this possibility on 
> your machines, please? Or something is wrong/missing with my Windows 
> installation, what can it be?
>
>
> I send you screen capture of both windows, above the cmd.exe below the 
> git-bash.exe after the installation.
>
> [image: git-bash.JPG]
>
>

-- 
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/f4d4ebd9-795f-4697-bec2-7787a5cba473%40googlegroups.com.

[git-users] Re: git log (HEAD->master, origin/master) vs (HEAD -> master)

[Philip Oakley]

Hi,
I believe this is a natural effect of being a distributed system. The two 
different PC's have different setup, so when git is displaying the local 
repository it can only 'attempt' to infer what the contents of the remote 
repositories (content of other reference servers) is, such as 'origin'

It looks like the other PC either does not have a remote repository called 
'origin' (unlikely), or that that the local PC knows about the remote 
called origin is different to that of the local repository HEAD. It is 
telling you that the HEAD link points to the branch named master (same for 
both PCs), bit that for the second PC, the local branch master  does not 
point to the "remote tracking branch (rtb)" (the local branch that tracks 
the remote branch) of that name. Try `git fetch origin` to bring the rtb up 
to date, and see if it is still showing the same thing, and that the Object 
ID (oid/sha1) values are the same between the two PCs.

Philip


On Monday, April 20, 2020 at 2:06:46 PM UTC+1, ldm wrote:
>
>  
>  Hello,
>   
>  There are two people working on the same project.
>   
>  While doing the 'git log', one see it with (HEAD->master, *origin/master*) 
> and another with just (HEAD -> master) without *origin/master*.
>   
>  What does it mean? Actually one cannot see the commits of another.
>   
>  Thank you!
>   
>

-- 
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/ed799705-9077-4ca0-a4d4-0369109b92b6%40googlegroups.com.

[git-users] Re: Git over Perforce

[Christopher]

I don't want to work between the two systems, I want to work strictly with 
git; but since I'm restricted to a p4 configuration file, work around this 
using only git ? 

Rather then the system, sending or commiting to perforce, it does all this 
though git. I searched the list, but from my search most are working 
between the two systems.

On Monday, February 24, 2020 at 7:32:39 AM UTC-5, Philip Oakley wrote:
>
> Don't know much about Perforce (p4) but there is an interface between the 
> two systems. Search the git list archive for "p4" or "perforce" to get a 
> start
>
> https://lore.kernel.org/git/?q=p4
>
> Philip
>
> On Sunday, February 23, 2020 at 5:16:12 PM UTC, CrestChristopher wrote:
>>
>> How can I create a Perforce configuration file but instead of Perforce I 
>> use only git; is this possible ? 
>>
>> Christopher 
>>
>>

-- 
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/32266bdb-585a-4056-92cc-4de888634fee%40googlegroups.com.

[git-users] Re: Git over Perforce

[Philip Oakley]

Don't know much about Perforce (p4) but there is an interface between the 
two systems. Search the git list archive for "p4" or "perforce" to get a 
start

https://lore.kernel.org/git/?q=p4

Philip

On Sunday, February 23, 2020 at 5:16:12 PM UTC, CrestChristopher wrote:
>
> How can I create a Perforce configuration file but instead of Perforce I 
> use only git; is this possible ? 
>
> Christopher 
>
>

-- 
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/8af2c18e-0025-4f4e-97e5-fc9137b74de4%40googlegroups.com.

[git-users] Re: Git Newbie

[scarlet cult]

thanks  a lot ! really  very helpful 

среда, 15 января 2020 г., 9:19:15 UTC-8 пользователь Subbu Subbu написал:
>
> How do you select the build software after doing a fork of your source in 
> github. How can multiple developers use github.
>
> Regds
> Subbu
>

-- 
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/69d232e5-5629-4f13-97f7-e304c7a81061%40googlegroups.com.

Re: [git-users] Re: git commit message template plugin

[Tim Schofield]

Ok, I have obviously misunderstood. What I was meaning was our system where
that hook throws up a customised commit message with different sections to
be filled in by the user, and I thought that was what you were after.
Apologies for my misunderstanding.

On Fri, 20 Dec 2019, 20:21 Python Prog,  wrote:

> Still doesn't answer my question,I am looking for a UI to pop-up (via
> plugin) on git commit so that user can the requested commit message fields
>
> On Wednesday, December 18, 2019 at 3:42:46 PM UTC-8, Python Prog wrote:
>>
>> Hello
>>
>> I am looking to develop a commit message plugin where developers working
>> on committing changes has an easy way to enter all the required info using
>> the plugin and it gets saved as commit message?has anyone done something
>> like this before?how do I get started ?
>>
> --
> 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/ed11f52d-022c-420b-a3a5-203cfef2f70e%40googlegroups.com
> 
> .
>

-- 
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/CABsfishCQoXOtJm9jYvd7pLqtmKDEbp8Tp6C54X-gvhTXkT6mQ%40mail.gmail.com.

[git-users] Re: git commit message template plugin

[Python Prog]

Still doesn't answer my question,I am looking for a UI to pop-up (via 
plugin) on git commit so that user can the requested commit message fields 

On Wednesday, December 18, 2019 at 3:42:46 PM UTC-8, Python Prog wrote:
>
> Hello
>
> I am looking to develop a commit message plugin where developers working 
> on committing changes has an easy way to enter all the required info using 
> the plugin and it gets saved as commit message?has anyone done something 
> like this before?how do I get started ?
>

-- 
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/ed11f52d-022c-420b-a3a5-203cfef2f70e%40googlegroups.com.

Re: [git-users] Re: Git ignores global filemode setting when clonning new repositories

[Philip Oakley]

Hi Jiří,

The thing to note here is that filemode is only affecting (the 
understanding of) the executable bit.


It does *not* affect the file contents at all, so if the 'empty' 
.gitkeep file is now being shown as having gained a line then there is 
some other effect going on.


It maybe that there is some error/warning/advice message saying that the 
original file had no "end of file" (*) which is being confused as being 
that it has an extra line.


What is the actual message you see? (cut and paste?)

Philip

(*) I have seen discussions that suggest that a proper file, consisting 
of lines of text, should always have a terminating LF (line feed) as 
that is (stated as) the terminating delimiter for a line, so if it isn't 
there, there isn't a line... However some of that is just standards 
lawyering, and is ignored often (I don't even remember which standards 
might have said that - Posix?)


On 21/11/2019 08:04, Jiří Bělský wrote:

Thanks for reply,

Repos are hosted on gitlab and most devs are on linux (but not all) 
and as example, when i set filemode=true in one of the repos, it gives 
me changes in .gitkeep file saying i added a line to it (its empty file)


But again, since it does set it automatically, guess my option will be 
just to manually change it to false each time :)


čt 21. 11. 2019 v 0:30 odesílatel Philip Oakley 
 napsal:


Hi,

the clone command automatically detects if your local file system
is 'filemode' compatible.

`git help config`

search for `core.filemode`

" git-clone(1) or git-init(1) probe the filesystem to see if it
handles the executable bit correctly and this variable is
automatically set as necessary."

You may also need to consider how your team works compatibly
between OS systems. (what OS/version does the maintainer of the
repo being cloned use?)

Perhaps give an example of such a "file changed" report.


On Wednesday, November 20, 2019 at 1:48:34 PM UTC, Jiří Bělský wrote:

Hi,

im pretty sure this must be a bug, no matter what i tried, git
will always ignore filemode=false in global settings and set
filemode=true while cloning new repositories, which results in
having a lot of files tagged as changed.

Commands:
git config --get --global core.filemode
returned: false

git clone [some repository]
cd [some repository]
git config --get --local core.filemode
returned: true

i even tried setting global filemode with sudo, still same
result (:

Elementary OS 5 (based on Ubuntu 18.04)
Git version 2.24.0 (happening on 2.17.X and earlier as well)

-- 
You received this message because you are subscribed to a topic in

the Google Groups "Git for human beings" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/git-users/laea5leUejI/unsubscribe.
To unsubscribe from this group and all its topics, 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/27ce4968-a05e-4363-8e7f-81c726a332b8%40googlegroups.com

.

--
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/CAA2ZSoh30pU3j%3Dp4kr8zpFL1bxHOneLq8E6-3UnWaxq-dthDow%40mail.gmail.com 
.


--
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/34472833-111f-6ad1-1b85-225ecb2a8001%40iee.email.

Re: [git-users] Re: Git ignores global filemode setting when clonning new repositories

[Jiří Bělský]

Thanks for reply,

Repos are hosted on gitlab and most devs are on linux (but not all) and as
example, when i set filemode=true in one of the repos, it gives me changes
in .gitkeep file saying i added a line to it (its empty file)

But again, since it does set it automatically, guess my option will be just
to manually change it to false each time :)

čt 21. 11. 2019 v 0:30 odesílatel Philip Oakley 
napsal:

> Hi,
>
> the clone command *automatically *detects if your local file system is
> 'filemode' compatible.
>
> `git help config`
>
> search for `core.filemode`
>
> " git-clone(1) or git-init(1) probe the filesystem to see if it handles
> the executable bit correctly and this variable is automatically set as
> necessary."
>
> You may also need to consider how your team works compatibly between OS
> systems. (what OS/version does the maintainer of the repo being cloned use?)
>
> Perhaps give an example of such a "file changed" report.
>
>
> On Wednesday, November 20, 2019 at 1:48:34 PM UTC, Jiří Bělský wrote:
>>
>> Hi,
>>
>> im pretty sure this must be a bug, no matter what i tried, *git will
>> always ignore filemode=false in global settings and set filemode=true while
>> cloning new repositories*, which results in having a lot of files tagged
>> as changed.
>>
>> Commands:
>> *git config --get --global core.filemode*
>> returned: *false*
>>
>> *git clone [some repository]*
>> *cd [some repository]*
>>
>> *git config --get --local core.filemode*
>> returned:* true*
>>
>> i even tried setting global filemode with sudo, still same result (:
>>
>> Elementary OS 5 (based on Ubuntu 18.04)
>> Git version 2.24.0 (happening on 2.17.X and earlier as well)
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Git for human beings" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/git-users/laea5leUejI/unsubscribe.
> To unsubscribe from this group and all its topics, 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/27ce4968-a05e-4363-8e7f-81c726a332b8%40googlegroups.com
> 
> .
>

-- 
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/CAA2ZSoh30pU3j%3Dp4kr8zpFL1bxHOneLq8E6-3UnWaxq-dthDow%40mail.gmail.com.

[git-users] Re: Git ignores global filemode setting when clonning new repositories

[Philip Oakley]

Hi,

the clone command *automatically *detects if your local file system is 
'filemode' compatible.

`git help config`

search for `core.filemode`

" git-clone(1) or git-init(1) probe the filesystem to see if it handles the 
executable bit correctly and this variable is automatically set as 
necessary."

You may also need to consider how your team works compatibly between OS 
systems. (what OS/version does the maintainer of the repo being cloned use?)

Perhaps give an example of such a "file changed" report.


On Wednesday, November 20, 2019 at 1:48:34 PM UTC, Jiří Bělský wrote:
>
> Hi,
>
> im pretty sure this must be a bug, no matter what i tried, *git will 
> always ignore filemode=false in global settings and set filemode=true while 
> cloning new repositories*, which results in having a lot of files tagged 
> as changed.
>
> Commands:
> *git config --get --global core.filemode*
> returned: *false*
>
> *git clone [some repository]*
> *cd [some repository]*
>
> *git config --get --local core.filemode*
> returned:* true*
>
> i even tried setting global filemode with sudo, still same result (:
>
> Elementary OS 5 (based on Ubuntu 18.04)
> Git version 2.24.0 (happening on 2.17.X and earlier as well)
>

-- 
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/27ce4968-a05e-4363-8e7f-81c726a332b8%40googlegroups.com.

[git-users] Re: git pull failed.

[Philip Oakley]

So, you need to be on a branch. That is because 'pull' is a fetch, then a 
merge into the current branch.

You could read about 'remote tracking branches' and use just 'fetch',

Or you could start by checking out (or creating) your new current (e.g. 
master) branch.


You did not say how you got to this situation. I guess you have just 
initialised an empty repo and are now trying to get the content from your 
fork on some server. If that is the case you are better to simply use `git 
clone` which will bypass all these mysteries.

Philip

On Thursday, October 3, 2019 at 5:18:26 PM UTC+1, Hongyi Zhao wrote:
>
> $ git pull
> You are not currently on a branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
> git pull  
>
>
> How to solve this issue?
>

-- 
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/5e472816-9701-48c5-92b9-e4967d592f6a%40googlegroups.com.

[git-users] Re: Git pull/checkout streaming API/CLI

[fru xo]

Hi again :)
Thanks for all the feedback, really appreciate it!

If when you say “run git locally” you mean perform the actual checkout by 
running the usual commands, that is what I’m currently doing just to unlock 
myself, but being this part of an API server and being the purpose to store the 
whole repo (compressed) in a cloud storage, I am really keen to make it stream 
based, hoping to lower disk footprint and increase concurrency on each node 
(otherwise bound by the disk space consumed by concurrent invocations.

I’ll check the other links you have provided, thanks a million.

F

-- 
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/5c2fea5a-822a-4be0-bc2b-39e12d313a41%40googlegroups.com.

[git-users] Re: Git pull/checkout streaming API/CLI

[Philip Oakley]

Hi F,

Yes, the  https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols 
are the ones that could be considered as an API. Though it maybe worth 
simply running Git locally so that you don't need to write any code..just a 
few scripts.

Other options are looking at Git Bundle, which is normally used for 
sneakernet environments but can be used as a fake CDN (Content Delivery 
Network). Have a look over the archives https://public-inbox.org/git/?q=CDN 
for various discussions.

Philip

On Sunday, September 8, 2019 at 2:56:51 PM UTC+1, fru xo wrote:
>
> Hi Phillip,
> thanks for the pointers.
>
> I did not know about fast-import/export, I’ll have a look as streaming is 
> what I need :)
> As far as pack streams, is this what you refer to 
> https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols ? I’ve 
> read it this morning, not sure yet if it’ll do but it’s one more tool in my 
> box which might be handy.
>
> I’ll check the first option, thanks again.
> F
>
> On Sunday, 8 September 2019 13:04:26 UTC+1, Philip Oakley wrote:
>>
>> On Sunday, September 8, 2019 at 9:55:23 AM UTC+1, fru xo wrote:
>>>
>>> Hi all,
>>> I’d love to be able to issue a git pull/checkout and stream its results 
>>> to an on-line cloud storage for another party there to actually downloading 
>>> it and working with the source.
>>> Roughly just pipe all from a Git repo into that sink, but I presume I 
>>> would have to compress it somehow on the way.
>>>
>>> So:
>>> 1. any off-the-shelf solution for this (I’ve Googled but no success so 
>>> far)?
>>> 2. any description of the application-level protocol used by Git when 
>>> cloning/pulling/checking-out a repo?
>>>
>>> Thanks in advance,
>>> Francesco
>>>
>>
>> Have you looked at `fast-import` and `fast-export`  as they are designed 
>> as a streaming method. 
>>
>> However, do decide where control and response lies. Your question makes 
>> it sound like you are looking at Git as a service - you maybe just want to 
>> look directly at the Git pack streams that underlie a push/fetch
>> Philip
>>
>

-- 
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/382587ae-57b2-45c0-b22c-b33af2ef8934%40googlegroups.com.

[git-users] Re: Git pull/checkout streaming API/CLI

[fru xo]

Hi Phillip,
thanks for the pointers.

I did not know about fast-import/export, I’ll have a look as streaming is 
what I need :)
As far as pack streams, is this what you refer to 
https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols ? I’ve read 
it this morning, not sure yet if it’ll do but it’s one more tool in my box 
which might be handy.

I’ll check the first option, thanks again.
F

On Sunday, 8 September 2019 13:04:26 UTC+1, Philip Oakley wrote:
>
> On Sunday, September 8, 2019 at 9:55:23 AM UTC+1, fru xo wrote:
>>
>> Hi all,
>> I’d love to be able to issue a git pull/checkout and stream its results 
>> to an on-line cloud storage for another party there to actually downloading 
>> it and working with the source.
>> Roughly just pipe all from a Git repo into that sink, but I presume I 
>> would have to compress it somehow on the way.
>>
>> So:
>> 1. any off-the-shelf solution for this (I’ve Googled but no success so 
>> far)?
>> 2. any description of the application-level protocol used by Git when 
>> cloning/pulling/checking-out a repo?
>>
>> Thanks in advance,
>> Francesco
>>
>
> Have you looked at `fast-import` and `fast-export`  as they are designed 
> as a streaming method. 
>
> However, do decide where control and response lies. Your question makes it 
> sound like you are looking at Git as a service - you maybe just want to 
> look directly at the Git pack streams that underlie a push/fetch
> Philip
>

-- 
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/fc103fc7-c7b1-4d92-a700-a0ecdd7e5c2b%40googlegroups.com.

[git-users] Re: Git pull/checkout streaming API/CLI

[Philip Oakley]

On Sunday, September 8, 2019 at 9:55:23 AM UTC+1, fru xo wrote:
>
> Hi all,
> I’d love to be able to issue a git pull/checkout and stream its results to 
> an on-line cloud storage for another party there to actually downloading it 
> and working with the source.
> Roughly just pipe all from a Git repo into that sink, but I presume I 
> would have to compress it somehow on the way.
>
> So:
> 1. any off-the-shelf solution for this (I’ve Googled but no success so 
> far)?
> 2. any description of the application-level protocol used by Git when 
> cloning/pulling/checking-out a repo?
>
> Thanks in advance,
> Francesco
>

Have you looked at `fast-import` and `fast-export`  as they are designed as 
a streaming method. 

However, do decide where control and response lies. Your question makes it 
sound like you are looking at Git as a service - you maybe just want to 
look directly at the Git pack streams that underlie a push/fetch
Philip

-- 
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/61516c5e-a9f4-4933-8b11-66ffe81ddbe9%40googlegroups.com.

Re: [git-users] Re: git log --graph with a sort of local revision number

[Uwe Brauer]

>>> "PO" == Philip Oakley  writes:

   > What would be the benefit of you having your local reverse count of 
   > commits? I.E Which git commands would actually use that information. 

Convenience. From time to time I want to checkout a commit which is
close to HEAD (say HEAD -3)

So 

 git checkout HEAD~3 

Is more convenient than

 git checkout SOMELONGHASH 

I must even admit that I find the git convention of counting backwards
from HEAD more convenient than mercurial convention of counting forward
from the first commit.

To make that clear such a local revision number is purely convenience.
It has no real meaning.


 
   > Or perhaps maybe at the moment it's more of a comfort blanket desire 
   > because of the idiosyncratic nature of some of the git commands (it can be 
   > a battle...)

That is true (at least compared to mercurial) but that can be dealt
easily with aliasing.

-- 
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/871rxf3qxh.fsf%40mat.ucm.es.


smime.p7s
Description: S/MIME cryptographic signature

[git-users] Re: git log --graph with a sort of local revision number

[Philip Oakley]

What would be the benefit of you having your local reverse count of 
commits? I.E Which git commands would actually use that information. 

Or perhaps maybe at the moment it's more of a comfort blanket desire 
because of the idiosyncratic nature of some of the git commands (it can be 
a battle...)

Philip

On Thursday, August 15, 2019 at 9:34:25 AM UTC+1, UWE RICHARD OTTO BRAUER 
wrote:
>
>
> Hi
>
> I am an occasionally git user and am very used to local revision numbers
> mercurial provides in its log command. I don't want to start the
> discussion whether  local revision numbers are useful or not, nor
> whether mercurial is better or not.
>
> I only want to know whether there is any possibility to have this number
> in the log.
>
> I have seen 
>
>
> https://stackoverflow.com/questions/4120001/what-is-the-git-equivalent-for-revision-number
>
> That 
> git rev-list --count HEAD
>
> But I would like to have it in the 
>
>  git log --graph --decorate
>
> So something like this 
>
> o  changeset:   5:d3ae13222c31
> |  tag: tip
> |  user:Uwe Brauer >
> |  date:Wed Aug 14 14:23:29 2019 +0200
> |  summary: Six
> |
> o  changeset:   4:64a3eee07e93
> |  user:Uwe Brauer >
> |  date:Wed Aug 14 14:23:28 2019 +0200
> |  summary: Fifth
>
>
> Anybody know who to achieve it?
>
> I presume 
>
>  git checkout revnumber
>
> Would not work?
>
> I know that 
>
>  git checkout HEAD~somenumber
>
> Works
>
> Uwe Brauer 
>
>

-- 
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/a682f443-4a08-4c36-af13-67db578919ea%40googlegroups.com.

[git-users] Re: git svn clone author missing in authors file

[HTW]

Sorry for the quite misleading post. When i tried to clone with 
-rREVNO:HEAD leaving out the inital www-data revision, i got errors for 
other users as well. Turned out to be a malformatted authors file...

Am Montag, 24. Juni 2019 13:47:26 UTC+2 schrieb HTW:
>
> Hi,
>
> im trying to migrate from svn to git. The initial commit (Revision 1) of 
> my svn repository has set 'www-data' as the author. Of course i have added 
> this author to my authors file as well as all other authors, but 'git svn 
> clone' (as well as svn2git) fails with 'Author: www-data not defined in 
> authors.txt file'
>
> Any idea?
>

-- 
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/8adb6381-3267-49d4-817b-dee7212e37d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Messaggio privato relativo a: [git-users] Re: git rebase obscure and vague options

[Philip Oakley]

Hi

On 19/04/2019 16:51, neverasimov wrote:
Hi Philip, your no problem is for ... your incoming concrete example 
for --merge rebase command line usage? Thank you in advance, I wait 
patiently ... :-)


the phrase "No Problem" was a (British) short answer to your comment 
that you had not managed to create a command line example and had run 
out of time/ideas/ and were 'giving up' at the moment. It is a way of 
acknowledging that you have tried and there is nothing to blame. In a 
sense, it is a "thank you" for giving feedback and keeping the list 
informed.


If I get any spare time I may look at what the --merge does (or doesn't) 
do in the rebase context but... Hopefully someone else may do the open 
source thing and make a suggestion ;-)


Il ven 19 apr 2019, 17:48 Philip Oakley > ha scritto:



On 09/04/2019 16:07, neverasi...@gmail.com
 wrote:
> I can be satisfied, now I'm able to use in fluency a lot of GiT
features,
That's good

> but till I'll not be able to build a concrete example to see and to
> touch with hands the difference between --merge presence and
--merge
> absence...
No problem

> ... I'll never understand.
I do know the feeling...

Philip



--
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.
For more options, visit https://groups.google.com/d/optout.