From: Junio C Hamano <hidden> Date: 2005-09-30 11:55:08
Jeff Garzik [off-list ref] writes:
... Once the 'git fetch --tags' changes make it into the
official repository (are they there already?), I'll remove all
the remaining direct references to running rsync.
Sounds like a thinly veiled threat and/or very effective
prodding ;-).
It is not there yet only because I simply have not got around to
it, but it will happen before 0.99.8.
I suspect the version Linus posted has a funny interaction with
'git-pull'; 'git pull --tags' by mistake, or intentionally to
file a bug report to annoy me ;-), would create an Octopus out
of those tags, if I am not mistaken.
2) What is the easiest way to obtain a list of changes present in
repository B, that are not present in repository A? I used to use
git-changes-script [hacked cg-log script] for this:
I think I still have the copy you sent to the list. If you do
not mind me placing in the master branch just holler -- better
yet please send a patch with commit log and signoff to add the
latest, and I will apply it.
-jc
From: Jeff Garzik <hidden> Date: 2005-09-30 14:11:11
Junio C Hamano wrote:
Jeff Garzik [off-list ref] writes:
quoted
2) What is the easiest way to obtain a list of changes present in
repository B, that are not present in repository A? I used to use
git-changes-script [hacked cg-log script] for this:
I think I still have the copy you sent to the list. If you do
not mind me placing in the master branch just holler -- better
yet please send a patch with commit log and signoff to add the
latest, and I will apply it.
I suspect the version Linus posted has a funny interaction with
'git-pull'; 'git pull --tags' by mistake, or intentionally to
file a bug report to annoy me ;-), would create an Octopus out
of those tags, if I am not mistaken.
Hey, even more impressive is "git pull --all", which will happily try to
create an octopus of every single ref available at the other end.
Now, I think that octopus merges in _general_ are likely to be driver
error, and that it might make sense to have a separate flag to enable
them in the first place. That would solve the confusion..
So then you could do
git pull --all --octopus xyzzy
if you _really_ meant to do that.
Linus
From: Junio C Hamano <hidden> Date: 2005-10-01 07:36:42
Linus Torvalds [off-list ref] writes:
Hey, even more impressive is "git pull --all", which will happily try to
create an octopus of every single ref available at the other end.
True.
However, I think --all is a mistake even if you use it without
merging in 'git fetch', so I am not planning to do refs/heads/
side, at least not yet. Even if you prevent an Octopus, what
would you do then? If you choose to merge one of them, which
one? Not merging any that is not explicitly specified on the
command line, seems to me the most sensible and safe option.
The rule for 'pull' to decide which refs to merge is:
(1) if command line has explicit refspecs (--tags and --heads
do not count), they are all merged.
(2) if command line has no explicit refspecs (--tags and
--heads do not count), the default one found from either
remotes or branches file is merged.
Notice that I am forbidding remotes file to say "by default I
always merge these three heads from there to make an Octopus" by
the above rule (branches file cannot even name more than one
head so this is not an issue). Since everybody seems to agree
that Octopus is not something that is done mechanically and
routinely anyway [*1*], I think this is a sensible way to guard
against accidental Octopus.
We could consider fetching all heads, by minimally renaming
remote master to origin and getting everything else under the
same name, but I'd really want to keep the local namespace for
branches isolated from each other. Many kernel.org public
repositories seem to have 'test' and 'release' branches and if
you are a maintainer of such a tree, and if you are interested
in another maintainer's tree, and if that other maintainer has
the 'test' and 'release' branches, --heads (or --tags)
overwriting your 'test' with his 'test' is obviously not what
you want.
Possibly, something like this could be arranged later:
* git fetch --heads=$ns $remote "$@"
In addition to the usual refspecs (the rest of the
command line arguments), fetch all remote heads and
store remote refs/heads/$a under local refs/heads/$ns/$a
for all $a. If $ns is empty, remote "master" is renamed
"origin".
* git fetch --heads $remote "$@"
shorthand for empty $ns
[Footnote]
*1* I do make many Octopus merges, but they happen across my
local topic branches. Topics merged change day-by-day, and even
the set of topics alive at the time changes everyday. IOW, it
is not something I would want to do with the same sets of heads
every time by describing them in the remotes file.
From: Junio C Hamano <hidden> Date: 2005-10-02 08:47:28
Jeff Garzik [off-list ref] writes:
Junio C Hamano wrote:
quoted
Jeff Garzik [off-list ref] writes:
quoted
quoted
2) What is the easiest way to obtain a list of changes present in
repository B, that are not present in repository A? I used to use
git-changes-script [hacked cg-log script] for this:
I haven't really *read* that script, but I think it is trying to
make a list of commits from both repositories and trying to find
the set that are in one side and not in the other using diff (a
real shell programer probably would have used "comm" for this
kind of task, not "diff"), then doing a handcrafted git-log on
each of them.
Attached is my quick hack, based on your original question,
without really trying to understand what the script is doing, so
I cannot claim it is a rewrite nor even attempting to be
compatible. Please take a look at it and tell me if this is
any close to what you need.
I have a suspition that this might be better done as a natural
extension of git-log, though.
------------
#!/bin/sh
#
# Copyright (c) 2005 Junio C Hamano
#
. git-sh-setup || die "Not a git archive"
usage () {
echo >&2 "$0 ( -L | -R ) <dir> [<ref>] [<ref>]
-L shows changes in local not in remote.
-R shows changes in remote not in local.
<dir> names the remote repository.
If given no refs, local and remote HEADs are compared.
If given one ref, local HEAD and named remote ref are compared.
If given two refs, the first names a local ref, and the second names
remote ref to be compared.
"
exit 1
}
case "$1" in
-L | -R)
;;
*)
usage ;;
esac
other="$2"
(
unset GIT_DIR GIT_OBJECT_DIRECTORY
cd "$other" && . git-sh-setup ||
die "$other is not a valid git repository."
)
local=${3:-HEAD}
remote=${4:-HEAD}
# Basic validation.
local=$(git-rev-parse --verify "$local^0" 2>/dev/null) ||
die "local ref $local is not valid."
remote=$(GIT_DIR="$other" git-rev-parse --verify "$remote^0" 2>/dev/null) ||
die "remote ref $remote is not valid."
case "$1" in
-L)
list_args="$local ^$remote" ;;
-R)
list_args="^$local $remote" ;;
esac
GAOD="$GIT_ALTERNATE_OBJECT_DIRECTORIES"
GIT_ALTERNATE_OBJECT_DIRECTORIES="$other/.git/objects:$GAOD" \
git-rev-list --pretty $list_args |
LESS=-S ${PAGER:-less}