In my opinion, setting the file timestamp to the commit time (or
any other time other than the time of checkout) tends to screw
you up more than help you.
Suppose you have the latest checked out in your working tree,
you build and test, and find regressions. You'd want to check
out from an older
Greg KH <[EMAIL PROTECTED]> writes:
> So, the patch shows that there was another line at the end of the file,
> while in reality it isn't (this is due to me excluding a patch from the
> series that I'm applying due to other reasons.)
>
> Is this something that git can handle without me editing the
Immediately after I updated the "master" branch with the tool
renames, I got a complaint from somebody telling me that the
things do not work anymore without 'make install'.
Strictly speaking, git has never worked fully without
installation because 'git' wrapper looked for things in the same
direc
On Thu, 8 Sep 2005, Greg KH wrote:
>
> Or am I missing some option to 'git applymbox' that I can't seem to
> find?
No. git-apply wants an exact bit-for-bit match. Partly because fuzz is
hard, but mostly because I don't like it. I apply a _lot_ of patches, and
if a unforgiving "git-apply" work
On Thu, Sep 08, 2005 at 04:25:35PM -0700, Greg KH wrote:
> Ick. I'm trying to apply a bunch of patches to a git repo (the kernel
> tree), using 'git applymbox' and it's just dieing on simple patches that
> apply with fuzz.
Ok, found another one. This time I looked at the patch itself, and it
is
> > Yes, this is nice for smaller projects. But I don't think, that we want
> > to do such a thing on the kernel.org servers.
>
> I think this is a very useful feature for for some, but not all,
> repositories. Default it to off and have a magic file (like git-daemon),
> or a config variable turn
On 09/06/2005 02:08 PM, Junio C Hamano wrote:
> Jeff Carr <[EMAIL PROTECTED]> writes:
>
>
>>... If I remember
>>correctly, there was some threads at the beginning of git about how
>>datestamps were not accurate so there was no point in setting them(?) Or
>>maybe I mis-understood.
>
>
> The poin
The "master" branch post 0.99.6 already has the renamed tools
with backward compatibility symlinks. I'll be sending a
patch to address an issue raised by some people separately to
see what the list thinks, and also will attempt to send out a
patch for the Pasky and Catalin heads later this week.
On Thu, 8 Sep 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > I assume that what you want is something to include everything from two
> > commits, which would give conflicts if a name is reused?
>
> My understanding is that Darrin wants to do what Linus did when
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I assume that what you want is something to include everything from two
> commits, which would give conflicts if a name is reused?
My understanding is that Darrin wants to do what Linus did when
he merged gitk into git.git.
Personally I think that i
On Thu, 2005-09-08 at 17:39 -0400, Daniel Barkalow wrote:
> I assume that what you want is something to include everything from two
> commits, which would give conflicts if a name is reused?
>
Yes.
--
Darrin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mes
On Thu, 8 Sep 2005, Darrin Thompson wrote:
> On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:
> > I've got a version of read-tree which accepts multiple ancestors and does
> > a merge using information from all of them.
>
> Do the multiple ancestors have to share a common parent? More t
On Thu, 8 Sep 2005, Fredrik Kuivinen wrote:
> The first one agrees with what was actually committed. For the second
> one the difference between the tree produced by the algorithm and what
> was committed is:
>
> diff --git a/include/net/ieee80211.h b/include/net/ieee80211.h
> --- a/include/net/i
Junio C Hamano wrote:
[...]
Subject: [PATCH] Multi-backend merge driver.
This is just an illustration of concept patch.
The new command 'git merge' takes the current head and one or more
remote heads, with the commit log message for the automated case.
If the heads being merged are simple fast
On Thu, 8 Sep 2005, Chuck Lever wrote:
> >
> > Btw, in the sparse project, we have this really smart "pointer list" data
> > structure, which is extremely space- and time-efficient. It ends up
> > _looking_ like a linked list, but it batches things up in hunks of 29
> > entries (29 pointers plus
Junio C Hamano <[EMAIL PROTECTED]> writes:
> ... I'd like to leave what
> merge strategy to use as an user option, and leave the door open
> for other merge strategies to emerge later. I know Pasky wants
> to look into pcdv merge and other alternatives.
>
> This is still off-the-top-of-my-head, b
On Thu, Sep 08, 2005 at 12:16:05PM -0500, Darrin Thompson wrote:
> On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:
> > I've got a version of read-tree which accepts multiple ancestors and does
> > a merge using information from all of them.
>
> Do the multiple ancestors have to share a
On Mon, 2005-09-05 at 01:41 -0400, Daniel Barkalow wrote:
> I've got a version of read-tree which accepts multiple ancestors and does
> a merge using information from all of them.
Do the multiple ancestors have to share a common parent? More to the
point, is this read-tree any more friendly to ba
On Thu, Sep 08, 2005 at 11:27:35AM -0400, Daniel Barkalow wrote:
...
> > The two cases my algorithm merges cleanly and git-resolve-script do
> > not merge cleanly are 0e396ee43e445cb7c215a98da4e76d0ce354d9d7 and
> > 0c168775709faa74c1b87f1e61046e0c51ade7f3. Both of them have two common
> > ancest
Linus Torvalds wrote:
On Thu, 8 Sep 2005, Chuck Lever wrote:
in my case the merges were taking significantly longer than a half
second. making this change is certainly not worth it if merges are
running fast...
Note that in cold-cache cases, all the expense of read-tree is in actually
rea
Junio C Hamano wrote:
A Large Angry SCM <[EMAIL PROTECTED]> writes:
Naming and Directory Structure
--
Annotations are named by appending ".txt" to the basename of the
repository component it describes, and by appending ".dir" to each
directory patch component leading
On Thu, 8 Sep 2005, Chuck Lever wrote:
>
> in my case the merges were taking significantly longer than a half
> second. making this change is certainly not worth it if merges are
> running fast...
Note that in cold-cache cases, all the expense of read-tree is in actually
reading the tree obj
Chuck Lever wrote:
yay! are you also proposing some git tools to deal with these? it
would be great to have some version control (keep these like generation
files so we can see the history of revisions).
A Large Angry SCM wrote:
GIT Repository Annotation Convention
[...]
I'm not proposing
Linus Torvalds wrote:
On Thu, 8 Sep 2005, Junio C Hamano wrote:
Yes, the reading of three trees upfront is probably the culprit
in your case
However, note that _most_ tree reading just reads one.
Merges may take half a second, and yes, when I did it, the fact that we
move things around in
Darrin Thompson wrote:
What I'm going to do is actually an inversion of that. Publishing a
repository with the _intent_ of being merged into existing history, and
observing obvious naming conventions as the "prior arrangement".
I thought once I got the initial baseless merges done and committed
A Large Angry SCM <[EMAIL PROTECTED]> writes:
> Naming and Directory Structure
> --
> Annotations are named by appending ".txt" to the basename of the
> repository component it describes, and by appending ".dir" to each
> directory patch component leading to the reposit
Linus Torvalds <[EMAIL PROTECTED]> writes:
> So the data structure is optimized for a different case than reading in
> trees. Big deal. That optimization is definitely worth it: it allows us to
> do the read_cache() with the actual index entries being totally read-only
> (a linked list would ha
On Thu, 8 Sep 2005, Junio C Hamano wrote:
>
> Yes, the reading of three trees upfront is probably the culprit
> in your case
However, note that _most_ tree reading just reads one.
Merges may take half a second, and yes, when I did it, the fact that we
move things around in the array is by far
Chuck Lever <[EMAIL PROTECTED]> writes:
> Junio C Hamano wrote:
>> Chuck Lever <[EMAIL PROTECTED]> writes:
>>
> once the list implementation is working well, i plan to go back and
> replace it with something more sophisticated which can perform
> insertion, deletion, and searching efficiently.
GIT Repository Annotation Convention
GIT repositories can benefit from descriptions of /intent/ for portions
of the repository. This document formalizes a method to store those
descriptions in the repository.
Annotations
Annotations are UTF8 text
On Thu, 8 Sep 2005, Fredrik Kuivinen wrote:
> On Wed, Sep 07, 2005 at 02:33:42PM -0400, Daniel Barkalow wrote:
> > On Wed, 7 Sep 2005, Fredrik Kuivinen wrote:
> >
> > > Of the 500 merge commits that currently exists in the kernel
> > > repository 19 produces non-clean merges with git-merge-script
Junio C Hamano wrote:
Chuck Lever <[EMAIL PROTECTED]> writes:
for the past two weeks i've been attempting to replace the active_cache
array with an abstract data type (linked list just as a prototype) in
order to eliminate the need to use memmove() during insertions and
deletions.
one big
Kay Sievers wrote:
On Thu, Sep 08, 2005 at 10:45:45AM +0200, Sven Verdoolaege wrote:
On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:
Actually... should get it done. I'll see if I can sneak it in sometime soon...
This has been done at least twice already.
See e.g., http://www.l
On Thu, Sep 08, 2005 at 10:45:45AM +0200, Sven Verdoolaege wrote:
> On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:
> > Actually... should get it done. I'll see if I can sneak it in sometime
> > soon...
>
> This has been done at least twice already.
> See e.g., http://www.liacs.
On Thu, 2005-09-08 at 04:06, Junio C Hamano wrote:
> I would have appreciated if you said "Solaris portability patch"
> or somesuch on the subject line.
sorry, of course you're right..
the #ifndef __sun was done because getdomainname() doesn't exist on
solaris. (just for clarification)
> Curious.
On Thu, Sep 08, 2005 at 04:30:22PM +1200, Martin Langhoff wrote:
> Actually... should get it done. I'll see if I can sneak it in sometime
> soon...
This has been done at least twice already.
See e.g., http://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary
Check the archives for the othe
36 matches
Mail list logo
