* Re: The criss-cross merge case
From: Daniel Barkalow @ 2005-04-27 23:32 UTC (permalink / raw)
To: Bram Cohen; +Cc: git
In-Reply-To: <Pine.LNX.4.44.0504271254120.4678-100000@wax.eds.org>
On Wed, 27 Apr 2005, Bram Cohen wrote:
> The way Git handles this currently is very bad, because it forces the
> common ancestor to be from the same snapshot across all files, so this
> problem will happen if the modifications are made even in different files,
> not just different lines within the same file. That could be improved
> greatly by finding an LCA for each file individually, which is what
> Monotone does.
The git core is perfectly sufficient for getting all LCAs or
per-file best LCAs; merge-base doesn't bother, currently, because the
deficiencies of "merge" (a.k.a. diff3) are worse than the issues with
chosing a suboptimal LCA.
My plan is to implement multi-file diff and merge with a suffix tree-based
algorithm, and then revisit the history stuff once we have a merger that
can do sensible things with this information.
Note that the present very bad merger is actually seems to be sufficient
for the Linux kernel, where patches from different sides of a merge are
generally either unrelated or are identical, and, otherwise, they tend to
be true conflicts where people fixed the same bug independantly in
different ways.
> Darcs, Codeville, and all the Arch descendants have better merge
> algorithms which don't have to pick a single common ancestor.
I've been looking at Darcs (which seems to have a good method, although I
think the underlying diff isn't great), and Codeville still doesn't have
any documentation. Arch's method is strictly weaker than 3-way merge, and
generates more rejects (not even conflicts) in my experience than even
CVS.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Linus Torvalds @ 2005-04-27 23:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Luck, Tony, git
In-Reply-To: <20050427225821.GI22956@pasky.ji.cz>
On Thu, 28 Apr 2005, Petr Baudis wrote:
>
> Fixed and pushed out.
It looks like you only did the fix for the pure "just update to the
version at the other end" case.
So if you actually end up doing a merge, it still leaves all the old files
(that the merge may have removed from the tree) around. Or did I miss
something?
Linus
^ permalink raw reply
* Re: A shortcoming of the git repo format
From: Daniel Barkalow @ 2005-04-27 23:50 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <426FF8C4.8080809@zytor.com>
On Wed, 27 Apr 2005, H. Peter Anvin wrote:
> One can simply say "we don't do that"; finding an unknown tag is always
> a fatal error. That means the format is more brittle, but brittle does
> mean it breaks as opposed to getting deformed in some, potentially
> undesirable way.
If you find an object with an unknown tag, you can't do much with it
anyway, even if it has a format that matches generic rules. Sure, you
could trace reachability through it, but that's only helpful for a couple
of generic programs (fsck and pull), and those programs ought to
additionally have some clue about what's going on if they're going to act
appropriately.
On the other hand, it is probably true that programs should be able to
deal abstractly with new tags if built with a libgit that supports them,
but that's something that we can arrange a bit later.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: I'm missing isofs.h
From: Petr Baudis @ 2005-04-27 23:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20050426214338.32e9ac27.akpm@osdl.org>
Dear diary, on Wed, Apr 27, 2005 at 06:43:38AM CEST, I got a letter
where Andrew Morton <akpm@osdl.org> told me that...
> In a current tree, using git-pasky-0.7:
>
> bix:/usr/src/git26> cat .git/tags/v2.6.12-rc3
> a2755a80f40e5794ddc20e00f781af9d6320fafb
> bix:/usr/src/git26> git diff -r v2.6.12-rc3|grep isofs.h
> +#include "isofs.h"
> #include "zisofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> #include "zisofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
> +#include "isofs.h"
>
>
> That diff should have included the addition of the new isofs.h, but it
> isn't there.
Ouch.
Well, using -r v2.6.12-rc3: is a workable workaround, but this is a
problem. With the trailing :, you are diffing against your latest
commit, whilst without the trailing :, you are diffing against your
working tree. ;-)
The problem is in how the latter is implemented:
export GIT_INDEX_FILE=$(mktemp -t gitdiff.XXXXXX)
cp .git/index $GIT_INDEX_FILE
read-tree -m $(tree-id "$id1")
update-cache --refresh
tree=$(tree-id "$id1")
diff-cache -r -z $tree | xargs -0 cg-Xdiffdo ...
So, we are recording our adds to the index cache, but here we use a
different one with the adds are not recorded - so diff-cache won't catch
them.
So I fixed this by doing diff-cache --cached and updating the tmp index
by the +- entries. Pushed out, 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: [PATCH] cg-mkpatch: Show diffstat before the patch
From: Petr Baudis @ 2005-04-27 23:55 UTC (permalink / raw)
To: git
In-Reply-To: <20050426225855.GA28560@diku.dk>
Dear diary, on Wed, Apr 27, 2005 at 12:58:55AM CEST, I got a letter
where Jonas Fonseca <fonseca@diku.dk> told me that...
> Show diffstat before the patch.
>
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
I think you should first check by which(1) or something whether you have
diffstat. Piling up dependencies like this is pretty annoying.
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: A shortcoming of the git repo format
From: H. Peter Anvin @ 2005-04-27 23:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <Pine.LNX.4.21.0504271939100.30848-100000@iabervon.org>
Daniel Barkalow wrote:
>
> If you find an object with an unknown tag, you can't do much with it
> anyway, even if it has a format that matches generic rules. Sure, you
> could trace reachability through it, but that's only helpful for a couple
> of generic programs (fsck and pull), and those programs ought to
> additionally have some clue about what's going on if they're going to act
> appropriately.
>
> On the other hand, it is probably true that programs should be able to
> deal abstractly with new tags if built with a libgit that supports them,
> but that's something that we can arrange a bit later.
>
> -Daniel
There are a fair number of tools one may want that deal with reachability.
-hpa
^ permalink raw reply
* Re: [PATCH] cg-mkpatch: Show diffstat before the patch
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2005-04-28 0:07 UTC (permalink / raw)
To: fonseca; +Cc: pasky, git
In-Reply-To: <20050426225855.GA28560@diku.dk>
In article <20050426225855.GA28560@diku.dk> (at Wed, 27 Apr 2005 00:58:55 +0200), Jonas Fonseca <fonseca@diku.dk> says:
> Show diffstat before the patch.
We do not always need to generate diffstat.
Please add -s option or something to prepend diffstat.
Thanks.
--yoshfuji
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Petr Baudis @ 2005-04-28 0:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luck, Tony, git
In-Reply-To: <Pine.LNX.4.58.0504271632060.18901@ppc970.osdl.org>
Dear diary, on Thu, Apr 28, 2005 at 01:36:19AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Thu, 28 Apr 2005, Petr Baudis wrote:
> >
> > Fixed and pushed out.
>
> It looks like you only did the fix for the pure "just update to the
> version at the other end" case.
>
> So if you actually end up doing a merge, it still leaves all the old files
> (that the merge may have removed from the tree) around. Or did I miss
> something?
Hmm, doesn't the three-way read-tree -m take care of that? Then it
should hit
#
# deleted in one and unchanged in the other
#
"$1.$1" | "$1$1.")
#echo "Removing $4"
rm -f -- "$4"; update-cache --remove -- "$4"
exit 0
;;
in cg-Xmergefile.
--
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: [PATCH] cg-mkpatch: Show diffstat before the patch
From: Petr Baudis @ 2005-04-28 0:16 UTC (permalink / raw)
To: YOSHIFUJI Hideaki / ?$B5HF#1QL@; +Cc: fonseca, git
In-Reply-To: <20050428.090702.23236031.yoshfuji@linux-ipv6.org>
Dear diary, on Thu, Apr 28, 2005 at 02:07:02AM CEST, I got a letter
where "YOSHIFUJI Hideaki / ?$B5HF#1QL@" <yoshfuji@linux-ipv6.org> told me that...
> In article <20050426225855.GA28560@diku.dk> (at Wed, 27 Apr 2005 00:58:55 +0200), Jonas Fonseca <fonseca@diku.dk> says:
>
> > Show diffstat before the patch.
>
> We do not always need to generate diffstat.
> Please add -s option or something to prepend diffstat.
> Thanks.
Actually, I've been thinking about something like -s, but as in "short",
which would skip this --- part altogether.
--
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: I'm missing isofs.h
From: Linus Torvalds @ 2005-04-28 0:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: Andrew Morton, git
In-Reply-To: <20050427235115.GN22956@pasky.ji.cz>
On Thu, 28 Apr 2005, Petr Baudis wrote:
>
> without the trailing :, you are diffing against your
> working tree. ;-)
>
> The problem is in how the latter is implemented:
>
> export GIT_INDEX_FILE=$(mktemp -t gitdiff.XXXXXX)
> cp .git/index $GIT_INDEX_FILE
> read-tree -m $(tree-id "$id1")
> update-cache --refresh
> tree=$(tree-id "$id1")
> diff-cache -r -z $tree | xargs -0 cg-Xdiffdo ...
>
> So, we are recording our adds to the index cache, but here we use a
> different one with the adds are not recorded - so diff-cache won't catch
> them.
Umm.
Why do you create the new index file in the first place?
If you're diffing against the current working tree, you should just use
your current index file, no?
And to get the difference between an old tree and the current working
tree, you should just need to do
diff-cache -r -z $tree
and you're done.
In other words, that temporary index file really isn't needed in the
"diff-cache" world. It can diff the current index against _any_ old tree.
And together with Junio's stuff from today, you can literally just do
diff-cache -p $tree
and you're done - it diffs any release "$tree" against the current state.
And if you want to diff against the current head (rather than current
working state), a simple
diff-tree -p $tree $(cat .git/HEAD)
should do it.
Linus
^ permalink raw reply
* Re: git pull on ia64 linux tree
From: Linus Torvalds @ 2005-04-28 0:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: Luck, Tony, git
In-Reply-To: <20050428000729.GT22956@pasky.ji.cz>
On Thu, 28 Apr 2005, Petr Baudis wrote:
>
> Hmm, doesn't the three-way read-tree -m take care of that? Then it
> should hit
Yes, you're right, I didn't think about the fact that the helper script
actually does the checkout for the clashing files it merges.
(Which is not really nice, because it means that some files get updated
and others don't, depending on how they were merged, but whatever..)
Linus
^ permalink raw reply
* Cogito nit: cg-update should default to "origin".
From: David A. Wheeler @ 2005-04-28 0:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050427235115.GN22956@pasky.ji.cz>
Minor nit on Cogito: I think cg-update should default to "origin",
not the head, if you leave it unspecified. Instead, add an
option flag to specify the HEAD. The origin seems (to me)
to be a MUCH more common situation (and thus the better default).
--- David A. Wheeler
^ permalink raw reply
* Re: I'm missing isofs.h
From: Petr Baudis @ 2005-04-28 0:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, git
In-Reply-To: <Pine.LNX.4.58.0504271708550.18901@ppc970.osdl.org>
Dear diary, on Thu, Apr 28, 2005 at 02:19:07AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> And to get the difference between an old tree and the current working
> tree, you should just need to do
>
> diff-cache -r -z $tree
>
> and you're done.
>
> In other words, that temporary index file really isn't needed in the
> "diff-cache" world. It can diff the current index against _any_ old tree.
Oops, you are of course right. This was a stupid leftover from the
pre-diff-cache days, and since then I never looked at this code from
sufficient distance to see it. ;-)
> And together with Junio's stuff from today, you can literally just do
>
> diff-cache -p $tree
>
> and you're done - it diffs any release "$tree" against the current state.
Actually, I can't; the patch generator is not on par with mine yet.
It does not show modes and does not indicate file adds/removals by
/dev/null - basically, I need something cg-patch can eat (and it should
be backwards compatible). I think throwing the sha1 hashes away will not
harm; I got used to the Index: field and === marker, but I don't care if
I loose it.
--
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: git pull on ia64 linux tree
From: Petr Baudis @ 2005-04-28 0:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Luck, Tony, git
In-Reply-To: <Pine.LNX.4.58.0504271719380.18901@ppc970.osdl.org>
Dear diary, on Thu, Apr 28, 2005 at 02:21:19AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Thu, 28 Apr 2005, Petr Baudis wrote:
> >
> > Hmm, doesn't the three-way read-tree -m take care of that? Then it
> > should hit
>
> Yes, you're right, I didn't think about the fact that the helper script
> actually does the checkout for the clashing files it merges.
>
> (Which is not really nice, because it means that some files get updated
> and others don't, depending on how they were merged, but whatever..)
We always do checkout-cache -f -a after we do merge-cache, so it should
end up in a consistent state.
--
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: A shortcoming of the git repo format
From: David A. Wheeler @ 2005-04-28 0:45 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0504271352110.18901@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Wed, 27 Apr 2005, H. Peter Anvin wrote:
>
>>I know that. However, is that going to be true for all versions of the
>>repository format over all time? If so, the repository format is brittle.
>
> I agree, it's brittle by design, exactly because I think it's very
> important not to allow any variations.
In the short term, not allowing any variations is probably a
good thing, it'll winnow out mistakes. Creating a format that
COULD change in the future is, however, a very good way of avoiding
getting boxed into a corner if it turns out a mistake has been made.
> HOWEVER, that's where "convert-cache" comes in. Any one particular format
> may be brittle, but if we accept that, and just say "we can upgrade by
> converting the cache", then we should be ok. IOW, we can change from one
> brittle format with 160-bit SHA1 names to _another_ brittle format with
> 256-bit SHA1 (or other) names.
There's a disadvantage to that, unfortunately: invalidating signatures.
Yes, you can get people to re-sign their stuff... assuming you can
find them & convince them to do it (ha!). More than likely,
you'll lose signatures that way. Probably not your TOP priority,
but there are advantages to being able to go back & years later
SHOW that someone really did sign something.
In the long run, I'd really like to see (at least) signed commits,
and that those signatures would "stick around" cleanly into the future.
"Breaks" can be handled other ways, but it is DEFINITELY a pain,
and an avoidable one.
--- David A. Wheeler
^ permalink raw reply
* Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-28 0:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Bram Cohen, git
In-Reply-To: <Pine.LNX.4.58.0504261522340.18901@ppc970.osdl.org>
Dear diary, on Wed, Apr 27, 2005 at 12:25:58AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> 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.
Did you (or any other kernel developer reading this) actually try the
Codeville merge? (I admit I didn't get time to do anything real with it
yet.) SCM people keep praising it (as basically the best (at least
open-source) merge out there), so it would be interesting to compare
that with the actual real-world experience with it on the kernel.
> 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.
I think SVN is just irrelevant here - it is a completely different
league. The contenders here are probably Codeville, Monotone and perhaps
GNU Arch offsprings.
--
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: The criss-cross merge case
From: Tupshin Harper @ 2005-04-28 0:43 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Bram Cohen, git
In-Reply-To: <Pine.LNX.4.21.0504271854240.30848-100000@iabervon.org>
Daniel Barkalow wrote:
>I've been looking at Darcs (which seems to have a good method, although I
>think the underlying diff isn't great), and Codeville still doesn't have
>any documentation. Arch's method is strictly weaker than 3-way merge, and
>generates more rejects (not even conflicts) in my experience than even
>CVS.
>
> -Daniel
>
>
Can you clarify what you mean by darcs' underlying diff not being that
great? It seems to function pretty much identically to gnu diff. In what
way would you want the underlying diff to be improved?
-Tupshin
^ permalink raw reply
* Re: A shortcoming of the git repo format
From: David Lang @ 2005-04-28 0:46 UTC (permalink / raw)
To: David A. Wheeler; +Cc: Linus Torvalds, H. Peter Anvin, Git Mailing List
In-Reply-To: <4270320D.5090708@dwheeler.com>
On Wed, 27 Apr 2005, David A. Wheeler wrote:
> Linus Torvalds wrote:
>>
>> On Wed, 27 Apr 2005, H. Peter Anvin wrote:
>>
>>> I know that. However, is that going to be true for all versions of the
>>> repository format over all time? If so, the repository format is brittle.
<<SNIP>>
>> HOWEVER, that's where "convert-cache" comes in. Any one particular format
>> may be brittle, but if we accept that, and just say "we can upgrade by
>> converting the cache", then we should be ok. IOW, we can change from one
>> brittle format with 160-bit SHA1 names to _another_ brittle format with
>> 256-bit SHA1 (or other) names.
>
> There's a disadvantage to that, unfortunately: invalidating signatures.
> Yes, you can get people to re-sign their stuff... assuming you can
> find them & convince them to do it (ha!). More than likely,
> you'll lose signatures that way. Probably not your TOP priority,
> but there are advantages to being able to go back & years later
> SHOW that someone really did sign something.
all you have to do is to make sure that convert-cache doesn't loose any
data and you can always convert back (through as many steps as needed) to
check signatures.
no matter what you do, if you change the thing that's being signed the
signature is worthless, it doesn't matter if you change it in a flexible
or a brittle way, it's different. the brittle approach actually makes it
easier to go backwards as you KNOW exactly what it needs to be, there's no
possiblity that a later tag was there, but being ignored (except for the
signature)
> In the long run, I'd really like to see (at least) signed commits,
> and that those signatures would "stick around" cleanly into the future.
> "Breaks" can be handled other ways, but it is DEFINITELY a pain,
> and an avoidable one.
>
> --- David A. Wheeler
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: Cogito Tutorial If It Helps
From: Benjamin Herrenschmidt @ 2005-04-28 0:48 UTC (permalink / raw)
To: James Purser; +Cc: git
In-Reply-To: <1114548747.3083.1.camel@kryten>
On Wed, 2005-04-27 at 06:52 +1000, James Purser wrote:
> 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
Hrm... this tutorial is exactly like cogito's own readme as far as I'm
concerned : it just makes things even more confusing to me. I must be
really stupid, I should stick to hacking the kernel and not try to use
userland tools :)
Anyway, can you explain what it is all about this branch thing ?
I don't understand why in hell you would want linux-2.6 to be a branch
of cogito itself ...
Ben.
^ permalink raw reply
* Re: Cogito Tutorial If It Helps
From: Benjamin Herrenschmidt @ 2005-04-28 0:51 UTC (permalink / raw)
To: James Purser; +Cc: git
In-Reply-To: <1114649337.7112.208.camel@gaston>
On Thu, 2005-04-28 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2005-04-27 at 06:52 +1000, James Purser wrote:
> > 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
>
> Hrm... this tutorial is exactly like cogito's own readme as far as I'm
> concerned : it just makes things even more confusing to me. I must be
> really stupid, I should stick to hacking the kernel and not try to use
> userland tools :)
>
> Anyway, can you explain what it is all about this branch thing ?
>
> I don't understand why in hell you would want linux-2.6 to be a branch
> of cogito itself ...
Forget it, I must be lacking caffeine this morning, you are adding linus
git, not linux-2.6 as a branch which makes a lot more sense... sorry
for the noise.
Ben.
^ permalink raw reply
* Re: Cogito nit: cg-update should default to "origin".
From: Petr Baudis @ 2005-04-28 0:53 UTC (permalink / raw)
To: David A. Wheeler; +Cc: git
In-Reply-To: <42702F20.3050200@dwheeler.com>
Dear diary, on Thu, Apr 28, 2005 at 02:32:32AM CEST, I got a letter
where "David A. Wheeler" <dwheeler@dwheeler.com> told me that...
> Minor nit on Cogito: I think cg-update should default to "origin",
> not the head, if you leave it unspecified. Instead, add an
> option flag to specify the HEAD. The origin seems (to me)
> to be a MUCH more common situation (and thus the better default).
Actually, I wasn't too happy with the current update-to-HEAD special
case. Sure, it's similar to SVN, but SVN's concepts are totally
different here, and this special case wart (which does really do
something entirely different than normal cg-update) is one of the
Cogito-related shadows in my mind. What about moving this special case
to something like
cg-restore
and changing the defaulting of update and pull back to 'origin'? I think
people do this cg-update without arguments so seldom that changing this
now shouldn't hurt much, right?
Another thing is to UI-wise maintain clear difference between cg-cancel
and cg-restore. Do you think the names are distinctive enough? Any
better naming ideas?
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: A shortcoming of the git repo format
From: Linus Torvalds @ 2005-04-28 0:57 UTC (permalink / raw)
To: Tom Lord; +Cc: hpa, git
In-Reply-To: <200504272049.NAA14598@emf.net>
On Wed, 27 Apr 2005, Tom Lord wrote:
>
> I think one has to understand Linus' posts as coming from the
> "head-down, steaming ahead for *MY* project cause you all suck"
> perspective and impose corresponding filters on his declarations of
> "LAW".
I'm really being very head-strong on these things, and much more so than I
normally am, because quite frankly, I see "git" as a very different
project from Linux.
(Which is not to say that I'm not opinionated even normally, but I'm
normally a bit more open to listen to other people ;)
There's two huge differences between git and Linux, and I'm really sorry
if they make me act as an asshole, but they are important to me:
- with Linux, lots of people know what the "right thing" is, because the
UNIX mindset has really been a kind of "social background" that has
been around for long enough that it has institutionalized knowledge
about what an OS is supposed to do.
This means that in 99% of all technical discussions about the kernel,
people are already coming at the problem roughly from the same
stand-point. It's not _universally_ true, but I really think that the
institutionalized (but not always conscious) philosophy of UNIX is what
has made it a lot easier to talk about almost all kernel issues,
because people have generally the same expectations of what is "good".
Doing development is a lot about communication. Writing code in many
ways is secondary - it's much more important to try to make sure that
everybody knows what the goals are, because the _real_ pain in
development ends up being not the coding, but the much more fundamental
disagreements that happen when people really have totally different
expectations of what the end result is going to be.
SCM's don't have this. Quite the reverse. I see 30 years of "CVS" being
the common language for a lot of people, and the fact is, most of the
people on this mailing list probably never _really_ used BK, and do not
really understand very deeply about how the distributed model actually
ends up workign in _practice_.
I think a lot of people understand it intellectually, but I really do
think that we're lackign the kind of "institutionalized" knowledge
where people understand things at a much more visceral level.
- With Linux, I never had something I needed to get _done_. Even when I
started, it was just for fun, and by the time others joined in, the
system already did much more than I initially envisioned, so everything
was really "gravy".
With git, this isn't the case. The _only_ reason I started git in the
first place is that I knew better than pretty much anybody else what my
needs were, and I was forced to act on them because nothing out there
really solved the problem for me.
In other words: I _know_ that I've been unpleasant. I'm sorry about that,
but I am trying to explain _why_ I'm being an asshole about things, more
so than I usually am.
I'm not actually all that interested in SCM's. I'd have been much happier
if I never had to start doing git in the first place. But circumstances
not only forced me to do my own, it also so happens that I don't believe
that there are many people around that have ever really _seen_ what my
kind of development requirements are.
What does that boil down to? It means, for example, that to me it doesn't
matter one _whit_ if you've been doing SCM's for the last thirty years,
and you can do xdelta algorithms in your sleep.
Quite the reverse: such a person "knows" a lot of things, but I'm pretty
damn sure that such a person has _never_ actually worked on a system that
works the way the kernel development does, which means that most of the
things that person "knows" are things that may need to be un-learnt.
And because I don't actually _care_ about SCM's, and only care about
getting to the point where I (once more) don't have to even think about
the SCM that I use for the kernel, I also don't have much incentive to
worry about CM models that may well be very valid outside of kernel work.
See? When it comes to my Linux work, I'm very inclusive. Linux already
does everything _I_ need it to do, so in many ways, all that really
motivates me to improve it are really about other peoples needs, and as
such, I'm really really interested in what _other_ people want. I still
say "no, that's now how we do things", but that's much less contentious.
In contrast, with git, I'm totally uninterested in anything that doesn't
make my kernel work go faster or more smoothly, and does so _today_. Which
makes me a cantancerous old bastard, and bit the heads off anybody who
isn't focused on that one thing.
And I really _am_ sorry. I don't actually _like_ being nasty about these
things. But when it comes to git, I have one motivation, and one
motivation only, and being nice about it isn't going to help.
The good news? I actually think my needs are very basic. Once gits gets to
the point where it does what I need it to do, I don't really have any
motivation to say "this is how we do it" any more. And I think we're
actually getting to that point fairly soon. That's not saying git is
"done", any less than Linux was "done" in 1992. It's just that at that
point I don't have any reason to be a nasty control freak any more.
In fact, I don't see myself even maintaining the project, especially since
there seem to be others that are more motivated to do so than I am. Then
I'll just go back into my dark kernel cave, and hopefully I don't have to
come out again for a while.
But for now, the _only_ point of git is as a kernel maintenance tool.
There are tons of other SCM systems that are probably better for other
projects, so if git is "just another SCM project", then git is totally
pointless. So for now, the absolutely _only_ thing that matters for git
design (as far as I'm concerned) is "how well does it suit Linus".
Linus
^ permalink raw reply
* Re: git add / update-cache --add fails.
From: Paul Jackson @ 2005-04-28 1:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: ecashin, git
In-Reply-To: <20050427173059.GE22956@pasky.ji.cz>
Petr wrote:
> fd = open(path, O_RDONLY);
> if (fd < 0) {
> + fprintf(stderr, "update-cache Error: %s\n", strerror(errno));
It's usually a good idea to indicate which system call you were
attempting in such error messages, and if handy, the key argument.
Just the errno might not mean much:
> + fprintf(stderr, "update-cache open(%s) failed: %s\n", path, strerror(errno));
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@engr.sgi.com> 1.650.933.1373, 1.925.600.0401
^ permalink raw reply
* Re: [PATCH] add a diff-files command
From: Nicolas Pitre @ 2005-04-28 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vr7gvevpv.fsf@assigned-by-dhcp.cox.net>
On Wed, 27 Apr 2005, Junio C Hamano wrote:
> >>>>> "NP" == Nicolas Pitre <nico@cam.org> writes:
>
> NP> It also has the ability to accept exclude file patterns with -x and even
> NP> a file containing a list of patterns to exclude with -X. This is
> NP> especially useful to use the famous dontdiff file when looking for
> NP> uncommitted files in a compiled kernel tree.
>
> I think show-diff with path restriction (if restriction is
> simple), or piping its output to grep or filterdiff (otherwise),
> would be enough to do what you do here, so personally I doubt
> this new command is even useful that much.
First, show-diff doesn't handle files in the work tree which are not
listed in the cache.
Have you ever looked at the dontdiff file? You can get a sample of it
from http://www.moses.uklinux.net/patches/dontdiff to give you an idea.
Using grep or filterdiff is really backward in that case since out of
all the junk that might appear in the output about 98% will be filtered
away in most useful cases, which is rather inefficient.
Path restriction is inclusive, while the exclude list is, well,
exclusive. They serves separate purposes. So trust me it _is_ pretty
damn useful, unless you always run "make clean" on your kernel tree
before checking for potentially uncommitted files then recompile
everything afterwards which is a hassle.
> That said, I have a couple of comments. Other than these I do
> not see anything majorly wrong (although I haven't even compiled
> it yet ;-).
>
> NP> +static const char *diff_files_usage = "diff-files [-a] [-c] [-d] [-o] [-p | -z]"
> NP> + " [-x <pattern>] [-X <file>] [paths...]";
> NP> +
>
> If you are trying to do something similar to show-files by these
> -[acdo] flags, matching these flags in both commands would be
> less confusing to the users and script writers. Either make
> diff-files take fully spelled --others etc. that show-files
> takes, or submit a patch for show-files to match these shorter
> ones as well. I personally prefer the latter.
Agreed.
> NP> +/*
> NP> + * Read a directory tree. We currently ignore anything but
> NP> + * directories and regular files. That's because git doesn't
> NP> + * handle them at all yet. Maybe that will change some day.
> NP> + *
> NP> + * Also, we currently ignore all names starting with a dot.
> NP> + * That likely will not change.
> NP> + */
>
> For that logic, instead of doing de->d_name[0] == '.' and things
> yourself, I'd rather see you lift verify_path() function from
> update-cache.c into common library and call it.
Sure, but actually I'd prefer for that to be a separate patch since it's
a tangential issue that might affect show-files as well.
Nicolas
^ permalink raw reply
* Re: git add / update-cache --add fails.
From: Petr Baudis @ 2005-04-28 1:05 UTC (permalink / raw)
To: Paul Jackson; +Cc: ecashin, git
In-Reply-To: <20050427180143.0447ceaa.pj@sgi.com>
Dear diary, on Thu, Apr 28, 2005 at 03:01:43AM CEST, I got a letter
where Paul Jackson <pj@sgi.com> told me that...
> Petr wrote:
> > fd = open(path, O_RDONLY);
> > if (fd < 0) {
> > + fprintf(stderr, "update-cache Error: %s\n", strerror(errno));
>
> It's usually a good idea to indicate which system call you were
> attempting in such error messages, and if handy, the key argument.
> Just the errno might not mean much:
>
> > + fprintf(stderr, "update-cache open(%s) failed: %s\n", path, strerror(errno));
Sorry for being unclear, I meant that I did an analogous change in my
tree before; it is actually a little different:
if (errno == ENOENT) {
if (allow_remove)
return remove_file_from_cache(path);
}
return error("open(\"%s\"): %s", path, strerror(errno));
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ 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