* Re: fix t5000-tar-tree.sh when $TAR isn't set
From: Alex Riesen @ 2005-11-08 15:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0511081250020.2649@wbgn013.biozentrum.uni-wuerzburg.de>
On 11/8/05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > $TAR isn't set everywhere. Provide a default (tar)
>
> You run "sh t5000*" in t/, right? Usually, TAR is set in t/Makefile (that
> is why it Just Works in the normal case). Note that you can -- instead of
> your patch -- run "TAR=tar sh t5000*".
Oh, I see... I did "make -C t" to avoid recompilation tests (this is
unbearably slow on the system Not To Be Named). Maybe put such
variables in the separate makefile and include it?
^ permalink raw reply
* Re: Notes on http-push
From: Nick Hengeveld @ 2005-11-08 15:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy83zjz0e.fsf@assigned-by-dhcp.cox.net>
On Tue, Nov 08, 2005 at 12:59:45AM -0800, Junio C Hamano wrote:
> Pushing git commit history into SVN server --- this must be a
> sick joke ;-). Can you pull over http from there?
I rather felt like I'd violated some law of nature or something. Pulls
work fine from there - it's feasible to put an entire GIT repo behind a
DAV server, assuming there's a way to run all the non-push/pull git
commands. If you're using mod_dav_fs, that could just mean having
shell/filesystem access to the server. If you're using mod_dav_svn, it
could either mean using something like Davfs2 or putting intelligence
into the git commands to handle GIT_DIR=http://dav.serv.er/path by using
HTTP GET/PUT instead of read/write system calls.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* [RFC/PATCH] Make git-recursive the default strategy for git-pull.
From: Junio C Hamano @ 2005-11-08 16:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511071629270.3247@g5.osdl.org>
This does two things:
- It changes the hardcoded default merge strategy for two-head
git-pull from resolve to recursive.
- .git/config file acquires two configuration items.
pull.twohead names the strategy for two-head case, and
pull.octopus names the strategy for octopus merge.
IOW you are paranoid, you can have the following lines in your
.git/config file and keep using git-merge-resolve when pulling
one remote:
[pull]
twohead = resolve
OTOH, you can say this:
[pull]
twohead = resolve
twohead = recursive
to try quicker resolve first, and when it fails, fall back to
recursive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> Hmm. True. The _really_ trivial in-index case triggers for me pretty
> often, but I haven't done any statistics. It might be only 50% of the
> time.
>...
> It's certainly an option to just do what I just did, namely use the
> default one until it breaks, and then just do "git reset --hard" and re-do
> the pull with "-s recursive". A bit sad, and it would be good to have
> coverage on the recursive strategy..
Hopefully something like this would make people aware of
recursive and give it a wider coverage and chance to mature.
git-pull.sh | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
applies-to: 75922cf23cc070e2d5220d961a8f645f1bc8bb60
3acc20beaf0df9ce11a1b7aabf8c9dc7507a9b44
diff --git a/git-pull.sh b/git-pull.sh
index 2358af6..3b875ad 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -79,10 +79,22 @@ case "$merge_head" in
exit 0
;;
?*' '?*)
- strategy_default_args='-s octopus'
+ var=`git-var -l | sed -ne 's/^pull\.octopus=/-s /p'`
+ if test '' = "$var"
+ then
+ strategy_default_args='-s octopus'
+ else
+ strategy_default_args=$var
+ fi
;;
*)
- strategy_default_args='-s resolve'
+ var=`git-var -l | sed -ne 's/^pull\.twohead=/-s /p'`
+ if test '' = "$var"
+ then
+ strategy_default_args='-s recursive'
+ else
+ strategy_default_args=$var
+ fi
;;
esac
---
0.99.9.GIT
^ permalink raw reply related
* Re: git-pull.sh's bad mode
From: Junio C Hamano @ 2005-11-08 16:25 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <E1EZUK2-0005EG-56@jdl.com>
Jon Loeliger <jdl@freescale.com> writes:
> Public apology and brown paper bag. My patch
> accidentally twiddled the mode on git-pull.sh:
>
> mode change 100755 => 100644 git-pull.sh
No need for worrying things like this. Mistakes and accidents
happen.
Makefile installs git-pull with executable bit set anyway, so it
really does not matter.
-jc
^ permalink raw reply
* Re: git-pull.sh's bad mode
From: Petr Baudis @ 2005-11-08 16:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7v4q6njecr.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Nov 08, 2005 at 05:25:56PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> Jon Loeliger <jdl@freescale.com> writes:
>
> > Public apology and brown paper bag. My patch
> > accidentally twiddled the mode on git-pull.sh:
> >
> > mode change 100755 => 100644 git-pull.sh
>
> No need for worrying things like this. Mistakes and accidents
> happen.
>
> Makefile installs git-pull with executable bit set anyway, so it
> really does not matter.
But it should definitely be fixed. E.g. I actually personally use (for
Cogito development) git-core which I never make install (I have
system-wide git-core installation which is just whatever is the latest
version Gentoo ships, and I use that for non-Cogito development).
It would be painful if this mode of usage wouldn't be supported.
--
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
* Build report on RPMs for git and cogito
From: Horst von Brand @ 2005-11-08 16:36 UTC (permalink / raw)
To: git
Just built and installed the current versions here on Fedora rawhide,
x86_64. No troubles.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* Re: [PATCH] Cogito: Support for implicit remote branches in cloned repositories
From: Josef Weidendorfer @ 2005-11-08 16:46 UTC (permalink / raw)
To: git
In-Reply-To: <20051107232122.GZ1431@pasky.or.cz>
On Tuesday 08 November 2005 00:21, Petr Baudis wrote:
> The problem is that at least Cogito defaults to the 'origin' branch when
> pulling/merging, so if you'll have 'origin/master' instead of 'origin',
> I will have to hack that around. So it's not _just_ a convention but
> something reflected in some code as well.
The new git-clone simply would not produce an "origin" branch at all, and I do
not think Cogito expects that a repository always has an "origin" branch.
The following fact (Git's default clone setup until now, Cogito's clone setup)
"origin" tracks remote "master", to be merged into local "master"
has to be stored into some configuration file, and not to be set up implicitly
as it is done currently. Then you take this setup from the configuration, and
there never would be something hardcoded, and Junios suggestion would be a
convention.
Git already stores half of this into remotes/repo: the "Pull" lines specify
which local head tracks which remote head; the same with Cogito's .git/branches.
Missing in both cases is the information that "origin" maps to the local
development head "master". More common name for this information: "origin" is
the upstream for "master".
This information is useful at least for two cases:
(1) for specifying the default action to be done on "git-pull" or "cg-update",
and (2) try to prohibit accidental bogus merges.
The default action currently is either hardcoded (Cogito) or working somehow
by luck (Git: you have to be on "master" for git-pull).
AFAIK, Cogito prohibits bogus merges by enforcing to be either on "master"
or to be in a not-mergeable state (cg-seeking).
Merge relationship is useful to be specified not only for upstream direction,
but also for branches which branched off the current head and should be
merged back (e.g. topical branches). For this, multiple branches to be
merged with "git pull" should be specifyable.
Where to put the information about default merge relation?
Both .git/remotes and .git/branches are candidates, but merge relation
also makes sense for local branches, i.e. git-branch <branch> <origbranch>
should set up to merge from <origbranch> if you are on <branch> by default.
Similarly, it should set up a relation the other way to state that it is
useful to merge from <branch> into <origbranch> (this is for (2) above).
A possiblity would be to put the merge relationship into .git/config:
[master]
merge-canditate: origin
merge-default: origin
Problem here is that head names should not appear in key names,
because key names are case insensitive :-(
A possibility would be for config keys to become case sensitive after a ":"
(of course only for toplevel keys):
[head:master]
merge-default: origin
> > - clone by default [*1*] creates .git/refs/heads/origin/*
> > heads; your "master" becomes my "origin/master".
> > Interestingly but logically, if your repository was cloned
> > from somewhere else, you would have "origin/master", which
> > would become my "origin/origin/master".
>
> This loses the pretty nice property that 'origin' refers to the HEAD
> branch of the remote repository, no matter how is it called (well, it is
> nice as long as the remote repository doesn't _switch_ the HEAD to some
> non-superset branch; but repositories you're cloning from shouldn't do
> that). So you should either have origin/HEAD locally, or make the
> 'master' branch more "socially canonical".
Ah, so git-clone sets up a local development head for the remote HEAD, which
does not always have to be "master", right? This information would be available
by the proposed storing of merge relationship: local "master" wants get merges
from remote HEAD to be updated.
Josef
^ permalink raw reply
* GIT 0.99.9f
From: Junio C Hamano @ 2005-11-08 16:46 UTC (permalink / raw)
To: git
This is more like a "current snapshot" rather than "contains
important fixes -- please update".
Much of the changes are documentation fixes, but there are two
new toys to play with.
- git-push is now aware of push over DAV (Nick)
- git-cvs suite has 'exportcommit' to play git commits back at
CVS (Martin).
---
Alex Riesen:
ls-files and read-tree need core.filemode
Fredrik Kuivinen:
merge-recursive: Only print relevant rename messages
Johannes Schindelin:
Small bugfixes for http-push.c
Jon Loeliger:
Refactored merge options into separate merge-options.txt.
Add bug isolation howto, scraped from Linus.
Add --tags documentation, scraped from JC mail.
Use consistent shell prompts and example style.
Junio C Hamano:
Documentation: talk about guts of merge in tutorial.
Recover dropped +x bit from git-pull.sh by accident.
Do not fail on hierarchical tagnames.
Documentation: asciidoc formatting fix for git-cvsexportcommit doc.
Fix documentation dependency generation.
Ignore more generated files.
Documentation: fix dependency generation.
Tutorial: do not use 'git resolve'.
Debian: packaging updates.
git-am: do not lose already edited final-commit when resuming.
GIT 0.99.9f
Kai Ruemmler:
Documentation update: use git branch -d foo where applicable
Martin Langhoff:
Introducing: git-cvsexportcommit
Nick Hengeveld:
Make http-push smarter about creating remote dirs
Add support for git-http-push to git-push script
^ permalink raw reply
* Regarding: Debian: packaging updates.
From: Johannes Schindelin @ 2005-11-08 17:08 UTC (permalink / raw)
To: git
Hi,
I notice that there are files like "git-core.files". Wouldn't it be better
to generate them from the Makefile? The same mechanism could then be used
to make RPMs from the same Makefile.
Ciao,
Dscho
^ permalink raw reply
* Regarding: git-lost+found
From: Johannes Schindelin @ 2005-11-08 17:13 UTC (permalink / raw)
To: git
Hi,
I think this is a valuable addition to the "Now what?" part of git.
However, I'd like to see the results stored into .git/refs/lost+found/
rather than .git/lost+found/, so that it is possible to inspect them
easily with gitk or git-show-branch.
Just my sue tents,
Dscho
^ permalink raw reply
* Re: Check for differents trees
From: Junio C Hamano @ 2005-11-08 17:13 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20051106190249.39384.qmail@web26314.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> as you said, the speed is almost the same but your way is clearly better.
How often do you do this --diff-filter=AD and why?
If it is a common enough operation, we could add a specific hack
to stop feeding the diff machinery with unwanted kind of changes
when diff-filter is set and none of -B/-C/-M are used. That
_might_ speed things up for you.
^ permalink raw reply
* Re: [PATCH] Make the templates building a bit more silent
From: Junio C Hamano @ 2005-11-08 17:16 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051108094931.23012.6654.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> My guess is that it is some debugging leftover, actually.
> This patch kills it.
Thanks.
^ permalink raw reply
* Re: Regarding: git-lost+found
From: Petr Baudis @ 2005-11-08 17:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511081811080.18406@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Tue, Nov 08, 2005 at 06:13:06PM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> told me that...
> I think this is a valuable addition to the "Now what?" part of git.
> However, I'd like to see the results stored into .git/refs/lost+found/
> rather than .git/lost+found/, so that it is possible to inspect them
> easily with gitk or git-show-branch.
What is it supposed to be?
--
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: Regarding: git-lost+found
From: Petr Baudis @ 2005-11-08 17:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20051108174524.GD1431@pasky.or.cz>
> > I think this is a valuable addition to the "Now what?" part of git.
> > However, I'd like to see the results stored into .git/refs/lost+found/
> > rather than .git/lost+found/, so that it is possible to inspect them
> > easily with gitk or git-show-branch.
>
> What is it supposed to be?
Sorry for the noise - /lost.found/ found some matches (see the "what
after 0.98" mail from Junio). (Still, it would be helpful to put a
reference to your mail.)
--
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: ls-files and read-tree need core.filemode
From: Linus Torvalds @ 2005-11-08 18:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, git
In-Reply-To: <7vacgfldry.fsf@assigned-by-dhcp.cox.net>
On Tue, 8 Nov 2005, Junio C Hamano wrote:
>
> Attachments are a bit cumbersome to quote but otherwise OK, at
> least for me. Linus never admits it, but I am hoping that he is
> having a bit easier time applying e-mailed patches ever since
> rudimentally MIME attachment handling was added.
Actually, the MIME attachment support in git means that I have to remove
the "Content-Type: .. boundary: " line too when editing emails.
I do all my patch validation in mbox format (which is why when you look at
commit dates, you'll generally see a second or less between commits when I
actually apply a mbox series), and the MIME format makes emails totally
unreadable.
So I refuse to have anything to do with attachments and MIME types not
because my tools couldn't apply the patches, but because I can't go
through the patches manually sanely with them.
So I can do plain/text attachments, but they inevitably mean that I just
have to edit the damn mailbox to make sense of it. Anything else (like
base64-encoding or similar) I just refuse to touch.
Linus
^ permalink raw reply
* Re: Regarding: Debian: packaging updates.
From: Simon Richter @ 2005-11-08 18:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511081806320.18374@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 721 bytes --]
Hi,
Johannes Schindelin wrote:
> I notice that there are files like "git-core.files". Wouldn't it be better
> to generate them from the Makefile? The same mechanism could then be used
> to make RPMs from the same Makefile.
I'm currently in the process of working my way through the current
packaging, and there is quite a lot I am going to simplify. As the
Debian build scripts do not expect this file to be autogenerated, I
think it would be counterproductive to do so; it can seriously affect
reproducability of builds.
(actually, I would like to ask not to fix things in the Debian packaging
that aren't broken, as providing an upgrade path for earlier versions
will be a lot less painful then)
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: fix t5000-tar-tree.sh when $TAR isn't set
From: Junio C Hamano @ 2005-11-08 19:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511081250020.2649@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> You run "sh t5000*" in t/, right? Usually, TAR is set in t/Makefile (that
> is why it Just Works in the normal case). Note that you can -- instead of
> your patch -- run "TAR=tar sh t5000*".
Yes, but "cd t && sh ./t5000-*.sh" should work by itself.
^ permalink raw reply
* Re: make tests ignorable with "make -i"
From: Junio C Hamano @ 2005-11-08 19:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0511080151v69bc4578we093eaa751ee4bac@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> ... (Or to ignore plainly
> uninteresting situations because of the testing being done on say...
> cygwin ;)
Could you tell us which ones break on Cygwin?
^ permalink raw reply
* Re: git-pull.sh's bad mode
From: Junio C Hamano @ 2005-11-08 19:30 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Loeliger, git
In-Reply-To: <20051108163546.GC1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> Makefile installs git-pull with executable bit set anyway, so it
>> really does not matter.
>
> But it should definitely be fixed. E.g. I actually personally use (for
> Cogito development) git-core which I never make install (I have
> system-wide git-core installation which is just whatever is the latest
> version Gentoo ships, and I use that for non-Cogito development).
> It would be painful if this mode of usage wouldn't be supported.
You could perhaps do "make" without install and set PATH to
include the source directory (you need to do a bit more if we
ever update templates/ directory and you would want to try it).
The point is that git-pull was generated with +x from
git-pull.sh, and the mode bits of git-pull.sh (source) does not
matter anymore. It used to matter back when we called them
git-*-script but not these days.
^ permalink raw reply
* Re: Regarding: Debian: packaging updates.
From: Junio C Hamano @ 2005-11-08 19:30 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <4370EEF7.4060708@debian.org>
Simon Richter <sjr@debian.org> writes:
> I'm currently in the process of working my way through the current
> packaging, and there is quite a lot I am going to simplify. As the
> Debian build scripts do not expect this file to be autogenerated, I
> think it would be counterproductive to do so; it can seriously affect
> reproducability of builds.
>
> (actually, I would like to ask not to fix things in the Debian packaging
> that aren't broken, as providing an upgrade path for earlier versions
> will be a lot less painful then)
Noted. I just barely speak enough deb to build binary packages,
and the source packaging and upload procedure are something I've
never bothered to learn, so I won't be touching that area from
now on.
Since you have debian.org e-mail address, perhaps you can feed
me patches to debian/ area and deb: rule in the main Makefile?
I was asked to use dpkg-buildpackage/dpkg-genchanges and produce
the *.changes file as well by somebody who maintains his own
private apt source. I'd appreciate if you can take care of it
when you update the Makefile deb: rule as well, if the *.changes
file request makes sense to you.
^ permalink raw reply
* Re: Regarding: Debian: packaging updates.
From: Simon Richter @ 2005-11-08 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbr0vey42.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 620 bytes --]
Hi,
Junio C Hamano wrote:
> Since you have debian.org e-mail address, perhaps you can feed
> me patches to debian/ area and deb: rule in the main Makefile?
Sure. I have also talked this over with a few people and am going to
make official uploads occasionally.
> I'd appreciate if you can take care of it
> when you update the Makefile deb: rule as well, if the *.changes
> file request makes sense to you.
Not really. *.changes files make only sense if you are running archive
maintenance software, and the need to do that should go away with
reasonably up-to-date packages being in the archive RSN.
Simon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]
^ permalink raw reply
* Re: git-pull.sh's bad mode
From: Petr Baudis @ 2005-11-08 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vhdaney4d.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Tue, Nov 08, 2005 at 08:30:10PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> You could perhaps do "make" without install and set PATH to
> include the source directory (you need to do a bit more if we
> ever update templates/ directory and you would want to try it).
That's what I do.
> The point is that git-pull was generated with +x from
> git-pull.sh, and the mode bits of git-pull.sh (source) does not
> matter anymore. It used to matter back when we called them
> git-*-script but not these days.
Ah so. I see. Well, still useful when I'm changing something and I'm
lazy to remake after each change. ;-)
Either way, it should be consistent for all the scripts - either +x or
-x (but yes, definitely not a brown paper bag thing :).
--
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
* Diff between the non-head git work dir and non-git kernel sources
From: lamikr @ 2005-11-08 20:54 UTC (permalink / raw)
To: git
Hi
I am sorry if this a newbie question, but I have tried to read howtos
from the web without finding clear documentation or howto to following
kind of problem.
I have checked out the omap git tree with command
git-clone rsync://source.mvista.com/git/linux-omap-2.6.git
linux-omap-2.6
and now I am obviously having the omap kernel head in the linux-omap-2.6
working directory + hidden ".git" with commit history. In addition I
have my own "non git" development tree that is made on top of
traditional kernel snapshots. I however know that the sources in this
dir reflects to state in git history when following patch was committed
http://source.mvista.com/git/gitweb.cgi?p=linux-omap-2.6.git;a=commitdiff;h=d24aff0bd3e788d69a45a9d1b1eecda88d847a41
I would now like to revert the sources in git working dir to state that
was after this d24aff0bd3e788d69a45a9d1b1eecda88d847a41 commit
and then make the diff between that kernel source version and my non-git
source version and I am now trying to find out what is the "correct" way
of doing this.
1) If understood the documentation correctly I could move the working
dir to contain the state after
d24aff0bd3e788d69a45a9d1b1eecda88d847a41 commit in a following way
a) open qgit and mark correct commit with "make tag mytag" command
b) change the files in working dir to be same than during the "mytag"
commit time by using command git checkout -f mytag
Are there simpler method for doing this that uses commit id
d24aff0bd3e788d69a45a9d1b1eecda88d847a41 directly without need to make
tag or branch?
2) Does git-diff support making the diff between git's working dir and
"my non" git kernel source dir.
Or should I just just use normal diff and order that to ignore .git dir
and .gitignore files?
Mika
^ permalink raw reply
* Re: Comments on recursive merge..
From: Fredrik Kuivinen @ 2005-11-08 21:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Junio C Hamano, git, Fredrik Kuivinen
In-Reply-To: <Pine.LNX.4.63.0511081254520.2649@wbgn013.biozentrum.uni-wuerzburg.de>
On Tue, Nov 08, 2005 at 12:58:50PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 7 Nov 2005, Linus Torvalds wrote:
>
> > Is the recursive thing noticeably slower for the "easy" cases (ie things
> > that the old regular resolve strategy does well)?
>
> IIRC recursive does nothing else than recursively merging the merge-bases
> (granted, in a clever way). So if there is only one merge-base, the only
> slow-down would be the startup of python (which is probably worth it,
> anyway).
>
I haven't done any real measurements but my feeling is that the
recursive strategy is at least not very much slower than the resolve
strategy.
In the single-common-ancestor case I can think of the following things
which may make a difference speed wise:
* The recursive strategy is written in Python
* The code for finding common ancestors is also written in Python and
is probably a bit slower than git-merge-base.
* git-diff-tree -M --diff-filter=R <common ancestor> <branch> is
executed twice, once for each branch.
On the positive side the code which corresponds to git-merge-one-file
in the git-resolve case is also written in python, we can therefore
avoid some forks and execs.
> > It's certainly an option to just do what I just did, namely use the
> > default one until it breaks, and then just do "git reset --hard" and re-do
> > the pull with "-s recursive". A bit sad, and it would be good to have
> > coverage on the recursive strategy..
>
> We already have a fallback list: after really-trivial, try automatic, ...,
> try resolve. Why not just add recursive? So, if even resolve failed, just
> try once more, with recursive.
>
I don't think this is a very good idea for two reasons. The first one
is that there are some merge scenarios involving renames which should
be conflicts but are cleanly merged by git-resolve.
The second reason is that with the fall back list the recursive
strategy will only be used in the strange corner cases and will thus
not get nearly the same amount of testing it would get if it was the
first choice (or directly after the really-trivial merge).
- Fredrik
^ permalink raw reply
* Re: Expected Behavior?
From: Fredrik Kuivinen @ 2005-11-08 21:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jon Loeliger, git
In-Reply-To: <7vwtjjllw4.fsf@assigned-by-dhcp.cox.net>
On Mon, Nov 07, 2005 at 10:00:11PM -0800, Junio C Hamano wrote:
> Jon Loeliger <jdl@freescale.com> writes:
>
> > That is, after the merge, file3 appears to have simply kept
> > the contents of the current, master branch. Why wasn't the
> > dev branch represented here?
> >
> > I _almost_ think I get it, and then *poof*...
>
> Automerge completely punted for this path, and at this point, it
> is still unmerged:
>
> ------------
> $ git ls-files --unmerged
> 100644 c4da0eb.... 2 file3
> 100644 fbc2aa4.... 3 file3
> ------------
>
> Three-way "git-read-tree -m -u O A B" (O is for old, A is ours
> and B is hers) puts O in stage1, A in stage2 and B in stage3.
> This path did not exist in O so we only have them in stage2 and
> stage3. You could compare the stages like this:
>
Jon: You could try to this merge with the recursive merge strategy
(git merge -s recursive 'merge message' master dev) If you do, you
_should_ get something like:
CONFLICT (add/add): File file3 added non-identically in both
branches. Adding as file3_master and file3_dev instead.
You will then end up with file3_master and file3_dev in your working
tree, which corresponds to file3 in the master branch and file3 in the
dev branch, respectively.
- Fredrik
^ 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