>
> I'm not sure what I did. Was running fine. I did have a systems error that
> mentioned some hardware problem. It restarted ok. Perhaps it corrupted a
> file.
can you look in ~/.bash_history (or the equivalent for whatever shell you're
using) to see what you did?
--
You received this
physics would make a lot of good, the simple and direct solution is more
> efficient. That's just my opinion. I wish a real git developer would give
> some more insights about the arcane syntax of git cmd line.
>
>
>
> On Sunday, February 3, 2013 1:02:32 AM UTC-5, Les Nigh
I think every one of us has asked this same question at some point early in our
work with git.
There have been many attempts to sweeten the syntax with sugar. But mostly we
struggle through the abominable syntax and love git for it's great power and
flexibility.
It will help you a lot with the
Dmitris: all my work is solo and I love git. The git command line is (for me)
non-intuitive and inconsistent, but the ease of making ad hoc branches to try
some ideas, and then abandon or merge is unrivaled.
Les
On Dec 19, 2012, at 12:30 PM, Dimitris Papageorgiou wrote:
> Do you think git woul
The way I have handled this is to have the app configurable with a "theme"
concept. So the way the app appears depends on a variable that is on the server
of the particular instance. This way I have a single codebase that looks
different depending on what server it's running from.
Will this wor
If you just want to back up your code base, then git may not be the right
tool. But if you have ongoing development, it's a great tool. IMHO its
biggest strength is the ability to create an experimental code branch, hack
a bunch of changes in the branch and later decide either to merge the
bran
The first thing you need to try to diagnose is whether:
a. the far end is falling back to password access b/c it cannot
authenticate the public key you're sending
b. the pc thinks the local private key requires a password for access
if you can try an ssh connection using the keys with verbose mod
is it possible to pull all the test-only pieces of code from a "test_only"
file, that is ignored by git. Include the test code in such a way that if
the "test_only" file is not present, the production code still holds
together.
On Friday, July 6, 2012 11:42:58 AM UTC-7, Tim Chase wrote:
>
> I'v
Thank you PJ... yes you are exactly correct. I'm not clear, though,
why the mvim default in this scenario is to open in background.
On Mar 22, 11:01 am, PJ Weisberg wrote:
> On Wednesday, March 21, 2012, Les Nightingill
> wrote:> Solved! (not entirely sure why, though!). Postin
Solved! (not entirely sure why, though!). Posting the solution here for
future Googlers.
The solution is on
StackOverflow
http://stackoverflow.com/questions/4737381/git-editor-not-working-with-macvim
The solution is this configuration:
git config --global core.editor "mvim -f"
Strange thing
same as doing git
> rebase -i HEAD)?
>
> Usually I rebase like this (if I want to edit the last 5 commits): git
> rebase -i HEAD~5
>
> On Wednesday, March 21, 2012 8:11:54 PM UTC+1, Les Nightingill wrote:
>>
>> ...trying to understand how interactive rebase works
...trying to understand how interactive rebase works...
under what circumstances does git rebase -i
simply complete and present an empty git-rebase-todo for editing (i.e.
without a list of commits for me to pick/edit/squash etc)?
In my test, the rebase completes with the message "Successfully
re
12 matches
Mail list logo
