Daniel Barkalow <[EMAIL PROTECTED]> writes:
> I'd actually like to introduce Documentation/technical/trivial-merge for
> this stuff; I think it would be good to have documentation for people who
> need to know how the stuff works, rather than just how to use it, so we
> get a balance between reams
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> What I missed was that the effect of causes_df_conflict is to give "no
> merge" for the entry, rather than giving an error overall. So I do need an
> equivalent.
Correct.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of
Fredrik Kuivinen <[EMAIL PROTECTED]> writes:
> The main changes compared to the previous version are:
>
> * Lots of clean up.
> * Some of the scripts have been renamed to better match the naming
> convention used in Git.
> * A new option ('-s') has been added to git-merge-cache
> * Unclean merge
> "Matthias" == Matthias Urlichs <[EMAIL PROTECTED]> writes:
Matthias> Paths in SVN are usually prefixed "/trunk/" (main branch) or
Matthias> "/branches/foo/" (branch foo); tagging is done by creating
Matthias> "/tags/bar", with the trunk (or branch) revision it is
Matthias> pointing to as its
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This also removes the tests for "$GIT_DIR" and "$GIT_OBJECT_DIRECTORY"
> being directories, since the other tests will implicitly test for that
> anyway (ie the tests for HEAD, refs and 00 would fail).
I've thought about it when you brought up the An
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
>
> It looks like stage 2 is currently special as the stage that's similar to
> the index/HEAD/working tree.
Ahh, yes. We do actually want that. So yes, we should make only stage 3
have the multiple entries.
> I'd be afraid of confusing everything b
On Sat, 27 Aug 2005, Linus Torvalds wrote:
> On Sat, 27 Aug 2005, Daniel Barkalow wrote:
> >
> > What I missed was that the effect of causes_df_conflict is to give "no
> > merge" for the entry, rather than giving an error overall. So I do need an
> > equivalent.
>
> Daniel,
> I'm not 100% sure wh
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
>
> What I missed was that the effect of causes_df_conflict is to give "no
> merge" for the entry, rather than giving an error overall. So I do need an
> equivalent.
Daniel,
I'm not 100% sure what you're trying to do, but one thing that might work
On Sat, 27 Aug 2005, Daniel Barkalow wrote:
> Okay, so it looks to me like the only cases that care about the contents
> of the index, other than in stage 0 (which is effectively another tree,
> but already in index-form rather than tree-form), are 2 and 3, and these
> only care because read-tree
On Sat, 27 Aug 2005, Junio C Hamano wrote:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
> > Part of threeway_merge, however, wants to search the rest of the cache for
> > interfering entries in some cases, which would have to happen differently,
> > because I won't have the cache completely fil
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
We used to allow a regular file there, but git-fsck-cache has been
complaining abo
Hi,
I have cleaned up the code for the merge algorithm quite a lot. It is
in a much better shape now.
The main changes compared to the previous version are:
* Lots of clean up.
* Some of the scripts have been renamed to better match the naming
convention used in Git.
* A new option ('-s') has
On Sat, 27 Aug 2005, Martin Langhoff wrote:
> On 8/27/05, Daniel Barkalow <[EMAIL PROTECTED]> wrote:
> > The problem with both of these (and doing it in the build system) is that,
> > when a project includes another project, you generally don't want whatever
> > revision of the included project ha
Martin Langhoff <[EMAIL PROTECTED]> writes:
> On 8/28/05, Kalle Valo <[EMAIL PROTECTED]> wrote:
>> The documentation says that it should be possible to update
>> incrementally from the CVS repository. Am I doing something wrong or
>> is this a bug?
>
> It _should_ work the way you are running it,
On 8/28/05, Kalle Valo <[EMAIL PROTECTED]> wrote:
> The documentation says that it should be possible to update
> incrementally from the CVS repository. Am I doing something wrong or
> is this a bug?
It _should_ work the way you are running it, so consider it a bug. Do
you think you can do some ti
Frank Sorenson <[EMAIL PROTECTED]> writes:
> The current cogito tree contains an invalid tag
> (junio-gpg-pub => 0918385dbd9656cab0d1d81ba7453d49bbc16250), and
> git-repack-script (and probably others) will die when git-rev-list
> tries to dump the objects. This patch changes it to complain, but
Junio C Hamano <[EMAIL PROTECTED]> writes:
> Daniel Barkalow <[EMAIL PROTECTED]> writes:
>
>> Part of threeway_merge, however, wants to search the rest of the cache for
>> interfering entries in some cases, which would have to happen differently,
>> because I won't have the cache completely filled
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This patch adds an option to git-repack-script to repack all objects,
including both packed and unpacked. This allows a full repack of
a git archive (current cogito packs from 39MB to 4.5MB, and git packs
from 4.4MB to 3.8MB).
Signed-off-by: Frank So
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The current cogito tree contains an invalid tag
(junio-gpg-pub => 0918385dbd9656cab0d1d81ba7453d49bbc16250), and
git-repack-script (and probably others) will die when git-rev-list
tries to dump the objects. This patch changes it to complain, but
conti
Daniel Barkalow <[EMAIL PROTECTED]> writes:
> Part of threeway_merge, however, wants to search the rest of the cache for
> interfering entries in some cases, which would have to happen differently,
> because I won't have the cache completely filled out beforehand. I'm
> trying to figure out what t
I am running git/cogito on MacOSX 10.3.x mostly as a client, and it
works pretty well. My main dev machines are Debian boxes, so the OSX
build is most often just fetching commits and running cg-log. So it's
not very intensive ;)
I get all my build dependencies from Fink, and also get diffutils fro
21 matches
Mail list logo
