Power shortcuts for Git (and other SCM) nerds
Luther Goh Lu Feng
CTRL+SPACE=>git_status_shortcuts- show git status with file shortcutsCTRL+xc=>git_add_and_commit- add given files (if any), then commit staged changesCTRL+xSPACE=>git_commit_all- commit everything
Martin
--
The Python Community in Singapore!
www: http://python.sg
twitter: http://twitter.com/pythonsg
fb: https://www.facebook.com/groups/pythonsg
Official Mailing List/Google Groups:
email address: pyth...@googlegroups.com
web interface: https://groups.google.com/group/pythonsg/topics
irc: http://webchat.freenode.net/?channels=python-sg
Tamas Herman
this is pretty good. i like the trick how it exports the numbers as env vars.
im a big fan of this kind of abbreviations too,
although the really great solution would be something like
what we have in textmate / sublime when we are looking for file names.
if this interface would be the default for git, i wouldn't hate it so much ;)
however darcs is similarly convenient, except it is still just 1
executable file,
so i still prefer that & recommend for both beginners and professionals too...
--
tom
ps: just in the past few days i wasted 30+minutes because of git again...
the problem w it is quite complex. ppl can't learn it fast, misuse it and then
u can fight w the mess...
most common idiocity is to just version control everything in the project
directory, no matter if it's already version controlled somewhere or not.
git encourages this because it gives no easy way _by default_ to easily
pick the files u want to add to the repo.
it's not obvious how to checkout only the current state without the
full history.
in darcs even this is interactive and obvious...
all this is magnified when u try to do things on a lower bandwidth...
the other problem is the git commit -am which adds all the shit into a commit
overwriting a lot of things potentially, especially if u forgot to
pull before hand.
in darcs, even if u dont pull 1st, u have a lot lower chance for conflicts.
i can tell u from practice we hardly hit any conflicts w darcs, while i just
joined to a pretty young repo with 60 commits as the 3rd person.
it already had a conflict fix and my second really minor commit cause
a conflict too.
i think that's bullshit. it hurts more than it helps...
Martin Bähr
> ps: just in the past few days i wasted 30+minutes because of git again...
> the problem w it is quite complex. ppl can't learn it fast, misuse it and then
> u can fight w the mess...
tell us more...
> most common idiocity is to just version control everything in the project
> directory, no matter if it's already version controlled somewhere or not.
either something is to me versioned or it isn't. if it is then it shoudl
be in. if it isn't then it should be out. if you have local
configuration, that of course should be out.
> it's not obvious how to checkout only the current state without the
> full history.
you clone the complete history. you checkout the current state.
whether you clone the history or not (as in svn) has no effect
on your checkout. when i use git to clone an svn repo (which clones the
whole history) i get the same checkout as when checking out with svn
directly.
> the other problem is the git commit -am which adds all the shit into a commit
> overwriting a lot of things potentially, especially if u forgot to
> pull before hand.
you seem to be missing something. sure, -a adds all changes automatically.
but it won't overwrite anything! if you commit the wrong stuff you can
revert it or amend it.
what made you think that something got overwritten?
and pull also has nothing to do with it. anything that you didn't pull
lives happily in the remote branch ready for you to pull any time. that
is one of the nice things, unlike svn you are not forced to pull if you
are not ready.
personally i never pull. i fetch, and then i examine the remote branch
and then i decide when i am ready to merge, and then i merge. no
overwrites happening here either.
> in darcs, even if u dont pull 1st, u have a lot lower chance for conflicts.
> i can tell u from practice we hardly hit any conflicts w darcs, while i just
> joined to a pretty young repo with 60 commits as the 3rd person.
i hardly hit conflicts with git either. let the same group of people use
darcs on the same project and then see what happens...
greetings, martin.
--
cooperative communication with sTeam - caudium, pike, roxen and unix
services: debugging, programming, training, linux sysadmin, web development
--
pike programmer working in china community.gotpike.org
foresight developer (open-steam|caudium).org foresightlinux.org
unix sysadmin iaeste.at realss.com
Martin B�hr http://www.iaeste.at/~mbaehr/ is.schon.org
Martin
Martin Bähr http://www.iaeste.at/~mbaehr/ is.schon.org
--
Chat: http://hackerspace.sg/chat
Tay Ray Chuan
> most common idiocity is to just version control everything in the project
> directory, no matter if it's already version controlled somewhere or not.
> git encourages this because it gives no easy way _by default_ to easily
> pick the files u want to add to the repo.
Are you talking about
$ git add --all
? You can use
$ git add <path1> <path2>...
instead, just don't say 'git add .' (dot) that adds all files under
the directory you're in.
> it's not obvious how to checkout only the current state without the
> full history.
I believe the feature you're referring to in Darcs is
$ darcs get --lazy
? In git, this is known as a shallow clone, you can do it with
$ git clone --depth 1
but I think you already know this. You may be right that it's not
obvious how to do this in git from the documentation, most people just
grit their teeth through a full clone.
> in darcs even this is interactive and obvious...
> all this is magnified when u try to do things on a lower bandwidth...
Speaking about interactivity, yeah, in most places git doesn't enable
it by default, you have to specify it with a switch. IIRC,
interactivity seems more like an afterthought, being implemented with
Perl (eg. git add -p).
--
Cheers,
Ray Chuan
Tamas Herman
im following git almost since it's birth around 2005.
ppl are still
- talk about it a lot
- write big books
- create fancy cheat sheets
- make new front ends
- blog about tricks and how big fan of it are they
that's 6 yrs...
im using darcs since ~2004 personally.
i used collaboratively with 4 developers around 2006 for the 1st time.
i read the documentation in 2 nights.
referred back to it for another week or too occasionally
until i actually learnt and remembered even more advanced stuff.
that's it.
in those 7yrs, i didn't have to learn anything new about it.
no cheat sheets, no blogs, no bullshit. im just using it as is on linux & mac
and ~3 yrs ago it became pretty usable on windows too.
(ok, ssh on windows was a bit tricky 2yrs ago but that's not strictly
darcs related)
important to mention that i hardly ever have to deal with merge
conflicts either, unlike with git where it was a daily phenomena...
also important to mention that u dont have to create branches all the time.
u can use http://wiki.darcs.net/SpontaneousBranches
it's another means of saving time w darcs...
i could use my unwasted time to teach darcs to ~10 ppl in 1-2hrs.
a few more hours of mentoring and exercising made them expert users.
by that i mean they can do serious branch management quite confidently,
unlike git users who are using git for months...
everyone of them were very pleased with it
and didn't want to go back to anything else
or learn any other version control system afterwards.
i wouldn't hesitate though to convert a repo to GIT
IF 10+ppl would actively contribute (like every day)
to a repo with 10MB+ *own* code
OR many seriously differing branches
AND i would experience merge or performance issues.
-------------------
martin bahr:
most of our own project repos depend on software being present in our
repo directory tree, although these software are already version
controlled in their own repos.
for example:
- jquery and other js libs
- back in the day rails plugins / gems
- now nodejs modules
to mention a few.
still ppl commit these into their repository.
eventhough
- these things are multiple magnitudes bigger than the actual project itself
- contain files which they never use or even look at
- documentation
- unit tests
- all these have to be upgraded from time to time,
adding big patches/changes to the repo
this adds extra load on many levels:
- version control system
- network transfers
- peer reviewers
- co-developers
- sysadmins
- backup time & storage
i dont want to go into this deeper now; maybe i will blog about it some time.
-------------
regarding this fetch 1st then examine, sure it's a good approach, it's
just clunky in git.
in darcs "pull" is interactive so u can immediately examine the
patches before application.
it does have a fetch command though, but i never had to use it.
--
tom
Jason Ong
James Yuen
git, and I say this as someone who loves using git.
On the other hand, from what I've seen with new users who have no
background of version control systems, git does seem to come a bit
easier without any preconceived notions of how a vcs should work. At
least when I was learning git, that's probably where I spent most of
my time trying to change my thinking (and it didn't help some terms
are used in different vcs but with different meanings).
I really think (one of) the best part(s) about git is that it can be
as simple as you want it to be, or as complicated as you need it to
be. Perhaps if there were more tutorials that highlighted this.
On Nov 3, 5:57 pm, Jason Ong <velve...@gmail.com> wrote:
> Epic.
>
> http://think-like-a-git.net/epic.html
>
2er0
team, i'm gonna become one too....
Senthil Kumaran
git and p4. CVS is out of place now, but right now, I use rest of them
actively for different projects and fail to see any difference between
the version control systems.
What I encourage is for any new developer or development team is to
learn the use version control systems and use to effectively. I think,
the whole point of version control systems was to help you not be
afraid of experimenting, which is a kind of most important armor for a
developer.
--
Senthil
> --
> Chat: http://hackerspace.sg/chat
Tamas Herman
> To me, all version control systems are same. I have used cvs, svn, hg,
> git and p4. CVS is out of place now, but right now, I use rest of them
> actively for different projects and fail to see any difference between
> the version control systems.
<cynic>
of course u can't see a difference!
'coz u haven't tried http://darcs.net ;P
</cynic>
how often do u have to do code merges and resolve conflicts?
with darcs, i hardly ever have to do it.
w git, aaaall the time, even if it's just a small and new project w 2
developers...
and it's getting really bad if u start branching.
and u do start, because it's advertised to be easy.
ridiculous. especially after the darcs experience,
where it happens really rarely...
--
tom
Chow Loong Jin
> <cynic>
> of course u can't see a difference!
> 'coz u haven't tried http://darcs.net ;P
> </cynic>
>
> how often do u have to do code merges and resolve conflicts?
> with darcs, i hardly ever have to do it.
> w git, aaaall the time, even if it's just a small and new project w 2
> developers...
> and it's getting really bad if u start branching.
> and u do start, because it's advertised to be easy.
> ridiculous. especially after the darcs experience,
> where it happens really rarely...
Many of the merge conflicts come from things being changed too close to each
other. I don't mind the merge conflicts in these cases, as they have the
potential to introduce some rather nasty bugs that are hard to find and fix if
they were merged in the wrong order.
git rerere solves this problem in a rather nice manner, I think. It resolves
conflicts for you based on past resolutions, while leaving the files marked as
unmerged so you can check to make sure that it's done the correct thing (and it
usually does, with rare exceptions).
<troll>Also, git merges happen really quickly. The wikipedia article for
darcs[0] mentions something about darcs' merges taking exponential time.</troll>
[0] https://secure.wikimedia.org/wikipedia/en/wiki/Darcs
--
Kind regards,
Loong Jin
Patrick Haller
> the whole point of version control systems was to help you not be
> afraid of experimenting
Absolutely. Reduce the costs of working with code.
Tamas is just saying that git's merge-babying seems expensive to him.
Patrick
Tamas Herman
exactly!
thanks for putting it in a nutshell.
> git merges happen really quickly
it's exactly like the joke about the intel FPU bug:
u ask and AMD and an Intel processor:
how much is 2 + 2?
5! - said Intel immediately
4. - said AMD a tiny little bit later
but 5 is not correct!
Intel: sure, but i was fast, wasn't i?
http://www.netjeff.com/humor/item.cgi?file=PentiumJokes
we have experienced a slowdown once with darcs v1 in 2007 maybe but a
"darcs optimize" sped it up. that was the only time i ever used that
command. we NEVER hit any problems w darcs v2 though. all these
whining about this exponential merge problems are from the past. what
is presumably still present from the issue has only happened in maybe
2 private repositories, so there is not even public, reproducible
evidence of an exponential merge. however, git conflicts happen all
the time...
so indeed it is just trolling, because u r reviving obsolete
information which might scare ppl away.
--
tom
Lucian Teo
Chow Loong Jin
>
> so indeed it is just trolling, because u r reviving obsolete
> information which might scare ppl away.
"Although the issue was not completely corrected in Darcs 2,[5] exponential
merges have been minimized. Unfortunately, bugs still remain in which the
merging of recursive conflicts fails[6]."
I didn't say it. Wikipedia did. If you feel it is incorrect, please feel free to
correct the article.
Chow Loong Jin
hijack, let's bring out the graphs:-
Based on Debian's popularity contest:-
Git:
<http://qa.debian.org/popcon-graph.php?packages=git&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1>
Darcs:
<http://qa.debian.org/popcon-graph.php?packages=darcs&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1>
The statistic here seems to show some rather impressive growth in the number of
git users but little more or less no change in Darcs users. I won't pretend to
know anything about Darcs here, so I'm curious, is Darcs falling out of favour
with developers, or something? If so, why?
Chow Loong Jin
Actually here's a better graph which shows git and darcs together instead of
separately:
<http://qa.debian.org/popcon-graph.php?packages=darcs+git&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1>
Senthil Kumaran
of darcs vs git. Clubbing it with popularity is like saying, Miss
{Universe, World, Galaxy} is the most intelligent person in their
respective sphere. It is quite unrelated. :-)
Chow Loong Jin
> I thought, we were discussing technical merits and some design issues
> of darcs vs git. Clubbing it with popularity is like saying, Miss
> {Universe, World, Galaxy} is the most intelligent person in their
> respective sphere. It is quite unrelated. :-)
Somehow you'd expect the best tool to be growing in popularity, wouldn't you?
But somehow it froze at 2008.
Tay Ray Chuan
Looking at Darcs' "patch" model, I don't ever think that merges in
Darcs can be optimized to the level where it's as fast as Git, because
of the underlying algorithm - it will try to compute inverses,
commutations, etc. [1]
[1] http://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory#Merging)
Git on the other hand doesn't give a s**t about what the commit
history in either side of the merge - it just looks at the files, runs
a diff, then does the merge.
--
Cheers,
Ray Chuan
Tay Ray Chuan
> Based on Debian's popularity contest:-
> Git:
> <http://qa.debian.org/popcon-graph.php?packages=git&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1>
> Darcs:
> <http://qa.debian.org/popcon-graph.php?packages=darcs&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1>
>
> The statistic here seems to show some rather impressive growth in the number of
> git users but little more or less no change in Darcs users.
There's actually a reason behind the "impressive growth". I quote [1]:
On Sat, Oct 29, 2011 at 4:28 PM, Miles Bader <mi...@gnu.org> wrote:
> 2011/10/29 Miles Bader <mi...@gnu.org>:
>> That the sharpness of that graph is pretty amazing though; what
>> happened in 2010Q1?
>
> Actually, now I realize what happened: that's the date the Debian
> "git-core" package was renamed "git" (the "git" package used to be
> "gnu interactive tools")!!
So the git users were there all the while - it was after 2010 that we
"saw" them.
[1] http://article.gmane.org/gmane.comp.version-control.git/184449
--
Cheers,
Ray Chuan
Chow Loong Jin
> So the git users were there all the while - it was after 2010 that we
> "saw" them.
>
> [1] http://article.gmane.org/gmane.comp.version-control.git/184449
Ah yes, that's true. popcon graph link:
<http://qa.debian.org/popcon-graph.php?packages=git-core+git+darcs&show_installed=on&want_legend=on&want_ticks=on&date_fmt=%25Y-%25m&beenhere=1>
Martin Bähr
> git, and I say this as someone who loves using git.
yeah, i agree, when i read that page i felt a bit overwhelmed. how does
graph theory help me understand git?
sure, i use the history graphs all the time, when ever i am not sure
about whats going on and what the state should be i look at the graph
and can see where very commit is and what should be merged, cherrypicked
etc...
but i don't need graph theory for that. reachability? i can see where
the lines go, that's all that's needed...
> I really think (one of) the best part(s) about git is that it can be
> as simple as you want it to be, or as complicated as you need it to
> be. Perhaps if there were more tutorials that highlighted this.
totally.
i am working with a student here using eclipse and git. (eclipse has
some decent git integration) i am slowly teaching him how to work with
git. starting from making commits and and showing him how that adds a
new dot on the line. look, there is your latest change. and we can look
at the difference to compare it to see what changed.
i am avoiding merge for now and just do rebases if i have changes so
that we keep a linear history. (this mostly to be able to use rebase -i
later to clean out some commits that shouldn't have happened before we
make the code public)
maybe darcs makes that easier when merges are involved, but what from my
experience darcs doesn't do (or at least i could not figure out how to
do) is to give me a checksum over the current state of a repository.
for my own sanity i need an easy way to tell that your checkout and mine are
identical, means that you have the exace same patches as i have yielding
the exact same result.
greetings, martin.
--
cooperative communication with sTeam - caudium, pike, roxen and unix
services: debugging, programming, training, linux sysadmin, web development
--
pike programmer working in china community.gotpike.org
foresight developer (open-steam|caudium).org foresightlinux.org
unix sysadmin iaeste.at realss.com
Tamas Herman
Benjamin Scherrey
--
tom
--
Chat: http://hackerspace.sg/chat
Tamas Herman
<mba...@email.archlab.tuwien.ac.at> wrote:
> On Thu, Nov 03, 2011 at 05:00:55AM -0700, James Yuen wrote:
> maybe darcs makes that easier when merges are involved, but what from my
> experience darcs doesn't do (or at least i could not figure out how to
> do) is to give me a checksum over the current state of a repository.
>
> for my own sanity i need an easy way to tell that your checkout and mine are
> identical, means that you have the exace same patches as i have yielding
> the exact same result.
" An untagged repository state can still be identified unambiguously
by a context file, as generated by `darcs changes --context'. "
-- from http://darcs.net/manual/bigpage.html#SECTION00642000000000000000
for in-house projects it's very unlikely u need this.
u either checkout the source up to the the latest release tag or
checkout the most up-to-date version and try to reproduce the issue in question.
as a bonus here are some minor tweaks to improve darcs' convenience
even further :
export DARCS_DO_COLOR_LINES=1 # so u have colored diffs during "commit"
and my ~/.darcs/defaults looks like this now:
ALL look-for-adds
the --look-for-adds shows/considers new, untracked files for the
whatsnew, amend and record commands.
in case u are using tabs as the indentation character, u can
reconfigure the terminal to print only 2 or 4 space when it encounters
a tab character by running:
tabs -2 # on a mac at least
i prefer tabs, because it is possible to adjust their size in editors,
which is really important if you are using proportional fonts. (my
choice is the Optima font. for this week :)
--
tom