* Re: Something looks like CVS modules
From: Junio C Hamano @ 2005-11-11 8:05 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200511111313.27273.lan@ac-sw.com>
Alexander Litvinov <lan@ac-sw.com> writes:
> Does anybody can guide me how to replace CVS modules in the git enviroment ?
Sorry, no such thing as far as I can tell.
And no, there is no plan to add such a thing before 1.0 at the
core level, sorry. Porcelains are separate story, though.
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Fredrik Kuivinen @ 2005-11-11 7:52 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90511091638k726d605r170717539225a712@mail.gmail.com>
On Thu, Nov 10, 2005 at 01:38:35PM +1300, Martin Langhoff wrote:
> We are working with a series of closely related heads, and merging
> among them. I am sometimes finding merge conflicts that I don't think
> I should be seeing. Assuming two branches, 'local' and 'remote', where
> local has with remote before (*), and I have no conflicting changes in
> local...
>
> 1 - pull and merge from remote. The merge touches file A, B and C
> 2 - on local, develop on unrelated files O,P,Q, commit
> 3 - pull and merge from remote. The merge touches file B, C and D. I
> am sometimes seeing conflicts on file B and C, which was never touched
> on local.
>
> * - In the case i have, the ancestry before the merge is a bit
> convoluted. AFAIK, this shouldn't affect us going forward. Both
> branches have a common ancestor, though, and are now merging often
> from remote to local.
>
> We are using cogito for this, although on step 3 I have also tested
> with git-merge.sh and I get the same result. It could still be a
> problem related to how the merge on step 1 is recording the merge.
>
> For an example, clone
> http://locke.catalyst.net.nz/git/moodle.git#mdl-artena-tairawhiti and
> register also the
> http://locke.catalyst.net.nz/git/moodle.git#mdl-local branch. Create
> two heads:
>
> master: 214e6374d49e6d014f0ba6f159d585a3fe468909
> remote: 05059be73c9e09e22b98bc796be35c595e551ed6
>
> On git-merge 'testing merge' master remote you'll see conflicts over
> mod/quiz/editlib.php -- doing the same with cg-merge gets an
> additional conflict on mod/quiz/export.php. Neither of those files
> were ever modified on local -- however, both merges brought in changes
> to the same lines of code.
>
> I suspect this is because the merge itself is being considered a
> commit on the local branch. Fair enough -- git has no way of ensuring
> that I haven't slipped in a few changes of mine in the merge. OTOH,
> it's pretty unexpected to see this on files that are not one char
> different from the 'remote' branch. Am I doing something wrong?
>
This merge has two common ancestors,
$ git-merge-base --all master remote
3b12fc6420c26a6556c2d806fca79dd96e8e22b9
2163a9076d9515f00494ba9df7dbc85c9804790f
This may explain the results you get with cg-merge, as that script
seems to use 'git-merge-base' without the '--all' flag.
It really seems to be the case that there is a real conflict in
mod/quiz/editlib.php, this can be visualized nicely with
gitk master remote -- mod/quiz/editlib.php
- Fredrik
^ permalink raw reply
* type in cg-merge?
From: Alan Chandler @ 2005-11-11 7:52 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
I am just reading the code in cg-merge to see how it works (taking your advice
to see how to re-write my history properly - see early threads about this
subject)
At line there is an echo 0 that looks suspiciously like it should be an exit
0.
Of course I may just have egg on my face - its my first attempt at looking at
the code.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* [PATCH] Do not lose author name information to locale gotchas.
From: Junio C Hamano @ 2005-11-11 7:42 UTC (permalink / raw)
To: git
I noticed format-patch loses authorship information of Lukas' patch
when I run git tools with LC_LANG set to ja_JP. It turns out that
the sed script to set environment variables were not working on his
name (encoded in UTF-8), which is unfortunate but technically correct.
Force sed invocation under C locale because we always want literal byte
semantics.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* I might have screwed up people's names already without
noticing; if that happened to you, please forgive me. I
think this patch fixes all the problematic places...
git-commit.sh | 2 +-
git-format-patch.sh | 2 +-
git-revert.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
applies-to: 8eacf17303188e55375f76bea8051555ba1baf02
0375d39e7d3052bdb9b21f984a7b7d2b02e627a5
diff --git a/git-commit.sh b/git-commit.sh
index daf90f1..41955e8 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -184,7 +184,7 @@ then
}
'
set_author_env=`git-cat-file commit "$use_commit" |
- sed -ne "$pick_author_script"`
+ LANG=C LC_ALL=C sed -ne "$pick_author_script"`
eval "$set_author_env"
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
diff --git a/git-format-patch.sh b/git-format-patch.sh
index 548d2d5..7ee5d32 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -201,7 +201,7 @@ process_one () {
;;
esac
- eval "$(sed -ne "$whosepatchScript" $commsg)"
+ eval "$(LANG=C LC_ALL=C sed -ne "$whosepatchScript" $commsg)"
test "$author,$au" = ",$me" || {
mailScript="$mailScript"'
a\
diff --git a/git-revert.sh b/git-revert.sh
index dfd914c..4154fe0 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -112,7 +112,7 @@ cherry-pick)
q
}'
set_author_env=`git-cat-file commit "$commit" |
- sed -ne "$pick_author_script"`
+ LANG=C LC_ALL=C sed -ne "$pick_author_script"`
eval "$set_author_env"
export GIT_AUTHOR_NAME
export GIT_AUTHOR_EMAIL
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH] C implementation of the 'git' program.
From: Junio C Hamano @ 2005-11-11 7:40 UTC (permalink / raw)
To: Raja R Harinath, Andreas Ericsson; +Cc: git
In-Reply-To: <m3lkzv4qnz.fsf@harinath.blr.novell.com>
Raja R Harinath <rharinath@novell.com> writes:
> This is bad, since it does the wrong thing for the correct way:
>
> make prefix=/usr
> sudo make prefix=/usr install
>
> With your patch 'git' will be compiled as root.
You are correct.
We should allow building as user and installing as root, with
the installation step _not_ touching the build directory at all.
A good litmus test is that you should be able to build and
install from a root-squashed NFS mounted working tree, without
giving write permissions to NFS-nobody user (obviously you need
to give read and search permissions).
Andreas?
^ permalink raw reply
* Something looks like CVS modules
From: Alexander Litvinov @ 2005-11-11 7:13 UTC (permalink / raw)
To: git
Does anybody can guide me how to replace CVS modules in the git enviroment ?
Currently we have few (~5) projects that can be used by others. At cvs world
we have modules and everything works fine. There are external links in the
svn word - almost the same except tags and branches.
What can I do to make similar functionality with git ?
^ permalink raw reply
* Should have been what is cg-clone doing (Re: What is cg-clone)
From: Alan Chandler @ 2005-11-11 7:03 UTC (permalink / raw)
To: git
In-Reply-To: <200511110656.29553.alan@chandlerfamily.org.uk>
On Friday 11 Nov 2005 06:56, Alan Chandler wrote:
> Just trying to set up my public repository and test it.
>
> cg-clone http://www.chandlerfamily.org.uk/git/famtree.git new
>
> When I get near the end the following happens:
>
> http://www.chandlerfamily.org.uk/git/famtree.git/refs/tags/:
> 05:46:53 ERROR 403: Forbidden.
>
> I suspect its trying to get a list of tags, but is the ":" part of the
> error message, or was that what it was trying to receive.
>
> Does it require that apache serves the directories properly, because at the
> moment I have DirectoryIndex on these set to gitweb.cgi (although thats
> giving me 403 errors at the moment, hence my suspicions)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Raja R Harinath @ 2005-11-11 6:58 UTC (permalink / raw)
To: git
In-Reply-To: <20051110182631.3C5615BF90@nox.op5.se>
Hi,
exon@op5.se (Andreas Ericsson) writes:
[snip]
> As a nice side-effect, the patch also fixes the problem with
> make
> make prefix=/usr install
>
> Signed-off-by: Andreas Ericsson <ae@op5.se>
[snip]
> +# Force rebuild so that "make prefix=<something> install" Just Works.
> +.PHONY: git
This is bad, since it does the wrong thing for the correct way:
make prefix=/usr
sudo make prefix=/usr install
With your patch 'git' will be compiled as root.
- Hari
^ permalink raw reply
* What is cg-clone
From: Alan Chandler @ 2005-11-11 6:56 UTC (permalink / raw)
To: git
Just trying to set up my public repository and test it.
cg-clone http://www.chandlerfamily.org.uk/git/famtree.git new
When I get near the end the following happens:
http://www.chandlerfamily.org.uk/git/famtree.git/refs/tags/:
05:46:53 ERROR 403: Forbidden.
I suspect its trying to get a list of tags, but is the ":" part of the error
message, or was that what it was trying to receive.
Does it require that apache serves the directories properly, because at the
moment I have DirectoryIndex on these set to gitweb.cgi (although thats
giving me 403 errors at the moment, hence my suspicions)
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: merge-base: fully contaminate the well.
From: Junio C Hamano @ 2005-11-11 6:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511102125510.4627@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So the cheap test is to just say
>
> /* Do we have multiple results? */
> if (result->next)
> contaminate_well(result);
>
> no?
Correct. And this is only for really artificial corner case so
we should try to avoid for normal cases as much as possible,
cheaply.
> Btw, I don't think your contamination logic is necessarily complete. We
> may not even have parsed some of the commits that end up being on that
> strange corner case.
I haven't tried walking any other test cases, but wouldn't that
be arguing that the our assumption that the current merge-base
is at least complete if not optimum?
^ permalink raw reply
* Re: git-archimport
From: Martin Langhoff @ 2005-11-11 5:58 UTC (permalink / raw)
To: Kevin Geiss; +Cc: git
In-Reply-To: <20051111051910.GP9131@raven.localdomain>
On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1
I've never imported a signed changeset, perhaps that's the problem. Is
the repo public so I can test it myself?
cheers,
martin
^ permalink raw reply
* [PATCH] cg-fetch: support for active symbols in rsync path
From: Pavel Roskin @ 2005-11-11 5:49 UTC (permalink / raw)
To: git, Petr Baudis
t9112-fetch-rsync.sh breaks if cogito is located in a directory
containing e.g. spaces. The test uses its own rsync replacement
(localrsync) and supplies it to cg-fetch with full patch. cg-fetch
doesn't quote rsync sufficiently to prevent interpreting the path to
localrsync by the shell.
This bug is unlikely to be a problem in real life, but it's important to
have cogito tests run properly in directories with unusual names, since
it allows to catch a number of more serious problems.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-fetch b/cg-fetch
index 8fa34ce..6dfd02f 100755
--- a/cg-fetch
+++ b/cg-fetch
@@ -102,7 +102,7 @@ get_rsync()
shift
fi
- eval ${RSYNC:-rsync} $RSYNC_FLAGS $rsync_flags_l -v -Lr \
+ eval '"${RSYNC:-rsync}"' $RSYNC_FLAGS $rsync_flags_l -v -Lr \
"$1$appenduri" "$2$appenduri" $redir | $filter
return ${PIPESTATUS[0]}
}
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: merge-base: fully contaminate the well.
From: Linus Torvalds @ 2005-11-11 5:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmobuc00.fsf@assigned-by-dhcp.cox.net>
On Thu, 10 Nov 2005, Junio C Hamano wrote:
>
> The discussion on the list demonstrated a pathological case where
> an ancestor of a merge-base can be left interesting. This commit
> introduces a postprocessing phase to fix it.
Hmm. I'd suggest only doing this for the (relatively unlikely) case of
there being more than one merge-base..
You don't even have to be exact about it: just see if the result list is
bigger than one. (ie "result->next != NULL"). Yeah, sometimes there are
result commits that get turned UNINTERESTING after they are added to the
result list, and your "contaminate" phase would be strictly not needed
then, but that's already a pretty unusual case.
So the cheap test is to just say
/* Do we have multiple results? */
if (result->next)
contaminate_well(result);
no?
Btw, I don't think your contamination logic is necessarily complete. We
may not even have parsed some of the commits that end up being on that
strange corner case. I think you catch the particular case you tried, but
I think that in theory, with long chains of commits out of date order, you
could be in the situation of having determined that everything was
uninteresting before you even parsed enough to see the chain from one
merge-base to another.
In fact, I think it would happen with your pathological example if it had
just one more commit out-of-order in the E-D-C-B chain. But I didn't walk
it through.
Linus
^ permalink raw reply
* Re: git-archimport
From: Kevin Geiss @ 2005-11-11 5:19 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Kevin Geiss, git
In-Reply-To: <46a038f90511101421o7988a1bfi89eb0e33bd34e4bb@mail.gmail.com>
On Fri, Nov 11, 2005 at 11:21:12AM +1300, Martin Langhoff wrote:
> On 11/11/05, Kevin Geiss <kevin@desertsol.com> wrote:
> > Cannot find patchset for 'kevin@desertsol.com--files/scripts--oco--0--patch-1' at /usr/bin/git-archimport line 784
>
> Hmmm. The script uses tla itself to get the patch. What happens if you do
>
> tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1
>
> In short, you must have a recent tla configured and with the archive
> registered.
>
> cheers,
>
>
>
> martin
I've got tla 1.3, and the changeset seems to be there:
10:15pm0raven>tla get-changeset -A kevin@desertsol.com--files/scripts--oco--0--patch-1 /tmp
usage: tla get-changeset [options] revision [dir]
try get-changeset --help
10:15pm1raven>tla get-changeset kevin@desertsol.com--files/scripts--oco--0--patch-1 /tmp
gpg: Signature made Mon Feb 14 12:28:10 2005 MST using DSA key ID E1E6A3B1
gpg: Good signature from "Kevin Geiss <kevin@desertsol.com>"
10:15pm0raven>tla get-changeset --help /tmp
retrieve a changeset from an archive
usage: tla get-changeset [options] revision [dir]
-h, --help Display a help message and exit.
-H Display a verbose help message and exit.
-V, --version Display a release identifier string
and exit.
-A, --archive Override `my-default-archive'
10:16pm0raven>tla --version /tmp
tla lord@emf.net--gnu-arch-2004/dists--tla--1.3--version-0(configs/gnu/This-release) from regexps.com
^ permalink raw reply
* [PATCH] git-clone: quote destination directory name
From: Pavel Roskin @ 2005-11-11 5:19 UTC (permalink / raw)
To: git
git-clone doesn't quote the full path to the destination directory,
which causes it to fail if the path contains spaces or other characters
interpreted by the shell.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/git-clone.sh b/git-clone.sh
index 4fdd652..0f37dff 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -163,7 +163,7 @@ yes,yes)
rm -f "$D/.git/TMP_ALT"
if test -f "$D/.git/TMP_ALT"
then
- ( cd $D &&
+ ( cd "$D" &&
. git-parse-remote &&
resolve_alternates "$repo" <"./.git/TMP_ALT" ) |
while read alt
@@ -191,7 +191,7 @@ yes,yes)
;;
esac
-cd $D || exit
+cd "$D" || exit
if test -f ".git/HEAD"
then
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: tracking a tree that doesn't progress linearly
From: Martin Langhoff @ 2005-11-11 4:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17268.3463.252020.591687@cargo.ozlabs.ibm.com>
On 11/11/05, Paul Mackerras <paulus@samba.org> wrote:
> I want to be able to publish a git tree for others to follow but I
> also want to be retain the freedom to remove commits and/or rebase
> commits in the tree.
I sometimes want that too, but git doesn't have a 'rewind' semantics,
and probably for a good reason. The approach I am studying is to
create a thousand throaway short-lived branches. It is safe to publish
them as long as people following your branches _know_ that they'll be
orphaned, and that any commits they have on top of them they'll have
to rebase.
So you could publish your tree with devel-<datestamp> heads, and
announce when you're moving to a newer one. People tracking your
branches can tend register & checkout the new branches, and do a
git-merge to rebase their patches to your new branch, or replay them
with git-format-patch and git-am.
On the other hand, if StGIT grows better support for sharing patches,
it could make all this look like the stone age.
cheers,
martin
^ permalink raw reply
* [PATCH] archimport: handle pika escaping
From: Martin Langhoff @ 2005-11-11 5:00 UTC (permalink / raw)
To: git; +Cc: Martin Langhoff
Arch uses pika escaping in some places (but not all!). Specifically, commits of
the type 'patch' use pika escaping in the log entries, which we parse to know
what to add/delete and what to commit.
This patch checks for hints of pika escaping and asks tla to unescape for us.
Originally implemented by Penny Leach <penny@catalyst.net.nz>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
---
git-archimport.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
applies-to: 6466c53ae80cddbb581c5fdb2332f9321fade867
b9d1055507ebce7f1ae1706feb79619cb03cf078
diff --git a/git-archimport.perl b/git-archimport.perl
index 980e827..e22c816 100755
--- a/git-archimport.perl
+++ b/git-archimport.perl
@@ -565,6 +565,11 @@ sub parselog {
next if $t =~ m!\{arch\}/!;
next if $t =~ m!\.arch-ids/!;
next if $t =~ m!\.arch-inventory$!;
+ # tla cat-archive-log will give us filenames with spaces as file\(sp)name - why?
+ # we can assume that any filename with \ indicates some pika escaping that we want to get rid of.
+ if ($t =~ /\\/ ){
+ $t = `tla escape --unescaped '$t'`;
+ }
push (@tmp, shell_quote($t));
}
@$ref = @tmp;
---
0.99.8.GIT
^ permalink raw reply related
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Pavel Roskin @ 2005-11-11 4:53 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Petr Baudis, git
In-Reply-To: <200511110213.54846.Josef.Weidendorfer@gmx.de>
On Fri, 2005-11-11 at 02:13 +0100, Josef Weidendorfer wrote:
> > Correct. But if it's a concern, I think we could make some
> > improvements. Following approaches could be tried (starting from top,
> > using following steps as a fallback):
> >
> > 1) Use recorded branch, i.e. the branch name that was used in cg-clone.
>
> This is the "#..." part in .git/branches/origin, and it is already used.
I'm not sure if we understand each other, but "recorded" refers to
automatically determined branch name. If cg-clone can determine the
branch name, that name should be saved and used for updates.
Whether the branch name is saved in .git/branches/ using hash notation
(old style) or in .git/remotes/ (new style) is irrelevant.
If cg-clone cannot determine the branch name, we may either support it,
or revert to "master". I'm ambivalent about that. Probably reverting
to "master" is better to simplify the code. On the other hand, I can
imagine public repositories without the "master" branch.
> I have nothing against using HEAD for cloning, but the branch name should
> be recorded, such that cg-pull always fetches from the same branch.
To use HEAD, we'll need to port git from Cygwin, since readlink doesn't
work over http.
> I think 1) is enough if we add the detected branch name in the #... part
> in .git/branches/origin at cg-clone time.
I agree that the branch name should be saved explicitly using already
supported notation (if that's what you mean).
> And "detectable" covers the local case, which was my concern here [*1*]
>
> Josef
>
> [*1*] after being told about the "stable HEAD" property of public repositories,
> which is correct. I am not even sure that a HEAD makes sense
> in public repositories: in my opinion HEAD has something to do with checked out
> files, and a public repository usually does not have these. But perhaps
> that's only me...
That's why I mentioned the idea of having a separate file to indicate
the default branch for export.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Martin Langhoff @ 2005-11-11 4:40 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20051110102043.GQ30496@pasky.or.cz>
On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> Interesting. Could you check what the merge base is?
>
> git-merge-base local remote
>
> It should be the merge from (1).
It seems to be actually one of the parents, not the merge itself.
> > For an example, clone
> > http://locke.catalyst.net.nz/git/moodle.git#mdl-artena-tairawhiti and
> > register also the
> > http://locke.catalyst.net.nz/git/moodle.git#mdl-local branch. Create
> > two heads:
>
> Could you please run git-update-server-info over there?
Should be fixed now...
cheers,
martin
^ permalink raw reply
* tracking a tree that doesn't progress linearly
From: Paul Mackerras @ 2005-11-11 3:18 UTC (permalink / raw)
To: git
I want to be able to publish a git tree for others to follow but I
also want to be retain the freedom to remove commits and/or rebase
commits in the tree. For example, if someone sends me a patch and I
put it in the tree, then they send me a revised version, I want to be
able to roll back to just before I applied the older patch and start
again from there.
What this means, AFAICS, is that the head of the published tree won't
always be a descendent of all previous values of the head. If
somebody is following the state of the tree by doing a git pull every
so often, and I have rolled back the tree and applied some new
patches, then the git pull will try to merge the old and new state,
which is not what we want. What we want is something that just gets
the local tree to the same state as the remote tree.
Is there a git command which does the equivalent of a git fetch,
followed by setting the head and checking it out?
Or is this an incredibly stupid idea for some reason that hasn't
occurred to me yet? :)
Thanks,
Paul.
^ permalink raw reply
* merge-base: fully contaminate the well.
From: Junio C Hamano @ 2005-11-11 2:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511091348530.4627@g5.osdl.org>
The discussion on the list demonstrated a pathological case where
an ancestor of a merge-base can be left interesting. This commit
introduces a postprocessing phase to fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> On Wed, 9 Nov 2005, Junio C Hamano wrote:
>
>> But the point of well-poisoning you did in merge-base was to
>> detect that E is an ancestor of B and exclude it in the first
>> place.
>
> Ahh, you're right, and I'm wrong. That "E" is not a real merge-base, since
> there _is_ a valid merge-base that is a direct descendant of it and thus
> objectively better.
>
> Which means that sometimes it can stop with too _many_ merge heads, just
> because it hasn't realized that they are reachable through a chain that is
> otherwise provably uninteresting.
I am not particularly proud of this change, but here is an
attempt to fully contaminate the well without going all the
way down to root. It adds a postprocessing phase which does
not parse any new commits.
> The thing is, I don't see what guarantees that the show-branch brhaviour
> is safe or conservative.
You are right about this; I have a separate patch to fix it.
merge-base.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 77 insertions(+), 1 deletions(-)
applies-to: 8eacf17303188e55375f76bea8051555ba1baf02
a2fd94f707128f3f390362725c8d8b0802940111
diff --git a/merge-base.c b/merge-base.c
index 286bf0e..43a6818 100644
--- a/merge-base.c
+++ b/merge-base.c
@@ -80,6 +80,45 @@ static struct commit *interesting(struct
* Now, list does not have any interesting commit. So we find the newest
* commit from the result list that is not marked uninteresting. Which is
* commit B.
+ *
+ *
+ * Another pathological example how this thing can fail to mark an ancestor
+ * of a merge base as UNINTERESTING without the postprocessing phase.
+ *
+ * 2
+ * H
+ * 1 / \
+ * G A \
+ * |\ / \
+ * | B \
+ * | \ \
+ * \ C F
+ * \ \ /
+ * \ D /
+ * \ | /
+ * \| /
+ * E
+ *
+ * list A B C D E F G H
+ * G1 H2 - - - - - - 1 2
+ * H2 E1 B1 - 1 - - 1 - 1 2
+ * F2 E1 B1 A2 2 1 - - 1 2 1 2
+ * E3 B1 A2 2 1 - - 3 2 1 2
+ * B1 A2 2 1 - - 3 2 1 2
+ * C1 A2 2 1 1 - 3 2 1 2
+ * D1 A2 2 1 1 1 3 2 1 2
+ * A2 2 1 1 1 3 2 1 2
+ * B3 2 3 1 1 3 2 1 2
+ * C7 2 3 7 1 3 2 1 2
+ *
+ * At this point, unfortunately, everybody in the list is
+ * uninteresting, so we fail to complete the following two
+ * steps to fully marking uninteresting commits.
+ *
+ * D7 2 3 7 7 3 2 1 2
+ * E7 2 3 7 7 7 2 1 2
+ *
+ * and we end up showing E as an interesting merge base.
*/
static int show_all = 0;
@@ -88,6 +127,7 @@ static int merge_base(struct commit *rev
{
struct commit_list *list = NULL;
struct commit_list *result = NULL;
+ struct commit_list *tmp = NULL;
if (rev1 == rev2) {
printf("%s\n", sha1_to_hex(rev1->object.sha1));
@@ -104,9 +144,10 @@ static int merge_base(struct commit *rev
while (interesting(list)) {
struct commit *commit = list->item;
- struct commit_list *tmp = list, *parents;
+ struct commit_list *parents;
int flags = commit->object.flags & 7;
+ tmp = list;
list = list->next;
free(tmp);
if (flags == 3) {
@@ -130,6 +171,41 @@ static int merge_base(struct commit *rev
if (!result)
return 1;
+ /*
+ * Postprocess to fully contaminate the well.
+ */
+ for (tmp = result; tmp; tmp = tmp->next) {
+ struct commit *c = tmp->item;
+ /* Reinject uninteresting ones to list,
+ * so we can scan their parents.
+ */
+ if (c->object.flags & UNINTERESTING)
+ commit_list_insert(c, &list);
+ }
+ while (list) {
+ struct commit *c = list->item;
+ struct commit_list *parents;
+
+ tmp = list;
+ list = list->next;
+ free(tmp);
+
+ /* Anything taken out of the list is uninteresting, so
+ * mark all its parents uninteresting. We do not
+ * parse new ones (we already parsed all the relevant
+ * ones).
+ */
+ parents = c->parents;
+ while (parents) {
+ struct commit *p = parents->item;
+ parents = parents->next;
+ if (!(p->object.flags & UNINTERESTING)) {
+ p->object.flags |= UNINTERESTING;
+ commit_list_insert(p, &list);
+ }
+ }
+ }
+
while (result) {
struct commit *commit = result->item;
result = result->next;
---
0.99.9.GIT
^ permalink raw reply related
* Re: The host:remote syntax mess
From: Junio C Hamano @ 2005-11-11 1:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111012216.GJ30496@pasky.or.cz>
Petr Baudis <pasky@ucw.cz> writes:
> I've just noticed that host:remote syntax seems to have been hijacked
> again and is now attached to the GIT protocol in
>
> Documentation/pull-fetch-param.txt
>
> (which BTW misses git+ssh). I said "seems", because connect.c still
> appears to assume it is SSH. So what is the plan?
Sorry about that. Thanks for noticing.
There is no plan to change that. This documentation gotcha was
just that yours truly stupidly merged documentation changes
without reading every single line.
-- >8 -- cut here -- >8 --
[PATCH] Documentation: "host:path/to/repo" is git native over ssh.
You could also spell it ssh://host:/path/to/repo (or git+ssh,
ssh+git), but without method:// is shorter to type, so mention
only that one in the short and sweet list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 5c2888e..ddd5823 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -8,7 +8,7 @@
- Rsync URL: rsync://remote.machine/path/to/repo.git/
- HTTP(s) URL: http://remote.machine/path/to/repo.git/
- git URL: git://remote.machine/path/to/repo.git/
- or remote.machine:/path/to/repo.git/
+- ssh URL: remote.machine:/path/to/repo.git/
- Local directory: /path/to/repo.git/
===============================================================
+
^ permalink raw reply related
* Re: [PATCH] Change 'cache' to 'index' in the docs
From: Junio C Hamano @ 2005-11-11 1:34 UTC (permalink / raw)
To: Lukas =?iso-2022-jp-2?B?U2FuZHN0chsuQRtOdm0=?=; +Cc: git, junkio
In-Reply-To: <4373EFFB.6060802@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 410 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> git-update-index.txt says:
> "Modifies the index or directory cache."
>
> I thought the index was the directory cache.
> Is git-update-index.txt badly worded or is there something
> I'm missing?
Nothing. Just 'cache' is so ingrained to the brain of some/many
of us that we let it go unnoticed, with an excuse that somewhere
we say "index aka cache".
^ permalink raw reply
* The host:remote syntax mess
From: Petr Baudis @ 2005-11-11 1:22 UTC (permalink / raw)
To: git
Hello,
I've just noticed that host:remote syntax seems to have been hijacked
again and is now attached to the GIT protocol in
Documentation/pull-fetch-param.txt
(which BTW misses git+ssh). I said "seems", because connect.c still
appears to assume it is SSH. So what is the plan? One possible
explanation is just that the git+ssh line should have been between the
git line and the : line in the documentation.
But if you really intend to change it, please don't. It's enough mess
as it is now, and I'm actually not convinced at all that we should
support it at all (god forbid promote it). When you have a location
specifier, you don't want it to randomly switch protocols, especially
such significantly different ones as ssh and git.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
From: Josef Weidendorfer @ 2005-11-11 1:13 UTC (permalink / raw)
To: Pavel Roskin; +Cc: Petr Baudis, git
In-Reply-To: <1131668075.3987.5.camel@dv>
On Friday 11 November 2005 01:14, Pavel Roskin wrote:
> On Fri, 2005-11-11 at 00:40 +0100, Petr Baudis wrote:
> > Dear diary, on Fri, Nov 11, 2005 at 12:26:18AM CET, I got a letter
> > where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > > Why would anybody want to fetch the current upstream HEAD at cg-pull
> > > time?
> ...
> Correct. But if it's a concern, I think we could make some
> improvements. Following approaches could be tried (starting from top,
> using following steps as a fallback):
>
> 1) Use recorded branch, i.e. the branch name that was used in cg-clone.
This is the "#..." part in .git/branches/origin, and it is already used.
I have nothing against using HEAD for cloning, but the branch name should
be recorded, such that cg-pull always fetches from the same branch.
I think 1) is enough if we add the detected branch name in the #... part
in .git/branches/origin at cg-clone time.
And "detectable" covers the local case, which was my concern here [*1*]
Josef
[*1*] after being told about the "stable HEAD" property of public repositories,
which is correct. I am not even sure that a HEAD makes sense
in public repositories: in my opinion HEAD has something to do with checked out
files, and a public repository usually does not have these. But perhaps
that's only me...
^ 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