* [PATCH 06/14] difftool: use perl built-ins when testing for msys
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg, David Aguilar
In-Reply-To: <1239006689-14695-6-git-send-email-davvid@gmail.com>
I don't even know what $COMSPEC means so let's be safe and use the
same perly $^O test add--interactive uses. While we're at it, make
git-difftool match the prevalent git-perl style.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib/difftool/git-difftool b/contrib/difftool/git-difftool
index 0deda3a..207dd50 100755
--- a/contrib/difftool/git-difftool
+++ b/contrib/difftool/git-difftool
@@ -33,7 +33,10 @@ sub setup_environment
sub exe
{
my $exe = shift;
- return defined $ENV{COMSPEC} ? "$exe.exe" : $exe;
+ if ($^O eq 'MSWin32' || $^O eq 'msys') {
+ return "$exe.exe";
+ }
+ return $exe;
}
sub generate_command
@@ -47,7 +50,7 @@ sub generate_command
$skip_next = 0;
next;
}
- if ($arg eq '-t' or $arg eq '--tool') {
+ if ($arg eq '-t' || $arg eq '--tool') {
usage() if $#ARGV <= $idx;
$ENV{GIT_DIFF_TOOL} = $ARGV[$idx + 1];
$skip_next = 1;
--
1.6.2.2.414.g81aa9
^ permalink raw reply related
* [PATCH 05/14] difftool: remove the backup file feature
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg, David Aguilar
In-Reply-To: <1239006689-14695-5-git-send-email-davvid@gmail.com>
Most users find the backup file feature annoying and there's no
need for it since diff is supposed to be a read-only operation.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool-helper | 34 +---------------------------------
1 files changed, 1 insertions(+), 33 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index ef684b6..e74a274 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -9,31 +9,7 @@
# Set GIT_DIFFTOOL_NO_PROMPT to bypass the per-file prompt.
should_prompt () {
- ! test -n "$GIT_DIFFTOOL_NO_PROMPT"
-}
-
-# Should we keep the backup .orig file?
-keep_backup_mode="$(git config --bool merge.keepBackup || echo true)"
-keep_backup () {
- test "$keep_backup_mode" = "true"
-}
-
-# This function manages the backup .orig file.
-# A backup $MERGED.orig file is created if changes are detected.
-cleanup_temp_files () {
- if test -n "$MERGED"; then
- if keep_backup && test "$MERGED" -nt "$BACKUP"; then
- test -f "$BACKUP" && mv -- "$BACKUP" "$MERGED.orig"
- else
- rm -f -- "$BACKUP"
- fi
- fi
-}
-
-# This is called when users Ctrl-C out of git-difftool-helper
-sigint_handler () {
- cleanup_temp_files
- exit 1
+ test -z "$GIT_DIFFTOOL_NO_PROMPT"
}
# This function prepares temporary files and launches the appropriate
@@ -47,12 +23,6 @@ launch_merge_tool () {
LOCAL="$2"
REMOTE="$3"
BASE="$1"
- ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
- BACKUP="$MERGED.BACKUP.$ext"
-
- # Create and ensure that we clean up $BACKUP
- test -f "$MERGED" && cp -- "$MERGED" "$BACKUP"
- trap sigint_handler INT
# $LOCAL and $REMOTE are temporary files so prompt
# the user with the real $MERGED name before launching $merge_tool.
@@ -120,8 +90,6 @@ launch_merge_tool () {
fi
;;
esac
-
- cleanup_temp_files
}
# Verifies that (difftool|mergetool).<tool>.cmd exists
--
1.6.2.2.414.g81aa9
^ permalink raw reply related
* [PATCH 04/14] difftool: remove merge options for opendiff, tkdiff, kdiff3 and xxdiff
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg, David Aguilar
In-Reply-To: <1239006689-14695-4-git-send-email-davvid@gmail.com>
We shouldn't try to merge files when using difftool, so remove
any merge-specific options.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/difftool/git-difftool-helper | 10 +++-------
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
index e481913..ef684b6 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/contrib/difftool/git-difftool-helper
@@ -69,7 +69,7 @@ launch_merge_tool () {
"$merge_tool_path" --auto \
--L1 "$basename (A)" \
--L2 "$basename (B)" \
- -o "$MERGED" "$LOCAL" "$REMOTE" \
+ "$LOCAL" "$REMOTE" \
> /dev/null 2>&1
;;
@@ -78,7 +78,7 @@ launch_merge_tool () {
;;
tkdiff)
- "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
+ "$merge_tool_path" "$LOCAL" "$REMOTE"
;;
meld)
@@ -95,17 +95,13 @@ launch_merge_tool () {
xxdiff)
"$merge_tool_path" \
- -X \
- -R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
- --merged-file "$MERGED" \
"$LOCAL" "$REMOTE"
;;
opendiff)
- "$merge_tool_path" "$LOCAL" "$REMOTE" \
- -merge "$MERGED" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" | cat
;;
ecmerge)
--
1.6.2.2.414.g81aa9
^ permalink raw reply related
* [PATCH 03/14] git-mergetool: add new merge tool TortoiseMerge
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg
In-Reply-To: <1239006689-14695-3-git-send-email-davvid@gmail.com>
From: Markus Heidelberg <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.414.g81aa9
^ permalink raw reply related
* [PATCH 02/14] git-mergetool/difftool: make (g)vimdiff workable under Windows
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg
In-Reply-To: <1239006689-14695-2-git-send-email-davvid@gmail.com>
From: Markus Heidelberg <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.414.g81aa9
^ permalink raw reply related
* [PATCH 01/14] doc/merge-config: list ecmerge as a built-in merge tool
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg
In-Reply-To: <1239006689-14695-1-git-send-email-davvid@gmail.com>
From: Markus Heidelberg <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.414.g81aa9
^ permalink raw reply related
* git-{merge,diff}tool refactor round three
From: David Aguilar @ 2009-04-06 8:31 UTC (permalink / raw)
To: gitster; +Cc: git, charles, markus.heidelberg
Hopefully this is the final round =)
This series is based on top of master.
The result of this series gets us to where da/difftool in pu
arrived, but does so in a maintainer-friendly way.
I'm including Markus' patches in this series just so that it's
clear that this series is dependent on it.
Everything before "move 'git-difftool' out of contrib" can be
applied to master directly since it is not involved in the
refactor.
We'll need to revert:
d3b8cec difftool: move 'git-difftool' out of contrib
to avoid a merge conflict in next.
In case anyone's curious, da/difftool originally
contained 25 commits. Less is more.
^ permalink raw reply
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Paolo Ciarrocchi @ 2009-04-06 8:30 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090406043426.GC12341@coredump.intra.peff.net>
On Mon, Apr 6, 2009 at 6:34 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Apr 05, 2009 at 11:25:29PM +0200, Paolo Ciarrocchi wrote:
>
>> An example:
>> $ git clone -n URL temp
>> $ cd temp
>> $ git branch -r
>> origin/master
>> origin/foo
>> Origin/bar
>> $ git checkout --track -b foo origin/foo
>>
>> Now, how can I know that foo is tracking origin/foo ?
>
> Doing it right is hard. You have to:
>
> 1. check branch.foo.merge and branch.foo.rebase; if no value, it is not
> tracking anything; if it is, remember that value as $m
>
> 2. check branch.foo.remote for the remote name, $r
>
> 3. check the fetch refspecs for remote $r; these can come from
> the config, or from .git/remotes/* files. Maybe even .git/branches
> files; I don't even remember how those work.
>
> 4. find the refspec that fetches from $m; then find the matching
> destination for that refspec. That is the tracking branch.
>
> E.g., in your example (and using a modern git):
>
> 1. $m is refs/heads/foo
> 2. $r is origin
> 3. The fetch refspec is in remote.origin.fetch, and is generally
> "refs/heads/*:refs/remotes/origin/*"
> 4. So refs/heads/foo becomes refs/remotes/origin/foo.
> refs/remotes/origin/foo is your tracking branch.
>
> Steps 1 and 2 are easy, but 3 and 4 are a bit nasty. You can fake it by
> assuming that "refs/heads/$m" on "$r" is always "refs/remotes/$r/$m",
> which is true for very vanilla setups.
>
> There is C code that does this, but there is not a good way of accessing
> it from the command-line. The best you can do is "git remote show
> origin", which on recent git versions should show something like:
>
> ...
> Local branches configured for 'git pull':
> foo merges with remote foo
> ...
>
> But of course that implies that you already guessed the remote "origin".
> And it's not using plumbing, so it's not very suitable for scripts.
>
> I don't think it would be unreasonable to expose this functionality via
> "for-each-ref". Something like this (which would need cleanup,
> documentation, and perhaps a :short variant):
Jeff,
thank you very much for your prompt answers and for your patch.
I often act like a GIT "evangelist" trying to help friends and
colleagues in starting using GIT and one of the "complaint" I'm
getting is that people expect to get this information out of the
branch command.
I mean something like:
$ git branch
* foo <-> origin/foo
What do you think?
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
^ permalink raw reply
* What's cooking in git.git (Apr 2009, #01; Mon, 06)
From: Junio C Hamano @ 2009-04-06 8:28 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* mh/html-path (Sun Apr 5 04:15:16 2009 +0200) 1 commit
+ add --html-path to get the location of installed HTML docs
* lt/reflog-expire (Mon Mar 30 21:34:14 2009 -0700) 2 commits
+ Speed up reflog pruning of unreachable commits
+ Clean up reflog unreachability pruning decision
* bs/maint-1.6.0-tree-walk-prefix (Wed Apr 1 19:34:03 2009 -0700) 2 commits
+ match_tree_entry(): a pathspec only matches at directory
boundaries
+ tree_entry_interesting: a pathspec only matches at directory
boundary
* ms/http-auth (Wed Apr 1 19:48:24 2009 +0300) 1 commit
+ Allow curl to rewind the read buffers
* js/maint-submodule-checkout (Thu Apr 2 15:30:25 2009 +0200) 1 commit
+ Fix 'git checkout <submodule>' to update the index
* cb/maint-merge-recursive-submodule-fix (Sun Apr 5 02:47:00 2009 +0200) 3 commits
+ simplify output of conflicting merge
+ update cache for conflicting submodule entries
+ add tests for merging with submodules
* fg/remote-prune (Fri Apr 3 11:03:44 2009 +0200) 2 commits
+ git remote update: New option --prune
+ builtin-remote.c: Split out prune_remote as a separate function.
These should go to 'master' soonish.
* cc/sha1-bsearch (Mon Apr 6 00:48:49 2009 -0700) 3 commits
- sha1-lookup: fix up the assertion message
- patch-ids: use the new generic "sha1_pos" function to lookup sha1
- sha1-lookup: add new "sha1_pos" function to efficiently lookup
sha1
I think this is Ok for 'next', but somebody might want to prove me wrong
by running some benchmarks.
----------------------------------------------------------------
[Will Discard]
* jc/name-branch-iffy (Sat Mar 21 14:30:21 2009 -0700) 1 commit
- checkout -: make "-" to mean "previous branch" everywhere
----------------------------------------------------------------
[Graduated to "master"]
* cj/doc-format (Fri Mar 27 00:36:47 2009 -0700) 11 commits
+ Merge branch 'cj/doc-quiet' into cj/doc-format
+ Documentation: option to render literal text as bold for manpages
+ Documentation: asciidoc.conf: fix verse block with block titles
+ Documentation: asciidoc.conf: always use <literallayout> for
[blocktext]
+ Documentation: move "spurious .sp" code into manpage-base.xsl
+ Documentation: move quieting params into manpage-base.xsl
+ Documentation: rename docbook-xsl-172 attribute to git-asciidoc-
no-roff
+ Documentation: use parametrized manpage-base.xsl with manpage-
{1.72,normal}.xsl
+ Documentation: move callouts.xsl to manpage-{base,normal}.xsl
+ Documentation/Makefile: break up texi pipeline
+ Documentation/Makefile: make most operations "quiet"
* cj/doc-quiet (Fri Mar 27 01:49:39 2009 -0500) 2 commits
+ Documentation/Makefile: break up texi pipeline
+ Documentation/Makefile: make most operations "quiet"
* jc/name-branch (Sat Mar 21 14:35:51 2009 -0700) 5 commits
+ strbuf_check_branch_ref(): a helper to check a refname for a
branch
+ Fix branch -m @{-1} newname
+ check-ref-format --branch: give Porcelain a way to grok branch
shorthand
+ strbuf_branchname(): a wrapper for branch name shorthands
+ Rename interpret/substitute nth_last_branch functions
* sb/format-patch-patchname (Fri Mar 27 01:13:01 2009 +0100) 7 commits
+ log-tree: fix patch filename computation in "git format-patch"
+ format-patch: --numbered-files and --stdout aren't mutually
exclusive
+ format-patch: --attach/inline uses filename instead of SHA1
+ format-patch: move get_patch_filename() into log-tree
+ format-patch: pass a commit to reopen_stdout()
+ format-patch: construct patch filename in one function
+ pretty.c: add %f format specifier to format_commit_message()
* mg/tracked-local-branches (Thu Mar 26 21:53:25 2009 +0100) 2 commits
+ Make local branches behave like remote branches when --tracked
+ Test for local branches being followed with --track
* jc/shared-literally (Fri Mar 27 23:21:00 2009 -0700) 4 commits
+ set_shared_perm(): sometimes we know what the final mode bits
should look like
+ move_temp_to_file(): do not forget to chmod() in "Coda hack"
codepath
+ Move chmod(foo, 0444) into move_temp_to_file()
+ "core.sharedrepository = 0mode" should set, not loosen
* tr/maint-1.6.1-doc-format-patch--root (Thu Mar 26 18:29:25 2009 +0100) 1 commit
+ Documentation: format-patch --root clarifications
* mh/format-patch-add-header (Thu Mar 26 10:51:05 2009 -0600) 1 commit
+ format-patch: add arbitrary email headers
* ef/fast-export (Mon Mar 23 12:53:09 2009 +0000) 4 commits
+ builtin-fast-export.c: handle nested tags
+ builtin-fast-export.c: fix crash on tagged trees
+ builtin-fast-export.c: turn error into warning
+ test-suite: adding a test for fast-export with tag variants
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
+ stat_tracking_info(): only count real commits
* jc/maint-1.6.0-keep-pack (Sat Mar 21 17:26:11 2009 -0500) 6 commits
+ pack-objects: don't loosen objects available in alternate or kept
packs
+ t7700: demonstrate repack flaw which may loosen objects
unnecessarily
+ Remove --kept-pack-only option and associated infrastructure
+ pack-objects: only repack or loosen objects residing in "local"
packs
+ git-repack.sh: don't use --kept-pack-only option to pack-objects
+ t7700-repack: add two new tests demonstrating repacking flaws
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* ps/blame (Thu Mar 12 21:30:03 2009 +1100) 1 commit
- blame.c: start libifying the blame infrastructure
A few minor point remains in this initial one. I hate to do these minor
fix-ups myself, but I may end up doing so...
* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
- Allow --date=local --date=other-format to work as expected
The one I posted had a few corner-case bugs that was caught with the test
suite; this one has them fixed. People did not like the UI so it is kept
out of 'next'
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
- archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
Probably I should discard it and wait for a reroll if needed.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user.
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
- tests: fix "export var=val"
- notes: refuse to edit notes outside refs/notes/
- t3301: use test_must_fail instead of !
- t3301: fix confusing quoting in test for valid notes ref
- notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
- notes: only clean up message file when editing
- handle empty notes gracefully
- git notes show: test empty notes
- git-notes: fix printing of multi-line notes
- notes: fix core.notesRef documentation
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
* hv/cvsps-tests (Sun Apr 5 01:40:50 2009 -0700) 8 commits
- t/t9600: remove exit after test_done
- cvsimport: extend testcase about patchset order to contain
branches
- cvsimport: add test illustrating a bug in cvsps
+ Add a test of "git cvsimport"'s handling of tags and branches
+ Add some tests of git-cvsimport's handling of vendor branches
+ Test contents of entire cvsimported "master" tree contents
+ Use CVS's -f option if available (ignore user's ~/.cvsrc file)
+ Start a library for cvsimport-related tests
Two cvsimport test topics were rewound from 'next' and merged into this
one. I'll keep this in 'pu' so that people can polish their cvsps skilz
to resolve issues these tests identify.
----------------------------------------------------------------
[Actively cooking]
* da/difftool (Sat Apr 4 21:00:24 2009 -0700) 25 commits
- mergetool--lib: add new merge tool TortoiseMerge
- mergetool--lib: make (g)vimdiff workable under Windows
- mergetool--lib: consolidate the last redundant bits in
{diff,merge}tool
- mergetool-lib: specialize opendiff options when in diff mode
- mergetool-lib: refactor run_mergetool and check_unchanged
- bash completion: add git-difftool
- {diff,merge}tool: rename helpers to remove them from tab-
completion
- mergetool-lib: add diffuse as merge and diff tool
- mergetool-lib: specialize xxdiff options when in diff mode
- mergetool-lib: specialize kdiff3 options when in diff mode
- mergetool: use run_mergetool from git-mergetool-lib
- difftool: use run_mergetool from git-mergetool-lib
- mergetool-lib: introduce run_mergetool
- difftool: use valid_tool from git-mergetool-lib
- mergetool: use valid_tool from git-mergetool-lib
- difftool: use get_mergetool_path from git-mergetool-lib
- mergetool: use get_mergetool_path from git-mergetool-lib
- Add a mergetool-lib scriptlet for holding common merge tool
functions
- mergetool: use $( ... ) instead of `backticks`
- difftool: add support for a difftool.prompt config variable
- difftool: add a -y shortcut for --no-prompt
- difftool: use perl built-ins when testing for msys
- difftool: add various git-difftool tests
- difftool: add git-difftool to the list of commands
+ difftool: move 'git-difftool' out of contrib
* cc/bisect-filter (Mon Mar 30 06:59:59 2009 +0200) 19 commits
- bisect--helper: string output variables together with "&&"
- rev-list: pass "int flags" as last argument of "show_bisect_vars"
- t6030: test bisecting with paths
- bisect: use "bisect--helper" and remove "filter_skipped" function
- bisect: implement "read_bisect_paths" to read paths in
"$GIT_DIR/BISECT_NAMES"
- bisect--helper: implement "git bisect--helper"
- bisect: use the new generic "sha1_pos" function to lookup sha1
- rev-list: call new "filter_skip" function
- Merge branch 'cc/sha1-bsearch' into HEAD
- patch-ids: use the new generic "sha1_pos" function to lookup sha1
- sha1-lookup: add new "sha1_pos" function to efficiently lookup
sha1
+ rev-list: pass "revs" to "show_bisect_vars"
+ rev-list: make "show_bisect_vars" non static
+ rev-list: move code to show bisect vars into its own function
+ rev-list: move bisect related code into its own file
+ rev-list: make "bisect_list" variable local to "cmd_rev_list"
+ refs: add "for_each_ref_in" function to refactor "for_each_*_ref"
functions
+ quote: add "sq_dequote_to_argv" to put unwrapped args in an argv
array
+ quote: implement "sq_dequote_many" to unwrap many args in one
string
Re-rolled and made earlier parts ready for 'master'. I think we should
move this to 'next' soonish and aim to have it in 1.6.3
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 13 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
- patch-ids: use the new generic "sha1_pos" function to lookup sha1
- sha1-lookup: add new "sha1_pos" function to efficiently lookup
sha1
Re-rolled based on the updated binary search API.
----------------------------------------------------------------
[On Hold]
* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
- receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
- Refuse updating the current branch in a non-bare repository via
push
These are for 1.7.0, but the messages when they trigger together may need
to be rethought.
^ permalink raw reply
* The EGIT Chronicles Issue Volume 3, Issue 1
From: Robin Rosenberg @ 2009-04-06 6:33 UTC (permalink / raw)
To: git
A year and a thousand commits has passed since the previous issue of this
newsletter.
Publicity
- The EGit plugin has passed version 0.4 some 280 commits ago and has raised more attention. Downloads are on the rise and the project gets attention in blogs around the net. mostly positive, which may be surprising, since it still lacks a lot of functionality. That's encouraging.
Most interestingly, some Eclipse developers, i.e. the ones that build and contribute to the Eclipse platform, have raised interest in Git for source control. We have had an Eclipse proposal under development for a while and finally submitted EGit for consideration as and Eclipse Technology project. Link: http://www.eclipse.org/proposals/egit/
Egit is EPL and BSD licensed which license-wise qualifies it for inclusion into the Eclipse project, unlike the nearest competitor Mercurial that cannot
be bundled with Eclipse due to the GPL.
Obviously a proposal is not the same thing as acceptance. If you are interested in the project you can contribute to the discussion in the newsgroup available via the link above.
- Shawn's been working on Gerrit2, a code review system built on top of JGit, the core of the Eclipse plugin.
Noteable contributions
- Last Google Summer of Code contributed push/fetch support to the plugin. Marek Zawirskis code is still mostly as he left it, which proves it was well crafted.
- Tor Arne Westbø rewrote the decorator to run faster and wit fewer bugs.
Thanks to a dozen or so other people that contributed with important fixes
and improvements.
The pipe
- Lots of stuff is coming. For example, a few diff engines are being considered, a blame implementation has been demonstrated, though not fully ready yet. Some simple merge/cherry picking capability is included already, but without the diff/patch engine it's not as fully automated as one might want yet. Gerrit2 uses it though.
Update site
- New built versions are regularly published to an update site for easy installation.
- When downloading from the update site, the plugin now has a description you can read (git shortlog) summarizing the changes since the previous version.
Bug tracker/Wiki
- Bugs can be reported on http://egit.googlecode.com and there is a wiki too
- Msysgit issues
A lot of people choose (?) to run Git and Eclipse on Windows and there are some issues when using the plugin and msysgit side-by-side (and you still have to for serious git use) on Windows. A serious bug was found and fixed in msysgit. That was easily trigged by running Eclipse and msysgit in parallel. During repack your repo could ( likely) be whacked and obliterated. This was fixed in version 1.6.2. There are other issue, but they are very minor compared to this one. All these issues aren't really specific to EGit, but it tends to trigger the problems more often since it accesses the repository quite often to look for changes.
- Controversial topics
Non-ASCII filenames is an issue that comes up ever more often. JGit/EGit handles this differently since the C Git way simply doesn't work cross platform. Hopefully we'll be able to reconciliate soon. EGit / C Git is compatible between Unix (except OS X) in UTF-8 mode and Windows. For other situations your mileage may vary. We store names in UTF-8 on all platforms. The OSX issue here is the infamous case of decomposed Unicode, i.e. a letter lika ä gets decomposed into two unicode code points on Macs. The final word on this issue has not yet been uttered.
-- robin
^ permalink raw reply
* Re: [PATCH 5/7] user-manual: use SHA-1 instead of SHA1 or sha1
From: Junio C Hamano @ 2009-04-06 8:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1238837909-3060-6-git-send-email-felipe.contreras@gmail.com>
Thanks.
This also seems to depend on the missing 3/7 but I've managed. I retitled
it to "user-manual: the name of the hash function is SHA-1, not sha1".
^ permalink raw reply
* Re: [PATCH 4/7] user-manual: use 'fast-forward' instead of 'fast forward'
From: Junio C Hamano @ 2009-04-06 8:14 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1238837909-3060-5-git-send-email-felipe.contreras@gmail.com>
As there isn't 3/7 and this seems to depend on it, I'm dropping this, for
now, but is this an improvement, or is it a "many places already use
fast-forward and this patch is bringing consistency to the remainder"
patch?
^ permalink raw reply
* Re: [PATCH v2] Add configuration variable for sign-off to format-patch
From: Junio C Hamano @ 2009-04-06 8:14 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Jeff King, git
In-Reply-To: <20090401175153.GA90421@macbook.lan>
Heiko Voigt <hvoigt@hvoigt.net> writes:
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index ad22cb8..27cb7f1 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -715,6 +715,13 @@ format.thread::
> A true boolean value is the same as `shallow`, and a false
> value disables threading.
>
> +format.signoff::
> + A boolean value which lets you enable the `-s/--signoff` option of
> + format-patch by default. *Note:* Adding the Signed-off-by: line to a
> + patch should be a conscious act and means that you certify you have
> + the rights to submit this work under the same open source license.
> + Please see the 'SubmittingPatches' document for further discussion.
I have a mixed feeling about this description. The existing description
on the --signoff option merely talks about what it does, leaving what it
means, and it is quite deliberate. If your project uses S-o-b, it may be
useful. If yours doesn't, you simply just don't use it. It does not
matter to _us_ as the document writer what that line means to your
project.
We do want to make the reader think twice iff S-o-b is used in the
reader's project with the same meaning as it means in git and the Linux
kernel project, which is what the description you added is about. But
should we just assume if anybody uses S-o-b convention in their project
they must give it the same meaning as we give it?
The patch looks straightforward enough, and the wording we can update if
somebody can come up with a better one, so I'll apply the patch to
'master' and we will go from there.
Thanks.
^ permalink raw reply
* Re: non-ascii filenames issue
From: Peter Krefting @ 2009-04-06 7:28 UTC (permalink / raw)
To: John Tapsell; +Cc: Teemu Likonen, git
In-Reply-To: <43d8ce650904050351p72590d52l8861b3901f95201a@mail.gmail.com>
John Tapsell:
> 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.
It comes from the Unix tradition, unfortunately, that file names are just a
stream of bytes, instead of a stream of characters mapped to a byte
sequence. The "stream of bytes" think worked back when everyone used ASCII,
but as soon as other character encodings were used (i.e back in the 1970s or
so), that assumption broke.
> 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.
Since most people on Linux nowadays probably are running in a UTF-8-based
locale, I tried introducing some (very incomplete) patches for the Windows
port to make this assumption, to allow Windows users to make use of
non-ASCII file names (Windows uses Unicode strings for file names). Mac OS
uses (semi-decomposed) UTF-8 strings, so it should also be able to make use
of this.
Unfortunately, there seems to be quite some resistance towards deciding on
a platform- and language-independent way of storing file names in Git, but
rather just going the "Unix" way and making it someone elses problem. I find
this a bit sad.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Running 'git pull' from an unnamed branch
From: Reece Dunn @ 2009-04-06 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v3acmoalw.fsf@gitster.siamese.dyndns.org>
2009/4/6 Junio C Hamano <gitster@pobox.com>:
> Reece Dunn <msclrhd@googlemail.com> writes:
>
>> diff --git a/git-pull.sh b/git-pull.sh
>> index 8a26763..00a72dd 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -97,6 +97,10 @@ error_on_no_merge_candidates () {
>> echo "try again (e.g. 'git pull <repository> <refspec>')."
>> echo "See git-pull(1) for details on the refspec."
>> echo
>> + echo "You may not be on a branch. In this case, you need to move"
>> + echo "onto the branch you want to pull to (usually master):"
>> + echo " git checkout <branch>"
>> + echo
>
> I do not think that is necessarily what the user wanted to hear. Often I
> create trial merges on a detached HEAD when I hear a pull-request from
> others (I have a few work trees that share the repository with my primary
> working area, made with contrib/workdir/git-new-workdir script, and their
> HEAD are typically detached at the tip of the master), and in such a use
> case, the first line of the instruction in the context in your patch is
> the right thing to give. I do not want to have the resulting trial merge
> anywhere on my real branches, and do not want to be told to switch to any
> of them.
>
> We really should teach people, especially the new ones early on, that "git
> push" and "git pull" are meant to be told where-to/from and what, and how
> to drive these commands with explicit arguments, before letting them rely
> on the default configuration blindly without understanding the underlying
> concepts.
Ok, so how about something like:
"You may not be on a branch. Because of this, you need to specify
where you are pulling from and to. See git-pull(1) for how to do this.
Alternatively, you can move to a named branch using:
git checkout <branch>"
> The automation given by the configuration variables is certainly nice, and
> the default created by "clone", "remote add" and "checkout -b" (with its
> implicit "track") may make them simpler to operate for every day life, but
> there is a limit. Working on a detached HEAD is an ultimate free-form
> hacking, and you do not even necessarily _want_ to have a "while my HEAD
> is detached, please always do this" default configured.
How about the above wording? I have kept the moving to a named branch,
but have made it optional and secondary to using git pull with
arguments. This supports the workflow you and others have described,
while retaining the hint for when you don't want to work on a detached
HEAD - for example, after running bisect - without saying that the
latter is required.
- Reece
^ permalink raw reply
* Re: Segfault on merge with 1.6.2.1
From: Clemens Buchacher @ 2009-04-06 6:41 UTC (permalink / raw)
To: Michael Johnson; +Cc: git, Miklos Vajna, Johannes Schindelin
In-Reply-To: <op.urx07jgeso3nzr@sulidor.mdjohnson.us>
On Sun, Apr 05, 2009 at 09:29:33PM -0500, Michael Johnson wrote:
>> +# history
>> +#
>> +# a --- c
>> +# / \ /
>> +# root X
>> +# \ / \
>> +# b --- d
>
> This also explains a lot. Is there any way to get this sort of simplified
> representation from the existing tools? I would think gitk would show it,
> but would I be able to recognize it.?
I simply tagged everything that showed up in "git merge-base --all" and then
I did "gitk --all --simplify-by-decoration". That shows pretty much the
graph above.
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-06 6:18 UTC (permalink / raw)
To: David Aguilar; +Cc: Sverre Rabbelier, markus.heidelberg, Felipe Contreras, git
In-Reply-To: <20090406055301.GA17080@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> Ah, I know the answer:
>
> http://kerneltrap.org/mailarchive/git/2008/11/12/4072144
> http://kerneltrap.org/mailarchive/git/2008/11/12/4067114
> http://kerneltrap.org/mailarchive/git/2008/11/2/3896104
>
> I did say it *seemed* appealing, not that it actually was ;)
Heh, I forgot all about that.
What is sad about it is that I back then predicted that we will regret
"diff --staged".
http://kerneltrap.org/mailarchive/git/2008/11/11/4056664
^ permalink raw reply
* Re: [PATCH] Initial Japanese gitk translation
From: Mike Hommey @ 2009-04-06 6:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: FORS Luis, git
In-Reply-To: <7vws9ymudz.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 05, 2009 at 06:40:56PM -0700, Junio C Hamano wrote:
> > +msgid "Short SHA1 id %s is ambiguous"
> > +msgstr "%sを含むSHA1が複数存在する"
>
> Good job!!
Should be します, though.
> > +msgid "The commits on branch %s aren't on any other branch.\nReally delete branch %s?"
> > +msgstr "ブランチ%sが一意リビジョンを含む。\nそれでも削除しますか？"
>
> ブランチ%sには他ブランチにマージされていないコミットがあります。それでも・・・
Wouldn't it be better with brackets (「」) around %s ?
Mike
^ permalink raw reply
* Re: GPG signing for git commit?
From: Sam Vilain @ 2009-04-06 6:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Chow Loong Jin, git
In-Reply-To: <alpine.LFD.2.00.0904031535140.3915@localhost.localdomain>
Linus Torvalds wrote:
> On Sat, 4 Apr 2009, Chow Loong Jin wrote:
>
>> It crossed my mind that currently git commits cannot actually be
>> verified to be authentic, due to the fact that I can just set my
>> identity to be someone else, and then commit under their name.
>>
>
> You can't do that.
>
> Well, you can, but it's always going to be inferior to just adding a tag.
>
> The thing is, what is it you want to protect? The tree, the authorship,
> the committer info, the commit log, what?
>
[...]
> Btw, there's a final reason, and probably the really real one. Signing
> each commit is totally stupid. It just means that you automate it, and you
> make the signature worth less. It also doesn't add any real value, since
> the way the git DAG-chain of SHA1's work, you only ever need _one_
> signature to make all the commits reachable from that one be effectively
> covered by that one. So signing each commit is simply missing the point.
>
> IOW, you don't _ever_ have a reason to sign anythign but the "tip". The
> only exception is the "go back and re-sign", but that's the one that
> requires external signatures anyway.
>
> So be happy with 'git tag -s'. It really is the right way.
>
Linus I agree with these points - I'd just like to point you to the new
mirror-sync design document. Under Documentation/git-mirror-sync.txt on
http://github.com/samv/git/tree/mirror-sync - and an implementation plan
outlined in Documentation/git-mirror-sync-impl.txt
This system allows for *pushes* to be signed and in general laying the
foundation for knowing that commits are authentic without the intrusion
into the refs/tags/* space that making lots of signed tags would imply.
The idea is to put 'packed-refs' contents (or a moral equivalent) in tag
bodies. It is really a new type of object, but it's sufficiently similar
to a tag that I thought I'd just go and go with that design for now.
Anyway if you're curious take a look, otherwise wait for the formal
submission once I've got something better together...
Sam
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: David Aguilar @ 2009-04-06 5:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, markus.heidelberg, Felipe Contreras, git
In-Reply-To: <7v63hie4yh.fsf@gitster.siamese.dyndns.org>
On 0, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> writes:
>
> > On 0, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> >> Heya,
> >>
> >> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg
> >> <markus.heidelberg@web.de> wrote:
> >> > Felipe Contreras, 06.04.2009:
> >> >> But actually, "git diff --cached" is a
> >> >> different action; you can't do "git diff --cached HEAD^.." for
> >> >> example.
> >> >
> >> > And I neither could I do "git stage diff HEAD^.."
> >>
> >> I rest my case ;). That's the whole point Felipe is trying to make here.
> >> $ git diff --cached
> >> $ git diff HEAD^..
> >>
> >> That's two different modes of operation with the only difference being
> >> a switch ('--cached'), which changes what is, and what is not valid
> >> after that.
> >>
> >> Whereas with
> >> $ git stage diff
> >>
> >> There is no confusion that 'HEAD^..' is not a valid argument, as there
> >> is no command in 'git stage diff' to which it _is_ a valid argument.
> >
> > Here's an interesting email from a while back:
> >
> > http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
> >
> > The above mentions the following suggestion:
> >
> > git diff STAGE WORKTREE (like "git diff" today)
> > git diff HEAD WORKTREE (like "git diff HEAD" today)
> > git diff WORKTREE HEAD (like "git diff -R HEAD" today)
> > git diff HEAD STAGE (like "git diff --cached" today)
> > git diff commit STAGE (like "git diff --cached commit" today)
> >
> > From a consistency and usability perspective, the above
> > example seems very appealing because:
> > ...
> > All we'd have to do is teach git-diff to special-case
> > 'STAGE' and 'WORKTREE'. Now, whether we'd want to do
> > that is a completely different discussion, but I figured I'd
> > throw the old thread out there.
>
> How would you express operations the current --index option does in such a
> scheme? Yet another WORKTREEANDTHEINDEX token?
Is it a trick question?
git-diff doesn't have an --index option, only --staged.
Ah, I know the answer:
http://kerneltrap.org/mailarchive/git/2008/11/12/4072144
http://kerneltrap.org/mailarchive/git/2008/11/12/4067114
http://kerneltrap.org/mailarchive/git/2008/11/2/3896104
I did say it *seemed* appealing, not that it actually was ;)
Alrighty.. my only purpose was to bring up the old thread
since I think many ideas were fleshed out back when
'git diff --staged' was introduced.
How useful it is in the context of this discussion about a
new 'stage' command is questionable, so I'll shut up now =)
--
David
^ permalink raw reply
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Jeff King @ 2009-04-06 5:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <7vy6uecpwd.fsf@gitster.siamese.dyndns.org>
On Sun, Apr 05, 2009 at 10:28:02PM -0700, Junio C Hamano wrote:
> > I don't think it would be unreasonable to expose this functionality via
> > "for-each-ref". Something like this (which would need cleanup,
> > documentation, and perhaps a :short variant):
>
> I think that is a sane approach, but isn't "tracking" a misnomer? I think
> what you are describing is what is called "the upstream branch" by the
> description of Documentation/config.txt::branch.<name>.merge, and not what
> people call "tracking branch" (see Documentation/glossary-content.txt).
I think this is the classic "both of these concepts are called
tracking and it is confusing" that people complain about from time to
time. This is the value created by "--track", and most of the internal
functions call it that (e.g., stat_tracking_info, fill_tracking_info,
etc).
But I am happy to call it something else if it will reduce confusion.
"upstream" is a fine name, I think (though that is often referring to
the upstream _repository_, so maybe somebody might expect it to print
"origin" here).
> I also wonder if you want to say "this remote" and "that branch"
> separately. As far as I can tell you are not giving the former but only
> the latter information?
Well, I don't think they are two separate parts. "that branch" has
already used information about the remote to reach its answer, and is
self-contained. It's all you need to know to do any non-fetching
operations (like seeing how your commits compare with upstream's, for
example).
Which isn't to say "this remote" might not be interesting. But I think
that is somewhat independent of this value, and moreover, it is already
trivial to find via "branch.*.remote" (or are there lookup rules I am
forgetting about?). The point of this exercise was that it is very
tricky to do the "upstream" correctly, so exposing the C code makes
sense.
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: clarify .gitattributes search
From: Junio C Hamano @ 2009-04-06 5:46 UTC (permalink / raw)
To: Jason Merrill; +Cc: git, gitster
In-Reply-To: <49D96C63.9070200@redhat.com>
Jason Merrill <jason@redhat.com> writes:
> From 04b504dc0c174d697cc1b75829fe2f7473f193ce Mon Sep 17 00:00:00 2001
> From: Jason Merrill <jason@redhat.com>
> Date: Sun, 5 Apr 2009 21:54:37 -0400
> Subject: [PATCH] Documentation: clarify .gitattributes search
You do not want these four lines in the body of the message.
> When deciding what attributes are assigned to a path, git
> consults `$GIT_DIR/info/attributes` file (which has the highest
> precedence), `.gitattributes` file in the same directory as the
> -path in question, and its parent directories (the further the
> -directory that contains `.gitattributes` is from the path in
> -question, the lower its precedence).
> +path in question, and its parent directories within the git repository
> +(the further the directory that contains `.gitattributes` is from the
> +path in question, the lower its precedence).
I initially:
(1) thought this was in "it goes without saying" category (but I am at
fault here---losing git virginity long time ago);
(2) also wondered why you were confused to think if your home directory
(for that matter, any higher directory, like /.gitattributes at the
filesystem root level) that is clearly outside of the project could
possibly affect what happens inside a project; and
(3) was puzzled why you do not have any patch to description of ignore
files (perhaps you do not even a similar confusion on them).
The last point was interesting, because the documentation of gitignore
uses this language:
* Patterns read from a `.gitignore` file in the same directory
as the path, or in any parent directory, with patterns in the
higher level files (up to the root) being overridden by those in
lower level files down to the directory containing the file.
These patterns match relative to the location of the
`.gitignore` file.
So "up to the root" might help. It might not.
A few questions.
(1) To a long-time git person, "up to the root" is obviously talking
about the toplevel of the work tree, not "root of the filesystem",
but is it clear to _you_ (or do you think it would be clear to
somebody else without much previous exposure to git)?
(2) If not, I think we should come up with a good wording and use that in
both. How does the "toplevel of the work tree" sound for that
purpose?
I would want to avoid the word "directories within the git repository",
because people would misinterpret that to mean directories like .git/refs
and .git/objects/info, which is clearly not what you meant here.
^ permalink raw reply
* Re: [question] how can i verify whether a local branch is tracking a remote branch?
From: Junio C Hamano @ 2009-04-06 5:28 UTC (permalink / raw)
To: Jeff King; +Cc: Paolo Ciarrocchi, git
In-Reply-To: <20090406043426.GC12341@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't think it would be unreasonable to expose this functionality via
> "for-each-ref". Something like this (which would need cleanup,
> documentation, and perhaps a :short variant):
I think that is a sane approach, but isn't "tracking" a misnomer? I think
what you are describing is what is called "the upstream branch" by the
description of Documentation/config.txt::branch.<name>.merge, and not what
people call "tracking branch" (see Documentation/glossary-content.txt).
In a repository with a handcrafted fetch refspec, being able to show
"tracking" information would also be interesting (e.g. a clone of git.git
made with pre-1.5.0 git would say "origin's master" for refs/heads/origin
and "origin's next" for refs/heads/next), but the separate-remote layout
is the default these days, so it wouldn't be so interesting anymore. In
other words, I am not suggesting you to add "tracking" information.
I also wonder if you want to say "this remote" and "that branch"
separately. As far as I can tell you are not giving the former but only
the latter information?
^ permalink raw reply
* Re: [RFC/PATCH 0/2] New 'stage' command
From: Junio C Hamano @ 2009-04-06 5:17 UTC (permalink / raw)
To: David Aguilar; +Cc: Sverre Rabbelier, markus.heidelberg, Felipe Contreras, git
In-Reply-To: <20090406032457.GA14758@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> On 0, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> Heya,
>>
>> On Mon, Apr 6, 2009 at 01:17, Markus Heidelberg
>> <markus.heidelberg@web.de> wrote:
>> > Felipe Contreras, 06.04.2009:
>> >> But actually, "git diff --cached" is a
>> >> different action; you can't do "git diff --cached HEAD^.." for
>> >> example.
>> >
>> > And I neither could I do "git stage diff HEAD^.."
>>
>> I rest my case ;). That's the whole point Felipe is trying to make here.
>> $ git diff --cached
>> $ git diff HEAD^..
>>
>> That's two different modes of operation with the only difference being
>> a switch ('--cached'), which changes what is, and what is not valid
>> after that.
>>
>> Whereas with
>> $ git stage diff
>>
>> There is no confusion that 'HEAD^..' is not a valid argument, as there
>> is no command in 'git stage diff' to which it _is_ a valid argument.
>
> Hello
>
> Here's an interesting email from a while back:
>
> http://kerneltrap.org/mailarchive/git/2008/10/29/3857134
>
> The above mentions the following suggestion:
>
> git diff STAGE WORKTREE (like "git diff" today)
> git diff HEAD WORKTREE (like "git diff HEAD" today)
> git diff WORKTREE HEAD (like "git diff -R HEAD" today)
> git diff HEAD STAGE (like "git diff --cached" today)
> git diff commit STAGE (like "git diff --cached commit" today)
>
>
> From a consistency and usability perspective, the above
> example seems very appealing because:
>
> a) it does not introduce any new commands, and
>
> b) it is consistent with the way git-diff's command-line
> interface works today.
>
> All we'd have to do is teach git-diff to special-case
> 'STAGE' and 'WORKTREE'. Now, whether we'd want to do
> that is a completely different discussion, but I figured I'd
> throw the old thread out there.
How would you express operations the current --index option does in such a
scheme? Yet another WORKTREEANDTHEINDEX token?
^ permalink raw reply
* Re: Performance issue: initial git clone causes massive repack
From: Junio C Hamano @ 2009-04-06 5:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: david, Nicolas Sebrecht, Robin H. Johnson, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0904052326090.6741@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> What git-pack-objects does in this case is not a full repack. It
> instead _reuse_ as much of the existing packs as possible, and only does
> the heavy packing processing for loose objects and/or inter pack
> boundaryes when gluing everything together for streaming over the net.
> If for example you have a single pack because your repo is already fully
> packed, then the "packing operation" involved during a clone should
> merely copy the existing pack over with no further attempt at delta
> compression.
One possibile scenario that you still need to spend memory and cycle is if
the cloned repository was packed to an excessive depth to cause many of
its objects to be in deltified form on insanely deep chains, while cloning
send-pack uses a depth that is more reasonable. Then pack-objects invoked
by send-pack is not allowed to reuse most of the objects and would end up
redoing the delta on them.
^ 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