* [PATCH] git-mergetool: add support for ediff
From: Sam Vilain @ 2007-06-30 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
In-Reply-To: <11831937823756-git-send-email-sam.vilain@catalyst.net.nz>
There was emerge already but I much prefer this mode.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
Documentation/config.txt | 3 ++-
Documentation/git-mergetool.txt | 3 ++-
git-mergetool.sh | 19 ++++++++++++++-----
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 50503e8..4661e24 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -550,7 +550,8 @@ merge.summary::
merge.tool::
Controls which merge resolution program is used by
gitlink:git-mergetool[l]. Valid values are: "kdiff3", "tkdiff",
- "meld", "xxdiff", "emerge", "vimdiff", "gvimdiff", and "opendiff".
+ "meld", "xxdiff", "emerge", "ediff", "vimdiff", "gvimdiff", and
+ "opendiff".
merge.verbosity::
Controls the amount of output shown by the recursive merge
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..1efe6e4 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,8 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, ediff, vimdiff, gvimdiff,
+ and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7b66309..6fda8af 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -258,6 +258,15 @@ merge_file () {
status=$?
save_backup
;;
+ ediff)
+ if base_present ; then
+ emacs --eval "(ediff-merge-files-with-ancestor \"$LOCAL\" \"$REMOTE\" \"$BASE\" nil \"$path\")"
+ else
+ emacs --eval "(ediff-merge-files \"$LOCAL\" \"$REMOTE\" nil \"$path\")"
+ fi
+ status=$?
+ save_backup
+ ;;
esac
if test "$status" -ne 0; then
echo "merge of $path failed" 1>&2
@@ -299,7 +308,7 @@ done
if test -z "$merge_tool"; then
merge_tool=`git-config merge.tool`
case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | ediff | vimdiff | gvimdiff | "")
;; # happy
*)
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
@@ -320,15 +329,15 @@ if test -z "$merge_tool" ; then
fi
fi
if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
- merge_tool_candidates="$merge_tool_candidates emerge"
+ merge_tool_candidates="$merge_tool_candidates emerge ediff"
fi
if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
merge_tool_candidates="$merge_tool_candidates vimdiff"
fi
- merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
+ merge_tool_candidates="$merge_tool_candidates opendiff ediff emerge vimdiff"
echo "merge tool candidates: $merge_tool_candidates"
for i in $merge_tool_candidates; do
- if test $i = emerge ; then
+ if test $i = emerge || test $i = ediff ; then
cmd=emacs
else
cmd=$i
@@ -351,7 +360,7 @@ case "$merge_tool" in
exit 1
fi
;;
- emerge)
+ emerge|ediff)
if ! type "emacs" > /dev/null 2>&1; then
echo "Emacs is not available"
exit 1
--
1.5.2.1.1131.g3b90
^ permalink raw reply related
* a bunch of outstanding updates
From: Sam Vilain @ 2007-06-30 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Following up to this e-mail are a whole load of outstanding feature
requests of mine.
These changes are relatively mundane:
* repack: improve documentation on -a option
* git-remote: document -n
* git-remote: allow 'git-remote fetch' as a synonym for 'git fetch'
* git-svn: use git-log rather than rev-list | xargs cat-file
* git-svn: cache max revision in rev_db databases
This one will impact on the version displayed by "git --version", but
I think this is for the better:
* GIT-VERSION-GEN: don't convert - delimiter to .'s
These ones are really only very minor updates based on feedback so
far:
* git-merge-ff: fast-forward only merge
* git-mergetool: add support for ediff
This one is just the previously posted hook script put into the
templates directory, let me know if you'd rather I reshaped it to go
into contrib/hooks:
* contrib/hooks: add post-update hook for updating working copy
This one probably needs a bit more consideration and review, could
perhaps sit on pu.
* git-repack: generational repacking (and example hook script)
^ permalink raw reply
* [PATCH] git-repack: generational repacking (and example hook script)
From: Sam Vilain @ 2007-06-30 8:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Sam Vilain
In-Reply-To: <11831937823588-git-send-email-sam.vilain@catalyst.net.nz>
Add an option to git-repack that makes the repack run suitable for
running very often. The idea is that packs get given a "generation",
and that the number of packs in each generation (except the last one)
is bounded.
The useful invocation of this is git-repack -d -g
The -a option then becomes a degenerate case of generative repacking.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
---
Documentation/git-repack.txt | 6 +++
git-repack.sh | 74 +++++++++++++++++++++++++++++++++++-------
templates/hooks--post-commit | 14 +++++++-
3 files changed, 81 insertions(+), 13 deletions(-)
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index be8e5f8..d458377 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -42,6 +42,12 @@ OPTIONS
existing packs redundant, remove the redundant packs.
Also runs gitlink:git-prune-packed[1].
+-g::
+ Enable "generational" repacking. This attempts to keep the
+ number of packs under control when repacking very often. Most
+ useful when called from the `post-commit` hook (see
+ link:hooks.html[hooks] for more information).
+
-l::
Pass the `--local` option to `git pack-objects`, see
gitlink:git-pack-objects[1].
diff --git a/git-repack.sh b/git-repack.sh
index 8c32724..3d253fa 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -3,19 +3,21 @@
# Copyright (c) 2005 Linus Torvalds
#
-USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--depth=N]'
+USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [-g] [--max-pack-size=N] [--window=N] [--depth=N]'
SUBDIRECTORY_OK='Yes'
. git-sh-setup
-no_update_info= all_into_one= remove_redundant=
-local= quiet= no_reuse= extra=
+no_update_info= generations= remove_redundant=
+local= quiet= no_reuse= extra= generation_width=
while case "$#" in 0) break ;; esac
do
case "$1" in
-n) no_update_info=t ;;
- -a) all_into_one=t ;;
+ -a) generations=0 ;;
-d) remove_redundant=t ;;
-q) quiet=-q ;;
+ -g) generations=3 generation_width=10 ;;
+ -G) generations=$2; generation_width=5; shift ;;
-f) no_reuse=--no-reuse-object ;;
-l) local=--local ;;
--max-pack-size=*) extra="$extra $1" ;;
@@ -40,24 +42,69 @@ PACKTMP="$GIT_OBJECT_DIRECTORY/.tmp-$$-pack"
rm -f "$PACKTMP"-*
trap 'rm -f "$PACKTMP"-*' 0 1 2 3 15
+generation=
+redundant=
+
# There will be more repacking strategies to come...
-case ",$all_into_one," in
+case ",$generations," in
,,)
args='--unpacked --incremental'
;;
-,t,)
+,*,)
if [ -d "$PACKDIR" ]; then
+ max_gen=0
for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \
| sed -e 's/^\.\///' -e 's/\.pack$//'`
do
if [ -e "$PACKDIR/$e.keep" ]; then
: keep
else
- args="$args --unpacked=$e.pack"
existing="$existing $e"
+ if [ -e "$PACKDIR/$e.gen" ]; then
+ gen=`cat $PACKDIR/$e.gen`
+ else
+ gen=1
+ fi
+ [ "$max_gen" -lt $gen ] && max_gen=$gen
+ eval "gen_${gen}=\"\$gen_${gen} $e\"";
+ eval "c_gen_${gen}=\$((\$c_gen_${gen} + 1))";
fi
done
+ i=$max_gen
+ packing=
+ while [ $i -gt 0 ]
+ do
+ eval "c_gen=\$c_gen_$i"
+ eval "packs=\$gen_$i"
+ if [ -n "$c_gen" -a $i -gt "$generations" ]
+ then
+ echo "saw $c_gen packs at generation $i"
+ echo "therefore, repacking everything"
+ packing=1
+ [ -z "$generation" ] && generation=$(($i + 1))
+ elif [ -n "$c_gen" -a "$c_gen" -ge "$generation_width" -a "$i" -lt "$generations" ]
+ then
+ echo -n "generation $i has too many packs "
+ echo "($c_gen >= $generation_width)"
+ echo "repacking at this level and below"
+ packing=1
+ [ -z "$generation" ] && generation=$(($i + 1))
+ fi
+ if [ -n "$packing" ]
+ then
+ for x in $packs; do
+ args="$args --unpacked=$x.pack"
+ redundant="$redundant $x"
+ done
+ fi
+ i=$(($i - 1))
+ done
+ if [ -n "$generation" ]; then
+ [ "$generation" -gt "$generations" ] && generation=$generations
+ [ "$generation" -eq 0 ] && generation=1
+ fi
fi
+
[ -z "$args" ] && args='--unpacked --incremental'
;;
esac
@@ -95,20 +142,23 @@ for name in $names ; do
exit 1
}
rm -f "$PACKDIR/old-pack-$name.pack" "$PACKDIR/old-pack-$name.idx"
+ [ -n "$generation" ] && echo $generation > "$PACKDIR/pack-$name.gen"
done
if test "$remove_redundant" = t
then
- # We know $existing are all redundant.
- if [ -n "$existing" ]
+ echo "removing redundant packs"
+ # We know $redundant are all redundant.
+ if [ -n "$redundant" ]
then
sync
( cd "$PACKDIR" &&
- for e in $existing
+ for e in $redundant
do
case " $fullbases " in
- *" $e "*) ;;
- *) rm -f "$e.pack" "$e.idx" "$e.keep" ;;
+ *" $e "*) echo "ignoring $e" ;;
+ *) echo "removing $e.pack etc";
+ rm -f "$e.pack" "$e.idx" "$e.keep" ;;
esac
done
)
diff --git a/templates/hooks--post-commit b/templates/hooks--post-commit
index 8be6f34..669f1fc 100644
--- a/templates/hooks--post-commit
+++ b/templates/hooks--post-commit
@@ -5,4 +5,16 @@
#
# To enable this hook, make this file executable.
-: Nothing
+threshold=`git-config gc.threshold`
+threshold=${threshold-250}
+
+gd=`git-rev-parse --git-dir`
+found=$(find $gd/objects/?? -type f | head -$threshold | wc -l)
+
+if [ $found -ge $threshold ]
+then
+ echo "At least $threshold loose objects, running generational repack"
+ git-repack -g -d
+else
+ echo "Found only $found loose objects, less than $threshold"
+fi
--
1.5.2.1.1131.g3b90
^ permalink raw reply related
* Re: a bunch of outstanding updates
From: Frank Lichtenheld @ 2007-06-30 11:05 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <1183193781941-git-send-email-sam.vilain@catalyst.net.nz>
On Sat, Jun 30, 2007 at 08:56:11PM +1200, Sam Vilain wrote:
>
> Following up to this e-mail are a whole load of outstanding feature
> requests of mine.
FWIW, I would prefer you'd use --no-chain-reply-to for totally unrelated
changes. (But really I would prefer not to have -chain-reply-to as
default anyway...)
just my 2¢
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] git-remote: document -n
From: Frank Lichtenheld @ 2007-06-30 11:12 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <1183193782172-git-send-email-sam.vilain@catalyst.net.nz>
On Sat, Jun 30, 2007 at 08:56:16PM +1200, Sam Vilain wrote:
> From: Sam Vilain <sam@vilain.net>
>
> The 'show' and 'prune' commands accept an option '-n'; document what
> it does.
You might want to add that in the SYNOPSIS, too.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] repack: improve documentation on -a option
From: Frank Lichtenheld @ 2007-06-30 11:15 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <11831937813223-git-send-email-sam.vilain@catalyst.net.nz>
On Sat, Jun 30, 2007 at 08:56:12PM +1200, Sam Vilain wrote:
> -a::
> Instead of incrementally packing the unpacked objects,
> - pack everything available into a single pack.
> + pack everything referenced into a single pack.
> Especially useful when packing a repository that is used
> - for private development and there is no need to worry
> - about people fetching via dumb file transfer protocols
> - from it. Use with '-d'.
> + for private development and there no need to worry
Got "is" lost here intentionally? The change doesn't make sense
to me.
> + about people fetching via dumb protocols from it. Use
> + with '-d'. This will clean up the objects that `git prune`
> + leaves behind, but `git fsck-objects --full` shows as
> + dangling.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Alternative git logo and favicon
From: Carlos Rica @ 2007-06-30 12:20 UTC (permalink / raw)
To: Henrik Nyh; +Cc: git
In-Reply-To: <e8965c600706290054w43f896f3jaba176974938752d@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
I've created an image following the same idea... I attached it here
since I have no server to upload it and I don't know what license has
the original image from Git. Just for fun.
2007/6/29, Henrik Nyh <henrik@nyh.se>:
> I came up with an alternative logo/favicon to use with my gitweb:
> http://henrik.nyh.se/2007/06/alternative-git-logo-and-favicon.
>
> Thought I'd sent it to the list in case someone else likes them.
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[-- Attachment #2: git-logo-small-modified.png --]
[-- Type: image/png, Size: 498 bytes --]
^ permalink raw reply
* Re: most commonly used git commands?
From: Alex Riesen @ 2007-06-30 13:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0706281506390.4438@racer.site>
Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:
> > No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> > "chmod a+x blub".
>
> Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
> begin with.
>
But it is necessary on Windows (Cygwin): chmod(2) with mode set to
0644 will happily take execute permission from an .com, .bat, .cmd,
.pl, .exe or .dll file. Which means something different on Windows,
but results in unexpectedly (for a Windows user) looking errors. The
users there do not expect seeing an .exe-file but be not able to
run it.
^ permalink raw reply
* Re: [PATCH] git-clone: fetch possibly detached HEAD over dumb http
From: Alex Riesen @ 2007-06-30 13:33 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: Junio C Hamano, git, Louis-Noel Pouchet
In-Reply-To: <20070629083108.GA14747@liacs.nl>
Sven Verdoolaege, Fri, Jun 29, 2007 10:31:08 +0200:
> + head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
> + case "$head_sha1" in
> + 'ref: refs/'*)
> + ;;
And what do you do if the HEAD is a reflink on something not in refs/?
Like "ref: tmp"? Yes, it is unlikely, but is not forbidden.
How about "[0-9a-f]*)" instead:
case "$head_sha1" in
[0-9a-f]*)
git-http-fetch $v -a "$head_sha1" "$1" ||
rm -f "$GIT_DIR/REMOTE_HEAD"
;;
esac
^ permalink raw reply
* Re: [PATCH] git-clone: fetch possibly detached HEAD over dumb http
From: Sven Verdoolaege @ 2007-06-30 13:45 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Louis-Noel Pouchet
In-Reply-To: <20070630133310.GB2866@steel.home>
On Sat, Jun 30, 2007 at 03:33:10PM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Fri, Jun 29, 2007 10:31:08 +0200:
> > + head_sha1=`cat "$GIT_DIR/REMOTE_HEAD"`
> > + case "$head_sha1" in
> > + 'ref: refs/'*)
> > + ;;
>
> And what do you do if the HEAD is a reflink on something not in refs/?
> Like "ref: tmp"? Yes, it is unlikely, but is not forbidden.
It may not be forbidden, but I don't think it would
work with current git-clone either.
skimo
^ permalink raw reply
* Re: [PATCH] git-merge-ff: fast-forward only merge
From: Johannes Schindelin @ 2007-06-30 14:28 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git
In-Reply-To: <11831937823756-git-send-email-sam.vilain@catalyst.net.nz>
Hi,
On Sat, 30 Jun 2007, Sam Vilain wrote:
> Documentation/merge-strategies.txt | 5 +++++
> Makefile | 2 +-
> git-merge-ff.sh | 8 ++++++++
> git-merge.sh | 4 ++--
Still no test script that could tell you if it does what it is supposed to
be...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Don't fflush(stdout) when it's not helpful
From: Theodore Tso @ 2007-06-30 14:27 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Jeff King, Frank Lichtenheld, Jim Meyering, git
In-Reply-To: <alpine.LFD.0.98.0706292114350.8675@woody.linux-foundation.org>
On Fri, Jun 29, 2007 at 09:24:41PM -0700, Linus Torvalds wrote:
> So you basically cannot get "perfect" with stdio. It's impossible. But the
> above re-ordering will at least get you _closer_, and *most* of the time
> you'll get exactly the error you'd expect.
Well, we *can* get perfect with stdio, but I can pretty much guarantee
no one will like it. We could wrap printf, fprintf, purchar, et. al,
and check each of them for an error return. The spec doesn't
currently specify that errno is supposed to be set, but a defect[1]
was filed last year saying that fprintf et.al, are indeed supposed to
set errno and not throw it away.
It would be a real pain in the *ss, though....
- Ted
[1] http://www.opengroup.org/austin/mailarchives/ag-review/msg02161.html
^ permalink raw reply
* Re: most commonly used git commands?
From: Johannes Schindelin @ 2007-06-30 14:31 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Sixt, git
In-Reply-To: <20070630131428.GA2866@steel.home>
Hi,
On Sat, 30 Jun 2007, Alex Riesen wrote:
> Johannes Schindelin, Thu, Jun 28, 2007 16:07:17 +0200:
> > > No. It was meant as Alex said it. Windows (MinGW) doesn't understand
> > > "chmod a+x blub".
> >
> > Yes, I suspected that. But I don't see a need for it on Windows (MinGW) to
> > begin with.
> >
>
> But it is necessary on Windows (Cygwin):
I thought that on Cygwin, filemode=1? I mean, Cygwin _never_ had problems
with chmod under my fingers.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH (3rd try)] Add git-stash script
From: Johannes Schindelin @ 2007-06-30 15:41 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Junio C Hamano
In-Reply-To: <200706300539.l5U5dHLh003989@mi1.bluebottle.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1104 bytes --]
Hi,
On Sat, 30 Jun 2007, しらいしななこ wrote:
> diff --git a/git-stash.sh b/git-stash.sh
> [...]
> + printf >&2 'Saved WIP on %s\n' "$msg"
You have an awful lot of printfs in the code. Why not just use echos?
> +list_stash () {
> + git-log --pretty=oneline -g "$@" $ref_stash |
Wouldn't you want "--default $ref_stash" here?
> +apply_stash () {
> + git-diff-files --quiet ||
> + die 'Cannot restore on top of a dirty state'
You meant "no_changes", right? I think you miss changes in the index
otherwise.
> + git-diff --cached --name-only --diff-filter=A $c_tree >"$a" &&
> + git-read-tree --reset $c_tree &&
> + git-update-index --add --stdin <"$a" ||
> + die "Cannot unstage modified files"
Isn't there a way to avoid the temporary file here?
> + else
> + # Merge conflict
> + exit 1
Since $? is already != 0, and it might tell the savvy user what kind of
error merge-recursive returned, why not use "exit", which is equivalent to
"exit $?"?
> + set x -n 10
> + shift
This is more elegantly written as "set -- -n 10", or in our context even
"set -- -10".
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add a manual page for git-stash
From: Johannes Schindelin @ 2007-06-30 15:44 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Junio C Hamano
In-Reply-To: <200706300539.l5U5dHLh003989@mi1.bluebottle.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-stash.txt | 116 +++++++++++++++++++++++++++++++++++++++++++
1 files changed, 116 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-stash.txt
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
new file mode 100644
index 0000000..b109f6e
--- /dev/null
+++ b/Documentation/git-stash.txt
@@ -0,0 +1,116 @@
+git-stash(1)
+=============
+
+NAME
+----
+git-stash - Stash the changes in a dirty working directory away
+
+SYNOPSIS
+--------
+[verse]
+'git-stash' [clear]
+'git-stash' [list | show | apply] [<stashname>]
+
+DESCRIPTION
+-----------
+Use 'git stash' when you want to record the current state of the
+working directory and the index, but want to go back to a clean
+working directory.
+
+For example, if you have to pull, but are in the middle of some
+interesting work, not yet ready to be committed, use git-stash.
+
+The default operation (when called without options), is to save
+the changes away.
+
+
+OPTIONS
+-------
+clear::
+ Undo _all_ stashes (dangerous!).
+
+list [<stashname>]::
+ List all stashed states.
+
+show [<stashname>]::
+ Show a combined diff of the stashed working directory, index and
+ HEAD.
+
+apply [<stashname>]::
+ Try to apply the stashed changes to the current HEAD. You need
+ a clean working directory for that, i.e. you must not have changes
+ relative to HEAD in your working directory or index.
+
+<stashname>::
+ A name of a stashed state. Typically something like 'stash@{2}'
+ or 'stash@{2.days.ago}'.
+
+
+EXAMPLES
+--------
+
+Get to a clean working directory, quick:
+
+---------------------
+$ git stash
+---------------------
+
+See what you stashed:
+
+---------------------
+$ git stash list
+---------------------
+
+Inspect the last stashed state:
+
+---------------------
+$ git stash show
+---------------------
+
+Inspect the second last stashed state:
+
+--------------------------
+$ git stash show stash@{1}
+--------------------------
+
+Apply the second last stashed state:
+
+---------------------------
+$ git stash apply stash@{1}
+---------------------------
+
+
+DISCUSSION
+----------
+
+The state is saved as three commits:
+
+- HEAD,
+- a commit which contains the state of the index, which has HEAD as a
+ parent, and
+- a commit which contains the state of the working directory (only the
+ tracked files, though), which has both HEAD and the second commit
+ as parents.
+
+The third commit holds the complete information of the stash, and is
+stored as the ref 'refs/stash'.
+
+Since that commit does not have any reference to other stashed states,
+the stash listing relies on the reflog of 'refs/stash'. Therefore,
+the stashed states are garbage collected like all the other reflogs.
+
+
+SEE ALSO
+--------
+gitlink:git-commit[1],
+gitlink:git-log[1],
+gitlink:git-reflog[1]
+
+Author
+------
+Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
--
1.5.2.2.3249.g33841
^ permalink raw reply related
* [PATCH] Add tests for git-stash
From: Johannes Schindelin @ 2007-06-30 16:06 UTC (permalink / raw)
To: しらいしななこ
Cc: GIT, Junio C Hamano
In-Reply-To: <200706300539.l5U5dHLh003989@mi1.bluebottle.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
In the current version of git-stash, the last test fails.
Basically, it tests if different changes to the file "file"
in the working directory and the index are reconstructed.
They are not (index changes are not there), but I think they
should be.
t/t3903-stash.sh | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 55 insertions(+), 0 deletions(-)
create mode 100755 t/t3903-stash.sh
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
new file mode 100755
index 0000000..6d42373
--- /dev/null
+++ b/t/t3903-stash.sh
@@ -0,0 +1,55 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Johannes E Schindelin
+#
+
+test_description='Test git-stash'
+
+. ./test-lib.sh
+
+test_expect_success 'stash some dirty working directory' '
+ echo 1 > file &&
+ git add file &&
+ test_tick &&
+ git commit -m initial &&
+ echo 2 > file &&
+ git add file &&
+ echo 3 > file &&
+ test_tick &&
+ git stash &&
+ git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD
+'
+
+cat > expect << EOF
+diff --git a/file b/file
+index 0cfbf08..00750ed 100644
+--- a/file
++++ b/file
+@@ -1 +1 @@
+-2
++3
+EOF
+
+test_expect_success 'parents of stash' '
+ test $(git rev-parse stash^) = $(git rev-parse HEAD) &&
+ git diff stash^2..stash > output &&
+ diff -u output expect
+'
+
+test_expect_success 'apply needs clean working directory' '
+ echo 4 > other-file &&
+ git add other-file &&
+ ! git stash apply
+'
+
+test_expect_success 'apply stashed changes' '
+ test_tick &&
+ git commit -m other-file &&
+ git stash apply &&
+ test 3 = $(cat file) &&
+ test 2 = $(git show :file) &&
+ test 1 = $(git show HEAD:file)
+'
+
+test_done
--
1.5.2.2.3249.g33841
^ permalink raw reply related
* Question about git-prune
From: walt @ 2007-06-30 16:29 UTC (permalink / raw)
To: git
I'm wondering why git-prune seems to work differently on the two git
repositories I track (Junio's and Linus's).
Specifically, when I use git-prune on Linus's kernel, all the dangling
objects disappear completely, and git-fsck shows no objects remaining.
But this is what happens with Junio's repository:
$cd src/git
$git-fsck
dangling tree c642c018aa55d39fff061183f58062de9d8375ac
dangling commit e1341abc3759950e891822088cb0163b71b316b3
dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
$git-prune
$git-fsck
dangling tree c642c018aa55d39fff061183f58062de9d8375ac
dangling commit e1341abc3759950e891822088cb0163b71b316b3
dangling commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
dangling commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
And here is another puzzle:
$git-fsck --unreachable
unreachable commit f291504563a5c96862e600247d233f91572a005f
unreachable tree 0e925e128b7b83750e2b8b0d901d7d518cadbdaf
unreachable tree c642c018aa55d39fff061183f58062de9d8375ac
unreachable tree 0b43ac348827a25d54a6fc90c36c12c4c6bdd6c1
unreachable tree 4d43b9900856904cdfc69769124b1930435dae51
unreachable commit e1341abc3759950e891822088cb0163b71b316b3
unreachable blob 590533321a99bf4d00b872a839527f00616ed593
unreachable tree e355b3845361c5f0c829bd146c47c77867aa36a3
unreachable tree 7e08ac7c56e51ea94db1dd6525c26fe123537b07
unreachable commit 9f38e1ef7e7992ca490b9b419f52fb4d11efb0e4
unreachable commit b82871b3c32faa8a317007f343fdf2d0ddc9954e
unreachable commit 750f7b668f33c9e8decbdd8141115328992d6fea
git-prune is supposed to remove all the unreachable objects, IIUC,
so it seems that git-prune does nothing at all in Junio's repo.
Can anyone reproduce this behavior, or explain it?
Thanks.
^ permalink raw reply
* Re: [PATCH] Add a manual page for git-stash
From: Frank Lichtenheld @ 2007-06-30 16:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT,
Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0706301644190.4438@racer.site>
On Sat, Jun 30, 2007 at 04:44:39PM +0100, Johannes Schindelin wrote:
> +Author
> +------
> +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
AFAICT "Author" is usually used for the author of the documented program
and "Documentation" for the author of the documentation itself.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] GIT-VERSION-GEN: don't convert - delimiter to .'s
From: Junio C Hamano @ 2007-06-30 17:19 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <11831937823982-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> Otherwise, a custom "v1.5.2.42.gb1ff" is considered newer than a
> "v1.5.2.1.69.gcafe"
Does this solve anything, I wonder? v1.5.2-this and
v1.5.2.1-that are not really comparable to begin with.
^ permalink raw reply
* Re: [PATCH] git-remote: allow 'git-remote fetch' as a synonym for 'git fetch'
From: Junio C Hamano @ 2007-06-30 17:19 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, Sam Vilain
In-Reply-To: <11831937822249-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> From: Sam Vilain <sam@vilain.net>
>
> I found myself typing this when doing remote-like things. Perhaps
> other people will find this useful
I would like to reject this, for the same reason I did not apply
three patch series "Human friendly git" on April 1st this year
;-).
^ permalink raw reply
* Re: [PATCH] git-mergetool: add support for ediff
From: Junio C Hamano @ 2007-06-30 17:19 UTC (permalink / raw)
To: Sam Vilain; +Cc: git, tytso
In-Reply-To: <11831937822950-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> There was emerge already but I much prefer this mode.
I thought Ted said he'll look into clearning this up, so I won't
apply it yet at this moment to my tree, but have one comment...
> @@ -320,15 +329,15 @@ if test -z "$merge_tool" ; then
> fi
> fi
> if echo "${VISUAL:-$EDITOR}" | grep 'emacs' > /dev/null 2>&1; then
> - merge_tool_candidates="$merge_tool_candidates emerge"
> + merge_tool_candidates="$merge_tool_candidates emerge ediff"
> fi
> if echo "${VISUAL:-$EDITOR}" | grep 'vim' > /dev/null 2>&1; then
> merge_tool_candidates="$merge_tool_candidates vimdiff"
> fi
> - merge_tool_candidates="$merge_tool_candidates opendiff emerge vimdiff"
> + merge_tool_candidates="$merge_tool_candidates opendiff ediff emerge vimdiff"
> echo "merge tool candidates: $merge_tool_candidates"
So by default outside X environment, if your $EDITOR is emacs,
you would use emerge and not ediff, but if your $EDITOR is unset
and have emacs in your $PATH you would use ediff not emerge?
^ permalink raw reply
* Re: [PATCH] repack: improve documentation on -a option
From: Junio C Hamano @ 2007-06-30 17:19 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Sam Vilain, git
In-Reply-To: <20070630111551.GR12721@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Sat, Jun 30, 2007 at 08:56:12PM +1200, Sam Vilain wrote:
>> -a::
>> Instead of incrementally packing the unpacked objects,
>> - pack everything available into a single pack.
>> + pack everything referenced into a single pack.
>> Especially useful when packing a repository that is used
>> - for private development and there is no need to worry
>> - about people fetching via dumb file transfer protocols
>> - from it. Use with '-d'.
>> + for private development and there no need to worry
>
> Got "is" lost here intentionally? The change doesn't make sense
> to me.
>
>> + about people fetching via dumb protocols from it. Use
>> + with '-d'. This will clean up the objects that `git prune`
>> + leaves behind, but `git fsck-objects --full` shows as
>> + dangling.
Also 'fsck-objects' is somewhat outdated. Will fix them up.
^ permalink raw reply
* Re: [PATCH (3rd try)] Add git-stash script
From: Junio C Hamano @ 2007-06-30 17:19 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0706301641000.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> diff --git a/git-stash.sh b/git-stash.sh
>> [...]
>> + printf >&2 'Saved WIP on %s\n' "$msg"
>
> You have an awful lot of printfs in the code. Why not just use echos?
I had the same impression, but I would say it is Ok (actually
printf is even better). Judging from our recent changes
(e.g. a23bfae) I think it is prudent to avoid echo when printing
user supplied messages. Not that corrupted backslash sequence
matters that much on stderr, though ;-).
>> +list_stash () {
>> + git-log --pretty=oneline -g "$@" $ref_stash |
>
> Wouldn't you want "--default $ref_stash" here?
But "git log --pretty=oneline -g master --default refs/stash"
would not make much sense would it? The design currently seems
to follow what I suggested earlier, namely to use a single stash
ref per repository, so $ref_stash is spelled as a variable but
it is a constant. IOW, you do not specify "alternate stash"
from the command line.
Unfortunately we do not have a good way to reject non-flag rev
parameters in "$@" to error out "git stash list master". What
we would want here is a way to allow things like --since=1.hour
and -20 while rejecting branch/tag names and other parameters.
>> +apply_stash () {
>> + git-diff-files --quiet ||
>> + die 'Cannot restore on top of a dirty state'
>
> You meant "no_changes", right? I think you miss changes in the index
> otherwise.
Interestingly, I think this is actually correct in the sense
that the code is internally consistent, as it uses the current
index, not the HEAD, as the base of application. It however is
debatable if this sequence (which is allowed because it does not
use no_changes here) makes sense:
: hack hack hack
: get interrupted
$ git stash
: do something else on a clean slate
$ git commit
: hack hack hack
$ git add -u
$ git unstash
>> + git-diff --cached --name-only --diff-filter=A $c_tree >"$a" &&
>> + git-read-tree --reset $c_tree &&
>> + git-update-index --add --stdin <"$a" ||
>> + die "Cannot unstage modified files"
>
> Isn't there a way to avoid the temporary file here?
We could obviously do
files=$(git-diff --cached ...) &&
git-read-tree --reset $c_tree &&
echo "$files" | git-update-index --add --stdin
Oops, the last "echo" may have to be "printf '%s'" ;-)
There might be quite many files that have been added to make the
$files variable too big to be given to echo, though.
git-diff --cached ... |
(
git-read-tree --reset $c_tree &&
git-update-index --add --stdin
)
would not work, unless you copy the index into a temporary file
and have the upstream git-diff use it. But then we are using a
temporary file anyway.
>> + set x -n 10
>> + shift
>
> This is more elegantly written as "set -- -n 10", or in our context even
> "set -- -10".
That is Ok in POSIX only world, but so far we have stayed away
from using "set -- potentially-dangerous-string" in any of our
scripts. I would feel x + shift is safer and more comfortable
but probably that is largely because I am old fashioned.
^ permalink raw reply
* Re: [PATCH] contrib/hooks: add post-update hook for updating working copy
From: Junio C Hamano @ 2007-06-30 17:19 UTC (permalink / raw)
To: Sam Vilain; +Cc: git
In-Reply-To: <11831937823588-git-send-email-sam.vilain@catalyst.net.nz>
Sam Vilain <sam.vilain@catalyst.net.nz> writes:
> diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
> index 665f6dc..9f5fbc7 100644
> --- a/Documentation/git-push.txt
> +++ b/Documentation/git-push.txt
> @@ -20,7 +20,9 @@ necessary to complete the given refs.
>
> You can make interesting things happen to a repository
> every time you push into it, by setting up 'hooks' there. See
> -documentation for gitlink:git-receive-pack[1].
> +documentation for gitlink:git-receive-pack[1]. One commonly
> +requested feature, updating the working copy of the target
> +repository, must be enabled in this way.
That is more like "could be", not "must be", and it is not the
manpage's job to pass judgement on if a feature is often requested.
> diff --git a/templates/hooks--post-update b/templates/hooks--post-update
> index bcba893..b5d490c 100644
> --- a/templates/hooks--post-update
> +++ b/templates/hooks--post-update
> @@ -1,8 +1,78 @@
> #!/bin/sh
> #
> -# An example hook script to prepare a packed repository for use over
> -# dumb transports.
> +# This hook does two things:
> #
> -# To enable this hook, make this file executable by "chmod +x post-update".
> +# 1. update the "info" files that allow the list of references to be
> +# queries over dumb transports such as http
> +#
> +# 2. if this repository looks like it is a non-bare repository, and
> +# the checked-out branch is pushed to, then update the working copy.
> +# This makes "push" and "pull" symmetric operations, as in darcs and
> +# bzr.
> +
> +git-update-server-info
> +
> +export GIT_DIR=`cd $GIT_DIR; pwd`
> +[ `expr "$GIT_DIR" : '.*/\.git'` = 0 ] && exit 0
That's convoluted. If you use 'expr', probably
expr "$GIT_DIR" : '.*/\.git' >/dev/null || exit 0
but I would probably do without an extra fork, like this:
case "$GIT_DIR" in */.git) : happy ;; *) exit 0 ;; esac
Also you can exit early if $GIT_DIR/index does not exist.
> +
> +tree_in_revlog() {
revlog? Since when are we Hg?
> + ref=$1
> + tree=$2
> + found=$(
> + tail logs/$ref | while read commit rubbish
> + do
> + this_tree=`git-rev-parse commit $commit^{tree}`
> + if [ "$this_tree" = "$tree" ]
> + then
> + echo $commit
> + fi
> + done
> + )
> + [ -n "$found" ] && true
> +}
I would imagine that "$some_command && true" would always give
the same result as "$some_command" alone. I'd just write this
as:
test -n "$found"
if I were you.
> +
> +for ref
> +do
> +active=`git-symbolic-ref HEAD`
- You do not want to do this inside "for ref" loop as this is
constant expression.
- When the HEAD is detached, this will give you an error message,
and an empty string. But you do not care about detached HEAD
case anyway I would imagine.
Perhaps...
active=$(git symbolic-ref -q HEAD) || exit 0
for ref
do
...
> +if [ "$ref" = "$active" ]
> +then
> + echo "Pushing to checked out branch - updating working copy" >&2
> + success=
> + if ! (cd ..; git-diff-files) | grep -q .
> + then
Trying to see if there is any difference from the index, aka
git diff-files --quiet
?
> + # save the current index just in case
> + current_tree=`git-write-tree`
What happens if the user is in the middle of a merge?
write-tree would fail and you should error out.
> + if tree_in_revlog $ref $current_tree
> + then
Why should it behave differently depending on whether the index
matches one of the arbitrary (i.e. taken from "tail" default)
number of commits the user happened to be at in the recent past?
If the check were "does it match with the HEAD", there could be
a valid justification but this check does not make any sense to
me.
> + cd ..
> + if git-diff-index -R --name-status HEAD >&2 &&
> + git-diff-index -z --name-only --diff-filter=A HEAD | xargs -0r rm &&
> + git-reset --hard HEAD
I do not understand the first two lines at all. Are you trying
to lose working files for the paths that were added to the index
since HEAD? "git reset --hard HEAD" should take care of that
already. To test:
$ >a-new-file
$ git add a-new-file
$ git reset --hard HEAD
$ ls -l a-new-file
ls: a-new-file: No such file or directory
But more importantly, why is it justified to throw away such
files to begin with?
> + then
> + success=1
> + else
> + echo "E:unexpected error during update" >&2
> + fi
> + else
> + echo "E:uncommitted, staged changes found" >&2
> + fi
> + else
> + echo "E:unstaged changes found" >&2
> + fi
I think this part is a good demonstration why pushing into a
live branch should not attempt to update the working tree. It
sometimes happens, and it sometimes cannot (which is not your
fault at all), but the indication of what happened (or did not
happen) goes to the person who pushed the changes, not to the
person who gets confusing behaviour if the index/worktree
suddenly goes out of sync with respect to the updated HEAD.
The longer I look at this patch, the more inclined I become to
say that the only part that is worth saving is the next hunk.
> -exec git-update-server-info
> + if [ -z "$success" ]
> + then
> + (
> + echo "Non-bare repository checkout is not clean - not updating it"
> + echo "However I AM going to update the index. Any half-staged commit"
> + echo "in that checkout will be thrown away, but on the bright side"
> + echo "this is probably the least confusing thing for us to do and at"
> + echo "least we're not throwing any files somebody has changed away"
> + git-reset --mixed HEAD
> + echo
> + echo "This is the new status of the upstream working copy:"
> + git-status
> + ) >&2
> + fi
> +fi
> +done
> --
> 1.5.2.1.1131.g3b90
^ permalink raw reply
* Re: [PATCH] Add a manual page for git-stash
From: Junio C Hamano @ 2007-06-30 17:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: しらいしななこ, GIT
In-Reply-To: <Pine.LNX.4.64.0706301644190.4438@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +DESCRIPTION
> +-----------
> +Use 'git stash' when you want to record the current state of the
> +working directory and the index, but want to go back to a clean
> +working directory.
> +
> +For example, if you have to pull, but are in the middle of some
> +interesting work, not yet ready to be committed, use git-stash.
> +
> +The default operation (when called without options), is to save
> +the changes away.
> +
> +
> +OPTIONS
> +-------
> +clear::
> + Undo _all_ stashes (dangerous!).
> +
> +list [<stashname>]::
> + List all stashed states.
> +
I suspect that is not what the implementation intends to do.
"list -n 4", "list --since=1.hour" would make sense, but "list
stash@{12}" would probably not.
> +show [<stashname>]::
> + Show a combined diff of the stashed working directory, index and
> + HEAD.
Is that what it does? I had an impression that "show stash@{2}"
shows a regular diff between the base and the stashed working
tree state.
> +apply [<stashname>]::
> + Try to apply the stashed changes to the current HEAD. You need
> + a clean working directory for that, i.e. you must not have changes
> + relative to HEAD in your working directory or index.
The implementation appears to apply on a clean index without
restriction to where the HEAD is. I hinted that that behaviour
is fine in my previous message, but on the other hand haven't
convinced myself enough to say that it would not confuse end
users. Maybe insisting on not just clean index but no changes
from the HEAD would reduce confusion? I dunno.
> +<stashname>::
> + A name of a stashed state. Typically something like 'stash@{2}'
> + or 'stash@{2.days.ago}'.
Probably this should be defined in DESCRIPTION, along with the
definition of what a stash is ("records the difference between
the HEAD when the stash was created and the working tree state
in such a way that it can be applied to a different state
later").
> +DISCUSSION
> +----------
> +
> +The state is saved as three commits:
> +
> +- HEAD,
> +- a commit which contains the state of the index, which has HEAD as a
> + parent, and
> +- a commit which contains the state of the working directory (only the
> + tracked files, though), which has both HEAD and the second commit
> + as parents.
> +
> +The third commit holds the complete information of the stash, and is
> +stored as the ref 'refs/stash'.
> +
> +Since that commit does not have any reference to other stashed states,
> +the stash listing relies on the reflog of 'refs/stash'. Therefore,
> +the stashed states are garbage collected like all the other reflogs.
Nit; s/the other reflogs/the other reflog entries/
> +Author
> +------
> +Written by Johannes E. Schindelin <johannes.schindelin@gmx.de>
You wrote that ;-)?
^ 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