* 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] 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] 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: 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 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
* [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
* [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] 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
* 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] 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
* 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
* 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: 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: [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: [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: 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: How to find a revision's branch name
From: Junio C Hamano @ 2006-03-18 6:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603172202ia4b69f2he5562b826e491426@mail.gmail.com>
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.
$ git show-branch master~1 next pu
! [master~1] blame: Nicer output
! [next] Merge branch 'jc/cvsimport' into next
! [pu] Merge branch 'jc/cvsimport' into next
---
-- [next] Merge branch 'jc/cvsimport' into next
++ [next^2] cvsimport: honor -i and non -i upon subsequent
imports
-- [next^] Merge branch 'jc/fetch' into next
++ [next^^2] fetch: exit non-zero when fast-forward check
fails.
-- [next~2] Merge branch 'ew/abbrev' into next
++ [next~2^2] ls-files: add --abbrev[=<n>] option
++ [next~2^2^] ls-tree: add --abbrev[=<n>] option
++ [next^2^] blame: Fix git-blame <directory>
+++ [master~1] blame: Nicer output
$ git rev-parse --verify master~1
88a8b7955666ed8fa5924fadbb3bb58984eaa6af
Now what should this command say?
$ git branch --tell 88a8b7955666ed8fa5924fadbb3bb58984eaa6af
It is not head of any branch. Should it say master~1?
next^2~1? pu^2~1?
The closest thing is name-rev, which tries to give you the
simplest. It may or may not match what you want:
$ git name-rev 88a8b7955666ed8fa5924fadbb3bb58984eaa6af
88a8b7955666ed8fa5924fadbb3bb58984eaa6af master~1
$ git name-rev `git rev-parse --verify b14e24`
b14e2494b8a70737066f4ade4df1b5559e81b44b todo~16
However.
> 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>
It lists 70 commits at the moment.
^ permalink raw reply
* How to find a revision's branch name
From: Marco Costalba @ 2006-03-18 6:02 UTC (permalink / raw)
To: junkio; +Cc: git
In today git archive, todo branch.
$ git-rev-list -n1 --header b14e2494b8a70737066f4ade4df1b5559e81b44b
b14e2494b8a70737066f4ade4df1b5559e81b44b
tree 1baa1f8405d1fef90fe95f2477133a69adec288b
parent 8158d510c641e2354cf24a10bc3e994c7a1e3125
author Junio C Hamano <junkio@cox.net> 1137562948 -0800
committer Junio C Hamano <junkio@cox.net> 1137562948 -0800
TODO updates 2006-01-17.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Is it possible to get branch name from a revision sha?
Something like
$ git branch b14e2494b8a70737066f4ade4df1b5559e81b44b
todo
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>
So I need to get 'todo' branch name from a given revision sha's.
BTW also git blame fails (gracefully) if revision is not in HEAD:
$ git blame b14e2494b8a70737066f4ade4df1b5559e81b44b
b14e2494b8a70737066f4ade4df1b5559e81b44b not found in HEAD
Thanks
Marco
^ permalink raw reply
* Re: First dumb question to the list :)
From: Jeff King @ 2006-03-18 4:25 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30603160949l655c4f9blb1e202eaf22fbfe@mail.gmail.com>
On Thu, Mar 16, 2006 at 06:49:16PM +0100, Paolo Ciarrocchi wrote:
> performed a simple cg-clone git://URItoLinus2.6 linux2.6
> [...]
> What I want to do is to simply keep my repository aligned with Linus
> so I simply have to do:
> cd linus2.6
> cg-fetch
> [...]
> How can I confg git in order to, by default, use git instead of rsync ?
It should use the git protocol by default; cg-clone will make an
'origin' branch (cogito doesn't support .git/remotes/ yet) pointing to
the original source. Future 'cg-fetch' invocations default to the origin
branch.
Try using 'cg-branch-ls' to see what's on your origin branch.
> Now my dumb question is... since I want to build that kernel do I have
> to locally clone/copy it in order to don't modify any file on my local
> tree?
> If I don't do so, I guess git/cogito will not be happy when I run
> cg-fetch, right?
cg-fetch just pulls Linus' changes to your 'origin' head. You will then
have to cg-merge the changes into your branch. You can do both at once
with cg-update. If there are conflits, then cogito will notify you.
-Peff
^ permalink raw reply
* [PATCH] 3% tighter packs for free
From: Nicolas Pitre @ 2006-03-18 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch makes for 3.4% smaller pack with the git repository, and
a bit more than 3% smaller pack with the kernel repository.
And so with _no_ measurable CPU difference.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index aaee7be..1188b31 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -136,7 +136,8 @@ void *diff_delta(void *from_buf, unsigne
unsigned long *delta_size,
unsigned long max_size)
{
- unsigned int i, outpos, outsize, inscnt, hash_shift;
+ unsigned int i, outpos, outsize, hash_shift;
+ int inscnt;
const unsigned char *ref_data, *ref_top, *data, *top;
unsigned char *out;
struct index *entry, **hash;
@@ -222,6 +223,20 @@ void *diff_delta(void *from_buf, unsigne
unsigned char *op;
if (inscnt) {
+ while (moff && ref_data[moff-1] == data[-1]) {
+ if (msize == 0x10000)
+ break;
+ /* we can match one byte back */
+ msize++;
+ moff--;
+ data--;
+ outpos--;
+ if (--inscnt)
+ continue;
+ outpos--; /* remove count slot */
+ inscnt--; /* make it -1 */
+ break;
+ }
out[outpos - inscnt - 1] = inscnt;
inscnt = 0;
}
^ permalink raw reply related
* Subprojects: a user perspective
From: R. Steve McKown @ 2006-03-18 2:11 UTC (permalink / raw)
To: git
We are looking to migrate from CVS to a distributed VCS like git. I've read
the discussions on this list WRT subprojects and wanted to present another
user's perspective. The history of this list is active, so I apologize if my
post is redundant or unwanted. Send flames my way! ;^)
Our repository is relatively large and extensively uses the CVS vendor branch
feature to use and track software components managed by other groups, such as
the linux kernel, openssl, busybox, uclibc, etc. These are the tasks that we
perform to manage components:
1. Occasionally import new revisions of components we use into
the component's private branch (like an incoming branch).
This provides a version history of each component's "pristine
source" as used within the project over its lifetime.
2. Each component gets a subdirectory in the project branch(es).
Component versions are merged from the component's incoming
branch into this subdirectory as new components or component
revisions are incorporated into the project.
3. Local modifications, as necessary, are made to component
code within the project branch(es), not the incoming
branches which only hold pristine sources.
4. Patches of local changes made to a component, like for
submission to the upstream maintainer, are built by diffing
a project branch's component subdir with the component's
incoming branch.
I think git can do all of this if the component incoming branches have the
same path information as the project branches. In other words, if the
project places the busybox component at /src/components/busybox, then the
busybox incoming branch must place the busybox code
into /src/component/busybox.
So, in terms of adding specific support for subprojects, the only thing I see
that could be improved would be the ability to reference a sub-tree in git
operations that currently expect a tree (aka tree-ish or refspec parameters).
I liked Junio's concept of subproject linking, but only because it provided a
way to conceptually address a sub-tree.
With sub-tree addressing, a component branch could be naturally rooted, and
diffing its head against the a project branch head at the component's subdir:
git diff linux-incoming proj-branch@/src/components/linux
or merging a new linux version into the project:
git checkout linux-incoming
#suck in a new linux release from upstream
git commit -a
git tag linux-2.4.16
git checkout master
git pull . linux-2.4.16:.@/src/components/linux
All the best,
Steve
^ permalink raw reply
* [PATCH] Rewrite synopsis to clarify the two primary uses of git-checkout.
From: Jon Loeliger @ 2006-03-18 0:26 UTC (permalink / raw)
To: git
Fix a few typo/grammar problems.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-checkout.txt | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
3a8c8dc1832fcffe58cdc4894959f67d91c6a924
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 556e733..dc821bb 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -7,15 +7,18 @@ git-checkout - Checkout and switch to a
SYNOPSIS
--------
-'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]
+[verse]
+'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>]
+'git-checkout' [-m] [<branch>] <paths>...
DESCRIPTION
-----------
-When <paths> are not given, this command switches branches, by
+When <paths> are not given, this command switches branches by
updating the index and working tree to reflect the specified
branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>.
+specified, <new_branch>. Using -b will cause <new_branch> to
+be created.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
@@ -29,17 +32,17 @@ given paths before updating the working
OPTIONS
-------
-f::
- Force an re-read of everything.
+ Force a re-read of everything.
-b::
Create a new branch and start it at <branch>.
-m::
- If you have local modifications to a file that is
- different between the current branch and the branch you
- are switching to, the command refuses to switch
- branches, to preserve your modifications in context.
- With this option, a three-way merge between the current
+ If you have local modifications to one or more files that
+ are different between the current branch and the branch to
+ which you are switching, the command refuses to switch
+ branches in order to preserve your modifications in context.
+ However, with this option, a three-way merge between the current
branch, your working tree contents, and the new branch
is done, and you will be on the new branch.
+
@@ -82,7 +85,7 @@ $ git checkout -- hello.c
------------
. After working in a wrong branch, switching to the correct
-branch you would want to is done with:
+branch would be done using:
+
------------
$ git checkout mytopic
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Fix minor typo.
From: Jon Loeliger @ 2006-03-18 0:25 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-show-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
0ccfbeb321dbebc70c2203cb801079a90255b2df
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index d3b6e62..f115b45 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -141,7 +141,7 @@ it, having the following in the configur
------------
-With this,`git show-branch` without extra parameters would show
+With this, `git show-branch` without extra parameters would show
only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Clarify git-rebase example commands.
From: Jon Loeliger @ 2006-03-18 0:25 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-rebase.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
f59f6f2e8da2e6260ad9585734010b5ea1cd7c2a
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 4d5b546..b36276c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -25,7 +25,7 @@ Assume the following history exists and
/
D---E---F---G master
-From this point, the result of the following commands:
+From this point, the result of either of the following commands:
git-rebase master
git-rebase master topic
@@ -36,7 +36,7 @@ would be:
/
D---E---F---G master
-While, starting from the same point, the result of the following
+While, starting from the same point, the result of either of the following
commands:
git-rebase --onto master~1 master
@@ -58,7 +58,7 @@ OPTIONS
<upstream>::
Upstream branch to compare against.
-<head>::
+<branch>::
Working branch; defaults to HEAD.
Author
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Reference git-commit-tree for env vars.
From: Jon Loeliger @ 2006-03-18 0:25 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-commit.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
4b5717172191a526600010ddfe9a4747fa9c33d2
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 214ed23..d04b342 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -18,6 +18,10 @@ Updates the index file for given paths,
VISUAL and EDITOR environment variables to edit the commit log
message.
+Several environment variable are used during commits. They are
+documented in gitlink:git-commit-tree[1].
+
+
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
--
1.2.4.gdd7be
^ 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