Reorganized clone dialog

[antis81]

Here it comes! A polished version of our clone dialog - and more.

The dialog is expandable to show more options, but in its initial state it shows the very simplified version.

:exclamation: Note: Depends on PR 63 in GitWrap.

This is crucial for the following reasons:

• Especially new users to Git will appreciate a small user interface without the screen flooded with options (even if they are all preset with the correct values).
• The workflow must be reasonably fast. Thus, it should be editable just by the keyboard at hand.

For everything else, there's the options panel. When expanding the options, we have three "modes" available (currently titled with "Repository Type"):

• Normal: Creates a normal Git clone of an existing repo, followed by a checkout to the working directory.
• Bare: Creates a bare clone. In this mode, submodule options are not available.
• Mirror: :construction: (not implemented yet) This is a mirrored bare clone of an existing repository.

TODO:

• [x] Complete implementation of options.
• [x] Append the repository name to the destination path, when the checkbox is checked. For a bare clone, it should end with .git
  • At the moment, simply the last segment of "From-URL" is appended. See on Redmine: http://redmine.macgitver.info/issues/214
• [x] States are not completing correctly, which is actually still a bug :beetle:.
• [x] Support alternates (See Git clone docs: http://git-scm.com/docs/git-clone) Not realized in this PR. See redmine (http://redmine.macgitver.info/issues/212)

As of API changes to GW, there'll be more features available:

• [x] Checkout a commit: updates HEAD and index correctly
• [x] Checkout a branch / reference works

Other changes:

• [x] Removed "Close" action from Main menu.
  • It does not work and - at this state - just clutters the menu with useless features. It may be re-added later with lots of polishment.
• [x] Removed "Jump to current branch" action from Refs-View
  • Will be moved to another place and become "Show HEAD".
• [x] Creation of lightweight tags on any commit in history view.

[antis81]

:eyes: Some screenshots to show in more detail what is going on here.

Simple Dialog:

Dialog with options expanded:

[antis81]

:flags: :zap: As GitWrap API received some major changes, I'll use this PR to implement more GitWrap::Operations related stuff.

This allows to finish some features, that got broken or evolved over time. You shall see them in the TODO list :book: above :top:.

[antis81]

:exclamation: I'm just about merging this PR together with the GitWrap API changes (PR mentioned in description).

@scunz This is about ~80 commits of coding goodness! It is not "perfectly finished", but it fixes a lot of our "not yet working" or even "crashing" features, adds more unit-tests (well, stubs actually) and stabilizes what we currently have in MGV. Plus - it is based on the very latest libgit2 v0.22-beta development branch. I want to base the "RepoMan Object-Migration" on the more stable development branch. If you are not happy with this step, please let me know.

[scunz]

@antis81 I've always preferred to build upon libgit2's dev branch :cactus:

[scunz]

The .git "extension" suffix to the repository is no hard requirement - It's not always required and sometimes must even be omitted.

[antis81]

The .git "extension" suffix to the repository is no hard requirement - It's not always required and sometimes must even be omitted.

Yeah, it is not a killerfeature. I'm just asking, because this little feature is useful, but not completely finished. As we are not supporting SSL based protocols at this state, this is not a killerfeature and I can live with that pretty well for the moment.

EDIT: There's a redmine ticket, mentioning that for the release, so this does not get lost.

[antis81]

@antis81 I've always preferred to build upon libgit2's dev branch :cactus:

That's the best we can do. Just ´git pull --rebase lg2 master && "adjust to API" && git push origin master´ and be happy with the latest and greatest API breaks - I love it!

[scunz]

Yeah, it is not a killerfeature.

No, it is a killing feature.

And it doesn't have anything to do with SSL at all.

I can pretty much place a bare or non-bare git repository into any folder on my hard drive and access it via SSH (which is what git does using the git@host:/path syntax, also known from rsync, scp & co.). There's no hard convention that folders which contain bare git repositories have a name ending in .git. Further, I can point whatever web-server or proxy to that directory and access it via http (using the dump protocol stack). Again: No hard requirement that this url is ending in .git.

In fact, major hosting providers support both forms of the url. I.e. in Jenkins you sometimes have to give a https url ending in .git while sometimes you shouldn't do that. Weird, but that's the life out there!

[antis81]

...Again: No hard requirement that this url is ending in .git.

Exactly, it's a naming convention. And there is not a single problem with that, I just want to mention it here, because it needs some final cleanup.

:construction: Example: If you clone with MGV like this (checkbox "Append repository name" is checked): From: http://server.com/my-repo.git To: /whatever/path/you/can/think/of

The resulting path becomes ... surprise :star: /whatever/path/you/can/think/of/my-repo.git No matter if you did a "bare" or "normal" clone. The checkbox does exactly what's written on it, but not what users expect!

If you uncheck "Append repository name", the "To" path stays exactly like you wrote it!

Thus, it is not even a killing feature and completely harmless :smile:.

Think you misunderstood, what I wanted to state with the SSL part. So ... sorry, simply forget about that. It's not working in MGV (especially!).

Back to the important things: This PR helps to get the "update-objects-issue" done right - because we (at least I) can now directly see results (for example by performing a checkout from within history-view) :+1:.

Basically I have two options and this is the reason, I asked you to help making the decision:

1. Merge this PR (including the GW PR63). Then create a new PR for the "update-mgv-objects" stuff.
   • This will improve the presentation of MGV to the public.
     1. Append the "update-mgv-objects" changes on top of this PR and merge when everything is done. I expect the effort to be at least 6 months for a single person - calculating with 4h each and every day.

[scunz]

Despite that there is no public, I still remember the trouble with long-running PRs... So, YES: Merge it.

Remember the open-source credo: "Ship early; ship often" But please, make sure to actually have something to ship.

But, honestly: 6 * 30 * 4 = 720 hours... That ought to be enough to finish the whole project :)

[antis81]

Despite that there is no public, ...

Sorry, but that's truely wrong. Personally, I can name at least 3 (actually more than 10 :) people, just waiting for a working MGV release for windows. This excludes the vast amount of people involved in the project :smile:.

... I still remember the trouble with long-running PRs... So, YES: Merge it.

Thanks, OK. Merge is landing soon :airplane:, please keep your seatbelts closed.

Remember the open-source credo: "Ship early; ship often" But please, make sure to actually have something to ship.

Didn't know that, thanks.

But, honestly: 6 * 30 * 4 = 720 hours... That ought to be enough to finish the whole project :)

Think again ... libgit2 with >1.000 (partly professional) contributors hasn't got a single stable release after how much years now? Just saying ... :). To achieve such a goal, we would really have to make strict, painful and actually really, really bad decisions -we don't want that (77 x :exclamation:). Take the 6 months as a substitution for "I don't know - no really - I DON'T KNOW! Provide me 2-3 developers helping out and they might hold this deadline.". Think you understand :).

I simply can't stop providing those crazy ideas making my head spin :partly_sunny:. It's good to know someone, who really is able to understand them and getting me back to earth :).