* Re: [PATCH 0/3] git-mergetool/difftool: TortoiseMerge and (g)vimdiff for Windows
From: Johannes Schindelin @ 2009-04-05 13:52 UTC (permalink / raw)
To: Markus Heidelberg
Cc: Junio C Hamano, git, msysgit, David Aguilar, Charles Bailey
In-Reply-To: <200904051440.33154.markus.heidelberg@web.de>
Hi,
On Sun, 5 Apr 2009, Markus Heidelberg wrote:
> Patches 2/3 and 3/3 are already in 'da/difftool' in 'pu'. This series is
> based on 'master', now they can be applied to 4msysgit.git.
Thanks, they are in, as branch 'tortoisemerge'.
Ciao,
Dscho
^ permalink raw reply
* [RFC/PATCH 2/2] Add new 'git stage' script
From: Felipe Contreras @ 2009-04-05 13:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1238939331-10152-2-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Makefile | 1 +
git-stage.sh | 28 ++++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
create mode 100644 git-stage.sh
diff --git a/Makefile b/Makefile
index 0c3de6b..a1837fc 100644
--- a/Makefile
+++ b/Makefile
@@ -291,6 +291,7 @@ SCRIPT_SH += git-rebase.sh
SCRIPT_SH += git-repack.sh
SCRIPT_SH += git-request-pull.sh
SCRIPT_SH += git-sh-setup.sh
+SCRIPT_SH += git-stage.sh
SCRIPT_SH += git-stash.sh
SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
diff --git a/git-stage.sh b/git-stage.sh
new file mode 100644
index 0000000..a5b3ad8
--- /dev/null
+++ b/git-stage.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+
+case "$1" in
+add)
+ shift
+ git add $@
+ ;;
+rm)
+ shift
+ git rm --cached $@
+ ;;
+diff)
+ shift
+ git diff --cached $@
+ ;;
+import)
+ shift
+ git ls-files --modified --others --exclude-standard -z | \
+ git update-index --add --remove -z --stdin
+ ;;
+ls)
+ shift
+ git ls-files --stage $@
+ ;;
+*)
+ git add $@
+ ;;
+esac
--
1.6.2.2.406.g45db3f
^ permalink raw reply related
* [RFC/PATCH 1/2] git: remote stage
From: Felipe Contreras @ 2009-04-05 13:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
In-Reply-To: <1238939331-10152-1-git-send-email-felipe.contreras@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
Documentation/git-stage.txt | 19 -------------------
Makefile | 1 -
git.c | 1 -
3 files changed, 0 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/git-stage.txt
diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt
deleted file mode 100644
index 7f251a5..0000000
--- a/Documentation/git-stage.txt
+++ /dev/null
@@ -1,19 +0,0 @@
-git-stage(1)
-==============
-
-NAME
-----
-git-stage - Add file contents to the staging area
-
-
-SYNOPSIS
---------
-[verse]
-'git stage' args...
-
-
-DESCRIPTION
------------
-
-This is a synonym for linkgit:git-add[1]. Please refer to the
-documentation of that command.
diff --git a/Makefile b/Makefile
index 7867eac..0c3de6b 100644
--- a/Makefile
+++ b/Makefile
@@ -345,7 +345,6 @@ BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
BUILT_INS += git-show$X
-BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
diff --git a/git.c b/git.c
index c2b181e..ebc3ccb 100644
--- a/git.c
+++ b/git.c
@@ -267,7 +267,6 @@ static void handle_internal_command(int argc, const char **argv)
const char *cmd = argv[0];
static struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
- { "stage", cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply },
{ "archive", cmd_archive },
--
1.6.2.2.406.g45db3f
^ permalink raw reply related
* [RFC/PATCH 0/2] New 'stage' command
From: Felipe Contreras @ 2009-04-05 13:48 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Felipe Contreras
Hi,
The 'stage' is probably the most novel-yet-missunderstood feature of git, and
somehow the user interface is not exploiting it properly, even to the point
where it doesn't even have a consistent name (stage, index, cache, etc)
This patch series is one approach that has been working reasonably well for me,
which is to replace the 'git stage' command to map different actions that can
be executed with it.
For example 'git stage diff' is more natural (at least to me) than 'git diff
--cached', same goes for 'git stage rm foo.c' vs 'git rm --cached foo.c'.
This is the list of actions I've mapped:
* add: git stage = git stage add (git add)
* rm: (git rm --cached)
* diff: (git rm --cached)
* import: stage all files; modified, deleted, new
* ls: (git ls-files --stage)
Felipe Contreras (2):
git: remote stage
Add new 'git stage' script
Documentation/git-stage.txt | 19 -------------------
Makefile | 2 +-
git-stage.sh | 28 ++++++++++++++++++++++++++++
git.c | 1 -
4 files changed, 29 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/git-stage.txt
create mode 100644 git-stage.sh
^ permalink raw reply
* Re: [PATCH 4/4] replace_object: use the new generic "sha1_pos" function to lookup sha1
From: Johannes Schindelin @ 2009-04-05 13:19 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <20090404225941.7fef76a7.chriscool@tuxfamily.org>
Hi,
On Sat, 4 Apr 2009, Christian Couder wrote:
> instead of the specific one that was simpler but less efficient.
>
> Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
> ---
> replace_object.c | 24 +++++++++---------------
> 1 files changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/replace_object.c b/replace_object.c
> index 1227214..eb59604 100644
> --- a/replace_object.c
> +++ b/replace_object.c
> @@ -1,4 +1,5 @@
> #include "cache.h"
> +#include "sha1-lookup.h"
> #include "refs.h"
>
> static struct replace_object {
> @@ -7,23 +8,16 @@ static struct replace_object {
>
> static int replace_object_alloc, replace_object_nr;
>
> +static const unsigned char *replace_sha1_access(size_t index, void *table)
> +{
> + struct replace_object **replace = table;
> + return replace[index]->sha1[0];
> +}
I have to agree with Junio that this is potentially slowing down things,
as there is an additional redirection layer here.
If the tables are not too large, I'd prefer using a
struct sha1_list_entry {
unsigned char *sha1;
void *object;
};
Hmm.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Johannes Schindelin @ 2009-04-05 13:11 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git
In-Reply-To: <20090404225926.a9ad50e0.chriscool@tuxfamily.org>
Hi,
On Sat, 4 Apr 2009, Christian Couder wrote:
> This function has been copied from the "patch_pos" function in
> "patch-ids.c" but an additional parameter has been added.
>
> The new parameter is a function pointer, that is used to access the
> sha1 of an element in the table.
Frankly, this is hard to follow.
It would have been easier if the first patch added that parameter, and the
second patch just _moved_ the function.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 3/3] git-mergetool: add new merge tool TortoiseMerge
From: Markus Heidelberg @ 2009-04-05 12:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, msysgit, Johannes Schindelin, David Aguilar, Charles Bailey
In-Reply-To: <200904051440.33154.markus.heidelberg@web.de>
TortoiseMerge comes with TortoiseSVN or TortoiseGit for Windows. It can
only be used as a merge tool with an existing base file. It cannot be
used without a base nor as a diff tool.
The documentation only mentions the slash '/' as command line option
prefix, which refused to work, but the parser also accepts the dash '-'
See http://code.google.com/p/msysgit/issues/detail?id=226
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-mergetool.txt | 3 ++-
Documentation/merge-config.txt | 2 +-
git-mergetool.sh | 16 +++++++++++++---
3 files changed, 16 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 5d3c632..5edac4d 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -26,7 +26,8 @@ OPTIONS
--tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge,
+ tortoisemerge and opendiff
+
If a merge resolution program is not specified, 'git-mergetool'
will use the configuration variable `merge.tool`. If the
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 9c44af8..8c10f66 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -23,7 +23,7 @@ merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
"tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff",
- "ecmerge" and
+ "ecmerge", tortoisemerge and
"opendiff". Any other value is treated is custom merge tool
and there must be a corresponding mergetool.<tool>.cmd option.
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 6e611e9..be9717a 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -265,6 +265,16 @@ merge_file () {
fi
status=$?
;;
+ tortoisemerge)
+ if base_present ; then
+ touch "$BACKUP"
+ "$merge_tool_path" -base:"$BASE" -mine:"$LOCAL" -theirs:"$REMOTE" -merged:"$MERGED"
+ check_unchanged
+ else
+ echo "TortoiseMerge cannot be used without a base" 1>&2
+ status=1
+ fi
+ ;;
*)
if test -n "$merge_tool_cmd"; then
if test "$merge_tool_trust_exit_code" = "false"; then
@@ -345,7 +355,7 @@ valid_custom_tool()
valid_tool() {
case "$1" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge | tortoisemerge)
;; # happy
*)
if ! valid_custom_tool "$1"; then
@@ -404,9 +414,9 @@ fi
if test -z "$merge_tool" ; then
if test -n "$DISPLAY"; then
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld kdiff3 tkdiff xxdiff gvimdiff"
+ merge_tool_candidates="meld kdiff3 tkdiff xxdiff tortoisemerge gvimdiff"
else
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
--
1.6.2.2.460.g49e5c
^ permalink raw reply related
* [PATCH 2/3] git-mergetool/difftool: make (g)vimdiff workable under Windows
From: Markus Heidelberg @ 2009-04-05 12:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, msysgit, Johannes Schindelin, David Aguilar, Charles Bailey
In-Reply-To: <200904051440.33154.markus.heidelberg@web.de>
Under Windows vimdiff and gvimdiff are not available as symbolic links,
but as batch files vimdiff.bat and gvimdiff.bat. These files weren't
found by 'type vimdiff' which led to the following error:
The merge tool vimdiff is not available as 'vimdiff'
Even if they were found, it wouldn't work to invoke these batch files
from git-mergetool.
To solve this, use vim and gvim (vim.exe and gvim.exe) and pass the -d
command line switch over to them.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
contrib/difftool/git-difftool-helper | 10 ++++++++--
git-mergetool.sh | 10 ++++++++--
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index 9c0a134..e481913 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -86,11 +86,11 @@ launch_merge_tool () {
;;
vimdiff)
- "$merge_tool_path" -c "wincmd l" "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -d -c "wincmd l" "$LOCAL" "$REMOTE"
;;
gvimdiff)
- "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -d -c "wincmd l" -f "$LOCAL" "$REMOTE"
;;
xxdiff)
@@ -160,6 +160,12 @@ init_merge_tool_path() {
merge_tool_path=$(git config mergetool."$1".path)
if test -z "$merge_tool_path"; then
case "$1" in
+ vimdiff)
+ merge_tool_path=vim
+ ;;
+ gvimdiff)
+ merge_tool_path=gvim
+ ;;
emerge)
merge_tool_path=emacs
;;
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 87fa88a..6e611e9 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -214,12 +214,12 @@ merge_file () {
;;
vimdiff)
touch "$BACKUP"
- "$merge_tool_path" -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
+ "$merge_tool_path" -d -c "wincmd l" "$LOCAL" "$MERGED" "$REMOTE"
check_unchanged
;;
gvimdiff)
touch "$BACKUP"
- "$merge_tool_path" -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
+ "$merge_tool_path" -d -c "wincmd l" -f "$LOCAL" "$MERGED" "$REMOTE"
check_unchanged
;;
xxdiff)
@@ -359,6 +359,12 @@ init_merge_tool_path() {
merge_tool_path=`git config mergetool.$1.path`
if test -z "$merge_tool_path" ; then
case "$1" in
+ vimdiff)
+ merge_tool_path=vim
+ ;;
+ gvimdiff)
+ merge_tool_path=gvim
+ ;;
emerge)
merge_tool_path=emacs
;;
--
1.6.2.2.460.g49e5c
^ permalink raw reply related
* [PATCH 1/3] doc/merge-config: list ecmerge as a built-in merge tool
From: Markus Heidelberg @ 2009-04-05 12:42 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, msysgit, Johannes Schindelin, David Aguilar, Charles Bailey
In-Reply-To: <200904051440.33154.markus.heidelberg@web.de>
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/merge-config.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/merge-config.txt b/Documentation/merge-config.txt
index 1ff08ff..9c44af8 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -22,7 +22,8 @@ merge.stat::
merge.tool::
Controls which merge resolution program is used by
linkgit:git-mergetool[1]. Valid built-in values are: "kdiff3",
- "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and
+ "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff",
+ "ecmerge" and
"opendiff". Any other value is treated is custom merge tool
and there must be a corresponding mergetool.<tool>.cmd option.
--
1.6.2.2.460.g49e5c
^ permalink raw reply related
* [PATCH 0/3] git-mergetool/difftool: TortoiseMerge and (g)vimdiff for Windows
From: Markus Heidelberg @ 2009-04-05 12:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, msysgit, Johannes Schindelin, David Aguilar, Charles Bailey
Patches 2/3 and 3/3 are already in 'da/difftool' in 'pu'. This series is
based on 'master', now they can be applied to 4msysgit.git.
'da/difftool' should be recreated anyway.
Markus Heidelberg (3):
doc/merge-config: list ecmerge as a valid merge tool
git-mergetool/difftool: make (g)vimdiff workable under Windows
git-mergetool: add new merge tool TortoiseMerge
Documentation/git-mergetool.txt | 3 ++-
Documentation/merge-config.txt | 3 ++-
contrib/difftool/git-difftool-helper | 10 ++++++++--
git-mergetool.sh | 26 +++++++++++++++++++++-----
4 files changed, 33 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Johannes Schindelin @ 2009-04-05 11:50 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Miklos Vajna, Michael Johnson
In-Reply-To: <1238892420-721-1-git-send-email-drizzd@aon.at>
Hi,
On Sun, 5 Apr 2009, Clemens Buchacher wrote:
> The segmentation fault is caused by a null pointer dereference which
> happens during recursive merge with a submodule conflict between two
> merge bases. This is fixed by the following patches.
>
> However, there are other problems with merging submodules. For example,
> git diff aborts with "fatal: read error 'sub'" for conflicting
> submodules. I have also added a test for this.
>
> Dscho has already started working on related issues. I have therefore
> skipped t7404, which is already used in Dscho's work.
Thanks for working on this,
Dscho
^ permalink raw reply
* Re: non-ascii filenames issue
From: John Tapsell @ 2009-04-05 10:51 UTC (permalink / raw)
To: Teemu Likonen, git
In-Reply-To: <20090405100127.GA12126@home>
2009/4/5 Gregory Petrosyan <gregory.petrosyan@gmail.com>:
> On Sun, Apr 05, 2009 at 12:54:28PM +0300, Teemu Likonen wrote:
>> On 2009-04-05 13:36 (+0400), Gregory Petrosyan wrote:
>>
>> > # Changes to be committed:
>> > # (use "git rm --cached <file>..." to unstage)
>> > #
>> > # new file: "\321\204\320\260\320\271\320\273"
>> > #
>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> > "файл" should be here instead
>>
>> It can be fixed with command:
>>
>> git config --global core.quotepath false
>
> Thanks! That works. Does it make sence to set it to "false" by default?
Unfortunately not, because for some absolutely crazy reason, there is
no way at all to tell what encoding the string is in. It never
occured to anyone that it might actually be useful to be able to read
the filename in an unambiguous way. The result is this sort of mess.
Just wait until you try to checkout that file on a new filesystem with
a different encoding. Or try to checkout that file in Windows. It's
like git decided to step backwards 30 years.
John
^ permalink raw reply
* [question] how can i verify whether a local branch is tracking a remote branch?
From: Paolo Ciarrocchi @ 2009-04-05 10:32 UTC (permalink / raw)
To: git
Hi all,
is there a way to verify, using the UI, whether a local branch is
tracking a remote branch?
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
^ permalink raw reply
* Re: [PATCH] mergetool-lib: make (g)vimdiff workable under Windows
From: Markus Heidelberg @ 2009-04-05 10:32 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano
Cc: git, David Aguilar, Charles Bailey, msysgit
In-Reply-To: <alpine.DEB.1.00.0904051134210.10279@pacific.mpi-cbg.de>
Johannes Schindelin, 05.04.2009:
> Hi,
>
> On Sat, 4 Apr 2009, Markus Heidelberg wrote:
>
> > Under Windows vimdiff and gvimdiff are not available as symbolic links,
> > but as batch files vimdiff.bat and gvimdiff.bat. These files weren't
> > found by 'type vimdiff' which led to the following error:
> >
> > The merge tool vimdiff is not available as 'vimdiff'
> >
> > Even if they were found, it wouldn't work to invoke these batch files
> > from git-mergetool.
> >
> > To solve this, use vim and gvim (vim.exe and gvim.exe) and pass the -d
> > command line switch over to them.
> >
> > Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> > ---
> >
> > This patch goes on top of the current difftool/mergetool patches from David.
>
> ,.. which is a pity, because I could have applied them directly to
> msysGit's 'devel' branch otherwise.
There is currently a lot of refactoring going on in difftool/mergetool,
so of course I didn't send this to Junio against 'master'. But if you
want I can send it for you based on 'master' (or 4msysgit.git 'devel').
Junio, is this something for maint? I'm not sure, since this problem
only occurs on Windows and 'maint' isn't interesting for msysgit ATM.
Markus
^ permalink raw reply
* Re: [PATCH 1/4] sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
From: Sverre Rabbelier @ 2009-04-05 10:17 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <20090404225926.a9ad50e0.chriscool@tuxfamily.org>
Heya,
On Sat, Apr 4, 2009 at 22:59, Christian Couder <chriscool@tuxfamily.org> wrote:
> + if (lo <= mi && mi < hi)
> + break;
> + die("oops");
That's going to be an official git error message? Why not make it "The
fatal error oops has occured, press ctrl-c to lose all your work, or
press any other key to do the same"?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* git monthly links: 2009-03
From: Felipe Contreras @ 2009-04-05 10:14 UTC (permalink / raw)
To: git
Hi,
git monthly links is my attempt to gather all the links people have
been tagging as "git" in delicious.com[1] (these are not chosen by
me). It's a manual process so I might miss some links; I subscribe to
the RSS feed and go through all the links simply picking the ones
tagged the most.
The fancier blog version is here:
http://gitlog.wordpress.com/2009/04/05/git-monthly-links-2009-03/
== Outstanding ==
Understanding Git Conceptually
Charles Duan explains that "you can only really use Git if you
understand how Git works"
http://www.eecs.harvard.edu/~cduan/technical/git/
git ready: learn git one commit at a time
http://gitready.com/
== Hot ==
Many new guides, a new site 'learn.github' and Python picked Mercurial over
git :(
Intro to Git for Web Designers
High level quick and appealing introduction to git
http://www.webdesignerdepot.com/2009/03/intro-to-git-for-web-designers/
2009 Rubyist's guide to a Mac OS X development environment
Quick introduction to development tools for OS X development, including git
http://giantrobots.thoughtbot.com/2009/3/30/2009-rubyist-guide-mac-os-x-development-environment
When GitHub goes down...
Don't Panic!
http://ozmm.org/posts/when_github_goes_down.html
Migrating from svn to a distributed VCS
Analysis of DSCMs for the Python project
http://www.python.org/dev/peps/pep-0374/
Version Control for Designers
Comprehensive introduction to git
http://hoth.entp.com/output/git_for_designers.html
learn.github
A number of resources to learn git
http://learn.github.com/
== Other ==
Git pre-commit hooks and the Clang Static Analyzer
http://speirs.org/2009/04/03/git-pre-commit-hooks-and-the-clang-static-analyzer/
Git/Github survival guide
http://flanders.co.nz/2009/03/21/gitgithub-survival-guide/
gitguru: meditations on scm using git
http://gitguru.com/
tips - svnメイン、でもgithubでも公開したい場合の最小手順
http://blog.livedoor.jp/dankogai/archives/51194979.html
SubversionのリポジトリをGitのリポジトリに変換する方法
http://builder.japan.zdnet.com/news/story/0,3800079086,20390856,00.htm?ref=rss
Lesser Known(?) Git Tricks
http://www.pointy-stick.com/blog/2009/03/25/lesser-known-git-tricks/
Why Perforce is more scalable than Git
http://gandolf.homelinux.org/blog/index.php?id=50
A Git workflow for single developers
http://cakebaker.42dh.com/2009/03/08/a-git-workflow-for-single-developers/
A look back: Bram Cohen vs Linus Torvalds
http://wincent.com/a/about/wincent/weblog/archives/2007/07/a_look_back_bra.php
Git is the next Unix
http://www.advogato.org/person/apenwarr/diary/371.html
[1] http://delicious.com/tag/git
--
Felipe Contreras
^ permalink raw reply
* Re: non-ascii filenames issue
From: Gregory Petrosyan @ 2009-04-05 10:01 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <87ab6v2zor.fsf@iki.fi>
On Sun, Apr 05, 2009 at 12:54:28PM +0300, Teemu Likonen wrote:
> On 2009-04-05 13:36 (+0400), Gregory Petrosyan wrote:
>
> > # Changes to be committed:
> > # (use "git rm --cached <file>..." to unstage)
> > #
> > # new file: "\321\204\320\260\320\271\320\273"
> > #
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > "файл" should be here instead
>
> It can be fixed with command:
>
> git config --global core.quotepath false
Thanks! That works. Does it make sence to set it to "false" by default?
Gregory
^ permalink raw reply
* Re: non-ascii filenames issue
From: Teemu Likonen @ 2009-04-05 9:54 UTC (permalink / raw)
To: Gregory Petrosyan; +Cc: git
In-Reply-To: <20090405093640.GA9803@home>
On 2009-04-05 13:36 (+0400), Gregory Petrosyan wrote:
> # Changes to be committed:
> # (use "git rm --cached <file>..." to unstage)
> #
> # new file: "\321\204\320\260\320\271\320\273"
> #
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "файл" should be here instead
It can be fixed with command:
git config --global core.quotepath false
^ permalink raw reply
* Re: [PATCH 6/7] user-manual: add global config section
From: Junio C Hamano @ 2009-04-05 9:47 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1238837909-3060-7-git-send-email-felipe.contreras@gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> Documentation/user-manual.txt | 30 ++++++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 3278aa7..a3032c7 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -40,6 +40,36 @@ without any explanation.
> Finally, see <<todo>> for ways that you can help make this manual more
> complete.
I think a "getting started" section near the beginning of the manual is a
good idea (and ll.40- is a very early part of the manual).
For that "introductory" purpose, however, I'd suggest showing how they
appear in the actual .git/config file first in the editor and then show a
way to use the "git config" command as an alternative.
> +[[getting-started]]
> +Getting started
> +=============
> +
> +Git's configuration is distributed among different locations--this manual will
> +only to deal with 'global' and 'repository' variables, where 'repository'
> +variables take precedence over 'global' ones.
> +
> +You would probably want to start setting up something useful:
> +------------------------------------------------
> +$ git config --global color.ui auto
> +------------------------------------------------
> +
> +This will make prettier the output of certain commands such as `git diff`, but
> +that's not important; what is important here is that `color.ui` has been
> +stored in the 'global' (for the user) configuration.
"(for the user)" in parentheses here is better than not saying it
anywhere, but I think you should have it in the first paragraph where you
explain there are (at least) two kinds, global vs repository, in order to
clarify what you mean by 'global' is not "system/site wide" but "in any
repository I use" upfront.
> +View and manually modify the configuration with the `--edit`
> +option (which will use '$EDITOR'):
> +------------------------------------------------
> +$ git config --global --edit
> +[color]
> + ui = auto
> +------------------------------------------------
Copies of user manual are found quite easily (and bookmarked by many
people) on the web, and are looked at by people with not-so-bleeding-edge
version of git, so I'd rather not to give them "config --edit" this early
in the documentation. Perhaps after at least 6 months (preferrably a
year) after a release that has the new option, we can start encouraging
it, but not before. So I'd suggest replacing 'with the --edit ...' with
'$HOME/.gitconfig with your favorite editor' or something like that for
now.
> +Or you can manually edit the file which is located in `~/.gitconfig`. Other
> +locations are `/etc/gitconfig` (system), and `.git/config` (repository).
IOW, have this (without "Or") at the very beginning, and then as an
alternative give "git config color.ui auto".
Thanks.
^ permalink raw reply
* Re: [PATCHv2 2/2] git remote update: New option --prune
From: Junio C Hamano @ 2009-04-05 9:47 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: Jeff King, demerphq, git
In-Reply-To: <20090403090344.GB5199@pvv.org>
Thanks, queued (with a minor C90 fixup).
^ permalink raw reply
* Re: [PATCH 3/3] simplify output of conflicting merge
From: Junio C Hamano @ 2009-04-05 9:47 UTC (permalink / raw)
To: Clemens Buchacher; +Cc: git, Miklos Vajna, Michael Johnson, Johannes Schindelin
In-Reply-To: <1238892420-721-4-git-send-email-drizzd@aon.at>
Will queue, forking from maint. Thanks.
^ permalink raw reply
* Re: [PATCH] bisect: improve error message when branch checkout fails
From: Junio C Hamano @ 2009-04-05 9:46 UTC (permalink / raw)
To: Christian Couder; +Cc: git, malc
In-Reply-To: <20090404220226.58a3ac99.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> In "git-bisect.sh" the "git checkout" command is only used to
> change the current branch, but it is used like this:
>
> git checkout "$branch"
>
> which will output the following misleading error message when
> it fails:
>
> error: pathspec 'foo' did not match any file(s) known to git.
>
> This patch change the way we use "git checkout" like this:
>
> git checkout "$branch" --
>
> so that we will get the following error message:
>
> fatal: invalid reference: foo
>
> which is better.
Thanks; will apply.
But I think "git checkout" should either say "unknown branch" (assuming
that most people switch branches, not detach HEAD), or "no such commit"
(which could be a bit confusing for people who have not even heard of
detached HEAD, but may be more technically correct).
"Invalid reference" does not help anybody and is not technically correct,
either. A git newbie would say "Huh? what is a ref?" and a git savvy
would say "I admit I made a typo, but you, the git checkout command, are
supposed to take an arbitrary commit object, not necessarily a ref".
^ permalink raw reply
* Re: git-{diff,merge} refactor round 2
From: Junio C Hamano @ 2009-04-05 9:45 UTC (permalink / raw)
To: David Aguilar; +Cc: Markus Heidelberg, charles, git
In-Reply-To: <20090405033443.GA16219@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
>> David Aguilar, 01.04.2009:
>> > Here's the 2nd round of refactoring.
>>
>> I just noticed that mergetool.<mergetool>.path doesn't work anymore.
>> git grep mergetool.*path only hits one line in git-difftool--helper.sh
>> Neither does it seem to work with difftool, but I'm gonna go to bed now.
>>
>> Markus
>>
>
> Oops. Well, I have one final patch that removes the last bit of
> redundant code. It also fixed this problem so I'll go ahead
> and send it (it's based on top of da/difftool mentioned in
> pu).
>
> Since the test cases didn't catch that breakage I added a test
> for it.
>
> Look for a patch called:
>
> mergetool--lib: consolidate the last redundant bits in {diff,merge}tool
I'll try to queue all the outstanding da/difftool patches tonight, but I
think the patches in the series are getting to the point of needing a
fresh redoing. Patches like "oops, these non-user scripts should have
been named with double-dash" can and should disappear.
Currently they are:
$ git log --oneline next..da/difftool
736e6b6 mergetool--lib: add new merge tool TortoiseMerge
b3ef7cc mergetool--lib: make (g)vimdiff workable under Windows
c4d690e mergetool--lib: consolidate the last redundant bits in {diff,merge}tool
def88c8 mergetool-lib: specialize opendiff options when in diff mode
bd52fab mergetool-lib: refactor run_mergetool and check_unchanged
e87266c bash completion: add git-difftool
04c3b54 {diff,merge}tool: rename helpers to remove them from tab-completion
2a83022 mergetool-lib: add diffuse as merge and diff tool
73c59d9 mergetool-lib: specialize xxdiff options when in diff mode
273e7a2 mergetool-lib: specialize kdiff3 options when in diff mode
99511d8 mergetool: use run_mergetool from git-mergetool-lib
37c48c7 difftool: use run_mergetool from git-mergetool-lib
4e314b5 mergetool-lib: introduce run_mergetool
588954e difftool: use valid_tool from git-mergetool-lib
8af4556 mergetool: use valid_tool from git-mergetool-lib
72286b5 difftool: use get_mergetool_path from git-mergetool-lib
d03b97f mergetool: use get_mergetool_path from git-mergetool-lib
c6afc72 Add a mergetool-lib scriptlet for holding common merge tool functions
6108b75 mergetool: use $( ... ) instead of `backticks`
73786e2 difftool: add support for a difftool.prompt config variable
472ff62 difftool: add a -y shortcut for --no-prompt
de2b85d difftool: use perl built-ins when testing for msys
9df990e difftool: add various git-difftool tests
8ac77f2 difftool: add git-difftool to the list of commands
^ permalink raw reply
* Re: git send-email prompting too much
From: Junio C Hamano @ 2009-04-05 9:45 UTC (permalink / raw)
To: Jay Soffian; +Cc: Bruce Stephens, Dan McGee, git
In-Reply-To: <76718490904041949w4b66d9ffkbf06299fbff22db9@mail.gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 0/4] start refactoring binary search function
From: Junio C Hamano @ 2009-04-05 9:45 UTC (permalink / raw)
To: Christian Couder; +Cc: git, Johannes Schindelin
In-Reply-To: <20090404225920.6a10fe78.chriscool@tuxfamily.org>
Christian Couder <chriscool@tuxfamily.org> writes:
> There are many binary search functions in the code base and I have been
> asked to refactor them in these message:
>
> http://thread.gmane.org/gmane.comp.version-control.git/105363/focus=105436
> http://thread.gmane.org/gmane.comp.version-control.git/114735/focus=115391
>
> so here is a start
>
> The following patch applies on top of pu where they can be squashed into other
> patches:
>
> sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1
> patch-ids: use the new generic "sha1_pos" function to lookup sha1
> bisect: use the new generic "sha1_pos" function to lookup sha1
> replace_object: use the new generic "sha1_pos" function to lookup
> sha1
I think the refactoring itself does make sense. Less duplicated code has
better chance to be improved further if there is demonstrated need, and
I like the series for that "clean-up" value alone.
In the last two patches, however, you advertised the use of this new API
for gaining better performance (in exchange for simpler copy-pasted
implementation), but changing a simple (base + index * sizeof(struct that
contains the sha-1 field)) into a call to a function whose address is
passed _may_ have larger negative impact to the performance, than what is
gained by the better initial midpoint selection the new code uses.
If the extra indirect call turns to degrade the performance too much, we
could always reimplement it as a macro, I think, but let's not go there
before somebody runs benchmarks and demonstrates that it is a problem.
I've restructured your existing two branches to take advantage of the
first two patches.
Thanks.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox