* Re: Possible --remove-empty bug
From: Junio C Hamano @ 2006-03-18 6:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, Linus Torvalds
In-Reply-To: <e5bfff550603170257u21ee6583jabe5a6409cc40766@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 3/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
>>
>> However, to be honest, the only reason to ever use --remove-empty is for
>> rename detection, and Frederik's approach of doing that through the
>> library interface directly is actually a much superior option. So we might
>> as well drop the compilcation of --remove-empty entirely, unless somebody
>> has already started using it.
>
> In case of a rather recent file --remove-empty option gives a good
> speed up in history loading with git-rev-list. So qgit uses that
> option.
So you _do_ use it, and I think I still have that remove-empty
stuff held back in "next" branch. Should I unleash it?
^ permalink raw reply
* Re: [PATCH] Rewrite synopsis to clarify the two primary uses of git-checkout.
From: Junio C Hamano @ 2006-03-18 7:11 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1FKPGb-00062a-QC@jdl.com>
All 7 look good. Thanks.
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Junio C Hamano @ 2006-03-18 7:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603172205490.4889@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> if (inscnt) {
> + while (moff && ref_data[moff-1] == data[-1]) {
> + if (msize == 0x10000)
> + break;
> + /* we can match one byte back */
> ...
> + break;
> + }
> out[outpos - inscnt - 1] = inscnt;
Once you make it into a patch form, it is plainly obvious that
this is a good optimization. Since our BLK_SIZE is 16 bytes,
you are grabbing up to 15 more bytes (on average 8 more bytes or
so) for every match after a partially modified block.
Very nice. I wonder if a larger BLK_SIZE (say 32 bytes) would
give us faster packing without losing much compression if we use
this idea.
^ permalink raw reply
* Re: How to find a revision's branch name
From: Marco Costalba @ 2006-03-18 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylgz29x.fsf@assigned-by-dhcp.cox.net>
On 3/18/06, Junio C Hamano <junkio@cox.net> wrote:
> Marco Costalba <mcostalba@gmail.com> writes:
>
> > Is it possible to get branch name from a revision sha?
> > Something like
> >
> > $ git branch b14e2494b8a70737066f4ade4df1b5559e81b44b
> > todo
>
> That is in general impossible.
>
>
> > I need this to correctly annotate files not in HEAD
> > tree. Currently qgit runs git-rev-list --header --topo-order
> > --parents --remove-empty HEAD -- <path>
> >
> > to get a file history. But this fails if <path> is not found
> > in HEAD. The right command to run in our case should be:
> > git-rev-list --header --topo-order --parents --remove-empty
> > todo -- <path>
>
> ... I wonder why you care. Wouldn't this work just as well?
>
> $ git rev-list --header --topo-order --parents --remove-empty \
> --all -- <path>
>
Yessss!!!
Thanks for the fix. I missed that.
Marco
^ permalink raw reply
* Re: Possible --remove-empty bug
From: Marco Costalba @ 2006-03-18 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vbqw4z25v.fsf@assigned-by-dhcp.cox.net>
On 3/18/06, Junio C Hamano <junkio@cox.net> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> >
> > In case of a rather recent file --remove-empty option gives a good
> > speed up in history loading with git-rev-list. So qgit uses that
> > option.
>
> So you _do_ use it, and I think I still have that remove-empty
> stuff held back in "next" branch. Should I unleash it?
>
>
Yes please.
^ permalink raw reply
* Re: How to find a revision's branch name
From: Junio C Hamano @ 2006-03-18 8:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, git
In-Reply-To: <e5bfff550603172335v11ea36a8j9cca2ed2df58b45d@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
>> ... I wonder why you care. Wouldn't this work just as well?
>>
>> $ git rev-list --header --topo-order --parents --remove-empty \
>> --all -- <path>
>>
>
> Yessss!!!
I think I spoke too early. I think --remove-empty does not
prevent rev-list from traversing branches that <path> _never_
appears in their history, so if the <path> given was TODO, it
will go all the way back to the very first commit by Linus, and
the very first commit for gitk by Paul, without finding a commit
that touches that file.
One option is "--remove-empty --all" with <path> to omit heads
and tags that do _not_ have given <path>s from the set of
starting points, but then you cannot grab history of rev-tree.c
between v0.99.7 and 9dcc829 (v0.99.7 was the last tagged commit
that had rev-tree.c, but removal of the file happened 39 commits
after that), so that is not really an option.
I guess we need to live with this; git.git repository is quite
special. If you clone from it, you would get todo, html and man
branches, so it *appears* that these are part of the same
repository, but logically these branches are not part of the
project history proper.
The commits that belong to these three branches do not appear in
my private development repository. The todo branch is pushed
into git.git from a completely separate repository from my side,
and html and man branches are pushed from other separate
repositories of their own on a kernel.org machine, automatically
built after I push new stuff into the "master" branch of git.git
repository, by the post-update hook.
The only reason I have these three branches in git.git
repository is historical. I do not have write access on
kernel.org machine in /pub/scm/git itself. I can only write in
/pub/scm/git/git.git/, and I never bothered to ask the operators
to make /pub/scm/git itself writable by me; otherwise I would
have made /pub/scm/git/git-{todo,html,man}.git repositories.
^ permalink raw reply
* [PATCH] Makefile: Add TAGS and tags targets
From: Fredrik Kuivinen @ 2006-03-18 10:07 UTC (permalink / raw)
To: git; +Cc: junkio
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
Makefile | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 8a20c76..8d45378 100644
--- a/Makefile
+++ b/Makefile
@@ -553,6 +553,13 @@ $(LIB_FILE): $(LIB_OBJS)
doc:
$(MAKE) -C Documentation all
+TAGS:
+ rm -f TAGS
+ find . -name '*.[hcS]' -print | xargs etags -a
+
+tags:
+ rm -f tags
+ find . -name '*.[hcS]' -print | xargs ctags -a
### Testing rules
@@ -617,7 +624,7 @@ rpm: dist
clean:
rm -f *.o mozilla-sha1/*.o arm/*.o ppc/*.o compat/*.o $(LIB_FILE)
rm -f $(ALL_PROGRAMS) git$X
- rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h
+ rm -f *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags
rm -rf $(GIT_TARNAME)
rm -f $(GIT_TARNAME).tar.gz git-core_$(GIT_VERSION)-*.tar.gz
$(MAKE) -C Documentation/ clean
@@ -626,5 +633,5 @@ clean:
rm -f GIT-VERSION-FILE
.PHONY: all install clean strip
-.PHONY: .FORCE-GIT-VERSION-FILE
+.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags
^ permalink raw reply related
* On merging strategies, fast forward and index merge
From: Mark Wooding @ 2006-03-18 10:17 UTC (permalink / raw)
To: git
I recently read Junio's description of how to dig oneself out of a hole
using `git merge -s ours' (I'm learning to use the space...), and I've
realised there's a problem here.
The `ours' merge strategy is meant to create a merge commit whose tree
is in every way identical to that of the starting commit. But `git
merge' won't always do this, because it doesn't always invoke the
strategy program.
Consider the command `git merge -s ours MESSAGE MASTER FAILED'.
* If we've not actually messed with our MASTER since the FAILED branch
departed, then MASTER is actually an ancestor of FAILED, and `git
merge' will unhelpfully fast-forward us to the tip of the FAILED
branch. Instead of leaving the merge result like MASTER, it's made
it entirely the wrong thing!
* If both MASTER and FAILED have made changes, but to different files,
then `git merge' will try an index-level merge, find that it
succeeds, and leave us with a mixture of MASTER and FAILED files.
Which is (in this case) entirely what we didn't want.
Additionally, it occurs to me that the fast-forwarding behaviour isn't
always what I want anyway. Consider a merge of a topic branch:
`git merge MESSAGE MASTER TOPIC'
If I allow fast-forward, I lose information about where the topic
started and ended. This is a shame, particularly if I find other places
I want to apply those changes (either as a string of similar commits, or
squidged into a single one) onto other branches.
Because code speaks louder, I'll follow-up this article with a suggested
patch.
-- [mdw]
^ permalink raw reply
* [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Mark Wooding @ 2006-03-18 10:19 UTC (permalink / raw)
To: git
In-Reply-To: <slrne1nnhm.fr9.mdw@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
These options disable some of git-merge's optimizations.
--no-fast-forward
Does what it says on the tin: git-merge will always make a
commit as a result of this merge (or leave one in the pipeline,
if --no-commit was given).
--direct
Don't do anything clever: go directly to the merge strategy
programs. In particular, this forbids an attempt at in-index
merging.
We also force direct merging with the `ours' strategy, since this is
obviously what was wanted.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
Documentation/merge-options.txt | 9 ++++++++-
git-merge.sh | 28 ++++++++++++++++++++++------
git-pull.sh | 13 +++++++++++--
3 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 53cc355..5b145a1 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -6,7 +6,6 @@
not autocommit, to give the user a chance to inspect and
further tweak the merge result before committing.
-
-s <strategy>, \--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
once to specify them in the order they should be tried.
@@ -14,3 +13,11 @@
is used instead (`git-merge-recursive` when merging a single
head, `git-merge-octopus` otherwise).
+--no-ff, \--no-fast-forward::
+ Don't fast-forward, even when it looks possible. There will
+ always be a commit to do at the end of the merge.
+
+--direct::
+ Don't do anything clever: go directly to the merge strategy
+ programs. In particular, this forbids an attempt at in-index
+ merging.
diff --git a/git-merge.sh b/git-merge.sh
index cc0952a..d6a579f 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -13,6 +13,8 @@ LF='
all_strategies='recursive octopus resolve stupid ours'
default_strategies='recursive'
use_strategies=
+ff=t
+index_merge=t
if test "@@NO_PYTHON@@"; then
all_strategies='resolve octopus stupid ours'
default_strategies='resolve'
@@ -65,6 +67,12 @@ do
no_summary=t ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=t ;;
+ --no-f|--no-ff|--no-fa|--no-fas|--no-fast|--no-fast-|--no-fast-f|\
+ --no-fast-fo|--no-fast-for|--no-fast-forw|--no-fast-forwa|\
+ --no-fast-forwar|--no-fast-forward)
+ ff=f ;;
+ --d|--di|--dir|--dire|--direc|--direct)
+ ff=f index_merge=f ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -90,6 +98,10 @@ do
shift
done
+# `ours' is a funny strategy and clever merging optimizations here make
+# it not work.
+case " $use_strategies " in *" ours "*) ff=f index_merge=f ;; esac
+
test "$#" -le 2 && usage ;# we need at least two heads.
merge_msg="$1"
@@ -118,18 +130,18 @@ case "$#" in
esac
echo "$head" >"$GIT_DIR/ORIG_HEAD"
-case "$#,$common,$no_commit" in
-*,'',*)
+case "$#,$ff,$index_merge,$common,$no_commit" in
+*,*,*,'',*)
# No common ancestors found. We need a real merge.
;;
-1,"$1",*)
+1,*,*,"$1",*)
# If head can reach all the merge then we are up to date.
# but first the most common case of merging one remote
echo "Already up-to-date."
dropsave
exit 0
;;
-1,"$head",*)
+1,t,*,"$head",*)
# Again the most common case of merging one remote.
echo "Updating from $head to $1"
git-update-index --refresh 2>/dev/null
@@ -139,11 +151,11 @@ case "$#,$common,$no_commit" in
dropsave
exit 0
;;
-1,?*"$LF"?*,*)
+1,*,*,?*"$LF"?*,*)
# We are not doing octopus and not fast forward. Need a
# real merge.
;;
-1,*,)
+1,*,t,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -164,6 +176,10 @@ case "$#,$common,$no_commit" in
fi
echo "Nope."
;;
+1,*,*,*,)
+ # Only a single remote, but we've been told not to try anything
+ # clever. Skip to real merge.
+ ;;
*)
# An octopus. If we can reach all the remote we are up to date.
up_to_date=t
diff --git a/git-pull.sh b/git-pull.sh
index 17fda26..229cec7 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -8,7 +8,7 @@ USAGE='[-n | --no-summary] [--no-commit]
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
. git-sh-setup
-strategy_args= no_summary= no_commit=
+strategy_args= no_summary= no_commit= noff= direct=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -17,6 +17,12 @@ do
no_summary=-n ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
no_commit=--no-commit ;;
+ --no-f|--no-ff|--no-fa|--no-fas|--no-fast|--no-fast-|--no-fast-f|\
+ --no-fast-fo|--no-fast-for|--no-fast-forw|--no-fast-forwa|\
+ --no-fast-forwar|--no-fast-forward)
+ noff=--no-fast-forward ;;
+ --d|--di|--dir|--dire|--direc|--direct)
+ direct=--direct ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -92,4 +98,7 @@ case "$strategy_args" in
esac
merge_name=$(git-fmt-merge-msg <"$GIT_DIR/FETCH_HEAD")
-git-merge $no_summary $no_commit $strategy_args "$merge_name" HEAD $merge_head
+git-merge \
+ $no_summary $no_commit $noff $direct \
+ $strategy_args \
+ "$merge_name" HEAD $merge_head
^ permalink raw reply related
* [PATCH] ls-files: Don't require exclude files to end with a newline.
From: Alexandre Julliard @ 2006-03-18 10:27 UTC (permalink / raw)
To: git
Without this patch, the last line of an exclude file is silently
ignored if it doesn't end with a newline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
ls-files.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
9c5a78851bcf3b541364f818f6b397c29a8f4592
diff --git a/ls-files.c b/ls-files.c
index df25c8c..e42119c 100644
--- a/ls-files.c
+++ b/ls-files.c
@@ -92,11 +92,12 @@ static int add_excludes_from_file_1(cons
close(fd);
return 0;
}
- buf = xmalloc(size);
+ buf = xmalloc(size+1);
if (read(fd, buf, size) != size)
goto err;
close(fd);
+ buf[size++] = '\n';
entry = buf;
for (i = 0; i < size; i++) {
if (buf[i] == '\n') {
--
1.2.4.g5a1f-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH] Basic Zsh completion support
From: Fredrik Kuivinen @ 2006-03-18 14:53 UTC (permalink / raw)
To: git; +Cc: junkio
Based on the completion code for quilt in the Zsh distribution.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
.gitignore | 1 +
Makefile | 8 +++++++-
generate-zsh-compl.sh | 26 ++++++++++++++++++++++++++
3 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/.gitignore b/.gitignore
index b4355b9..1cf6ac0 100644
--- a/.gitignore
+++ b/.gitignore
@@ -133,3 +133,4 @@ libgit.a
*.py[co]
config.mak
git-blame
+_git
diff --git a/Makefile b/Makefile
index 8a20c76..85c5e2d 100644
--- a/Makefile
+++ b/Makefile
@@ -96,6 +96,7 @@ bindir = $(prefix)/bin
gitexecdir = $(bindir)
template_dir = $(prefix)/share/git-core/templates/
GIT_PYTHON_DIR = $(prefix)/share/git-core/python
+ZSH_COMPL_DIR = $(prefix)/share/zsh/site-functions
# DESTDIR=
CC = gcc
@@ -438,13 +439,14 @@ SHELL_PATH_SQ = $(subst ','\'',$(SHELL_P
PERL_PATH_SQ = $(subst ','\'',$(PERL_PATH))
PYTHON_PATH_SQ = $(subst ','\'',$(PYTHON_PATH))
GIT_PYTHON_DIR_SQ = $(subst ','\'',$(GIT_PYTHON_DIR))
+ZSH_COMPL_DIR_SQ = $(subst ','\'',$(ZSH_COMPL_DIR))
ALL_CFLAGS += -DSHA1_HEADER='$(SHA1_HEADER_SQ)' $(COMPAT_CFLAGS)
LIB_OBJS += $(COMPAT_OBJS)
export prefix TAR INSTALL DESTDIR SHELL_PATH template_dir
### Build rules
-all: $(ALL_PROGRAMS) git$X gitk
+all: $(ALL_PROGRAMS) git$X gitk _git
all:
$(MAKE) -C templates
@@ -553,6 +555,8 @@ $(LIB_FILE): $(LIB_OBJS)
doc:
$(MAKE) -C Documentation all
+_git: generate-zsh-compl.sh
+ ./generate-zsh-compl.sh version help $(ALL_PROGRAMS) > _git
### Testing rules
@@ -586,6 +590,8 @@ install: all
$(MAKE) -C templates install
$(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
$(INSTALL) $(PYMODULES) '$(DESTDIR_SQ)$(GIT_PYTHON_DIR_SQ)'
+ $(INSTALL) -d -m755 $(ZSH_COMPL_DIR)
+ $(INSTALL) -m644 _git '$(DESTDIR_SQ)$(ZSH_COMPL_DIR_SQ)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/generate-zsh-compl.sh b/generate-zsh-compl.sh
new file mode 100755
index 0000000..f8c80de
--- /dev/null
+++ b/generate-zsh-compl.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+cmds=$(echo "$@" | sed s/git-//g | sed "s/\\.[^ ]*//g")
+
+cat <<EOF
+#compdef git
+
+# Automatically generated by $0
+
+local _git_subcommands expl curcontext="$curcontext"
+
+_arguments \
+ '--version' \
+ '--exec-path=:Git exec path:_path_files' \
+ '--help' \
+ '*::git command:->subcmd' && return 0
+
+ _git_subcommands=($cmds)
+
+if (( CURRENT == 1 )); then
+ _describe -t subcommand 'subcommand' _git_subcommands
+else
+ # this part should be tailored for subcmds
+ _files
+fi
+EOF
^ permalink raw reply related
* Re: [PATCH] Basic Zsh completion support
From: Nikolai Weibull @ 2006-03-18 15:25 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git, junkio
In-Reply-To: <20060318145347.15128.85902.stgit@c165>
On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
>
> Based on the completion code for quilt in the Zsh distribution.
Actually, there's an almost-complete implementation in 4.3 already.
Written by me nonetheless. You can take a look and make suggestions
if you like :-). I have an updated version to deal with post
1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
nikolai
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Bertrand Jacquin @ 2006-03-18 15:52 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <dbfc82860603180725w2eb3057ey17fa8d9dc746127@mail.gmail.com>
On 3/18/06, Nikolai Weibull <now@bitwi.se> wrote:
> On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> >
> > Based on the completion code for quilt in the Zsh distribution.
>
> Actually, there's an almost-complete implementation in 4.3 already.
> Written by me nonetheless. You can take a look and make suggestions
> if you like :-). I have an updated version to deal with post
> 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
Any plan do to this for cogito ?
>
> nikolai
> -
> 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
>
--
Beber
#e.fr@freenode
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Nikolai Weibull @ 2006-03-18 16:14 UTC (permalink / raw)
To: Bertrand Jacquin; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <4fb292fa0603180752r731c628eoa2b96fcd6ef43e0f@mail.gmail.com>
On 3/18/06, Bertrand Jacquin <beber.mailing@gmail.com> wrote:
> On 3/18/06, Nikolai Weibull <now@bitwi.se> wrote:
> > On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> > >
> > > Based on the completion code for quilt in the Zsh distribution.
> >
> > Actually, there's an almost-complete implementation in 4.3 already.
> > Written by me nonetheless. You can take a look and make suggestions
> > if you like :-). I have an updated version to deal with post
> > 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
>
> Any plan do to this for cogito ?
Sure, and stgit as well, but I haven't gotten around to it. The idea
was to reuse as much as possible of the stuff that the three have in
common (like tags, references, and so on), but as I haven't used
either of the two (cogito and stgit) I haven't had a compelling reason
to sit down and do it.
nikolai
^ permalink raw reply
* Re: [PATCH] Basic Zsh completion support
From: Fredrik Kuivinen @ 2006-03-18 16:23 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: Fredrik Kuivinen, git, junkio
In-Reply-To: <dbfc82860603180725w2eb3057ey17fa8d9dc746127@mail.gmail.com>
On Sat, Mar 18, 2006 at 04:25:04PM +0100, Nikolai Weibull wrote:
> On 3/18/06, Fredrik Kuivinen <freku045@student.liu.se> wrote:
> >
> > Based on the completion code for quilt in the Zsh distribution.
>
> Actually, there's an almost-complete implementation in 4.3 already.
> Written by me nonetheless. You can take a look and make suggestions
> if you like :-). I have an updated version to deal with post
> 1.0-changes locally that I'm going to put in Zsh's CVS soon enough.
>
Oh, I didn't know about that.
<updates zsh>
Very nice! Much better than my crude cut-and-paste work.
Junio: Please don't apply the patch.
- Fredrik
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Nicolas Pitre @ 2006-03-18 18:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtesxloi.fsf@assigned-by-dhcp.cox.net>
On Fri, 17 Mar 2006, Junio C Hamano wrote:
> Once you make it into a patch form, it is plainly obvious that
> this is a good optimization. Since our BLK_SIZE is 16 bytes,
> you are grabbing up to 15 more bytes (on average 8 more bytes or
> so) for every match after a partially modified block.
>
> Very nice. I wonder if a larger BLK_SIZE (say 32 bytes) would
> give us faster packing without losing much compression if we use
> this idea.
Tried that long ago. As BLK_SIZE is increased the adler32 cost, which
has to be computed for every offset in the target buffer, increases
accordingly. So you end up with both worse compression and more CPU
usage.
Nicolas
^ permalink raw reply
* Re: [PATCH] 3% tighter packs for free
From: Junio C Hamano @ 2006-03-18 19:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603181315060.4889@localhost.localdomain>
Nicolas Pitre <nico@cam.org> writes:
> Tried that long ago. As BLK_SIZE is increased the adler32 cost, which
> has to be computed for every offset in the target buffer, increases
> accordingly. So you end up with both worse compression and more CPU
> usage.
Ah, I was not paying enough attention. I did not realize
destination scanning was done for every byte.
^ permalink raw reply
* Re: [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Junio C Hamano @ 2006-03-18 21:59 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060318101941.8941.52615.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> These options disable some of git-merge's optimizations.
While there is no question about the part of the proposed change
to bypass "trivial merge", I do not necessarily agree with
"skipping fast forward" part.
It is a problem that "ours" strategy cannot be used as a way to
recover from the "accidentally rewound head" situation, because
it is prevented from running under certain conditions as you
described. But that does not necessarily mean we should make
"ours" to work in these situations.
You accidentally discarded B while somebody picked it up:
o---o
/ \
---o---o---A---o---o---B
^your head
Now you would want to recover. With your patch, it would create
this:
o---o
/ \
---o---o---A---o---o---B
\ \
------------M
^your updated head,
having the same tree as A
But recording A as a parent of M is not necessary. I think what
we want to have as the result is this instead:
o---o
/ \
---o---o---A---o---o---B---M
^your updated head,
having the same tree as A
This is something you cannot do within the current git-merge
framework; it is set up to either just fast forward or make a
multi-parent commit. You would want have a "revert to this
state" [*1*], something like this (assuming you have rewound to
A and currently your index matches A):
$ git reset --soft B
$ git commit -m 'Discard A..B and revert to A'
I did "ours" primarily as a demonstration of a funky thing
people could do with the consolidated driver "git-merge". I did
not have a useful use-case in mind back then, but it turned out
to be the ideal way to recover from "accidentally rewound head"
situation, except that making a merge commit between A and B is
not always the way to recover from it. If we wanted to, we
could have a special purpose command that does "git merge -s
ours" if there will be a new commit, otherwise the above two
commands sequence if it will be a fast forward, but the
"recovering from accidentally rewound head" _is_ really a
special purpose, so I do not know if it is worth it.
In your cover letter, you talked about using --no-fast-forward
to collapse your sole topic branch into your master branch. I
do not think smudging the development history with extra merge
commits for that is justfied either. There is no reason for you
to discard your topic branch heads after you merged them into
master. If they get in the way of your normal workflow, you can
stash them away as tags that you do not usually see in "git
branch" output [*2*].
Also I am already unhappy that git-merge knows about the
specifics of strategies [*3*], e.g. it knows octopus is
currently the only strategy that can do more than two heads.
Your patch gives more strategy specific knowledge to it, but I
do not know how to avoid it.
[Footnotes]
*1* As opposed to "git revert X" which means "revert the effect
of commit X", you would want "revert to the state X".
*2* I keep some of my old topic branch heads under
.git/tags/attic/.
*3* Another thing I am unhappy about is the list of available
strategies. I initially wanted to allow users to write their
own merge strategies and have them on their PATH (not even
necessarily in GIT_EXEC_PATH directory), so that you can do a
git-merge-mdw secretly, keep it in ~mdw/bin and cook it for a
while using yourself as a guinea pig, and then share that with
the community later, _without_ touching git-merge.
^ permalink raw reply
* Re: [PATCH] git-merge: New options `--no-fast-forward' and `--direct'.
From: Junio C Hamano @ 2006-03-18 22:53 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <7vmzfns9c6.fsf@assigned-by-dhcp.cox.net>
>From nobody Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sat Mar 18 14:50:53 2006 -0800
Subject: [PATCH] git-merge knows some strategies want to skip trivial merges
Most notably "ours". Also this makes sure we do not record
duplicated parents on the parent list of the resulting commit.
This is based on Mark Wooding's work, but does not change the UI
nor introduce new flags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* How about this instead? It looks larger than it really is
because strategy-defaulting code needed to get moved around.
git-merge.sh | 67 +++++++++++++++++++++++++++++++++++-----------------------
1 files changed, 40 insertions(+), 27 deletions(-)
313093ea6d29bbce5977556645eb5946dbfb211e
diff --git a/git-merge.sh b/git-merge.sh
index cc0952a..78ab422 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -11,11 +11,15 @@ LF='
'
all_strategies='recursive octopus resolve stupid ours'
-default_strategies='recursive'
+default_twohead_strategies='recursive'
+default_octopus_strategies='octopus'
+no_trivial_merge_strategies='ours'
use_strategies=
+
+index_merge=t
if test "@@NO_PYTHON@@"; then
all_strategies='resolve octopus stupid ours'
- default_strategies='resolve'
+ default_twohead_strategies='resolve'
fi
dropsave() {
@@ -90,8 +94,6 @@ do
shift
done
-test "$#" -le 2 && usage ;# we need at least two heads.
-
merge_msg="$1"
shift
head_arg="$1"
@@ -99,6 +101,8 @@ head=$(git-rev-parse --verify "$1"^0) ||
shift
# All the rest are remote heads
+test "$#" = 0 && usage ;# we need at least one remote head.
+
remoteheads=
for remote
do
@@ -108,6 +112,27 @@ do
done
set x $remoteheads ; shift
+case "$use_strategies" in
+'')
+ case "$#" in
+ 1)
+ use_strategies="$default_twohead_strategies" ;;
+ *)
+ use_strategies="$default_octopus_strategies" ;;
+ esac
+ ;;
+esac
+
+for s in $use_strategies
+do
+ case " $s " in
+ *" $no_trivial_merge_strategies "*)
+ index_merge=f
+ break
+ ;;
+ esac
+done
+
case "$#" in
1)
common=$(git-merge-base --all $head "$@")
@@ -118,18 +143,21 @@ case "$#" in
esac
echo "$head" >"$GIT_DIR/ORIG_HEAD"
-case "$#,$common,$no_commit" in
-*,'',*)
+case "$index_merge,$#,$common,$no_commit" in
+f,*)
+ # We've been told not to try anything clever. Skip to real merge.
+ ;;
+?,*,'',*)
# No common ancestors found. We need a real merge.
;;
-1,"$1",*)
+?,1,"$1",*)
# If head can reach all the merge then we are up to date.
- # but first the most common case of merging one remote
+ # but first the most common case of merging one remote.
echo "Already up-to-date."
dropsave
exit 0
;;
-1,"$head",*)
+?,1,"$head",*)
# Again the most common case of merging one remote.
echo "Updating from $head to $1"
git-update-index --refresh 2>/dev/null
@@ -139,11 +167,11 @@ case "$#,$common,$no_commit" in
dropsave
exit 0
;;
-1,?*"$LF"?*,*)
+?,1,?*"$LF"?*,*)
# We are not doing octopus and not fast forward. Need a
# real merge.
;;
-1,*,)
+?,1,*,)
# We are not doing octopus, not fast forward, and have only
# one common. See if it is really trivial.
git var GIT_COMMITTER_IDENT >/dev/null || exit
@@ -188,17 +216,6 @@ esac
# We are going to make a new commit.
git var GIT_COMMITTER_IDENT >/dev/null || exit
-case "$use_strategies" in
-'')
- case "$#" in
- 1)
- use_strategies="$default_strategies" ;;
- *)
- use_strategies=octopus ;;
- esac
- ;;
-esac
-
# At this point, we need a real merge. No matter what strategy
# we use, it would operate on the index, possibly affecting the
# working tree, and when resolved cleanly, have the desired tree
@@ -270,11 +287,7 @@ done
# auto resolved the merge cleanly.
if test '' != "$result_tree"
then
- parents="-p $head"
- for remote
- do
- parents="$parents -p $remote"
- done
+ parents=$(git-show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree $parents) || exit
finish "$result_commit" "Merge $result_commit, made by $wt_strategy."
dropsave
--
1.2.4.g2fc2
^ permalink raw reply related
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-18 23:21 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86bqw51z5q.fsf@blue.stonehenge.com>
I tested the version in today's "next" branch, and it fixes the
problem for me in my tests that use my day-job CVS repository as
a guinea pig.
In case you are not brave enough to switch to "next" wholesale,
but are kind enough to try out the relevant cvsimport change for
us, here is a patch that applies on top of "master". It is a
roll-up of two commits on my jc/cvsimport branch.
-- >8 --
cvsimport: honor -i and non -i upon subsequent imports
Documentation says -i is "import only", so without it,
subsequent import should update the current branch and working
tree files in a sensible way.
"A sensible way" defined by this commit is "act as if it is a
git pull from foreign repository which happens to be CVS not
git". So:
- If importing into the current branch (note that cvsimport
requires the tracking branch is pristine -- you checked out
the tracking branch but it is your responsibility not to make
your own commits there), fast forward the branch head and
match the index and working tree using two-way merge, just
like "git pull" does.
- If importing into a separate tracking branch, update that
branch head, and merge it into your current branch, again,
just like "git pull" does.
Initial round of the updated code read the tip of the current
branch before and after the import runs, but forgot to chomp
what we read from the command. The read-tree command did not
them with the trailing LF. This has been fixed.
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 02d1928..3728294 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -453,6 +453,7 @@ chdir($git_tree);
my $last_branch = "";
my $orig_branch = "";
my %branch_date;
+my $tip_at_start = undef;
my $git_dir = $ENV{"GIT_DIR"} || ".git";
$git_dir = getwd()."/".$git_dir unless $git_dir =~ m#^/#;
@@ -487,6 +488,7 @@ unless(-d $git_dir) {
$last_branch = "master";
}
$orig_branch = $last_branch;
+ $tip_at_start = `git-rev-parse --verify HEAD`;
# populate index
system('git-read-tree', $last_branch);
@@ -873,7 +875,22 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if($orig_branch) {
- print "DONE; you may need to merge manually.\n" if $opt_v;
+ print "DONE.\n" if $opt_v;
+ if ($opt_i) {
+ exit 0;
+ }
+ my $tip_at_end = `git-rev-parse --verify HEAD`;
+ if ($tip_at_start ne $tip_at_end) {
+ for ($tip_at_start, $tip_at_end) { chomp; }
+ print "Fetched into the current branch.\n" if $opt_v;
+ system(qw(git-read-tree -u -m),
+ $tip_at_start, $tip_at_end);
+ die "Fast-forward update failed: $?\n" if $?;
+ }
+ else {
+ system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+ die "Could not merge $opt_o into the current branch.\n" if $?;
+ }
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
^ permalink raw reply related
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Fredrik Kuivinen @ 2006-03-19 0:32 UTC (permalink / raw)
To: junkio; +Cc: git, Jon Loeliger
In-Reply-To: <E1FEyx7-0007vo-Je@jdl.com>
On Thu, Mar 02, 2006 at 07:19:29PM -0600, Jon Loeliger wrote:
>
> Signed-off-by: Jon Loeliger <jdl@jdl.com>
>
> ---
>
> Documentation/technical/pack-heuristics.txt | 466 +++++++++++++++++++++++++++
> 1 files changed, 466 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/technical/pack-heuristics.txt
>
> 0cbbcac437be6f8a0249f6cf83b90a6fe9d2362e
> diff --git a/Documentation/technical/pack-heuristics.txt b/Documentation/technical/pack-heuristics.txt
> new file mode 100644
> index 0000000..eaab3ee
> --- /dev/null
> +++ b/Documentation/technical/pack-heuristics.txt
> @@ -0,0 +1,466 @@
> + Concerning Git's Packing Heuristics
> + ===================================
> +
[nice description of Git's packing heuristics]
Junio, are there any specific reasons why this hasn't been applied
yet?
- Fredrik
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Junio C Hamano @ 2006-03-19 2:46 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: junkio, git, Jon Loeliger
In-Reply-To: <20060319003255.GA17124@c165.ib.student.liu.se>
Fredrik Kuivinen <freku045@student.liu.se> writes:
> [nice description of Git's packing heuristics]
>
> Junio, are there any specific reasons why this hasn't been applied
> yet?
Funny. I was just re-reading it last night.
It _is_ amusing, but I am not sure if it should go to
technical/. If properly digested and reorganized, I suspect
that the document would become 1/3 of its current length.
^ permalink raw reply
* Re: [PATCH] Added Packing Heursitics IRC writeup.
From: Jon Loeliger @ 2006-03-19 3:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vr74zqhhi.fsf@assigned-by-dhcp.cox.net>
So, like, the other day Junio C Hamano mumbled:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
>
> > [nice description of Git's packing heuristics]
> >
> > Junio, are there any specific reasons why this hasn't been applied
> > yet?
>
> Funny. I was just re-reading it last night.
>
> It _is_ amusing, but I am not sure if it should go to
> technical/.
You know, I don't know what to do with it either. :-)
I have half a notion to submit it to the OLS call for
"Linux Essay Contest" just to see what happens....
> If properly digested and reorganized, I suspect
> that the document would become 1/3 of its current length.
I suppose I could do a round of that, if you would like. :-)
I should either drink more or less, I can't tell which...
jdl
^ permalink raw reply
* [PATCH 1/3] git.el: More robust handling of subprocess errors when returning strings.
From: Alexandre Julliard @ 2006-03-19 9:05 UTC (permalink / raw)
To: git
Make sure that functions that call a git process and return a string
always return nil when the subprocess failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 29 +++++++++++++----------------
1 files changed, 13 insertions(+), 16 deletions(-)
66a8d3c3e63a2d4178c9917e0c172bdc2cbec3bb
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 5135e36..cf650da 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -148,6 +148,12 @@ The default is to fall back to `add-log-
(append (git-get-env-strings env) (list "git") args))
(apply #'call-process "git" nil buffer nil args)))
+(defun git-call-process-env-string (env &rest args)
+ "Wrapper for call-process that sets environment strings, and returns the process output as a string."
+ (with-temp-buffer
+ (and (eq 0 (apply #' git-call-process-env t env args))
+ (buffer-string))))
+
(defun git-run-process-region (buffer start end program args)
"Run a git process with a buffer region as input."
(let ((output-buffer (current-buffer))
@@ -189,8 +195,9 @@ The default is to fall back to `add-log-
(defun git-get-string-sha1 (string)
"Read a SHA1 from the specified string."
- (let ((pos (string-match "[0-9a-f]\\{40\\}" string)))
- (and pos (substring string pos (match-end 0)))))
+ (and string
+ (string-match "[0-9a-f]\\{40\\}" string)
+ (match-string 0 string)))
(defun git-get-committer-name ()
"Return the name to use as GIT_COMMITTER_NAME."
@@ -259,18 +266,12 @@ The default is to fall back to `add-log-
(defun git-rev-parse (rev)
"Parse a revision name and return its SHA1."
(git-get-string-sha1
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t nil "rev-parse" rev)))))
+ (git-call-process-env-string nil "rev-parse" rev)))
(defun git-symbolic-ref (ref)
"Wrapper for the git-symbolic-ref command."
- (car
- (split-string
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t nil "symbolic-ref" ref)))
- "\n")))
+ (let ((str (git-call-process-env-string nil "symbolic-ref" ref)))
+ (and str (car (split-string str "\n")))))
(defun git-update-ref (ref val &optional oldval)
"Update a reference by calling git-update-ref."
@@ -285,11 +286,7 @@ The default is to fall back to `add-log-
(defun git-write-tree (&optional index-file)
"Call git-write-tree and return the resulting tree SHA1 as a string."
(git-get-string-sha1
- (with-output-to-string
- (with-current-buffer standard-output
- (git-call-process-env t
- (if index-file `(("GIT_INDEX_FILE" . ,index-file)) nil)
- "write-tree")))))
+ (git-call-process-env-string (and index-file `(("GIT_INDEX_FILE" . ,index-file))) "write-tree")))
(defun git-commit-tree (buffer tree head)
"Call git-commit-tree with buffer as input and return the resulting commit SHA1."
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* [PATCH 2/3] git.el: Get the default user name and email from the repository config.
From: Alexandre Julliard @ 2006-03-19 9:05 UTC (permalink / raw)
To: git
If user name or email are not set explicitly, get them from the
user.name and user.email configuration values before falling back to
the Emacs defaults.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
contrib/emacs/git.el | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
ac4b54cc4019abdb92cd0fbbf7c644976227fea0
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index cf650da..5496a1b 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -59,14 +59,14 @@
(defcustom git-committer-name nil
"User name to use for commits.
-The default is to fall back to `add-log-full-name' and then `user-full-name'."
+The default is to fall back to the repository config, then to `add-log-full-name' and then to `user-full-name'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Name")))
(defcustom git-committer-email nil
"Email address to use for commits.
-The default is to fall back to `add-log-mailing-address' and then `user-mail-address'."
+The default is to fall back to the git repository config, then to `add-log-mailing-address' and then to `user-mail-address'."
:group 'git
:type '(choice (const :tag "Default" nil)
(string :tag "Email")))
@@ -203,6 +203,7 @@ The default is to fall back to `add-log-
"Return the name to use as GIT_COMMITTER_NAME."
; copied from log-edit
(or git-committer-name
+ (git-repo-config "user.name")
(and (boundp 'add-log-full-name) add-log-full-name)
(and (fboundp 'user-full-name) (user-full-name))
(and (boundp 'user-full-name) user-full-name)))
@@ -211,6 +212,7 @@ The default is to fall back to `add-log-
"Return the email address to use as GIT_COMMITTER_EMAIL."
; copied from log-edit
(or git-committer-email
+ (git-repo-config "user.email")
(and (boundp 'add-log-mailing-address) add-log-mailing-address)
(and (fboundp 'user-mail-address) (user-mail-address))
(and (boundp 'user-mail-address) user-mail-address)))
@@ -268,6 +270,11 @@ The default is to fall back to `add-log-
(git-get-string-sha1
(git-call-process-env-string nil "rev-parse" rev)))
+(defun git-repo-config (key)
+ "Retrieve the value associated to KEY in the git repository config file."
+ (let ((str (git-call-process-env-string nil "repo-config" key)))
+ (and str (car (split-string str "\n")))))
+
(defun git-symbolic-ref (ref)
"Wrapper for the git-symbolic-ref command."
(let ((str (git-call-process-env-string nil "symbolic-ref" ref)))
--
1.2.4.g9c5a7
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
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