* git merge
From: Petr Baudis @ 2005-04-14 22:11 UTC (permalink / raw)
To: git; +Cc: torvalds
In-Reply-To: <20050414002902.GU25711@pasky.ji.cz>
Hi,
note that in my git tree there is a git merge implementation which
does out-of-tree merges now. It is still very trivial, and basically
just does something along the lines of (symbolically written)
checkout-cache $(diff-tree)
git diff $base $mergedbranch | git apply
.. fix rejects etc ..
git commit
It seems to work, but it is only very lightly tested - it is likely
there are various tiny mistakes and typos in various unusual code paths
and other weird corners of the scripts. Testing is encouraged, and
especially patches fixing bugs you come over.
It is designed in a way to make it possible to just replace the
checkout-cache and git diff | git apply steps with the merge-tree.pl
tool when it is finished.
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: Merge with git-pasky II.
From: Christopher Li @ 2005-04-14 18:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Linus Torvalds, git
In-Reply-To: <7vll7lqlbg.fsf@assigned-by-dhcp.cox.net>
On Thu, Apr 14, 2005 at 11:12:35AM -0700, Junio C Hamano wrote:
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> At this moment in the script, we have run "read-tree" the
> ancestor so the dircache has the original. %tree0 and %tree1
> both did not touch the path ($_ here) so it is the same as
> ancestor. When '-f' is specified we are populating the output
> working tree with the merge result so that is what that
> 'checkout-cache' is about. "O - $path" means "we took the
> original".
>
> The idea is to populate the dircache of merge-temp with the
> merge result and leave uncertain stuff as in the common ancestor
> state, so that the user can fix them starting from there.
>
> Maybe it is a good time for me to summarize the output somewhere
> in a document.
>
> O - $path Tree-A and tree-B did not touch this; the result
> is taken from the ancestor (O for original).
>
> A D $path Only tree-A (or tree-B) deleted this and the other
> B D $path branch did not touch this; the result is to delete.
>
> A M $path Only tree-A (or tree-B) modified this and the other
> B M $path branch did not touch this; the result is to use one
> from tree-A (or tree-B). This includes file
> creation case.
>
> *DD $path Both tree-A and tree-B deleted this; the result
> is to delete.
>
> *DM $path Tree-A deleted while tree-B modified this (or
> *MD $path vice versa), and manual conflict resolution is
> needed; dircache is left as in the ancestor, and
> the modified file is saved as $path~A~ in the
> working directory. The user can rename it to $path
> and run show-diff to see what Tree-A wanted to do
> and decide before running update-cache.
>
> *MM $path Tree-A and tree-B did the exact same
> modification; the result is to use that.
>
> MRG $path Tree-A and tree-B have different modifications;
> run "merge" and the merge result is left as
> $path in the working directory.
>
> In cases other than *DM, *MD, and MRG, the result is trivial and
I believe there is simpler way to do it as in my demo python script.
I start it easier but you bits me in time. It is a demo script, it
only print the action instead of actually going out to do it.
change that to corresponding os.system("") call leaves to the reader.
Again, this is a demo how it can be done. Not python vs perl thing
I did not chose perl only because I am not good at it.
#!/usr/bin/env python
import re
import sys
import os
from pprint import pprint
def get_tree(commit):
data = os.popen("cat-file commit %s"%commit).read()
return re.findall(r"(?m)^tree (\w+)", data)[0]
PREFIX = 0
PATH = -1
SHA = -2
ORIGSHA = -3
def get_difftree(old, new):
lines = os.popen("diff-tree %s %s"%(old, new)).read().split("\x00")
patterns = (r"(\*)(\d+)->(\d+)\s(\w+)\s(\w+)->(\w+)\s(.*)",
r"([+-])(\d+)\s(\w+)\s(\w+)\s(.*)")
res = {}
for l in lines:
if not l: continue
for p in patterns:
m = re.findall(p, l)
if m:
m = m[0]
res[m[-1]] = m
break
else:
raise "difftree: unknow line", l
return res
def analyze(diff1, diff2):
diff1only = [ diff1[k] for k in diff1 if k not in diff2 ]
diff2only = [ diff2[k] for k in diff2 if k not in diff1 ]
both = [ (diff1[k],diff2[k]) for k in diff2 if k in diff1 ]
action(diff1only)
action(diff2only)
action_two(both)
def action(diffs):
for act in diffs:
if act[PREFIX] == "*":
print "modify", act[PATH], act[SHA]
elif act[PREFIX] == '-':
print "remove", act[PATH], act[SHA]
elif act[PREFIX] == '+':
print "add", "remove", act[PATH], act[SHA]
else:
raise "unknow action"
def action_two(diffs):
for act1, act2 in diffs:
if len(act1) == len(act2): # same kind type
if act1[PREFIX] == act2[PREFIX]:
if act1[SHA] == act2[SHA] or act1[PREFIX] == '-':
return action(act1)
if act1[PREFIX]=='*':
print "3way-merge", act1[PATH], act1[ORIGSHA], act1[SHA], act2[SHA]
return
print "unable to handle", act[PATH]
print "one side wants", act1[PREFIX]
print "the other side wants", act2[PREFIX]
args = sys.argv[1:]
trees = map(get_tree, args)
print "check out tree", trees[0]
diff1 = get_difftree(trees[0], trees[1])
diff2 = get_difftree(trees[0], trees[2])
analyze(diff1, diff2)
^ permalink raw reply
* Re: Yet another base64 patch
From: bert hubert @ 2005-04-14 21:47 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Linus Torvalds, Christopher Li, git
In-Reply-To: <425EC3B4.6090908@zytor.com>
On Thu, Apr 14, 2005 at 12:25:40PM -0700, H. Peter Anvin wrote:
> >That may be true :-), but from the "front lines" I can report that
> >directories with > 32000 or > 65000 entries is *asking* for trouble. There
> >is a whole chain of systems that need to get things right for huge
> >directories to work well, and it often is not that way.
> >
>
> Specifics, please?
We've seen even Linus assume there is a 65K limit, and it appears more
people have been confused.
The systems I've seen mess this up include backup tools (quite serious ones
too), NetApp NFS servers, Samba shares and archivers.
Some tools just fail visibly, which is good, others become so slow as to
effectively lock up, which was the case with the backup tools.
I've quite often been able to fix broken systems by hashing directories -
many problems just vanish.
It is too easy to get into a O(N^2) situation. Git may be able to deal with
it but you may hurt yourself when making backups, or if you ever want to
share your tree (possibly with yourself) over the network.
But if you live in an all Linux world, and use mostly tar and rsync, it
should work.
Bert.
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
^ permalink raw reply
* Re: Date handling.
From: David Woodhouse @ 2005-04-14 21:48 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Luck, Tony, Linus Torvalds, git
In-Reply-To: <425EDA43.3040404@zytor.com>
On Thu, 2005-04-14 at 14:01 -0700, H. Peter Anvin wrote:
> Both of these are metadata; they may not be directly relevant to the
> filesystem, but are attributes relevant to the client thereof;
> effectively an xattr.
Right. That's perfectly acceptable -- and that's the reason why I think
it's also fine to keep the timezone and the rename information in there
too. If we were being _really_ anal about auxiliary information being
separate, we'd stick it in a separate blob object and merely refer to it
from the commit object. I don't think there's really any call to take it
that far, though.
--
dwmw2
^ permalink raw reply
* Re: Date handling.
From: H. Peter Anvin @ 2005-04-14 21:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: Luck, Tony, Linus Torvalds, git
In-Reply-To: <1113512078.12012.227.camel@baythorne.infradead.org>
David Woodhouse wrote:
> On Thu, 2005-04-14 at 12:42 -0700, Luck, Tony wrote:
>
>>This is a very good point ... but this still has problems with the
>>"git is a filesystem, not a SCM" mantra. Timezone comments don't
>>belong in the git inode.
>
> Yeah, but really I'd want to see other serious users of it before I'd
> accept that the timezone information _really_ needs to be stored
> separately. After all, the committer and author information really
> wouldn't be considered part of the _filesystem_ either.
>
Both of these are metadata; they may not be directly relevant to the
filesystem, but are attributes relevant to the client thereof;
effectively an xattr. It's not really any different than the fact that
RFC 2822-style messages frequently contain headers rarely used by either
MTAs or MUAs; they're metadata provided along the standard format for
metadata in that system. In fact, the ability for RFC (2)822 to
accommodate this type of data has shown to be a major strength of the
system, as opposed to the uncountably many attempts at binary email formats.
-hpa
^ permalink raw reply
* Re: Re: Naming the SCM (was Re: Handling renames.)
From: Petr Baudis @ 2005-04-14 21:01 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Steven Cole, Andrew Timberlake-Newell, git, 'Zach Welch',
'Linus Torvalds'
In-Reply-To: <425ED98C.9020101@zytor.com>
Dear diary, on Thu, Apr 14, 2005 at 10:58:52PM CEST, I got a letter
where "H. Peter Anvin" <hpa@zytor.com> told me that...
> Petr Baudis wrote:
>
> >>Cogito. "Git inside" can be the first slogan.
> >
> >What about tig?
>
> I like "Cogito"; it's a real name, plus it'd be a good use for the
> otherwise-pretty-useless two-letter combination "cg".
Duh, believe me or not but I completely missed the "Cogito" part of
Steven's mail. Of course, I like it too.
I'll commit my poor man's git-merge-in-separate-tree and finally get
some sleep. I promise.
--
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: Naming the SCM (was Re: Handling renames.)
From: H. Peter Anvin @ 2005-04-14 20:58 UTC (permalink / raw)
To: Petr Baudis
Cc: Steven Cole, Andrew Timberlake-Newell, git, 'Zach Welch',
'Linus Torvalds'
In-Reply-To: <20050414205329.GF22699@pasky.ji.cz>
Petr Baudis wrote:
>>Cogito. "Git inside" can be the first slogan.
>
> What about tig?
I like "Cogito"; it's a real name, plus it'd be a good use for the
otherwise-pretty-useless two-letter combination "cg".
-hpa
^ permalink raw reply
* RE: Date handling.
From: David Woodhouse @ 2005-04-14 20:54 UTC (permalink / raw)
To: Luck, Tony; +Cc: Linus Torvalds, git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F03457AE6@scsmsx401.amr.corp.intel.com>
On Thu, 2005-04-14 at 12:42 -0700, Luck, Tony wrote:
> This is a very good point ... but this still has problems with the
> "git is a filesystem, not a SCM" mantra. Timezone comments don't
> belong in the git inode.
Yeah, but really I'd want to see other serious users of it before I'd
accept that the timezone information _really_ needs to be stored
separately. After all, the committer and author information really
wouldn't be considered part of the _filesystem_ either.
--
dwmw2
^ permalink raw reply
* Re: Naming the SCM (was Re: Handling renames.)
From: Petr Baudis @ 2005-04-14 20:53 UTC (permalink / raw)
To: Steven Cole
Cc: Andrew Timberlake-Newell, git, 'Zach Welch',
'Linus Torvalds'
In-Reply-To: <200504141442.17235.elenstev@mesatop.com>
Dear diary, on Thu, Apr 14, 2005 at 10:42:16PM CEST, I got a letter
where Steven Cole <elenstev@mesatop.com> told me that...
> On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:
> > Zach Welch pontificated:
> > > I imagine quite a few folks expect something not entirely unlike an SCM
> > > to emerge from these current efforts. Moreover, Petr's 'git' scripts
> > > wrap your "filesystem" plumbing to that very end.
> > >
> > > To avoid confusion, I think it would be better to distinguish the two
> > > layers, perhaps by calling the low-level plumbing... 'gitfs', of course.
> >
> > Or perhaps to come up with a name (or at least nickname) for the SCM.
> >
> > GitMaster?
> >
>
> Cogito. "Git inside" can be the first slogan.
What about tig?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
^ permalink raw reply
* Naming the SCM (was Re: Handling renames.)
From: Steven Cole @ 2005-04-14 20:42 UTC (permalink / raw)
To: Andrew Timberlake-Newell
Cc: git, 'Zach Welch', 'Linus Torvalds'
In-Reply-To: <002701c54129$da2ffdd0$9b11a8c0@allianceoneinc.com>
On Thursday 14 April 2005 01:40 pm, Andrew Timberlake-Newell wrote:
> Zach Welch pontificated:
> > I imagine quite a few folks expect something not entirely unlike an SCM
> > to emerge from these current efforts. Moreover, Petr's 'git' scripts
> > wrap your "filesystem" plumbing to that very end.
> >
> > To avoid confusion, I think it would be better to distinguish the two
> > layers, perhaps by calling the low-level plumbing... 'gitfs', of course.
>
> Or perhaps to come up with a name (or at least nickname) for the SCM.
>
> GitMaster?
>
Cogito. "Git inside" can be the first slogan.
Differentiating the SCM built on top of git from git itself is probably worthwhile
to avoid confusion. Other SCMs may be developed later, built on git, and these
can come up with their own clever names.
Steven
^ permalink raw reply
* Re: Re: Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-14 20:24 UTC (permalink / raw)
To: Erik van Konijnenburg; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20050414222326.E2442@banaan.localdomain>
Dear diary, on Thu, Apr 14, 2005 at 10:23:26PM CEST, I got a letter
where Erik van Konijnenburg <ekonijn@xs4all.nl> told me that...
> On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
> > Hmm. I actually don't like this naming. I think it's not too consistent,
> > is irregular, therefore parsing it would be ugly. What I propose:
> >
> > 12c\tname <- legend
> > <- original file
> > D <- tree #1 removed file
> > D <- tree #2 removed file
> > DD <- both trees removed file
> > M <- tree #1 modified file
> > M
> > DM* <- conflict, tree #1 removed file, tree #2 modified file
> > MD*
> > MM <- exact same modification
> > MM* <- different modifications, merging
> >
> > This is generic, theoretically scales well even to more trees, is easy
> > to parse trivially, still is human readable (actually the asterisk in
> > the 'conflict' column is there basically only for the humans), is
> > completely regular and consistent.
>
> Detail: perhaps use underscore instead of space, to avoid space/tab typos
> that are invisible on paper and user friendly mail clients?
I'd go for dots in that case. Looks less intrusive. :^)
--
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: Re: Merge with git-pasky II.
From: Erik van Konijnenburg @ 2005-04-14 20:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Linus Torvalds, git
In-Reply-To: <20050414193507.GA22699@pasky.ji.cz>
On Thu, Apr 14, 2005 at 09:35:07PM +0200, Petr Baudis wrote:
> Hmm. I actually don't like this naming. I think it's not too consistent,
> is irregular, therefore parsing it would be ugly. What I propose:
>
> 12c\tname <- legend
> <- original file
> D <- tree #1 removed file
> D <- tree #2 removed file
> DD <- both trees removed file
> M <- tree #1 modified file
> M
> DM* <- conflict, tree #1 removed file, tree #2 modified file
> MD*
> MM <- exact same modification
> MM* <- different modifications, merging
>
> This is generic, theoretically scales well even to more trees, is easy
> to parse trivially, still is human readable (actually the asterisk in
> the 'conflict' column is there basically only for the humans), is
> completely regular and consistent.
Detail: perhaps use underscore instead of space, to avoid space/tab typos
that are invisible on paper and user friendly mail clients?
Regards,
Erik
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-14 20:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v7jj5qgdz.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Apr 14, 2005 at 09:59:04PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
>
> LT> On Thu, 14 Apr 2005, Junio C Hamano wrote:
>
> >> Sorry, I have not seen what you have been doing since pasky 0.3,
> >> and I have not even started to understand the mental model of
> >> the world your tool is building. That said, my gut feeling is
> >> that telling this script about git-pasky's world model might be
> >> a mistake. I'd rather see you consider the script as mere "part
> >> of the plumbing".
>
> LT> I agree. Having separate abstraction layers is good. I'm actually very
> LT> happy with Pasky's cleaned-up-tree, exactly because unlike the first one,
(Just a side-note - functionally and even organizationally, the cleaned
up tree does not differ significantly from the original one.)
> LT> Pasky did a great job of maintaining the abstraction between "plumbing"
> LT> and user interfaces.
>
> Agreed, not just with your agreeing with me, but with the
> statement that Pasky did a good job (although I am ashamed to
> say I have not caught up with the "userland" tools).
Thanks. :-)
> LT> The plumbing should take user interface needs into account, but the more
> LT> conceptually separate it is ("does it makes sense on its own?") the better
> LT> off we'll be. And "merge these two trees" (which works on a _tree_ level)
> LT> or "find the common commit" (which works on a _commit_ level) look like
> LT> plumbing to me - the kind of things I should have written, if I weren't
> LT> such a lazy slob.
>
> I am planning drop the ancestor computation from the script, and
> make it another command line parameter to the script. Dan
> Barkalow's merge-base program should be used to compute it and
> his result should drive the merge. That sounds more UNIXy to
> me.
Good move, I say!
> I even may want to make the script take three trees not
> commits, since the merge script does not need commits (it only
> needs trees). As plumbing it would be cleaner interface to it
> to do so. The wrapper SCM scripts can and should make sure it
> is fed trees when the user gives it commits (or symbolic
> representation of it like .git/tags/blah, or `cat .git/HEAD`).
Agreed.
> But one different thing to note here.
>
> You say "merge these two trees" above (I take it that you mean
> "merge these two trees, taking account of this tree as their
> common ancestor", so actually you are dealing with three trees),
> and I am tending to agree with the notion of merging trees not
> commits. However you might get richer context and more sensible
> resulting merge if you say "merge these two commits". Since
> commit chaining is part of the fundamental git object model you
> may as well use it.
Could you be more particular on the richer context etc?
I think this script should stay strictly on the level of trees. When
someone invents it, there could be a merge-commits script which does
something very smart about two commits, traversing the graph between
them etc, and doing a set of merge-tree invocations, possibly preparing
the staging area for them etc.
--
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: Junio C Hamano @ 2005-04-14 19:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Petr Baudis, git
In-Reply-To: <Pine.LNX.4.58.0504141133260.7211@ppc970.osdl.org>
>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> On Thu, 14 Apr 2005, Junio C Hamano wrote:
>> Sorry, I have not seen what you have been doing since pasky 0.3,
>> and I have not even started to understand the mental model of
>> the world your tool is building. That said, my gut feeling is
>> that telling this script about git-pasky's world model might be
>> a mistake. I'd rather see you consider the script as mere "part
>> of the plumbing".
LT> I agree. Having separate abstraction layers is good. I'm actually very
LT> happy with Pasky's cleaned-up-tree, exactly because unlike the first one,
LT> Pasky did a great job of maintaining the abstraction between "plumbing"
LT> and user interfaces.
Agreed, not just with your agreeing with me, but with the
statement that Pasky did a good job (although I am ashamed to
say I have not caught up with the "userland" tools).
LT> The plumbing should take user interface needs into account, but the more
LT> conceptually separate it is ("does it makes sense on its own?") the better
LT> off we'll be. And "merge these two trees" (which works on a _tree_ level)
LT> or "find the common commit" (which works on a _commit_ level) look like
LT> plumbing to me - the kind of things I should have written, if I weren't
LT> such a lazy slob.
I am planning drop the ancestor computation from the script, and
make it another command line parameter to the script. Dan
Barkalow's merge-base program should be used to compute it and
his result should drive the merge. That sounds more UNIXy to
me. I even may want to make the script take three trees not
commits, since the merge script does not need commits (it only
needs trees). As plumbing it would be cleaner interface to it
to do so. The wrapper SCM scripts can and should make sure it
is fed trees when the user gives it commits (or symbolic
representation of it like .git/tags/blah, or `cat .git/HEAD`).
But one different thing to note here.
You say "merge these two trees" above (I take it that you mean
"merge these two trees, taking account of this tree as their
common ancestor", so actually you are dealing with three trees),
and I am tending to agree with the notion of merging trees not
commits. However you might get richer context and more sensible
resulting merge if you say "merge these two commits". Since
commit chaining is part of the fundamental git object model you
may as well use it.
This however opens up another set of can of worms---it would
involve not just three trees but all the trees in the commit
chain in between. That's when you start wondering if it would
be better to add renames in the git object model, which is the
topic of another thread. I have not formed an opinion on that
one myself yet.
^ permalink raw reply
* Live Merging from remote repositories
From: Barry Silverman @ 2005-04-14 20:01 UTC (permalink / raw)
To: Petr Baudis, Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <20050414193507.GA22699@pasky.ji.cz>
If you are merging from many distributed developers, than you would need to
replicate every one of their repositories into your own. Is this necessary?
I have been looking at Junio's code for merging, and it looks like it would
be (relatively) easy change to make it run live across two remote
repositories - assuming "future" science to develop remote common ancestor
lookup...
IE, merge.pl $COMMON-BASE $LOCAL-CHANGESET remote::$REMOTE-CHANGESET
To make this work, only a couple of things need to happen:
1) be able to remotely run "remote::diff-tree $BASE $REMOTE-CHANGESET", and
copy the results over the net to the place in the script where it is done
locally. This is not a LOT of data, and is bounded by the number of total
number of blobs in the resulting tree.
2) When a remote blob is required (for merging, or copying), then copy it
from the remote .git/objects to the local one. You only copy the blobs that
will end up in the merged result (or be used for file merge).
The way Junio has done it, no intermediate trees or commits are used...
You don't copy remote's tree of commits between $BASE and $REMOTE-CHANGESET,
or any of their associated trees and blobs (unless used to merge).
Is this a bug or a feature?
Barry Silverman
^ permalink raw reply
* Re: RE: Date handling.
From: Petr Baudis @ 2005-04-14 19:46 UTC (permalink / raw)
To: Luck, Tony; +Cc: David Woodhouse, Linus Torvalds, git
In-Reply-To: <B8E391BBE9FE384DAA4C5C003888BE6F03457AE6@scsmsx401.amr.corp.intel.com>
Dear diary, on Thu, Apr 14, 2005 at 09:42:28PM CEST, I got a letter
where "Luck, Tony" <tony.luck@intel.com> told me that...
> >I'd prefer not to lose the information. If someone has committed a
> >change at 2am, I like to know that it was 2am for _them_. It helps me
> >decide where to look first for the cause of problems. :)
>
> I'd think the 8:00am-before-the-first-coffee checkins would be the
> most worrying :-)
>
> >It also helps disambiguate certain comments, especially those involving
> >words or phrases such as "yesterday" or "this afternoon".
>
> This is a very good point ... but this still has problems with the
> "git is a filesystem, not a SCM" mantra. Timezone comments don't
> belong in the git inode.
So, when commit is done in a given time of day, a "*YAWN*" line should
be automatically appended to the log message. ;-)
--
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: Date handling.
From: Luck, Tony @ 2005-04-14 19:42 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, git
>I'd prefer not to lose the information. If someone has committed a
>change at 2am, I like to know that it was 2am for _them_. It helps me
>decide where to look first for the cause of problems. :)
I'd think the 8:00am-before-the-first-coffee checkins would be the
most worrying :-)
>It also helps disambiguate certain comments, especially those involving
>words or phrases such as "yesterday" or "this afternoon".
This is a very good point ... but this still has problems with the
"git is a filesystem, not a SCM" mantra. Timezone comments don't
belong in the git inode.
-Tony
^ permalink raw reply
* RE: Handling renames.
From: Andrew Timberlake-Newell @ 2005-04-14 19:40 UTC (permalink / raw)
To: git; +Cc: 'Zach Welch', 'Linus Torvalds'
In-Reply-To: <425EC2E8.3010703@superlucidity.net>
Zach Welch pontificated:
> I imagine quite a few folks expect something not entirely unlike an SCM
> to emerge from these current efforts. Moreover, Petr's 'git' scripts
> wrap your "filesystem" plumbing to that very end.
>
> To avoid confusion, I think it would be better to distinguish the two
> layers, perhaps by calling the low-level plumbing... 'gitfs', of course.
Or perhaps to come up with a name (or at least nickname) for the SCM.
GitMaster?
^ permalink raw reply
* Re: Re: Merge with git-pasky II.
From: Petr Baudis @ 2005-04-14 19:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vll7lqlbg.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Apr 14, 2005 at 08:12:35PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> told me that...
> >>>>> "PB" == Petr Baudis <pasky@ucw.cz> writes:
>
> PB> Bah, you outran me. ;-)
>
> Just being in a different timezone, I guess.
>
> PB> I'll change it to use the cool git-pasky stuff (commit-id etc) and its
> PB> style of committing - that is, it will merely record the update-caches
> PB> to be done upon commit, and it will read-tree the branch we are merging
> PB> to instead of the ancestor. (So that git diff gives useful output.)
>
> Sorry, I have not seen what you have been doing since pasky 0.3,
> and I have not even started to understand the mental model of
> the world your tool is building. That said, my gut feeling is
> that telling this script about git-pasky's world model might be
> a mistake. I'd rather see you consider the script as mere "part
> of the plumbing". Maybe adding an extra parameter to the script
> to let the user explicitly specify the common ancestor to use
> would be needed, but I would prefer git-pasky-merge to do its
> own magic (converting symbolic commit names into raw commit
> names and such) before calling this low level script.
>
> That way people like me who have not migrated to your framework
> can still keep using it. All the script currently needs is a
> bare git object database; i.e., nothing other than what is in
> .git/objects and a couple of commit record SHA1s as its
> parameters. No .git/heads/, no .git/HEAD.local, no .git/tags,
> are involved for it to work, and I would prefer to keep things
> that way if possible.
I see, and I actually agree with it. However, I'll want merge-tree.pl to
do a little less than it does now for that, though. The mechanics in
"kernel" is fine as long as I can control policy in my "userspace". ;-)
BTW, the git* name sorta imply my toilet instead of the core plumbing, and
it'd be more consistent with the current plumbnaming; and could we have
it with the .pl extension, please? :-)
What I would like your script to do is therefore just do the merge in a
given already prepared (including built index) directory, with a passed
base. The base should be determined by a separate tool (I already saw
some patches); most future "science" will probably go to a clever
selection of this base, anyway.
This will give the tool maximal flexibility. E.g., then someone who
wants to can just merge with his working copy (if you don't give
checkout-cache -f - but why would you anyway), or do whatever other
cleverness he wants.
> >> * show-diff updates to add -r flag to squelch diffs for files not in
> >> the working directory. This is mainly useful when verifying the
> >> result of an automated merge.
..snip..
> was too tired and did not think of a letter when I wrote it. I
> guess '-r' stood for removed, but I agree it is a bad choice.
> Any objections to '-q'?
None here.
> >> +# Create a temporary directory and go there.
> >> +system 'rm', '-rf', ',,merge-temp';
>
> PB> Can't we call it just ,,merge?
>
> I'd rather have a command line option '-o' (scrapping the
> current '-o' and renaming it to something else; as you can see I
> am terrible at picking option names ;-)) to mean "output to this
> directory". I am not really an Arch person so I do not
> particulary care about /^,,/. How about "git~merge~$$"?
I'm all for an -o, and I don't mind ,, - I just don't want it uselessly
long. I hope "git~merge~$$" was a joke... :-)
> >> +for ((',,merge-temp', '.git')) { mkdir $_; chdir $_; }
> >> +symlink "../../.git/objects", "objects";
> >> +chdir '..';
> >> +
> >> +my $ancestor_tree = read_commit_tree($common);
> >> +system 'read-tree', $ancestor_tree;
> >> +
> >> +my %tree0 = read_diff_tree($ancestor_tree, read_commit_tree($ARGV[0]));
> >> +my %tree1 = read_diff_tree($ancestor_tree, read_commit_tree($ARGV[1]));
> >> +
> >> +my @ancestor_file = read_show_files();
> >> +my %ancestor_file = map { $_ => 1 } @ancestor_file;
> >> +
> >> +for (@ancestor_file) {
> >> + if (! exists $tree0{$_} && ! exists $tree1{$_}) {
By the way, what about indentation with tabs? If you have a strong
opinion about this, I don't insist - but if you really don't mind/care
either way, it'd be great to use tabs as in the rest of the git code.
> >> + if ($full_checkout) {
> >> + system 'checkout-cache', $_;
> >> + }
> >> + print STDERR "O - $_\n";
>
> PB> Huh, what are you trying to do here? I think you should just record
> PB> remove, no? (And I wouldn't do anything with my read-tree. ;-)
>
> At this moment in the script, we have run "read-tree" the
> ancestor so the dircache has the original. %tree0 and %tree1
> both did not touch the path ($_ here) so it is the same as
> ancestor. When '-f' is specified we are populating the output
> working tree with the merge result so that is what that
> 'checkout-cache' is about. "O - $path" means "we took the
> original".
Aha! Thanks.
Is there a fundamental reason why the directory cache contains the
ancestor instead of the destination branch? It makes no sense to me and
I think the script actually does not fundamentally depend on it. My main
motivation is that the user can then trivially see what is he actually
going to commit to his destination branch, which would be bought for
free by that.
> The idea is to populate the dircache of merge-temp with the
> merge result and leave uncertain stuff as in the common ancestor
> state, so that the user can fix them starting from there.
And this is another thing I dislike a lot. I'd like merge-tree.pl to
leave my directory cache alone, thank you very much. You know, I see
what goes to the directory cache as actually part of the policy part.
What you actually do is interfering with my different policy choice,
which is to record stuff to index only at the time of commit (I've asked
about this and noone replied, so I assume it's an ok choice). show-diff
does the right thing for me then, and I don't need to care about losing
*any* information when replacing/rebuilding the index for any reason. I
have full control, and I like that. :-)
I'd be happy with parsing merge-tree.pl output and doing the right thing
on my side. Of course I could then blast away the tediously modified
index with my one, but I didn't need to do any such hacking before and
I'd prefer not to now either.
Actually, the only time I need to do explicit update-cache (with my
policy) when doing git merge is when deleting stuff or adding new stuff;
both of this is not so common as modifying, when I need not to do
anything.
> Maybe it is a good time for me to summarize the output somewhere
> in a document.
>
> O - $path Tree-A and tree-B did not touch this; the result
> is taken from the ancestor (O for original).
>
> A D $path Only tree-A (or tree-B) deleted this and the other
> B D $path branch did not touch this; the result is to delete.
>
> A M $path Only tree-A (or tree-B) modified this and the other
> B M $path branch did not touch this; the result is to use one
> from tree-A (or tree-B). This includes file
> creation case.
Could we please have the file creation case separately? Modification
is much more common and creation has pretty different consequences
(especially that it can't combine with anything else :-).
> *DD $path Both tree-A and tree-B deleted this; the result
> is to delete.
>
> *DM $path Tree-A deleted while tree-B modified this (or
> *MD $path vice versa), and manual conflict resolution is
> needed; dircache is left as in the ancestor, and
> the modified file is saved as $path~A~ in the
> working directory. The user can rename it to $path
> and run show-diff to see what Tree-A wanted to do
> and decide before running update-cache.
>
> *MM $path Tree-A and tree-B did the exact same
> modification; the result is to use that.
>
> MRG $path Tree-A and tree-B have different modifications;
> run "merge" and the merge result is left as
> $path in the working directory.
Hmm. I actually don't like this naming. I think it's not too consistent,
is irregular, therefore parsing it would be ugly. What I propose:
12c\tname <- legend
<- original file
D <- tree #1 removed file
D <- tree #2 removed file
DD <- both trees removed file
M <- tree #1 modified file
M
DM* <- conflict, tree #1 removed file, tree #2 modified file
MD*
MM <- exact same modification
MM* <- different modifications, merging
This is generic, theoretically scales well even to more trees, is easy
to parse trivially, still is human readable (actually the asterisk in
the 'conflict' column is there basically only for the humans), is
completely regular and consistent.
Now that we have the notion of tree A and tree B gone, I'd prefer to use
numbers instead of letters for the ~1~ and ~2~ suffixes. Not insisting,
though.
What do you think?
> In cases other than *DM, *MD, and MRG, the result is trivial and
> is recorded in the dircache. Without '-o' (to be renamed ;-)
> nor '-f' there will not be a file checked out in the working
> directory for them. The three merge cases need human attention.
> The dircache is not touched in these cases and left as the
> ancestor version, and the working directory gets some file as
> described above.
>
> NOTE NOTE NOTE: I am not dealing with a case where both branches
> create the same file but with different contents. In such a
> case the current code falls into MRG path without having a
> common ancestor, which is nonsense---I can use /dev/null as the
> common ancestor, I guess. Also NOTE NOTE NOTE I need to detect
That might be the best way at least for the start, although I suspect
that merge will fail horribly this way even in the case of slightest
differences; still better than nothing.
> the case where one branch creates a directory while the other
> creates a file. There is nothing an automated tool can do in
> that case but it needs to be detected and be told the user
> loudly.
Or when both branches create directories... ;-)
--
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: Yet another base64 patch
From: H. Peter Anvin @ 2005-04-14 19:25 UTC (permalink / raw)
To: bert hubert; +Cc: Linus Torvalds, Christopher Li, git
In-Reply-To: <20050414191157.GA27696@outpost.ds9a.nl>
bert hubert wrote:
>
> That may be true :-), but from the "front lines" I can report that
> directories with > 32000 or > 65000 entries is *asking* for trouble. There
> is a whole chain of systems that need to get things right for huge
> directories to work well, and it often is not that way.
>
Specifics, please?
-hpa
^ permalink raw reply
* Re: Date handling.
From: David Woodhouse @ 2005-04-14 19:23 UTC (permalink / raw)
To: tony.luck; +Cc: Linus Torvalds, git
In-Reply-To: <200504141919.j3EJJfG04166@unix-os.sc.intel.com>
On Thu, 2005-04-14 at 12:19 -0700, tony.luck@intel.com wrote:
> With a UTC date, why would anyone care in which timezone the commit was
> made? Any pretty printing would most likely be prettiest if it is done
> relative to the timezone of the person looking at the commit record, not
> the person who created the record.
I'd prefer not to lose the information. If someone has committed a
change at 2am, I like to know that it was 2am for _them_. It helps me
decide where to look first for the cause of problems. :)
It also helps disambiguate certain comments, especially those involving
words or phrases such as "yesterday" or "this afternoon".
--
dwmw2
^ permalink raw reply
* Re: Handling renames.
From: Zach Welch @ 2005-04-14 19:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: H. Peter Anvin, David Woodhouse, git, James Bottomley
In-Reply-To: <Pine.LNX.4.58.0504141145220.7211@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 14 Apr 2005, H. Peter Anvin wrote:
>
>> Although Linus is correct in that an SCM doesn't *have* to handle
>> this, it really feels like shooting for mediocracy to me. We might
>> as well design it right from the beginning.
>
>
> No. git is not an SCM. it's a filesystem designed to _host_ an SCM,
> and that _is_ doing it right from the beginning.
I imagine quite a few folks expect something not entirely unlike an SCM
to emerge from these current efforts. Moreover, Petr's 'git' scripts
wrap your "filesystem" plumbing to that very end.
To avoid confusion, I think it would be better to distinguish the two
layers, perhaps by calling the low-level plumbing... 'gitfs', of course.
Cheers,
Zach Welch
Superlucidity Services
^ permalink raw reply
* Re: Handling renames.
From: David Mansfield @ 2005-04-14 19:21 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ingo Molnar, David Woodhouse, git, James Bottomley
In-Reply-To: <Pine.LNX.4.58.0504141124220.7211@ppc970.osdl.org>
Linus Torvalds wrote:
>
> On Thu, 14 Apr 2005, Ingo Molnar wrote:
>
>>there's no redundancy caused by this method: only renames (which are
>>rare) go through the rename_commit redirection. (to speed up the lookup
>>the rename_commit object could cache the offset of the two names within
>>their tree objects.)
>
>
>
> Some "higher level" thing can add its own rules _on_top_ of git rules. The
> same way we have normal applications having their _own_ rules on top of
> the kernel. You do abstraction in layers, but for this to work, the base
> you build on top of had better be damn solid, and not have any ugly
> special cases.
>
Maybe you (or the group) should standardize on a way to 'extend' the
commit 'object' in terms of:
the layer1 (git) header for commit object is defined as such-and-such
the layer2 (scm or other) header for commit object is defined as
such-and-such
Much the way network protocols stack on top of each other. If a
standard way of stacking is defined, then it could be much cleaner for
future implementors to understand a 'new' stacking protocol, and it will
make the scm-level extensions easier to discuss it terms of their own
'layer'.
David
^ permalink raw reply
* Re: Handling renames.
From: David Woodhouse @ 2005-04-14 19:20 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Linus Torvalds, git, James Bottomley
In-Reply-To: <20050414185841.GA16865@elte.hu>
On Thu, 2005-04-14 at 20:58 +0200, Ingo Molnar wrote:
> The thing i tried to avoid was to list long filenames in the commit
> (because of the tree hierarchy we'd need to do tree-absolute pathnames
> or something like that, and escape things, and do lookups - duplicating
> a VFS which is quite bad) - it would be better to identify the rename
> source and target via its tree object hash and its offset within that
> tree. Such information could be embedded in the commit object just fine.
> Something like:
Actually I'm not sure that's true. Let's consider the two main users of
this information.
Firstly, because it's what I've been playing with: to list a given
file's revision history, I currently work with its filename -- walk the
commit objects, inspecting the tree and selecting those commits where
the file has changed. If my filename is 'fs/jffs2/inode.c' then I can
immediately skip over a commit where the 'fs' entry in the top-level
tree is identical to that in the parent, or I can skip a commit where
the 'jffs2' entry in the 'fs' subtree is identical to the parent... it's
all done on filename, and the {parent, entry} tuple wouldn't help much
here; I'd probably have to convert back to a filename anyway.
Secondly, there's merges. I've paid less attention to these (see mail 5
minutes ago) but I think they'd end up operating on the rename
information in a very similar way. To find a common ancestor for a given
file,, we want to track its name as it changed during history; at that
point it's all string compares.
--
dwmw2
^ permalink raw reply
* Re: Date handling.
From: tony.luck @ 2005-04-14 19:19 UTC (permalink / raw)
To: David Woodhouse; +Cc: Linus Torvalds, git
In-Reply-To: <1113500316.27227.8.camel@hades.cambridge.redhat.com>
> OK. commit-tree now eats RFC2822 dates as AUTHOR_DATE because that's
> what you're going to want to feed it. We store seconds since UTC epoch,
> we add the author's or committer's timezone as auxiliary data so that
> dates can be pretty-printed in the original timezone later if anyone
> cares.
With a UTC date, why would anyone care in which timezone the commit was
made? Any pretty printing would most likely be prettiest if it is done
relative to the timezone of the person looking at the commit record, not
the person who created the record.
If we do need the timezone, then I think we also need the latitude of the
committer too, so that we know whether to interpret "July" as summer or
winter :-)
-Tony
^ 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