Need list of supported git bash commands

[ElectricRCAircraftGuy]

• I was not able to find an open or closed issue matching what I'm seeing

In my off-time and evenings, I'm writing git extensions (ex: git-tree, sync_git_repo_from_pc1_to_pc2.sh, git-filechange-search.sh, and git diffn to show line numbers in git diff) using bash and Python in Linux Ubuntu, but was hoping they'd run on Git for Windows too inside the included git bash shell. What commands are supported? Is there a full list somewhere?

1. Does running Python scripts work?
2. awk?
3. sed?
4. etc.

@dscho

[PhilipOakley]

Have a look at the build-extra repo which has the build process (it's also part of the SDK).

It's the build-extra that packages those extra support tools.

(sorry for the short reply, hope you can manage to browse through the repo to locate the package list)

[PhilipOakley]

Ok so try

compgen -c | grep ^[a-zA-Z].* | uniq | sed /.*\.dll/d 

The internet tells me that compgen -c lists all commands, the grep throws out all the ones starting _, __, etc., uniq removes doublers, and sed deletes all the dll's.

That was a fun learning exercise.

Should give you a head start

[dscho]

What commands are supported? Is there a full list somewhere?

I fear that I have to disappoint you: there is no such list, and there are no plans to ever provide one.

The only reason why these commands are bundled within Git for Windows' installer is to support Git. If no part of Git was written in Unix shell script, there would be no reason for those commands to exist.

In that light, if we ever see that we do not need Perl anymore, I can see us removing it from the Git for Windows installer.

Also keep in mind that probably the majority of Git for Windows users use it indirectly, via MinGit (a subset of Git for Windows intended to be bundled in applications using Git's functionality, e.g. Visual Studio, GitHub Desktop, Atom, etc). There is a version of MinGit that comes with BusyBox instead of all those MSYS2 tools, and if we ever manage to stabilize our copy of BusyBox, that version of MinGit will most likely become the one that is used everywhere. MinGit already does not ship with Perl, BusyBox variant or not.

I can answer your questions like these:

• Does running Python scripts work?

Yes, if the user has Python installed separately. It is not included in Git for Windows.

• awk?

We do ship with MSYS2 awk, except in the BusyBox-backed MinGit, where BusyBox' awk command is used instead.

• sed?

Same as with awk.

• etc.

Yes/no/maybe.

😀

But honestly, I do not really see the point in asking this question, as Git for Windows does not try to provide a Linux-like work environment, even if it might happen to work for many users. There was never a promise to do this, and there will never be. If you need a Linux-like work environment, use WSL, or Cygwin, or MSYS2.

Your implicit question seems to be whether Git for Windows can support your extensions. Looking at git tree, I see that it requires Python: so Git for Windows won't support this out of the box, ever. Users will always have to install Python manually to make that work.

In general, I don't necessarily think that it makes sense to develop something like git tree outside of git.git. With a little deliberation, it should be relatively easy to find a good spot in Git's own source code where functionality like this could be added.

compgen -c | grep ^[a-zA-Z].* | uniq | sed /.*\.dll/d

If you replace sed /.*\.dll/d by grep -vi '\.dll$', and if you move that before the uniq, I agree that this is a start to figure out the status quo. Of course, we won't promise that those tools will all be there. And the list also includes pretty much everything on the PATH, including TSTheme.exe(which is provided by the Windows Operating System) andvsjitdebugger.exe` (if you have Visual Studio installed). So maybe it is not all that great a start.

A better start might be find /usr/bin /mingw64/bin -type f | grep -i '\.exe$', except that that does not catch shell scripts like zless.

[PhilipOakley]

@ElectricRCAircraftGuy

What commands are supported? Is there a full list somewhere? I fear that I have to disappoint you: there is no such list, and there are no plans to ever provide one. The only reason why these commands are bundled within Git for Windows' installer is to support Git. If no part of Git was written in Unix shell script, there would be no reason for those commands to exist. In that light, if we ever see that we do not need Perl anymore, I can see us removing it from the Git for Windows installer. Also keep in mind that probably the majority of Git for Windows users use it indirectly, via MinGit (a subset of Git for Windows intended to be bundled in applications using Git's functionality, e.g. Visual Studio, GitHub Desktop, Atom, etc). There is a version of MinGit that comes with BusyBox instead of all those MSYS2 tools, and if we ever manage to stabilize our copy of BusyBox <#1439>, that version of MinGit will most likely become the one that is used everywhere. MinGit already does not ship with Perl, BusyBox variant or not. I can answer your questions like these: * Does running Python scripts work? Yes, if the user has Python installed separately. It is not included in Git for Windows. * awk? We do ship with MSYS2 awk, except in the BusyBox-backed MinGit, where BusyBox' awk command is used instead. * sed? Same as with awk. * etc. Yes/no/maybe. 😀 But honestly, I do not really see the point in asking this question, as Git for Windows does not try to provide a Linux-like work environment, even if it might happen to work for many users. There was never a promise to do this, and there will never be. If you need a Linux-like work environment, use WSL, or Cygwin, or MSYS2. Your implicit question seems to be whether Git for Windows can support your extensions. Looking at git tree, I see that it requires Python: so Git for Windows won't support this out of the box, ever. Users will always have to install Python manually to make that work.

Hi dscho,

In general, I don't necessarily think that it makes sense to develop something like git tree outside of git.git.

sorry for the ignorance, I presume your mention of `git tree` would be a mimic of a linux type command that lists commands ..? Or have I misunderstood the comment.

With a little deliberation, it should be relatively easy to find a good spot in Git's own source code where functionality like this could be added. compgen -c | grep ^[a-zA-Z].* | uniq | sed /.*\.dll/d If you replace sed /.*\.dll/d by grep -vi '\.dll$', and if you move that before the uniq,

Any special reason for the swap (interested/genuine Q)

I agree that this is a start to figure out the status quo. Of course, we won't promise that those tools will all be there. And the list also includes pretty much everything on the PATH, including TSTheme.exe(which is provided by the Windows Operating System) andvsjitdebugger.exe` (if you have Visual Studio installed).

Maybe work putting some of this in the wiki, just for the record (what I know is..). I'd agree that it is greedy to list locally available stuff, which for a local user is probably most useful, but not as a minimal list (which we don't guarantee anyway..)

So maybe it is not all that great a start. A better start might be find /usr/bin /mingw64/bin -type f | grep -i '\.exe$', except that that does not catch shell scripts like zless.

yes, there's no perfect answer. Philip

[ElectricRCAircraftGuy]

sorry for the ignorance, I presume your mention of git tree would be a
mimic of a linux type command that lists commands ..? Or have I
misunderstood the comment.

Hi @PhilipOakley , git tree would do what I show arc flow doing here: https://stackoverflow.com/a/54231342/4561887. It will graphically show user-defined dependencies among branches:

master                              
└──graft-D999
   └──new_feature_1
      └──new_feature_2 

That's it! It's a means of visually seeing how you are forcefully stacking and rebasing branches, so that your new_feature_1 branch can depend on your buddy's D999 branch prior to D999 being merged into master, and your new_feature_2 can be based on your new_feature_1 prior to either of those getting merged into master.

It's a work-flow aid tool.

It would have an additional pretty cool feature called git tree cascade which would recursively rebase graft-D999 onto master, then new_feature_1 onto graft-D999, then new_feature_2 onto new_feature_1, all with that one, single command rather than having to do all that manually, which is a pain.

On large teams, sometimes the review process takes so long and is so onerous I've had up to 7 to 9 branches open at once, all stacked up on top of each other, waiting for previous branches to get approved and merged. Without a tool like this it becomes nearly impossible to keep track of it all and manage which branch is based on which, especially considering their upstreams must point to the remote repo where you are uploading them to github, so you can't resort to using their upstreams as a means of setting who is based on who, and even if you could, without being able to graphically visualize that information, it's basically useless anyway.

[ElectricRCAircraftGuy]

Thanks guys, by the way, for the info.

Also, I need a tester for git diffn on Windows using Git for Windows. I don't have access to a Windows machine right now.

See my screenshots and full instructions here: https://stackoverflow.com/questions/24455377/git-diff-with-line-numbers-git-log-with-line-numbers/61997003#61997003.

Any takers?

I think it's pretty useful and I'm pretty excited about it! Check this out. It shows line numbers!

[PhilipOakley]

On 25/05/2020 08:14, Gabriel Staples wrote: sorry for the ignorance, I presume your mention of git tree would be a mimic of a linux type command that lists commands ..? Or have I misunderstood the comment. Hi @PhilipOakley <https://github.com/PhilipOakley> , git tree would do what I show arc flow doing here: https://stackoverflow.com/a/54231342/4561887. It will graphically show user-defined dependencies among branches: master └──graft-D999 └──new_feature_1 └──new_feature_2 That's it! It's a means of visually seeing how you are forcefully stacking and rebasing branches, so that your new_feature_ branch can depend on your buddy's D999 branch prior to D999 being merged into master, and your new_feature_2 can be based on your new_feature_1 prior to either of those getting merged into master. It's a work-flow aid tool.

because branches are just light weight (throw away) pointers to the tip of a line of development (i.e. a commit is not owned by any branch); And branches can criss-cross, merge and fork; the dependency/ownership model doesn't really work that well. A common visualisation is the --graph and history simplification methods for the `log` and similar commands. Philip (just another engineer;-)

[ElectricRCAircraftGuy]

I'm not explaining myself very well. It doesn't necessarily show what the actual branch dependency or fork tree is, it shows the order you are hereby stating the branches need to be merged, and who needs to be merged into who, in order to minimize merge conflicts. It's a user-defined order. It's akin to using git branch -u my_upstream_branch on every branch you create, to set your upstream branch to who you plan to merge into in the end and rebase on as you make changes, and then graphically visualizing the chain of upstream branches set by -u. It has nothing to do with git log. Once I finish the program I'll write a tutorial/demo. Note: this type of workflow using a tool with these features has been tested with hundreds if not thousands of developers for years in a single org and it works very well. My demo would fully explain the workflow and the problems this workflow solves.

---

Meanwhile, if you could help me test git diffn that'd be awesome. It relies on gawk, but if gawk doesn't work in the Git for Windows bash terminal I can make some modifications I think and make it work with regular awk.

I also need to know what install instructions work to get git diffn working. See my Stack Overflow answer for install instructions for Linux which I think may work in Git for Windows too.

Update: let's make this a new issue: #2635

[dscho]

Update: let's make this a new issue: #2635

And in the same vein, let's close this here ticket as the answer has been provided.