* [PATCH] git submodule: fix add usage line
From: Julien Danjou @ 2009-04-02 8:47 UTC (permalink / raw)
To: gitster; +Cc: git, Julien Danjou
Actually, cmd_add() parse options first and stop as soon as an unknown
word is encoutered.
So we need to put the option like -b at the beginning, or the option
parsing loop will be escaped before we got the change to have our -b
option parsed.
Signed-off-by: Julien Danjou <julien@danjou.info>
---
git-submodule.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 0a27232..7c2e060 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add [-b branch] <repo> <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
--
1.6.2.1
^ permalink raw reply related
* [PATCH 1/3] mergetool-lib: specialize kdiff3 options when in diff mode
From: David Aguilar @ 2009-04-02 10:30 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
kdiff3 should only show two files when in diff mode.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-mergetool-lib.sh | 16 +++++++++++++---
1 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
index d28be68..e2d074d 100644
--- a/git-mergetool-lib.sh
+++ b/git-mergetool-lib.sh
@@ -67,9 +67,19 @@ run_mergetool () {
--L1 "$MERGED (Base)" --L2 "$MERGED (Local)" --L3 "$MERGED (Remote)" \
-o "$MERGED" "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- ("$merge_tool_path" --auto \
- --L1 "$MERGED (Local)" --L2 "$MERGED (Remote)" \
- -o "$MERGED" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
+ if merge_mode; then
+ ("$merge_tool_path" --auto \
+ --L1 "$MERGED (Local)" \
+ --L2 "$MERGED (Remote)" \
+ -o "$MERGED" "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1)
+ else
+ ("$merge_tool_path" --auto \
+ --L1 "$MERGED (A)" \
+ --L2 "$MERGED (B)" \
+ "$LOCAL" "$REMOTE" \
+ > /dev/null 2>&1)
+ fi
fi
status=$?
;;
--
1.6.2.1.303.g63699
^ permalink raw reply related
* [PATCH 3/3] mergetool-lib: add diffuse as merge and diff tool
From: David Aguilar @ 2009-04-02 10:30 UTC (permalink / raw)
To: gitster; +Cc: git, Sebastian Pipping, David Aguilar
In-Reply-To: <1238668246-762-2-git-send-email-davvid@gmail.com>
From: Sebastian Pipping <sebastian@pipping.org>
This adds diffuse as a built-in merge tool.
Signed-off-by: Sebastian Pipping <sebastian@pipping.org>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This is Sebastian's patch rebased onto Junio's pu branch.
I removed the git-gui part because I think git-gui
patches go through Shawn / git-gui.git?
This diff is still too big, so maybe we should
refactor the $mergetool_candidate code into
mergetool-lib as well.
Documentation/git-difftool.txt | 4 ++--
Documentation/git-mergetool.txt | 3 ++-
Documentation/merge-config.txt | 7 ++++---
contrib/completion/git-completion.bash | 3 ++-
git-difftool-helper.sh | 6 ++----
git-mergetool-lib.sh | 17 ++++++++++++++++-
git-mergetool.sh | 4 ++--
7 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 73d4782..15b247b 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -30,8 +30,8 @@ OPTIONS
--tool=<tool>::
Use the diff tool specified by <tool>.
Valid merge tools are:
- kdiff3, kompare, tkdiff, meld, xxdiff, emerge,
- vimdiff, gvimdiff, ecmerge, and opendiff
+ kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
+ ecmerge, diffuse and opendiff
+
If a diff tool is not specified, 'git-difftool'
will use the configuration variable `diff.tool`. If the
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 5d3c632..c3a8092 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,
+ diffuse 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 1ff08ff..c4fc3eb 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -22,9 +22,10 @@ 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
- "opendiff". Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.<tool>.cmd option.
+ "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff",
+ "diffuse" and "opendiff". Any other value is treated as a custom
+ merge tool and there must be a corresponding mergetool.<tool>.cmd
+ option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e72ce24..4fcd77a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1173,7 +1173,8 @@ _git_mergetool ()
--tool=*)
__gitcomp "
kdiff3 tkdiff meld xxdiff emerge
- vimdiff gvimdiff ecmerge opendiff
+ vimdiff gvimdiff ecmerge diffuse
+ opendiff
" "" "${cur##--tool=}"
return
;;
diff --git a/git-difftool-helper.sh b/git-difftool-helper.sh
index 2dfc870..d174b34 100755
--- a/git-difftool-helper.sh
+++ b/git-difftool-helper.sh
@@ -1,7 +1,5 @@
#!/bin/sh
# git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
-# It supports kdiff3, kompare, tkdiff, xxdiff, meld, opendiff,
-# emerge, ecmerge, vimdiff, gvimdiff, and custom user-configurable tools.
# This script is typically launched by using the 'git difftool'
# convenience command.
#
@@ -70,9 +68,9 @@ if test -z "$merge_tool"; then
if test -n "$DISPLAY"; then
# If gnome then prefer meld, otherwise, prefer kdiff3 or kompare
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld kdiff3 kompare tkdiff xxdiff gvimdiff"
+ merge_tool_candidates="meld kdiff3 kompare tkdiff xxdiff gvimdiff diffuse"
else
- merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff"
+ merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff diffuse"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
index 3ba332b..197533e 100644
--- a/git-mergetool-lib.sh
+++ b/git-mergetool-lib.sh
@@ -29,7 +29,7 @@ check_unchanged () {
valid_tool () {
case "$1" in
- kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge | diffuse)
if test "$1" = "kompare" && ! diff_mode; then
return 1
fi
@@ -108,6 +108,21 @@ run_mergetool () {
fi
check_unchanged
;;
+ diffuse)
+ if merge_mode; then
+ touch "$BACKUP"
+ fi
+ if $base_present; then
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE" "$BASE" | cat
+ else
+ if merge_mode; then
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE" | cat
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" | cat
+ fi
+ fi
+ check_unchanged
+ ;;
vimdiff)
if merge_mode; then
touch "$BACKUP"
diff --git a/git-mergetool.sh b/git-mergetool.sh
index fd81ad7..16562bd 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -284,9 +284,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 gvimdiff diffuse"
else
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff diffuse"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
--
1.6.2.1.303.g63699
^ permalink raw reply related
* [PATCH 2/3] mergetool-lib: specialize xxdiff options when in diff mode
From: David Aguilar @ 2009-04-02 10:30 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
In-Reply-To: <1238668246-762-1-git-send-email-davvid@gmail.com>
We don't need '-merged-file', 'save as', and the merge-status exit
code when in diff mode
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-mergetool-lib.sh | 22 +++++++++++++++-------
1 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
index e2d074d..3ba332b 100644
--- a/git-mergetool-lib.sh
+++ b/git-mergetool-lib.sh
@@ -127,7 +127,9 @@ run_mergetool () {
fi
;;
xxdiff)
- merge_mode && touch "$BACKUP"
+ if merge_mode; then
+ touch "$BACKUP"
+ fi
if $base_present; then
"$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
@@ -135,12 +137,18 @@ run_mergetool () {
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$MERGED" "$LOCAL" "$BASE" "$REMOTE"
else
- merge_mode && extra=--show-merged-pane
- "$merge_tool_path" -X $extra \
- -R 'Accel.SaveAsMerged: "Ctrl-S"' \
- -R 'Accel.Search: "Ctrl+F"' \
- -R 'Accel.SearchForward: "Ctrl-G"' \
- --merged-file "$MERGED" "$LOCAL" "$REMOTE"
+ if merge_mode; then
+ "$merge_tool_path" -X $extra \
+ -R 'Accel.SaveAsMerged: "Ctrl-S"' \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ --merged-file "$MERGED" "$LOCAL" "$REMOTE"
+ else
+ "$merge_tool_path" \
+ -R 'Accel.Search: "Ctrl+F"' \
+ -R 'Accel.SearchForward: "Ctrl-G"' \
+ "$LOCAL" "$REMOTE"
+ fi
fi
check_unchanged
;;
--
1.6.2.1.303.g63699
^ permalink raw reply related
* Re: How to sync two svn repositories via git?
From: Josef Wolf @ 2009-04-02 10:36 UTC (permalink / raw)
To: git
In-Reply-To: <49D46C2B.3080100@drmicha.warpmail.net>
On Thu, Apr 02, 2009 at 09:41:31AM +0200, Michael J Gruber wrote:
> Josef Wolf venit, vidit, dixit 02.04.2009 00:30:
[ ... ]
> > The first step I'd like to do is to "mirror" the manual merges that were
> > done between the subversion repositories in the past:
> >
> > git checkout svn-first
> > git merge -s ours --log commit-of-the-first-merge-in-svn-second
> >
> > git checkout svn-second
> > git merge -s ours --log commit-of-the-first-merge-in-svn-first
> >
> > This seems to work, but git-gui shows conflicts. How can I get conflicts
> > when I use the "-s ours" merge strategy?
>
> What do git status and git diff (--stat, --combined) say?
Umm, that's somewhat odd.
Directly after the merge commands, gitk says there are local modifications.
Then I run "git status" which says the working directory is clean. Then
I re-run gitk, which _now_ shows no local modifications any more.
^ permalink raw reply
* Re: [PATCH 3/3] mergetool-lib: add diffuse as merge and diff tool
From: David Aguilar @ 2009-04-02 10:42 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git, gitster, spearce
In-Reply-To: <1238668246-762-3-git-send-email-davvid@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1801 bytes --]
On 0, David Aguilar <davvid@gmail.com> wrote:
> From: Sebastian Pipping <sebastian@pipping.org>
>
> This adds diffuse as a built-in merge tool.
>
> Signed-off-by: Sebastian Pipping <sebastian@pipping.org>
> Signed-off-by: David Aguilar <davvid@gmail.com>
> ---
>
> This is Sebastian's patch rebased onto Junio's pu branch.
>
> I removed the git-gui part because I think git-gui
> patches go through Shawn / git-gui.git?
>
Hi Sebastian..
Here's the patch you sent a couple of days ago applied
onto Junio's pu branch
As I mentioned above, you had some git-gui changes in your
original that I stripped out since I was under the impression
that git-gui patches go through Shawn / git-gui.git.
git-send-email (probably gmail, too) won't let me send
one patch in a series with a different "From:" header,
so maybe you should resend this patch so that you can get the
proper authorship recognition? I've attached the original
patch file I sent in case you want to just grab it and
send-email it back out for the purposes of getting the right
authorship in there (actually, Junio, please advise...,
I'm not exactly sure what you'd prefer)
Also, all three patches should apply independently,
so even though this says 3/3 in principle they are
actually all independent patches,
I just happened to have them queued up that way.
>
> Documentation/git-difftool.txt | 4 ++--
> Documentation/git-mergetool.txt | 3 ++-
> Documentation/merge-config.txt | 7 ++++---
> contrib/completion/git-completion.bash | 3 ++-
> git-difftool-helper.sh | 6 ++----
> git-mergetool-lib.sh | 17 ++++++++++++++++-
> git-mergetool.sh | 4 ++--
> 7 files changed, 30 insertions(+), 14 deletions(-)
>
--
David
[-- Attachment #2: 0003-mergetool-lib-add-diffuse-as-merge-and-diff-tool.patch --]
[-- Type: text/x-diff, Size: 6284 bytes --]
>From 34186399f67930e3e0f6a8772fbea2966c997cfa Mon Sep 17 00:00:00 2001
From: Sebastian Pipping <sebastian@pipping.org>
Date: Thu, 26 Mar 2009 20:42:31 +0100
Subject: [PATCH 3/3] mergetool-lib: add diffuse as merge and diff tool
This adds diffuse as a built-in merge tool.
Signed-off-by: Sebastian Pipping <sebastian@pipping.org>
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This is Sebastian's patch rebased onto Junio's pu branch.
I removed the git-gui part because I think git-gui
patches go through Shawn / git-gui.git?
This diff is still too big, so maybe we should
refactor the $mergetool_candidate code into
mergetool-lib as well.
Documentation/git-difftool.txt | 4 ++--
Documentation/git-mergetool.txt | 3 ++-
Documentation/merge-config.txt | 7 ++++---
contrib/completion/git-completion.bash | 3 ++-
git-difftool-helper.sh | 6 ++----
git-mergetool-lib.sh | 17 ++++++++++++++++-
git-mergetool.sh | 4 ++--
7 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-difftool.txt b/Documentation/git-difftool.txt
index 73d4782..15b247b 100644
--- a/Documentation/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -30,8 +30,8 @@ OPTIONS
--tool=<tool>::
Use the diff tool specified by <tool>.
Valid merge tools are:
- kdiff3, kompare, tkdiff, meld, xxdiff, emerge,
- vimdiff, gvimdiff, ecmerge, and opendiff
+ kdiff3, kompare, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff,
+ ecmerge, diffuse and opendiff
+
If a diff tool is not specified, 'git-difftool'
will use the configuration variable `diff.tool`. If the
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 5d3c632..c3a8092 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,
+ diffuse 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 1ff08ff..c4fc3eb 100644
--- a/Documentation/merge-config.txt
+++ b/Documentation/merge-config.txt
@@ -22,9 +22,10 @@ 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
- "opendiff". Any other value is treated is custom merge tool
- and there must be a corresponding mergetool.<tool>.cmd option.
+ "tkdiff", "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff",
+ "diffuse" and "opendiff". Any other value is treated as a custom
+ merge tool and there must be a corresponding mergetool.<tool>.cmd
+ option.
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e72ce24..4fcd77a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1173,7 +1173,8 @@ _git_mergetool ()
--tool=*)
__gitcomp "
kdiff3 tkdiff meld xxdiff emerge
- vimdiff gvimdiff ecmerge opendiff
+ vimdiff gvimdiff ecmerge diffuse
+ opendiff
" "" "${cur##--tool=}"
return
;;
diff --git a/git-difftool-helper.sh b/git-difftool-helper.sh
index 2dfc870..d174b34 100755
--- a/git-difftool-helper.sh
+++ b/git-difftool-helper.sh
@@ -1,7 +1,5 @@
#!/bin/sh
# git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
-# It supports kdiff3, kompare, tkdiff, xxdiff, meld, opendiff,
-# emerge, ecmerge, vimdiff, gvimdiff, and custom user-configurable tools.
# This script is typically launched by using the 'git difftool'
# convenience command.
#
@@ -70,9 +68,9 @@ if test -z "$merge_tool"; then
if test -n "$DISPLAY"; then
# If gnome then prefer meld, otherwise, prefer kdiff3 or kompare
if test -n "$GNOME_DESKTOP_SESSION_ID" ; then
- merge_tool_candidates="meld kdiff3 kompare tkdiff xxdiff gvimdiff"
+ merge_tool_candidates="meld kdiff3 kompare tkdiff xxdiff gvimdiff diffuse"
else
- merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff"
+ merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff diffuse"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
diff --git a/git-mergetool-lib.sh b/git-mergetool-lib.sh
index 3ba332b..197533e 100644
--- a/git-mergetool-lib.sh
+++ b/git-mergetool-lib.sh
@@ -29,7 +29,7 @@ check_unchanged () {
valid_tool () {
case "$1" in
- kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
+ kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge | diffuse)
if test "$1" = "kompare" && ! diff_mode; then
return 1
fi
@@ -108,6 +108,21 @@ run_mergetool () {
fi
check_unchanged
;;
+ diffuse)
+ if merge_mode; then
+ touch "$BACKUP"
+ fi
+ if $base_present; then
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE" "$BASE" | cat
+ else
+ if merge_mode; then
+ "$merge_tool_path" "$LOCAL" "$MERGED" "$REMOTE" | cat
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" | cat
+ fi
+ fi
+ check_unchanged
+ ;;
vimdiff)
if merge_mode; then
touch "$BACKUP"
diff --git a/git-mergetool.sh b/git-mergetool.sh
index fd81ad7..16562bd 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -284,9 +284,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 gvimdiff diffuse"
else
- merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
+ merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff diffuse"
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
--
1.6.2.1.303.g63699
^ permalink raw reply related
* Re: "git clone --depth <depth>" producing history with <depth + 1> commits?
From: Johannes Schindelin @ 2009-04-02 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sebastian Pipping, git
In-Reply-To: <7veiwbokd7.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 1 Apr 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 1 Apr 2009, Sebastian Pipping wrote:
> >
> >> Sebastian Pipping wrote:
> >> > Is "git clone --depth 1 <ropository>" expected to give a history
> >> > with 2 commits? "--depth 2" gives 3 commits, "--depth 0" all.
> >> >
> >> > Is that by design or a bug?
> >>
> >> Anyone? Is "git clone --depth 1 <ropository>" really supposed to
> >> produce a history holding _two_ commits? Why so?
> >
> > Because storing _no_ commit (according to you, that should happen with
> > --depth=0) would make no sense?
>
> But then you can error out upon such a request.
Right. Or disable the shallow cloning, as is the case now.
> > After all, if you want to clone, you want to clone at least
> > _something_.
>
> I am a bit puzzled by your logic. If one is requested, shouldn't you
> give only one and not two?
Reading the OP again, I have to apologize: I missed the fact that there is
no way to have _just_ one commit.
And that is very obviously a bug.
If nobody beats me to it, I will take care of it this weekend.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] Header includes cleanup
From: Jeff King @ 2009-04-02 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Christian Couder, Nathaniel P Dawson, Johannes Sixt, git
In-Reply-To: <7v8wmjk4p6.fsf@gitster.siamese.dyndns.org>
On Wed, Apr 01, 2009 at 10:25:09PM -0700, Junio C Hamano wrote:
> > - a header file should be included in a C file only if it is needed to
> > compile the C file (it is not ok to include it only because it includes
> > many other headers that are needed)
>
> If that is the rule, perhaps the problem lies not in a .c program that
> includes such a .h header, but in the .h itself that includes many other
> header files.
If this were combined with splitting gigantic .h files (like cache.h)
into smaller logical units, then we could in theory speed up
recompilation times with make (we would also need to correctly track
header dependencies, but gcc -M can do this fairly easily).
But it does come at the price of actually having to consider which
include files are necessary. I can't think of more than half a dozen
times in the last year I have actually had to add a #include while
working on a git .c file, mostly because everything and the kitchen sink
is included by cache.h.
So I don't know if it is worth it.
-Peff
^ permalink raw reply
* [PATCH] bash completion: add git-difftool
From: David Aguilar @ 2009-04-02 11:30 UTC (permalink / raw)
To: gitster, spearce; +Cc: git, David Aguilar
This adds completion for difftool's --tool flag.
The known diff tool names were also consolidated into
a single variable.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
contrib/completion/git-completion.bash | 27 ++++++++++++++++++++++-----
1 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 4fcd77a..33a8ec7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -909,6 +909,26 @@ _git_diff ()
__git_complete_file
}
+__git_mergetools_common="diffuse ecmerge emerge kdiff3 meld opendiff
+ tkdiff vimdiff gvimdiff xxdiff
+"
+
+_git_difftool ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --tool=*)
+ __gitcomp "$__git_mergetools_common kompare" "" "${cur##--tool=}"
+ return
+ ;;
+ --*)
+ __gitcomp "--tool="
+ return
+ ;;
+ esac
+ COMPREPLY=()
+}
+
__git_fetch_options="
--quiet --verbose --append --upload-pack --force --keep --depth=
--tags --no-tags
@@ -1171,11 +1191,7 @@ _git_mergetool ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--tool=*)
- __gitcomp "
- kdiff3 tkdiff meld xxdiff emerge
- vimdiff gvimdiff ecmerge diffuse
- opendiff
- " "" "${cur##--tool=}"
+ __gitcomp "$__git_mergetools_common" "" "${cur##--tool=}"
return
;;
--*)
@@ -1900,6 +1916,7 @@ _git ()
config) _git_config ;;
describe) _git_describe ;;
diff) _git_diff ;;
+ difftool) _git_difftool;;
fetch) _git_fetch ;;
format-patch) _git_format_patch ;;
fsck) _git_fsck ;;
--
1.6.2.1.469.gdffc1
^ permalink raw reply related
* [PATCH] {diff,merge}tool: rename helpers to remove them from tab-completion
From: David Aguilar @ 2009-04-02 11:38 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
Users should never run difftool-helper or mergetool-lib directly,
so rename them to *--helper and *--lib. This keeps the helper
scripts from showing up when using bash tab completion.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This is based on the 'pu' branch + the patches
I sent out earlier.
.gitignore | 4 ++--
...it-mergetool-lib.txt => git-mergetool--lib.txt} | 10 +++++-----
Makefile | 4 ++--
command-list.txt | 2 +-
git-difftool-helper.sh => git-difftool--helper.sh | 6 +++---
git-difftool.perl | 6 +++---
git-mergetool-lib.sh => git-mergetool--lib.sh | 2 +-
git-mergetool.sh | 2 +-
8 files changed, 18 insertions(+), 18 deletions(-)
rename Documentation/{git-mergetool-lib.txt => git-mergetool--lib.txt} (82%)
rename git-difftool-helper.sh => git-difftool--helper.sh (96%)
rename git-mergetool-lib.sh => git-mergetool--lib.sh (98%)
diff --git a/.gitignore b/.gitignore
index 75c154a..757c7f0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,7 +36,7 @@ git-diff-files
git-diff-index
git-diff-tree
git-difftool
-git-difftool-helper
+git-difftool--helper
git-describe
git-fast-export
git-fast-import
@@ -80,7 +80,7 @@ git-merge-recursive
git-merge-resolve
git-merge-subtree
git-mergetool
-git-mergetool-lib
+git-mergetool--lib
git-mktag
git-mktree
git-name-rev
diff --git a/Documentation/git-mergetool-lib.txt b/Documentation/git-mergetool--lib.txt
similarity index 82%
rename from Documentation/git-mergetool-lib.txt
rename to Documentation/git-mergetool--lib.txt
index 7377774..ffda66b 100644
--- a/Documentation/git-mergetool-lib.txt
+++ b/Documentation/git-mergetool--lib.txt
@@ -1,13 +1,13 @@
-git-mergetool-lib(1)
-====================
+git-mergetool--lib(1)
+=====================
NAME
----
-git-mergetool-lib - Common git merge tool shell scriptlets
+git-mergetool--lib - Common git merge tool shell scriptlets
SYNOPSIS
--------
-'. "$(git --exec-path)/git-mergetool-lib"'
+'. "$(git --exec-path)/git-mergetool--lib"'
DESCRIPTION
-----------
@@ -16,7 +16,7 @@ This is not a command the end user would want to run. Ever.
This documentation is meant for people who are studying the
Porcelain-ish scripts and/or are writing new ones.
-The 'git-mergetool-lib' scriptlet is designed to be sourced (using
+The 'git-mergetool--lib' scriptlet is designed to be sourced (using
`.`) by other shell scripts to set up functions for working
with git merge tools.
diff --git a/Makefile b/Makefile
index 086f9e7..3e56274 100644
--- a/Makefile
+++ b/Makefile
@@ -277,14 +277,14 @@ TEST_PROGRAMS =
SCRIPT_SH += git-am.sh
SCRIPT_SH += git-bisect.sh
-SCRIPT_SH += git-difftool-helper.sh
+SCRIPT_SH += git-difftool--helper.sh
SCRIPT_SH += git-filter-branch.sh
SCRIPT_SH += git-lost-found.sh
SCRIPT_SH += git-merge-octopus.sh
SCRIPT_SH += git-merge-one-file.sh
SCRIPT_SH += git-merge-resolve.sh
SCRIPT_SH += git-mergetool.sh
-SCRIPT_SH += git-mergetool-lib.sh
+SCRIPT_SH += git-mergetool--lib.sh
SCRIPT_SH += git-parse-remote.sh
SCRIPT_SH += git-pull.sh
SCRIPT_SH += git-quiltimport.sh
diff --git a/command-list.txt b/command-list.txt
index 922c815..fd66395 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -69,7 +69,7 @@ git-merge-file plumbingmanipulators
git-merge-index plumbingmanipulators
git-merge-one-file purehelpers
git-mergetool ancillarymanipulators
-git-mergetool-lib purehelpers
+git-mergetool--lib purehelpers
git-merge-tree ancillaryinterrogators
git-mktag plumbingmanipulators
git-mktree plumbingmanipulators
diff --git a/git-difftool-helper.sh b/git-difftool--helper.sh
similarity index 96%
rename from git-difftool-helper.sh
rename to git-difftool--helper.sh
index d174b34..602cd4f 100755
--- a/git-difftool-helper.sh
+++ b/git-difftool--helper.sh
@@ -1,13 +1,13 @@
#!/bin/sh
-# git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
+# git-difftool--helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
# This script is typically launched by using the 'git difftool'
# convenience command.
#
# Copyright (c) 2009 David Aguilar
-# Load common functions from git-mergetool-lib
+# Load common functions from git-mergetool--lib
TOOL_MODE=diff
-. git-mergetool-lib
+. git-mergetool--lib
# difftool.prompt controls the default prompt/no-prompt behavior
# and is overridden with $GIT_DIFFTOOL*_PROMPT.
diff --git a/git-difftool.perl b/git-difftool.perl
index 985dfe0..948ff7f 100755
--- a/git-difftool.perl
+++ b/git-difftool.perl
@@ -2,11 +2,11 @@
# Copyright (c) 2009 David Aguilar
#
# This is a wrapper around the GIT_EXTERNAL_DIFF-compatible
-# git-difftool-helper script.
+# git-difftool--helper script.
#
# This script exports GIT_EXTERNAL_DIFF and GIT_PAGER for use by git.
# GIT_DIFFTOOL_NO_PROMPT, GIT_DIFFTOOL_PROMPT, and GIT_DIFF_TOOL
-# are exported for use by git-difftool-helper.
+# are exported for use by git-difftool--helper.
#
# Any arguments that are unknown to this script are forwarded to 'git diff'.
@@ -30,7 +30,7 @@ sub setup_environment
{
$ENV{PATH} = "$DIR:$ENV{PATH}";
$ENV{GIT_PAGER} = '';
- $ENV{GIT_EXTERNAL_DIFF} = 'git-difftool-helper';
+ $ENV{GIT_EXTERNAL_DIFF} = 'git-difftool--helper';
}
sub exe
diff --git a/git-mergetool-lib.sh b/git-mergetool--lib.sh
similarity index 98%
rename from git-mergetool-lib.sh
rename to git-mergetool--lib.sh
index 197533e..91d5453 100644
--- a/git-mergetool-lib.sh
+++ b/git-mergetool--lib.sh
@@ -1,4 +1,4 @@
-# git-mergetool-lib is a library for common merge tool functions
+# git-mergetool--lib is a library for common merge tool functions
diff_mode() {
test $TOOL_MODE = "diff"
}
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 16562bd..401c107 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -13,7 +13,7 @@ SUBDIRECTORY_OK=Yes
OPTIONS_SPEC=
TOOL_MODE=merge
. git-sh-setup
-. git-mergetool-lib
+. git-mergetool--lib
require_work_tree
# Returns true if the mode reflects a symlink
--
1.6.2.1.469.gdffc1
^ permalink raw reply related
* Re: [PATCH] tree_entry_interesting: Only recurse when the pathspec is a leading path component
From: Björn Steinbrink @ 2009-04-02 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, Anton Gyllenberg, git
In-Reply-To: <7vbprfn0ai.fsf@gitster.siamese.dyndns.org>
On 2009.04.01 21:32:05 -0700, Junio C Hamano wrote:
> I'm planning to queue this.
> [Improved version of my patch]
Ah, thanks. Got busy with other stuff, and tried to fix another related
bug in ls-tree which made me forget to send the match_tree_entry fix :-/
That other ls-tree bug is with recursing into subdirectories, because
match_tree_entry matches even when the base is a subdirectory, but
ls-tree doesn't actually want that behaviour, I think. For example:
$ git ls-tree --abbrev HEAD git-gui/macosx/AppMain.tcl
100644 blob ddbe633 git-gui/macosx/AppMain.tcl
$ git ls-tree --abbrev HEAD git-gui/
100644 blob f96112d git-gui/.gitattributes
100644 blob 6483b21 git-gui/.gitignore
100755 blob b3f937e git-gui/GIT-VERSION-GEN
100644 blob 3ad8a21 git-gui/Makefile
100755 blob 12e117e git-gui/git-gui--askpass
100755 blob e018e07 git-gui/git-gui.sh
040000 tree f723285 git-gui/lib
040000 tree 73f3c34 git-gui/macosx
040000 tree 11cd1a0 git-gui/po
040000 tree 144728d git-gui/windows
$ git ls-tree --abbrev HEAD git-gui/macosx/AppMain.tcl git-gui/
100644 blob f96112d git-gui/.gitattributes
100644 blob 6483b21 git-gui/.gitignore
100755 blob b3f937e git-gui/GIT-VERSION-GEN
100644 blob 3ad8a21 git-gui/Makefile
100755 blob 12e117e git-gui/git-gui--askpass
100755 blob e018e07 git-gui/git-gui.sh
040000 tree f723285 git-gui/lib
100644 blob ddbe633 git-gui/macosx/AppMain.tcl
100644 blob b3bf15f git-gui/macosx/Info.plist
100644 blob 77d88a7 git-gui/macosx/git-gui.icns
040000 tree 11cd1a0 git-gui/po
040000 tree 144728d git-gui/windows
The last ls-tree shows all entries from git-gui/macosx/, beacuse the
first pattern makes it descend into that tree and all entries are
matched by the git-gui/ prefix. So the combined ls-tree shows more than
what the individual calls show. Seems wrong to me, but I'm unsure how to
tackle that, assuming that match_tree_entry is right in allowing any
base that's a subdirectory of a specified pathspec.
Björn
^ permalink raw reply
* [PATCH] git remote update: New option --prune (-p)
From: Finn Arne Gangstad @ 2009-04-02 12:38 UTC (permalink / raw)
To: git, gitster
With the --prune (or -p) option, git remote update will also prune
all the remotes that it fetches. Previously, you had to do a manual git
remote prune <remote> for each of the remotes you wanted to prune, and this
could be tedious with many remotes.
A single command will now update all remotes, and remove all stale
branches: git remote update -p
Signed-off-by: Finn Arne Gangstad <finnag@pvv.org>
---
Documentation/git-remote.txt | 4 ++-
builtin-remote.c | 73 ++++++++++++++++++++++++++----------------
2 files changed, 48 insertions(+), 29 deletions(-)
diff --git a/Documentation/git-remote.txt b/Documentation/git-remote.txt
index c9c0e6f..0b6e67d 100644
--- a/Documentation/git-remote.txt
+++ b/Documentation/git-remote.txt
@@ -16,7 +16,7 @@ SYNOPSIS
'git remote set-head' <name> [-a | -d | <branch>]
'git remote show' [-n] <name>
'git remote prune' [-n | --dry-run] <name>
-'git remote update' [group]
+'git remote update' [-p | --prune] [group]
DESCRIPTION
-----------
@@ -125,6 +125,8 @@ the configuration parameter remotes.default will get used; if
remotes.default is not defined, all remotes which do not have the
configuration parameter remote.<name>.skipDefaultUpdate set to true will
be updated. (See linkgit:git-config[1]).
++
+With `--prune` option, prune all the remotes that are updated.
DISCUSSION
diff --git a/builtin-remote.c b/builtin-remote.c
index 9ef846f..da46b5f 100644
--- a/builtin-remote.c
+++ b/builtin-remote.c
@@ -15,7 +15,7 @@ static const char * const builtin_remote_usage[] = {
"git remote set-head <name> [-a | -d | <branch>]",
"git remote show [-n] <name>",
"git remote prune [-n | --dry-run] <name>",
- "git remote [-v | --verbose] update [group]",
+ "git remote [-v | --verbose] update [-p | --prune] [group]",
NULL
};
@@ -26,6 +26,7 @@ static const char * const builtin_remote_usage[] = {
static int verbose;
static int show_all(void);
+static int prune_remote(const char *remote, int dry_run);
static inline int postfixcmp(const char *string, const char *postfix)
{
@@ -1128,46 +1129,51 @@ static int prune(int argc, const char **argv)
OPT__DRY_RUN(&dry_run),
OPT_END()
};
- struct ref_states states;
- const char *dangling_msg;
argc = parse_options(argc, argv, options, builtin_remote_usage, 0);
if (argc < 1)
usage_with_options(builtin_remote_usage, options);
- dangling_msg = (dry_run
- ? " %s will become dangling!\n"
- : " %s has become dangling!\n");
-
- memset(&states, 0, sizeof(states));
for (; argc; argc--, argv++) {
- int i;
+ result |= prune_remote(*argv, dry_run);
+ }
+ return result;
+}
- get_remote_ref_states(*argv, &states, GET_REF_STATES);
+static int prune_remote(const char *remote, int dry_run)
+{
+ int result = 0;
+ struct ref_states states;
+ const char *dangling_msg = dry_run
+ ? " %s will become dangling!\n"
+ : " %s has become dangling!\n";
- if (states.stale.nr) {
- printf("Pruning %s\n", *argv);
- printf("URL: %s\n",
- states.remote->url_nr
- ? states.remote->url[0]
- : "(no URL)");
- }
+ memset(&states, 0, sizeof(states));
+ int i;
- for (i = 0; i < states.stale.nr; i++) {
- const char *refname = states.stale.items[i].util;
+ get_remote_ref_states(remote, &states, GET_REF_STATES);
- if (!dry_run)
- result |= delete_ref(refname, NULL, 0);
+ if (states.stale.nr) {
+ printf("Pruning %s\n", remote);
+ printf("URL: %s\n",
+ states.remote->url_nr
+ ? states.remote->url[0]
+ : "(no URL)");
+ }
- printf(" * [%s] %s\n", dry_run ? "would prune" : "pruned",
- abbrev_ref(refname, "refs/remotes/"));
- warn_dangling_symref(dangling_msg, refname);
- }
+ for (i = 0; i < states.stale.nr; i++) {
+ const char *refname = states.stale.items[i].util;
- free_remote_ref_states(&states);
+ if (!dry_run)
+ result |= delete_ref(refname, NULL, 0);
+
+ printf(" * [%s] %s\n", dry_run ? "would prune" : "pruned",
+ abbrev_ref(refname, "refs/remotes/"));
+ warn_dangling_symref(dangling_msg, refname);
}
+ free_remote_ref_states(&states);
return result;
}
@@ -1204,10 +1210,18 @@ static int get_remote_group(const char *key, const char *value, void *cb)
static int update(int argc, const char **argv)
{
- int i, result = 0;
+ int i, result = 0, prune = 0;
struct string_list list = { NULL, 0, 0, 0 };
static const char *default_argv[] = { NULL, "default", NULL };
+ struct option options[] = {
+ OPT_GROUP("update specific options"),
+ OPT_BOOLEAN('p', "prune", &prune,
+ "prune remotes after fecthing"),
+ OPT_END()
+ };
+ argc = parse_options(argc, argv, options, builtin_remote_usage,
+ PARSE_OPT_KEEP_ARGV0);
if (argc < 2) {
argc = 2;
argv = default_argv;
@@ -1222,8 +1236,11 @@ static int update(int argc, const char **argv)
if (!result && !list.nr && argc == 2 && !strcmp(argv[1], "default"))
result = for_each_remote(get_one_remote_for_update, &list);
- for (i = 0; i < list.nr; i++)
+ for (i = 0; i < list.nr; i++) {
result |= fetch_remote(list.items[i].string);
+ if (prune)
+ prune_remote(list.items[i].string, 0);
+ }
/* all names were strdup()ed or strndup()ed */
list.strdup_strings = 1;
--
1.6.2.1.470.gd21ca.dirty
^ permalink raw reply related
* Broken t9001 tests
From: Johannes Schindelin @ 2009-04-02 13:22 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
Hi,
only when I revert both dc1460a(send-email: ask_default should apply to
all emails, not just the first) and c18f75a(send-email: add tests for
refactored prompting) does my test suite pass without asking me
_interactively_ (twice, even) if I want to
Send this email? ([y]es|[n]o|[q]uit|[a]ll):
Please fix.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Fix 'git checkout <submodule>' to update the index
From: Johannes Schindelin @ 2009-04-02 13:30 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <cover.1238678601u.git.johannes.schindelin@gmx.de>
While 'git checkout <submodule>' should not update the submodule's
working directory, it should update the index. This is in line with
how submodules are handled in the rest of Git.
While at it, test 'git reset [<commit>] <submodule>', too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I have no idea who thought that it would be a good idea to leave
the submodules alone, but I think it is highly counterintuitive
that
git checkout <submodule>
does not touch the index.
This patch fixes it.
I'm really swamped with work these days, but happily, this fix was
part of it: one of my users had a merge conflict in a submodule
and wanted to use the same procedure as for files.
In the meantime, "git reset <submodule>" did the job, but this
rather limits the user's options:
git checkout --theirs <submodule>
is a much desired function here. (Note: I did not test that this
works, actually, but then, I do not see why it should not, after
this patch...)
builtin-checkout.c | 3 --
t/t2013-checkout-submodule.sh | 42 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 3 deletions(-)
create mode 100755 t/t2013-checkout-submodule.sh
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 33d1fec..2e4fe1a 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -53,9 +53,6 @@ static int update_some(const unsigned char *sha1, const char *base, int baselen,
int len;
struct cache_entry *ce;
- if (S_ISGITLINK(mode))
- return 0;
-
if (S_ISDIR(mode))
return READ_TREE_RECURSIVE;
diff --git a/t/t2013-checkout-submodule.sh b/t/t2013-checkout-submodule.sh
new file mode 100755
index 0000000..fda3f0a
--- /dev/null
+++ b/t/t2013-checkout-submodule.sh
@@ -0,0 +1,42 @@
+#!/bin/sh
+
+test_description='checkout can handle submodules'
+
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+ mkdir submodule &&
+ (cd submodule &&
+ git init &&
+ test_commit first) &&
+ git add submodule &&
+ test_tick &&
+ git commit -m superproject &&
+ (cd submodule &&
+ test_commit second) &&
+ git add submodule &&
+ test_tick &&
+ git commit -m updated.superproject
+'
+
+test_expect_success '"reset <submodule>" updates the index' '
+ git update-index --refresh &&
+ git diff-files --quiet &&
+ git diff-index --quiet --cached HEAD &&
+ test_must_fail git reset HEAD^ submodule &&
+ test_must_fail git diff-files --quiet &&
+ git reset submodule &&
+ git diff-files --quiet
+'
+
+test_expect_success '"checkout <submodule>" updates the index only' '
+ git update-index --refresh &&
+ git diff-files --quiet &&
+ git diff-index --quiet --cached HEAD &&
+ git checkout HEAD^ submodule &&
+ test_must_fail git diff-files --quiet &&
+ git checkout HEAD submodule &&
+ git diff-files --quiet
+'
+
+test_done
--
1.6.2.1.493.g67cf3
^ permalink raw reply related
* Re: [PATCH] git remote update: New option --prune (-p)
From: demerphq @ 2009-04-02 13:34 UTC (permalink / raw)
To: Finn Arne Gangstad; +Cc: git, gitster
In-Reply-To: <20090402123823.GA1756@pvv.org>
2009/4/2 Finn Arne Gangstad <finnag@pvv.org>:
> With the --prune (or -p) option, git remote update will also prune
> all the remotes that it fetches. Previously, you had to do a manual git
> remote prune <remote> for each of the remotes you wanted to prune, and this
> could be tedious with many remotes.
Yay!
But one question. It seem to me odd to put this as an option to git
remote update, and not git remote prune.
I mean, it seems weird that one must say:
git remote update --prune
and one cannot say:
git remote prune --all
especially when there is a `git remote prune` already. It seems a bit
counterintuitive to find pruning actions under "update", but not all
that strange to find an all "--all" option for the "prune" action.
Although to me having both be allowed and mean the same thing also makes sense.
Anyway, thanks for this regardless, I am looking forward to this
functionality. :-)
Cheers,
yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Broken t9001 tests
From: Jeff King @ 2009-04-02 13:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jay Soffian, git
In-Reply-To: <alpine.DEB.1.00.0904021520200.7464@intel-tinevez-2-302>
On Thu, Apr 02, 2009 at 03:22:33PM +0200, Johannes Schindelin wrote:
> only when I revert both dc1460a(send-email: ask_default should apply to
> all emails, not just the first) and c18f75a(send-email: add tests for
> refactored prompting) does my test suite pass without asking me
> _interactively_ (twice, even) if I want to
>
> Send this email? ([y]es|[n]o|[q]uit|[a]ll):
>
> Please fix.
Try
http://article.gmane.org/gmane.comp.version-control.git/115280
Junio seems to have picked up the first part of the series, but not this
fix. I'm not sure why.
-Peff
^ permalink raw reply
* Re: [PATCH] git remote update: New option --prune (-p)
From: Jeff King @ 2009-04-02 13:44 UTC (permalink / raw)
To: demerphq; +Cc: Finn Arne Gangstad, git, gitster
In-Reply-To: <9b18b3110904020634i17633645ue4ba91701ea243a1@mail.gmail.com>
On Thu, Apr 02, 2009 at 03:34:15PM +0200, demerphq wrote:
> But one question. It seem to me odd to put this as an option to git
> remote update, and not git remote prune.
>
> I mean, it seems weird that one must say:
>
> git remote update --prune
>
> and one cannot say:
>
> git remote prune --all
But "git remote update" actually respects "remote groups", so it is not
just "--all". I think what you want is "git remote prune <group>".
> especially when there is a `git remote prune` already. It seems a bit
> counterintuitive to find pruning actions under "update", but not all
> that strange to find an all "--all" option for the "prune" action.
I think it makes sense under update as pruning is really just a
different (and perhaps slightly more dangerous) form of update.
Generally I would only want to run prune after having run update, so
combining them makes sense from a workflow perspective.
> Although to me having both be allowed and mean the same thing also
> makes sense.
I think that would make sense, too.
-Peff
^ permalink raw reply
* Re: Broken t9001 tests
From: Jay Soffian @ 2009-04-02 14:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Jeff King, Junio C Hamano
In-Reply-To: <20090402134019.GA26699@coredump.intra.peff.net>
On Thu, Apr 2, 2009 at 9:40 AM, Jeff King <peff@peff.net> wrote:
> On Thu, Apr 02, 2009 at 03:22:33PM +0200, Johannes Schindelin wrote:
>
>> only when I revert both dc1460a(send-email: ask_default should apply to
>> all emails, not just the first) and c18f75a(send-email: add tests for
>> refactored prompting) does my test suite pass without asking me
>> _interactively_ (twice, even) if I want to
>>
>> Send this email? ([y]es|[n]o|[q]uit|[a]ll):
>>
>> Please fix.
Sorry, as Jeff mentions:
> Try
>
> http://article.gmane.org/gmane.comp.version-control.git/115280
And BTW, it's not as if I didn't test. The "going interactive" issue
is hidden by bash. But don't worry, I've since downloaded and
installed dash just for running git tests, so it won't happen again.
> Junio seems to have picked up the first part of the series, but not this
> fix. I'm not sure why.
Junio, may I please draw you attention to 3/4 and 4/4 at the link
above. Please amend the commit message for 3/4 though. It says it
corrects commit 67f1fe5 which is wrong. Please sed
's/67f1fe5/c18f75a/' in that message.
Thanks,
j.
^ permalink raw reply
* Re: [PATCH] git remote update: New option --prune (-p)
From: demerphq @ 2009-04-02 14:17 UTC (permalink / raw)
To: Jeff King; +Cc: Finn Arne Gangstad, git, gitster
In-Reply-To: <20090402134414.GB26699@coredump.intra.peff.net>
2009/4/2 Jeff King <peff@peff.net>:
> On Thu, Apr 02, 2009 at 03:34:15PM +0200, demerphq wrote:
>
>> But one question. It seem to me odd to put this as an option to git
>> remote update, and not git remote prune.
>>
>> I mean, it seems weird that one must say:
>>
>> git remote update --prune
>>
>> and one cannot say:
>>
>> git remote prune --all
>
> But "git remote update" actually respects "remote groups", so it is not
> just "--all". I think what you want is "git remote prune <group>".
Are there any implicit groups defined, like "all-remotes" or
something? It seems less than desirable to have to define such a group
for an operation that IMO is pretty reasonable to expect to happen
regularly.
I personally haven't found any use for defining remote groups yet to
be honest. Its a granularity of operation that hasnt served much
purpose for me yet. Although i could see it being useful in the
future.
Generally tho I either want to update and prune one remote only, with
git fetch $remote; git prune $remote,
or i want to update and prune all with something like:
git remote update; for r in $(git remote); do git remote prune $r; done;
This patch makes the latter better huffman encoded, but I'd kind of
expect both to be doable as single commands in terms of how often I
want to do them.
Maybe git fetch --prune would be a nice complement to this patch.
>> especially when there is a `git remote prune` already. It seems a bit
>> counterintuitive to find pruning actions under "update", but not all
>> that strange to find an all "--all" option for the "prune" action.
>
> I think it makes sense under update as pruning is really just a
> different (and perhaps slightly more dangerous) form of update.
> Generally I would only want to run prune after having run update, so
> combining them makes sense from a workflow perspective.
Yeah, conceptually they approach the same point from different angles.
>
>> Although to me having both be allowed and mean the same thing also
>> makes sense.
>
> I think that would make sense, too.
And the solution that presents the least surprise to the most users.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [PATCH] builtin-clone.c: allow multiple cmd_clone() calls
From: Ali Gholami Rudi @ 2009-04-02 14:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
With this patch, cmd_clone() safely frees its xstrdup()-allocated
memory. Also cmd_clone() registers remove_junk() (for getting called in
a signal handler or atexit()) at most once.
junk_work_tree and junk_git_dir (used in remove_junk()) were changed to
use static arrays rather than sharing the memory allocated in
cmd_clone(). The junk_* global variables are overwritten in each
cmd_clone() call. But if concurrent cmd_clone() calls are disallowed
that won't be an issue since we only care about the currently executing
cmd_clone() in remove_junk().
Signed-off-by: Ali Gholami Rudi <ali@rudi.ir>
---
builtin-clone.c | 30 +++++++++++++++++++-----------
1 files changed, 19 insertions(+), 11 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 880373f..6ef31cd 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -268,8 +268,9 @@ static const struct ref *clone_local(const char *src_repo,
return ret;
}
-static const char *junk_work_tree;
-static const char *junk_git_dir;
+static int junk_registered;
+static char junk_work_tree[PATH_MAX];
+static char junk_git_dir[PATH_MAX];
static pid_t junk_pid;
static void remove_junk(void)
@@ -277,12 +278,12 @@ static void remove_junk(void)
struct strbuf sb = STRBUF_INIT;
if (getpid() != junk_pid)
return;
- if (junk_git_dir) {
+ if (*junk_git_dir) {
strbuf_addstr(&sb, junk_git_dir);
remove_dir_recursively(&sb, 0);
strbuf_reset(&sb);
}
- if (junk_work_tree) {
+ if (*junk_work_tree) {
strbuf_addstr(&sb, junk_work_tree);
remove_dir_recursively(&sb, 0);
strbuf_reset(&sb);
@@ -320,8 +321,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0;
struct stat buf;
- const char *repo_name, *repo, *work_tree, *git_dir;
- char *path, *dir;
+ const char *repo_name, *work_tree;
+ char *path, *dir, *repo, *git_dir;
int dest_exists;
const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
@@ -362,7 +363,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
else if (!strchr(repo_name, ':'))
repo = xstrdup(make_absolute_path(repo_name));
else
- repo = repo_name;
+ repo = xstrdup(repo_name);
if (argc == 2)
dir = xstrdup(argv[1]);
@@ -393,7 +394,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
}
if (!option_bare) {
- junk_work_tree = work_tree;
+ strcpy(junk_work_tree, work_tree);
if (safe_create_leading_directories_const(work_tree) < 0)
die("could not create leading directories of '%s': %s",
work_tree, strerror(errno));
@@ -402,9 +403,12 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
work_tree, strerror(errno));
set_git_work_tree(work_tree);
}
- junk_git_dir = git_dir;
- atexit(remove_junk);
- sigchain_push_common(remove_junk_on_signal);
+ strcpy(junk_git_dir, git_dir);
+ if (!junk_registered) {
+ junk_registered = 1;
+ atexit(remove_junk);
+ sigchain_push_common(remove_junk_on_signal);
+ }
setenv(CONFIG_ENVIRONMENT, mkpath("%s/config", git_dir), 1);
@@ -590,6 +594,10 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
strbuf_release(&branch_top);
strbuf_release(&key);
strbuf_release(&value);
+ free(path);
+ free(repo);
+ free(dir);
+ free(git_dir);
junk_pid = 0;
return err;
}
^ permalink raw reply related
* Re: [PATCH] git remote update: New option --prune (-p)
From: Jeff King @ 2009-04-02 14:31 UTC (permalink / raw)
To: demerphq; +Cc: Finn Arne Gangstad, git, gitster
In-Reply-To: <9b18b3110904020717h3a0d4b34h7f4b2b83527e6743@mail.gmail.com>
On Thu, Apr 02, 2009 at 04:17:35PM +0200, demerphq wrote:
> > But "git remote update" actually respects "remote groups", so it is not
> > just "--all". I think what you want is "git remote prune <group>".
>
> Are there any implicit groups defined, like "all-remotes" or
> something? It seems less than desirable to have to define such a group
> for an operation that IMO is pretty reasonable to expect to happen
> regularly.
Yes. From "git help remote":
update
Fetch updates for a named set of remotes in the repository as
defined by remotes.<group>. If a named group is not specified on
the command line, the configuration parameter remotes.default will
get used; if remotes.default is not defined, all remotes which do
not have the configuration parameter
remote.<name>.skipDefaultUpdate set to true will be updated. (See
git-config(1)).
So without defining any other config, "git remote update" will by
default update everything
> I personally haven't found any use for defining remote groups yet to
> be honest. Its a granularity of operation that hasnt served much
> purpose for me yet. Although i could see it being useful in the
> future.
I haven't either. I suspect it would be useful if you had a complex set
of repo relationships, like an integration manager pulling from an
upstream but also from other developers.
> Generally tho I either want to update and prune one remote only, with
>
> git fetch $remote; git prune $remote,
It might be useful if "remote update" treated an unconfigured group as a
simple remote. So that "git remote update --prune $remote" would do what
you wanted here.
I could even see "remote.*.autoprune" config being useful so you could
avoid --prune. It is living dangerously, I suppose, for some workflows;
but I generally consider whatever is in my remote tracking branches to
be throwaway, and automatically pruning is not really dangerous.
> or i want to update and prune all with something like:
>
> git remote update; for r in $(git remote); do git remote prune $r; done;
>
> This patch makes the latter better huffman encoded, but I'd kind of
> expect both to be doable as single commands in terms of how often I
> want to do them.
>
> Maybe git fetch --prune would be a nice complement to this patch.
I think we have tried to keep pruning out of fetch, as fetch does not
necessarily use or know about tracking branches. But the "git remote
update $remote" proposal I gave above would do basically the same thing
(except you would call it "remote update" instead of "fetch").
-Peff
^ permalink raw reply
* RE: More help with "pull" please
From: John Dlugosz @ 2009-04-02 14:45 UTC (permalink / raw)
To: Junio C Hamano, Tomas Carnecky; +Cc: git
In-Reply-To: <7viqlnokrv.fsf@gitster.siamese.dyndns.org>
> If your repository is using .git/remotes/origin to name the "origin"
I don't have a directory under .git called remotes. A new repository
made using clone describes origin in the config file. Is that an old
way of doing things?
> remote, they are still honored. But you are correct to point out that
> branch.<name>.remote and with the remote.<name>.* variables in
> .git/config
> are used to control these more recent features. So in that sense the
> documentation is still correct.
A related question: is the name "origin" hard-coded as the default, or
does each repository remember specifically which is the upstream
repository regardless of what you named it? From what I see in the
config file, it would have to be per-branch. I suppose in other cases
it's implicit in where the label was found under remotes.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: More help with "pull" please
From: Tomas Carnecky @ 2009-04-02 15:18 UTC (permalink / raw)
To: John Dlugosz; +Cc: Junio C Hamano, git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A7D4FF7@EXCHANGE.trad.tradestation.com>
On Apr 2, 2009, at 4:45 PM, John Dlugosz wrote:
>> If your repository is using .git/remotes/origin to name the "origin"
>
> I don't have a directory under .git called remotes. A new repository
> made using clone describes origin in the config file. Is that an old
> way of doing things?
Yep. Earlier git versions used one config file per remote. Newer git
versions use the .git/config file.
>> remote, they are still honored. But you are correct to point out
>> that
>> branch.<name>.remote and with the remote.<name>.* variables in
>> .git/config
>> are used to control these more recent features. So in that sense the
>> documentation is still correct.
>
> A related question: is the name "origin" hard-coded as the default,
> or
> does each repository remember specifically which is the upstream
> repository regardless of what you named it? From what I see in the
> config file, it would have to be per-branch. I suppose in other cases
> it's implicit in where the label was found under remotes.
'origin' is the default name for the remote you cloned from. But there
is nothing special to it other than being a default name used
throughout git. You can manually add remotes under a different name if
you like.
$ git clone $url ./xyz
is roughly the same as:
$ mkdir ./xyz && cd ./xyz
$ git init
$ git remote add origin $url
$ git fetch origin
$ git checkout -b master origin/master
tom
^ permalink raw reply
* Re: "git reflog expire --all" very slow
From: Linus Torvalds @ 2009-04-02 15:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, Johannes Schindelin, Git Mailing List
In-Reply-To: <7vmyazimds.fsf@gitster.siamese.dyndns.org>
On Wed, 1 Apr 2009, Junio C Hamano wrote:
>
> Correct. But after thinking about this a bit more, I am starting to suspect
> the "of course" in your earlier
>
> If I do
>
> mark_reachable(cb.ref_commit, 0);
>
> instead (to traverse the _whole_ tree, with no regards to date), the time
> shrinks to 1.7s. But of course, that's also wrong.
>
> may not be such a clearly obvious thing.
I think we should never do it up-front, because for nicely behaved people
who just pull other peoples work (which are also the people most likely to
not have beefy machines), the normal reflog is going to be entirely
reachable, and we don't have to traverse the whole thing.
So what I'd suggest is something like:
- start off with the time limit, possibly with some extra fudging
- but never bother calling "in_merge_bases()"
- if we ever get to a commit that doesn't look reachable in that
situation, we now have two choices:
(a) just use the dang 'object->flags & REACHABLE' flag as-is.
Why even bother to be clever? We did the reachability by time
already, it's done, it's there, just use it. In other words, the
reachability simply works like "--since=<date>'.
(b) Try to do the "exact" thing, and waste lots of time on it, and
maybe find an odd commit or two where the date had been wrong. Do
we really care?
I'd actually go for 'a', with a slight modification: try to convert the
"reflog date" (the date of a local action) into a "commit date" (the date
of a commit in the repository). Because those two are different "time
spaces", and comparing a "commit date" to a "in my repo" date is fairly
wrong.
But in general, I don't think this is something that needs any extra
precision. We're not talking about "theoretically reachable" here. We're
talking about reflog entries that are already older than the
unreachability limit, and that point to commits that are older than the
reachability limit. Yes, yes, clocks aren't synchronized, but do we really
care?
IOW, I'd suggest just removing the in_merge_base() tests entirely. Make
the semantics even simpler:
have_done_reachability = 0;
reachability_date = 0;
for_each_reflog_oldest_first() {
/* Older than unconditional expire? */
if (really_old(entry)) {
reachability_date = entry->commit->date;
goto prune;
}
/* Younger than the reflog reachability? */
if (really_young(entry) && !fix_stale)
goto save;
/*
* Ok, not an unconditional expire entry.
* Do the reachability - once
*/
if (!have_done_reachability) {
have_done_reachability = 1;
if (fix_stale)
reachability_date = 0;
mark_reachabile(top, reachability_date);
}
if (!(entry->commit->flags & REACHABLE))
goto prune;
save:
save(entry);
continue;
prune:
prune(entry);
continue;
}
Does that change semantics? Yes, absolutely. But it sounds very practical.
Linus
^ permalink raw reply
* Re: [PATCH] git remote update: New option --prune (-p)
From: demerphq @ 2009-04-02 16:07 UTC (permalink / raw)
To: Jeff King; +Cc: Finn Arne Gangstad, git, gitster
In-Reply-To: <20090402143112.GA26974@coredump.intra.peff.net>
2009/4/2 Jeff King <peff@peff.net>:
> On Thu, Apr 02, 2009 at 04:17:35PM +0200, demerphq wrote:
>
>> > But "git remote update" actually respects "remote groups", so it is not
>> > just "--all". I think what you want is "git remote prune <group>".
>>
>> Are there any implicit groups defined, like "all-remotes" or
>> something? It seems less than desirable to have to define such a group
>> for an operation that IMO is pretty reasonable to expect to happen
>> regularly.
>
> Yes. From "git help remote":
>
> update
> Fetch updates for a named set of remotes in the repository as
> defined by remotes.<group>. If a named group is not specified on
> the command line, the configuration parameter remotes.default will
> get used; if remotes.default is not defined, all remotes which do
> not have the configuration parameter
> remote.<name>.skipDefaultUpdate set to true will be updated. (See
> git-config(1)).
>
> So without defining any other config, "git remote update" will by
> default update everything
Er, personally i find that documentation pretty cryptic. And when i
check git config for group, i see this:
remotes.<group>
The list of remotes which are fetched by "git remote update
<group>". See git-remote(1).
and
remote.<name>.skipDefaultUpdate
If true, this remote will be skipped by default when updating using
the update subcommand of git-remote(1).
Neither of which really explain groups, how to define them properly,
(the list is separated by what? and includes the remote name?) or
whether there are implicit groups. I mean, it seems logical that if
you can have user defined groups that there are some built in ones
too, like "all" and "none" or perhaps groups defined by transport
"http" or "git" for instance.
>> I personally haven't found any use for defining remote groups yet to
>> be honest. Its a granularity of operation that hasnt served much
>> purpose for me yet. Although i could see it being useful in the
>> future.
>
> I haven't either. I suspect it would be useful if you had a complex set
> of repo relationships, like an integration manager pulling from an
> upstream but also from other developers.
Now that you have called my attention to them in more detail i suspect
ill end up using them for a few things. Maybe ill try to write up a
doc patch once i have.
>> Generally tho I either want to update and prune one remote only, with
>>
>> git fetch $remote; git prune $remote,
>
> It might be useful if "remote update" treated an unconfigured group as a
> simple remote. So that "git remote update --prune $remote" would do what
> you wanted here.
It seems reasonable to me that names for groups and remotes should
stay distinct and that remotes are treated as being groups which
contain only the remote of the same name. These would be yet more
implicit groups.
>
> I could even see "remote.*.autoprune" config being useful so you could
> avoid --prune. It is living dangerously, I suppose, for some workflows;
> but I generally consider whatever is in my remote tracking branches to
> be throwaway, and automatically pruning is not really dangerous.
Me too.
>> or i want to update and prune all with something like:
>>
>> git remote update; for r in $(git remote); do git remote prune $r; done;
>>
>> This patch makes the latter better huffman encoded, but I'd kind of
>> expect both to be doable as single commands in terms of how often I
>> want to do them.
>>
>> Maybe git fetch --prune would be a nice complement to this patch.
>
> I think we have tried to keep pruning out of fetch, as fetch does not
> necessarily use or know about tracking branches. But the "git remote
> update $remote" proposal I gave above would do basically the same thing
> (except you would call it "remote update" instead of "fetch").
Ok, that makes sense. I see why fetch would be left out. Thanks for explaining.
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ 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