Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-other / 2012-09

Easygit and Git discussions (moved from fpc-devel)

1 message · 1 person ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Hi,

Bernd wrote
default it is doing its best to be as cryptic, strange behaving and unaccessible as possible. I almost believe Linus did this on purpose.

That was maybe the case in the early days of git versions leading up to v1.0. Since then Git commands have been radically simplified. Maybe you should try a git v1.6.x or v1.7.x branch again.

It needed easygit to finally make me comfortable with git and see its advantages.

I had a look at easygit, and I really don't see the "advantage" compared to git v1.6.x or git v1.7.x - because all the easygit commands are near identical to the real git commands.

Easygit seems outdated too, because they "introduce new features", but those "features" already exist in git.

http://people.gnome.org/~newren/eg/documentation/list-of-changes.html

for example:

---------------
Changes to branch:
'eg branch' is identical to 'git branch' other than adding a new -s option for switching to a branch immediately after creating it. ---------------

...well in git you simply do 'git checkout -b <branchname>' and it will create the branch mentioned, and check it out for you.

Going through that list of changes, lots of the functionality mentioned in easygit has already existed in git for some time. So it seems easygit was a good idea in the early days of git, but definitely lost it relevance in git v1.6.x and git v1.7.x releases.

git commit -a

This command is only great for the initial commit (importing new source code) of a Git repository. Using the -a parameter every time, and you loose so much of the benefits of git, and staged commits.

For example: I do development work for a hour or two, then start committing. Even though I might have made lots of code changes, I believe in small atomic commits (something the -a parameter is not, and neither is 'svn commit'). So I launch 'git gui' select the hunks I want to commit, or even select only certain lines inside a hunk to be committed. I repeat this until all the code changes I want is committed. At the same time I can discard (revert) debug changes I don't want to commit, like debug writeln() statements etc. Small atomic commits is key to an easy to manage repository, plus it makes 'git bisect' and 'git log' infinitely more useful.

Speaking of 'git log'. Here is a comparison of 'eg log' vs 'git log' output. I find the latter color coded output much easier to read. See attached image. Then doing commands like 'eg show' in actual fact simple executes 'git show' with no extra modifications. So you get the full benefit of git with color highlighting, showing diffs in red/green/cyan.

pull from and push to by default, git has some totally unintuitive defaults and surprising behavior for many things

I have no idea what you mean.

and btw the git help you mentioned is the worst help I have seen so far in the last 30 years. Try eg help to see how helpful help needs to look like.

"eg help uses its own help system, ignoring the one from git help...except that eg help will call git help if asked for help on a subcommand it does not recognize.

The git man pages are really nice for people who are experts with git;
they are comprehensive and detailed."
                  --- from the 'eg help help' output

So other than the very basic 15 lines of help output for the odd 10 commands 'eg' knows, it actually uses the real git help. :-)

The 'eg help' is a help an overview of what a
command does. It gives no real help with various git usage examples etc. that the actual git help does.

Then, did you actually bother to read the official Git online help, Pro Git book, Git User Manual etc?

http://git-scm.com/docs

Detailed help with images and graphs to help explain and visualise things. Tutorial videos (thanks to the GitHub guys) etc. For an open source project, Git has pretty impressive official help with lots of very valuable real usage command examples. No to mention the thousands of unofficial git help sites out there too.

Anyway, like I said. I think there was a time when easygit could have been useful. But with the latest versions of git, it is already so easy to use, it makes easygit obsolete. And if the command line is too much for a git newbie simply create some desktop icons for 'gitk --all' or 'git gui' or 'git gui blame <filename>'

Lets just be glad you are using git and not svn any more. ;-)

Cheers,
- Graeme -

Reply by email