* 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
* Re: [ANNOUNCE] Cogito-0.8 (former git-pasky, big changes!)
From: Petr Baudis @ 2005-04-26 20:43 UTC (permalink / raw)
To: Philip Pokorny; +Cc: git, linux-kernel
In-Reply-To: <426DE78A.3050508@mindspring.com>
Dear diary, on Tue, Apr 26, 2005 at 09:02:34AM CEST, I got a letter
where Philip Pokorny <ppokorny@mindspring.com> told me that...
> Petr Baudis wrote:
>
> >the history changed again (hopefully the
> >last time?) because of fixing dates of some old commits.
> >
>
> Looks like the git-pasky-0.7 tags (and friends) are now dead links. For
> example:
>
> [philip@xray cogito]$ cg-mkpatch git-pasky-0.7:HEAD
> .git/objects/c8/3b95297c2a6336c2007548f909769e0862b509: No such file or
> directory
> fatal: cat-file c83b95297c2a6336c2007548f909769e0862b509: bad file
> Invalid id: c83b95297c2a6336c2007548f909769e0862b509
Oops. Good catch, fixed. I actually just iterated cg-log. ;-)
--
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: Tom Lord @ 2005-04-26 20:39 UTC (permalink / raw)
To: bram; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504261301520.4678-100000@wax.eds.org>
> What I'd really like to hear is some explanation of why git is
> reimplementing all of this stuff from scratch.
Whatever Linus' reasons, it's not a bad exercise and it does help
robustify the kernel project to roll its own. Not that he seems to be
doing *this* part especially well or anything, but that doesn't matter
from the perspective of the good reasons to do it.
It doesn't matter much -- get stuff into git and people can layer on
that pretty gently. The low layers of git are a common idea but
context and Linus' nifty code make this instance of the idea a bit
of a gem.
> please remember that I've spent years
> thinking about merge algorithms
I'm surprised we haven't met sooner. If we did and I forgot, sorry.
-t
^ permalink raw reply
* Re: : Networking
From: Bram Cohen @ 2005-04-26 20:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, pasky, davem, git
In-Reply-To: <Pine.LNX.4.58.0504261310120.18901@ppc970.osdl.org>
Linus Torvalds wrote:
> On Tue, 26 Apr 2005, Andrew Morton wrote:
> >
> > With bk I was resolving that by just smashing the patches on top of each
> > other, ignoring the rejects and refreshing the topmost patch. That
> > approach actually resolved this linus-vs-davem dupe as well.
>
> Oh, wow. I didn't realize that your scripts were quite _that_ stupid, and
> didn't actually take advantage of any automatic merges at all.
>
> If so, git should trivially do everything that BK ever did for you. Which
> is not saying a lot ;)
No version control system will do a particularly good job of merging
content which got passed around outside of the system. They can be made to
sort-of handle some simple cases well, but fundamentally too much
information is getting dropped.
The solution is to get everyone using the same version control system,
which is actually quite a workable solution if (a) the version control
system in question is quite nice, and (b) there isn't some deep political
reason why many people will never agree to use it.
-Bram
^ permalink raw reply
* Re: [RFC] diff-cache buglet
From: Junio C Hamano @ 2005-04-26 20:34 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0504261207380.18901@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Tue, 26 Apr 2005, Junio C Hamano wrote:
>>
>> We should just fix "remove-merge-entries" and call that
>> unconditionally before the read-tree is called. Once it is
>> fixed, we need to think about how to show this stage
>> information but that should be a separate discussion.
LT> I just thought that _if_ you wanted the unmerged parts to show up, then
LT> the "1//filename.c" thing might be acceptable. Personally, I just think
LT> diff-cache is pretty nonsensical with unmerged files,
I agree to what you said here. We are not interested in the
unmerged files in the original GIT_INDEX_FILE at all.
However, remember that "unmerged" entries diff_cache() function
sees are from the tree you are comparing against, either your
GIT_INDEX_FILE (with --cached) or your working tree (without).
Currently I suspect the behaviour of diff-cache without --cached
flag may be broken. Don't we need to check cached_only before
or inside of the first two if() statements in diff_cache()? For
a path that appears in the tree you are comparing against (i.e.
stage 1 entries):
- if GIT_INDEX_FILE does not have it but the working tree does,
it would still say "deleted".
- if GIT_INDEX_FILE does have it, the comparison goes against
that entry, not against the working tree.
Similarly for entries that are not in the stage 1, the code ends
up comparing only the dircache entries and never goes to the
filesystem.
Here is a proposed fix. When running without --cached,
diff_cache function really goes to the filesystem if the stage 0
entry in GIT_INDEX_FILE does not match what is in the working
tree for these cases.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-cache.c | 40 ++++++++++++++++++++++++++++++++++++----
1 files changed, 36 insertions(+), 4 deletions(-)
./jit-snap -v 3:6
# - 04/26 12:25 Fix agreed with Linus.
# + 04/26 13:26 Proposed fix.
--- k/diff-cache.c
+++ l/diff-cache.c
@@ -10,6 +10,19 @@ static void show_file(const char *prefix
sha1_to_hex(ce->sha1), ce->name, line_termination);
}
+/* A file *may* have been added to the working tree */
+static void show_possible_local_add(struct cache_entry *new)
+{
+ static unsigned char no_sha1[20];
+ struct stat st;
+ if (stat(new->name, &st) < 0)
+ return; /* no, working tree does not have one. */
+ if (cache_match_stat(new, &st))
+ return show_file("+", new);
+
+ printf("+%o\t%s\t%s\t%s%c", st.st_mode, "blob",
+ sha1_to_hex(no_sha1), new->name, line_termination);
+}
static int show_modified(struct cache_entry *old, struct cache_entry *new)
{
unsigned int mode = ntohl(new->ce_mode), oldmode;
@@ -29,6 +42,8 @@ static int show_modified(struct cache_en
mode = st.st_mode;
sha1 = no_sha1;
}
+ else if (old == new)
+ return 0;
}
oldmode = ntohl(old->ce_mode);
@@ -48,16 +63,33 @@ static int diff_cache(struct cache_entry
while (entries) {
struct cache_entry *ce = *ac;
- /* No matching 0-stage (current) entry? Show it as deleted */
+ /* No matching 0-stage (current) entry?
+ * Show it as deleted.
+ */
if (ce_stage(ce)) {
- show_file("-", ce);
+ /* ... well, not so fast. We may have it in the
+ * working tree and operating without --cache.
+ */
+ if (cached_only)
+ show_file("-", ce);
+ else
+ /* this is sneaky but it works. trust me. */
+ show_modified(ce, ce);
ac++;
entries--;
continue;
}
- /* No matching 1-stage (tree) entry? Show the current one as added */
+ /* No matching 1-stage (tree) entry?
+ * Show the current one as added.
+ */
if (entries == 1 || !same_name(ce, ac[1])) {
- show_file("+", ce);
+ /* ... again, we may not have that in the
+ * working tree and operating without --cache.
+ */
+ if (cached_only)
+ show_file("+", ce);
+ else
+ show_possible_local_add(ce);
ac++;
entries--;
continue;
^ 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