* 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
* 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
* 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: typo in cg-merge?
From: Alan Chandler @ 2005-11-11 8:05 UTC (permalink / raw)
To: git
In-Reply-To: <200511110752.53249.alan@chandlerfamily.org.uk>
On Friday 11 Nov 2005 07:52, Alan Chandler wrote:
> At line there is an echo 0 that looks suspiciously like it should be an
> exit 0.
That was line 149
And I had a typo in the subject line:-(
--
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 8:28 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:
> 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....
You are right. And the situation seems really bad.
The full-contaminator is not full at all, and fails miserably in
not so pathlogical case. If we have something like this:
1 2 List A B C D E F G
F E F1 E2 - - - - 2 1 -
|\ /| G1 E2 D1 C1 - - 1 1 2 1 1
\ \ / | E2 D1 C1 - - 1 1 2 1 1
|\ D /| G3 D3 C3 - - 3 3 2 1 3
| \ | / | D3 C3 - - 3 3 2 1 3
| C | C7 - - 7 3 2 1 3
| | |
| B |
| | /
\ A /
\ | /
G
we would end up finding D and G and stop there, without ever
seeing A or B. B _might_ be touched when we look at C at the
last round, but there is no way for us to find G is reachable
from D (or C) without parsing more than what we parsed in the
main loop.
The worst part of this is that you can indefinitely extend C-B-A
chain trivially, and all it takes is the one, initial commit G,
that has a screwed-up timestamp. All the other commits in this
example are in the right time order. Very sad.
^ permalink raw reply
* [PATCH] specfile cleanups
From: Chris Wright @ 2005-11-11 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Some specfile cleanups after the split.
- zlib dependency fix, current method is inconsistent, you can
potentially build a package that you can't install on machine you
built it on
- Add proper defattr
- Remove trailing '.' in summary
- Add docs to split up packages
- Add git-core dependency for each subpackage
- Move arch import to separate package as well
Signed-off-by: Chris Wright <chrisw@osdl.org>
---
diff --git a/git-core.spec.in b/git-core.spec.in
index 26846d0..8ef29b8 100644
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -1,4 +1,4 @@
-# Pass --without docs to rpmbuild if you don't want the documetnation
+# Pass --without docs to rpmbuild if you don't want the documentation
Name: git-core
Version: @@VERSION@@
Release: 1%{?dist}
@@ -7,7 +7,7 @@ License: GPL
Group: Development/Tools
URL: http://kernel.org/pub/software/scm/git/
Source: http://kernel.org/pub/software/scm/git/%{name}-%{version}.tar.gz
-BuildRequires: zlib-devel, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
+BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4
@@ -20,22 +20,30 @@ rudimentary tools that can be used as a
elsewhere for tools for ordinary humans layered on top of this.
%package svn
-Summary: Git tools for importing Subversion repositories.
+Summary: Git tools for importing Subversion repositories
Group: Development/Tools
-Requires: subversion
+Requires: git-core = %{version}-%{release} subversion
%description svn
Git tools for importing Subversion repositories.
%package cvs
-Summary: Git tools for importing CVS repositories.
+Summary: Git tools for importing CVS repositories
Group: Development/Tools
-Requires: cvs
+Requires: git-core = %{version}-%{release} cvs
%description cvs
Git tools for importing CVS repositories.
+%package arch
+Summary: Git tools for importing Arch repositories
+Group: Development/Tools
+Requires: git-core = %{version}-%{release}
+%description arch
+Git tools for importing Arch repositories.
+
%package email
-Summary: Git tools for sending email.
+Summary: Git tools for sending email
Group: Development/Tools
+Requires: git-core = %{version}-%{release}
%description email
Git tools for sending email.
@@ -52,33 +60,54 @@ make %{_smp_mflags} DESTDIR=$RPM_BUILD_R
prefix=%{_prefix} mandir=%{_mandir} \
install %{!?_without_docs: install-doc}
-(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "svn|cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-files
+(find $RPM_BUILD_ROOT%{_bindir} -type f | grep -vE "arch|svn|cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@) > bin-man-doc-files
%if %{!?_without_docs:1}0
-(find $RPM_BUILD_ROOT%{_mandir} -type f | grep -vE "svn|cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-files
+(find $RPM_BUILD_ROOT%{_mandir} $RPM_BUILD_ROOT/Documentation -type f | grep -vE "arch|svn|git-cvs|email" | sed -e s@^$RPM_BUILD_ROOT@@ -e 's/$/*/' ) >> bin-man-doc-files
%endif
%clean
rm -rf $RPM_BUILD_ROOT
%files svn
+%defattr(-,root,root)
%{_bindir}/*svn*
+%doc Documentation/*svn*.txt
%{!?_without_docs: %{_mandir}/man1/*svn*.1*}
+%{!?_without_docs: %doc Documentation/*svn*.html }
%files cvs
+%defattr(-,root,root)
+%doc Documentation/*git-cvs*.txt
%{_bindir}/*cvs*
%{!?_without_docs: %{_mandir}/man1/*cvs*.1*}
+%{!?_without_docs: %doc Documentation/*git-cvs*.html }
+
+%files arch
+%defattr(-,root,root)
+%doc Documentation/*arch*.txt
+%{_bindir}/*arch*
+%{!?_without_docs: %{_mandir}/man1/*arch*.1*}
+%{!?_without_docs: %doc Documentation/*arch*.html }
%files email
+%defattr(-,root,root)
+%doc Documentation/*email*.txt
%{_bindir}/*email*
%{!?_without_docs: %{_mandir}/man1/*email*.1*}
+%{!?_without_docs: %doc Documentation/*email*.html }
-%files -f bin-man-files
+%files -f bin-man-doc-files
%defattr(-,root,root)
%{_datadir}/git-core/
%doc README COPYING Documentation/*.txt
%{!?_without_docs: %doc Documentation/*.html }
%changelog
+* Thu Nov 10 2005 Chris Wright <chrisw@osdl.org> 0.99.9g-1
+- zlib dependency fix
+- Minor cleanups from split
+- Move arch import to separate package as well
+
* Tue Sep 27 2005 Jim Radford <radford@blackbean.org>
- Move programs with non-standard dependencies (svn, cvs, email)
into separate packages
^ permalink raw reply related
* Re: Getting rid of symlinks in .git?
From: Simon Richter @ 2005-11-11 9:15 UTC (permalink / raw)
To: Petr Baudis; +Cc: Pavel Roskin, git
In-Reply-To: <20051110204543.GZ30496@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 424 bytes --]
Hello,
Petr Baudis wrote:
> I personally would not mind getting rid of symlinks completely, but we
> will still have to support them for some reasonable time period (several
> major releases, as far as Cogito is concerned - actually, there is
> plenty of people still using 0.13 and such).
As someone who carries around git repositories on VFAT formatted USB
sticks, I welcome our symlink-deprived overlords.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: [PATCH] specfile cleanups
From: Junio C Hamano @ 2005-11-11 9:22 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20051111091029.GW8041@shell0.pdx.osdl.net>
Chris Wright <chrisw@osdl.org> writes:
> Some specfile cleanups after the split.
Thanks.
Does it matter some Requires use comma and others don't?
> -BuildRequires: zlib-devel, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
> +BuildRequires: zlib-devel >= 1.2, openssl-devel, curl-devel %{!?_without_docs:, xmlto, asciidoc > 6.0.3}
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
> Requires: zlib >= 1.2, rsync, rcs, curl, less, openssh-clients, python >= 2.3, tk >= 8.4
>
> Group: Development/Tools
> -Requires: subversion
> +Requires: git-core = %{version}-%{release} subversion
^ permalink raw reply
* Re: type in cg-merge?
From: Petr Baudis @ 2005-11-11 10:17 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511110752.53249.alan@chandlerfamily.org.uk>
Dear diary, on Fri, Nov 11, 2005 at 08:52:53AM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> 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.
You are obviously right. Thanks, fixed.
--
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: What is cg-clone
From: Petr Baudis @ 2005-11-11 10:28 UTC (permalink / raw)
To: Alan Chandler; +Cc: git
In-Reply-To: <200511110656.29553.alan@chandlerfamily.org.uk>
You seem to have bad luck with subjects today. ;-)
Dear diary, on Fri, Nov 11, 2005 at 07:56:29AM CET, I got a letter
where Alan Chandler <alan@chandlerfamily.org.uk> said that...
> 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.
It seems to be part of the error message. This is wget's error anyway.
> 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)
It require_d_ in the past that refs/tags/ would have directory listing
permitted.
This is no longer the requirement right now and in 0.16rc1 (which I
released the last night, but didn't get to write announcement for it
yet).
--
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: Something looks like CVS modules
From: Petr Baudis @ 2005-11-11 10:28 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200511111313.27273.lan@ac-sw.com>
Dear diary, on Fri, Nov 11, 2005 at 08:13:26AM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> 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 ?
Well, what exactly is the problem with just having multiple
repositories?
--
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: tracking a tree that doesn't progress linearly
From: Catalin Marinas @ 2005-11-11 10:40 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17268.3463.252020.591687@cargo.ozlabs.ibm.com>
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. 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.
I'm facing a similar problem. I use StGIT for my development branch
(usually with less than 20 patches) but I would like to export a HEAD
for others to pull from. When rebasing the patches with StGIT, the new
HEAD wouldn't be a descendant of the old one.
The partial solution I got to was to make the master branch available
to people and the devel branch private. Initially, the master branch
would pick the patches ('stg pick') from the devel branch which I want
to make public. When I'm happy with the patches on the master branch,
I run 'stg commit' and store them permanently (you won't be able to
modify them). After permanently storing the patches, I can use the
master branch in the normal way with GIT (merge, pull, push etc.).
When I get a patch in the devel branch updated, I just run 'stg pick
patchname@devel' in the master branch. Because of the nature of the
three-way merge, the new picked patch should only contain the
differences from the previous one. It might also cause conflicts which
need resolving if the new patch modifies lines which were present in
the old patch (i.e. not only additions or removals). At this point you
can change the patch description since the new picked patch only
represents an update to the old one and not the full feature.
The only little drawback I see with this approach is that merging in
the latest changes from the mainline kernel could produce identical
conflicts (if any) in both master and devel branches.
--
Catalin
^ permalink raw reply
* Re: Something looks like CVS modules
From: Alexander Litvinov @ 2005-11-11 10:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111102857.GM30496@pasky.or.cz>
On Friday 11 November 2005 16:28, Petr Baudis wrote:
> Well, what exactly is the problem with just having multiple
> repositories?
1. The problem with checkout - single checkout should checkout all needed
modules to build project. Update should also update all modules. The same
with commit.
2. Tags should be done on all modules. All modules should be able to be in the
same branch.
And in the same time one module should be able to exists in two or more
projects !
^ permalink raw reply
* Re: Something looks like CVS modules
From: Petr Baudis @ 2005-11-11 10:58 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200511111642.25908.lan@ac-sw.com>
Dear diary, on Fri, Nov 11, 2005 at 11:42:25AM CET, I got a letter
where Alexander Litvinov <lan@ac-sw.com> said that...
> On Friday 11 November 2005 16:28, Petr Baudis wrote:
> > Well, what exactly is the problem with just having multiple
> > repositories?
>
> 1. The problem with checkout - single checkout should checkout all needed
> modules to build project. Update should also update all modules. The same
> with commit.
> 2. Tags should be done on all modules. All modules should be able to be in the
> same branch.
Then just have only a bunch of directories in your project root, and
that shall be your modules. :-)
(CVS modules don't work like that either, do they?)
> And in the same time one module should be able to exists in two or more
> projects !
But this is troublesome, and doesn't fit into GIT's model at all. Do you
have any concrete example of a scenario where something like this would
be useful?
--
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: tracking a tree that doesn't progress linearly
From: Petr Baudis @ 2005-11-11 11:06 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17268.3463.252020.591687@cargo.ozlabs.ibm.com>
Dear diary, on Fri, Nov 11, 2005 at 04:18:31AM CET, I got a letter
where Paul Mackerras <paulus@samba.org> said that...
> 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?
I plan to change the fast-forward condition in Cogito from
is_ancestor(current, new_head)
to
current == old_head || is_ancestor(current, new_head)
which should enable you to do this - just rebase, and it will Just Work
for those cg-update'ing from you; the only problem si that cg-fetch +
cg-merge will NOT work, but I have no simple workaround for that.
I already proposed this several times and it was always passed in
silence, so I assume there are no problems with this approach.
--
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: Something looks like CVS modules
From: Sven Verdoolaege @ 2005-11-11 11:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Alexander Litvinov, git
In-Reply-To: <20051111105820.GN30496@pasky.or.cz>
On Fri, Nov 11, 2005 at 11:58:20AM +0100, Petr Baudis wrote:
> Dear diary, on Fri, Nov 11, 2005 at 11:42:25AM CET, I got a letter
> where Alexander Litvinov <lan@ac-sw.com> said that...
> > And in the same time one module should be able to exists in two or more
> > projects !
>
> But this is troublesome, and doesn't fit into GIT's model at all. Do you
> have any concrete example of a scenario where something like this would
> be useful?
A .bib file shared by several publications.
skimo
^ permalink raw reply
* Re: Something looks like CVS modules
From: Alexander Litvinov @ 2005-11-11 11:13 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051111105820.GN30496@pasky.or.cz>
On Friday 11 November 2005 16:58, Petr Baudis wrote:
> > 1. The problem with checkout - single checkout should checkout all needed
> > modules to build project. Update should also update all modules. The same
> > with commit.
> > 2. Tags should be done on all modules. All modules should be able to be
> > in the same branch.
>
> > And in the same time one module should be able to exists in two or more
> > projects !
>
> Then just have only a bunch of directories in your project root, and
> that shall be your modules. :-)
>
> (CVS modules don't work like that either, do they?)
As far as CVS tracks tags/branches separatly for each file, tags abd branches
work well for modules.
Bunch of directories is almost what I want except tags/branches/history. CVS
does not care if two directories have separate root/repos. All it wants -is a
properly CVS dir.
> But this is troublesome, and doesn't fit into GIT's model at all. Do you
> have any concrete example of a scenario where something like this would
> be useful?
For eaxmle: I have java lib A. I setup project B in this way:
B/src/
B/A/src
Have another project C:
C/src/
C/A/src
Both of them share the same code from library's module. I can tag them, edit,
commit: do all work I usualy do. If I change something in B/A/src this will
be updated into C/A/src.
This is what I dreaming about :-)
^ permalink raw reply
* Re: [PATCH] specfile cleanups
From: Andreas Ericsson @ 2005-11-11 11:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vveyzpmi7.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Junio C Hamano wrote:
> Chris Wright <chrisw@osdl.org> writes:
>
>
>>Some specfile cleanups after the split.
>
>
> Thanks.
>
> Does it matter some Requires use comma and others don't?
>
Other than for consistency reasons, no. Most distributions have it in
their conventions to use commas. Some don't.
Most also have the conventions enforced by the attached script as it
enhances readability by removing much un-necessary clutter.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
[-- Attachment #2: specwash.sh --]
[-- Type: application/x-shellscript, Size: 1044 bytes --]
^ permalink raw reply
* Re: Strange merge conflicts against earlier merge.
From: Petr Baudis @ 2005-11-11 11:35 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90511102040n3e251252rce54117c51ce0429@mail.gmail.com>
Dear diary, on Fri, Nov 11, 2005 at 05:40:05AM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> > > 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...
I still have trouble cloning:
$ cg-clone http://locke.catalyst.net.nz/git/moodle.git#mdl-artena-tairawhiti
defaulting to local storage area
warning: templates not found /home/xpasky/share/git-core/templates/
12:13:31 URL:http://locke.catalyst.net.nz/git/moodle.git/refs/heads/mdl-artena-tairawhiti [41/41] -> ".git/refs/heads/.origin-fetching" [1]
progress: 3 objects, 860 bytes
Getting alternates list
progress: 4 objects, 1934 bytes
Getting pack list
progress: 19 objects, 12532 bytes
error: The requested URL returned error: 404
error: Unable to find 214e6374d49e6d014f0ba6f159d585a3fe468909 under
http://locke.catalyst.net.nz/git/moodle.git/
Cannot obtain needed commit 214e6374d49e6d014f0ba6f159d585a3fe468909
while processing commit 6d32aa8241387e58ffd0e18862114add0d20d686.
cg-fetch: objects fetch failed
cg-clone: fetch failed
PS: Do I understand it right that git-clone can't clone just a single
head?
--
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: Strange merge conflicts against earlier merge.
From: Petr Baudis @ 2005-11-11 11:45 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <20051111075257.GA4765@c165.ib.student.liu.se>
Dear diary, on Fri, Nov 11, 2005 at 08:52:57AM CET, I got a letter
where Fredrik Kuivinen <freku045@student.liu.se> said that...
> 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.
Hmm. So what should I do with that? :-)
I wondered about adding multi-base merge support to Cogito, but it seems
to be a bit funny, and totally undocumented. Especially, is it right
that I would end up with _four_ stages in case of two-base "three"-way
merge? That would mean complete rewrite of the one-file merger, right?
And it seems git-merge-index would overflow and crash. :-)
I guess I really don't want to do that, but instead choose one of the
bases. Hmm. Well, I suppose it's as good as anything to leave this
decision on the user. Kind of:
if [ $(wc -l merge-bases) -ge 1 ]; then
echo "Multiple merge bases, please select one by the -b parameter:" >&2
cat merge-bases
echo -n "The most conservative base (but likely a lot of conflicts):" >&2
while true; do
git-merge-base --all $(cat merge-bases) >merge-bases~
mv merge-bases~ merge-bases
[ $(wc -l merge-bases) -eq 1 ] && break
done
cat merge-bases
exit 1
fi
Does core GIT have support for multibase merges, except for the
recursive merge strategy? How do you do it?
--
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] Change 'cache' to 'index' in the docs
From: Andreas Ericsson @ 2005-11-11 11:49 UTC (permalink / raw)
To: git
In-Reply-To: <7voe4svufi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> 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".
>
This had me puzzled for quite some time. Some notice to the tutorial
about what's meant when it says "tree-ish" or "commit-ish" would be nice
(I still haven't been able to figure it out).
The wording in git-diff-index.txt isn't exactly stellar either. The
git(7) man-page mentions that it's nice to read git-diff-index before
doing anything else, but it was just yesterday before I figured out that
it can be used to produce a diff between an updated index and the
checked out working tree (which has led me to some fairly obscure
juggling with patches and source-files to remember just what the hell it
was I changed).
Oh well. Perhaps I checked in all the wrong places.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] C implementation of the 'git' program.
From: Andreas Ericsson @ 2005-11-11 12:04 UTC (permalink / raw)
To: git
In-Reply-To: <7vveyzskdk.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> 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.
Sane point. This doesn't work without a ./configure script or some such
though (something external to the Makefile that updates a config-file of
some sort), as
make
(make finishes, user remembers he/she must use prefix= to install somewhere)
make prefix=/usr
wouldn't rebuild git so binaries produced would still try to use
$HOME/bin for libdir. Granted, it's easy enough to do 'touch git.c'
before rebuilding, but it's not exactly intuitive.
I'll hack up a configure-script if that's alright. It should be fairly
short and just define the GIT_VERSION and GIT_LIBDIR macros.
I imagine this can be done through the config.mak file, included from
221 in Makefile, supposing it's forcibly included rather than just if it
exists, and we'll have the 'git:' target depend on it. I think this is
the least intrusive change. OTOH, it might not be bad to move some of
the uname_? logic to a shell-script (and have all targets depend on
config.mak).
Thoughts? I've got a feeling I've overlooked something here.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Alex Riesen @ 2005-11-11 12:43 UTC (permalink / raw)
To: Simon Richter; +Cc: Petr Baudis, Pavel Roskin, git
In-Reply-To: <43746118.30404@hogyros.de>
On 11/11/05, Simon Richter <Simon.Richter@hogyros.de> wrote:
> > I personally would not mind getting rid of symlinks completely, but we
> > will still have to support them for some reasonable time period (several
> > major releases, as far as Cogito is concerned - actually, there is
> > plenty of people still using 0.13 and such).
>
> As someone who carries around git repositories on VFAT formatted USB
> sticks, I welcome our symlink-deprived overlords.
>
But you shouldn't care if you have reasonably recent git everywhere:
symlinks and their absence already handled: .git/config created by
init-db contains the configuration parameter for filemode, which
decides whether it is safe to use the symlinks on the underlying
filesystem.
It looks more like a rhetorical question of code cleanup, because
in-file symlinks already handle all possible cases.
^ permalink raw reply
* Re: Getting rid of symlinks in .git?
From: Petr Baudis @ 2005-11-11 13:01 UTC (permalink / raw)
To: Alex Riesen; +Cc: Simon Richter, Pavel Roskin, git
In-Reply-To: <81b0412b0511110443x48415032k8ca40d999071e8a9@mail.gmail.com>
Dear diary, on Fri, Nov 11, 2005 at 01:43:18PM CET, I got a letter
where Alex Riesen <raa.lkml@gmail.com> said that...
> It looks more like a rhetorical question of code cleanup, because
> in-file symlinks already handle all possible cases.
Another example recently mentioned is detecting current branch over
HTTP, where you can't see where the HEAD's symlink heads to.
Actually, cg-fetch wouldn't handle the 'ref:' head properly. Just fixed
that.
--
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: Strange merge conflicts against earlier merge.
From: Petr Baudis @ 2005-11-11 13:12 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: Martin Langhoff, Git Mailing List
In-Reply-To: <20051111114511.GQ30496@pasky.or.cz>
Dear diary, on Fri, Nov 11, 2005 at 12:45:11PM CET, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> I guess I really don't want to do that, but instead choose one of the
> bases. Hmm. Well, I suppose it's as good as anything to leave this
> decision on the user. Kind of:
>
> if [ $(wc -l merge-bases) -ge 1 ]; then
> echo "Multiple merge bases, please select one by the -b parameter:" >&2
> cat merge-bases
> echo -n "The most conservative base (but likely a lot of conflicts):" >&2
> while true; do
> git-merge-base --all $(cat merge-bases) >merge-bases~
> mv merge-bases~ merge-bases
> [ $(wc -l merge-bases) -eq 1 ] && break
> done
> cat merge-bases
> exit 1
> fi
I just did something in this style. Since I'm unable to get the
repository, could someone please test it?
I'll try to come up with some automated testcase later.
--
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
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