... But since I have perfectionist tendencies...With that said: Do get some kind of VCS!-Armando (February 19, 2011, 02:39 PM)
With that said: Do get some kind of VCS!-Ath (February 19, 2011, 02:59 PM)
get some version control, right now. Even if you're never going to collaborate with other people, you'll learn to appreciate it. VCS serves as part of a backup scheme, it's easier to find particular versions of your source code than dealing with timestamped copies, and once you become disciplined and write proper commit messages and commit at a proper granularity, you'll see you have some powerful tools at hand to search history, track regressions, managed branches et cetera. It does take a bit getting really used to VCS and reap all the benefits, but it's worth investing time in it.-f0dder (February 20, 2011, 05:39 PM)
If I were starting from nothing, I think I'd consider Mercurial over SVN - it seems less complex than Git and seem a bit more Windows friendly. [...] I'm considering converting my personal SVN repository to Mercurial, and hosting it on https://bitbucket.org/ where you can have free private repositories.-mwb1100 (February 20, 2011, 04:32 PM)
* Fetching the entire Notepad++ Community Release wia Git via my 20mbit ADSL is faster than grabbing fSekrit with subversion on my gigabit LAN. Nuff' said?-f0dder (February 20, 2011, 05:39 PM)
* Since dvcs store all files locally in addition to the (optional) remote repository, switching branches or datamining history is lightning fast. With subversion, even on a gigabit lan some operations can be painfully slow.-f0dder (February 20, 2011, 05:39 PM)
* Subversion stores it's info in ".svn" folders in each and every subfolder of your project. This is ugly, it means you have to use "svn export" to grab/export a clean subtree, and if you forget to do this and copy subfolders around in your svn-managed project, you can screw things up majorly. Both Hg and Git use a single top-level folder per project.-f0dder (February 20, 2011, 05:39 PM)
* Even though subversion has metadata scattered in all those .svn folders, you don't have the full project history locally - so if your remote repository goes AWOL, you're screwed. With Hg and Git, your own machine has a full local copy of all history.-f0dder (February 20, 2011, 05:39 PM)
* Subversion doesn't treat branches and tags specially, but just as part of the filesystem. This does, kinda, give you some flexibility, but it's flex you don't need, and it can cause a lot of clutter and fuss if you aren't very disciplined with how you arrange stuff.-f0dder (February 20, 2011, 05:39 PM)
* Branches in svn always go to your repository, meaning they're slightly slow operations to perform, they "pollute" the namespace, etc. Thus, with svn, you think a lot before you make a branch, especially on a multi-dev project. With Hg and Git, you can do local "feature branches" to work on without disturbing other people, and merge those to the current working branch before pushing your changes upstream. In other words, YOU have a lot of flexibility on your own machine, without necessarily cluttering things for everybody else. Even on single-dev projects, it's nice being able to take a break from adding a new feature to fix a bug, and then merge it all together.-f0dder (February 20, 2011, 05:39 PM)
And if you stay clear of svn, you won't need to muck around with converting your repositories when you feel like ditching it at some later point-f0dder (February 20, 2011, 05:39 PM)
I'm considering converting my personal SVN repository to Mercurial, and hosting it on https://bitbucket.org/ where you can have free private repositories. If bitbucket ever goes away, that's not a big deal since any workspace I have is essentially a full backup of the repository. Moving my hosted SVN stuff was a bit of a pain when my 1st hoster dropped their free plans.-mwb1100 (February 20, 2011, 04:32 PM)
1.6.1. Subversion
Subversion is a popular revision control tool, developed to replace CVS. It has a centralised client/server architecture.
Subversion and Mercurial have similarly named commands for performing the same operations, so if you're familiar with one, it is easy to learn to use the other. Both tools are portable to all popular operating systems.
Prior to version 1.5, Subversion had no useful support for merges. At the time of writing, its merge tracking capability is new, and known to be complicated and buggy [http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword].
Mercurial has a substantial performance advantage over Subversion on every revision control operation I have benchmarked. I have measured its advantage as ranging from a factor of two to a factor of six when compared with Subversion 1.4.3's ra_local file store, which is the fastest access method available. In more realistic deployments involving a network-based store, Subversion will be at a substantially larger disadvantage. Because many Subversion commands must talk to the server and Subversion does not have useful replication facilities, server capacity and network bandwidth become bottlenecks for modestly large projects. Additionally, Subversion incurs substantial storage overhead to avoid network transactions for a few common operations, such as finding modified files (status) and displaying modifications against the current revision (diff). As a result, a Subversion working copy is often the same size as, or larger than, a Mercurial repository and working directory, even though the Mercurial repository contains a complete history of the project.
Subversion is widely supported by third party tools. Mercurial currently lags considerably in this area. This gap is closing, however, and indeed some of Mercurial's GUI tools now outshine their Subversion equivalents. Like Mercurial, Subversion has an excellent user manual.
Because Subversion doesn't store revision history on the client, it is well suited to managing projects that deal with lots of large, opaque binary files. If you check in fifty revisions to an incompressible 10MB file, Subversion's client-side space usage stays constant The space used by any distributed SCM will grow rapidly in proportion to the number of revisions, because the differences between each revision are large.
In addition, it's often difficult or, more usually, impossible to merge different versions of a binary file. Subversion's ability to let a user lock a file, so that they temporarily have the exclusive right to commit changes to it, can be a significant advantage to a project where binary files are widely used.
Mercurial can import revision history from a Subversion repository. It can also export revision history to a Subversion repository. This makes it easy to “test the waters” and use Mercurial and Subversion in parallel before deciding to switch. History conversion is incremental, so you can perform an initial conversion, then small additional conversions afterwards to bring in new changes.
1.6.2. Git
Git is a distributed revision control tool that was developed for managing the Linux kernel source tree. Like Mercurial, its early design was somewhat influenced by Monotone.
Git has a very large command set, with version 1.5.0 providing 139 individual commands. It has something of a reputation for being difficult to learn. Compared to Git, Mercurial has a strong focus on simplicity.
In terms of performance, Git is extremely fast. In several cases, it is faster than Mercurial, at least on Linux, while Mercurial performs better on other operations. However, on Windows, the performance and general level of support that Git provides is, at the time of writing, far behind that of Mercurial.
While a Mercurial repository needs no maintenance, a Git repository requires frequent manual “repacks” of its metadata. Without these, performance degrades, while space usage grows rapidly. A server that contains many Git repositories that are not rigorously and frequently repacked will become heavily disk-bound during backups, and there have been instances of daily backups taking far longer than 24 hours as a result. A freshly packed Git repository is slightly smaller than a Mercurial repository, but an unpacked repository is several orders of magnitude larger.
The core of Git is written in C. Many Git commands are implemented as shell or Perl scripts, and the quality of these scripts varies widely. I have encountered several instances where scripts charged along blindly in the presence of errors that should have been fatal.
Mercurial can import revision history from a Git repository.
Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time. :) Or am I missing something ?That's probably the main reason the icon overlays in Windows Explorer turn red if something has changed locally. You have to take action yourself though, no auto-commit (nor would I want that).-Armando (March 02, 2011, 10:06 AM)
Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time. :) Or am I missing something ?First, there's no way to really tell when a file modification is done and complete - the best heuristic you could go by is "file has been modified, and now hasn't been additionally modified for n seconds".-Armando (March 02, 2011, 10:06 AM)
Committing changes is a voluntary action and, knowing myself, I'll obviously forget to commit important changes from time to time. :) Or am I missing something ?-Armando (March 02, 2011, 10:06 AM)
That's probably the main reason the icon overlays in Windows Explorer turn red if something has changed locally. You have to take action yourself though, no auto-commit (nor would I want that).
You haven't mentioned the programming environment/IDE you are using for your project. Maybe that has an integration, as most of the big IDE's have it (NetBeans, Eclipse and descendants, Visual Studio). Some of them can even warn you if you try to close without committing your changes.-Ath (March 02, 2011, 10:16 AM)
First, there's no way to really tell when a file modification is done and complete - the best heuristic you could go by is "file has been modified, and now hasn't been additionally modified for n seconds".
Second, you don't want commits based on random modifications - at least when programming, you'll often be doing a related set of changes across a few files, and then commit that. Think of it as not commiting files, but committing features :)-f0dder (March 02, 2011, 10:53 AM)
One thing that git was able to do (but I'm not sure if Mercurial supports this or not) is collapsing a set of changes at the 'tip' of a branch into a single change. Git also lets you drop changes that are at the tip (though it's pretty easy to get them back if you do it by accident, since the change isn't really gone, it's just not at the tip anymore). What these features enable is that you can commit your local changes at will, without too much regard for whether or not they're 'correct'. Until you push the changes, they aren't seen by anyone else, and when you have something you want to push publicly, you can squash (that's the term git uses) the several changes into a single, coherent change, and push that to the public repository.-mwb1100 (March 02, 2011, 11:10 AM)
Usage Patterns
This extension is particularly useful when you follow the practice of committing regularly to your local repository, possibly before you've got anything sufficiently complete to be put in a shared repository. Rather than filling the changelog with changes of the "OK it almost works now" type, you can collapse all of your intermediate commits before pushing to the shared repository.
N.B. 'hg collapse' is destructive; it rewrites history. Therefore you should never collapse any changeset that has been pushed to another repository, unless you really know what you are doing.-http://mercurial.selenic.com/wiki/CollapseExtension
First, there's no way to really tell when a file modification is done and complete - the best heuristic you could go by is "file has been modified, and now hasn't been additionally modified for n seconds".
Second, you don't want commits based on random modifications - at least when programming, you'll often be doing a related set of changes across a few files, and then commit that. Think of it as not commiting files, but committing features :)-f0dder (March 02, 2011, 10:53 AM)
Wouldn't that be a sound feature request ? Would you use it ?Nope, some language/tools/developers using vcs controlled source induce so many changes, that can be relatively unimportant, but need to be checked in at one moment, while in another environment, a single line changed can make a world of difference that needs to be committed at once. So change-counting doesn't count :P-Armando (March 03, 2011, 01:45 PM)
Nope, some language/tools/developers using vcs controlled source induce so many changes, that can be relatively unimportant, but need to be checked in at one moment, while in another environment, a single line changed can make a world of difference that needs to be committed at once. So change-counting doesn't count :P-Ath (March 03, 2011, 02:01 PM)
They change only on F5, and sometimes they don't. I have to open/close the repo/folder for them to update.That's related to 2 things: Settings in the TortoiseXX tooling (Check out 'Icon overlays'), and the sometimes flaky icon-cache of Windows (including Win7)-Armando (March 03, 2011, 08:18 PM)
I probably shouldn't but I'm currently looking at Git.Oh yes, you should, if you have the time, resources and interest in it.-Armando (March 04, 2011, 03:19 PM)
I've settled on Git for moving fSekrit forwards, but that's mainly because of Git's "blow off your legs" power with regards to history rewriting - I want to make the codebase public, but retain no memory in the public codebase from the non-public versions. Yet, at the same time, I want the private repository to have FULL history, and do that without committing future versions to both public and private repositories. Git supports that (even if I haven't worked out the details of how to set it up 100% :)).-f0dder (March 04, 2011, 03:28 PM)
History of a single function that moves? Interesting. That's not something inherent in how git stores the version history, though, unless I've missed something - Git stores the full version of each file for each commit, whereas both subversion and Mercurial store changesets (iirc Mercurial also stores a full-version "every once in a while" so moving between versions doesn't become too slow). But IOW, if Git can do it, it's gotta be history analyzing magic smartness that could potentially be done by everybody else too?-f0dder (March 04, 2011, 03:28 PM)
From what I've seen from various comparisons, Git and Mercurial offer most of the same features, as long as you don't need the über-wicked geek functionality (Mercurial pretty much won't let you blow your legs off). Also seems like there's not massive speed differences for "normal" size projects.-f0dder (March 04, 2011, 03:28 PM)
Git seems a bit more down and dirty, and the tortoise version still isn't as polished as the tortoise versions of other version control systems... it still shows a bit that Git was originally a whole bunch of shell scripts, instead of designing it "properly" as a C/C++ library with a "proper" front-end :)-f0dder (March 04, 2011, 03:28 PM)
I probably shouldn't but I'm currently looking at Git.Oh yes, you should, if you have the time, resources and interest in it.-Armando (March 04, 2011, 03:19 PM)
Making a more educated choice now (early/pre-start) is way better than to change half way through your project, if you then discover a feature in the other solution you absolutely must have, for whatever reason.-Ath (March 04, 2011, 03:30 PM)
I use git with great success, but it does have drawbacks, namely poor support for Windows platform.
It is very fast even with large repositories.
AFAIK mercurial has much wider platform support than git, but is also rather slow. This is from hearsay though.
I chose git at that time because it was the new shit.-housetier (March 04, 2011, 04:12 PM)
The 'portable Git preview' software (for Windows) you can get from softpedia looks to be very promising.
And together with SmartGit (http://www.syntevo.com/smartgit/index.html) (free for personal use) it starts to look quite nice as well.
One hell of lot better than WinCVS at least ;)
**EDIT
Added the SmartGit part.-Shades (March 04, 2011, 04:50 PM)
One question : You'll still be able to commit code from the private to the public repo even if you squashed the changesets/history in the public one ??? I most probably don't understand properly as I'm not sure how that would work.Well, I'm still not 100% on how it works under the hood, but the idea is that after "going public", you don't touch the old private repo, you keep doing all new development in the public one, and the private is kept just for the history - but is able to show entire history.-Armando (March 04, 2011, 10:07 PM)
In any case, I've edited Mercurial's ini file to add the "collapse" extension and it seems to load properly. Haven't properly tested it yet. Collapsing changesets is probably not too dangerous when working alone, but I don't know about team work. Potential for disaster.As long as you don't collapse changesets that have already been pushed, you should be fine - so do all your crazy-small local commits, collapse changesets to your liking, then push remotely and you should be fine :)-Armando (March 04, 2011, 10:07 PM)
Each git command is like a Swiss Army knife. For example, git checkout can switch the working directory to a new branch, update file contents to that of a previous revision, and even create a new branch. It’s an efficient way to work once you learn all the arguments and how they interact with each other.
Mercurial is like a well-equipped kitchen — it has a lot of tools that each do one simple, well-defined thing, and do it well. To switch the working directory you use hg update. To update file contents to what they were at a previous revision you use hg revert. To create a new branch you use hg branch. This means there are more commands to learn, but each command is much simpler and more specific to a single conceptual task.- http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
1 As a benchmark, Git and Mercurial repositories were seeded with approximately 1500 files totaling 35 M of data. The servers were running in Chicago and the clients in Mountain View (51 ms ping time). The operation of cloning the remote repository (similar to a initial checkout in traditional version control systems) averaged 8.1 seconds for Mercurial and 178 seconds for Git (22 times slower). A single file in the repository was then changed 50 times and the clients pulled the updates. In this case, Mercurial took 1.5 seconds and Git required 18 seconds (12 times slower). When the Git protocol was used instead of HTTP, Git's performance was similar to Mercurial (8.7 seconds for cloning, 2.8 seconds for the pull).-http://code.google.com/p/support/wiki/DVCSAnalysis
Armando: nice post - DoCoCoins coming your way. More, please! :)
On speed: first, you have to do some manual cleanup of Git repositories every once in a while, to do garbage collection and (re)pack the repository - this helps wrt. speed and disk space consumption. This can of course be automated, but it's something you have to automate, Git doesn't do it for you.-f0dder (March 08, 2011, 03:53 AM)
"Users are encouraged to run this task on a regular basis within each repository to maintain good disk space utilization and good operating performance."
Some git commands may automatically run git gc; see the --auto flag below for details.
Occasionally, Git automatically runs a command called “auto gc”. Most of the time, this command does nothing. However, if there are too many loose objects (objects not in a packfile) or too many packfiles, Git launches a full-fledged git gc command. The gc stands for garbage collect, and the command does a number of things: it gathers up all the loose objects and places them in packfiles, it consolidates packfiles into one big packfile, and it removes objects that aren’t reachable from any commit and are a few months old.
You can run auto gc manually as follows:
$ git gc --auto
Again, this generally does nothing. You must have around 7,000 loose objects or more than 50 packfiles for Git to fire up a real gc command. You can modify these limits with the gc.auto and gc.autopacklimit config settings, respectively.
builtin/merge.c: const char *argv_gc_auto[] = { "gc", "--auto", NULL };
builtin/receive-pack.c: "gc", "--auto", "--quiet", NULL,
git-am.sh: git gc --auto
git-rebase--interactive.sh: git gc --auto &&
git-svn.perl: command_noisy('gc', '--auto');
From git grep -- --auto on git.git, those results looked interesting. The notable one is builtin/merge.c meaning that the ever so common git pull should trigger a git gc --auto.
Additionally, unless your 'non-technical' staff is doing rather 'advanced' stuff (at which point they wouldn't be 'non-technical' anymore), I don't see why they would ever need to run git gc manually instead of just letting git gc --auto handle everything.
If you need the fastest system and don’t mind occassional performance glitches and volatile repository sizes, git is the way to go. Note that its speed drops to half the speed of Mercurial (and less for big repositories, since the time for the garbage collection rises linearly) if Git is forced to avoid frequently growing and shrinking repositories by running the garbage collection every ten commits. Also note that git gc --auto allowed the repository to grow to more than 5 times the minimum size and that garbage collection created 100% load for 3 of my 4 cores which would slow down all other processes on a server, too (otherwise gc would likely have been slower by factor 3).... :)
If you need reliable performance and space requirements, Mercurial is the better choice, especially when called directly via its API. Also for small repositories with up to about 200 commits, it is faster than git even without garbage collection.
Also, there's definitely been a lot of progress in Git over the years. Considering that more and more has been going from shell scripts -> native C code, it's probably not fair looking at a 2 years old benchmark :)-f0dder (March 08, 2011, 03:53 AM)
On Tortoise... I've been considering moving away from it. Yes, the icon overlays in explorer are kinda nice, but that's about it - I feel that a dedicated app would probably provide more efficient workflows. Also, having cache processes for t-svn, t-git, t-hg seems a bit much, and I often run into problems with those processes keeping folders locked when they shouldn't.
Dunno which app(s), though - I wasn't all impressed when I checked out SmartGit, but can't remember exactly why, guess I'll give it another chance. I think my 'meh' was partially causes by the program being implemented in Java, and (worse) not having an option to use the system JDK but installing it's own separate copy.-f0dder (March 08, 2011, 03:53 AM)
I find that all these GUIs have limitations. And, yes, having all these tortoise running at the same might cause some caching problem. Although I've read that they're now supposed to play well together (speaking of the icons overlay here).Oh, the problems I've had are there even with a single Tortoise flavor installed - dunno if it "stacks up" when there's multiple versions. Happens relatively rarely, but enough that it's a minor annoyance.-Armando (March 08, 2011, 10:50 AM)
Features :
• Support for operations: Commit, Revert, Resolve, Compare, Update, Tags, Push, Pull, Incoming, Outgoing, Merge, Clone, Bundle, Archive, Annotate (Blame), View File, Grep, Bookmarks, Rebase
• File history dialog with support of file differencing
• Support tracking of file renames in file history dialog
• Support external file comparison tools
• Revisions graph log. This feature is similar to hgk, hgview and tortoiseHg change log window
• Support for merging revisions
• Support for rebasing revisions
• Support for inline file difference in most of package windows
• Support for bookmarks-http://www.newsupaplex.pp.ru/hgwin_news_eng.html
Nice that you're continuing with this - appreciated :)-f0dder (March 15, 2011, 03:02 AM)
I still don't have a definitive favorite wrt. GUIs. TortoiseGit, gitk and git-gui all feel a bit rough around the edges. I'm not sure exactly what it is, probably the overall combination of several smaller flaws ("mid 90's linux GUI look", progress not always updated before the command is done (related to calling git.exe and parsing textual output?), et cetera).-f0dder (March 15, 2011, 03:02 AM)
PS: "The sluggishness is probably" -> ends mid-sentence.-f0dder (March 15, 2011, 03:02 AM)
I follow this thread with great interest, but lack of time got me never further than actually using the software.
So keep up the good work! :Thmbsup:-Shades (March 16, 2011, 01:05 PM)
I do have a question though: I assume it is possible to search for a particular change by a particular user using any of the GUI tools?
(the lack of that option is something I absolutely hate from WinCVS / CVS (which I am forced to work with).)-Shades (March 16, 2011, 01:05 PM)
not having an option to use the system JDK but installing it's own separate copy.Currently there is something like the following bit in section 5.4 of the bundled file quick-start-guide.pdf:-f0dder (March 08, 2011, 03:53 AM)
5.4 JRE search order (Windows)
On Windows, the smartgit.exe launcher will search for an appropriate JRE in the following order (from top to bottom):
- Environment variable SMARTGIT JAVA HOME
- Sub-directory jre within SmartGit’s installation directory
- Environment variable JAVA HOME
- Environment variable JDK HOME
- Registry key HKEY LOCAL MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment
The staging area is a simple file, generally contained in your Git directory, that stores information about what will go into your next commit. It’s sometimes referred to as the index, but it’s becoming standard to refer to it as the staging area.
Unlike other, similar tools you may have used, Git does not commit changes directly from the working tree into the repository. Instead, changes are first registered in something called the index. Think of it as a way of “confirming” your changes, one by one, before doing a commit (which records all your approved changes at once). Some find it helpful to call it instead as the “staging area”, instead of the index.
One of the features that git users talk about often is git’s index (http://book.git-scm.com/1_the_git_index.html). Mercurial has the record (http://mercurial.selenic.com/wiki/RecordExtension) extension, but it’s not really the same thing.
I personally don’t like the index. I feel that git encourages people to check in changesets that contain code which they’ve never tested (or even built) because the index is such a prominent part of git’s workflow.
Yes, one can argue that you don’t actually push changes until you’ve got a working state. The problem is that when you then try to run git bisect later to find a bug you’ll have to waste time skipping over changesets that don’t build. You could use git rebase --interactive to fold partial changesets into one big one, but again, my gut feeling is that few people actually bother testing the results.-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
With all that said, I’ve considered creating a Mercurial extension that adds git’s index functionality to Mercurial, because I think it would make the transition to Mercurial easier for git users. I’ve had enough experience with Mercurial’s internals to know that such a thing is possible, but I simply don’t have the time to do it all myself. If you’re interested in helping out please let me know!-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
It is important to note that it is the contents that are stored, not the files. The names and modes of the files are not stored with the blob, just the contents.
This means that if you have two files anywhere in your project that are exactly the same, even if they have different names, Git will only store the blob once. This also means that during repository transfers, such as clones or fetches, Git will only transfer the blob once, then expand it out into multiple files upon checkout.
The record extension provides the record command, which may be used in lieu of commit. This command lets you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks.
The crecord extension is a curses (i.e. text-based GUI) interface which provides the crecord and qcrecord commands that may be used in lieu of commit or qnew -f. These commands let you choose which parts of the changes in a working directory you'd like to commit, at the granularity of patch hunks or lines.
sometimes you forget to be proactive about separating your changes and then you want to untangle them after the fact. You can do this using the Record extension. This is another extension that ships with Mercurial, but you have to enable it to use it.
The Record extension is invoked with "hg record" and will go through the files you've changed (or just the ones you tell it to look at) and will iterative over each change "hunk" in the file. A change hunk is a set of sequentially changed lines. For each hunk it asks you if you want to record the change or not. You simply say "y" if you want it, and "n" if you don't.
The result is a new commit that contains the changes you recorded. It's a surprisingly easy process.
However, there's a flaw with this approach. The resulting commit might be broken: it might not compile, or the tests might not pass. And since it turns directly into a commit, you don't really get the chance to test it...
There's also the MQ extension (Mercurial Queue). I remember liking MQ a lot.This looked interesting to me, but I never tried it out. Perhaps some day...-Armando (May 10, 2011, 10:01 AM)
I don't have the time to discuss that in depth, but I also remember that I found it easier to work with the "index" like features in Git using the GUI (Git GUI), than with Mercurial (Tortoise Hg). Things are changing fast though and I'll revisit tortoise Hg in a while to see how it does this whole "partial commit" thing.Looking forward to nicer UIs :)
Perhaps I'll try out gitsum for Emacs in the mean time:
http://chneukirchen.org/blog/archive/2008/02/introducing-gitsum.html
BTW, any thoughts on the likes of:
http://nvie.com/posts/a-successful-git-branching-model/
It does miss some other important ones though, like “blame”, “stash”, “clone –bare” (last one : surprising, to say the least… Unless I missed something).-Armando (March 15, 2011, 12:26 AM)
1- some kind of optional “console like” textual feedback, some commands log view, like the one Git extensions provides (see #4). That would be good (maybe is that a secretly available option but… I didn’t find it).Not quite what you may have been looking for, but if you look in the .settings directory, there is a file named "log.txt" which contains various details. Perhaps better than nothing...-Armando (March 15, 2011, 12:26 AM)
log.txt contains debug log information. It's configured via log4j.properties.
Is it possible or configurable to view the Git commands executed by SmartGit somewhere? It would be awesome if they were displayed in the status bar or a console popup.
You can find the executed Git commands (and the output of the Git command) in SmartGit's log.txt.
It would be awesome if they were displayed in the status bar or a console popup.
My log file is in not in the .setting directory but in \Application Data\syntevo\SmartGit\2.Ah, my bad...Perhaps it's in .settings for me because I'm using the portable version.-Armando (May 18, 2011, 09:26 AM)
Anyway... considering all that, SmartGit is probably what I'll try to use more in the next week.Looking forward to any observations :)
Looking forward to any observations :)-ewemoa (May 18, 2011, 10:35 PM)
BTW, I wanted to search the history of a project via the log window and was stumped initially. I learned that "search as you type" (they call this speed-search apparently) seems to work. Was this obvious to you? I didn't find this in the docs...it was again via a posting to that support list.
Then I spent a while trying to figure out how to search for subsequent occurrences -- finally after trying a variety of combinations, I hit on using the down (for next) and up (for previous) arrow keys...feels odd but at least something works.-ewemoa (May 18, 2011, 10:35 PM)
On a related note, I've started to investigate gitk and am noticing that it seems to produce more search results than SmartGit for the same search terms in some cases. It appears that SmartGit doesn't load all commits [1] by default and the searching only seems to take place over what's loaded -- once sufficiently more commits are loaded, additional search results seem to come up...
[1] Found a "Load all commits" menu item via the Query menu.-ewemoa (May 18, 2011, 10:35 PM)
Dunno which app(s), though - I wasn't all impressed when I checked out SmartGit, but can't remember exactly why, guess I'll give it another chance. I think my 'meh' was partially causes by the program being implemented in Java, and (worse) not having an option to use the system JDK but installing it's own separate copy.SmartGit offers three download bundles for Windows, the default one which includes a Java Runtime Environment (so the normal users are using a tested JRE version), one without a bundled JRE (requires an installed one) and a portable one with JRE (stores its settings in the same directory structure, so it can be installed on an USB stick).-f0dder (March 08, 2011, 03:53 AM)
It does miss some other important ones though, like “blame”,"blame" is on our todo-list. Could you please explain the use-case behind "clone --bare"? Isn't a bare repository usually located on a server without GUI?“stash”, “clone –bare” (last one : surprising, to say the least… Unless I missed something [I did miss the "stash" command which was very obvious :-[ ] ).-Armando (March 15, 2011, 12:26 AM)
I did encounter a few problems and solving these problems meant dropping to the command line. E.g. : how do you "correct" a rebase that’s stalled… and won't abort nor continue ? hmmmm... 8)Do you mean, that SmartGit sometimes hangs during a rebase? This bug has been fixed in version "2.1 early-access build 5". This was caused by Git trying to open an editor and waiting for it to exit.-Armando (March 15, 2011, 12:26 AM)
The manual is ok, but not as clear as Tortoise’s, IMHO. Very dry, almost no graphs… and so it remains slightly abstract. I’d almost rather read Git’s man pages (not bad at all btw).You are right, our manual is a weak spot.-Armando (March 15, 2011, 12:26 AM)
On a related note, I've started to investigate gitk and am noticing that it seems to produce more search results than SmartGit for the same search terms in some cases. It appears that SmartGit doesn't load all commits [1] by default and the searching only seems to take place over what's loaded -- once sufficiently more commits are loaded, additional search results seem to come up..."Load all commits" does not load all commits from the repository (which might be too large), but instead loads commits which are not reachable from a branch or tag any more, e.g. those which remain after performing an amend-commit. Maybe one has a better name suggestion?
[1] Found a "Load all commits" menu item via the Query menu.-ewemoa (May 18, 2011, 10:35 PM)
Wow, nope, I didn't know about the search as you type feature.What shortcut did you expect? What we can do to make the "search-as-you-type" feature more noticeable?
Thanks for sharing all this!
Yes, the arrows do feel a bit odd, but I'll get use to it.-Armando (May 19, 2011, 09:00 AM)
It does miss some other important ones though, like “blame”,"blame" is on our todo-list. Could you please explain the use-case behind "clone --bare"? Isn't a bare repository usually located on a server without GUI?“stash”, “clone –bare” (last one : surprising, to say the least… Unless I missed something [I did miss the "stash" command which was very obvious :-[ ] ).-Armando (March 15, 2011, 12:26 AM)-syntevo (May 19, 2011, 01:26 PM)
I did encounter a few problems and solving these problems meant dropping to the command line. E.g. : how do you "correct" a rebase that’s stalled… and won't abort nor continue ? hmmmm... 8)Do you mean, that SmartGit sometimes hangs during a rebase? This bug has been fixed in version "2.1 early-access build 5". This was caused by Git trying to open an editor and waiting for it to exit.-Armando (March 15, 2011, 12:26 AM)-syntevo (May 19, 2011, 01:26 PM)
The manual is ok, but not as clear as Tortoise’s, IMHO. Very dry, almost no graphs… and so it remains slightly abstract. I’d almost rather read Git’s man pages (not bad at all btw).You are right, our manual is a weak spot.-Armando (March 15, 2011, 12:26 AM)-syntevo (May 19, 2011, 01:26 PM)
Wow, nope, I didn't know about the search as you type feature.What shortcut did you expect? What we can do to make the "search-as-you-type" feature more noticeable?
Thanks for sharing all this!
Yes, the arrows do feel a bit odd, but I'll get use to it.-Armando (May 19, 2011, 09:00 AM)-syntevo (May 19, 2011, 01:26 PM)
As you probably know, a lot of Windows applications (text editors, IDEs) use F3 and Shift/ctrl+F3 to move to next/previous occurrence (can't talk about Linux or Mac as I haven't really worked with those in the last couple years and I forgot...). I couldn't say for sure what the standard is, but F3 is what I'm used to... Hence the "awkward" feel.-Armando (May 20, 2011, 02:18 PM)
| Chrome 11 | Firefox 4 | IE 8 | Opera 11 | |
| Enter / Shift+Enter | o | o | o | o |
| Control+G / Control+Shift+G | o | o | x | o |
| F3 / Shift+F3 | o | o | x | o |
| Alt+N / Alt+P | x | o | x | x |
As you probably know, a lot of Windows applications (text editors, IDEs) use F3 and Shift/ctrl+F3 to move to next/previous occurrence (can't talk about Linux or Mac as I haven't really worked with those in the last couple years and I forgot...). I couldn't say for sure what the standard is, but F3 is what I'm used to... Hence the "awkward" feel.OK, I'll try to add (Shift+) F3 in the next 2.1 build. Unfortunately, this will be hard-coded and not customizable, because only the shortcuts for menu items are customizable.-Armando (May 20, 2011, 02:18 PM)
- Some other shortcuts feel a bit weird. E.g.: Ctrl+T for staging. I immediately changed it for Alt+Enter, and Ctrl+Alt+Enter for editing the index, which seems much more natural when reviewing changes using Alt+Arrows. This is personal of course... but just saying.We took Ctrl+T from the Git GUI. BTW, I have changed Alt+Up/+Down to F3/F4 so I only need one hand for navigation...-Armando (May 20, 2011, 02:18 PM)
- After staging some content, the focus always moves to the newly staged file, which interrupts the "files modifications reviewing". There might be a way to prevent that but I haven't found it. Question: Could the focus remain at the top of the list and not move? When reviewing files before committing , it's inconvenient to always have to move back to the top of the file list or where the other file to review is located.We'll try to find a solution.-Armando (May 20, 2011, 02:18 PM)
- Some tooltips seem too verbose.IMHO "Show unchanged files" is ambiguous: it could mean the current state or the action which happens when clicking. Hence we decided to be precise.
E.g., in the files section/table : "if selected, unchanged files will be shown".
Why not simply : "Show unchanged files" ? It's more "to the point" IMO.-Armando (May 20, 2011, 02:18 PM)
BTW, have you seen the same author's post on Mercurial Queues?
With all that said, I’ve considered creating a Mercurial extension that adds git’s index functionality to Mercurial, because I think it would make the transition to Mercurial easier for git users. I’ve had enough experience with Mercurial’s internals to know that such a thing is possible, but I simply don’t have the time to do it all myself. If you’re interested in helping out please let me know!-http://stevelosh.com/blog/2010/01/the-real-difference-between-mercurial-and-git/
... So maybe this index isn't that useless after all. :)-Armando (May 09, 2011, 11:48 AM)
Thanks for the comments, and for the link to Mercurial Queues. It's true that queues are something that Git doesn't have; but then again, they're not needed in Git because it has (cheap) branches and you can reorder the commits afterwards.
However, using Mercurial Queues is definitely not the same as using the Git index, nor should it be confused as such. Yes, using Queues can enable you to do (local) feature branching (which is good) but Git's index is the set of things you are *about* to commit.
A case in point: I was merging the old Mac ZFS code and the onnv_72 code, which involved a significant merge set (see https://github.com/alblue/mac-zfs/commit/6d20fbb74f11a). Putting the changeset into perspective: "Showing 604 changed files with 422,503 additions and 1,496 deletions" is the message that GitHub shows.
There is no way I would have been able to commit that with Mercurial Queues. For a start, 100-200 files were in conflict, which would mean either (a) putting some changes in with the conflict markers in place, or (b) backing out the merge node and applying changes incrementally, i.e. doing a manual merge.
However, using the Git index, I was able to solve one conflicted file at a time, and add it into the git index when I had de-conflicted that file. The git status was then able to tell me those files which were different from the index (i.e. those ones which I hadn't de-conflicted yet) and as such, give me a progress report on how far down the de-confliction line was. Once I had all conflicts addressed, and added into the git index, I was able to commit the merge node separately.
So don't get me wrong; I think if you have to use Hg then an extension like Queues (and histedit etc.) are absolutely necessary tools to have at your disposal. But they just replace built in functions of the git tree structure and in no way are able to replace the index.
...and give the gource developer more practice with OpenGL may be..-ewemoa (May 31, 2011, 05:34 AM)
And there's this great blog article (also fairly recent -- recommended) : Mercurial and Git: a technical comparison (http://alblue.bandlem.com/2011/03/mercurial-and-git-technical-comparison.html).-Armando (May 27, 2011, 03:00 PM)
One question- it seems that your repository in the case that you're not using something like github is purely local- is this true?-wraith808 (June 05, 2011, 08:26 PM)
And is there a way to have a copy of the repository without another machine?
if A and B are on a network, you can directly pull to A from B and conversely.-Armando (June 07, 2011, 09:35 AM)
I've used Tortoise SVN with the Express editions of Visual C#. Can Mercurial or GIT either one be used with these Express versions, or do they only function with the Professional/Enterprise versions of the Visual Studio IDE?-kyrathaba (June 08, 2011, 05:31 PM)
Thanks for your help with this. I'm going to try to set it up tomorrow.-wraith808 (June 07, 2011, 11:25 PM)
env GIT_SSL_NO_VERIFY=true git clone https://example.com:4567/myrepos.git
env GIT_SSL_NO_VERIFY=true path-to-smartgit-folder/bin/smartgit.sh
set GIT_SSL_NO_VERIFY=true
start c:\apps\SmartGit\bin\smartgit.exe
Project ->
New Window ->
Open an existing local or create a new repository
On a side note, I noticed that SmartGit now supports "git init" -- IIRC, it used to be that one had to use git from the command line for this :up:Project ->
New Window ->
Open an existing local or create a new repository-ewemoa (April 22, 2012, 05:49 AM)
Did you send a message to the developer(s) ?-Armando (April 23, 2012, 11:06 PM)
i believe SmartGit has been offering the "Open an existing local or create a new repository" for a while (since v2.x) . I might be mistaken though...
BTW, does any one know how to tell -- via the Main perspective -- which branch one is on?-ewemoa (May 06, 2012, 06:49 AM)
In the the "directories" section/pane, the top directory should have the branch specified in parenthesis.**-Armando (May 06, 2012, 12:19 PM)
Explicit copy and move operations are not possible, Git recognizes them automatically.
Only the contents of the middle and the right editor can be modified. You can alter the contents of the Index either by editing the contents of the middle editor, or by moving chunks between the three editors. To do so, either click on the arrow and 'x' buttons between the editors, or click on the Take Left and Take Right buttons on the toolbar. After you're done, save your changes and close the Index Editor.
FWIW, it looks like there is some kind of stash support (at least in the 2.x series):-ewemoa (May 16, 2011, 11:12 PM)
Git is fun, isn't it ?-Armando (November 26, 2012, 09:27 AM)
Rebase, not as much. Maybe because I'm mostly working on my own, I don't mind having a few meaningless commits.
Apart from that, yes, stashing can be extremely useful. E.g. for those times where I find a bug that should be fixed before pursuing some coding : stash the current work, do the bug fixing, come back to previous coding by reapplying stash.
You mentioned renaming in a previous post. I still use the command line when I want to do an explicit file rename. But I usually don't have to as Git detects those if you're careful not committing renames with a bunch of other changes.
SmartGit proved to be quite user friendly, stable and helpful. Used it almost exclusively, together with TortoiseGit which has some great features implementations too (I especially like the fact that I can select and copy commits from the log view and I'll get a nice clean copy of all of them, with the comments... I use that for quickly creating reports). Also, SmartGit now supports Hg, which is a good thing for those of us who use mercurial !
Did my first interactive rebase today -- great stuff :up:
Wanted to see if SmartGit has some nice GUI for it and found:
http://smartgit.3668570.n2.nabble.com/Interactive-rebasing-td7572897.html (http://smartgit.3668570.n2.nabble.com/Interactive-rebasing-td7572897.html)
Don't know if there's anything there yet -- have you come across anything?-ewemoa (November 24, 2012, 08:36 AM)
Before pushing, you can cleanup your commits visually (except of merge commits): reorder commits by using drag and drop, join adjacent commits or edit commit messages.
The commit appears to include the selected files even if changes from them have not been registered with the index.-ewemoa (December 30, 2012, 05:53 PM)
Visual Studio will have Git support – and concretely, we released a CTP of a VSIX plugin for the Visual Studio 2012 Update 2 CTP today.
...
Why are we incorporating Git?
When we made the decision that we were going to take the DVCS plunge, we looked at many options. Should we build something? Buy something? Adopt OSS? We looked at Git, Mercurial and others. It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS. We thought hard about building something. Git hasn’t been as friendly for Windows developers as on other platforms. By building on Git, we can take all the time we might spend just “catching up” and spend that effort on something where we can add more distinctive value. Choosing Git just made sense.
...
Older versions of VS & TFS – At this time, we are not planning to include Git integration in older versions of VS or TFS.
Interesting to see MS adopt Git as an official first-rate citizen.
And it's going to be interesting to see what "His Screwyouness" has to say about this ;p-f0dder (January 30, 2013, 02:22 PM)
Who is His Screwyouness?Linus Torvalds - he tends to flip people off and call them nasty names and such - and now Evil Inc. is taking his baby and putting it into one of their big, nasty producst? Uh oh! :)-wraith808 (January 30, 2013, 02:55 PM)
Linus Torvalds - he tends to flip people off and call them nasty names and such - and now Evil Inc. is taking his baby and putting it into one of their big, nasty producst? Uh oh! :)-f0dder (January 30, 2013, 03:06 PM)
I was glad to see there is something like libgit2 (http://libgit2.github.com/) that can be used for stuff like this, because quite frankly the half-baked msys smells-like-posix-spirit on top of Windows bash scripts all over the place official git is an abomination on Windows.Yeah, nice to see that indeed!-Jibz (January 31, 2013, 01:15 AM)
I was glad to see there is something like libgit2 (http://libgit2.github.com/)-Jibz (January 31, 2013, 01:15 AM)
I was glad to see there is something like libgit2 (http://libgit2.github.com/)-Jibz (January 31, 2013, 01:15 AM)
Ooo, how nice. Thanks for the link :Thmbsup:-ewemoa (January 31, 2013, 07:16 AM)
The Lost Heads will show all commit heads which are not accessible from a tag or branch.
I have been using the following handy tip in SmartGitHg recently with some success:
Depending on the conditions, I found it's possible to modify the content of commits older than the most recent [1].
The most recent commit can be made available for editing via the "Undo Last Commit" command. Sometimes it's possible to use the "Reorder Commits" command to make an older commit the most recent commit. Once that is done, the "Undo Last Commit" command can be applied to it, modifications performed, and a new replacement commit can be created. It may then be possible to reorder the new commit back into its original position (so-to-speak).
When this works I find it simpler than doing git rebase -i <sha-of-parent-commit-of-interest> from the command line.
[1] Strictly speaking the commit isn't being modified -- a new sequence of commits is created with appropriate content, but I assume most folks interested in doing this sort of thing know this already :)-ewemoa (June 15, 2013, 07:42 AM)
being able to stage individual hunks is a really nice way to avoid commits that contain multiple unrelated changes.-Jibz (August 31, 2013, 05:21 AM)
Funny and sad at the same time!-ewemoa (May 09, 2014, 09:06 PM)
Unfortunately no luck reaching the three under "Lots of screencasts/videos… Here are some interesting URLs with a few fun tricks"...-ewemoa (October 20, 2014, 06:11 PM)
On a side note, haven't read it recently, but at some point I found the following useful:
https://mercurial.selenic.com/wiki/GitConcepts
(Please note specifically the section about Git's staging area -- section 2.2.)-ewemoa (July 07, 2015, 01:05 AM)
I've been using SourceTree (http://sourcetreeapp.com/) to easily handle making/merging/closing branches for the Gitflow workflow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (in Mercurial) and TortoiseHg (http://tortoisehg.bitbucket.org/) for all the actual committing, shelving, pushing, pulling, etc.-Deozaan (July 07, 2015, 01:21 AM)
(for instance chapter 2 of Git Internals (https://github.com/pluralsight/git-internals-pdf))-Jibz (July 07, 2015, 04:59 AM)
With --patch, you can interactively select hunks from the diff
between HEAD and the working tree to be stashed. The stash entry is
constructed such that its index state is the same as the index
state of your repository, and its worktree contains only the
changes you selected interactively. The selected changes are then
rolled back from your worktree. See the “Interactive Mode” section
of git-add(1) to learn how to operate the --patch mode.
Also, I'm a little confused about something with regard to how Git stores blobs. I like how it doesn't care about files or filenames, and that if the content is the same, it will only store it once. But doesn't that mean if you make one tiny change to a file, it has to store the entire file again as if it was a brand new file? Shouldn't that make the size of the repo huge?-Deozaan (July 08, 2015, 04:53 PM)
While that's true and important on the conceptual level, it is NOT true at the storage level.
Git does use deltas for storage.
But I have to admit I got totally lost on the subject of rebasing. Usually when I had trouble following the descriptive text, I could look at the illustrations and figure out exactly what was going on. But I'm still not grasping how rebasing works or exactly what it does after having fully read the text and studied the illustrations for some time.-Deozaan (July 08, 2015, 04:53 PM)
Check out the part that starts:While that's true and important on the conceptual level, it is NOT true at the storage level.
Git does use deltas for storage.
toward the end of http://stackoverflow.com/questions/8198105/how-does-git-store-files/8198276#8198276
I don't know about being more efficient than any other system, but regarding storing deltas, I have seen that claim in a few other places (sorry, didn't find references so far).-ewemoa (July 08, 2015, 05:09 PM)
But I have to admit I got totally lost on the subject of rebasing. Usually when I had trouble following the descriptive text, I could look at the illustrations and figure out exactly what was going on. But I'm still not grasping how rebasing works or exactly what it does after having fully read the text and studied the illustrations for some time.-Deozaan (July 08, 2015, 04:53 PM)
Among other things, the following has a section on rebasing with images:
https://marklodato.github.io/visual-git-guide/index-en.html
There's also this:
https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Do those help at all?-ewemoa (July 08, 2015, 05:22 PM)
Just to muddy the waters here a bit, it looks like a new desktop version of git is coming, promising "the same, native experience on OS X and Windows operating systems":
desktop.github.com (https://desktop.github.com/)-irkregent (July 10, 2015, 03:48 PM)
Came across gource (http://code.google.com/p/gource/) -- "a software version control visualization tool" -- anyone tried it out?
Sample videos (http://code.google.com/p/gource/wiki/Videos) and screenshots (http://code.google.com/p/gource/wiki/Screenshots) :)-ewemoa (May 31, 2011, 04:28 AM)