[git-users] Re: What is the structure of Git tree, commit, and tag objects that get hashed to produce an object ID?

[Philip Oakley]

Hi, 

A good place to look at the structure of the Git objects is 
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

The codebase itself can get rather deep. A good place to look at changes is 
the mailing list https://lore.kernel.org/git/ and search for the various 
terms you are interested in and then looking at where the patches are 
applied (filenames, and function names). Emails to the mailing list MUST be 
in plain text - any html is treated a spam email ;-)

On Tuesday, November 14, 2023 at 6:10:01 PM UTC alilley...@gmail.com wrote:

> Hi everyone,
>
> I'm part of the OmniBOR project, which is trying to build a mechanism to 
> track fine-grained dependencies used to produce software artifacts you 
> distribute to others. Under the hood, this is done by producing Git object 
> ID's to identify each artifact, and then using those to produce manifests 
> which record inputs for builds.
>
> As part of this, I maintain the `gitoid` crate (package) for the Rust 
> ecosystem. Currently, this crate only really supports blob objects, because 
> that's all OmniBOR actually needs. But I'd like it to support all Git 
> object types.
>
> To do this, I'll need to implement handling for producing GitOIDs for 
> trees, commits, and tags. I've done some spelunking in the Git codebase, 
> but haven't yet figured out for myself the structure of the buffer contents 
> used to produce GitOIDs for those object types.
>
> Any clarification of what the contents of those buffers look like would be 
> very helpful!
>

-- 
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/c46c842b-551e-4936-b489-36e8de3d39c7n%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.

[git-users] Re: clean/smudge filter with age

[Philip Oakley]

And, make sure that your settings are committed first. I think your 
.gitattributes file should be committed first, so that the git add of the 
secrets is actioned.

On Friday, June 9, 2023 at 9:52:44 PM UTC+1 Philip Oakley wrote:

> Not sure if I understood what you are saying. My impression is that you 
> have an existing repo, cloned from a server (with clone on a server;-), and 
> you now want to have the in-repository file blobs be stored in an encrypted 
> manner. 
> It sounds as if you have two problems.
> 1. your starting point is with the coin upside down. You want your 
> existing repos (local and server) to actually contain encrypted data, and 
> then on checkout they will be filters to be un-encrypted (plain text). - 
> this would explain the sudden appearance of the diff at the point where you 
> start storing encrypted blobs.
> 2. the smudge/clean filters, at least to me, are described in the manuals 
> in the opposite manner than expected. you may have the same problem, and it 
> may be the cause of the 'wrong way around' perceived diffs (assuming 1. 
> wasn't the problem).
>
> I didn't have time to actually check stuff, but those are the issues I 
> would consider clarifying.
> --
> Philip 
>
> On Friday, June 9, 2023 at 3:49:18 PM UTC+1 mag...@therning.org wrote:
>
>> I'm trying out age[1] as a filter for encrypting files in a git 
>> repo but I must be missing something because every new clone 
>> thinks the encrypted file has changed, and if I commit that change 
>> then every other clone sees a diff after pulling in the change. 
>>
>> The main reason I want to try out age is that it can make use of 
>> SSH keys for encryption, which makes it a bit nicer than something 
>> like git-crypt. 
>>
>> I'm setting it up like this: 
>>
>> - 
>> ❯ cat .gitattributes 
>> *.secret filter=age 
>>
>> ❯ git config -l --local|grep filter.age 
>> filter.age.smudge=age --decrypt -i ~/.ssh/id_ed25519 - 
>> filter.age.clean=age --encrypt -R ~/.ssh/id_ed25519.pub - 
>> - 
>>
>> Here's a sequence setting up a first repo: 
>>
>> - 
>> ❯ git init 
>> Initialized empty Git repository in /home/user/tmp/age-0/.git/ 
>>
>> ❯ echo '*.secret filter=age' > .gitattributes 
>>
>> ❯ git config --local --add filter.age.smudge "age --decrypt -i 
>> ~/.ssh/id_ed25519 -" 
>>
>> ❯ git config --local --add filter.age.clean "age --encrypt -R 
>> ~/.ssh/id_ed25519.pub -" 
>>
>> ❯ echo "a secret" > foo.secret 
>>
>> ❯ echo "not a secret" > bar.txt 
>>
>> ❯ git add .gitattributes bar.txt foo.secret 
>>
>> ❯ git commit -m 'The first commit' 
>> [main (root-commit) ae75577] The first commit 
>> 3 files changed, 2 insertions(+) 
>> create mode 100644 .gitattributes 
>> create mode 100644 bar.txt 
>> create mode 100644 foo.secret 
>> - 
>>
>> Now I can make a clone: 
>>
>> - 
>> ❯ cd .. 
>>
>> ❯ git clone age-0 age-1 
>> Cloning into 'age-1'... 
>> done. 
>>
>> ❯ cd age-1 
>>
>> ❯ git ls-files 
>> .gitattributes 
>> bar.txt 
>> foo.secret 
>>
>> ❯ cat foo.secret 
>> age-encryption.org/v1 
>> -> ssh-ed25519 ozAWLA ReSnu8CTgPgnuKUMvG8PWTcc7Lr5IHkKaWc6k4Hfsms 
>> dHsdERPHdsdOQluzyeeRamfjIrmsc2pQ+lhwLlt/0no 
>> --- aHijNp3L2/0MeE/EXWwVhVwyv1uBYW1Ake055jico5M 
>> WF}`YqBO7Ԏwߨ% 
>> - 
>>
>> So far so good. The file is encrypted. Now I configure the filter 
>> the same way and make sure the file is decrypted: 
>>
>> - 
>> ❯ git config --local --add filter.age.smudge "age --decrypt -i 
>> ~/.ssh/id_ed25519 -" 
>>
>> age-1 on  main 
>> ❯ git config --local --add filter.age.clean "age --encrypt -R 
>> ~/.ssh/id_ed25519.pub -" 
>>
>> ❯ rm foo.secret 
>>
>> ❯ git reset --hard HEAD 
>> HEAD is now at ae75577 The first commit 
>>
>> ❯ cat foo.secret 
>> a secret 
>> - 
>>
>> Now comes the problem, git thinks the file with secrets has been 
>> changed when it really hasn't: 
>>
>> - 

[git-users] Re: clean/smudge filter with age

[Philip Oakley]

Not sure if I understood what you are saying. My impression is that you 
have an existing repo, cloned from a server (with clone on a server;-), and 
you now want to have the in-repository file blobs be stored in an encrypted 
manner. 
It sounds as if you have two problems.
1. your starting point is with the coin upside down. You want your existing 
repos (local and server) to actually contain encrypted data, and then on 
checkout they will be filters to be un-encrypted (plain text). - this would 
explain the sudden appearance of the diff at the point where you start 
storing encrypted blobs.
2. the smudge/clean filters, at least to me, are described in the manuals 
in the opposite manner than expected. you may have the same problem, and it 
may be the cause of the 'wrong way around' perceived diffs (assuming 1. 
wasn't the problem).

I didn't have time to actually check stuff, but those are the issues I 
would consider clarifying.
--
Philip 

On Friday, June 9, 2023 at 3:49:18 PM UTC+1 mag...@therning.org wrote:

> I'm trying out age[1] as a filter for encrypting files in a git 
> repo but I must be missing something because every new clone 
> thinks the encrypted file has changed, and if I commit that change 
> then every other clone sees a diff after pulling in the change.
>
> The main reason I want to try out age is that it can make use of 
> SSH keys for encryption, which makes it a bit nicer than something 
> like git-crypt.
>
> I'm setting it up like this:
>
> -
> ❯ cat .gitattributes
> *.secret filter=age
>
> ❯ git config -l --local|grep filter.age
> filter.age.smudge=age --decrypt -i ~/.ssh/id_ed25519 -
> filter.age.clean=age --encrypt -R ~/.ssh/id_ed25519.pub -
> -
>
> Here's a sequence setting up a first repo:
>
> -
> ❯ git init
> Initialized empty Git repository in /home/user/tmp/age-0/.git/
>
> ❯ echo '*.secret filter=age' > .gitattributes
>
> ❯ git config --local --add filter.age.smudge "age --decrypt -i 
> ~/.ssh/id_ed25519 -"
>
> ❯ git config --local --add filter.age.clean "age --encrypt -R 
> ~/.ssh/id_ed25519.pub -"
>
> ❯ echo "a secret" > foo.secret
>
> ❯ echo "not a secret" > bar.txt
>
> ❯ git add .gitattributes bar.txt foo.secret
>
> ❯ git commit -m 'The first commit'
> [main (root-commit) ae75577] The first commit
> 3 files changed, 2 insertions(+)
> create mode 100644 .gitattributes
> create mode 100644 bar.txt
> create mode 100644 foo.secret
> -
>
> Now I can make a clone:
>
> -
> ❯ cd ..
>
> ❯ git clone age-0 age-1
> Cloning into 'age-1'...
> done.
>
> ❯ cd age-1
>
> ❯ git ls-files
> .gitattributes
> bar.txt
> foo.secret
>
> ❯ cat foo.secret
> age-encryption.org/v1
> -> ssh-ed25519 ozAWLA ReSnu8CTgPgnuKUMvG8PWTcc7Lr5IHkKaWc6k4Hfsms
> dHsdERPHdsdOQluzyeeRamfjIrmsc2pQ+lhwLlt/0no
> --- aHijNp3L2/0MeE/EXWwVhVwyv1uBYW1Ake055jico5M
> WF}`YqBO7Ԏwߨ%
> -
>
> So far so good. The file is encrypted. Now I configure the filter 
> the same way and make sure the file is decrypted:
>
> -
> ❯ git config --local --add filter.age.smudge "age --decrypt -i 
> ~/.ssh/id_ed25519 -"
>
> age-1 on  main
> ❯ git config --local --add filter.age.clean "age --encrypt -R 
> ~/.ssh/id_ed25519.pub -"
>
> ❯ rm foo.secret
>
> ❯ git reset --hard HEAD
> HEAD is now at ae75577 The first commit
>
> ❯ cat foo.secret
> a secret
> -
>
> Now comes the problem, git thinks the file with secrets has been 
> changed when it really hasn't:
>
> -
> ❯ git status
> On branch main
> Your branch is up to date with 'origin/main'.
>
> Changes not staged for commit:
> (use "git add ..." to update what will be committed)
> (use "git restore ..." to discard changes in working 
> directory)
> modified: foo.secret
>
> no changes added to commit (use "git add" and/or "git commit -a")
>
> ❯ git diff
> diff --git a/foo.secret b/foo.secret
> index 2de33ca..18e4331 100644
> Binary files a/foo.secret and b/foo.secret differ
>
> ❯ md5sum foo.secret ../age-0/foo.secret
> 6046316bf834dbdf83a5be74be6fd2ac foo.secret
> 6046316bf834dbdf83a5be74be6fd2ac ../age-0/foo.secret
> -
>
> This isn't what I expected. What's wrong with my setup, what am I 
> missing?
>
> /M
>
> [1]: https://github.com/FiloSottile/age
>
> -- 
> Magnus Therning OpenPGP: 0x927912051716CE39
> email: mag...@therning.org
> @mag...@mastodon.technology http://magnus.therning.org/
>
> "He dropped his voice still lower. In the stillness, a fly would 
> not
> have dared clear its throat."
>

-- 
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 fro

[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: Test message - HTML?

[Philip Oakley]

The "Git Users" (alt "Git for human beings") is a googlegroups hosted 
discussion list and appears to always use HTML. Folks can choose how they 
receive notification emails, even though they are typically prepared in 
HTML editor. I think I have mine set to sending plain text and attachments.

If the problem is specifically about the Windows aspects of 
git-for-windows, then use https://github.com/git-for-windows/git/issues (or 
the Discussions pages)

This Git User discussion is completely independent of the 
g...@vger.kerenel.org Git developer mailing list, which is 100% plain text. 
see http://vger.kernel.org/vger-lists.html for details of *subscribing *to 
that list, though you can just send emails without subscribing 

On Friday, April 28, 2023 at 9:44:53 PM UTC+1 stro...@gmail.com wrote:

>
> I'm sending this using "New conversation" on the Google Groups page for 
> the list.
>
> Does it come up in HTML or plain text?
>
> I don't see a ... for turning off HTML in the compose window.
>
>
>

-- 
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/4dcbcb65-983a-4280-8469-ee3ca9c0fb18n%40googlegroups.com.

[git-users] Re: Slight UX regression in `git range-diff`?

[Philip Oakley]

> What do you think? Should I bring this up on the Git mailing list? Or
have I missed something/misunderstood something? 

It does sound worth including in a mailing list discussion, even it it's 
only adding a short clarifying sentence in the man page or its syntax 
summary (synopsis)

Draft patches also help discussions.
The mailing list does not require a subscription, but does require 'plain' 
text (absolutely no HTML)
On Thursday, March 23, 2023 at 9:08:09 PM UTC kristoffer...@gmail.com wrote:

> I was using `git range-diff`:
>
> $ git range-diff main feature-v2 HEAD
>
> And got an error message:
>
> fatal: need two commit ranges
>
> I intended to give three arguments to the command. I started to wonder
> if I maybe had just typed `main feature-v2` (forgot the third
> argument). No, it was three arguments.
>
> The problem was that I had mistyped one argument; it was `feature-v3`,
> not `feature-v2`.
>
> I thought that this error message was a little misleading or too
> generic. I looked at the history of the file (`builtin/range-diff.c`)
> and saw this commit: b75747829f (range-diff: optionally accept
> pathspecs, 2022-08-26).
>
> Maybe it works better with a `pathspec` marker (`--`)?
>
> $ git range-diff HEAD main feature-v2 --
> fatal: not a revision: 'feature-v2'
>
> usage: git range-diff [] .. 
> ..
>or: git range-diff [] ...
>or: git range-diff []   
>
> Yes it does: `not a revision: 'feature-v2'`.
>
> So I tried to contrast the behavior on the current release with the
> behavior on the release before the aforementioned commit.
>
> $ git checkout v2.40.0
> $ make clean
> $ NO_CURL=true make -j 4
> $ # Misspelled ref `seen` as `seent`
> $ ./bin-wrappers/git range-diff master next seent
> fatal: need two commit ranges
>
> usage: git range-diff [] .. 
> ..
>or: git range-diff [] ...
>or: git range-diff []   
> […]
>
> Expected behavior: tell me that `seent` is not a revision.
>
> Actual behavior: generic error message.
>
> But I get a nice error message if I append `--`:
>
> $ ./bin-wrappers/git range-diff master next seent --
> fatal: not a revision: 'seent'
>
> usage: git range-diff [] .. 
> ..
>or: git range-diff [] ...
>or: git range-diff []   
>
> Contrast the behavior on `v2.37.2`, which is one of the tags before
> rev. b75747829f (range-diff: optionally accept pathspecs,
> 2022-08-26).[1]
>
> $ git checkout v2.37.2
> $ make clean
> $ NO_CURL=true make -j 4
> $ ./bin-wrappers/git range-diff master next seent
> fatal: not a revision: 'seent'
>
> usage: git range-diff [] .. 
> ..
>or: git range-diff [] ...
>or: git range-diff []   
> […]
>
> $ # Tag before rev. b75747829f (range-diff: optionally
> $ # accept pathspecs, 2022-08-26)
> $ git checkout v2.37.2
> $ ./bin-wrappers/git range-diff HEAD master seent
> fatal: ambiguous argument 'HEAD..seent': unknown revision or path not 
> in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
> error: could not parse log for 'HEAD..seent'
>
> [1]: I figured out later that `v2.37.6` looks like the last release
> which does not have this commit
>
> This error message is exactly what I expect to see when I mistype a ref
> (my git(1) conditioning).
>
> But the `v2.40.0` error message with `--` is better: `fatal: not a
> revision: 'seent'`
>
> So what if I give a `--`:
>
> $ ./bin-wrappers/git range-diff master next seent --
> fatal: ambiguous argument 'master..seent': unknown revision or path 
> not in the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git  [...] -- [...]'
> error: could not parse log for 'master..seent'
>
> It’s the same. Oh, right—I guess rev. b75747829f (range-diff: optionally
> accept pathspecs, 2022-08-26) that `range-diff` about `--`.
>
> So in conclusion: IMO `range-diff` has a slight usability regression for
> when you mistype the ref. It would be nice if the error message without
> a pathspec (`--`/`dash_dash`) was as nice as one without it.
>
> ---
>
> What do you think? Should I bring this up on the Git mailing list? Or
> have I missed something/misunderstood something?
>

-- 
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/2b97e5cc-cf20-4eae-a691-dabbbe2869e1n%40googlegroups.com.

[git-users] Re: how is name-rev determined

[Philip Oakley]

Hi Uwe,
(supplemental to Felipe's reply)

Underlying the 'branch name' "problem" is the same conceptual shift that 
Git adopts for the separation of file names from the (blob) content.

By separating the metadata from the item, Git allows itself to pivot from 
being human centric (with all our insecurities..) to the hard logic 
computer centred view that doesn't care about names, so blobs aren't known 
by their file name [e.g. LICENCE, COPYING, EULA, README, etc] but instead 
use the hash of the content which stays fixed across renames and local 
naming choices. This makes the code "simpler" (less UI stuff).

For 'branches', their names likewise become temporary meta-data artefacts 
that the computer (and hence the software logic that has to deal with it) 
does not care about. At best we (Git) allow the distinction between 'first 
parent' and other parents at a merge, but aren't concerned with where a 
branch started, especially if someone else started it, and hasn't merged it 
yet into a line of development we've looked at. (i.e. distributed 
development could bring with it some real collaboration and communication 
issues that we just side stepped - see Conway's Law vlog 
https://www.youtube.com/watch?v=5IUj1EZwpJY for thoughts on that)

Philip
On Saturday, March 4, 2023 at 7:39:04 AM UTC o...@ucm.es wrote:

>
>
> Hi
>
> Since I also use mercurial, one thing I am missing in git, when running
> git log --graph
>
> Is a information, which commit belongs to which branch (an information
> mercurial provides in named branches)
>
> However a solution is to use name-rev 
>
> Like this
>
> git log --graph --color=always --all --since=2years --decorate --pretty | 
> git name-rev --annotate-stdin | less -R
>
>
> And the resulting graph looks, at least for me, close enough to
> mercurial's named branches.
>
> So I am wondering, is this name-rev information somewhere stored, or
> calculated on the fly each time the command is called?
>
> Thanks and regards
>
>
> Uwe Brauer
>
>
> -- 
> Warning: Content may be disturbing to some audiences
> I strongly condemn Putin's war of aggression against the Ukraine.
> I support to deliver weapons to Ukraine's military. 
> I support the ban of Russia from SWIFT.
> I support the EU membership of the Ukraine. 
>
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>

-- 
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/d06abf34-3e76-461c-a523-da2ea067ecd9n%40googlegroups.com.

[git-users] Re: DCSV in 2007: Linus Thorvalds talk

[Philip Oakley]

As I understand it, each of the Linux area maintainers made/provided their 
own [public readable] server so that they could fetch (and merge, = pull) 
from each other (see `git request-pull`) and could also push to some 
reference servers, or each other. 

Being Linux hackers (in the best sense of the word) they obviously had such 
capabilities, compared to those who might work in more managed 'corporate' 
environments. 

That free interchange of development branches is said to be the source of 
the 'Pull' mechanism that has now fallen out of favour with the rise of the 
communal server services and central corporate servers that we now tend to 
use so as to maintain a Trunk or first parent perspective on the 
'linear/flattened' development. 

Collaboration has always required a method of 'publishing' one's work and 
those cloud servers make it so much easier for us lesser mortals to not 
only publish, but to be found as well, along with the ease of 'forking' 
promising projects.

Philip
+1 for an interesting question ;-)

On Friday, February 24, 2023 at 1:51:49 PM UTC o...@ucm.es wrote:

>
>
> Hi
>
> Sorry if this off-topic but I got curious. I stumbled of the talk Linus
> Thorvald gave in 2007 about git
> https://www.youtube.com/watch?v=4XpnKHJAok8
>
> It is fun to watch [1]
>
> And he emphasizing DVCS, but I am wondering, how was this
> supposed to work in 2007. Github/gitlab/bitbucket did not exist, only
> sourceforge if I remember correctly.
>
> Git is only a client software, as far as I know.
>
> Anybody knows how this was done in 2007?
>
> Regards
>
> Uwe Brauer 
>
>
> Footnotes:
> [1] (his accent seems to be quite good, although I am no native
> speaker...). His jokes about CVS and subversion are hilarious, 
> but not about mercurial 😇
>
>
> -- 
> Warning: Content may be disturbing to some audiences
> I strongly condemn Putin's war of aggression against the Ukraine.
> I support to deliver weapons to Ukraine's military. 
> I support the ban of Russia from SWIFT.
> I support the EU membership of the Ukraine. 
>
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>

-- 
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/1159e807-3424-41cb-899b-5f2a4846203an%40googlegroups.com.

Re: [git-users] Fast method to get a range diff that excludes merges

[Philip Oakley]

further example courtesy of Microsoft ... " Git history simplification can 
be a confusing beast. "
 
https://learn.microsoft.com/en-us/azure/devops/repos/git/git-log-history-simplification?view=azure-devops

(ignore those '>' vs '>' html errors in the git code examples ;-) 
On Wednesday, February 22, 2023 at 12:23:50 PM UTC Philip Oakley wrote:

> I haven't tried to follow that example properly yet.. 
>
> However one other thing to look at is the "History Simplification" that 
> includes parent re-writing that's in the rev-list-options.txt file and then 
> included in a number of man pages (log, show, short-log,..).  There are 
> some slippery concepts in there, often context dependent!
>
> https://git-scm.com/docs/git-log#_history_simplification
>
> On Wednesday, February 22, 2023 at 5:00:51 AM UTC s...@codeapprove.com 
> wrote:
>
>> Thank you both for getting back to me. The discussion in the docs about 
>> flattening was really interesting!  I should note that the git clone / git 
>> log command pair I provided gives me almost exactly what I want, but I need 
>> to combine the diffs. It seems to contain the correct changes, and the 
>> speed is pretty good too.
>>
>> Let me give an example of the situation I am optimizing for. I apologize 
>> in advance I am going to use GitHub terms which I know are not pure git, 
>> but in the end my question is a git question. 
>>
>> Say you're a developer working in a many-developer repository. Here's the 
>> sequence:
>>
>>- On Day 0 you check out "main" and create "my-topic-branch". You add 
>>commits A, B, C, D to that branch. 
>>- Now you open a pull request on GitHub asking to merge your branch 
>>"my-topic-branch" into "master". 
>>- You see a collaborator has landed a change to "main" since you 
>>started. So you do "git fetch origin main && git merge main" and make a 
>>merge commit in your branch. 
>>- Then you add three more commits E, F, G on top of that and push 
>>your branch again. So you have: A, B, C, D, (merge main), E, F, G.
>>- A coworker has already looked at commits A, B, C and wants to see 
>>what you've done then. So they ask GitHub to show the diff from commits D 
>>through G (including the merge).
>>
>> When you do this, GitHub does something which (to me, anyway) is pretty 
>> magical. You are shown only the changes that you committed to your branch 
>> in D, E, F, and G. Changes which you merged in, which may or may not 
>> involve the files in your Pull Request, are not shown at all since they're 
>> not "yours".
>>
>> Here's a public example showing a team using this pattern. This one has 
>> multiple merges, so I may need to find a cleaner example but hopefully this 
>> makes sense.
>>
>>- Consider this PR: 
>>https://github.com/firebase/firebase-tools/pull/5478/files
>>   - This is the full diff (according to GitHub) and we can see 
>>   exactly one added line in CHANGELOG.md
>>- Here's a merge commit: 
>>
>> https://github.com/firebase/firebase-tools/pull/5478/commits/ebce28ceb799f721d36b986705c54cbcd597a27a
>>   - We can see that on the base branch, "master", a line was added 
>>   to the *end* of the CHANGELOG.md file. There is no such addition 
>>   displayed in the full diff.
>>- Here's a "magic" diff where I selected three commits (before merge, 
>>merge, and after merge): 
>>
>> https://github.com/firebase/firebase-tools/pull/5478/files/28b8a72561b266a2086059c0d9840ab25f03d8ae..b2d89ebd67e3f8c17c4c607c630c18096303096b
>>   - We can see that the changes from the merge commit are not shown 
>>   as additions! But they are present as context lines.
>>
>> I need to find a sequence of git commands to produce the same exact diff 
>> that GitHub produces (and ideally do it very quickly even in a large 
>> repository) and I just can't figure it out.
>>
>> Thanks,
>> Sam
>>
>>
>>
>>
>> On Tuesday, 21 February 2023 at 14:12:48 UTC-8 philip...@iee.email wrote:
>>
>>> This may also be an issue of the History Simplification process and / or 
>>> the 'flattening' processes for history linearisation and rebases.
>>>
>>> The flattening is a known phenomena and was currently being mentioned on 
>>> the Git List, so I have noted this there. 
>>> [1] https://lor

Re: [git-users] Fast method to get a range diff that excludes merges

[Philip Oakley]

I haven't tried to follow that example properly yet.. 

However one other thing to look at is the "History Simplification" that 
includes parent re-writing that's in the rev-list-options.txt file and then 
included in a number of man pages (log, show, short-log,..).  There are 
some slippery concepts in there, often context dependent!

https://git-scm.com/docs/git-log#_history_simplification

On Wednesday, February 22, 2023 at 5:00:51 AM UTC s...@codeapprove.com 
wrote:

> Thank you both for getting back to me. The discussion in the docs about 
> flattening was really interesting!  I should note that the git clone / git 
> log command pair I provided gives me almost exactly what I want, but I need 
> to combine the diffs. It seems to contain the correct changes, and the 
> speed is pretty good too.
>
> Let me give an example of the situation I am optimizing for. I apologize 
> in advance I am going to use GitHub terms which I know are not pure git, 
> but in the end my question is a git question. 
>
> Say you're a developer working in a many-developer repository. Here's the 
> sequence:
>
>- On Day 0 you check out "main" and create "my-topic-branch". You add 
>commits A, B, C, D to that branch. 
>- Now you open a pull request on GitHub asking to merge your branch 
>"my-topic-branch" into "master". 
>- You see a collaborator has landed a change to "main" since you 
>started. So you do "git fetch origin main && git merge main" and make a 
>merge commit in your branch. 
>- Then you add three more commits E, F, G on top of that and push your 
>branch again. So you have: A, B, C, D, (merge main), E, F, G.
>- A coworker has already looked at commits A, B, C and wants to see 
>what you've done then. So they ask GitHub to show the diff from commits D 
>through G (including the merge).
>
> When you do this, GitHub does something which (to me, anyway) is pretty 
> magical. You are shown only the changes that you committed to your branch 
> in D, E, F, and G. Changes which you merged in, which may or may not 
> involve the files in your Pull Request, are not shown at all since they're 
> not "yours".
>
> Here's a public example showing a team using this pattern. This one has 
> multiple merges, so I may need to find a cleaner example but hopefully this 
> makes sense.
>
>- Consider this PR: 
>https://github.com/firebase/firebase-tools/pull/5478/files
>   - This is the full diff (according to GitHub) and we can see 
>   exactly one added line in CHANGELOG.md
>- Here's a merge commit: 
>
> https://github.com/firebase/firebase-tools/pull/5478/commits/ebce28ceb799f721d36b986705c54cbcd597a27a
>   - We can see that on the base branch, "master", a line was added to 
>   the *end* of the CHANGELOG.md file. There is no such addition 
>   displayed in the full diff.
>- Here's a "magic" diff where I selected three commits (before merge, 
>merge, and after merge): 
>
> https://github.com/firebase/firebase-tools/pull/5478/files/28b8a72561b266a2086059c0d9840ab25f03d8ae..b2d89ebd67e3f8c17c4c607c630c18096303096b
>   - We can see that the changes from the merge commit are not shown 
>   as additions! But they are present as context lines.
>
> I need to find a sequence of git commands to produce the same exact diff 
> that GitHub produces (and ideally do it very quickly even in a large 
> repository) and I just can't figure it out.
>
> Thanks,
> Sam
>
>
>
>
> On Tuesday, 21 February 2023 at 14:12:48 UTC-8 philip...@iee.email wrote:
>
>> This may also be an issue of the History Simplification process and / or 
>> the 'flattening' processes for history linearisation and rebases.
>>
>> The flattening is a known phenomena and was currently being mentioned on 
>> the Git List, so I have noted this there. 
>> [1] https://lore.kernel.org/git/a856dd16-9876-509b...@iee.email/ 
>> 
>>
>> There is a technical discussion of flattening in the docs at 
>> https://github.com/git/git/blob/master/Documentation/howto/keep-canonical-history-correct.txt
>>  
>>
>> Do note the original email title  "Pull is mostly evil" ;-) (whole thread 
>> at https://lore.kernel.org/git/5363bb9...@xiplink.com/ 
>> )
>>
>> Clarifying the " excluding merge commit changes" (or misunderstandings if 
>> you've there were some..) would be really useful. The existing devs do have 
>> the 'curse of knowledge' so often can't see the problems.
>> On Tuesday, February 21, 2023 at 5:29:36 PM UTC Konstantin Khomoutov 
>> wrote:
>>
>>> On Mon, Feb 20, 2023 at 09:27:20PM -0800, 'Samuel Stern' via Git for 
>>> human beings wrote: 
>>>
>>> > This is an *extremely* specific question which I've been trying to get 
>>> an 
>>> > answer to for quite a while now, so hopefully someone here knows the 
>>> answer. 
>>> > 
>>> > Let's say I am starting f

Re: [git-users] Fast method to get a range diff that excludes merges

[Philip Oakley]

This may also be an issue of the History Simplification process and / or 
the 'flattening' processes for history linearisation and rebases.

The flattening is a known phenomena and was currently being mentioned on 
the Git List, so I have noted this there. 
[1] 
https://lore.kernel.org/git/a856dd16-9876-509b-6a99-11ea0020633c@iee.email/

There is a technical discussion of flattening in the docs at 
https://github.com/git/git/blob/master/Documentation/howto/keep-canonical-history-correct.txt
 


Do note the original email title  "Pull is mostly evil" ;-) (whole thread 
at https://lore.kernel.org/git/5363bb9f.40...@xiplink.com/)

Clarifying the " excluding merge commit changes" (or misunderstandings if 
you've there were some..) would be really useful. The existing devs do have 
the 'curse of knowledge' so often can't see the problems.
On Tuesday, February 21, 2023 at 5:29:36 PM UTC Konstantin Khomoutov wrote:

> On Mon, Feb 20, 2023 at 09:27:20PM -0800, 'Samuel Stern' via Git for human 
> beings wrote:
>
> > This is an *extremely* specific question which I've been trying to get 
> an 
> > answer to for quite a while now, so hopefully someone here knows the 
> answer.
> > 
> > Let's say I am starting from nothing, an empty directory on a server. I 
> > have:
> > 
> > - The URL for a public git repository
> > - Two endpoint SHAs (commits on the same branch)
> > 
> > I want to get the complete diff between those commits *excluding* merge 
> > commit changes, and I want to do this as fast as possible (so much 
> faster 
> > than cloning everything and diffing).
> > 
> > I am able to get almost there with the following sequence:
> > 
> > # Fast clone
> > git clone --verbose --no-checkout --filter=blob:limit=250k 
> --single-branch 
> > --branch=${branch} --depth=${depth} $REPO_URL
> > 
> > # Get a series of patches
> > git log --no-merges --first-parent --patch ${base.sha}..${head.sha}
> > 
> > However I need to get a *single* patch that represents all the changes 
> > combined, not a series of patches from the log.
>
> Isn't mere
>
> git diff ${head.sha} ${base.sha}
>
> is what you're looking for?
>
> Otherwise, I'm with Philipp in that your statements (rephrased)
>
> - I want to get a single combined change ("patch") describing the literal
> set of changes between such and such commits.
>
> - I want changes brought in by merge commits excluded.
>
> Contradict each other: I could in principle envision some algorithm which
> would try to incrementally produce a diff as in walks a chain of commits 
> and
> tries to ignore the changes introduced by merge commits located in that 
> chain,
> but leaving aside the fact such an algotithm would be very brittle for any
> real-world cases, I simply see no use for it - even a theoretical one.
>
>
> You might got trapped by the fact you have found `git log` first in your
> search, and this command traverses all individual commits in the subgraph 
> it's
> told to traverse - including "sidelines" brought in by merge commits.
> Instead, plain old `git diff` does not traverse anything: it takes two 
> states
> of the project and compares them.
>
>

-- 
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/faffc666-5ec7-499a-8aad-4310c286769fn%40googlegroups.com.

[git-users] Re: Fast method to get a range diff that excludes merges

[Philip Oakley]

> diff between those commits *excluding* merge commit changes, 

What does this mean?

If we have commit sequence

```
A-B-C-M-D-E-F
 /
S-T-U
```
and want you complete diff between A..F, but somehow excluding merge M (and 
hence S-T-U),
what does that mean. 
Was the merge clean, or were there conflict fixups?
Do you mean A..C plus D..F

Do you have an example of the perceived Github way of doing things?

P.

On Tuesday, February 21, 2023 at 5:27:20 AM UTC s...@codeapprove.com wrote:

> Hello all,
>
> This is an *extremely* specific question which I've been trying to get an 
> answer to for quite a while now, so hopefully someone here knows the answer.
>
> Let's say I am starting from nothing, an empty directory on a server. I 
> have:
>
>- The URL for a public git repository
>- Two endpoint SHAs (commits on the same branch)
>
> I want to get the complete diff between those commits *excluding* merge 
> commit changes, and I want to do this as fast as possible (so much faster 
> than cloning everything and diffing).
>
> I am able to get almost there with the following sequence:
>
> # Fast clone
> git clone --verbose --no-checkout --filter=blob:limit=250k --single-branch 
> --branch=${branch} --depth=${depth} $REPO_URL
>
> # Get a series of patches
> git log --no-merges --first-parent --patch ${base.sha}..${head.sha}
>
> However I need to get a *single* patch that represents all the changes 
> combined, not a series of patches from the log. In theory I could combine 
> the series of patches I get but I have found that task exceedingly 
> difficult (suggestions welcome!)
>
> This might sound like a wacky task, but it's actually quite commonly done. 
> If you are using GitHub to view the changes in a pull request and select a 
> range of commits which includes a merge, GitHub does this exact operation 
> on the backend. I just can't figure out how.
>
> Any pointers welcome!
>
> - Sam
>
>
>
>

-- 
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/1170d470-a027-497b-ae46-ff5bd325e497n%40googlegroups.com.

Re: [git-users] slightly off topic: Windows11+git+https access (matlab) where are the credentials stored

[Philip Oakley]

Uwe,

Do the individual students have any form of personal 'HOME' storage for 
saving their local project work?

How is that organised? I guess emails are all done via a web browser and 
'cloud' storage, so that would provide no guidance. Likewise much of their 
student rotas would be accessed via a browser, again no guidance. 

Do they have any 'Dropbox' style service for their work storage? Does it, 
if available, end up in a personalised file/dir path 
(c:/Student/UB123456/*), or is it a 'signed in' standard path (e.g. 
C:/HOME/*). These could lead to having the student's global config on their 
HOME drive, secure from others.

My only other thought is to have a 'throw-away' ssh style connection that 
has additional password protection. I do this for my Github account, so 
when I push to 'my' remote, I am always asked for my personal pass-phrase 
for that ssh. It was a bit of hassle to set up at the time (quite a few 
steps) but since then it's been pretty simple and reliable. It means all my 
pushes have extra passphrase protection even if one is a bit lax about the 
ssh public/private file pair. (do emphasise that folks should use a long 
phrase rather than a short password!)

Philip

On Thursday, February 9, 2023 at 1:09:52 PM UTC o...@ucm.es wrote:

> >>> "KK" == Konstantin Khomoutov  writes:
>
> > On Wed, Feb 08, 2023 at 10:34:46PM +0100, Uwe Brauer wrote:
> > [...]
> >> It seems to me that the credential helper system might be helpful for a
> >> single user szenario.
> >> 
> >> But PC running Windows and only have one user for all students will
> >> inevitably run into problems. So that looks a bit over engineered to me.
> > [...]
>
> > Do I understand correctly that the PCs in your department all have a 
> single
> > user account shared by different people - so that's what you call "single
> > user"? [*]
>
> Right! That is what I meant, only one account for well hundreds of 
> students.
>
>
> > If yes, well, I would say that this is the least correct way to run 
> shared
> > PCs this day and age, but anyway since it's not you who decides on this
> > stuff, then yes, any credential caching (and I mean it: not only that of 
> Git)
> > will actively work against the grit here: all such systems imply any
> > particular account belongs to a physically distinct person and hence any
> > session created for that account can share certain stuff related to that
> > person.
>
> > If you really use single login for different folks, you has to turn any
> > credential caching off. If possible, this should be talked about with 
> whoever
> > administers these PCs so they maybe have such settings made in a 
> centralized
> > manner - for instance, they could use Windows domain policies to 
> pre-tweak
> > system-wide Git configuration to turn the GCM off.
>
>
> Well, welcome to Spain my friend. 
>
> Even when I started to mention the problems (before knowing the
> solution) concerning the credentials he looked at me as if I were an
> alien. There is only one decent system administer in this department and
> as I must add maybe in the whole university, but his job is to maintain
> Linux and Mac. But then the students want to use windows. Anyhow, sad
> topic.
>
>
>
>
> > [*] I mean, when I hear "single user" I think of a system with 0 or 1 
> active
> > login sessions at any given time - like a typical PC running Windows of
> > its "desktop" flavor. This concept does not mean multiple users share the
> > same account/credentials - merely just it's impossble to have more than a
> > single user logged in and active at any given time. To illustrate, on
> > desktop Windows, logging in remotely over the so-called Remote Desktop
> > Protocol (RDP) locks the currenly active "console" session - that one
> > where a user works at the physical I/O devices attached to the machine,
> > such as the monitor, keyboard and a pointing device (collectively called
> > "a seat" these days), - and unlocking the console session back would
> > disconnect the RDP session, enforcing that "single user" policy.
>
> -- 
> Warning: Content may be disturbing to some audiences
> I strongly condemn Putin's war of aggression against the Ukraine.
> I support to deliver weapons to Ukraine's military. 
> I support the ban of Russia from SWIFT.
> I support the EU membership of the Ukraine. 
>
> https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/
>

-- 
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/c54060bc-e1e4-4ea1-9d2a-f0134a074b67n%40googlegroups.com.

[git-users] Re: fast-import: cannot use previous commit hash in "from"

[Philip Oakley]

A quick comment. While I don't use fast-export, fast-import, I have seen 
comments on the git list https://lore.kernel.org/git/ that suggest some 
times the code is either running separate threads in parallel, or is don't 
some computations out of sequence, that can mean that some hashes aren't 
available at the time that you might expect leading to these sorts of 
faults. It's a bit speculative, but it may suggest things to look at in 
your investigations.

Lets hope others who are better informed are able to comment 
On Sunday, January 1, 2023 at 7:51:13 PM UTC Eduardo wrote:

> Hi!
>
> Using fast-import, I tried to:
> 1. Create a commit
> 2. Get its hash (using get mark)
> 3. Create another commit
> 4. Pass the hash of the previous commit to 'from', to use it as parent
>
> I've got this instead:
>
> fatal: Not a valid commit: 846f127ede7fe8d0068e5d89419d050d88396ade
>
> Most Recent Commands Before Crash
> -
>   commit refs/heads/master
>   mark :1
>   committer no-author  0 +
>   data 0
>   
>   get-mark :1
>   commit refs/heads/master
>   committer no-author  0 +
>   data 0
> * from 846f127ede7fe8d0068e5d89419d050d88396ade
>
> Active Branch LRU
> -
> active_branches = 1 cur, 5 max
>
>   pos  clock name
>   ~
>1)  1 refs/heads/master
>
> Inactive Branches
> -
> refs/heads/master:
>   status  : active loaded
>   tip commit  : 846f127ede7fe8d0068e5d89419d050d88396ade
>   old tree: 4b825dc642cb6eb9a060e54bf8d69288fbee4904
>   cur tree: 4b825dc642cb6eb9a060e54bf8d69288fbee4904
>   commit clock: 1
>   last pack   : 0
>
>
> Marks
> -
> :1 846f127ede7fe8d0068e5d89419d050d88396ade
>
> ---
> END OF CRASH REPORT
>
> How is "846f127ede7fe8d0068e5d89419d050d88396ade" not a valid commit when 
> it is showing that it is the tip commit of a branch? Is this a bug?
>
> git version 2.37.2
>
> The exact commands are (yellow is stdout):
>
> commit refs/heads/master
> mark :1
> committer no-author  0 +
> data 0
>
>
> get-mark :1
> 846f127ede7fe8d0068e5d89419d050d88396ade
> commit refs/heads/master
> committer no-author  0 +
> data 0
>
> from 846f127ede7fe8d0068e5d89419d050d88396ade
>
>
> Thanks 
>
>

-- 
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/f2de8b18-ff82-4a15-a6fb-cb2e5dba29can%40googlegroups.com.

Re: [git-users] off topic, git host without ssh for pushing

[Philip Oakley]

A better formatted link https://git-scm.com/docs/SubmittingPatches

On 11/12/2022 11:40, Philip Oakley wrote:
> It's worth having a look at Git's
> 'SubmittingPatches' [2] doc for some of the "Cheats" that the Git team
> use to look good ;-)
> [2] https://github.com/git/git/blob/master/Documentation/SubmittingPatches

-- 
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/cde69f0e-e4c7-2565-56cb-91b3262dda28%40iee.email.

Re: [git-users] off topic, git host without ssh for pushing

[Philip Oakley]

On 10/12/2022 22:00, Uwe Brauer wrote:
>> The great thing was I
>> could save (to Git) snippets (hunks) of my code out of sequence and have
>> instant replay of those bits of quick trial code that would recreate
>> figures and tables that became useful in retrospect. Sort of a 'commit a
>> minute' speed.
> Never heard of this
>
>
That is a literal, 'I would make a simple commit about once every one or
two minutes' while doing some Matlab coding development while
investigating some broader problem or issue that I was modelling.

So every time I updated a graph / chart / figure I'd do a quick commit
so if it turned out that the graph, three revisions ago, was useful (in
retrospect) I could leap back to it. Theses problems are especially
common in engineering trade-offs where resources are limited, so lots of
resource trade off curves are developed, most of which end up useless,
but one or two, if you can remember where they are, are very useful
(hence "commit early, commit often" to misquote..)

Example,
a local/personal issue at the moment is: when does condensation happen
on the windows because we've turned the heating down, and the outside
temperature has dropped, and we aren't sure if relative humidity,
absolute humidity, perceived humidity are the best way of representing
the curves that show just when and where the condensation will happen,
or where it came from. Lots of opinions on the inter-web, but lacking in
clear modelling.  A fun project, but no idea which way [which simple
graph] is best for explaining to spouse why (a bit more exactly) dark
cold corners are now getting damp and mouldy. It's a 'no right answer'
problem [1], so record lots of potential answers and steps toward them..

If the student is in a 'hack and hope' mode, then they will get very
confused if [when] they don't have a bread crumb trail to get back to
some point of halfway success to branch off in a different direction,
cherry picking little bits that are useful from the trail of failures.. 

Git's ability to "commit early, commit often" is the saviour here. It's
fast, requires no permissions, minimal storage, doesn't need to be shown
to anyone. Git let's you tidy up the working and make it look pristine
before submission. What's not to like. It's worth having a look at Git's
'SubmittingPatches' [2] doc for some of the "Cheats" that the Git team
use to look good ;-)

Aside:  for appealing to students better nature for using "version
recovery" see [3] !

Philip

[1] https://en.wikipedia.org/wiki/Wicked_problem
[2] https://github.com/git/git/blob/master/Documentation/SubmittingPatches
[3] https://www.interviewbit.com/git-interview-questions

-- 
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/7ecb97c8-5f0a-43c0-6162-914a177adecd%40iee.email.

Re: [git-users] off topic, git host without ssh for pushing

[Philip Oakley]

On 09/12/2022 18:50, Uwe Brauer wrote:
>> The `.git` folder for the users local repo is stored with the project
>> directory anyway, so the restrictions on project access should be the same.
> Well that will be another problem. 
>
> The chances that the students will use the command line is close to
> zero, so I asked the system administrators to install sourcetree a
> hg/git gui. That might allow something of what you propose but I think I
> feel a bit uncomfortable
>
So where is the project folder that contains the student's '*.m' files?
For that 'folder' is where Git Gui, or SourceTree or Git Extensions will
store/access the local repository (i.e. `.git` folder)

When I was doing my Matlab work developing electro-optic products I was
just using the Git Gui and (IIRC) Tortoise Git. The great thing was I
could save (to Git) snippets (hunks) of my code out of sequence and have
instant replay of those bits of quick trial code that would recreate
figures and tables that became useful in retrospect. Sort of a 'commit a
minute' speed.

Git isn't designed to work with these cloud storage apps such as the
good old DropBox, or GoogleDocs because they argue about their mental
(algorithm) model of 'synchronisation' One is file level, the other is
directory level.

Philip
PS. Students have always been 'dumb' - I was one once ;-)

-- 
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/6671f0cc-a6e0-42e4-8182-d71cb589e642%40iee.email.

Re: [git-users] off topic, git host without ssh for pushing

[Philip Oakley]

Hi Uwe,

On 09/12/2022 15:53, Uwe Brauer wrote:
> Next semester I want to run an
> experiment and encourage my students to use a VC for their coding, and
> since Matlab supports git (and svn) it will be git.
>
> However I encounter a problem: so far I have tested github and bitbucket
> and both don't allow to push via https and a simple password anymore.
>
> My ssh knowledge is a bit rusty, but in order to have ssh, one needs to
> generate a key pair, and to put the public key in github/bitbucket
> (https://gist.github.com/xirixiz/b6b0c6f4917ce17a90e00f9b60566278)
>
> That alone might be difficult for some students, the real problem is:
> one needs to have the private key installed in the machine from which
> one is pushing.
>
> Now the students will work in the University on public Desktops, so to
> have private keys there is a no-go.

A clarification here.

Do the students have, or are allowed, USB access to the desktops? Or are
the desktops locked down?

Do students have local storage space that is password (user) protected
on the university system, or is it just a password for access control
(to the tools)?

Are FIDO tokens a possibility via the USB ports? (I've not used them..)

>
> Any suggestion how to deal with this requirements?

Workarounds usually need some gap in the system that gives an access
port to the trust the student/user has already been given, hence the
query about the limits of the existing trust relationships.

A secondary thought is that if it's just push/fetch/pull (and ls-remote)
that's needed, then can't they add a password to that specific host ssh.
I certainly have a password set for all my GitHub pushes, though as I've
a public open repos the fetch doesn't need me to provide the ssh password.

The `.git` folder for the users local repo is stored with the project
directory anyway, so the restrictions on project access should be the same.

I used the fact that .git was hidden to start using version storage
[remember there is no control in DVCS - the control has already been
distributed to the user, not the 'manager' ;-) ] on Matlab when I was
working - my branch didn't show up for the other users as the common
storage was still on 'main' and the '.git' was hidden ;-)

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/b0320073-e394-76e9-87b3-7ba6dbbbc7e8%40iee.email.

Re: [git-users] Re: The git projects disappeared after the updated

[Philip Oakley]

(for the discussion)

On 04/12/2022 12:00, Konstantin Khomoutov wrote:
> Git never supported keeping its repositores on non-local filesystems such as
> OneDrive (or whatever other "cloud" drive or networked filesystems such as NFS
> or CIFS/Samba). It does have some hacks and kludges to facilitate working on
> _some_ of them, but it's never guaranteed. This is not some whimsical decision
> of the Git's creators

I thought I'd just note that Git's creator, Linus Torvalds, did know
something about filesystems, particularly Linux, for which this DVCS was
designed, and knew of the filesystem limitations. :Smiley-face:

A key part of the 'distributed' nature of Git DVCS, is the swapping of
'control' to the local filesystem (for complete projects!), and instead
uses sha1 hash validation to check if copies (and sub-copies) were
correct. The validation design technique looks to the complete project,
rather than individual files and directories.

The net effect is that the file/folder designs of the likes of cloud
storage methods of Google Drive, One Drive, DropBox, rsysnc, can all
lose data when they 'compete' with Git's local authority viewpoint of
the complete project. Losing .git loses all the local source control
information.

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/970cdd5d-e020-bc1f-77f5-c63f60cb5f10%40iee.email.

Re: [git-users] Re: The git projects disappeared after the updated

[Philip Oakley]

On 04/12/2022 13:34, rozanski.s...@gmail.com wrote:
> Of course, snapshotting done by cloud synching software is absolutely broken 
> when it comes to version control systems such as Git because such pieces of 
> synching software are blissfully unaware about the "snapshot semantics" such 
> VC systems use - which means a set of many different operations on assorted 
> files in a repository must be considered as a single change.

The problems that happen with rsync and dropbox (et.al.) have been
discussed on the main Git mailing list [1], but I don't think it got to
be included in the git FAQ man page [2].

Philip

[1] https://lore.kernel.org/git/?q=dropbox
[2] https://git-scm.com/docs/gitfaq

-- 
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/1c91fb20-dc16-3c68-9811-abd83d7e8a7a%40iee.email.

[git-users] Re: mentorship for Gsoc & Open Source Contribution

[Philip Oakley]

Hi Vishal, 

The GSOC is managed through the Git developers List (at g...@vger.kernel.org) 
. The developer page at https://git.github.io/ has links for mentoring, the 
SoC, hacking on git, and other news (etc.). 

To join the Git List see http://vger.kernel.org/vger-lists.html#git  *REMEMBER: 
Subscription to the lists go via  ! *

The list archive is at https://lore.kernel.org/git/ where lots of GSOC 
contributions (patches) use the [GSOC] prefix in the patch subject lines, 
or a simple https://lore.kernel.org/git/?q=gsoc 

Contributions are also welcome for the Git-for-Windows friendly fork which 
is built (and rebuilt) on top of the current Git and provides a wider view 
of 'compatibility' ;-)

Philip
On Saturday, December 3, 2022 at 2:27:33 AM UTC vishalty...@gmail.com wrote:

> Good day, everyone.
> I'm Vishal, a college student, and I've always been fascinated by 
> technology and the concept of open source. I'd like to start contributing 
> to the development of git itself, which serves as the foundation for 
> millions of projects. I'd like to get started and participate in Gsoc with 
> the help of a mentor.
>

-- 
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/f8fad567-cda1-4a08-b4b3-86be67f11fc5n%40googlegroups.com.

Re: [git-users] Re: The git projects disappeared after the updated

[Philip Oakley]

> when I was using Git on Windows, the ".git" directories really have 
the "hidden" attribute set on them, so they were invisible in Windows 
Explorer 
by default. 

That is true. 
The ".git" sub-directory is marked as hidden in its properties, and is 
normally hidden by Explorer. I always select the show hidden and show 
extensions options in Explorer..

You can set those on the 'View' tab, and ticking the check boxes in the 
right hand "Show/hide" group. I also have (somehow) the hidden folders 
displayed in a slightly softer colour tone.


On Friday, December 2, 2022 at 2:46:43 PM UTC Konstantin Khomoutov wrote:

> On Fri, Dec 02, 2022 at 05:36:28AM -0800, Philip Oakley wrote:
>
> >> do they print sensible information? 
> [...]
> > Also, if you look in the project top level directory, does it contain 
> the 
> > 'hidden' (sub-)directory named ".git", and are to able to determine the 
> > ownership of that directory. I ask as there have been some security 
> updates 
> > that check that you have ownership of your repository.
>
> Back then when I was using Git on Windows, the ".git" directories really 
> have
> the "hidden" attribute set on them, so they were invisible in Windows 
> Explorer
> by default.
>
> Has that changed, or does memory serves me wrong?
>
>

-- 
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/de34d1d7-1ecf-4446-ad62-fb204cecb5f7n%40googlegroups.com.

Re: [git-users] Re: The git projects disappeared after the updated

[Philip Oakley]

>  do they print sensible information? 

@rozans:
Extra clarification:  could you also copy and paste the exact output into 
any responses, as often there are extra clues in having the exact words and 
character stings from the error reports (and successes!).

Also, if you look in the project top level directory, does it contain the 
'hidden' (sub-)directory named ".git", and are to able to determine the 
ownership of that directory. I ask as there have been some security updates 
that check that you have ownership of your repository.

On Friday, December 2, 2022 at 11:40:46 AM UTC Konstantin Khomoutov wrote:

> On Fri, Dec 02, 2022 at 02:42:27PM +0400, Konstantin Khomoutov wrote:
>
> [...]
> > Can you verify Git "barely works"?
> [...]
>
> To make my intent clear: in your original message you've referred to 
> 3rd-party
> software like PHPStorm which can use Git in weird and unexpected ways, so 
> we
> should try to dissect the problem to actually make sure which part broke: 
> the
> installation of Git, Git itself, or something in Git has changed in a way
> certain external software now fails to properly interoperate with it.
>
> So, let's start with figuring out whether Git itself is installed and 
> working.
>
>

-- 
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/f1592f4f-d857-4fd7-8c10-de8cee3779d4n%40googlegroups.com.

Re: [git-users] an elementary question how to switch/checkout a remote branch

[Philip Oakley]

Hi all,

On 16/11/2022 11:55, Konstantin Khomoutov wrote:
>> I thought the main difference between git and hg, is (besides the
>> command syntax) the way branches are considered, a git branch is similar
>> to a bookmark, while a named branch has no equivalent in git.
> This is true, but the terminology, as usually, is open to interpretaton
> and allows some wiggle room for mind ;-)
> When some text says Git branches are like bookmarks, and that Hg's named
> branches have no equivalent in Git, that is true, but the meaning of this is
> that 1) Git commits do not embed the name of the branch which was checked out
> when the commit has been recorded; 2) Branches do not have any metadata except
> the current name of the branch; 3) A brach records its tip commit; when a new
> commit is recorded on a branch, this record is overwritten.
>
> I find it easier to undertand if you think of a Git branch as

I visualise it similar to a speech bubble or label that is attached to /
moved along with, the tip commit. Perhaps as a 'push-pin', if you will,
that marks your progress in generating the sequence of commits in the
'graph'.

And also if you merge a feature branch into a main branch you, just like
a push-pin on a road map, lose the sense of the route you took to get
there. You just know where that label *is*, rather than where it has been.

>  a text file (and
> in the reference Git implementation a branch _is_ a text file) which contains
> the cryptographic hash of the commit it points at.
> When you record a new commit, the file is rewritten with the new hash.
> When you rename a branch, the file is renamed.
> You see, we can say it looks like a bookmark to a commit.
>
while 100% true, sometimes folks don't see the implementation view,
hence the shift to an analogy, even though analogies can lead to other
misunderstandings...


As for the 'Frenchness' of "remote tracking branches" (local branches de
tracking de remote ;-), they can be really confusing, along with the
feeling that you must have a personal local branch to match an 'rtb'.

As rtb's are local, their tip is just one of the push-pin labels, so you
don't need a second push-pin at the same commit with a local name just
to reference it. That took me a long while (years) to appreciate.

I hope the extra comparison explanation is of help.

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/925711eb-bacb-9f72-88a6-f47214aedf92%40iee.email.

[git-users] Re: Would like to generate logs just like in the official documentation from a real git repo

[Philip Oakley]

I'd been looking at the `log` man page, rather than the rebase 
man page!

A the moment it's not possible.

It might become possible if (big if):

   1. there was a way of labelling all commits with single letter labels, 
   and limiting the size to the screen width. (with two dashes and a single 
   char you only get ~26 steps across the graph, fits [A-Z] though;-)
   2. A mode that simply provides those labels A-Z, a-z etc
   3. List the label key (if required) mapping the label to the oid or any 
   of the other formats.
   4. Maybe could have a 2 digit `Trunc` option that didn't use ellipsis 
   for shortening the hash for a 2 digit oid label .
   5. rework of the algorithm (currently one line per `*` commit) to allow 
   many commits in the same (now) column.

Could make a nice little [extendable] project.

Try `git log --graph --format="%<(4,trunc)%h=2" -16` to see the current 
`trunc` 2 dot ellipsis that could be dropped if a hard `Trunc` was added, 
and probably an `Ltrunc` to get the last N chars.


On Tuesday, October 18, 2022 at 4:26:33 PM UTC+1 amine.ab...@gmail.com 
wrote:

> I've pasted the example I would like to output from `git log` in my 
> original post. If you say that is hand-crafted then that basically leaves 
> me with no choice but to either hand craft things myself as well or accept 
> the output of ` git log --graph --format="%(describe:tags=true)" --all` 
> however horrific it may look.
>
> If you know of a quick/effective way to generate horizontal graphs of 
> revision histories from real repositories then I'd love to hear about it. 
> My preference is using `git log` but based on what I've seen so far the 
> orientation (horizontal/vertical) or the standard output cannot be 
> controlled. 
>
>
>
>
> On Friday, October 14, 2022 at 2:46:46 PM UTC+2 philip...@iee.email wrote:
>
>> Hi Amine,
>>
>> Would you be able to provide a link to any particular example that you 
>> felt may have been formatted via `git log` or similar.
>> Likely places are via the //git-scm.com/doc 
>>  site, and/or (even better) via 
>> /git.git/Documentation/ 
>>  's 
>> files (especially with line number selection;-).
>>
>> I suspect that the examples will have been hand crafted as a 
>> retrospective that tries to look nice on the doc pages, rather than 
>> represent a real output.
>>
>> That said, it doesn't mean it can't be done (or extended to do it). 
>>
>> [Aside: Things like the hex oid (instead of tag) could be 
>> extended/simplified to use 10 bits of oid, as the first two hex digits 
>> (bits 0-7 counting from msb), and capitalised based on bits 8 & 11 of the 
>> oid (i.e. third char is 0-7/8-f, and even/odd). Or something like that 
>> (just realise 0-9 can't be capitalised easily, doh!). Very compact, low 
>> chance of collision. ]
>>
>> On Friday, October 14, 2022 at 12:08:18 PM UTC+1 amine.ab...@gmail.com 
>> wrote:
>>
>>> Suppose I have a small local repo which I have set up exactly as 
>>> follows, following the docs  for 
>>> rebasing with Git :
>>>
>>>   A---B---C topic
>>>  /
>>> D---E---F---G master
>>>
>>> I tag each commit with its respective letter, D, E or F for example.
>>>
>>> I would like to construct a git log command which would provide me with 
>>> exactly the log shown above. So it should look like a graph, should show 
>>> only the tagged commit, show the commit tag instead of hash sequence and 
>>> show the branch name at the tip of each branch.
>>>
>>> I was able to build up part of this as follows:
>>>
>>> git log --graph --format="%(describe:tags=true)" --all
>>>
>>> There are still a couple of issues, namely:
>>>
>>>- The graph is not horizontal 
>>>- The branch names are not shown at the tips of the branches 
>>>
>>> Is there anyway to get git log to generate the output I’m looking for? 
>>> If not then I’d be curious to know how logs in the official documentation 
>>> were generated?
>>> ​
>>>
>>>

-- 
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/da1c5d24-8278-4f02-a176-c450113a040an%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: Would like to generate logs just like in the official documentation from a real git repo

[Philip Oakley]

Hi Amine,

Would you be able to provide a link to any particular example that you felt 
may have been formatted via `git log` or similar.
Likely places are via the //git-scm.com/doc 
 site, and/or (even better) via 
/git.git/Documentation/ 
 's files 
(especially with line number selection;-).

I suspect that the examples will have been hand crafted as a retrospective 
that tries to look nice on the doc pages, rather than represent a real 
output.

That said, it doesn't mean it can't be done (or extended to do it). 

[Aside: Things like the hex oid (instead of tag) could be 
extended/simplified to use 10 bits of oid, as the first two hex digits 
(bits 0-7 counting from msb), and capitalised based on bits 8 & 11 of the 
oid (i.e. third char is 0-7/8-f, and even/odd). Or something like that 
(just realise 0-9 can't be capitalised easily, doh!). Very compact, low 
chance of collision. ]

On Friday, October 14, 2022 at 12:08:18 PM UTC+1 amine.ab...@gmail.com 
wrote:

> Suppose I have a small local repo which I have set up exactly as follows, 
> following the docs  for rebasing 
> with Git :
>
>   A---B---C topic
>  /
> D---E---F---G master
>
> I tag each commit with its respective letter, D, E or F for example.
>
> I would like to construct a git log command which would provide me with 
> exactly the log shown above. So it should look like a graph, should show 
> only the tagged commit, show the commit tag instead of hash sequence and 
> show the branch name at the tip of each branch.
>
> I was able to build up part of this as follows:
>
> git log --graph --format="%(describe:tags=true)" --all
>
> There are still a couple of issues, namely:
>
>- The graph is not horizontal 
>- The branch names are not shown at the tips of the branches 
>
> Is there anyway to get git log to generate the output I’m looking for? If 
> not then I’d be curious to know how logs in the official documentation were 
> generated?
> ​
>
>

-- 
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/aadd31bc-528d-4d4f-83f8-2652463fb1b9n%40googlegroups.com.

Re: [git-users] Re: "\ No newline at end of file" displayed for symlinks

[Philip Oakley]

There is a further discussion on the Git mailing list on this subject [1].

The key point is that this is not a "warning" (in the 'treat warnings as 
errors' vein [2]), rather is a statement about the presence or absence of a 
particular 'white space' in the file.
Unix tend to believe that a complete (text) file is a sequence of lines, 
each terminated by a line feed (LF), so this is only a 'warning' in the 
social sense, and is hence informative. It's not a bug, but part of the 
flip side of diff needing some technical clarity as to how to deal with 
this 'change'.

[1] https://lore.kernel.org/git/xmqq35bsk9og.fsf@gitster.g/T/#u 
[2] https://blog.submain.com/treat-warnings-errors/
On Thursday, October 13, 2022 at 5:20:39 AM UTC+1 Thorsten Schöning wrote:

> Guten Tag 'Daniel Gutson' via Git for human beings,
> am Mittwoch, 12. Oktober 2022 um 23:12 schrieben Sie:
>
> > this actually is not a question, but a potential bug report. I
> > think git should not complain about the lack of the newline for symlinks.
>
> The contents of what GIT maintains as symlinks are plain textual paths
> and are therefore handled like every other plain text. So things are
> consistent as they are, including the warning. If symlink contents aka
> their paths wouldn't be treated as plain text like all other texts, you
> wouldn't be able to diff anything anyway.
>
> So the real question is: How do you think symlinks should be diffed?
> As textual path would be the wrong answer, as that's what's done
> right now.
>
> Alternatively you would need to discuss why the missing newline ending
> is warned about for ANY textual content, as it's up to the user if
> that is necessary or not anyway. GIT can't decide such things.
>
> And besides, one needs to make sure where that warning comes from at
> all as well. Is it really GIT itself or some default text editor
> involved like VI or ...
>
> To make a long story short: I don't think it's worth it to report that
> as a bug and I guess it won't be "fixed".
>
> Mit freundlichen Grüßen
>
> Thorsten Schöning
>
> -- 
> AM-SoFT IT-Service - Bitstore Hameln GmbH
> Mitglied der Bitstore Gruppe - Ihr Full-Service-Dienstleister für IT und TK
>
> E-Mail: thorsten@am-soft.de
> Web: http://www.AM-SoFT.de/
>
> Tel: +49 5151- 9468- 0 <+49%205151%2094680>
> Tel: +49 5151- 9468-55 <+49%205151%20946855>
> Mobil: +49 178-8 9468-04
>
> AM-SoFT IT-Service - Bitstore Hameln GmbH, Brandenburger Str. 7c, 31789 
> Hameln
> AG Hannover HRB 221853 - Geschäftsführer: Janine Galonska
>
>
> Für Rückfragen stehe ich Ihnen jederzeit zur Verfügung. 
>
> Mit freundlichen Grüßen, 
>
> Thorsten Schöning
>
>
> Telefon: +49 5151 9468-55 <+49%205151%20946855>
> Fax: 
> E-Mail: tscho...@am-soft.de
>
> AM-Soft IT-Service - Bitstore Hameln GmbH
> Brandenburger Straße 7c
> 31789 Hameln
>
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
> Informationen und ist ausschliesslich für den Adressaten bestimmt. 
> Jeglicher Zugriff auf diese E-Mail durch andere Personen als den Adressaten 
> ist untersagt. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
> vernichten Sie diese E-Mail. Sollten Sie nicht der für diese E-Mail 
> bestimmte Adressat sein, ist Ihnen jede Veröffentlichung, Vervielfältigung 
> oder Weitergabe wie auch das Ergreifen oder Unterlassen von Massnahmen im 
> Vertrauen auf erlangte Information untersagt. 
>
> This e-mail may contain confidential and/or privileged information and is 
> intended solely for the addressee. Access to this email by anyone else is 
> unauthorized. If you are not the intended recipient (or have received this 
> e-mail in error) please notify the sender immediately and destroy this 
> e-mail. If you are not the intended recipient, any disclosure, copying, 
> distribution or any action taken or omitted to be taken in reliance on it, 
> is prohibited and may be unlawful. 
>
> Hinweise zum Datenschutz: bitstore.group/datenschutz
>
>
>
>

-- 
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/c4f53bb2-cff6-4a76-8fa7-cd34ca88ce63n%40googlegroups.com.

[git-users] Re: "\ No newline at end of file" displayed for symlinks

[Philip Oakley]

https://stackoverflow.com/a/954575/717355 may be a suitable answer that 
matches what you are seeing.

On Wednesday, October 12, 2022 at 9:06:01 PM UTC+1 ignacio...@eclypsium.com 
wrote:

> Hello,
>
> Sorry I forgot to mention I'm running a Linux system.
>
> Let me give you an example about how to reproduce this:
>
> - Clone git.git repo
> - *cd git*
> - l*n -s RelNotes RelNotes2*
> - *git add RelNotes2*
> - *git commit -m Test*
> - *git show* will display something like this:
>
>
>
>
>
>
>
>
>
>
>
>
>
> *commit 800c9cfa674e9c3e1d562c4c95699cc0094d6621 (HEAD -> master)Author: 
> Ignacio Taranto Date:   Wed Oct 12 17:04:52 2022 
> -0300Testdiff --git a/RelNotes2 b/RelNotes2new file mode 12index 
> 000..6efa746--- /dev/null+++ b/RelNotes2@@ -0,0 +1 @@+RelNotes*
>
> *\ No newline at end of file*
>
>
>
> On Wednesday, October 12, 2022 at 4:40:21 PM UTC-3 philip...@iee.email 
> wrote:
>
>> Is this a Linux/*nix system, or a Windows (Git for Windows [GfW]) system? 
>>
>> It's important because Symlinks on nix systems are, as best I understand 
>> it, a file system property, while on Windows it's emulated as a file (IIRC) 
>> and the Git Index makes a note of that mode status.
>>
>> Can you show the actual setup and output that you are seeing.
>>
>> It wouldn't surprise me that the file, from the *nix dev view would not 
>> have a terminating LF (Git does that a lot).
>>
>> If you actually have the git.git repo cloned, then look at the RelNotes 
>> 'file'. On my GfW it has no LF terminator.
>>
>> On Wednesday, October 12, 2022 at 8:11:33 PM UTC+1 
>> ignacio...@eclypsium.com wrote:
>>
>>> So, both *git diff* and *git show* display "\ No newline at end of 
>>> file" for symlinks.
>>>
>>> I think this doesn't make any sense since symlinks are not even regular 
>>> files.
>>>
>>> I think this is a bug about how Git renders diffs for symlinks, I am 
>>> making any sense here?
>>>
>>> Should I report this bug into the mailing 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/5cb04fef-e539-494f-a621-57f22ccd73bbn%40googlegroups.com.

[git-users] Re: "\ No newline at end of file" displayed for symlinks

[Philip Oakley]

Is this a Linux/*nix system, or a Windows (Git for Windows [GfW]) system? 

It's important because Symlinks on nix systems are, as best I understand 
it, a file system property, while on Windows it's emulated as a file (IIRC) 
and the Git Index makes a note of that mode status.

Can you show the actual setup and output that you are seeing.

It wouldn't surprise me that the file, from the *nix dev view would not 
have a terminating LF (Git does that a lot).

If you actually have the git.git repo cloned, then look at the RelNotes 
'file'. On my GfW it has no LF terminator.

On Wednesday, October 12, 2022 at 8:11:33 PM UTC+1 ignacio...@eclypsium.com 
wrote:

> So, both *git diff* and *git show* display "\ No newline at end of file" 
> for symlinks.
>
> I think this doesn't make any sense since symlinks are not even regular 
> files.
>
> I think this is a bug about how Git renders diffs for symlinks, I am 
> making any sense here?
>
> Should I report this bug into the mailing 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/15f45646-35b5-43e2-aa6c-2182bd5476c9n%40googlegroups.com.

[git-users] Re: There is no tracking information for the current branch.

[Philip Oakley]

There are few things going on within Git that can catch folks unawares. 
The first is that you should compare the idea of whether you want to create 
a duplicate copy, or whether you are looking to create a twin, with a 
separate life of it's own. The latter (for which clone is 'designed') is 
the case when you are building upon the work of others, while the former is 
the 'backup' case. You could look at using the --mirror options for keeping 
duplicates.

Given the 'normal' case is the independent clones case it than become 
necessary to actively tell your local clone exactly which of the other 
clones of the project that you are following (for the 'pull' and 'fetch' 
cases). This is where the tracking information for the 'upstream' comes in. 
While 'pull' was historically the leading use case, it is now best practice 
(usually after a few face plants) to think through the processes you 
want/need and utilise those instead (i.e. split the pull so that you have a 
separate 'fetch' and then a personally chosen alternate to the 'merge' 
step).

A really big learning step, I found, was to realise that 'remote tracking 
branches' are actually local, and are just regular branches (which Git 
tries to keep 'read only'), with easy access and naming. So you can easily 
start a new branch on top of say 'origin/main' (using the common names for 
the remote, and its leading branch). You don't actually need to have a 
personal branch called 'main' that's a duplicate of the 'upstream' 
repository.

It then becomes easy to push your updates back to any 'fork' (clone) that *you 
*have on one of the Gitxxx services. The key is the use of the 
"pushDefault" config setting so that where you 'publish' your updates is 
distinct from the upstream that you follw (which usually won't accept your 
pushes in an open source environment - that's for pull requests;-)
```
[remote]
pushDefault = my
```

Hope that is useful in getting to grips with the power of Git.
On Friday, August 19, 2022 at 12:07:22 AM UTC+1 MJ Hennebry wrote:

> I have a git repository I use for all related work.
> I cloned it for two reasons:
> A backup.
> Allow testing whether everything needed is under version control.
>
> This seems like something that should be easy.
> If I cannot do it, I might have to give up on version control,
> as git seems to have conquered the world.
>
> To be clear, by "cloned", I mean that I made it with git clone.
> I want to maintain the clone as a more or less exact copy of its mother.
> The clone, of course, would remember its mother.
>
> From git help fetch and git help pull , I gathered I could do this.
> Nyet.
> No combination of git fetch and git pull seems to do the trick.
> Eventually I got
> [hennebry@fedora sqrt-g]$ git pull
> \There is no tracking information for the current branch.
> Please specify which branch you want to merge with.
> See git-pull(1) for details.
>
> git pull  
>
> If you wish to set tracking information for this branch you can do so with:
>
> git branch --set-upstream-to=origin/ master
>
> [hennebry@fedora sqrt-g]$ gvim /tmp/git.txt
> [hennebry@fedora sqrt-g]$ pwd
> /home/hennebry/sqrt-g
> [hennebry@fedora sqrt-g]$ git branch
>   corrections
> * master
>   split1
> [hennebry@fedora sqrt-g]$ 
>
> I am not happy.
> What happened?
> How do I do what I want to do?
> Will I have to process each branch one at a time?
> That could be difficult, since at the moment,
> I cannot even process one branch.
> git fetch --all ?
>
> The mother is on an SD card that through USB has
> been continuously connected to my PC at all times.
> The clone is on my hard drive.
>
> [hennebry@fedora sqrt-g]$ git remote -v
> origin/run/media/hennebry/data2/mathprog/sqrt-g (fetch)
> origin/run/media/hennebry/data2/mathprog/sqrt-g (push)
> [hennebry@fedora sqrt-g]$ [hennebry@fedora sqrt-g]$ git diff
> [hennebry@fedora sqrt-g]$ git merge
> fatal: No remote for the current branch.
> [hennebry@fedora sqrt-g]$ 
>
>
>

-- 
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/2e4d940f-aa13-4ad7-92dd-8c23f0be95c1n%40googlegroups.com.

Re: [git-users] Feature Request - Branch Metadata or Descriptions

[Philip Oakley]

On 21/07/2022 12:13, Konstantin Khomoutov wrote:
> On Mon, Jul 18, 2022 at 02:34:44PM -0700, Dan Rosen wrote:
>
>> Adding metadata to branches would be helpful for third party APIs to 
>> organize and tag branches without putting them in the branch name. For 
>> example, project management software will use an issue key to search the 
>> branch name but it would be better to search branch metadata. I know 
>> branches have descriptions but I believe these are part of the local 
>> configuration?
> FWIW, a recent discussion on the main Git list [1] brought to my attention
> that there exist support for setting textual branch descriptions: a config
> setting branch..description, which can be manipulated with the
> `git branch --edit-description` command. See the gitconfig manual page for
> more details.
>
>  1. https://public-inbox.org/git/xmqqilnr1hff.fsf@gitster.g/

That discussion is looking interesting.

However the discussion about Commit-IDs at
https://lore.kernel.org/git/bdbe9b7c1123f70c0b4325d778af1df8fea2bb1b.ca...@that.guru/
should also be looked at to see some of the nuances that need to be
considered (e.g. https://lore.kernel.org/git/yth9tccexfmag...@mit.edu/).

I'm for the idea that it should be possible for branch descriptions to
be portable and be passed between repos and devs, but ultimately it is
for the local dev to decide which description to accept, use and publish.

-- 
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/37cea93d-75f3-d7dd-5430-08ac035287e7%40iee.email.

Re: [git-users] Re: Feature Request - Branch Metadata or Descriptions

[Philip Oakley]

On 19/07/2022 00:10, Dan Rosen wrote:
> Is there no board of directors to discuss improvements to Git? 

Git is Open Source, so anyone can propose patches that may improve Git's
capability (mailing list https://lore.kernel.org/git/). There is a
maintainer who makes a final judgement, after reviews on the git mailing
list. So, no, there are no directors..

It's important to realise that the core essence of Git is to provide
source code management for the Linux project, so it does need to be
compatible with the wide variation in styles of the diverse
contributors, along with maintaining backwards compatibility for those
on older versions.

> Modern common practice organizes branches with slashes "/'.
> "feature/new-feature, bug/bug-fix, etc" 
That's an artefact of the original scripts that stored branch refs as
file paths. Formally, a ref is just a character string, though old
habits die hard.

> but this is a limited way to add meta data to a branch. 
As a _distributed control_  system, it's the user that gets to name
their local branch and any metadata.
Yes, commonly we lazy humans just reuse the upstream name (as passed
down on tablets of stone from the directors ;-), but that's not always
the case, especially if you are looking at multiple 'upstream' forks,
each thinking they have their own 'master' and 'main' and 'feature1'
branches, so when that happens I have to rename them, despite the
upstream naming (Git and Git-for-Windows had that issue for a while).

> Tags can have annotations so why can't branches?

Tags have the opposite problem. You can't easily rename them when you
have multiple upstreams, each thinking they can tag their v1.2.3 release
- confusing!
>
> Why not have a way to say that branches XYZ and ABC are part of
> release 3.2.1? Why not have a way to say branch XYZ is a feature
> (story) and ABC is a bugfix?

The above is not to say it can't be done, rather that there are more
stakeholders to be considered. It will depend on how users upstream
remotes are managed and who can push to them, and their
interrelationship. If every dev has their own push/publish fork, then
they should be able to add their own metadata to their branches, and
push them to their publish remote. However the projects golden remote
will have different rules, and the branch metadata there would be set by
it's 'owner' and may not match the meta data that the local dev has
created / amended for the same 'branch'.

At some point there needs to be a separation of control so that a dev
could fetch, and maybe merge, the upstream branch metadata, but that
needs to be in the user's control. Likewise the user needs (should be
able) to store their branch metadata in their publish remote (they have
control!). All that would need some extensions to the transport and
permissions protocols, which may be a more detailed project.

>
> branch-per-task is a very common git workflow. And branch naming is
> getting ugly because there are things in the name that shouldn't be.

Why not have a careful review of the various workflows to see how others
break up these Catch 22 issues to see where the implicit conflicts are,
such as the longevity of branch names vs the expectation that they are
ephemeral, etc.  Maybe also look at the way Git itself manages
contributions - contributor branch names rarely match those allocated by
the maintainer. The "A note from the maintainer" is at
https://lore.kernel.org/git/xmqqbktufedk.fsf@gitster.g/ e.g. see the
"How various branches are used" section.
>
> Do what you will with my thoughts...

Maybe consider having a dev have a look at the code as a side `10%
project` to see what the options could be? Contributions are always welcome.


>
> On Monday, July 18, 2022 at 4:34:05 PM UTC-6 philip...@iee.email wrote:
>
> I believe this has been discussed a few times. However branches
> are meant to be local and ephemeral, which goes against that
> 'organise' view that, in a sense, sees branches as tasks to be
> controlled.
>
> Git, being distributed, looks to the code content, along with the
> DAG, to get it's perspective on the code. Once a branch has been
> merged, where would the meta data go (and who decides)?
>
> On Monday, July 18, 2022 at 10:34:44 PM UTC+1 dro...@ucar.edu
> 
> wrote:
>
> Adding metadata to branches would be helpful for third party
> APIs to organize and tag branches without putting them in the
> branch name. For example, project management software will use
> an issue key to search the branch name but it would be better
> to search branch metadata. I know branches have descriptions
> but I believe these are part of the local configuration?
>
> - Dan Rosen
>

-- 
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 vie

[git-users] Re: Feature Request - Branch Metadata or Descriptions

[Philip Oakley]

I believe this has been discussed a few times. However branches are meant 
to be local and ephemeral, which goes against that 'organise' view that, in 
a sense, sees branches as tasks to be controlled. 

Git, being distributed, looks to the code content, along with the DAG, to 
get it's perspective on the code. Once a branch has been merged, where 
would the meta data go (and who decides)?

On Monday, July 18, 2022 at 10:34:44 PM UTC+1 dro...@ucar.edu wrote:

> Adding metadata to branches would be helpful for third party APIs to 
> organize and tag branches without putting them in the branch name. For 
> example, project management software will use an issue key to search the 
> branch name but it would be better to search branch metadata. I know 
> branches have descriptions but I believe these are part of the local 
> configuration?
>
> - Dan Rosen
>

-- 
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/62f625ec-1a6c-4dde-aad8-2ac438eb1b45n%40googlegroups.com.

Re: [git-users] Feature idea: Warning for git reset --hard with unstaged local changes

[Philip Oakley]

> Still, implementing such mode is impossible in `git reset --hard` because 
it's being extensively used in scripts which must continue working 
unmodified. 

I'm more upbeat about the possibilities here for a multi-graded option for 
capturing the user's prior tree, with it's user modified versions of the 
tracked files that will be overwritten being stored in the object store, 
and noted in a suitable reflog. Initial thought is that it's not a commit, 
rather it's just the tree and updated blobs, so they would be garbage 
collected eventually.

Key factors will be the detection of it being a cli command vs being a 
script, so that the initial default could be to capture all `reset --hard` 
commands, softening to just those directly given on the command line (which 
maybe the general default - usual reasons), and then have one for capturing 
the --soft option (similar user mistakes), and finally the 'off' option.

I suspect that the simplest way is to pick up the default based on the 
choice of remote workflow (i.e. if they use the simple workflow, then start 
with full capture. 

This UX (user experience) does turn up quite often so let's at least put in 
a few simple defences for those not yet fully aware of how Git works.

On Monday, July 18, 2022 at 5:28:17 PM UTC+1 Konstantin Khomoutov wrote:

> On Mon, Jul 18, 2022 at 07:16:28PM +0300, Konstantin Khomoutov wrote: 
>
> [...] 
>
> > Another solution which seems logical at the first glance is using the 
> "trash 
> > bin" feature is the OS provides it but it also has practical problems: 
> it is 
> > never the core feature provided by the kernel, and Git is not always 
> used by 
> > human beings through graphical user interfaces, and also Git uses lots 
> of 
> > files not intended to be dealt with by the user anyway (though 
> admittedly in 
> > your particular case moving the files to the trash can could help). 
>
> May be a good middle ground could be using the "trash can" facility _if 
> possible_ with presenting a user with the summary of what unstaged files 
> to be 
> overwritten/removed. 
>
> Still, implementing such mode is impossible in `git reset --hard` because 
> it's 
> being extensively used in scripts which must continue working unmodified. 
>
> Adding a new command-line options forcing this work mode of the reset 
> command 
> to be extra-interactive will be of questionable utility as the user would 
> have 
> to type it in order to get this behavior. 
>
> So, looks like it's a case for a new top-level command, I dunno. 
> Adding new "sensible" top-level commands for already existing behavior is 
> not 
> uncommon: `git switch` is a good example. 
>
>

-- 
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/e49beb96-3e26-4680-9b98-1802c024ba0en%40googlegroups.com.

[git-users] Re: Feature request | GIT keep recently used files separately for each branch

[Philip Oakley]

Git already keeps the last modified date (mtime) in the index and I thought 
it could be accessed through appropriate commands (git ls-files), though a 
check of the man pages failed me), also the --format option is slowly being 
added to more commands. Is the file mtime what is needed?

I don't think that there are easy ways of Git remembering which files you 
were recently interested in (last opened times?) especially if it wasn't 
Git that opened the file - you could have opened the file in one of many 
file editors or IDEs.

There is a similar problem in trying to mark as file as being 'no longer 
interesting'  (remove from the interesting list until next time..)

I can see one option that is that the IDE maintains a very long list of 
'recently opened' files and their times, and then filters that based on the 
mtimes that are found in the current branch's index, so that only those 
files that are in/on the current branch tip will be shown in the recently 
used list.

So the IDE lists (internally) the files f1, f5, f3, f2, f9 in order that it 
opened those files, and then when on 'master' you only see f1, f3, f2 (as 
that their order for 'master' branch), and when on `feature` you see f1, 
f3, f9. You (the IDE) could even have a selector to allow 'all' 'current' 
'branch-by-name' selections.

All that is within the gift of the IDE designers, rather than Git.

HtH (Hope that Helps)

On Friday, July 1, 2022 at 3:01:07 PM UTC+1 scappatur...@gmail.com wrote:

> Hi,
> Changing branch is always annoying because IDE only shows most recent used 
> files independently from the branch you are on. So especially in big 
> project, after a branch switch you usually have to go find your files 
> manually.
>
> What do you think about introducing a new feature for keeping track of 
> recently used file separately for each branch ?
>
> e.g 
> master 
> file 1 file 2 file 3
> feature 
> file 1 file 5 file 9
>
> Then IDE developer can rely on this file in order to populate recently 
> used file list. Please let me know your thoughts.
>

-- 
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/8baf3340-1a4d-4155-90c0-2367939562fbn%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] Visualize all fork (branched) point from the main/master branch

[Philip Oakley]

> git branch [-r|-a] --contains 4356hae 

I should have known/remembered that! Thank you for the clarification.

On Wednesday, June 29, 2022 at 11:27:35 AM UTC+1 Konstantin Khomoutov wrote:

> On Tue, Jun 28, 2022 at 01:54:06PM -0700, Namasi wrote:
>
> [...]
>
> > For instance if "main" branch has a commit (ID: 4356hae), how to list 
> out 
> > the branches that containing his content/commit ID?
>
> This one is easy:
>
> git branch [-r|-a] --contains 4356hae
>
> will list all the local (or remote, if '-r' is specified, or local and 
> remote,
> if '-a' is specified) branches from the tips of which that commit is
> reachable, and which hence "contain" it.
>
>

-- 
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/a48f78bc-24bf-4543-824e-eb15aa2ab046n%40googlegroups.com.

Re: [git-users] Visualize all fork (branched) point from the main/master branch

[Philip Oakley]

Correction - it'll be the `contains` variant. (assumes dropping the 
negation works as expected..)

On Tuesday, June 28, 2022 at 10:37:19 PM UTC+1 Philip Oakley wrote:

> Try the `for-each-ref` command. I use it to list my most recent branches, 
> sorted so that the newest is at the end of the displayed list.
>
> my "branch sort" alias looks like:
> ```
> bsort = for-each-ref --sort=committerdate --format='%(refname:short) 
> %(committerdate:short) %(authorname)' refs/heads
> ```
>
> I think you will want to add ` --no-contains[=]` which only lists 
> refs which don’t contain the specified commit. 
> see 
> https://git-scm.com/docs/git-for-each-ref#Documentation/git-for-each-ref.txt---no-containsltobjectgt
>  
> then stick your oid as the .
>
> On Tuesday, June 28, 2022 at 9:54:07 PM UTC+1 Namasi wrote:
>
>> i understand that branch is like a "sticky-note" where the commit ID is 
>> overwritten when user makes new commits on that branch. The basis for my 
>> actual question was to find the latest fork point off  the main branch, so 
>> that i can find if a specific commit is present on a branch (which was 
>> created off main).
>>
>> For instance if "main" branch has a commit (ID: 4356hae), how to list out 
>> the branches that containing his content/commit ID?
>>
>> On Tuesday, June 28, 2022 at 4:17:05 AM UTC-5 Konstantin Khomoutov wrote:
>>
>>> On Mon, Jun 27, 2022 at 01:36:57PM -0700, Namasi wrote: 
>>>
>>> > What is the git command to visualize the all the fork (branch) point 
>>> from 
>>> > the main/master branch? There are few branches forked from the main, 
>>> so i 
>>> > don't have the complete list. Looks for a git comment to 
>>> comprehensively to 
>>> > list/summarize the point/commits. Prefer to see in a graphview. 
>>>
>>> I would say this task may be more complicated than you think. 
>>>
>>> For instance, consider this history: 
>>>
>>> o---o---o---m---o--- B 
>>> / / 
>>> ---o---f---o---o---o---o---o--- A 
>>>
>>> Here, the branch B has been forker off A at point f but then after 
>>> certain 
>>> development done on both branches A had been merged into B at point m. 
>>> After that, the development continued. 
>>> Does the point m represents a new fork point for B off A? 
>>> Note that logically the point m consolidated the state of the both 
>>> branches. 
>>>
>>> Now consider this: 
>>>
>>> o---o---o o---o--- B 
>>> / \ / 
>>> ---o---f---o---o---m---o---x---o--- A 
>>>
>>> Here, does the point f still represents a fork point of interest or not? 
>>> It _is_ a fork point as there are three commits developed on the forked 
>>> line 
>>> of history but that line has been merged back, and since branches in Git 
>>> do 
>>> not record their identity in the commits created "on" them, you cannot 
>>> know 
>>> what was the name of the branch back then when these three commits were 
>>> in 
>>> development. I mean that even if that developmend happened on a branch 
>>> named 
>>> B, that information is now completely lost: there is a fork point but 
>>> you 
>>> cannot say what the name of the forked branch was. 
>>>
>>> So, your question supposedly needs a more narrowly-scoped definition. 
>>>
>>> If it's about finding all possible "joints" of such "diamond-shaped" 
>>> bits of 
>>> the history - that's one thing. If you're only interested in the 
>>> branches 
>>> which currently exist in a repository - that's another thing. 
>>> If you're interested only in the last point any two branches had the 
>>> same 
>>> history - that's one thing; if you want to locate the last (oldest; 
>>> closest to 
>>> the root) such point - that's another thing. 
>>>
>>>

-- 
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/eff0df1b-8fb0-4482-90e5-d266aaee1d89n%40googlegroups.com.

Re: [git-users] Visualize all fork (branched) point from the main/master branch

[Philip Oakley]

Try the `for-each-ref` command. I use it to list my most recent branches, 
sorted so that the newest is at the end of the displayed list.

my "branch sort" alias looks like:
```
bsort = for-each-ref --sort=committerdate --format='%(refname:short) 
%(committerdate:short) %(authorname)' refs/heads
```

I think you will want to add ` --no-contains[=]` which only lists 
refs which don’t contain the specified commit. 
see 
https://git-scm.com/docs/git-for-each-ref#Documentation/git-for-each-ref.txt---no-containsltobjectgt
 

then stick your oid as the .

On Tuesday, June 28, 2022 at 9:54:07 PM UTC+1 Namasi wrote:

> i understand that branch is like a "sticky-note" where the commit ID is 
> overwritten when user makes new commits on that branch. The basis for my 
> actual question was to find the latest fork point off  the main branch, so 
> that i can find if a specific commit is present on a branch (which was 
> created off main).
>
> For instance if "main" branch has a commit (ID: 4356hae), how to list out 
> the branches that containing his content/commit ID?
>
> On Tuesday, June 28, 2022 at 4:17:05 AM UTC-5 Konstantin Khomoutov wrote:
>
>> On Mon, Jun 27, 2022 at 01:36:57PM -0700, Namasi wrote:
>>
>> > What is the git command to visualize the all the fork (branch) point 
>> from 
>> > the main/master branch? There are few branches forked from the main, so 
>> i 
>> > don't have the complete list. Looks for a git comment to 
>> comprehensively to 
>> > list/summarize the point/commits. Prefer to see in a graphview.
>>
>> I would say this task may be more complicated than you think.
>>
>> For instance, consider this history:
>>
>> o---o---o---m---o--- B
>> / / 
>> ---o---f---o---o---o---o---o--- A
>>
>> Here, the branch B has been forker off A at point f but then after certain
>> development done on both branches A had been merged into B at point m.
>> After that, the development continued.
>> Does the point m represents a new fork point for B off A?
>> Note that logically the point m consolidated the state of the both 
>> branches.
>>
>> Now consider this:
>>
>> o---o---o o---o--- B
>> / \ /
>> ---o---f---o---o---m---o---x---o--- A
>>
>> Here, does the point f still represents a fork point of interest or not?
>> It _is_ a fork point as there are three commits developed on the forked 
>> line
>> of history but that line has been merged back, and since branches in Git 
>> do
>> not record their identity in the commits created "on" them, you cannot 
>> know
>> what was the name of the branch back then when these three commits were in
>> development. I mean that even if that developmend happened on a branch 
>> named
>> B, that information is now completely lost: there is a fork point but you
>> cannot say what the name of the forked branch was.
>>
>> So, your question supposedly needs a more narrowly-scoped definition.
>>
>> If it's about finding all possible "joints" of such "diamond-shaped" bits 
>> of
>> the history - that's one thing. If you're only interested in the branches
>> which currently exist in a repository - that's another thing.
>> If you're interested only in the last point any two branches had the same
>> history - that's one thing; if you want to locate the last (oldest; 
>> closest to
>> the root) such point - that's another thing.
>>
>>

-- 
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/10733d3a-d192-4f8a-a982-836f901948f8n%40googlegroups.com.

[git-users] Re: About config

[Philip Oakley]

The `sudo make install` is a known problem from the effects of the 
`safe.directory` design, which was in response to a CVE vulnerability of 
accessing repositories that you don't own. 

The use of `sudo` changes the userID, so one can fall into the trap of not 
appearing to own repositories you know are good.

The extended discussion on the mailing list, which includes various 
explanations, is at 
https://lore.kernel.org/git/20220426183105.99779-1-care...@gmail.com/t/#u

Philip

On Monday, June 6, 2022 at 4:55:21 PM UTC+1 erba...@gmail.com wrote:

> Dear all,
>
> I work on a Ubuntu 20.04.4 LTS machine with Linux Mint installed. My 
> version of git is 2.36.1.
>
> I am trying to install a git repository, complexespp 
> , 
> which requires the external repository yaml_cpp 
> . While running the last step of 
> installation of complexespp
> sudo make install
> I face the following problem:
>
> [  1%] Performing update step for 'yaml_cpp_project'
> CMake Error at 
> /home/davide/Desktop/complexespp/complexes++/build-gen/yaml_cpp_project-prefix/tmp/yaml_cpp_project-gitupdate.cmake:25
>  
> (message):
>  Failed to get the hash for HEAD:
>
>  fatal: unsafe repository
>
>  
> ('/home/davide/Desktop/complexespp/complexes++/build-gen/yaml_cpp_project-prefix/src/yaml_cpp_project'
>  is owned by someone else)
>
>  To add an exception for this directory, call:
>
>  git config --global --add safe.directory
>
>  
> /home/davide/Desktop/complexespp/complexes++/build-gen/yaml_cpp_project-prefix/src/yaml_cpp_project
>
> make[2]: *** [CMakeFiles/yaml_cpp_project.dir/build.make:118: 
> yaml_cpp_project-prefix/src/yaml_cpp_project-stamp/yaml_cpp_project-update] 
> Error 1
> make[1]: *** [CMakeFiles/Makefile2:418: 
> CMakeFiles/yaml_cpp_project.dir/all] Error 2
> make: *** [Makefile:146: all] Error 2
>
> I ran the advised line of code and the path added to ~/.gitconfig as 
> [safe], but the sudo command goes on returning the same error (even if I 
> set "*" as safe). Do you have any idea about how to fix it?
>
> Thanks a lot 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/722a17f8-b33a-40d7-8f8e-8735a98f4433n%40googlegroups.com.

[git-users] Re: How to resolve merge conflicts on octopus merges

[Philip Oakley]

Just to get some of my ideas 'down on paper', here are some notes I made of 
the concept.

The Partial, or Muddy Merge (tm)

This presumes we have a conflicted merge so this is interactive merge 
strategy.

We initialise the muddy-merge by creating a multi parent merge commit MM-0. 
This comprises:-
1st parent: Current HEAD (this is/will be the progressive tip of the merge
2nd parent: Current HEAD (this is the mergebase tip)
3rd parent: first branch to be merged (possibly the single mudball branch
4+th parent: second & subsequent octopus branches to be merged.
tree: Current HEAD's tree.

The duplicate entry for P1 & P2 is the indicator for the start of the muddy 
merge (also that there's a P3, etc).
The deadhead of this initial muddy merge commit's tree being identical to 
that of the first parent could also be a useful indicator - see the GfW 
release merges)

The next partial/muddy merge commit (MM-1) has the same format but the 1st 
parent commit is that of the muddy merge initialiser, and the tree has 
progressed with the partial/muddy merge, and the merge commit explains that 
step.

After a sequence of these muddy merges we have the P1 and tree values 
progressing, while P2-n are the unchanged reference points of the whole 
muddy merge.
These could be simple file merges by subject matter experts (SMEs) or 
composite branch merges to resolve multiple conflicts within this window. 
I.e. Usual ball of mud progression.

Eventually we have a completed merge commit (MM-N) that contains the final 
tree, but we haven't tided up loose ends to present a single-step clean 
merge, along with a side stream of how it happened. This muddy merge MM-N 
still has the P1,P2-n parent arrangement.

The desired result is that the first parent history shows / implies a 
single clean merge. It also requires (user dependant) a supplementary 
commit that has a "spare" second parent pointing to the muddy merge 
sequence (but unchanged tree) (technique borrowed from GfW).

Case A: Finalise with side notes
 The finalised merge commit (MM-final) uses the P2-n commit list of 
contributors (the P2 being the original MM-0 HEAD, i.e. one less parents), 
with the final tree.
 The supplemental commit (MM-side) then has P1=finalised commit, 
P2=completed side merge commit, same tree; commit message that its the side 
merge.
Case B: Finalise without side notes (aka squashed notes.) as per finalised 
as above, but the auto-merge message includes oid to the squashed notes 
commit). Reflog, possible tag, extra ref, or temp branch.
Case C: as Case B but no mention of the side note oid hash in the merge 
message. reflog.

Note the suplemental commit can be 'simplified' with a '--deadhead' option 
(if implementated)

--> implied time
```
main:A - B  -  MMfinal-   MMside - -> 
  \ //   /   
mudball: XYz - . - ./
\\  \  /
muddymerge MM0 - MM1,MM2 - MM-N
```
Was ASCII art..

commit parentage & tree
XYz: one or more branch tips. Alludes to XY-problem & more, doing the wrong 
thing righter; theory is nice, but reality bite.
MM0: B,B,XYz;treeB  (all MMx commits are octopus)
MM1: MM0,B,XYz;treeMM1
MMN: MM(N-1),B,XYz;treeMMN
MMfinal: B,XYz:treeMMN
MMside: B,MMN;treeMMN  (2-parent merge)

Philip

On Monday, May 16, 2022 at 1:20:36 PM UTC+1 Philip Oakley wrote:

> One of the big unstated aspects is the distinction between --automatic and 
> --interactive expectations. The main Git project has the assumption of 
> --automatic merges without any need for user intervention. That's on the 
> assumption of a 'clean' workflow with proper separation of concerns, small 
> changes, short lived branches and all that good stuff. There is also the 
> expectation that the code change and commits will be readable and 
> understandable in hindsight / maintenance. This all drives the 'No 
> conflicts' rule.
>
> But as we all know the more general reality is the "Big Ball of Mud" 
> development process (or at least that's where our problems are ;-). In 
> these cases it will be an --interactive muddy merge, usually with multiple 
> participants. Either because they each contributed a branch to your 
> octopus, or they each had an area and files of interest when the 
> mega-feature (single branch) is being merged, and no single person can 
> resolve the combined conflict (there have been discussions on that). 
>
> I suspect that what is needed is a half way house that acknowledges both 
> positions and offers a Partial Merge (or muddy merge (tm)). This needs a 
> method of capturing the 'per person / branch' staged changes, and the final 
> 'global' octopus, so that the simplified history is one of the single mega 
> merge, all done in one magic step, but beneath that is the details

[git-users] Re: How to resolve merge conflicts on octopus merges

[Philip Oakley]

One of the big unstated aspects is the distinction between --automatic and 
--interactive expectations. The main Git project has the assumption of 
--automatic merges without any need for user intervention. That's on the 
assumption of a 'clean' workflow with proper separation of concerns, small 
changes, short lived branches and all that good stuff. There is also the 
expectation that the code change and commits will be readable and 
understandable in hindsight / maintenance. This all drives the 'No 
conflicts' rule.

But as we all know the more general reality is the "Big Ball of Mud" 
development process (or at least that's where our problems are ;-). In 
these cases it will be an --interactive muddy merge, usually with multiple 
participants. Either because they each contributed a branch to your 
octopus, or they each had an area and files of interest when the 
mega-feature (single branch) is being merged, and no single person can 
resolve the combined conflict (there have been discussions on that). 

I suspect that what is needed is a half way house that acknowledges both 
positions and offers a Partial Merge (or muddy merge (tm)). This needs a 
method of capturing the 'per person / branch' staged changes, and the final 
'global' octopus, so that the simplified history is one of the single mega 
merge, all done in one magic step, but beneath that is the details of the 
partial merges. 

On Monday, May 16, 2022 at 5:45:20 AM UTC+1 johannes.lipp...@gmail.com 
wrote:

> Very interesting, thank you. Especially that this discussion has been so 
> recent indeed.
>
> So after reading through that thread I had a look at git-merge-octopus.sh 
>  
> itself.
> I understand that it is a design decision to not to make octopus merges 
> with manual conflict resolution easy.
> I still think that that is a petty and that it would be useful.
> On the other hand, implementing it would mean reimplementing 
> git-merge-octopus almost completely.
>
> So I guess I will just hack together a custom solution for me.
> If I should stumble about a solution that can be generalized somewhat 
> easily then I will report back.
>
> Thanks a lot,
> Johannes
>

-- 
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/d0afebca-8078-4df4-b4eb-59aa66ad65aan%40googlegroups.com.

[git-users] Re: How to resolve merge conflicts on octopus merges

[Philip Oakley]

There's a recent discussion thread about octopus merges on the main Git 
List that may be of interest 
https://lore.kernel.org/git/caoltt8s8rh+vycuaqbentmphirqw7hroplfpkxfntjq6bng...@mail.gmail.com/t/#u


On Friday, May 13, 2022 at 12:09:35 PM UTC+1 johannes.lipp...@gmail.com 
wrote:

> (Of course I forgot to attach the attachment)
>
> On Friday, 13 May 2022 at 13:08:34 UTC+2 Johannes Lippmann wrote:
>
>> Hello, 
>>
>> I would like to merge multiple branches in one commit and resolve the 
>> merge conflicts by hand.
>> I was suprised to learn that this doesn't seem to be possible with git 
>> and am looking for a solution.
>>
>> My (simplified) situation is like this:
>>
>> I have a (python) project, versioned with git.
>> It's dependencies with versions are specified in a file called 
>> `pyproject.toml`.
>> There is also a file called `poetry.lock` which holds a lot of stuff, but 
>> also a hash over the project when the dependencies are installed.
>> Calculating this hash can only be done by really installing the packages, 
>> which is somewhat expensive (takes a view seconds).
>>
>> Then there is a bot (dependabot) which will update single packages on a 
>> new branch.
>> This changes both of the files mentioned above.
>> Let's say there are 3 of those dependabot branches: `update-dep-1`, 
>> `update-dep-2` and `update-dep-3`.
>> Now how should I merge them into main?
>>
>> Idea 1: I could merge them one by one. 
>> - `git merge update-dep-1` (no problems)
>> - `git merge update-dep-2` (merge conflict on `poetry.lock`, I have to 
>> regenerate this file)
>> - `git merge update-dep-3` (another merge conflict on `poetry.lock`, I 
>> have to regenerate this file)
>> As you see, I have to do the expensive recalculation n-1 times for n 
>> branches.
>> So this is not a nice workflow.
>>
>> Idea 2: I would like to do an octopus merge:
>> `git merge update-dep-1 update-dep-2 update-dep-3` (with single merge 
>> conflict)
>> I would then regenerate the `poetry.lock` once and be done with it.
>>
>> But unfortunatelly it seems that git wouldn't let me do an octopus merge 
>> where there are conflict.
>>
>> Fast-forwarding to: update-dep-1
>> Trying simple merge with update-dep-2
>> Simple merge did not work, trying automatic merge.
>> Auto-merging poetry.lock
>> ERROR: content conflict in poetry.lock
>> Auto-merging pyproject.toml
>> fatal: merge program failed
>> Automated merge did not work.
>> Should not be doing an octopus.
>> Merge with strategy octopus failed.
>>
>> Does anybody have an idea on how to make this work?
>> I would really like to hear your input on this.
>>
>> Yours,
>> Johannes
>>
>> PS: I have attached a small bash-script to build a minimal example of the 
>> problem,
>> run it in an empty directory.
>> (Of course review it before, you wouldn't run random bash scripts from 
>> strangers, would 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/237f060e-c489-4593-b00b-44d5674de0f2n%40googlegroups.com.

Re: [git-users] graphical interface for git (in Windows OS)

[Philip Oakley]

On 11/05/2022 14:20, Ballin Guillaume wrote:
Why not using git gui/gitk ? Thay are the official graphical interface 
for git and they works perfectly on linux, macos and windows.


I support the git-gui and gitk pair of UI's.

I find that `gitk` (or any of the equivalent commit graph viewers) to be 
quite important for beginners to see how the repository is/can be 
structured with branches, merges and remotes, which is all very 
different to classical configuration management with it's 'single 
blessed master' item view.


It's all very easy to use the `git-gui` to select files, hunks, and 
lines into commits with nice messages in quick succession (etc.), but 
it's easy to miss the complete mind-shift that comes from the Git 
weltanschauung change. It can take a while for that change to sink in, 
so a good viewer helps.


Philip


Le mer. 11 mai 2022 à 15:17, Uwe Brauer  a écrit :


Hi

I am a Linux user and rely on the command line for dealing wit git.
However my students a graphical require a graphical interface. Two
alternatives I found

    1. Sourcetree (that I installed on a MacBook without any trouble),
       however it seems that if you use MS Windows
       (https://www.sourcetreeapp.com/enterprise) you need a bitbucket
       account to use it. However here the idea is to install it on PC
       that are available to all students and don't have single
user. So
       I am not sure what is the best method to install sourcetree in
       such an environment. Any advice is very welcome.

    2. https://tortoisegit.org/download: I am a bit acquainted with
       tortoisehg on linux, but have not idea about it on MS Windows.
       Any comments?

Thanks and regards


Uwe Brauer

-- 
I strongly condemn Putin's war of aggression against the Ukraine.

I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.



--
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/0eb3df3a-b262-e9fc-7f2a-912cb92814db%40iee.email.

[git-users] Re: How to know the push time

[Philip Oakley]

On Tuesday, April 26, 2022 at 3:37:29 AM UTC+1 guangy...@gmail.com wrote:

> I'm a programmer from China, and I have a question when I use git, that I 
> can't get the push time of the code. git seems to only log commit times. 


Internally (locally), git does log all the changes to references (there is 
a config setting) such as branch tips, i.e. the reflogs but these aren't 
normally considered public. (haven't double checked that remotes are 
logged..)
 

> For example, if a colleague of mine commits the code to the local 
> repository on Sunday, and does not push it to the remote repository until 
> next Tuesday. 


That (commit time) is by design. Git is distributed, so control is 
distributed to the user. They can push (publish) at any time they like, 
independent of the time at which the idea/code was recorded (e.g. sign off 
for copyright and all that legal stuff).
 

> As an operation and maintenance, if I pull on Monday, I will not get any 
> updates. Wait until I do a pull on Tuesday and I'll get an update. But I 
> found that git log records the commit time and the date is Sunday.


If you have operational access to the server, or are linked to the server 
owner, you could organise that you get notification, but by design that is 
outside how Git operates - It was designed to support the Linux development 
process, which is far more distributed, open and ad-hoc than most 
organisations.
 

> Unless the developer tells me that he pushes on a Tuesday, I won't know 
> when he pushes. In response to this question, please answer it, or record 
> the push time on git. I think this may be easy to implement and necessary. 


It's not quite as easy as that when the whole eco-system is considered. 
What if the same repo is pushed to many servers (as git.git itself does), 
what time should one record (one at each server, or at source), and which 
one becomes the authoritative value? I could fetch/pull from all of those 
public servers and get identical *content*, but different fetch/pull times 
- as far as the repo's code goes, I don't care what time the fetch/pulls 
happen as long as the content is *identical*  (i.e. the remote refs all 
point at identically the same commit hash).

It may be that the git server capability could provide a last ref update 
time, but someone (you/your employer) would need to propose some code, 
along with a strong rationale that balances security, and all the other 
factors.
 

> Looking forward to your answers. thank you very much.
>

Summary: by design, such times are not considered important.

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/95016858-0ca2-4349-878d-851fc4437896n%40googlegroups.com.

[git-users] Re: GSoC 2022

[Philip Oakley]

These applications should be sent to the g...@vger.kernel.org address. They 
MUST be plain text. Any HTML is treated as spam and deleted...

The list archive is at https://lore.kernel.org/git/?q=GSOC  (pre-queried 
for GSOC ;-)

Philip

On Tuesday, April 19, 2022 at 12:17:52 PM UTC+1 debra...@gmail.com wrote:

> I hope you are doing well. I am a new member to this grroup and would like 
> your input on my proposal below to join one of the Git projects for the 
> GSoC contribution. Kindly review and help me with feedback. Thank you in 
> advance.
>
> SPARSE INDEX FEATURE INTERGRATION 
> 
>
>

-- 
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/11f3af62-8e4d-4805-b71d-27bcac787d4cn%40googlegroups.com.

Re: [git-users] Re: Restoring old version of directory tree with code

[Philip Oakley]

That sounds right. The problem I saw (I was reviewing this earlier) was 
working out my mental model for 'overlay' vs ' no-overlay'.

I think I mapped 'overlay' to 'paint over', so as you checkout a particular 
commit git will overpaint the relevant parts that the new commit has, but 
would leave the parts that have apparently 'gone away' unpainted rather 
than removed.

The no-overlay is like the swapping of drapes and curtains - all the old 
ones go, and the new ones are put up (unless of of course they are an 
unchanged drape/curtain/tapestry).

What git won't do is overwrite or remove anything that wasn't formally 
present in the previous commit as that would be destroying user data like 
an over enthusiastic house cleaner.

So you need to clean the house to airBnB  status before you change the 
decor for the next guests.

Hope that pushed the mental model/analogies/metaphors far enough along ;-)

P.

Mentally I had to swap/invert the overlay statements in the restore man 
page to grasp what it did, rather than what it didn't do.


On Sunday, April 3, 2022 at 10:57:04 PM UTC+1 H wrote:

> On 04/02/2022 03:06 PM, H wrote:
> > On 08/23/2021 06:47 PM, H wrote:
> >> On August 23, 2021 1:47:19 PM EDT, H  wrote:
> >>> On 08/22/2021 07:04 PM, H wrote:
> >>>> On 08/22/2021 04:23 PM, H wrote:
> >>>>> On 08/19/2021 06:08 AM, Philip Oakley wrote:
> >>>>>> Have a look for the `-f|--force` option and the `--no-overlay`
> >>> option (https://git-scm.com/docs/git-checkout), along with the `--
> >>> ` syntax (the `--` is space separated) if it is just a single
> >>> directory from the commit (treeish) that's required.
> >>>>>> There is also the `git reset` command but that can be a blunt
> >>> instrument..
> >>>>>> Hope that helps.
> >>>>>>
> >>>>>> On Thursday, August 19, 2021 at 2:10:03 AM UTC+1 H wrote:
> >>>>>>
> >>>>>> I am a newcomer to git but have read some of the documentation
> >>> and experimented with commits etc. My question, if I want to restore an
> >>> entire directory tree with code from a previous commit in git, how do I
> >>> do that?
> >>>>>> It seems that "git checkout " does not delete
> >>> directories and files in the directory tree that have been created
> >>> since the commit which makes sense. Would I thus need to delete the
> >>> entire directory tree and then use "git checkout " to restore
> >>> everything present in the git commit to achieve the desired result?
> >>>>>> Thanks.
> >>>>>>
> >>>>>> -- 
> >>>>>> 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+...@googlegroups.com
> >>> <mailto:git-users+...@googlegroups.com>.
> >>>>>> To view this discussion on the web visit
> >>> 
> https://groups.google.com/d/msgid/git-users/04e6b1c8-0f3d-4751-8be8-36c61d82b8cbn%40googlegroups.com
> >>> <
> https://groups.google.com/d/msgid/git-users/04e6b1c8-0f3d-4751-8be8-36c61d82b8cbn%40googlegroups.com?utm_medium=email&utm_source=footer
> >.
> >>>>> Thank you, it looks like this is what I need!
> >>>>>
> >>>> Just tried the --no-overlay option and it seems the version of git
> >>> supplied by my operating system, CentOS 7, version 1.8.3.1, does not
> >>> (yet) implement --no-overlay...
> >>>> My understanding is that while --force would overwrite files in the
> >>> directory tree but not remove newly added files/directories not in the
> >>> git archive and hence, not clean up as I would like...
> >>> I found git 2.18 on RH SCL and installed it. Unfortunately that version
> >>> also does not implement --no-overlay... It seems it was added in git
> >>> 2.22.
> >> I found git 2.24 in another repository (IUS) and have installed it so I 
> should now be good to go.
> > It's been a while since the conversation above, I had to spend time on 
> other projects but am now back trying to get the --no-overlay option to 
> work, so far without success...
> >
> > I am running git 2.24.4 and experimenting with a web project. I have 
> made one commit of the master tree, then created a useless fi

[git-users] Re: Bug report

[Philip Oakley]

Oh, also forgot to add that Gmail has been a bit slow for git@vger mail 
because of the quantity being send out to users of gmail. So do send a copy 
to yourself to check that the email has passed through gmail as plain text, 
even if it hasn't shown on the mailing list for gmail recipients.

On Wednesday, March 23, 2022 at 1:35:57 PM UTC Philip Oakley wrote:

> The key element of the bug report email is that it must be in plain text 
> only!  Gmail is notoriously bad for trying to add HTML parts to the email 
> which means that the report will be dumped as spam.
>
> There are various instruction on sending plain text emails on Gmail. "how 
> to send plain text email in gmail"
>
> Philip
>
> The git email archive is available at https://lore.kernel.org/git/
>
>
>
> On Wednesday, March 23, 2022 at 11:15:53 AM UTC pro...@gmail.com wrote:
>
>> I want to file a bug report, I have tried to follow instructions here:
>> https://git-scm.com/community
>>
>> So I have sent an email containing report generated by git bugreport 
>> tool, recepient was g...@vger.kernel.org. However Mail Delivery System 
>> replied message could not be delivered.
>>
>> Any idea what am I doing wrong? How can I file a bug report?
>>
>> 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/ac8fa4be-96bd-445b-96d6-a87c38b681ean%40googlegroups.com.

[git-users] Re: Bug report

[Philip Oakley]

The key element of the bug report email is that it must be in plain text 
only!  Gmail is notoriously bad for trying to add HTML parts to the email 
which means that the report will be dumped as spam.

There are various instruction on sending plain text emails on Gmail. "how 
to send plain text email in gmail"

Philip

The git email archive is available at https://lore.kernel.org/git/



On Wednesday, March 23, 2022 at 11:15:53 AM UTC pro...@gmail.com wrote:

> I want to file a bug report, I have tried to follow instructions here:
> https://git-scm.com/community
>
> So I have sent an email containing report generated by git bugreport tool, 
> recepient was g...@vger.kernel.org. However Mail Delivery System replied 
> message could not be delivered.
>
> Any idea what am I doing wrong? How can I file a bug report?
>
> 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/0f440e1c-8cfb-489d-9b29-c934a8979119n%40googlegroups.com.

[git-users] Re: Two machines, one repo, push errors on second machine when trying to push

[Philip Oakley]

Ahh, I think you have a `Files` view mental model, rather than a `project` 
view mental model.

Git uses the `whole project` mental model, with any separation of changes 
being on different branches.

It sounds like you haven't created a separate branch for each of the 
separate pieces of development (in this case `branches` =~= `refs`), so the 
branch at github (probably using the same name..) already contains the 
machine one changes, and now you want to push different changes (to the 
project) to the same branch, which is the conflict you see.

Try changing (renaming) the machine two branch name e.g `two/name` and then 
push. (this assumes the typical usage where the names at github are the 
same as locally.. but it's totally flexible should you need to total 
brain-explosion).

On Thursday, March 17, 2022 at 3:38:53 PM UTC iot.um...@gmail.com wrote:

> Hi all,
> I'm doing development work on two machines, but distinct folders. From one 
> machine I added/committed/pushed one folder to the repo. That worked fine. 
> From the other machine I used git add . as I had worked in quite a few 
> folders. commit worked fine, but push failed.  
>
> error: failed to push some refs to 'https://github.com/...
> hint: Updates were rejected because the remote contains work that you do 
> not have locally.
>
> There is work not local to the second machine, but it should not be 
> overlapping as what I'm trying to push from second machine. I don't want to 
> do a pull tothe second machine, as I do not know what will be overwritten.
>
> I can totally understand this behavior if the files are overlapping. But 
> not this case. Any ideas what is going wrong or what I am doing wrong? 
> Also, is there a command sequence to allow me to see what files are 
> conflicting?
>
> Many thanks,
> /tom 
>
>

-- 
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/98f5cade-5423-46d1-a4fb-32251cec2b31n%40googlegroups.com.

[git-users] Re: Exclude the master branch sources from a submodule commit ID.

[Philip Oakley]

There are two, maybe three, points here. 

Firstly determine which type of submodules you are using - in particular is 
the submodule's object store part of the main repository, or is it 
separately held in the submodule - it's an implementation detail but 
moderately relevant here. I.e. you need to know where the sub-module's data 
is stored. - what version/os of Git are you on? there has been a lot of 
work on sub-modules that have updated the expectations.

Second, do you need to have the sub-module master branch available for 
other work? If you do you will have the data locally leaving you with a 
problem.

Otherwise look at the 'refspec' for cloning the sub-module - you only want 
to have the secondary branch's details cloned, not everything!

The sub-module ID will be for the secondary branch at the commit you want. 
You may even want to only use a shallow clone with depth=1 when cloning the 
submodule.

There is more about cleaning up the repo if you already have too much in 
your object store and its 'packs'

Philip



On Tuesday, March 15, 2022 at 6:25:25 PM UTC ericfanc...@gmail.com wrote:

> New to git.
>
> We are trying to figure out how we can exclude the master branch sources 
> from a submodule commit ID. We have a repo that has a submodule to another 
> repo but the commit reference is to a branch that only has partial 
> information of the branch.
>
> We are finding out that if we clone the repo, we can go to that submodule 
> without any network connection to the company and extract the master branch 
> of that submodule exposing all the components we already hid behind the 
> different branch.
>
> Anyone know a solution for this, exclude the master branch sources from a 
> submodule commit ID?
>

-- 
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/02c1bf17-6c03-4377-9255-2585de9d40afn%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 fin

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

[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: How to implement WebRTC as a Git Protocol?

[Philip Oakley]

Hi Git Noob,

Supplemental to Konstantin's info, there is further details of the various 
protocols in the 
https://github.com/git/git/tree/master/Documentation/technical directory to 
complement the man pages.

Hope that helps

On Monday, February 21, 2022 at 10:46:45 AM UTC Konstantin Khomoutov wrote:

> On Sat, Feb 19, 2022 at 11:42:33AM -0800, git noob wrote:
>
> > > https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols
> > > https://git-scm.com/book/en/v2/Git-Internals-Transfer-Protocols
> > >
> > > Is there a way to use plumbing commands (internal transfer protocols?) 
> to 
> > > implement your own Git protocol over WebRTC? If you could somehow 
> generate 
> > > all the files necessary to update your Git repository ('git pull') and 
> > > instead of sending them over a standard protocol, you would use WebRTC 
> data 
> > > channels to send that data instead. And on the receiving end, use the 
> > > received files to update your repo.
> > >
> > > Or maybe there already exists a Git-over-WebRTC library?
>
> I do not know of any.
> I also honestly doubt about the suitability of WebRTC for the intended 
> task.
> I mean, not that it will not be able to carry out that task; just I cannot 
> see
> how it will be better at it than what's already there.
>
> > I did find this link about remote helpers and 'git fetch'. Is this what 
> I 
> > should be investigating?:
> > 
> > 
> https://stackoverflow.com/questions/17876132/can-i-create-a-custom-protocol-for-git
>
> You're about to implement something in Git.
> Why, then, are you reading the 'net and StackOverflow instead of the Git's
> source code, which is freely available?
>
> I mean, you would not avoid dealing with it anyway - basically because a
> data transport is never a simple plug-and-play thing: at least the part of 
> the
> code which deals with URLs of remote repositories must be able to tell 
> which
> transport to use from a given URL.
>
> As to implementing a custom transport, it worth building a correct mental
> model of how Git data exchange happens. You should probably start with 
> reading
> manual pages on `git send-pack` and `git receive-pack` programs, and in
> general start with reading the root Git manual page (run `git help git`) 
> and
> especially its section titled "Syncing repositories" which refers to the
> plumbing commands which carry out different ways to exchange data in Git.
>
>

-- 
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/1ccd94d4-8624-403f-823e-3e86fe1cf42fn%40googlegroups.com.

[git-users] Re: What is a git-index/staging area ?

[Philip Oakley]

Git loves to mix the "concept" with the "implementation", with overlaps all 
the way down (e.g. refs and branch names are just a "string of characters", 
but for convenience it started as a file path with the `/` slash delimiters 
..

So. The DirCache/Cache/Index/Staging area are all very similar with 
slightly different levels of misdirection. Importantly (as implementation), 
the Object Store is where all the "content" is located which includes what 
is formally in the repository, what is waiting to be added to the 
repository (staging area) and also all the temporary content.

The Index (implemented as a structured file) is the 'database' of what is 
in the current top level commit, and what is waiting to be committed 
(staged), along with temporary files while merging etc (e.g. for conflicts).

However, in colloquial discussion, the context of the discussion is used to 
indicate which part is being talked about, so when 'staging' (adding) a 
file ready for the next commit, it is "added to the index", as if that's 
all that's in the index. When looking at the current files, we can 'look at 
the index' to see how they compare to the last commit, and for sparse 
checkout, the index keeps a note of which commit objects are really in the 
file system at the moment, and which are still in the object store (because 
they haven't and won't be changed, so no need to 'check them out').

That's my viewpoint any way.

Hope it helps.

On Monday, February 14, 2022 at 2:38:31 AM UTC jaydeep...@gmail.com wrote:

> I have been reading a lot about the git index. Many blogs seem to explain 
> it as some area where the diffs of tracked file gets "staged" for commit. 
> In short, I would the get the general idea that the index is empty 99% of 
> the time and it only gets populated only when I make some changes to a 
> tracked file or make a new un-tracked file.
>
> However, when reading about sparse-index, I got confused again because it 
> seems to explain the index as a place where all of the contents of the 
> repository gets stored.
>
> So which one is the correct one? 
>
> Also, index and staging area are the same thing, right?
>

-- 
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/fbc9ccec-00b5-4d04-8800-3a4b30060cedn%40googlegroups.com.

[git-users] Re: Summer of Code

[Philip Oakley]

Hi Samarth,

For Git, have a look at the details in the https://git.github.io/ pages 
(tabs on left hand side bar) on SoC projects and micro projects. 

The Git mailing list is at https://lore.kernel.org/git/ (along with other 
places). Try search for GSOC and limiting to the last 6 months for the 
current status.

Philip

On Saturday, February 5, 2022 at 5:38:30 PM UTC samarthmay...@nitk.edu.in 
wrote:

> Dear Mentors,
> I'm an undergrad student looking forward to starting my open source 
> journey with GSoC. Thus, could you please give your valuable opinion on 
> what I should do to get started? I have seen the ideas list for 2021, which 
> has been exhausted in 2021 itself, so I don't know how to proceed. Please 
> guide me on what I should do to proceed.
> Thank you,
> Yours Sincerely,
> Samarth Mayya
>

-- 
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/892e93dd-e6f5-4448-8f83-b18844802aedn%40googlegroups.com.

Re: [git-users] [RFC on an idea] Commit Bundles

[Philip Oakley]

 > I understand most of what you said except:
> > But use the rebase/editing on the feature development branch to make 
that look clean (not to hide your mistakes, but to make it easier to 
understand and bug fix later),

Second guessing the parts that need explaining 

Part of the original idea for the "rebase" for the Linux code base, 
particularly the `-i` --interactive mode, is the ability to edit, correct 
and polish your patches (commits) so that what gets recorded in the formal 
project history is each of the small well formed steps of development. This 
is so that maintenance phase (bug fixing) can proceed smoothly and easily, 
no matter who is looking at the history.

Unfortunately (speaking as an old person;-) the proliferation of computer 
storage means many think we should record every key and pencil stroke, 
because because we can (or none at all). Just as we will use an eraser on a 
pencil sketch before we finalise a drawing, we should do the same with our 
commits (neat and tidy submitted work, like a freshly prepared melon, ready 
to eat).  

The tricky bit is we aren't taught formal writing of commits (try looking 
at the git SubmittingPatches file, search for "imperative") 

https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L47 
"Make separate commits for logically separate changes" 

https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L111 
" Describe your changes well" 

Definitely worth a read!



 


On Thursday, January 27, 2022 at 2:59:46 PM UTC shreyanst...@gmail.com 
wrote:

> I understand most of what you said except:
> > But use the rebase/editing on the feature development branch to make 
> that look clean (not to hide your mistakes, but to make it easier to 
> understand and bug fix later),
>
> Thanks for the reply!
> On Thursday, January 27, 2022 at 8:24:37 PM UTC+5:30 philip...@iee.email 
> wrote:
>
>> Use --first-parent log/show when looking at your history to get that 
>> clean "+1 feature" view.
>> But use the rebase/editing on the feature development branch to make that 
>> look clean (not to hide your mistakes, but to make it easier to understand 
>> and bug fix later),
>> and then merge with --no-ff set, adding a full commit message describing 
>> the feature (for the --first-parent log).
>>
>> This gives best of both worlds. You have a clean feature add view, and  
>> clean details for feature debugging (and if you have even a small amount of 
>> 'test driven bug fixing' ;-) then you can also use `git bisect` to locate 
>> (automatic) the _small_ detail commit that introduced the bug that fails 
>> the test.
>>
>> Your one remaining choice is whether to keep rebasing features to the 
>> clean tip of main, or keep them as starting from the original start point 
>> (depends on how you manage the 'conflicts' during feature dev)
>>
>> On Thursday, January 27, 2022 at 6:20:50 AM UTC shreyanst...@gmail.com 
>> wrote:
>>
>>> Even if a branch and a commit bundle occupy the same amount of space, in 
>>> my opinion, commit bundles would appear much cleaner which is the whole 
>>> point of this anyways.
>>>
>>> Thanks
>>> On Thursday, January 27, 2022 at 11:30:58 AM UTC+5:30 Tassilo Horn wrote:
>>>
 Shreyans Jain  writes: 

 Hi, 

 > So I had an idea if git could have a feature that allows you to 
 squash 
 > commits into a commit bundle which keeps the commit history clean 
 > while still maintaining a lot of the important verbose commit 
 > history. Just wanted some comments on this from the community. 

 I think that would create the need for a lot of changes in many places. 
 But you can achieve what you want with what's there already. Say you 
 develop a feature on a branch features/feature-x which you push to 
 origin/features/feature-x. When you are done, you squash the commits on 
 features/feature-x (but don't push), add a note 

 For dev history, see branch features/feature-x. 

 to the commit message, and finally merge features/feature-x (not 
 origin/features/feature-x) into main or wherever it should be. 

 Maybe it would be a good convention to rename the branch so that it is 
 immediately distinguishable from active branches, e.g., to 
 history/features/feature-x (and then link that in the squash commit's 
 message). 

 Bye, 
 Tassilo 

>>>

-- 
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/ff243759-7db2-462c-a03b-16d6b378b836n%40googlegroups.com.

Re: [git-users] [RFC on an idea] Commit Bundles

[Philip Oakley]

Use --first-parent log/show when looking at your history to get that clean 
"+1 feature" view.
But use the rebase/editing on the feature development branch to make that 
look clean (not to hide your mistakes, but to make it easier to understand 
and bug fix later),
and then merge with --no-ff set, adding a full commit message describing 
the feature (for the --first-parent log).

This gives best of both worlds. You have a clean feature add view, and  
clean details for feature debugging (and if you have even a small amount of 
'test driven bug fixing' ;-) then you can also use `git bisect` to locate 
(automatic) the _small_ detail commit that introduced the bug that fails 
the test.

Your one remaining choice is whether to keep rebasing features to the clean 
tip of main, or keep them as starting from the original start point 
(depends on how you manage the 'conflicts' during feature dev)

On Thursday, January 27, 2022 at 6:20:50 AM UTC shreyanst...@gmail.com 
wrote:

> Even if a branch and a commit bundle occupy the same amount of space, in 
> my opinion, commit bundles would appear much cleaner which is the whole 
> point of this anyways.
>
> Thanks
> On Thursday, January 27, 2022 at 11:30:58 AM UTC+5:30 Tassilo Horn wrote:
>
>> Shreyans Jain  writes:
>>
>> Hi,
>>
>> > So I had an idea if git could have a feature that allows you to squash
>> > commits into a commit bundle which keeps the commit history clean
>> > while still maintaining a lot of the important verbose commit
>> > history. Just wanted some comments on this from the community.
>>
>> I think that would create the need for a lot of changes in many places.
>> But you can achieve what you want with what's there already. Say you
>> develop a feature on a branch features/feature-x which you push to
>> origin/features/feature-x. When you are done, you squash the commits on
>> features/feature-x (but don't push), add a note
>>
>> For dev history, see branch features/feature-x.
>>
>> to the commit message, and finally merge features/feature-x (not
>> origin/features/feature-x) into main or wherever it should be.
>>
>> Maybe it would be a good convention to rename the branch so that it is
>> immediately distinguishable from active branches, e.g., to
>> history/features/feature-x (and then link that in the squash commit's
>> message).
>>
>> Bye,
>> Tassilo
>>
>

-- 
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/b6a6529f-1dd2-43eb-9afb-536b5dee38d7n%40googlegroups.com.

Re: [git-users] Re: Try to reproduce a sample repository according History Simplification section of git log

[Philip Oakley]

Thanks for the test repo. some notes.

When I looked at it using `gitk` (with options), it generally got things 
right, but it looks like the gui's don't always do the simplifications.

What I did notice was the tendency to need the --graph option to see the 
history simplification. 

I do admit that history simplification is an area I hadn't studied (but was 
interested in). 

Try `git log --oneline --graph --full-history -- foo`
`git log --oneline --graph --full-history --parents -- foo`
'git log --oneline --graph -- foo`

etc.

I also find "rev-list, what is it doing?" to be confusing (In parts I still 
am learing).

One 'hidden in plain view' is that the revlist has an order, and it's only 
when we add --graph to a log that we start to see some of the 
interconnectedness.

Some notes I made..
"history re-writing"

the magic example is at
https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L386-L425

--graph #L1119  **note how far down the document this is!
#L1126 This enables parent rewriting, see 'History Simplification' above. 


#L427-429 `rev-list` walks backwards through history, including or excluding
commits based on whether `--full-history` and/or parent rewriting
(via `--parents` or `--children`) are used.

** that's not `--min-parents` etc that's used for `--merges` #L104-131

#L453-455 Parent/child relations are only visible with `--parents`, but 
that does
not affect the commits selected in default mode, so we have shown the
parent lines.


#L472-474 Note that without parent rewriting, it is not really possible to 
talk
about the parent/child relationships between the commits, so we show
them disconnected.

%%#L457 --full-history (without parent rewriting)::  %% extra ()
%%#L476 --full-history (with parent (--graph) rewriting)::  %% extra (), 
extra (--graph)

Summary Question: were you investigating via a GUI tool, or via the command 
line?

On Monday, January 17, 2022 at 6:39:47 AM UTC chuc...@gmail.com wrote:

> According the documentation , when show full history with parent 
> rewriting, the commit C is excluded, as it's TREESAME to parent commit I. 
> The TREESAME means the commit C does not touch the foo file. So I think the 
> commit C is an empty commit with change.  
> [image: firefox_2022-01-17_14-32-50.png]
>
> The log graph of foo file in my sample repository is same as the 
> documentation mentioned above
> [image: TortoiseGitProc_2022-01-17_14-35-53.png]
>
> However it seems there is no clarified definition about the parent 
> rewriting.  and the command about show full history without parent 
> rewriting is not mentioned.
>
> On Saturday, January 15, 2022 at 7:10:20 PM UTC+8 philip...@iee.email 
> wrote:
>
>> I think " The commit c was made with empty change, git commit 
>> --allow-empty!" isn't a correct reading of the docs. 
>>
>>
>> https://github.com/ChuckTest/git-history-test/blob/de6543aca0c16e4740a8834f4df23894bea5d776/foo
>>
>> As noted earlier, my reading of the text is that file foo should have 
>> changed to contain 'foo', from it's former 'asdf'.
>>
>> That said, I haven't tried too hard to cross check, and do agree that 
>> having a reference repo would be a help.
>>
>>
>> On Saturday, January 15, 2022 at 10:29:39 AM UTC chuc...@gmail.com wrote:
>>
>>> Finally, I  made a sample repository 
>>> https://github.com/ChuckTest/git-history-test.
>>> The commit c was made with empty change, git commit --allow-empty
>>> And the TREESAME only consider file foo, if you do not modify the 
>>> content of foo and make a new commit, then it's TREESAME for file foo.
>>>
>>>
>>> The default mode with command  "git log --decorate --oneline --graph foo"
>>> full history with command "git log --decorate --oneline --graph 
>>> --full-history foo"
>>>
>>> The question would be which command to show "--full-history without 
>>> parent rewriting", have no idea which command can do this.
>>>
>>> On Friday, January 14, 2022 at 7:36:23 PM UTC+8 philip...@iee.email 
>>> wrote:
>>>
 The text itself is at 
 https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L386-L425,
  
 should you wish to try making it clearer.

 Unfortunately, there isn't a sample repo that contains the various 
 examples that are in the documentation. There are one or two that are 
 hidden in the test suite, but this doesn't appear to be one of them.

 How would you update the documentation to make it more useful to folks 
 like yourself trying to understand what is going on? Try posting here and 
 folks can help with preparing some patches to improve things.

 Philip

 On Friday, January 14, 2022 at 9:34:12 AM UTC Konstantin Khomoutov 
 wrote:

> On Thu, Jan 13, 2022 at 05:57:24PM -0800, Chuck Lu wrote: 
>
> >>> https://git-scm.com/docs/git-log#_history_simplification 
> >>> As there is no change, then how can I make a commit C? 
> >>> [image: firefox_2022-01-13_19-46-27.png] 
> >

Re: [git-users] Re: Try to reproduce a sample repository according History Simplification section of git log

[Philip Oakley]

I think " The commit c was made with empty change, git commit 
--allow-empty!" isn't a correct reading of the docs. 

https://github.com/ChuckTest/git-history-test/blob/de6543aca0c16e4740a8834f4df23894bea5d776/foo

As noted earlier, my reading of the text is that file foo should have 
changed to contain 'foo', from it's former 'asdf'.

That said, I haven't tried too hard to cross check, and do agree that 
having a reference repo would be a help.


On Saturday, January 15, 2022 at 10:29:39 AM UTC chuc...@gmail.com wrote:

> Finally, I  made a sample repository 
> https://github.com/ChuckTest/git-history-test.
> The commit c was made with empty change, git commit --allow-empty
> And the TREESAME only consider file foo, if you do not modify the content 
> of foo and make a new commit, then it's TREESAME for file foo.
>
>
> The default mode with command  "git log --decorate --oneline --graph foo"
> full history with command "git log --decorate --oneline --graph 
> --full-history foo"
>
> The question would be which command to show "--full-history without 
> parent rewriting", have no idea which command can do this.
>
> On Friday, January 14, 2022 at 7:36:23 PM UTC+8 philip...@iee.email wrote:
>
>> The text itself is at 
>> https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L386-L425,
>>  
>> should you wish to try making it clearer.
>>
>> Unfortunately, there isn't a sample repo that contains the various 
>> examples that are in the documentation. There are one or two that are 
>> hidden in the test suite, but this doesn't appear to be one of them.
>>
>> How would you update the documentation to make it more useful to folks 
>> like yourself trying to understand what is going on? Try posting here and 
>> folks can help with preparing some patches to improve things.
>>
>> Philip
>>
>> On Friday, January 14, 2022 at 9:34:12 AM UTC Konstantin Khomoutov wrote:
>>
>>> On Thu, Jan 13, 2022 at 05:57:24PM -0800, Chuck Lu wrote: 
>>>
>>> >>> https://git-scm.com/docs/git-log#_history_simplification 
>>> >>> As there is no change, then how can I make a commit C? 
>>> >>> [image: firefox_2022-01-13_19-46-27.png] 
>>> >> Commit C is to be compared to I. 
>>> >> 
>>> >> In `I` foo contains "asdf" 
>>> >> In `C` foo contains "foo" as described under 'A' (same as B, same as 
>>> C...) 
>>> >> so a confusion about the english way of describing and the graphical 
>>> >> expectation. 
>>> >> At least that's what I'm thinking. 
>>> [...] 
>>> > Yes, I know that C compare with I, and the description C does not 
>>> change 
>>> > foo, the foo is in red color, which means the C does not change file 
>>> foo. 
>>> > The content in file foo should keep the same as I which is "asdf". 
>>> It's 
>>> > really awful to read the documentation. 
>>> > Anyway, thanks for your help, I will try to reproduce a repository 
>>> with 
>>> > your explanation. 
>>> > 
>>> > Does anyone know who wrote this terrible documentation? If it is 
>>> possible, 
>>> > I would like to communicate with him/her directly. 
>>>
>>> The docs are written by the developers theirselves (the project is run 
>>> by a 
>>> volunteers, and AFAIU they don't have a dedicated technical writer in 
>>> the 
>>> team, and never had). You can contact the devs by posting a mail to the 
>>> developers' list - please be sure to read [1]. 
>>>
>>> Just in case, I urge you to be constructive: since Git is a volunteer 
>>> project, 
>>> and a piece of F/OSS, you got it for free, have full access to its 
>>> source 
>>> code - which includes the sources of the docs - and, as usual in such 
>>> cases, 
>>> the Git devs are not under any obligation to maintain whatever level of 
>>> quality 
>>> of their product. Hence you cannot sensibly demand anything from them - 
>>> at 
>>> best, your claims will be silently dismissed; what you could - and 
>>> should - 
>>> do instead is to propose ways to improve the docs: usually this is made 
>>> in 
>>> four steps: you offer the changes, discuss them, then post the patches, 
>>> then 
>>> they are reviewed, which might require multiple backs-and-forths to get 
>>> completed. 
>>>
>>> 1. 
>>> 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/f4e9f236-6734-4e91-9ef4-c7d8e0dcd64dn%40googlegroups.com.

[git-users] Re: Doubts regarding git codebase

[Philip Oakley]

I've just prepared  a small patch for the Git README.md for submission to 
the project using https://github.com/gitgitgadget/git/pull/1115

The main Git project is in the rc (release candidate phase) so it may not 
be included in the next release.
On Thursday, January 13, 2022 at 6:49:17 PM UTC Philip Oakley wrote:

> The codebase is C89, with just a few C99 items. Make sure that your linter 
> is able to play well with old style 'dumb' (cautiously basic) coding styles.
>
> Its worth reading the https://github.com/git/git/blob/master/README.md 
> for the links to the 
> https://github.com/git/git/blob/master/Documentation/SubmittingPatches 
> and https://github.com/git/git/blob/master/Documentation/CodingGuidelines 
> (which should be mentioned ;-)
>
> Do you have one or two particular examples from the linter?
>
> If you are able to provide translations of error messages there is a 
> companion project seehttps://
> github.com/git/git/blob/master/Documentation/SubmittingPatches#L421-L425 
> and https://github.com/git-l10n/git-po/blob/master/po/README.md
> On Thursday, January 13, 2022 at 4:54:34 PM UTC jaydeep...@gmail.com 
> wrote:
>
>> I want to contribute to git but I have some doubts regarding their 
>> codebase.
>>
>>
>>1. My ccls linter is picking a lot of syntax errors on the 
>>codebase(there are no errors/warnings on compilation though). Is the 
>>codebase based on C99? Because most the errors end in `invalid in C99`
>>2. Since I am just a beginner, I want to start with something simple. 
>>Currently the error messages in git for some commands are not that 
>> verbose. 
>>I want to improve the error messages. Where should I start?
>>
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/c2eda95f-a2a6-4dcd-aa44-d2d5c91482c6n%40googlegroups.com.

Re: [git-users] Re: Try to reproduce a sample repository according History Simplification section of git log

[Philip Oakley]

The text itself is at 
https://github.com/git/git/blob/master/Documentation/rev-list-options.txt#L386-L425,
 
should you wish to try making it clearer.

Unfortunately, there isn't a sample repo that contains the various examples 
that are in the documentation. There are one or two that are hidden in the 
test suite, but this doesn't appear to be one of them.

How would you update the documentation to make it more useful to folks like 
yourself trying to understand what is going on? Try posting here and folks 
can help with preparing some patches to improve things.

Philip

On Friday, January 14, 2022 at 9:34:12 AM UTC Konstantin Khomoutov wrote:

> On Thu, Jan 13, 2022 at 05:57:24PM -0800, Chuck Lu wrote:
>
> >>> https://git-scm.com/docs/git-log#_history_simplification
> >>> As there is no change, then how can I make a commit C?
> >>> [image: firefox_2022-01-13_19-46-27.png]
> >> Commit C is to be compared to I. 
> >>
> >> In `I` foo contains "asdf"
> >> In `C` foo contains "foo" as described under 'A' (same as B, same as 
> C...) 
> >> so a confusion about the english way of describing and the graphical 
> >> expectation.
> >> At least that's what I'm thinking.
> [...]
> > Yes, I know that C compare with I, and the description C does not change 
> > foo, the foo is in red color, which means the C does not change file 
> foo. 
> > The content in file foo should keep the same as I which is "asdf". It's 
> > really awful to read the documentation.
> > Anyway, thanks for your help, I will try to reproduce a repository with 
> > your explanation.
> > 
> > Does anyone know who wrote this terrible documentation? If it is 
> possible, 
> > I would like to communicate with him/her directly.
>
> The docs are written by the developers theirselves (the project is run by a
> volunteers, and AFAIU they don't have a dedicated technical writer in the
> team, and never had). You can contact the devs by posting a mail to the
> developers' list - please be sure to read [1].
>
> Just in case, I urge you to be constructive: since Git is a volunteer 
> project,
> and a piece of F/OSS, you got it for free, have full access to its source
> code - which includes the sources of the docs - and, as usual in such 
> cases,
> the Git devs are not under any obligation to maintain whatever level of 
> quality
> of their product. Hence you cannot sensibly demand anything from them - at
> best, your claims will be silently dismissed; what you could - and should -
> do instead is to propose ways to improve the docs: usually this is made in
> four steps: you offer the changes, discuss them, then post the patches, 
> then
> they are reviewed, which might require multiple backs-and-forths to get
> completed.
>
> 1. 
> 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/ca3539a5-d4f3-4b8a-9a49-e27a1bece701n%40googlegroups.com.

[git-users] Re: Doubts regarding git codebase

[Philip Oakley]

The codebase is C89, with just a few C99 items. Make sure that your linter 
is able to play well with old style 'dumb' (cautiously basic) coding styles.

Its worth reading the https://github.com/git/git/blob/master/README.md for 
the links to the 
https://github.com/git/git/blob/master/Documentation/SubmittingPatches and 
https://github.com/git/git/blob/master/Documentation/CodingGuidelines 
(which should be mentioned ;-)

Do you have one or two particular examples from the linter?

If you are able to provide translations of error messages there is a 
companion project 
seehttps://github.com/git/git/blob/master/Documentation/SubmittingPatches#L421-L425
 
and https://github.com/git-l10n/git-po/blob/master/po/README.md
On Thursday, January 13, 2022 at 4:54:34 PM UTC jaydeep...@gmail.com wrote:

> I want to contribute to git but I have some doubts regarding their 
> codebase.
>
>
>1. My ccls linter is picking a lot of syntax errors on the 
>codebase(there are no errors/warnings on compilation though). Is the 
>codebase based on C99? Because most the errors end in `invalid in C99`
>2. Since I am just a beginner, I want to start with something simple. 
>Currently the error messages in git for some commands are not that 
> verbose. 
>I want to improve the error messages. Where should I start?
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/434260c7-1b7d-4641-b740-15121d6e077en%40googlegroups.com.

[git-users] Re: Try to reproduce a sample repository according History Simplification section of git log

[Philip Oakley]

Commit C is to be compared to I. 

In `I` foo contains "asdf"
In `C` foo contains "foo" as described under 'A' (same as B, same as C...) 
so a confusion about the english way of describing and the graphical 
expectation.
At least that's what I'm thinking.

 

On Thursday, January 13, 2022 at 11:59:10 AM UTC chuc...@gmail.com wrote:

> https://git-scm.com/docs/git-log#_history_simplification
> As there is no change, then how can I make a commit C?
> [image: firefox_2022-01-13_19-46-27.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/c14d0a5c-7c27-4ee7-bf74-426a1787edf5n%40googlegroups.com.

Re: [git-users] Need help....locked out

[Philip Oakley]

The main question to Robert, is whether he can access his general GitHub 
account via a web browser. My expectation was that login step did not need 
ssh.

If Robert can login to his account (Confirmation needed), then he can 
update/replace his ssh keys (generate new ones).

On Sunday, January 2, 2022 at 6:49:48 PM UTC Chris Stone wrote:

> On my phone so I can't include links easily. However I used the link 
> provided earlier and went to 2fa under authentication. Even on the about 
> 2fa and recovery articles it states due to security concerns GitHub support 
> may not be able to help
>
> On Sun, Jan 2, 2022, 11:19 AM Philip Oakley  wrote:
>
>> I thought that the basic Github login (password and 2FA codes) was 
>> separate from the ssh key stuff.
>>
>> There is a support page link 
>> <https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/reviewing-your-ssh-keys>
>>  
>> on managing ssh keys suggesting that you could delete all old or 
>> compromised keys down to zero active keys, and start afresh with new ssh 
>> keys, but I could be mistaken (off by one..).
>>
>> Did you get (download) any recovery codes in the past... and still have 
>> them available.. ?  
>>
>> I'd contact GitHub support before you get doubly locked out by trying too 
>> hard to look like someone hacking in ;-)
>>
>> On Sunday, January 2, 2022 at 5:32:04 AM UTC Chris Stone wrote:
>>
>>> Never used 2fa on GitHub. However it does make sense. I do know you'd 
>>> have to generate a new ssh key before you can access your repo via ssh 
>>> since you lost the old one
>>>
>>> On Sat, Jan 1, 2022, 10:02 PM robert kugler  wrote:
>>>
>>>> As a newbie to git, i am having trouble getting in to my github account.
>>>> I have had a majoe computer hardware failure, and had to build a new 
>>>> computer with ubuntu 20.
>>>> I have lost my github password, and the private ssh key from the old 
>>>> computer is gone.
>>>> I try to log into github using firefox V95.0.1.
>>>> I click "forgot password" on github and get an email link to reset my 
>>>> password.
>>>> when I get a password reset email from GitHub, the 2FA requires a 
>>>> validation code.
>>>> I have a github authentication app on my phone, and it does give me a 
>>>> nvalidation code, but that code does not ever work.
>>>> I am wondering if it has something to do wirh my using a freshly 
>>>> rebuilt system, which may not have the same ssh key as the old system, but 
>>>> I am not sure.
>>>> Can anyone help me with this?
>>>> Thanks,
>>>> Bob
>>>>
>>>> -- 
>>>> 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+...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/git-users/62a84b7d-628e-4145-88b0-49f45f3d715cn%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/git-users/62a84b7d-628e-4145-88b0-49f45f3d715cn%40googlegroups.com?utm_medium=email&utm_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+...@googlegroups.com.
>>
> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/git-users/0e72150d-b269-4cbf-88ca-6224768d62b2n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/git-users/0e72150d-b269-4cbf-88ca-6224768d62b2n%40googlegroups.com?utm_medium=email&utm_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/2f99536f-a7ef-42db-9197-aaaccdee8b8en%40googlegroups.com.

Re: [git-users] Need help....locked out

[Philip Oakley]

I thought that the basic Github login (password and 2FA codes) was separate 
from the ssh key stuff.

There is a support page link 

 
on managing ssh keys suggesting that you could delete all old or 
compromised keys down to zero active keys, and start afresh with new ssh 
keys, but I could be mistaken (off by one..).

Did you get (download) any recovery codes in the past... and still have 
them available.. ?  

I'd contact GitHub support before you get doubly locked out by trying too 
hard to look like someone hacking in ;-)

On Sunday, January 2, 2022 at 5:32:04 AM UTC Chris Stone wrote:

> Never used 2fa on GitHub. However it does make sense. I do know you'd have 
> to generate a new ssh key before you can access your repo via ssh since you 
> lost the old one
>
> On Sat, Jan 1, 2022, 10:02 PM robert kugler  wrote:
>
>> As a newbie to git, i am having trouble getting in to my github account.
>> I have had a majoe computer hardware failure, and had to build a new 
>> computer with ubuntu 20.
>> I have lost my github password, and the private ssh key from the old 
>> computer is gone.
>> I try to log into github using firefox V95.0.1.
>> I click "forgot password" on github and get an email link to reset my 
>> password.
>> when I get a password reset email from GitHub, the 2FA requires a 
>> validation code.
>> I have a github authentication app on my phone, and it does give me a 
>> nvalidation code, but that code does not ever work.
>> I am wondering if it has something to do wirh my using a freshly rebuilt 
>> system, which may not have the same ssh key as the old system, but I am not 
>> sure.
>> Can anyone help me with this?
>> Thanks,
>> Bob
>>
>> -- 
>> 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+...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/git-users/62a84b7d-628e-4145-88b0-49f45f3d715cn%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/0e72150d-b269-4cbf-88ca-6224768d62b2n%40googlegroups.com.

[git-users] Re: How to print out a git repo (local)

[Philip Oakley]

An interesting question, but maybe not quite as clear as to what is 
desired. 


   - Are you just looking for a print out of the files in the final commit 
   - the finished project?
   - Are you looking for a listing of all the commits (headline/subject) 
   from the very beginning to the final commit?
   - Are you looking for the commit messages as well that explain every 
   step?
   - With each of the diff's for each explained commits?

Some of your answer will depend on how you managed the repos workflow, such 
as having strong summary merge commits, or making sure that all the 
temporary 'wip' commits had been rebased away. You may have had at least 
some good tags that summarise major releases (relatively easy to list..).

If it's just some formal summary document you need to tick a box for 
quality control then it (the readable summary) doesn't need doing well ;-) 

The main part will be to bundle whole repo and save that away as a 
'compressed attachment' which will allow the complete repo to be recreated. 
You may need to prune the remote refs and temporary branches before using 
--all to ensure you have the minimum of extraneous crud in the bundle 
(--all gets all the crud refs and everything..)


On Wednesday, December 22, 2021 at 3:05:25 PM UTC David McMurrey wrote:

> I have  looked and looked to see how we can print out or display the 
> contents of a local repo. I thought git-cat was the answer then git print 
> origin. 
>
> When we have finished a git project, we need to display it as a regular 
> document. How is that done?
>
> -- David
>

-- 
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/a6a966f8-a373-4a7a-8c84-4514376ff85bn%40googlegroups.com.

[git-users] Re: Make git aware of which machine did the git commits ?

[Philip Oakley]

Set up different 'username' on the two machines (or committer / author 
difference, etc).

Why does it matter?

On Sunday, December 5, 2021 at 3:53:08 AM UTC skybu...@hotmail.com wrote:

> Hello,
>
> Right now I am working with git on two different machines:
> Windows 7 on real hardware.
> Windows 11 on a virtual machine.
>
> It would be cool if git could be made aware somehow on which machine the 
> commits were made ?
>
> Right now the windows 7 machine uses Skybuck Flying
> Right now the windows 11 machine uses my e-mail addres ???
>
> So that is my second less important question why is windows 11 using my 
> e-mail and not my github account ? Hmmm... now github stats are kinda 
> ruined a bit...
>
> Is there still a way to correct that ?
>
> Would be cool if both can be done.
>
> Bye for now,
>   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/14fe69ba-834f-4fde-beb2-93d7a5b0a020n%40googlegroups.com.

Re: [git-users] GITK: Useability issue, can't scroll through fie list ?

[Philip Oakley]

> 1. git gui does not have a link to gitk ? 
Use the top left  menu: Repository >> Visualise .. for the two gitk viewer 
options.

> _3_. clicking on right bottom view where it says "path"[sic] "tree" does 
not make gitk context aware. 

The gitk Patch[!] / Tree options will swap what is being displayed in the 
two bottom windows.

* for Patch the right hand side lists just the commit/'comment' file and 
the files which have diffs (changes).
The left hand window then shows those diffs and commit comment. Clicking an 
item in the right hand pane will make the left pane jump to the required 
place.

* for Tree, the righ hand side panels lists the full file tree that is 
present in the commit snapshot, with the commit comment at the top. 
Directories has a small blue triangle and can be expanded by clicking the 
triangle - watch where the 'arrow' of the triangle points.
Having selected a file/item in the right hand window, the left hand window 
then will display that selected file as a full raw text. Useful if the diff 
context isn't sufficient in Patch mode.

HTH.
Philip

On Thursday, December 2, 2021 at 10:07:39 AM UTC Konstantin Khomoutov wrote:

> On Wed, Dec 01, 2021 at 09:55:38PM -0800, skybuck2000 wrote:
>
> > I see two issues right now:
>
> [...]
>
> Please stop reporting bugs on this list.
>
> As I've suggested several times before, this list is dedicated to help
> inexperienced Git users solve the problems they have when using Git.
>
> Discussing usability issues or apparent bugs is just pointless here for the
> two reasons: 1) this list is not read by Git developers (who could try to 
> fix
> the code), and 2) no one else is going to report bugs for you.
>
> Please re-read .
>
>
> Oh, and while we're at it, one more kind request: please stop posting
> identical e-mails to both git-users and git-for-windows. Again, as I've
> suggested elsewhere, the former list is for discussing basic _generic_
> problems with Git - no matter which flavour it is and on which platform it
> runs on, - and the latter is for solving problems specific to Windows and
> Git-for-Windows as the de-facto standard ongoing port of Git to that 
> platform.
>
>

-- 
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/58f1006c-e53e-4b21-a5c2-a4350ca6c4bdn%40googlegroups.com.

Re: [git-users] Re: Command to display current branch tracking information ?

[Philip Oakley]

> Can this command be set up as an alias ? This would require to pass a 
parameter somehow ? 

yes it can be an alias, but because the branch name is inserted in the 
command line it need to be a shell alias passing in the branch name as $1.


On Thursday, December 2, 2021 at 11:30:49 AM UTC Philip Oakley wrote:

> > Sorry but what is {u} supposed to be? The url of the remote server? 
>
> The '@{u}' is a shorthand for '@{upstream}' typed exactly, that modifies 
> the given branch name to become the upstream of the given branch, and then 
> rev-parse finds its pretty name, and abbrev-ref trims off the leading part 
> of the "ref/./.". 
>
> Worth looking up "@" and its qualifiers ;-) 
>
> On Thursday, December 2, 2021 at 7:45:33 AM UTC o...@ucm.es wrote:
>
>> >>> "PO" == Philip Oakley  writes:
>>
>> > git rev-parse --abbrev-ref --symbolic-full-name @{u}
>> > Had to look it up yesterday. Then you need
>>
>> Sorry but what is {u} supposed to be? The url of the remote server?
>>
>> I tried out 
>> git rev-parse --abbrev-ref --symbolic-full-name master@{git+ssh://
>> o...@git.code.sf.net/p/matlab-emacs/src 
>> <http://o...@git.code.sf.net/p/matlab-emacs/src>}
>>
>> Or 
>>
>> git rev-parse --abbrev-ref --symbolic-full-name master@{origin}
>>
>> None worked. I surely missed something essential.
>>
>

-- 
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/75776565-1e78-41b9-afd9-388bc430d58en%40googlegroups.com.

Re: [git-users] Re: Command to display current branch tracking information ?

[Philip Oakley]

> Sorry but what is {u} supposed to be? The url of the remote server? 

The '@{u}' is a shorthand for '@{upstream}' typed exactly, that modifies 
the given branch name to become the upstream of the given branch, and then 
rev-parse finds its pretty name, and abbrev-ref trims off the leading part 
of the "ref/./.". 

Worth looking up "@" and its qualifiers ;-) 

On Thursday, December 2, 2021 at 7:45:33 AM UTC o...@ucm.es wrote:

> >>> "PO" == Philip Oakley  writes:
>
> > git rev-parse --abbrev-ref --symbolic-full-name @{u}
> > Had to look it up yesterday. Then you need
>
> Sorry but what is {u} supposed to be? The url of the remote server?
>
> I tried out 
> git rev-parse --abbrev-ref --symbolic-full-name master@{git+ssh://
> o...@git.code.sf.net/p/matlab-emacs/src 
> <http://o...@git.code.sf.net/p/matlab-emacs/src>}
>
> Or 
>
> git rev-parse --abbrev-ref --symbolic-full-name master@{origin}
>
> None worked. I surely missed something essential.
>

-- 
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/0e58eb21-9368-477f-94e8-2817546b2b54n%40googlegroups.com.

[git-users] Re: Command to display current branch tracking information ?

[Philip Oakley]

 git rev-parse --abbrev-ref --symbolic-full-name @{u}

Had to look it up yesterday. Then you need

git remote -v   # or -vv

to find out where that remote really is!
- I have 10 remotes for variations of 'git' itself, including "my" which is 
my publish remote.

On Wednesday, December 1, 2021 at 2:51:06 PM UTC skybu...@hotmail.com wrote:

> It would be usefull if there was a command to see the tracking information 
> for the current branch, if any.
>
> Right now I am trying to figure out if any tracking is set for the local 
> branch to some kind of remote branch.
>
> There does not seem to be a command for it ?
>
> I know there are other commands to display all: git branch -vv
>
> However if the number of branches become very large, I may end up having 
> to search through such a list.
>
> Displaying such a huge list also distracts from the rest of the git 
> command flow.
>
> So something more tiny would be appreciated.
>
> Bye for now,
>   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/56540eb6-ed1b-4701-a69c-03dea549f38an%40googlegroups.com.

[git-users] Re: Rebase documentation is not clear enough.

[Philip Oakley]

'Documentation' is a tricky subject. Are the manuals for reference (i.e. 
looking up the specifics that you already understand) or for education, or 
training, or for examples, or concepts, philosophy and mental models, etc. 

At the moment they (man pages) are primarily for reference, rather than 
explanation and education, while the git-scm book comes from a different 
direction.

I'd agree that rebasing, and the man page, are tricky to navigate, and 
sometimes require extra coding or investigation to determine, for example 
commit-id ranges.

The first main concept to get / understand is "upstream" (and if it's the 
same as your "publish" repo). You may find that your use case deviates to 
the 'expected' approach [I've just been there!]. Then it's identify the 
three IDs approach, along wit the `-i` interactive check.

P.

On Tuesday, November 30, 2021 at 3:55:27 PM UTC skybu...@hotmail.com wrote:

> https://git-scm.com/book/en/v2/Git-Branching-Rebasing
>
> I believe git rebase must be done from the branch which is to be re-based.
>
> So it's always necessary to git switch 
>
> It is not possible to go to git switch 
>
> and then do git rebase  etc
>
> This will not work and go wrong correct ?!?
>
> If so, then the documentation at this link is not clear:
>
> https://git-scm.com/book/en/v2/Git-Branching-Rebasing
>
> There are some re-base commands without a clear git switch 
> 
>
> This makes it seems like it's possible to issue this command from any 
> branch.
>
> Documentation should be updated and make clear that user has to been on 
> the branch that is to be rebased.
>
> 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/1ccf4ac7-aa82-4798-9613-44578193437fn%40googlegroups.com.

[git-users] Re: GSOC

[Philip Oakley]

Hi, The Git GSOC is coordinated through the main Git Developers List (plain 
text email). 
The 'primary' searchable archive is at https://lore.kernel.org/git/
Git, like Linux is coded, in the main, in C89/99.

Maybe start at 
https://lore.kernel.org/git/20352639-deaa-0e3f-c99e-9bde937d6...@gmail.com/ 
for links to the 2021 GSOC.

Philip

On Thursday, November 25, 2021 at 7:01:02 AM UTC ashishge...@gmail.com 
wrote:

> Hello,
> As from today for GSOC 22 we have approx 7 months. As being now in the 
> first year can you guide how to use the period effectively and which 
> language is be most effective means being means from a Javascript, Java, 
> python C++ has a greater chance to get selected. I have a knowledge of data 
> science and machine learning(basic to moderate level) and moderate 
> knowledge of web dev and frontend. And I am a fast learner and i go in 
> depth or try something new as  I have a long span
> I can learn anything because I am confident please don't turn away because 
> Im a first year student.
> Everyone can learn but If there is a mentor to make the students to follow 
> the right path it can create wonders.
> thank you
> waiting for your reply!!!
>

-- 
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/45d6b383-5c87-411a-97a4-1d1f15d6fdfen%40googlegroups.com.

[git-users] Re: Security Issue : Commit with any other user's email

[Philip Oakley]

A similar confusion occurred on the main Git list very recently 
(https://lore.kernel.org/git/710dc612-0e3f-bf10-b123-f9443e605...@gmail.com/). 


There are three types user 'security going on here/there.:
1. SSH security across the link between server and user
2. 'username & email' for the "signed-off-by:" annotation in commits, if 
required - an assertion of legal authority to contribute
3. PGP style cryto signature - the association of the particular text with 
the particular user key.

Your config error matches the type 2 legal 'security' and is a human, less 
precise, standard of identity, as would be established in a law court. If 
you are able to correct your config and amend your commits, then that would 
be ideal, but sometimes your commits have escaped into the wild, but folks 
still (in general) know it is you.

Hope that helps (HTH)

On Wednesday, November 24, 2021 at 1:36:55 PM UTC bisht.a...@gmail.com 
wrote:

> Hey there, I'm Ayush. I'm using git since 2 years and today I found an 
> issue. 
> I was cloning a repo with SSH key, and after that I  locally config that 
> repo with an email. But the problem is that, I have entered the wrong email 
> which  belongs to an account. So when I committed some changes  , I found 
> that  the commit was done by that user (with that wrong email ) on that 
> repo. at github. 
>
> I think it should not be the case.
> I want to know more about this, and if it needs to  fix then I would love 
> to work with you. 
>
>
> how I encountered the issue:
>
>1. git clone git@some_repo
>2. cd repo
>3. git config --local user.email "someone_email"
>4. git checkout -b branch/dev
>5. # make some changes
>6. git add .
>7. git commit -m "first commit"
>8. git push origin branch/dev
>
>
> Thanks
>

-- 
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/2e37e276-16c3-4f33-bd88-05a451e03c84n%40googlegroups.com.

[git-users] Re: trouble syncing terminal

[Philip Oakley]

This sounds like you need, next, to look at the use of "Remotes". 

Remotes are other computers to the _one_ you are working on that you can 
communicate with via one of Git's interfaces to send and receive the 
difference between here, and the remote computer. 

The clone command is one simple example of fetching (syncing) with the 
remote.

Commonly folks will have have an account on one of the Git*** services to 
act as a nicely public remote - useful if you can't get your two computers 
to talk directly to each other via Git...

Point to note. The names for branches at the two ends can be different 
(which is useful)
Point to note 2. `git pull` isn't (usually) what you want. You should use 
`git fetch` for the information from the remote(s), and then separately 
decide what to do. If you `pull` back and forth you can get into knots.
--
Philip

On Friday, November 5, 2021 at 8:00:13 PM UTC Joe Sollers wrote:

> Good Afternoon 
> I have been following tutorial online and book as well working with 2 
> computers and about 8 windows open on both maybe 16 hrs but working on a 
> project that requires coding.It seems the tutorial is in master file and I 
> am in actual computer file. I cannot sync or proceed with what I'm doing 
> and wondering if I am missing something simple. I am very new and will 
> continue reading but there are areas that you spend hours going nowhere and 
> would like some assistance.
>
> 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/dc223cba-6844-4e14-8f49-9cd6e9b205f8n%40googlegroups.com.

Re: [git-users] fatal: not a git repository

[Philip Oakley]

What's the link for the on-line course (should additional questions come 
up)? Is it public?

On Friday, November 5, 2021 at 3:05:18 PM UTC Joe Sollers wrote:

> Thank you guys I am using git online classes and am no coding guru but I 
> am working on a project that has led me to take a deeper dive so I may as 
> well earn a few certificates from git. Following the video, which I have 
> watched repeatedly, there may be a step missing with the head aches come 
> the navigation skills. I will have many more questions. I am only 
> navigating thru tutorial which says is 6.5 hrs but may be 60 for me.
>
> On Friday, November 5, 2021 at 10:33:09 AM UTC-4 Konstantin Khomoutov 
> wrote:
>
>> On Fri, Nov 05, 2021 at 06:34:16AM -0700, Joe Sollers wrote:
>>
>> >Trying to go thru initial course and navigating the terminal directions 
>> but
>> >we have reached a point where I get fatal: not a git repository, backed 
>> the
>> >video up and tried several ways but not able to follow along with video
>> >because I am not getting beyond this message in git status. Maybe 
>> something
>> >simple but glad to be finding quality resources.
>> >Any feed back is much appreciated !
>>
>> I have no idea what is that "video" you're talking about but the message 
>> you
>> have cited should merely be interpreted verbatim: you run the command
>>
>> git status
>>
>> and Git tells you the directory which is current in a shell (that program
>> running in your terminal, which displays the prompt and allows you to 
>> execute
>> command) is not a Git repository, and hence there's nothing to show the 
>> status
>> of.
>>
>> My guess is that you have initialized a Git repository - with a command 
>> like
>>
>> git init myrepo
>>
>> but then failed to actually make the "myrepo" current directory of your 
>> shell.
>>
>> To summarize:
>>
>> - Any Git reposiory is a directory on a file system.
>>
>> - To do any useful work in a Git repository, the current directory of the
>> shell in which you're executing Git commands must be the root directory
>> of a Git repository or any directory underneath it (however deep).
>>
>> Otherwise Git just has no way to locate the repository.
>>
>>
>> I would also advise you to read this book [1] instead of whatever you're
>> following at the moment. This book is of good quality and should help you
>> to avoid straightforward bloopers.
>>
>> 1. https://git-scm.com/book/en/v2/
>>
>>

-- 
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/d4a253b7-02b8-4cdc-8bcc-8ee31f4e8f18n%40googlegroups.com.

[git-users] Re: fatal: not a git repository

[Philip Oakley]

This " fatal: not a git repository" means the your git command (which is 
executed when you are at the particular file location shown in your 
terminal) cannot find an actual git repository somewhere in the file system 
hierarchy starting at your current location.
You maybe one level above the repository you created, e.g. if you gave it a 
name. 
If you `git init` in an empty directory then git can start in that empty 
repo.

A git repository can be recognised by seeing if there is a `.git` 
subdirectory (usually 'hidden').

You may have missed a step asking you to `cd ` to move your 
location into the repository, whereupon the `git  status` will be able to 
do its stuff.
--
Philip

On Friday, November 5, 2021 at 1:34:16 PM UTC Joe Sollers wrote:

> Trying to go thru initial course and navigating the terminal directions 
> but we have reached a point where I get fatal: not a git repository, backed 
> the video up and tried several ways but not able to follow along with video 
> because I am not getting beyond this message in git status. Maybe something 
> simple but glad to be finding quality resources.
> Any feed back is much appreciated !
>
> 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/e5c046b2-2255-4983-a2e8-3cb5d27e69ddn%40googlegroups.com.

Re: [git-users] Integrating GIT with my own versioning system.

[Philip Oakley]

On 31/10/2021 18:35, skybuck2000 wrote:
>
> You do know you get automatic de-duplication because filename
> metadata
> is stored independently of content (blobs), so copied file
> contents take
> up zero room!
>
>
> I am in doubt what this means. I take the blog theory of GIT with a
> grain of salt. I have seen it fail to detect blobs.

Blobs _are_ simply file contents (as stream of bytes). The blob's name
is the hash of that stream. If the stream is the same, then it has the
same name (hash) and references the existing 'copy' (e.g. all the
identical GPL2 licence files!)

>  
>
>
> > 5b remote branches
>
> Mental mind trap: these are held locally when fetched. You can
> reference
> them _instantly_ and start a new work-branch directly from them,
> without
> having to create a 'local' version first
>
>
> Yes this I understand that they are locally fetched. This is the cool
> thing, it feels like they are remotes, but they are stored on my drive
> and I can see and work on/copy from them at any time and if/when it
> pleases me I could even upload something if it's not to old and then
> it may sync-up or issue a pull request on their remotes which is very
> cool, lots of automation there...
>
Because the remotes will have a lot of common parts (early history) they
take zero space, because of hash deduplication. its only the new bits
that take any space, and mainly it's small "deltas" within the pack files.

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/c1344a85-24ce-9e92-b1fb-5fe5aaf3ff49%40iee.email.

Re: [git-users] Integrating GIT with my own versioning system.

[Philip Oakley]

On 31/10/2021 18:35, skybuck2000 wrote:
>
> Git stores snapshots. It will
>
>
> I may have noticed this. I did notice the GIT database can get quite
> large. One example is PascalCoin... it's git database seems to be 100
> MB... it shouldn't be that big I think, I don't think the sources are
> that big, so this may be because of copies of all different versions
> stored ?
>  
>
> _show_ diffs between commits, but it's still between snapshots. It is
> only later at the database level that compression is applied.
>
>
> Are all snapshots stored in the git database uncompressed ?

Not quite, see below
>
> What do you mean with database and compression, is it applied later
> automatically by git ?

Yes, the compression, called "packing" is done automatically when
various size limits (usually heuristic) are reached. See
https://github.com/git/git/blob/master/Documentation/technical/pack-heuristics.txt
for how it's done ("magic" tada!)

>
> For example when I "download"/pull a git repository I do see some zip
> extraction going on... and sometimes maybe also further pulls.
> Is that only done for the communication/protocol part to cut bandwidth
> costs ?

Packing all the way down & up!
>
> Or is the git database later re-zipped ? For example after a GIT commit ?
>
> Come to think of it, compression might eat into time... so maybe GIT
> doesn't do much compression when day to day work and committing ?
It's quite fast because it knows how to cheat - see above. Often folks
will have overnight packing (server management style) so as to keep any
delays out of the way.

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/cde7ab14-ad68-340f-57b3-becb5a3d8c09%40iee.email.

Re: [git-users] Integrating GIT with my own versioning system.

[Philip Oakley]

A few follow ups.
On 31/10/2021 17:57, skybuck2000 wrote:
>
>
> the Git repo built. At least it gives a better overview, though the
> diffs can be terrible.
>
>
> Why were the diffs terribles to many code changes all at once ?

Terrible in the sense that it was "all the code changes at once",
refactoring, wholesale code moves, concept changes, the lot.
The diffs were 'correct' but not really that helpful. The value of Git
(when used well) is that you can see the fine grained change management,
though it can be hard to teach folk how to write good commits - the Git
project itself is quite good at that.


>
> Git is especially good in collaborative work, without some top knob
> being in 'control'. The hash is simple and unique and avoids all the
> coordination issues.
>
>
> This is a good point you make while not 100% theoretically correct
> there is a small chance of hash conflict, but in principle I can see
> how each hash in the world might be unique ?! ;)
>
> Though one could consider this a matter of principle, do I really want
> to base collaborative work based on "luck" getting a unique hash by
> luck ? hmmm...

Folk get all antsy about the theoretical possibility - memory corruption
by cosmic rays is more common! Just saying ;-)

Also the Git sha1 protection (because of blob format) is still unbroken,
despite the careful breakage of the pdf format

>
> What could be the risk of basing it on a hash conflict ? Hmmm has this
> ever happend to the Linux Kernel :) ?! =D

It's not even happened across *all* the hashes at Github & Microsoft.
Still rarer than hen's teeth.

>  
>
> > version numbers in file names are not that usefull for application
> code, there are however very usefull for shared code between
> applications, so that applications can always be build against exact
> version numbers.
>
> > This is what worries me the most for GIT, it's not suited for
> shared
> files between applications, updating code in a "working folder"
> would be
> horrible and break every application that ever used it, here
> versioning
> in folder names and file names is far superior to always be able to
> build ANYTHING at ANYTIME.
>
> This is a 'mental model' misunderstanding. It is a 'kit of parts /
> parts
> catalog' viewpoint (home built vehicle), while Git's primary view is
> that of 'the project' (compare to having a make/model of a car).
>
>
> Isn't this the same thing, software is build up out of modules=parts.

It's the direction of choice that matters. The super project choses it's
libs, rather than libs forcing super-project changes. You chose the
wheels for the car, not the car for the wheels (e.g. the "must be gold
plated" toilets in aerospace)
>  
>
> In Git you would designate each of the resuable folder/files as a
> sub-module, which can then be integrated when/wherever it's needed
> by a
> major project. The (supra-)project choses the version that is used.
>
>
> OK, point taken, so you are "saying" shared libraries and such should
> have a submodule.
> This is where it gets a bit hairy, this kinda implies and means GIT
> has to be "applied" to libraries that I may not want to work on at
> all, libraries from other people.
> But I still have to GIT-ti-FY them.
>
> Now one could argue, wait a moment Skybuck, if you don't work on them
> then you don't have to GIT-ti-FU them but here lies a bit of the
> danger... In the future I might discover a bug or problem or a desire
> to modify a library and then BAM/BINGO... now this introduces a BIG
> problem, because so far, let's suppose version information was missing
> in GIT then GIT at this point has no idea of what library was being
> used. So to solve this problem I would have to add a SUB MODULE before
> making any changes to the library and then it becomes QUESTIONABLE if
> previous GIT commits can understand what SUBMODULE/hash was supposed
> to be used ? Consider this a serious question:
>
> What happens to previous commits if a SUBMODULE is later introduced ?
> Here it gets very fuzy.
>
> Bye for now,
>   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/210ad64a-783e-4a64-a6dd-a88b5f73f6dfn%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/3d98bcfb

Re: [git-users] Integrating GIT with my own versioning system.

[Philip Oakley]

On 31/10/2021 05:14, skybuck2000 wrote:
> Anyway I hope to have convinced you somewhat that GIT is not ideal for
> me, it's risky if something bad happens to it's database, it's
> cumbersome to use, it's slow for that reason, lot's of overhead.

What you know is almost always better that some random unknown
alternative that contains 'worries'. There is no perfect 'versioning'
system that is good for everyone (cf. "Mona Lisa v2.5.1" ;-).  I bet Git
feels like one of those taxi rides through an unfamiliar city..

Git itself is fast. Changing mental models, and getting new 'wins' from
that change can be, like you said, slow.

> So far I have used GIT mostly with git commands, I know there is a GUI
> but then I feel more disconnected, for now it makes more sense to work
> like I was working in ms-dos to get more a feel for it.

I would recommend trying at least the git-gui and gitk at least for
their alternate view points when exploring Git.

>
> Problem with GIT gui approach is that git gui might change over time
> as many guis do and that idea seems horrible to me, unless there are
> some big benefits, I also do not want to be dependent on some
> non-windows gui for software development.

Because the basic data model of Git hasn't changed and is rock solid all
the gui's essentially show the same stuff at different levels of
prettiness and soft rounded graphics. Git-gui and gitk are TCL apps
which are multi-OS.



> 1. Big Open Soure Linux Operating System, here making simple copies
would fill up harddisks very quickly, so I can understand only storing
"differences".

This is one of the BIG LIES we tell. Git stores snapshots. It will
_show_ diffs between commits, but it's still between snapshots. It is
only later at the database level that compression is applied.

> I couldn't care less about storage space

The Git community is poor at highlighting the *backup capability* of
remotes, and when to 'push'. They are more worried about storage access
times ..

> 4. Difference engine, detecting differences

You do know you get automatic de-duplication because filename metadata
is stored independently of content (blobs), so copied file contents take
up zero room!

> 5b remote branches

Mental mind trap: these are held locally when fetched. You can reference
them _instantly_ and start a new work-branch directly from them, without
having to create a 'local' version first

> 1. Continue working with my own versioning system for very fast code
development when developing solo.

It's an option. However if your development becomes a team, you are
likely to run into scaling issues (see Mr Torvalds's issues ;-)


> GIT is more focused on sharing quality/working code and integrating code
> and less on experimental/broken/flawed/buggy code.

OOOH So missing the point... Git gives control to the user so they can
do the latter in the privacy of their own dev environment.
It then provides the tools so that they don't have to be embarrassed
when publishing their polished code !

You should see some of my hacks on Matlab (interpreted, 3 fails a minute).
Having lots of versions allows me to go back to interesting outputs that
would otherwise have been lost in most other versioning systems
(remember its 100% snapshots!)


The hard part of Git, and all those other fads and tools, is to reason
about the hidden issues that forced or constrained or enabled the
methods being proposed.  Instant perfect replication and fast
incremental compiling has made the machining of a 3d model of the
Titanic so much faster than that of the original, and it's sister ship.
Versioning methods were developed for the Engineering Drawing Offices
c.1900. Things have changed (though mk1 human, dunno?).

I'll stop there. Some much that could be discussed, but mileages vary.
--
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/fcc1ff4c-546d-aedd-6cf6-d2ef81f3cd6a%40iee.email.

Re: [git-users] Integrating GIT with my own versioning system.

[Philip Oakley]

On 31/10/2021 05:14, skybuck2000 wrote:
> My own versioning system is very simple and used for solo development
> 99.9%.
>
> I will give an example of how this works.
>
> The main thing is "folders", "version number in folders" and "comments
> in folders".
>
> For example, let's suppose I want to test an algorithm called "Jack".
>
> I would create a folder like so:
>
> C:\Source Code\Tests\Test Jack\version 0.01 original code\
>
> Then I would make a copy of that code:
>
> C:\Source Code\Tests\Test Jack\version 0.02 modify it\

I and a colleague had a versioning system like that. We zip compressed
the top level directory to keep the backup (had the version number). I
was better than trying to use the corporate system (too many 'controls')
of either a 'big-iron' system or SVN (I never used).

After completion I created a Git repo by simply extracting each snapshot
(I have a script somewhere) and then overlaying the previous versions as
the Git repo built. At least it gives a better overview, though the
diffs can be terrible.

Git is especially good in collaborative work, without some top knob
being in 'control'. The hash is simple and unique and avoids all the
coordination issues.

> version numbers in file names are not that usefull for application
code, there are however very usefull for shared code between
applications, so that applications can always be build against exact
version numbers.

> This is what worries me the most for GIT, it's not suited for shared
files between applications, updating code in a "working folder" would be
horrible and break every application that ever used it, here versioning
in folder names and file names is far superior to always be able to
build ANYTHING at ANYTIME.

This is a 'mental model' misunderstanding. It is a 'kit of parts / parts
catalog' viewpoint (home built vehicle), while Git's primary view is
that of 'the project' (compare to having a make/model of a car).

In Git you would designate each of the resuable folder/files as a
sub-module, which can then be integrated when/wherever it's needed by a
major project. The (supra-)project choses the version that is used.

(I've not read everything so I may have missed stuff)
-- 

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/63e93ed7-d74d-5988-4502-0472068f2b34%40iee.email.

[git-users] Re: Error of the newest 2.33 for ssh key to Gerrit

[Philip Oakley]

there are full answers on the Git for Windows Issues pages. Some are 
'closed', so remove the `is:open` from the filter ;-) 
https://github.com/git-for-windows/git/issues/3468 

Summary, that encryption has been deprecated by one of the upstreams. There 
are work arounds, but do considere if you can upgrade the encryption.

-- 
Philip

On Friday, October 22, 2021 at 4:14:02 AM UTC+1 yangqia...@gmail.com wrote:

> Dear all：
> I and my team have meet a question when we add ssh key that from git bash 
> to Gerrit:
> our input code is : ssh-keygen -t rsa -C "xxx"
> and when we add ~/.ssh/id_rsa.pub to Gerrit，the error log is :
> The authenticity of host '[x.x.x.x]:port (ip:port)' can't be established.
> *ED25519* key fingerprint is 
> SHA256:wnB29ySBr3fHVkh8c9d84p0zzdpBw64tscsqJLa2N+M.
> This key is not known by any other names
> Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
> Warning: Permanently added 'gerrit_ip:port' (ED25519) to the list of known 
> hosts.
> username@gerrit_ip: Permission denied (publickey).
>
> *our version of git bash is :2.33.1version of Gerrit is :3.4.1*
>
> but ,when I change my git bash from 2.33.1 to 2.18.0，there is no same 
> error,and I can connect to Gerrit successfully.
> I want to know if there are some configuration in the newst git bash for 
> ssh key,thanks for any replies.
>
> Wish you happiness~
>

-- 
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/aa48f37d-1981-44b5-8564-55a77ae71375n%40googlegroups.com.

Re: [git-users] Basic Git Questions

[Philip Oakley]

I (as an older engineer) like to compare the 'staging area' (aka index / 
cache) to the old style 'outbox' one may have had on ones desk or in the 
corner of the office where we would place completed paper memos for 
collection later. It gave us chance to carefully collate groups of memos, 
or amend memo's completed a bit earlier before the secretary/mail-person 
came to collect and file the results.

It does take a bit to get to used to, especially if you had a 'file at a 
time' process that was copied from working on the drawings for the ark (yes 
almost all the configuration management processes are based on handling 
paper [kaolin & linen] drawings with india ink markings - unique 
masterpieces). Perfect and instant replication by computers is slowly 
changing that but people are generations behind!

The think I like about Git is that I get control of what I store locally, 
and don't need permission/authority to store stuff in a version 'control' 
system. It's now validation & verification by hash id that counts , not 
controlled access to the repository.

The design philosophy of Git is that everyone must be able to choose and 
make commits as they please, and that the object store will hold all the 
temporary artefacts, protected by hash values. So the object store has both 
the 'repository' and all those temporary artefacts. Neat and efficient.

On Wednesday, October 13, 2021 at 10:32:27 AM UTC+1 Konstantin Khomoutov 
wrote:

> On Tue, Oct 12, 2021 at 11:48:55PM -0700, Everett Simpson wrote:
>
> > I was curious, what is the design philosophy behind having the "add" 
> > command, as opposed to just committing everything in the repository? Is 
> > that so people can have private files on their end? Or because it allows 
> > you to keep track one by one, while you are working on a project, of 
> which 
> > files you want to push, because they are finished?
>
> I can provide certain insight from a programmer's standpoint.
>
> When you're working on implementing a feature or fixing a bug the files of
> your project most of the time tend to end up in a situation where they 
> contain
> multiple tangled, intertwined changes of which each would be implemented
> separately - *if the developer would be able to look into a crystal ball 
> and
> see the future.* The Git's feature of having the so-called "staging area"
> which is a virtual space allowing you to construct a state you'd like to
> commit allows to turn a usual mess of changes into a string of atomic 
> changes
> following one another logically.
>
> Why is this needed? Because - as a very useful saying goes - «programs are
> meant to be read by humans and only incidentally for computers to execute»,
> and the history of changes to a computer program kept in a version control
> system merely adds another dimension to this approach: when another 
> developer
> later has to understand why such and such bit of code had appeared in a
> program they're tasked to modify, it's much better when they are able to 
> dig
> up the change history to a minimal, logical, well-explained change, 
> surrounded
> by the changes which have the same properties.
>
> Sure, `git add` is just an aid for creating good history of changes, and it
> sometimes does not cut it alone - one then should apply, say, interactive
> rebasing etc.
>
> Please note that what I presented is just describing one particular area 
> where
> Git is used - though admittedly the most wide one, - and of course I might
> well think of other applications where bypassing the staging area is just 
> the
> most sensible thing to do.
>
> > Are there any alternatives to Git which only have a "push" command, and 
> > push all the files in the repo to the other branches?
>
> Sure. The most visible one is filesystem synchronization solutions such as
> rsync, unison, rclone, SyncThing, various tools supplied by cloud storage
> vendors such as DropBox, Google Disk etc.
>
> The idea is that when you do not care about what comes in a change set, 
> then
> there might be no sense to have change sets in the first place, and just 
> have
> "remote replicas" of your project. In other words, you might just not need 
> a
> VC system to begin with.
>
> A to using a VC system the way you want, any would fit the bill, actually:
> nothing prevents you from having a Git alias (or a no-brainer shell script)
> which instructs Git to just put everything which is modified to the staging
> area, commit and push. I mean, there's no need to have a specially-designed
> system to get this behaviour: it's absolutely possible to dumb down a 
> flexible
> system in any way you need.
>
> $ git add -A
> $ git commit -m "Change at `date`"
> $ git push origin HEAD
>
> is a way to have all the changes added, committed and pushed in three 
> commands
> which ask no questions. Make a script of them and you're golden.
>
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscrib

Re: [git-users] how *not* to push a certain branch but all others yes

[Philip Oakley]

On 07/10/2021 16:51, Uwe Brauer wrote:
>> The inconvenience is that you need to remember to create your local branches
>> using that convention (and rename current branches - which is easy to do by
>> using the `git branch -M` command).
> I admit I am confused: I thought I should use the same name as in
> remote, so master should be master and not pub_master
>
> Most likely there is something fundamental I don't understand.
Yes, it's easy to be confused.

There is NO requirement that the names match.

There is no requirement that you even have a local branch that 'tracks'
(is a duplicate of) a remote branch you are interested in
- This one is really hard to grasp for newer users who weren't there
when 'remotes' were invented. You simply, already, have a branch
`remote/branch` that is your own local copy of that truly remote
server's branch, and you can use that name when you start your feature
branch.

Like wise, you can use that separation of naming to distinguish your
'keep-local' branches, from your 'happy-to-publish' branches.

Philip
Git, juggling chainsaws while running in flip-flops ;-)


-- 
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/77d45a5e-658a-4813-d934-d14e434e26a0%40iee.email.

Re: [git-users] Re: Feature Request: Recognizing which code belongs together and in what file and file segment it belongs.

[Philip Oakley]

On 07/10/2021 10:04, Magnus Therning wrote:
>
> skybuck2000  writes:
>
>> Here is a "real-world" example:
>>
>> The original repository is this one:
>> https://github.com/PascalCoin/PascalCoin
>>
>> My restructured repository is this one:
>> https://github.com/SkybuckFlying/PascalCoinRestructured
>
> I only took a quick glance at the two repositories, but it seems you
> are in a situation where
>
> 1. You have a branch with major changes
> (https://github.com/SkybuckFlying/PascalCoinRestructured/commit/b6eb90bbb95c40494838a61b0e52c3dc62ab508b
> has >10k lines that are changed across 84 files!), and
> 2. your branch has lived for a long time (3 years), and
> 3. your branch is 3 years behind the upstream master branch.
>
> I can't help but feel a little sorry for you.
>
> Maybe that https://github.com/mhagger/git-imerge can help you out of
> the predicament you've put yourself in.
>
> /M
>
A thought experiment about possible procedure and process...

The git diff used for creating patches that represent the changes will
extract hunk headers which are meant to represent logical segments of
the code.

If the files were 'split' at these logical segment headers (that split
then promotes each filename to be a directory name, and each segment
becomes a file e.g. named with its line range `fileL73-95`), and this
split was done for both sides of the merge, then it maybe a reasonable
candidate for the new merge -sORT capability which should be a lot
better at detecting the file renames and code movements.

I guess that the file-with-line-range naming wouldn't work because then
everything looks like a rename, but file-with-segment-name should be a
lot more stable. 

Even better would be the compiler's parser for the code that would just
split out the major 'functional' segments that the code syntax already
defines.

It all sounds like those interview questions where you have to tie the
pliers to the string and start it swinging so that you can catch it
while reaching something else...
--
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/ecb860f2-2c4a-6f70-92d6-d7e214b8f760%40iee.email.

Re: [git-users] cannot commit or pull

[Philip Oakley]

I'll throw in my visualisation if it's any help.

It (Staging) is like having the old style "Out" tray at the edge of you 
desk where the mail person will collect all the packages when everything is 
ready, as a nice tied up bundle.

It means you can prepare individual 'files' for the bundle and put them in 
the 'out' tray as you progress, and if needed get one file back for an 
update, then it's right there. You can update and change anything in that 
'Out' tray bundle right up to the point that you set the 'collect the 
bundle (Commit!)' flag and the mail person whisks it off to the storage 
repository.

If you have the tooling/head-model, then it's quite easy to 'add' each file 
as any part is completed (even just the update of a single 
function/section).

The neat thing is that, being a computer, the house elfs have already taken 
a sneak copy of everything you place in the 'Out' box and put the copy in 
the Object store, so you have a simple 'backup' of all those small 'done' 
jobs. All that happens when you do that final 'commit' is that all the 
latest things in the object store/outbox are tied (bundled) with 
string/ribbon as the commit object (links to previous commit) and tree 
object (file object links). That is real quick as it doesn't need to touch 
the files at all (the job was done earlier).

https://www.wisconsinhistory.org/Records/Image/IM97014 Office Clerks with 
IN/Out box. (see the desk clutter!)

On Thursday, September 16, 2021 at 8:03:09 AM UTC+1 o...@ucm.es wrote:

>
> > Uwe Brauer  writes:
>
>
> > Well, changes always have to be staged, but as you can see in the 
> > git-commit manpage there's an option to stage all changes to known 
> > files automatically by using
>
> > git commit -a
>
> Ah, very well. That indeed is helpful.
>
> > If you mean magit I have to say it's absolutely worth trying. It's 
> > what I use to do 99% of the times I need to do some "git stuff".
>
>
> Well I meant even the simpler vc.el, but yes people often talk about
> magit, at some point I must give it a try.
>
> > There you _also_ have to stage changes, but the interface is a bit 
> > more clear about it.
>
>
> > Staging is a bit of a mind-shift, but I do urge you to give it an 
> > honest shot before condemning it. When I switched to git from 
> > svn/hg I found it to be an utterly weird idea. Just a completely 
> > useless nuisance. Over time I've found it's grown on me, and now I 
> > miss it whenever I have to do work in a VCS that doesn't have it. 
> > In particular I've found that it allows me to not "self-censor"; 
> > I'll make any changes I want in my workspace, even ones that 
> > aren't related to the issue I'm working on at the moment, because 
> > I know that I can split the changes into multiple commits later 
> > on. Staging is the mechanism that enables that.
>
> Right. I do not condem staging, not at all, it is only the idea of
> «adding a file» that is already there seems contra intuitive. 
>
> As for stagint (or similar concepts): it might be annoying if you just
> want to commit a quick fix, but if you have already done some changes
> and you want really to control what you are going to commit.
>
> In mercurial I sometimes committed changes I did not want to commit,
> however with the new evolve extension you can commit interactively
> changes you want, so that is very similar to staging and I use it a lot.
> It is funny to see that git and hg at the end have very similar
> functionality however using a different philosophy and that might
> confuse users that switch from one to another. 
>
>
> Anyhow, thanks for your help
>

-- 
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/50677f51-115e-4b8d-92a5-7cd4ea5f9aedn%40googlegroups.com.

[git-users] Re: Meta: Gmane newsgroup bi-directionality

[Philip Oakley]

Thanks for the clarification. I guess it's a Google (groups) related issue. 
The main Git list is organised via the kernel.org so probably has more 
flexibility. Others may know more...

On Tuesday, September 14, 2021 at 1:37:13 PM UTC+1 Daniel Fleischer wrote:

> The "gmane.comp.version-control.git.user" is the NNTP broadcast of this 
> "git-users" group and I'm able to read it through NNTP. However the link is 
> one-directional, i.e. I can't send a message to the newsgroup having it 
> reach here. I know it's possible even with a google group because I did it 
> in another group.
>
> https://lore.kernel.org/git/  is the technical mailing list, available as 
> NNTP on "gmane.comp.version-control.git" and it's indeed bi-directional. 
>
> If there are legal issue, no worries; I was just wondering why the link 
> was one-directional. Can one still participate just be sending an email to "
> git-...@googlegroups.com" ? 
>
> On Tuesday, September 14, 2021 at 2:58:28 PM UTC+3 philip...@iee.email 
> wrote:
>
>> Gmane's majordomo service for Git was taken off-line a few years ago 
>> because of legal troubles at the gmane service (right to delete issues 
>> IIRC). 
>>
>> I believe it is still available as an nntp service. 
>>
>> If you need to access old gmane based links to past Git List mailings 
>> then use the https://lore.kernel.org/git/ (search for gmane) for that 
>> ability to reference gmane threads. Also on 
>> https://public-inbox.org/git/xmqqblrp...@gitster-ct.c.googlers.com/ 
>> 
>>
>> Hope we are talking about the same list...
>>
>> Philip
>>
>> On Tuesday, September 14, 2021 at 10:52:56 AM UTC+1 Daniel Fleischer 
>> wrote:
>>
>>> Hi, can you make the newsgroup "gmane.comp.version-control.git.user" 
>>> bi-directional so people can participate without using a browser or 
>>> email-subscribing? 
>>>
>>> Thank you, 
>>>
>>> Daniel Fleischer
>>>
>>

-- 
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/52143ca8-6a9d-470e-89a8-cf77cd913942n%40googlegroups.com.

[git-users] Re: Meta: Gmane newsgroup bi-directionality

[Philip Oakley]

Gmane's majordomo service for Git was taken off-line a few years ago 
because of legal troubles at the gmane service (right to delete issues 
IIRC). 

I believe it is still available as an nntp service. 

If you need to access old gmane based links to past Git List mailings then 
use the https://lore.kernel.org/git/ (search for gmane) for that ability to 
reference gmane threads. Also on 
https://public-inbox.org/git/xmqqblrpfky5@gitster-ct.c.googlers.com/

Hope we are talking about the same list...

Philip

On Tuesday, September 14, 2021 at 10:52:56 AM UTC+1 Daniel Fleischer wrote:

> Hi, can you make the newsgroup "gmane.comp.version-control.git.user" 
> bi-directional so people can participate without using a browser or 
> email-subscribing? 
>
> Thank you, 
>
> Daniel Fleischer
>

-- 
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/6a551882-b6af-42e4-ab2b-a0ed994dc4ffn%40googlegroups.com.

[git-users] Re: Feature Request: Recognizing which code belongs together and in what file and file segment it belongs.

[Philip Oakley]

Have you looked at the various --pickaxe and other file-following options 
that can be set to different levels of similarity for the tracking of such 
splitting and changing.

Sometimes the real problem is that the 'local' feature branch policies 
(i.e. your corporate way of doing things) can be in conflict with the 
underlying Git (Linux/Linus) philosophies of small changes, short lived 
branches, no mega-merges, etc. such that the apparent conflict resolutions 
(or failure to detect code movement) is easy for the dev to use git (with 
those extra parameters) to simply resolve the conflicts...

I guess Git hopes that the dev provides the `deep learning [caffeine 
fuelled?] neural brain`.. ;-)  while it provides some aggressive tools to 
follow those splits.

Also look out for the discussions on the Git mailing list for the 
forthcoming ORT merge strategy (i.e. the `-sort` option ;-)
https://blog.palantir.com/optimizing-gits-merge-machinery-part-v-46ff3710633e
https://lore.kernel.org/git/CABPp-BGR3dfJE7TZ+jkjDdWyeXYowmJhtoFaQ8_Abn=zroh...@mail.gmail.com/
 
(as a starter)

If you have some shareable examples then the author of ORT would be 
interested in those tricky cases. 
On Sunday, September 12, 2021 at 2:09:20 AM UTC+1 skybu...@hotmail.com 
wrote:

> Problem description:
>
> Background:
> Original fork does not want to split a file.
> Child fork does want to split the file and does so.
> Child fork can no longer benefit from changes from original fork.
>
> Problem:
> Git is incapable of transferring the changes of orignal fork file to child 
> fork splitted files.
>
> Suggested Solution:
> Use deep learning networks and machine learning to develop a neural brain 
> which is capable of detecting which changes/pieces of code belong together 
> and in what file they belong.
>
> Bye for now,
>   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/146d706d-7f7c-402b-b4f4-5e722c9a7672n%40googlegroups.com.

[git-users] Re: Combining two repositories (Local)

[Philip Oakley]

Look up the --orphan options for brining in an independent line of 
development into your repository. You can then formally merge the two lines 
of development (hence you will then have two root commits). It is also 
possible to use `git replace` if they are to looking like they occurred in 
sequence, but that's less useful.

It is quite common to have say an independent line of development for meta 
data or planning that isn't part of the regular 'codebase'.

P.

On Thursday, September 2, 2021 at 3:27:03 PM UTC+1 jta...@gmail.com wrote:

>
> I have two projects that are currently in separate local repositories.
> Given their current evolution, it now makes more sense that they should be 
> seen as a single project in a common repository.
>
> Is there a way to combine the two together while keeping the update 
> history of both?
> Either within one of the current repositories or (perhaps better in case 
> of mishaps in the process) into a new repository?
>
>

-- 
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/c61148a2-94fa-497c-9136-0907b212c023n%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.

Re: [git-users] Change management practices

[Philip Oakley]

If you can avoid branching feat-2 from feat-1 then that is worthwhile if if 
allows an independent feat-2 to be released while feat1 is still in test. 
However if there is some shared code, then it's worth branching earlier 
within feat-1 before the feature-1 visible changes show up. It is there 
that a code move rebase may be valid (must end up 'treesame' to the code in 
test), just so you gain that starting foothold. 

rebase --squash is useful for minor corrections and mistakes, but it (from 
my perspective) is poor practice to simply squash everything into the 
classic "big ball of mud" change - that's also a hang-over from drawing 
office procedures, and legal wanting to avoid 'discovery' (which is why you 
rebase early & often, but retain a clean history ;-).

How is the team, management, and the servers organised? This can affect how 
you can get the best workflow. Do you have independent forks on the server, 
or does every one have commit privilege to the golden branch (separation of 
concerns..)?. Is there a 'maintainer', who does that final validation for 
the merges and tagging of releases? Is this an entirely software product - 
is it GUI style, or hardware control or database manipulation, etc. (who 
else has fingers in the pie who aren't coders/devs). Is it a run fast and 
break things shop, or a steady as she goes, no icebergs shop?
On Tuesday, August 31, 2021 at 12:09:06 AM UTC+1 SJW wrote:

> Thanks to both of you for providing such detailed, in-depth responses.
>
> Your assumptions were correct. I branch per feature.  I have actually 
> branched a new branch (feature-branch-2) from another feature branch 
> (feature-branch-1) once but then I wasn't sure if it was logically right 
> because now, feature-branch-2 actually has 2 projects or features and it is 
> entirely possible for feature-branch-2 to be approved for production before 
> feature-branch-1.  Not a major problem I guess because  I can just leave it 
> unpublished until they are both approved however, just wasn't sure if I was 
> following good practice.
>
> And then, new changes to feature-branch-1 - I thought - do I just apply 
> them into feature-branch-2 and make this the single release no longer 
> requiring me to manage 2 branches... Your comments have given me some food 
> for thought.  I will do a bit more rebase research I think 
>
> I did look at rebase --squash and thought it was an idea given the 
> numerous commits I might have in a branch but, I was concerned about losing 
> history and wasn't sure the benefit outweighed the detriment so your 
> comments have solidified my thinking on this.
>
> There's a bit to unpack in the responses so I will get acquainted with 
> these suggestions.
>
> Any recommendations on learning would be appreciated too - if you have a 
> YT video or text or something else that covers the common usage patterns I 
> am interested in learning.
>
> On Tuesday, 31 August 2021 at 02:32:26 UTC+10 Mikko Rantalainen wrote:
>
>> On Sun, Aug 29, 2021 at 3:51 AM SJW wrote:
>>
>>> I will regularly create feature branches for each new enhancement or 
>>> fix. The problem rears its head when testing is delayed and the first 
>>> feature (feature-branch-1) is still not approved for production and sits as 
>>> a branch awaiting merge.
>>>
>>> Now, in my feature-branch-4 I am working In a similar area and really 
>>> need to consider changes from feature-branch-1 and I usually just copy some 
>>> of those changes over.
>>>
>>> Now this is not very efficient and I thought rebase would work great BUT 
>>> that code is not approved and may actually change. 
>>>
>>> I really just don't know what's the most efficient way to manage 
>>> situations like this without stopping development and waiting for testers 
>>> to approve code but this approach results in 1-2 days of waste where I just 
>>> twiddle my fingers waiting...
>>>
>>
>> I'm assuming you're already able to commit logical changes, not files. If 
>> that's not true, learn that first.
>>
>> I'm also assuming you're doing real feature branches instead of having a 
>> single branch per developer.
>>
>> The way I do it is to assume that whatever code my current branch depends 
>> on is going to be blessed in the future. Or at least the internal APIs that 
>> I use do not change and the problems are just in the implementation of 
>> those APIs. So logically I just branch my next feature on top of the 
>> non-blessed previous branch X.
>>
>> When testing/QA finds something wrong in branch X, it will be fixed as 
>> new branch X' and I just rebase my branch from X onto X' (see "git rebase 
>> --onto").
>>
>> If you mix bug fixes and features in your feature branch, the simplest 
>> way is to just "git rebase -i" your own branch and reorder/push all the bug 
>> fix patches towards the already blessed commits (that is, make the 
>> DAG/"history" appear like you did all the bug fixes first and all the 
>> feature stuff after that). That would allow getting t

[git-users] Re: Change management practices

[Philip Oakley]

Hi Shannon,

Some thoughts: first a bit of cod-philosophy : we can't control or 'manage' 
change, all we can do is administer it, and add a bit of political spin ( 
Situation, 
Problem, Implication, and Need-payoff ). Lot's of managers think they have 
control, but we all know.. Git with it's 'DVCS' distributes that 'version 
control' to the coder (because we can locally create versions/revisions to 
out heart's content). This separates the recording of versions from the 
inclusion (merge) into the main/golden repo. I raised that to highlight the 
shift in the focus that can be applied. (I remember the smell of a real 
'blueprint' machine!, and microfiche on IBM Hollerith cards.. the horrors 
of history;-)

It is worth looking at the different approaches to including code and 
changes, and where they came from. Most administrative methods have 
developed over the last century (yes) from the way that old style drawing 
offices controlled their 'drawings' used for the manufacture of hardware 
(think Titanic master drawings - no drawing, no ship). Those are the same, 
conceptually, as software code. They both require tools to take the 
information to create product. We now uses compilers rather than lathes 
(see CNC machines as missing evolutionary link).  They managers would batch 
up changes to the drawings (no touching the master, it was too precious), 
which is now the 'squash everything together' approach.  Each of the 
different approaches to merging and trunk development come out these 
historical experiences (monkey stepladder stuff)

Others would keep better records of the small changes, so they could see *why 
*faults happened later, especially if they did prototype testing. That's 
your current problem. You have a batch of changes, and a prototype is being 
tested. Meanwhile others have also being adding changes, and you might 
"need to consider changes from feature-branch". 

Some of this is a social issue of conflict/collaboration and negotiation, 
so that you could split out independent changes from (potentially) 
inter-related changes. This would allow your  *individual changes to be 
re-ordered* to have the independent changes first and the (potentially) 
interrelated changes (aka 'conflicts') put near the end of the rebase 
sequence. 

With this split you can split the testing into the two parts. Being able to 
add the independent changes early gives a firmer base for the interrelated 
changes and helps clarify the core element of the change. Often we can't 
see the woods for the trees in the feature branches. 

There is nothing to stop you from *doing a trial merge* of your 'released 
to test' branch with the 'alt-feature' branch just so that you can, in 
advance, know which 'conflicts' are just awkward context changes (the 
context lines don't line up), which are order dependent within the 
resolution, and which are wholescale syntactic changes. It's the last group 
that need the active social  action to convert that idle time to useful 
prep time. The former just need their resolutions recorded (unfortunately 
the `rerere` isn't easily exportable) so that whoever merges the features 
can resolve them with a single click. (one is assuming that testing is 
going to be successful...)

On Sunday, August 29, 2021 at 1:51:19 AM UTC+1 SJW wrote:

> I have been Watching YouTube tutorials in order to expand my knowledge in 
> git but there are now some questions that this has raised so I was hoping 
> someone here could educate me on some best practices or philosophies I 
> should consider.
>
> The main point is around rebase - I see great value in this but the whole 
> philosophy was around bringing committed code into your feature branch.
>
> I will regularly create feature branches for each new enhancement or fix. 
> The problem rears its head when testing is delayed and the first feature 
> (feature-branch-1) is still not approved for production and sits as a 
> branch awaiting merge.
>
> Now, in my feature-branch-4 I am working In a similar area and really need 
> to consider changes from feature-branch-1 and I usually just copy some of 
> those changes over.
>
> Now this is not very efficient and I thought rebase would work great BUT 
> that code is not approved and may actually change. 
>
> I really just don't know what's the most efficient way to manage 
> situations like this without stopping development and waiting for testers 
> to approve code but this approach results in 1-2 days of waste where I just 
> twiddle my fingers waiting...
>
> Any advice or personal experience would be welcome.
>

-- 
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/26653e02-b7b9-4445-aee2-13835bda112an%40googlegroups.com.

[git-users] Re: Restoring old version of directory tree with code

[Philip Oakley]

Have a look for the `-f|--force` option and the `--no-overlay` option 
(https://git-scm.com/docs/git-checkout), along with the `-- ` 
syntax (the `--` is space separated) if it is just a single directory from 
the commit (treeish) that's required.

There is also the `git reset` command but that can be a blunt instrument..

Hope that helps.

On Thursday, August 19, 2021 at 2:10:03 AM UTC+1 H wrote:

> I am a newcomer to git but have read some of the documentation and 
> experimented with commits etc. My question, if I want to restore an entire 
> directory tree with code from a previous commit in git, how do I do that?
>
> It seems that "git checkout " does not delete directories and 
> files in the directory tree that have been created since the commit which 
> makes sense. Would I thus need to delete the entire directory tree and then 
> use "git checkout " to restore everything present in the git commit 
> to achieve the desired result?
>
> Thanks.
>
>

-- 
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/04e6b1c8-0f3d-4751-8be8-36c61d82b8cbn%40googlegroups.com.