I finally sync'ed up with Pasky 0.4. Reviewing the diffs
between Linus tree and Pasky tree for the core part you seem to
have picked up some good changes (especially the byteorder one),
so I decided to rebase my changes. So here it comes...
What follows are the 3 patches to the core part to
No, '' have a higher priority (weight?) than ''.
has a higher precedence than
C Operator Precedence and Associativity
http://www.difranco.net/cop2220/op-prec.htm
and many others -- google for 'c operator precedence'
Where the bitops , | and ^ bite you is that they are
lower precedence
CL == Christopher Li [EMAIL PROTECTED] writes:
- Result is this object $SHA1 with mode $mode at $path (takes
one of the trees); you can do update-cache --cacheinfo (if
you want to muck with dircache) or cat-file blob (if you want
to get the file) or both.
CL Is that SHA1 for tree or the
On Fri, Apr 15, 2005 at 12:43:47AM -0700, Junio C Hamano wrote:
CL == Christopher Li [EMAIL PROTECTED] writes:
CL Is that SHA1 for tree or the file object?
I am talking about a single file here.
Then do you emit the entry for it's parents directory?
e.g. /foo/bar get created. foo doesn't
On Fri, 2005-04-15 at 11:36 +0200, Ingo Molnar wrote:
do such cases occur frequently? In the kernel at least it's not too
typical.
Isn't it? I thought it was a fairly accurate representation of the
process I make a whole bunch of changes to files I maintain, pulling
from Linus while
In perusing the git code, I noticed some errors in argument parsing,
which the patch below fixes. The show-diff error (checking argv[1]
each time around the loop) probably doesn't actually cause any real
problem, but it could be confusing for a novice if show-diff x
produces an error but
On Fri, Apr 15, 2005 at 02:03:08PM +0200, Johannes Schindelin wrote:
I disagree. In order to be trusted, this thing has to catch the following
scenario:
Skywalker and Solo start from the same base. They commit quite a lot to
their trees. In between, Skywalker commits a tree, where the
On Thu, 14 Apr 2005, Paul Jackson wrote:
To me, rename is a special case of the more general case of a
big chunk of code (a portion of a file) that was in one place
either being moved or copied to another place.
I wonder if there might be someway to use the tools that biologists use
to analyze DNA
PB == Petr Baudis [EMAIL PROTECTED] writes:
PB I can't see the conflicts between what I want and what Linus wants.
PB After all, Linus says that I can use the directory cache in any way I
PB please (well, the user can, but I'm speaking for him ;-). So I'm doing
PB so, and with your tool I would
CSA == C Scott Ananian [EMAIL PROTECTED] writes:
CSA On Fri, 15 Apr 2005, Junio C Hamano wrote:
to yours is no problem for me. Currently I see your HEAD is at
461aef08823a18a6c69d472499ef5257f8c7f6c8, so I will generate a
set of patches against it.
CSA Have you considered using an
Linus,
the merge-trees I sent you earlier was expecting the old
diff-tree behaviour, and I did not realize that I need an
explicit -z flag now. Here is a fix.
Signed-off-by: Junio C Hamano [EMAIL PROTECTED]
---
merge-trees |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
On Fri, 15 Apr 2005, Linus Torvalds wrote:
I think I've explained my name tracking worries. When it comes to how to
merge, there's three issues:
- we do commonly have merge clashes where both trees have applied the
exact same patch. That should merge perfectly well using the 3-way
Linus,
this adds '-z' to merge-tree and changes its default line
termination to LF to make it consistent with your other recent
changes.
The patch is against
commit 028c5948257e763b3deb391e567b624eb7975ec2
tree 6b866e10b16183e630db8449c64899f6810d4270
Signed-off-by: Junio C Hamano
On Fri, 15 Apr 2005, Daniel Barkalow wrote:
Is there some reason you don't commit before merging? All of the current
merge theory seems to want to merge two commits, using the information git
keeps about them.
Note that the 3-way merge would _only_ merge the committed state. The
thing is,
On Sat, 16 Apr 2005, Petr Baudis wrote:
I'm wondering, whether each tree should be fixed to a certain branch.
I'm wondering why you talk about branches at all.
No such thing should exist. There are no branches. There are just
repositories. You can track somebody elses repository, but you
On Fri, 15 Apr 2005, Linus Torvalds wrote:
On Fri, 15 Apr 2005, Daniel Barkalow wrote:
So you want to merge someone else's tree into your committed state, and
then merge the result with your working directory to get the working
directory you continue with, provided that the second merge
On Fri, 15 Apr 2005, Junio C Hamano wrote:
I'd take the hint, but I would say the current Perl version
would be far more usable than the C version I would come up with
by the end of this weekend because:
Actually, it turns out that I have a cunning plan.
I'm full of cunning plans, in
17 matches
Mail list logo
