* [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
* [PATCH] Document the default source of template files.
From: Jon Loeliger @ 2006-03-18 0:24 UTC (permalink / raw)
To: git
Also explain a bit more about how the template option works.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-init-db.txt | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
d86b69902d855748ff636d2debbf9524c6f09c04
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index ea4d849..aeb1115 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -14,7 +14,8 @@ SYNOPSIS
OPTIONS
-------
--template=<template_directory>::
- Provide the directory in from which templates will be used.
+ Provide the directory from which templates will be used.
+ The default template directory is `/usr/share/git-core/templates`.
--shared::
Specify that the git repository is to be shared amongst several users.
@@ -22,9 +23,17 @@ OPTIONS
DESCRIPTION
-----------
-This simply creates an empty git repository - basically a `.git` directory
-and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
-and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
+This command creates an empty git repository - basically a `.git` directory
+with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
+templated files.
+An initial `HEAD` file that references the HEAD of the master branch
+is also created.
+
+If `--template=<template_directory>` is specified, `<template_directory>`
+is used as the source of the template files rather than the default.
+The template files include some directory structure, some suggested
+"exclude patterns", and copies of non-executing "hook" files. The
+suggested patterns and hook files are all modifiable and extensible.
If the `$GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
@@ -38,7 +47,6 @@ repository. When specifying `--shared` t
is set to 'true' so that directories under `$GIT_DIR` are made group writable
(and g+sx, since the git group may be not the primary group of all users).
-
Running `git-init-db` in an existing repository is safe. It will not overwrite
things that are already there. The primary reason for rerunning `git-init-db`
is to pick up newly added templates.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Call out the two different uses of git-branch and fix a typo.
From: Jon Loeliger @ 2006-03-18 0:24 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-branch.txt | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
1a4336ee2a807d4ccc23d97c7b5c2dce2d4ef116
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4cd0cb9..71ecd85 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -7,16 +7,20 @@ git-branch - Create a new branch, or rem
SYNOPSIS
--------
-'git-branch' [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]]
+[verse]
+'git-branch' [[-f] <branchname> [<start-point>]]
+'git-branch' (-d | -D) <branchname>
DESCRIPTION
-----------
If no argument is provided, show available branches and mark current
branch with star. Otherwise, create a new branch of name <branchname>.
-
If a starting point is also specified, that will be where the branch is
created, otherwise it will be created at the current HEAD.
+With a `-d` or `-D` option, `<branchname>` will be deleted.
+
+
OPTIONS
-------
-d::
@@ -39,7 +43,7 @@ OPTIONS
Examples
~~~~~~~~
-Start development off of a know tag::
+Start development off of a known tag::
+
------------
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Add git-show reference
From: Jon Loeliger @ 2006-03-18 0:21 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
e202e207b8da1ac771a98f039cdfac70ad9ea0d2
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 8610d36..de3934d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -329,6 +329,9 @@ gitlink:git-revert[1]::
gitlink:git-shortlog[1]::
Summarizes 'git log' output.
+gitlink:git-show[1]::
+ Show one commit log and its diff.
+
gitlink:git-show-branch[1]::
Show branches and their commits.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH 2/2] blame: Fix git-blame <directory>
From: Fredrik Kuivinen @ 2006-03-17 21:49 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20060317214928.23075.76032.stgit@c165>
Before this patch git-blame <directory> gave non-sensible output. (It
assigned blame to some random file in <directory>) Abort with an error
message instead.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/blame.c b/blame.c
index 8af4b54..9c97aec 100644
--- a/blame.c
+++ b/blame.c
@@ -180,11 +180,13 @@ static int get_blob_sha1_internal(unsign
unsigned mode, int stage);
static unsigned char blob_sha1[20];
+static const char* blame_file;
static int get_blob_sha1(struct tree *t, const char *pathname,
unsigned char *sha1)
{
int i;
const char *pathspec[2];
+ blame_file = pathname;
pathspec[0] = pathname;
pathspec[1] = NULL;
memset(blob_sha1, 0, sizeof(blob_sha1));
@@ -209,6 +211,10 @@ static int get_blob_sha1_internal(unsign
if (S_ISDIR(mode))
return READ_TREE_RECURSIVE;
+ if (strncmp(blame_file, base, baselen) ||
+ strcmp(blame_file + baselen, pathname))
+ return -1;
+
memcpy(blob_sha1, sha1, 20);
return -1;
}
^ permalink raw reply related
* [PATCH 1/2] blame: Nicer output
From: Fredrik Kuivinen @ 2006-03-17 21:49 UTC (permalink / raw)
To: git; +Cc: junkio
As pointed out by Junio, it may be dangerous to cut off people's names
after 15 bytes. If the name is encoded in an encoding which uses more
than one byte per code point we may end up with outputting garbage.
Instead of trying to do something smart, just output the entire name.
We don't gain much screen space by chopping it off anyway.
Furthermore, only output the file name if we actually found any
renames.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/blame.c b/blame.c
index 1fb5070..8af4b54 100644
--- a/blame.c
+++ b/blame.c
@@ -742,6 +742,8 @@ int main(int argc, const char **argv)
struct commit_info ci;
const char *buf;
int max_digits;
+ size_t longest_file, longest_author;
+ int found_rename;
const char* prefix = setup_git_directory();
@@ -818,6 +820,25 @@ int main(int argc, const char **argv)
for (max_digits = 1, i = 10; i <= num_blame_lines + 1; max_digits++)
i *= 10;
+ longest_file = 0;
+ longest_author = 0;
+ found_rename = 0;
+ for (i = 0; i < num_blame_lines; i++) {
+ struct commit *c = blame_lines[i];
+ struct util_info* u;
+ if (!c)
+ c = initial;
+ u = c->object.util;
+
+ if (!found_rename && strcmp(filename, u->pathname))
+ found_rename = 1;
+ if (longest_file < strlen(u->pathname))
+ longest_file = strlen(u->pathname);
+ get_commit_info(c, &ci);
+ if (longest_author < strlen(ci.author))
+ longest_author = strlen(ci.author);
+ }
+
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
struct util_info* u;
@@ -828,14 +849,18 @@ int main(int argc, const char **argv)
u = c->object.util;
get_commit_info(c, &ci);
fwrite(sha1_to_hex(c->object.sha1), sha1_len, 1, stdout);
- if(compability)
+ if(compability) {
printf("\t(%10s\t%10s\t%d)", ci.author,
format_time(ci.author_time, ci.author_tz), i+1);
- else
- printf(" %s (%-15.15s %10s %*d) ", u->pathname,
- ci.author, format_time(ci.author_time,
- ci.author_tz),
+ } else {
+ if (found_rename)
+ printf(" %-*.*s", longest_file, longest_file,
+ u->pathname);
+ printf(" (%-*.*s %10s %*d) ",
+ longest_author, longest_author, ci.author,
+ format_time(ci.author_time, ci.author_tz),
max_digits, i+1);
+ }
if(i == num_blame_lines - 1) {
fwrite(buf, blame_len - (buf - blame_contents),
^ permalink raw reply related
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-17 21:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, paul, Git List
In-Reply-To: <1142623141.17536.225.camel@cashmere.sps.mot.com>
I'm in sort of shallow waters, hoping that Junio or Linus will come
along and pull me off the shores in case I mis-step and say something
stupid that would have made an amusing pictograph had it been done right
by a cartoonist.
Jon Loeliger wrote:
> On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:
>
>
>>You used to have something like this:
>>
>>
>> o---o---o---A
>> / ^ your HEAD used to point at here
>> ---o---o---o
>>
>>and you forgot other people already have the commit chain up to
>>commit A. But you rewound and did cleanups:
>>
>> o---o---o---A
>> /
>> ---o---o---o---o---o---B
>> ^ your HEAD now points at here
>>
>>People who track your HEAD have A and your updated head B does
>>not fast forward. Oops.
>>
>>The recovery consists of two steps. The first step is more
>>important. To find what commits you lost that others already
>>may have. You may be lucky and remember A's commit object name,
>>but when I did that I had to ask around on the list X-<.
>>
>>The second step is a single command:
>>
>> $ git merge -s ours 'Graft the lost side branch back in' \
>> HEAD A
>>
>>where A is the object name of that commit. On your current
>>branch, this creates a merge commit between A and B (your
>>current HEAD), taking the tree object from B.
>>
>> o---o---o---A
>> / \
>> ---o---o---o---o---o---B---M
>
>
> Junio,
>
> Can you explain a bit more why the "ours" strategy
> comes into play here? I _think_ I understand, but
> I'd like to hear a bit more explanation, please.
> How is this different from just merging in A directly?
>
"Ours" is an algorithm you can invent yourself and pass as the defautl
merge strategy (useful if you know you'll always keep upstream as-is or
some such).
>
>>You want to keep the contents of the cleaned-up HEAD, so that is
>>why you are taking the tree from B.
>
>
> And the "ours" strategy effectively says, "Favor the B
> side of things when pulling in the A parts", right?
>
Yes, and/or no. "Ours"' is still whatever you want it to be. Perhaps we
should add some new strategies, like "favour-current" and "favour-new".
>
>> With this commit M, you are
>>telling the outside world that it is OK if they start from a
>>commit on the now-recovered side branch.
>
>
> This is mystical to me. How is the "A" (ie, side branch)
> now in a "recovered" state?
>
Because the commits pullers already have are now inside the respository
history, as seen by average pullers (again). The merge between "master"
(or some such) and "new-devel" (or some such) happen to coincide, which
means they share a mutual merge-base, which means they're both part of
the same chain of developemnt. If you intend to disimiss most of the
changes between (fork-point) and (point-of-new-weird-rebase) this might
not be the best solution, but...
Sorry, but to me this is friaday night and currently I can't logically
differ between a bluewhale and a kangaroo [*1]
/exon
[1]
Sadly, this has been empirically proven. [*2]
[2]
At some other time. I'm no *that* drunk right now.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-reset and clones
From: Jon Loeliger @ 2006-03-17 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paul, Git List
In-Reply-To: <7vslpgztzc.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-03-17 at 14:39, Junio C Hamano wrote:
> > And the "ours" strategy effectively says, "Favor the B
> > side of things when pulling in the A parts", right?
>
> Yes, it is stronger than that. "ours" says: "the tree from our
> head commit B *is* the resulting tree -- whatever we are merging
> into us does not matter".
Aha! This all makes much more sense now suddenly.
Thank you.
>
> o---o---o---A---N
> / /
> ---o---o---o---o---o---B---'
>
> Because the forked track leading to B was either to fix mistakes
> or clean things up the upstream originally did in the track
> leading to A, the commits on the tracks leading to A and B from
> their fork point are almost guaranteed to have conflicting
> changes, and resolution of that conflict is forced on the
> downstream person. Worse yet, from this point on, since the
> upstream discarded the track that contains A, the branch
> downstream person has will _never_ converge to upstream branch,
> even though the downstream person did _no_ development of his
> own in the meantime. This is *B*A*D*.
Wow. Yeah. Bad.
> If there is a magic "ours" merge, the downstream person's
> repository records A as the last tip on the tracking branch, and
> git-fetch sees the updated head M is a descendant of it, so it
> simply fast-forwards:
That's beautiful. I get it. This has been an
extraordinarily helpful explanation (for me)!
Thank you!
jdl
^ 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