* Re: Full linux-2.6 history?
From: H. Peter Anvin @ 2005-04-26 22:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Thomas Gleixner, git
In-Reply-To: <20050426071723.GA15580@pasky.ji.cz>
Petr Baudis wrote:
> Hello,
>
> I would like to ask about the status of the project to export the
> linux-2.6 history from BitKeeper to GIT repository; it looked very
> hopeful about a week or two ago, but got covered in silence soon.
> Did Larry come upon you? ;-)
>
> I kept having people asking about this, so I would like to know.
>
There is a human-readable log file of the linux-2.5 repo posted on the
sourcepuller site, http://www.sf.net/projects/sourcepuller
-hpa
^ permalink raw reply
* Re: git-pasky "tutorial"
From: Benjamin Herrenschmidt @ 2005-04-26 22:42 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050426195752.GG13224@pasky.ji.cz>
> you might want to try again with cogito-0.8; I hope I simplified the
> concepts a lot.
Yup, I figured that out, thanks.
> There is no tracking, and branches are trivial - branches correspond to
> repositories. When you do cg-init <remoterepo>, you get a branch origin
> which represents the remoterepo (and gets updated when you do cg-pull or
> cg-update), you can make Cogito know of more remote repositories by
> doing cg-branch-add.
>
>
> Yes, the README sucks; but apparently it helps at least some people. ;-)
>
--
Benjamin Herrenschmidt <benh@kernel.crashing.org>
^ permalink raw reply
* Re: [PATCH] Add -r flag to show-diff for diff-cache/diff-tree like output.
From: Linus Torvalds @ 2005-04-26 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vy8b5mawy.fsf_-_@assigned-by-dhcp.cox.net>
On Tue, 26 Apr 2005, Junio C Hamano wrote:
>
> This adds a new option -r (rational) to show-diff command, to
> produce diff-cache/diff-tree compatible output.
Why not just make this the default? Who really cares about show-diff? I
see that "cg-merge" uses it, but does so with the "s" flag, just to see
whether there are any changes at all.
So why not just make "rational" the standard format, and then make
"diff-tree-helper" warn about unmerged ("U") files?
As far as I can tell, that is really what _everybody_ wants.
And calling "-r" "rational", when it means "recursive" for diff-tree and
diff-cache doesn't sound rational to me. It _is_ rational to just silently
accept it as "recursive", the same way diff-cache does.
Linus
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-26 22:30 UTC (permalink / raw)
To: Fabian Franz; +Cc: Bram Cohen, git
In-Reply-To: <200504262336.02583.FabianFranz@gmx.de>
On Tue, 26 Apr 2005, Fabian Franz wrote:
>
> Am Dienstag, 26. April 2005 23:28 schrieb Bram Cohen:
> > Now you've just gone off the deep end. This is an apples-to-apples
> > comparison. Please accept one of thee following two statements:
> >
> > (a) Git doesn't do merging, and none of the related new tools around it do
> > merging.
> >
> > (b) Codeville merge (sans rename functionality) would be superior for the
> > merging which will be done.
>
> I have one very humble question:
>
> Why don't you write and contribute some code for git to do good merging?
Don't bother. Bram doesn't know what he's talking about.
Linus
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.8 (former git-pasky, big changes!)
From: Pavel Machek @ 2005-04-26 22:21 UTC (permalink / raw)
To: pasky, git
In-Reply-To: <20050426032422.GQ13467@pasky.ji.cz>
Hi!
> here goes Cogito-0.8, my SCMish layer over Linus Torvald's git tree
> history tracker. This package was formerly called git-pasky, however
> this release brings big changes. The usage is significantly different,
> as well as some basic concepts; the history changed again (hopefully the
> last time?) because of fixing dates of some old commits. The .git/
> directory layout changed too.
>
> Upgrading through pull is possible, but rather difficult and requires
> some intimacy with both git, git-pasky and Cogito. So probably the best
> way to go is to just get cogito-0.8 tarball at
>
> http://www.kernel.org/pub/software/scm/cogito/
>
> or
>
> ftp://ftp.kernel.org/pub/software/scm/cogito/
>
> build and install it, and do
>
> cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
>
>
>
> Yes, this is a huge change. No, I don't expect any further changes of
> similar scale. I think the new interface is significantly simpler _and_
> cleaner than the old one.
It seems to need libcurl-dev... installed.
Error handling could certainly be improved:
pavel@amd:/data/l/cogito$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
./cg-clone: line 22: cg-init: command not found
pavel@amd:/data/l/cogito$ PATH=/data/l/cogito:$PATH
pavel@amd:/data/l/cogito$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
cg-clone: cogito/ already exists
Pavel
--
Boycott Kodak -- for their patent abuse against Java.
^ permalink raw reply
* [PATCH] Add -r flag to show-diff for diff-cache/diff-tree like output.
From: Junio C Hamano @ 2005-04-26 22:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504251832480.18901@ppc970.osdl.org>
This adds a new option -r (rational) to show-diff command, to
produce diff-cache/diff-tree compatible output. When -r is
specified, show-diff simply skips unmerged entries. This makes
the following thee behave quite similarly:
show-diff -r -z
diff-cache -r -z [--cached] <tree-or-commit>
diff-tree -r -z <tree-or-commit> <tree-or-commit>
When -z (machine readable) is used, it implies rational. In
addition to terminating each output record with NUL instead of
'\n', machine readable format also may output lines of the form:
U filename <NUL>
to show that there are unmerged entries, once per path (this is
to help scripts so that they do not have to run "sed | uniq" on
output from "show-files --unmerged", just to get the list of
unmerged files).
The earlier machine readable output format had another form:
X filename <NUL>
to show deleted files. This has been removed; these paths now
give the diff-cache compatible "-<mode> <sha1> <path>" output.
I resisted the temptation to change those tabs between columns
into spaces. Linus, what do you think? I do not think Cogito
cares and changing them into spaces would certainly make them
more readable by humans.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
show-diff.c | 44 +++++++++++++++++++++++++++++++++-----------
1 files changed, 33 insertions(+), 11 deletions(-)
--- k/show-diff.c
+++ l/show-diff.c
@@ -6,7 +6,8 @@
#include "cache.h"
#include "diff.h"
-static const char *show_diff_usage = "show-diff [-q] [-s] [-z] [paths...]";
+static const char *show_diff_usage =
+"show-diff [-q] [-s] [-r] [-z] [paths...]";
static int matches_pathspec(struct cache_entry *ce, char **spec, int cnt)
{
@@ -23,10 +24,17 @@ static int matches_pathspec(struct cache
return 0;
}
+static void show_file(int pfx, struct cache_entry *ce, int NUL_terminate)
+{
+ printf("%c%o\t%s\t%s\t%s%c", pfx, ntohl(ce->ce_mode), "blob",
+ sha1_to_hex(ce->sha1), ce->name, NUL_terminate ? 0 : '\n');
+}
+
int main(int argc, char **argv)
{
int silent = 0;
int silent_on_nonexisting_files = 0;
+ int rational = 0;
int machine_readable = 0;
int reverse = 0;
int entries = read_cache();
@@ -39,8 +47,12 @@ int main(int argc, char **argv)
silent_on_nonexisting_files = silent = 1;
else if (!strcmp(argv[1], "-q"))
silent_on_nonexisting_files = 1;
+ else if (!strcmp(argv[1], "-r"))
+ /* diff-cache and diff-tree compatible */
+ rational = 1;
else if (!strcmp(argv[1], "-z"))
- machine_readable = 1;
+ /* machine readable implies rational */
+ rational = machine_readable = 1;
else
usage(show_diff_usage);
argv++; argc--;
@@ -64,11 +76,16 @@ int main(int argc, char **argv)
continue;
if (ce_stage(ce)) {
+ /* machine-readble == rational in most cases,
+ * but rational does not care about unmerged.
+ * In some cases we want the list of unmerged
+ * files and running sort -u on show-files -z
+ * --unmerged for that is a pain.
+ */
if (machine_readable)
printf("U %s%c", ce->name, 0);
- else
- printf("%s: Unmerged\n",
- ce->name);
+ else if (!rational)
+ printf("%s: unmerged\n", ce->name);
while (i < entries &&
!strcmp(ce->name, active_cache[i]->name))
i++;
@@ -79,8 +96,10 @@ int main(int argc, char **argv)
if (stat(ce->name, &st) < 0) {
if (errno == ENOENT && silent_on_nonexisting_files)
continue;
- if (machine_readable)
- printf("X %s%c", ce->name, 0);
+ if (rational) {
+ /* deleted */
+ show_file('-', ce, machine_readable);
+ }
else {
printf("%s: %s\n", ce->name, strerror(errno));
if (errno == ENOENT)
@@ -91,10 +110,13 @@ int main(int argc, char **argv)
changed = cache_match_stat(ce, &st);
if (!changed)
continue;
- if (!machine_readable)
- printf("%s: %s\n", ce->name, sha1_to_hex(ce->sha1));
- else {
- printf("%s %s%c", sha1_to_hex(ce->sha1), ce->name, 0);
+ if (rational) {
+ static char *no_sha1_hex =
+ "0000000000000000000000000000000000000000";
+ printf("*%o->%o\t%s\t%s->%s\t%s%c",
+ ntohl(ce->ce_mode), st.st_mode,
+ "blob", sha1_to_hex(ce->sha1), no_sha1_hex,
+ ce->name, (machine_readable ? 0 : '\n'));
continue;
}
if (silent)
^ permalink raw reply
* Re: [PATCH] cg-export to tarball
From: Rene Scharfe @ 2005-04-26 22:24 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: Petr Baudis, git
In-Reply-To: <20050426202014.GJ13224@pasky.ji.cz>
Petr Baudis schrieb:
> Dear diary, on Tue, Apr 26, 2005 at 09:12:46AM CEST, I got a letter
> where "Joshua T. Corbin" <jcorbin@wunjo.org> told me that...
>
>> The following patch to cg-export will simlpy create a tarball if
>> the argument ends in .tar.gz, .tar.bz2, or .tar.
>>
>> Signed-off-by; Joshua T. Corbin <jcorbin@wunjo.org>
>
>
> What about cooperating with Rene Scharfe and using his tar-tree? I
> didn't actually try it yet (not even look at the code so far), it'd
> be cool if someone would give it some review and testing.
Yes, this looks like a job for tar-tree. You could do something like this:
destbasename=${destdir##*/}
case "$destdir" in
*.tar)
tar-tree $id "${destbasename%.tar}" > "$destdir"
;;
*.tgz)
tar-tree $id "${destbasename%.tgz}" | gzip -9 > "$destdir"
;;
# *.tar.gz, *.tar.bz2, ...
*)
mkdir -p "$destdir" || die "cannot create $destdir"
export GIT_INDEX_FILE="$destdir/.git-index"
read-tree $id
checkout-cache "--prefix=$destdir/" -a
rm "$GIT_INDEX_FILE"
;;
esac
The second parameter to tar-tree is an optional prefix for all paths
inside the archive (official kernel tarballs always have linux-2.x.xx as
a prefix). It makes some sense to set this value to the archive
filename, "cg-export linux-2.6.12-rc3.tar.bz2" would than work as expected.
What do you think? If you like it I'll cook up a patch later unless you
beat me to it.
Thanks,
Rene
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-26 22:25 UTC (permalink / raw)
To: Bram Cohen; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504261400570.4678-100000@wax.eds.org>
On Tue, 26 Apr 2005, Bram Cohen wrote:
>
> So you think that a system which supports snapshots and history but has no
> merging functionality whatsoever is the right thing?
You haven't looked at git, have you?
Git already merges better than _any_ open-source SCM out there. It just
does it so effortlessly that you didn't even realize it does that.
Today I've done four (count them) fully automated merges on the kernel
tree: serial, networking, usb and arm.
And they took a fraction of a second (plus the download of the new
objects, which is the real cost).
This is something that SVN _still_ cannot do, for example.
Linus
^ permalink raw reply
* [PATCH] cg-add checks to see if file exists
From: Rhys Hardwick @ 2005-04-26 22:17 UTC (permalink / raw)
To: git
Hi,
This is a patch to check if the file being added exists, and if not, issues a
warning and dies.
Rhys
Signed-off-by: Rhys Hardwick <rhys@rhyshardwick.co.uk
Index: cg-add
===================================================================
--- 6159f313b10f0cfcdfedd63d6fb044029fe46aaa/cg-add (mode:100755
sha1:8ba5351a4c7e28a577ea1aa4afa1078c54e9bccc)
+++ uncommitted/cg-add (mode:100755)
@@ -10,4 +10,10 @@
[ "$1" ] || die "usage: cg-add FILE..."
+if [ -f "$1" ]; then
+ echo "Adding file $1"
+else
+ die "$1 does not exist"
+fi
+
update-cache --add -- "$@"
^ permalink raw reply
* Re: unseeking?
From: Petr Baudis @ 2005-04-26 21:53 UTC (permalink / raw)
To: Zack Brown; +Cc: Daniel Barkalow, git
In-Reply-To: <20050426214819.GA14899@tumblerings.org>
Dear diary, on Tue, Apr 26, 2005 at 11:48:19PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Tue, Apr 26, 2005 at 10:28:05PM +0200, Petr Baudis wrote:
> > Dear diary, on Tue, Apr 26, 2005 at 12:28:33AM CEST, I got a letter
> > where Zack Brown <zbrown@tumblerings.org> told me that...
> > > So, I did 'git patch pasky:this', and got the following. Is this an appropriate
> > > way to submit a patch? BTW, the 'truckload' fix I tried to change back by
> > > editing the README again, and committing the change; but the git patch command
> > > still shows the change.
> >
> > Because it just exports individual patches. Use git diff (cg-diff) if
> > you want to get the cummulative diff.
> >
> > Could you please sign off your patch?
>
> Spelling fixes.
>
> Signed-off-by: Zack Brown <zbrown@tumblerings.org>
Thanks, applied. (master.kernel.org is now down, so it'll take a while
before I will be able to push it out.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: unseeking?
From: Zack Brown @ 2005-04-26 21:48 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Barkalow, git
In-Reply-To: <20050426202805.GL13224@pasky.ji.cz>
On Tue, Apr 26, 2005 at 10:28:05PM +0200, Petr Baudis wrote:
> Dear diary, on Tue, Apr 26, 2005 at 12:28:33AM CEST, I got a letter
> where Zack Brown <zbrown@tumblerings.org> told me that...
> > So, I did 'git patch pasky:this', and got the following. Is this an appropriate
> > way to submit a patch? BTW, the 'truckload' fix I tried to change back by
> > editing the README again, and committing the change; but the git patch command
> > still shows the change.
>
> Because it just exports individual patches. Use git diff (cg-diff) if
> you want to get the cummulative diff.
>
> Could you please sign off your patch?
Spelling fixes.
Signed-off-by: Zack Brown <zbrown@tumblerings.org>
Index: README
===================================================================
--- 6159f313b10f0cfcdfedd63d6fb044029fe46aaa/README (mode:100644
sha1:ae3c78a0f1927b9d92d788a0cd0b75d5fc3fc338)
+++ dbfe56b949992411184480136defe850a9f135cd/README (mode:100644
sha1:bbf1920e29cc74dccec1271d57628244c87c6fb8)
@@ -233,7 +233,7 @@
In particular, since the blob is entirely defined by its data,
if two files in a directory tree (or in multiple different
versions of the repository) have the same contents, they will
- share the same blob object. The object is toally independent
+ share the same blob object. The object is totally independent
of it's location in the directory tree, and renaming a file does
not change the object that file is associated with in any way.
@@ -288,7 +288,7 @@
actually have any relationship with the result, for example.
Note on changesets: unlike real SCM's, changesets do not contain
- rename information or file mode chane information. All of that
+ rename information or file mode change information. All of that
is implicit in the trees involved (the result tree, and the
result trees of the parents), and describing that makes no sense
in this idiotic file manager.
@@ -456,7 +456,7 @@
changes in your working directory (ie "update-cache").
However, if you decide to jump to a new version, or check out
- somebody elses version, or just restore a previous tree, you'd
+ somebody else's version, or just restore a previous tree, you'd
populate your index file with read-tree, and then you need to
check out the result with
--
Zack Brown
^ permalink raw reply
* Re: [PATCH] cogito - split out cg-X* to prefix/lib/cogito
From: Chris Wright @ 2005-04-26 21:44 UTC (permalink / raw)
To: Joshua T. Corbin; +Cc: git
In-Reply-To: <200504260053.33506.jcorbin@wunjo.org>
(BTW, this patch was linewrapped)
* Joshua T. Corbin (jcorbin@wunjo.org) wrote:
> The following patch does the following:
> * Change the Makefile to install all cg-X* to $(prefix)/lib/cogito
> * Modify all cg-* to use this lib prefix.
Hmm, I agree with the intent of this patch (place extraneous bits out of
/usr/bin namespace), although I'm not sure it's the best method. It
winds up only putting three files there (with cg- prefixes as well).
I've left it out of the rpm build for now.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
^ permalink raw reply
* Re: Cogito Tutorial If It Helps
From: Petr Baudis @ 2005-04-26 21:40 UTC (permalink / raw)
To: James Purser; +Cc: git
In-Reply-To: <1114551403.3083.3.camel@kryten>
Dear diary, on Tue, Apr 26, 2005 at 11:36:43PM CEST, I got a letter
where James Purser <purserj@ksit.dynalias.com> told me that...
> On Wed, 2005-04-27 at 07:18, Petr Baudis wrote:
> > cg-merge is _not_ like doing cg-diff | cg-patch - that's a dangerous
> > thought, and not true at all. cg-diff | cg-patch will just apply the
> > given diff to your working directory, but it won't record any merging
> > metadata, will often get it very wrong, and you will get to all sorts of
> > other troubles. Just always use cg-merge. And probably pass it -b only
> > when you know what are you doing.
>
> Thanks for that, I've changed it a little to point out that cg-patch
> should really only be used for small single file patches.
No, you've missed the point. It isn't the size of the change what
matters - cg-patch should handle even huge patches (mostly) fine. What
matters is that you just did was not merge. It was applying some patch
to your working tree, but not merging branches.
So after doing cg-diff | cg-patch several times, you have your working
tree full of huge local changes (making it impossible to sensibly
cg-merge) and your last commit happenned long ago. Or you commit the
cg-patch results, but your commits are wrong, since they don't carry the
appropriate merge information.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Fabian Franz @ 2005-04-26 21:36 UTC (permalink / raw)
To: Bram Cohen; +Cc: git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.44.0504261400570.4678-100000@wax.eds.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am Dienstag, 26. April 2005 23:28 schrieb Bram Cohen:
> Now you've just gone off the deep end. This is an apples-to-apples
> comparison. Please accept one of thee following two statements:
>
> (a) Git doesn't do merging, and none of the related new tools around it do
> merging.
>
> (b) Codeville merge (sans rename functionality) would be superior for the
> merging which will be done.
I have one very humble question:
Why don't you write and contribute some code for git to do good merging?
This would resolve all your problems.
I think the "magic-merge" command is quite exchangable and if your way works
good and is compatible, then people will automatically start using that.
cu
Fabian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFCbrRdI0lSH7CXz7MRAkS4AJ9JEka71M0Zc6cizXhrYpHiKHhL0gCcD/3Q
j+UnPU/cXafGjGG6Bt9mZE8=
=IYk0
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: Cogito Tutorial If It Helps
From: James Purser @ 2005-04-26 21:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050426211834.GO13224@pasky.ji.cz>
On Wed, 2005-04-27 at 07:18, Petr Baudis wrote:
> Dear diary, on Tue, Apr 26, 2005 at 10:52:27PM CEST, I got a letter
> where James Purser <purserj@ksit.dynalias.com> told me that...
> > I reworked the previous tutorial to take in the changes in the scripts.
> > Will make this a series of tutorials to cover all aspects. Any
> > suggestions or hints or spelling corrections would be most welcome.
> >
> > http://ksit.dynalias.com/articles.php?s_id=46&art_id=41
>
> Thanks for writing that! :-)
>
> I'd vote for describing the cg-update right near cg-pull, or perhaps
> even before cg-update, as the primary method; I think it's commonly what
> people really want to do when they do cg-pull anyway.
>
> cg-merge is _not_ like doing cg-diff | cg-patch - that's a dangerous
> thought, and not true at all. cg-diff | cg-patch will just apply the
> given diff to your working directory, but it won't record any merging
> metadata, will often get it very wrong, and you will get to all sorts of
> other troubles. Just always use cg-merge. And probably pass it -b only
> when you know what are you doing.
>
> Thanks,
Thanks for that, I've changed it a little to point out that cg-patch
should really only be used for small single file patches.
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Bram Cohen @ 2005-04-26 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261347520.18901@ppc970.osdl.org>
Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Bram Cohen wrote:
> >
> > Now that you're done being dismissive, could you either (a) rebut my quite
> > detailed explanation of exactly why that functionality is both a dubious
> > idea and difficult to implement, or (b) admit that you have no plans
> > whatsoever for supporting any of this stuff? You can't have it both ways.
>
> I'm absolutely not going to do it myself, you're right about that.
Now you're just being an ass. I stated, flatly, that what you're proposing
to have done (by you or whoever, for feasibility it doesn't matter which)
is not going to happen due to just plain difficulty. You obviously
disagree with me, but rather than coming out and saying so you're
pretending I didn't make that statement.
> > What I'd really like to hear is some explanation of why git is
> > reimplementing all of this stuff from scratch.
>
> Git does in ~5000 lines and two weeks of work what _I_ think is the right
> thing to do.
So you think that a system which supports snapshots and history but has no
merging functionality whatsoever is the right thing? I'm asking this
seriously. You have a magic --make-somebody-else-do-merge command, but for
everybody else the current state of things is workable as a stopgap
measure (the original plan) but very painful for anything more.
Codeville is comparable in terms of number of lines of code to Git, by the
way.
> You're welcome to disagree, but the fact is, people have whined and
> moaned about my use of BK FOR THREE YEARS without showing me any better
> alternatives.
You were happy with BitKeeper, so why should we? Monotone and Codeville
are only just about now really mature, and you aren't exactly known as a
model customer.
> So why are you complaining now, when I implement my own version in two
> weeks?
I'm trying to tell you that the amount of time between now and when a
system as nice as BitKeeper is in use by the kernel can be dramatically
reduced by either using an existing system verbatim or basing new efforts
on one.
If you think that git as it exists right now is at all comparable to
Monotone or Codeville you're completely delusional.
> > In case these concepts got conflated, I'd like to point out that Codeville
> > merge both supports renames *and* does better than three-way merge can do
> > at merging a single, non-renamed file.
>
> And I'd like to point out (again) that git doesn't actually care what
> merge strategy the user uses.
>
> Me _personally_, I want to have something that is very repeatable and
> non-clever. Something I understand _or_ tells me that it can't do it. And
> quite frankly, merging single-file history _without_ taking all the other
> files' history into account makes me go "ugh".
Now you've just gone off the deep end. This is an apples-to-apples
comparison. Please accept one of thee following two statements:
(a) Git doesn't do merging, and none of the related new tools around it do
merging.
(b) Codeville merge (sans rename functionality) would be superior for the
merging which will be done.
-Bram
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Diego Calleja @ 2005-04-26 21:26 UTC (permalink / raw)
To: Bram Cohen; +Cc: torvalds, git
In-Reply-To: <Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org>
El Tue, 26 Apr 2005 13:31:31 -0700 (PDT),
Bram Cohen <bram@bitconjurer.org> escribió:
> Even if we pretend that these are comparable features, that's far from
> clearly true. Function moves within a file occur more frequently, but a
> file rename moves *all* the functions within that file.
Renaming or moving files is _so_ rare and unusual that even not implementing
it (like CVS) is hardly a big issue. Even in the linux kernel people moved subsystems
around - OSS went from drivers/sound to /sound/oss in 2.6, and a USB subdirectory
moved too, I think.
The patch got bigger. People wasted 30 seconds more of their life because the .gz
file was bigger - who cares? If it's something it's going to happen every 5 years,
I'd rather move them like CVS does rather than wasting a single second
implementing file renaming/moving...
If something so uncommon like file renaming has been implemented, I don't see
why people shouldn't implement something really useful like the thing linus
proposes, in fact it doesn't looks like a bad idea at all (and you'd get
file renaming for free, too). Perhaps it would be hard to implement and get
right, but at least it would be _useful_.
^ permalink raw reply
* Website http://www.git-source.org
From: Denny Schierz @ 2005-04-26 21:25 UTC (permalink / raw)
To: Git
[-- Attachment #1: Type: text/plain, Size: 536 bytes --]
hi,
my name is Denny Schierz and we (at the moment four german people) want
to give you, and the community, something back. So we decided to create
a website (http://www.git-source.org). We hoping that we can help to
build a interface between the developers from git, and the users for
feedbacks, wishes, tutorials, etc.
At the moment, we're structure our ideas how to build the page (with
typo3 CMS), including:
* News
* Tutorials
* Feedback
* Changelog
* RSS Feeds
* Lynx compatible ;-)
and more
with kind regards
Denny Schierz
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 253 bytes --]
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-26 21:25 UTC (permalink / raw)
To: Bram Cohen; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261347520.18901@ppc970.osdl.org>
On Tue, 26 Apr 2005, Linus Torvalds wrote:
>
> > What I'd really like to hear is some explanation of why git is
> > reimplementing all of this stuff from scratch.
>
> Git does in ~5000 lines and two weeks of work what _I_ think is the right
> thing to do. You're welcome to disagree, but the fact is, people have
> whined and moaned about my use of BK FOR THREE YEARS without showing me
> any better alternatives.
Btw, I've also been pretty disgusted by SCM's apparently generally caring
about stuff that is totally not relevant.
For example, it seems like most SCM people think that merging is about
getting the end result of two conflicting patches right.
In my opinion, that's the _least_ important part of a merge. Maybe the
kernel is very unusual in this, but basically true _conflicts_ are not
only rare, but they tend to be things you want a human to look at
regardless.
The important part of a merge is not how it handles conflicts (which need
to be verified by a human anyway if they are at all interesting), but that
it should meld the history together right so that you have a new solid
base for future merges.
In other words, the important part is the _trivial_ part: the naming of
the parents, and keeping track of their relationship. Not the clashes.
For example, CVS gets this part totally wrong. Sure, it can merge the
contents, but it totally ignores the important part, so once you've done a
merge, you're pretty much up shit creek wrt any subsequent merges in any
other direction. All the other CVS problems pale in comparison. Renames?
Just a detail.
And it looks like 99% of SCM people seem to think that the solution to
that is to be more clever about content merges. Which misses the point
entirely.
Don't get me wrong: content merges are nice, but they are _gravy_. They
are not important. You can do them manually if you have to. What's
important is that once you _have_ done them (manually or automatically),
the system had better be able to go on, knowing that they've been done.
Linus
^ permalink raw reply
* Re: Cogito Tutorial If It Helps
From: Petr Baudis @ 2005-04-26 21:18 UTC (permalink / raw)
To: James Purser; +Cc: git
In-Reply-To: <1114548747.3083.1.camel@kryten>
Dear diary, on Tue, Apr 26, 2005 at 10:52:27PM CEST, I got a letter
where James Purser <purserj@ksit.dynalias.com> told me that...
> I reworked the previous tutorial to take in the changes in the scripts.
> Will make this a series of tutorials to cover all aspects. Any
> suggestions or hints or spelling corrections would be most welcome.
>
> http://ksit.dynalias.com/articles.php?s_id=46&art_id=41
Thanks for writing that! :-)
I'd vote for describing the cg-update right near cg-pull, or perhaps
even before cg-update, as the primary method; I think it's commonly what
people really want to do when they do cg-pull anyway.
cg-merge is _not_ like doing cg-diff | cg-patch - that's a dangerous
thought, and not true at all. cg-diff | cg-patch will just apply the
given diff to your working directory, but it won't record any merging
metadata, will often get it very wrong, and you will get to all sorts of
other troubles. Just always use cg-merge. And probably pass it -b only
when you know what are you doing.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Linus Torvalds @ 2005-04-26 21:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: Magnus Damm, mason, mike.taht, mpm, linux-kernel, git
In-Reply-To: <20050426135606.7b21a2e2.akpm@osdl.org>
On Tue, 26 Apr 2005, Andrew Morton wrote:
>
> Mounting as ext2 is a useful technique for determining whether the fs is
> getting in the way.
What's the preferred way to try to convert a root filesystem to a bigger
journal? Forcing "rootfstype=ext2" at boot and boot into single-user, and
then the appropriate magic tune2fs? Or what?
Linus
^ permalink raw reply
* Re: Mercurial 0.3 vs git benchmarks
From: Andrew Morton @ 2005-04-26 20:56 UTC (permalink / raw)
To: Magnus Damm; +Cc: mason, torvalds, mike.taht, mpm, linux-kernel, git
In-Reply-To: <aec7e5c305042609231a5d3f0@mail.gmail.com>
Magnus Damm <magnus.damm@gmail.com> wrote:
>
> My primitive guess is that it was because
> the ext3 journal became full.
The default ext3 journal size is inappropriately small, btw. Normally you
should manually make it 128M or so, rather than 32M. Unless you have a
small amount of memory and/or a large number of filesystems, in which case
there might be problems with pinned memory.
Mounting as ext2 is a useful technique for determining whether the fs is
getting in the way.
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Linus Torvalds @ 2005-04-26 20:58 UTC (permalink / raw)
To: Bram Cohen; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org>
On Tue, 26 Apr 2005, Bram Cohen wrote:
>
> Now that you're done being dismissive, could you either (a) rebut my quite
> detailed explanation of exactly why that functionality is both a dubious
> idea and difficult to implement, or (b) admit that you have no plans
> whatsoever for supporting any of this stuff? You can't have it both ways.
I'm absolutely not going to do it myself, you're right about that.
I just don't like your notion that you should support the 5% problem with
ugly hacks, and then you dismiss the 95% problem with "nothing else does
it either".
In other words, we're already merging manually for the 95%. Why do you
think the 5% is so important?
> What I'd really like to hear is some explanation of why git is
> reimplementing all of this stuff from scratch.
Git does in ~5000 lines and two weeks of work what _I_ think is the right
thing to do. You're welcome to disagree, but the fact is, people have
whined and moaned about my use of BK FOR THREE YEARS without showing me
any better alternatives.
So why are you complaining now, when I implement my own version in two
weeks?
> If someone offers you a dollar, no strings attached, do you turn them down
> because they didn't offer you ten?
"no strings attached"?
There are lots of strings attached to the "follow renames" thing. There's
30 _years_ of strings attached, and they result in people not looking at
the _interesting_ problem.
Exactly because people follow renames, they think that they have the
history of the code, but then they ignore the fact that they don't -
because it doesn't follow merging of code or splitting of code.
In other words, it's sometimes better to know that you don't know the
answer, than it is to _think_ that you know the answer.
> In case these concepts got conflated, I'd like to point out that Codeville
> merge both supports renames *and* does better than three-way merge can do
> at merging a single, non-renamed file.
And I'd like to point out (again) that git doesn't actually care what
merge strategy the user uses.
Me _personally_, I want to have something that is very repeatable and
non-clever. Something I understand _or_ tells me that it can't do it. And
quite frankly, merging single-file history _without_ taking all the other
files' history into account makes me go "ugh".
That's why I like the "we do _not_ look for 'nearer' parents on a per-file
basis", which is what this discussion started with, afaik. I think the
only original source that makes sense is the least common parent for the
whole _project_, exactly because other files have done things that may or
may not depend on the history of the file you're merging.
I (and thus git) really takes a "whole project" approach.
Linus
^ permalink raw reply
* Cogito Tutorial If It Helps
From: James Purser @ 2005-04-26 20:52 UTC (permalink / raw)
To: git
I reworked the previous tutorial to take in the changes in the scripts.
Will make this a series of tutorials to cover all aspects. Any
suggestions or hints or spelling corrections would be most welcome.
http://ksit.dynalias.com/articles.php?s_id=46&art_id=41
--
James Purser
http://ksit.dynalias.com
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Tom Lord @ 2005-04-26 20:44 UTC (permalink / raw)
To: barkalow; +Cc: torvalds, bram, git
In-Reply-To: <Pine.LNX.4.21.0504261607310.30848-100000@iabervon.org>
^ 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