Canonical fork?

[krlmlr]

I'm using git-sh and like it for its simplicity, compared to the (seemingly much more popular) gitsh. (That tool doesn't have an Ubuntu package and seems to require Ruby and libreadline for installation, at this point I stopped reading the instructions.)

The original repo by @rtomayko is archived, I'm wondering if there's interest to combine efforts to maintain this package and perhaps update the Homebrew and Ubuntu installers (which still seem to point to the original repo).

I'm opening this issue here because it appears to be the fork with issues enabled that has been pushed to most recently. I have contributed two PRs to @armano2's repository, but they don't seem to be included here.

I looked at the forks where the push date is more recent than the creation date, pinging the owners. It would be great to get a rough understanding how you tweaked your fork and to combine these changes into one repository.

Thanks in advance, sorry for disturbing.

@vargumedo @g-raud @rash67 @vlad2 @roeme @mattnworb @mehabox @selivan @armano2 @julesmqz @akras14 @Leonid99 @nikreiman @torsday @jiyinyiyong @taupecat @lmars @mfitzpatrick @phatblat @hhulkko @vrinek @igrep @capnslipp @mgax @richardkmichael @Daenyth @mbrubeck @bmizerany @ShadowOfHarbringer @jpfuentes2

[roeme]

Heyo @krlmlr; to answer your inquiry related to my own fork; while I did fork rtomayko's original repo; in my case I did a more-or-less-greenfield approach later on in https://github.com/roeme/shgit. It does reuse some conceptual parts of git-sh, but is scoped to be (much) more light-weight (as my $DAYJOB requires working under cygwin, which incurs heavy penalties to some syscalls), have less dependencies (no make install), obey/hook into git configuration conventions as much as possible, to be as minimally intrusive as possible (load user rc files etc.), among others.

[vlad2]

Hello @krlmlr, I've added you as a collaborator to this project.
For me it's easy enough to install git-sh from the repo directly, but yes, a deb/ubuntu package would be always welcome.

[nre-ableton]

I'd be happy to contribute patches from my fork, but I don't have time to be the maintainer of the canonical upstream. If you want to make your fork the new official one and contribute a package to Ubuntu, I'd be happy to see that. Godspeed!

[rash67]

i missed the fork and will be trying i made some personal hacks i merged on each pull that conflicted Sam Rash sam.rash@gmail.com

…

On Nov 24, 2018, at 4:26 PM, roeme ***@***.***> wrote: Heyo @krlmlr; to answer your inquiry related to my own fork; while I did fork rtomayko's original repo; in my case I did a more-or-less-greenfield approach later on in https://github.com/roeme/shgit. It does reuse some conceptual parts of git-sh, but is scoped to be (much) more light-weight (as my $DAYJOB requires working under cygwin, which incurs heavy penalties to some syscalls), have less dependencies (no make install), obey/hook into git configuration conventions as much as possible, to be as minimally intrusive as possible (load user rc files etc.), among others. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[taupecat]

I think all my fork did that the original project didn't was account for an macOS file (checks for .bash_profile instead of .bashrc), and it also adds "flow" as an accepted git alias. After seeing this thread, I tried gitsh and decided I didn't really like it. My forked version of git-sh works fine for me, and I think I'll keep using it as it is now. Good luck!

…

-- Tracy

On Sun, Nov 25, 2018 at 6:44 PM sr ***@***.***> wrote: i missed the fork and will be trying i made some personal hacks i merged on each pull that conflicted Sam Rash ***@***.*** > On Nov 24, 2018, at 4:26 PM, roeme ***@***.***> wrote: > > Heyo @krlmlr; to answer your inquiry related to my own fork; while I did fork rtomayko's original repo; in my case I did a more-or-less-greenfield approach later on in https://github.com/roeme/shgit. It does reuse some conceptual parts of git-sh, but is scoped to be (much) more light-weight (as my $DAYJOB requires working under cygwin, which incurs heavy penalties to some syscalls), have less dependencies (no make install), obey/hook into git configuration conventions as much as possible, to be as minimally intrusive as possible (load user rc files etc.), among others. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABEKE2PewoJmQbI48HhM9vX8RwI9h_rkks5uyytDgaJpZM4Yxlmu> .

-- Tracy Finifter Rotton tracy@taupecat.com