* git merge failure: what next?
From: Daniel Quinlan @ 2009-01-06 0:41 UTC (permalink / raw)
To: git
I cannot figure out how to resolve a problem with git merge.
I usually use "git pull" to merge changes from a central repository
before pushing local changes to the central repository.
I've learned from bitter experience not to have changes in the
intermediate cache/stage/index, since that always leads to
confusion -- but it's possible I failed to follow that rule in this
case.
The working tree is currently dirty with lots of changes I'm not ready
to commit.
Anyway, now I get this:
> % git pull
> *** : needs update
> .
> .
> fatal: Entry 'correct/orblag/orblag' would be overwritten by merge.
> Cannot merge.
> Merge with strategy recursive failed.
> %
>
At this point, I usually do something like remove the 'correct/orblag/
orblag', knowing that I just want
whatever is in the repository (or ultimately, not caring, provided I
can get past this message).
However, that doesn't work:
> % rm correct/orblag/orblag
> rm: cannot remove `correct/orblag/orblag': No such file or directory
>
Also,
> % git mergetool
> No files need merging
>
I'm stuck.
A related problem is that although I'm usually able to get past this
problem by deleting
a file, this can be tedious as there may be multiple files with
conflicts, but git-merge only
lets me know about the first one it finds. Knowing all the conflicts
right off the bat would
give me an idea about the breadth of the problem.
Another possibility I might like to see is the CVS approach -- just
create combined files
with all the differences in them instead of hanging up on the first
conflict.
Suggestions?
Thanks,
-- danq
^ permalink raw reply
* Re: [EGIT PATCH] Fixed trivial warnings. Mainly parametrized raw types, added serialVersionUID, removed unnecessery throws.
From: Robin Rosenberg @ 2009-01-06 0:54 UTC (permalink / raw)
To: Vasyl' Vavrychuk; +Cc: git
In-Reply-To: <gjrgip$al9$1@ger.gmane.org>
måndag 05 januari 2009 00:26:02 skrev Vasyl' Vavrychuk:
> Not sure what is right:
> public abstract class AnyObjectId implements Comparable<ObjectId> {
> or
> public abstract class AnyObjectId implements Comparable<AnyObjectId> {
>
> IMHO second, but class AnyObjectId contains some compareTo(ObjectId).
>
> Also not sure if this bunch of changes is complete enough. Maybe it's better to make more fixes in this direction and then commit.
I broke up the patch and applied it just to be nice, with the exception of this change.
-- robin
^ permalink raw reply
* [PATCH] Documentation/urls-remotes.txt: Multiple fetch lines are allowed
From: jidanni @ 2009-01-06 1:06 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/urls-remotes.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/urls-remotes.txt b/Documentation/urls-remotes.txt
index 41ec777..d38f189 100644
--- a/Documentation/urls-remotes.txt
+++ b/Documentation/urls-remotes.txt
@@ -22,7 +22,7 @@ or even by a manual edit to the `$GIT_DIR/config` file. The URL of
this remote will be used to access the repository. The refspec
of this remote will be used by default when you do
not provide a refspec on the command line. The entry in the
-config file would appear like this:
+config file would appear as below. Multiple fetch lines are allowed.
------------
[remote "<name>"]
--
1.6.0.6
^ permalink raw reply related
* Re: git documentation
From: Jakub Narebski @ 2009-01-06 1:07 UTC (permalink / raw)
To: David Lang; +Cc: git, Alexey Mahotkin
In-Reply-To: <alpine.DEB.1.10.0901051745280.28514@asgard.lang.hm>
David Lang <david@lang.hm> writes:
> On lwn there is a comment (under the GNOME survey topic)
> http://lwn.net/Articles/313435/
>
> The Shlomi Fish "Better SCM" site for example is very clear that Git
> won't do a merge across a rename. It even has a citation for this
> claim. But as a Git user who has actually done a merge across a rename
> I know it works just fine, and anyone familiar with Git's internals
> will guess immediately why. Yet probably there is no line of
> documentation on the Git site or elsewhere that I can quote to justify
> adding a "Yes" to the comparison.
I have tried to add info about Git to Better SCM quite a long time
ago; it was finally added by (IIRC) Alexey Mahotkin for
http://versioncontrolblog.com and sent for inclusion in Better SCM to
Shlomi Fish.
Unfortunately it contains some factual errors. I have sent corrections
to Alexey, but didn't finish it:
"Git at Better SCM Initiative comparison of VCS (long)"
http://article.gmane.org/gmane.comp.version-control.git/97253
(see also other posts in this thread, and other posts with the same,
or similar, subject on git mailing list).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] Documentation/git-rebase.txt: effect of Control-C interrupt
From: jidanni @ 2009-01-06 1:17 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-rebase.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index c8ad86a..91ca138 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -210,6 +210,9 @@ OPTIONS
--abort::
Restore the original branch and abort the rebase operation.
+ (If you interrupt a rebase with control-C, you will still have
+ to issue a subsequent git rebase --abort to restore the
+ initial state.)
--skip::
Restart the rebasing process by skipping the current patch.
--
1.6.0.6
^ permalink raw reply related
* Re: git documentation
From: Miklos Vajna @ 2009-01-06 1:46 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.1.10.0901051745280.28514@asgard.lang.hm>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Mon, Jan 05, 2009 at 05:46:56PM -0800, david@lang.hm wrote:
> why. Yet probably there is no line of documentation on the Git site or
> elsewhere that I can quote to justify adding a "Yes" to the comparison.
I think it's documented in Documentation/merge-strategies.txt, under the
'recursive' merge strategy:
"Additionally this can detect and handle merges involving renames."
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Scott Chacon @ 2009-01-06 1:49 UTC (permalink / raw)
To: David Bryson; +Cc: Mike Hommey, git
In-Reply-To: <20090105212716.GJ6595@eratosthenes.cryptobackpack.org>
Hi,
On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>
>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>> top right end, is "safe", trademark/copyright-wise. It looks too much
>> like ???????????????(D??mo-kun), the NHK mascot.
>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>
> I think Scott mentioned at GitTogether that they paid the same artist
> design some artwork for them including that tree munching monster and an
> octopus.
>
> Scott do you care to elaborate ?
I bought rights to the image from iStockPhoto, we can use it online
for whatever we want to. The only restriction is that we can't sell
stuff with the image on it. I have no idea what NHK is, nor do I know
how TM/copyright issues would work in this regard - (the site is
hosted in the US, has NHK registered TM for that here?) - but I doubt
it really matters. If I get a cease and desist, I'll replace the
image, but to me it doesn't seem close enough to infringe and I doubt
they would care.
Btw, I would also like to say in general that the response to this
from emails sent to me personally (my address is at the bottom of the
page) has been very positive and I've even received a few patches that
are now live.
Also, Miklos : your patch changes the format of the output and doesn't
speed things up or anything, so I'm just sticking with the current
script for now (unless I'm missing something).
Boyd Gerber: I'm confused - the mailing list archive link on the home
page points to the Gmane page, which is completely up to date. Is
there a link I'm missing?
Thanks,
Scott
>
> Dave
>
>
^ permalink raw reply
* Re: [ANNOUNCE] Git homepage change
From: Baz @ 2009-01-06 2:17 UTC (permalink / raw)
To: Scott Chacon; +Cc: David Bryson, Mike Hommey, git
In-Reply-To: <d411cc4a0901051749p2ef880bub45bba1c0d41bfc7@mail.gmail.com>
2009/1/6 Scott Chacon <schacon@gmail.com>:
> Hi,
>
> On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
>> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>>
>>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>>> top right end, is "safe", trademark/copyright-wise. It looks too much
>>> like ???????????????(D??mo-kun), the NHK mascot.
>>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>>
>> I think Scott mentioned at GitTogether that they paid the same artist
>> design some artwork for them including that tree munching monster and an
>> octopus.
>>
>> Scott do you care to elaborate ?
>
> I bought rights to the image from iStockPhoto, we can use it online
> for whatever we want to. The only restriction is that we can't sell
> stuff with the image on it. I have no idea what NHK is, nor do I know
> how TM/copyright issues would work in this regard - (the site is
> hosted in the US, has NHK registered TM for that here?) - but I doubt
> it really matters. If I get a cease and desist, I'll replace the
> image, but to me it doesn't seem close enough to infringe and I doubt
> they would care.
NHK are the public broadcaster in Japan, and Domo-kun is their mascot.
Apparently the NHK spots with Domo-kun are also used in the US on
Nickelodeon. It's like the NBC peacock, or the BBC test card girl:
instantly recognizable to anyone who watched that channel.
And yes, there is a US trademark:
http://tess2.uspto.gov/bin/showfield?f=doc&state=3pcqf.6.1
No connection to NHK at all, but I thought you'd used Domo
deliberately when I first saw that logo, so got curious. The site is
great, btw.
Cheers,
Baz
>
> Btw, I would also like to say in general that the response to this
> from emails sent to me personally (my address is at the bottom of the
> page) has been very positive and I've even received a few patches that
> are now live.
>
> Also, Miklos : your patch changes the format of the output and doesn't
> speed things up or anything, so I'm just sticking with the current
> script for now (unless I'm missing something).
>
> Boyd Gerber: I'm confused - the mailing list archive link on the home
> page points to the Gmane page, which is completely up to date. Is
> there a link I'm missing?
>
> Thanks,
> Scott
>
>>
>> Dave
>>
>>
> --
> 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
>
^ permalink raw reply
* [PATCH] Documentation/gitcore-tutorial.txt: HEAD not symlink these days
From: jidanni @ 2009-01-06 2:18 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/gitcore-tutorial.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index e4dd551..05328cf 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -751,7 +751,7 @@ Creating a new branch
Branches in git are really nothing more than pointers into the git
object database from within the `.git/refs/` subdirectory, and as we
-already discussed, the `HEAD` branch is nothing but a symlink to one of
+already discussed, the `HEAD` branch is nothing but a pointer to one of
these object pointers.
You can at any time create a new branch by just picking an arbitrary
--
1.6.0.6
^ permalink raw reply related
* Re: [ANNOUNCE] Git homepage change
From: Baz @ 2009-01-06 2:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: David Bryson, Mike Hommey, git
In-Reply-To: <2faad3050901051817g1381478ex9f5cb6f0404e5f86@mail.gmail.com>
2009/1/6 Baz <brian.ewins@gmail.com>:
> 2009/1/6 Scott Chacon <schacon@gmail.com>:
>> Hi,
>>
>> On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
>>> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>>>
>>>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>>>> top right end, is "safe", trademark/copyright-wise. It looks too much
>>>> like ???????????????(D??mo-kun), the NHK mascot.
>>>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>>>
>>> I think Scott mentioned at GitTogether that they paid the same artist
>>> design some artwork for them including that tree munching monster and an
>>> octopus.
>>>
>>> Scott do you care to elaborate ?
>>
>> I bought rights to the image from iStockPhoto, we can use it online
>> for whatever we want to. The only restriction is that we can't sell
>> stuff with the image on it. I have no idea what NHK is, nor do I know
>> how TM/copyright issues would work in this regard - (the site is
>> hosted in the US, has NHK registered TM for that here?) - but I doubt
>> it really matters. If I get a cease and desist, I'll replace the
>> image, but to me it doesn't seem close enough to infringe and I doubt
>> they would care.
>
> NHK are the public broadcaster in Japan, and Domo-kun is their mascot.
> Apparently the NHK spots with Domo-kun are also used in the US on
> Nickelodeon. It's like the NBC peacock, or the BBC test card girl:
> instantly recognizable to anyone who watched that channel.
>
> And yes, there is a US trademark:
> http://tess2.uspto.gov/bin/showfield?f=doc&state=3pcqf.6.1
Sorry, that link uses cookie state. Here's one directly to the TM:
http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=77266968
>
> No connection to NHK at all, but I thought you'd used Domo
> deliberately when I first saw that logo, so got curious. The site is
> great, btw.
>
> Cheers,
> Baz
>
>>
>> Btw, I would also like to say in general that the response to this
>> from emails sent to me personally (my address is at the bottom of the
>> page) has been very positive and I've even received a few patches that
>> are now live.
>>
>> Also, Miklos : your patch changes the format of the output and doesn't
>> speed things up or anything, so I'm just sticking with the current
>> script for now (unless I'm missing something).
>>
>> Boyd Gerber: I'm confused - the mailing list archive link on the home
>> page points to the Gmane page, which is completely up to date. Is
>> there a link I'm missing?
>>
>> Thanks,
>> Scott
>>
>>>
>>> Dave
>>>
>>>
>> --
>> 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
>>
>
^ permalink raw reply
* [PATCH] Documentation/gittutorial.txt: clarify git branch -d
From: jidanni @ 2009-01-06 2:40 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/gittutorial.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 7892244..4581a5a 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -260,11 +260,11 @@ At this point you could delete the experimental branch with
$ git branch -d experimental
------------------------------------------------
-This command ensures that the changes in the experimental branch are
-already in the current branch.
+This command makes sure that the changes in the experimental branch are
+already in the current branch before deleting.
If you develop on a branch crazy-idea, then regret it, you can always
-delete the branch with
+force deletion of the branch with
-------------------------------------
$ git branch -D crazy-idea
--
1.6.0.6
^ permalink raw reply related
* Re: [ANNOUNCE] Git homepage change
From: Miklos Vajna @ 2009-01-06 2:43 UTC (permalink / raw)
To: Scott Chacon; +Cc: David Bryson, Mike Hommey, git
In-Reply-To: <d411cc4a0901051749p2ef880bub45bba1c0d41bfc7@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 479 bytes --]
On Mon, Jan 05, 2009 at 05:49:01PM -0800, Scott Chacon <schacon@gmail.com> wrote:
> Also, Miklos : your patch changes the format of the output and doesn't
> speed things up or anything, so I'm just sticking with the current
> script for now (unless I'm missing something).
I think the patch just makes things simpler (why not using -s if you
then later use grep to drop what -s would hide?), and Adeodato's patch
updates the ruby part as well. But of course it's up to you. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation/gitcore-tutorial.txt: HEAD not symlink these days
From: Miklos Vajna @ 2009-01-06 2:44 UTC (permalink / raw)
To: jidanni; +Cc: git, gitster
In-Reply-To: <1231208319-12673-1-git-send-email-jidanni@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 451 bytes --]
On Tue, Jan 06, 2009 at 10:18:39AM +0800, jidanni@jidanni.org wrote:
> Branches in git are really nothing more than pointers into the git
> object database from within the `.git/refs/` subdirectory, and as we
> -already discussed, the `HEAD` branch is nothing but a symlink to one of
> +already discussed, the `HEAD` branch is nothing but a pointer to one of
> these object pointers.
The currect term for HEAD is a 'symref', see the glossary. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Documentation/gitcore-tutorial.txt: HEAD not symlink these days
From: jidanni @ 2009-01-06 2:47 UTC (permalink / raw)
To: vmiklos; +Cc: git, gitster
In-Reply-To: <20090106024443.GC21154@genesis.frugalware.org>
MV> The currect term for HEAD is a 'symref', see the glossary. ;-)
OK please change it for me, as today is my junior patching practice
day, and a patch to a patch is way over my head.
^ permalink raw reply
* [PATCH] Documentation/gittutorial.txt: minimum 4 chars to match SHA1s
From: jidanni @ 2009-01-06 2:49 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/gittutorial.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 4581a5a..42c2c91 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -481,7 +481,8 @@ $ git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7
-------------------------------------
But there are other ways to refer to commits. You can use any initial
-part of the name that is long enough to uniquely identify the commit:
+part of the name that is long enough to uniquely identify the commit
+(minimum is four characters):
-------------------------------------
$ git show c82a22c39c # the first few characters of the name are
--
1.6.0.6
^ permalink raw reply related
* git-branch man page contains rendered nroff
From: jidanni @ 2009-01-06 3:06 UTC (permalink / raw)
To: git
$ make git-branch.1 && man -l git-branch.1|col -b|fgrep .ft|sort|uniq -c
2 .ft
2 .ft C
Yuck.
^ permalink raw reply
* Re: git-branch man page contains rendered nroff
From: jidanni @ 2009-01-06 3:12 UTC (permalink / raw)
To: git
In-Reply-To: <87hc4dnner.fsf@jidanni.org>
OK, I am probably lacking some part of the tool chain that is not
warning me. Never mind.
^ permalink raw reply
* [PATCH] Documentation/git-show-branch.txt: compact -g
From: jidanni @ 2009-01-06 3:14 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/git-show-branch.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index 8277577..7e9ff37 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -99,12 +99,12 @@ OPTIONS
will show the revisions given by "git rev-list {caret}master
topic1 topic2"
+-g::
--reflog[=<n>[,<base>]] [<ref>]::
Shows <n> most recent ref-log entries for the given
ref. If <base> is given, <n> entries going back from
that entry. <base> can be specified as count or date.
- `-g` can be used as a short-hand for this option. When
- no explicit <ref> parameter is given, it defaults to the
+ When no explicit <ref> parameter is given, it defaults to the
current branch (or `HEAD` if it is detached).
Note that --more, --list, --independent and --merge-base options
--
1.6.0.6
^ permalink raw reply related
* git rebase --interactive needn't call editor for noop
From: jidanni @ 2009-01-06 3:17 UTC (permalink / raw)
To: git
On occasions when git rebase --interactive will invoke the editor with
the word "noop" in the buffer, it would be better if it just said that
on the command line instead of bothering to call the editor.
^ permalink raw reply
* gitk --help doesn't
From: jidanni @ 2009-01-06 3:22 UTC (permalink / raw)
To: git
gitk --help doesn't print the man text, instead it furls headlong
into, well, gitk --help which of course is not a happy scene.
^ permalink raw reply
* gitk: no key binding to bring up key bindings
From: jidanni @ 2009-01-06 3:23 UTC (permalink / raw)
To: git
Inside gitk there is no key bound to bring up the key bindings window.
Presently one must use the mouse to bring it up.
^ permalink raw reply
* git-completion.bash missing --help
From: jidanni @ 2009-01-06 3:29 UTC (permalink / raw)
To: git; +Cc: spearce
git-completion.bash seems to be missing --help. Hitting TAB just shows e.g.,
$ git add --<TAB>
--dry-run --ignore-errors --interactive --patch --refresh --update
Only for plain
$ git --<TAB>
is one able to complete --help.
^ permalink raw reply
* [PATCH] Documentation/merge-strategies.txt, diff-options: grammar
From: jidanni @ 2009-01-06 3:52 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/diff-options.txt | 4 ++--
Documentation/merge-strategies.txt | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index b432d25..9cd162f 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -143,11 +143,11 @@ endif::git-format-patch[]
that matches other criteria, nothing is selected.
--find-copies-harder::
- For performance reasons, by default, `-C` option finds copies only
+ For performance reasons, by default, the `-C` option finds copies only
if the original file of the copy was modified in the same
changeset. This flag makes the command
inspect unmodified files as candidates for the source of
- copy. This is a very expensive operation for large
+ the copy. This is a very expensive operation for large
projects, so use it with caution. Giving more than one
`-C` option has the same effect.
diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 1276f85..3cef90a 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -11,7 +11,7 @@ resolve::
recursive::
This can only resolve two heads using 3-way merge
algorithm. When there are more than one common
- ancestors that can be used for 3-way merge, it creates a
+ ancestor that can be used for 3-way merge, it creates a
merged tree of the common ancestors and uses that as
the reference tree for the 3-way merge. This has been
reported to result in fewer merge conflicts without
--
1.6.0.6
^ permalink raw reply related
* [PATCH] Documentation/diff-generate-patch.txt the truth about "diff --git"
From: jidanni @ 2009-01-06 4:01 UTC (permalink / raw)
To: git; +Cc: gitster
Signed-off-by: jidanni <jidanni@jidanni.org>
---
Documentation/diff-generate-patch.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/diff-generate-patch.txt b/Documentation/diff-generate-patch.txt
index 0f25ba7..dfc186c 100644
--- a/Documentation/diff-generate-patch.txt
+++ b/Documentation/diff-generate-patch.txt
@@ -19,6 +19,7 @@ diff format.
The `a/` and `b/` filenames are the same unless rename/copy is
involved. Especially, even for a creation or a deletion,
`/dev/null` is _not_ used in place of `a/` or `b/` filenames.
+(Diff(1) does not actually have a --git option.)
+
When rename/copy is involved, `file1` and `file2` show the
name of the source file of the rename/copy and the name of
--
1.6.0.6
^ permalink raw reply related
* Re: [ANNOUNCE] Git homepage change
From: Boyd Lynn Gerber @ 2009-01-06 4:24 UTC (permalink / raw)
To: Scott Chacon; +Cc: David Bryson, Mike Hommey, git
In-Reply-To: <d411cc4a0901051749p2ef880bub45bba1c0d41bfc7@mail.gmail.com>
On Mon, 5 Jan 2009, Scott Chacon wrote:
> On Mon, Jan 5, 2009 at 1:27 PM, David Bryson <david@statichacks.org> wrote:
>> On Mon, Jan 05, 2009 at 08:40:11PM +0100 or thereabouts, Mike Hommey wrote:
>>>
>>> FWIW, I think the "mascot" or whatever it is supposed to be, on the
>>> top right end, is "safe", trademark/copyright-wise. It looks too much
>>> like ???????????????(D??mo-kun), the NHK mascot.
>>> http://images.google.co.jp/images?q=%E3%81%A9%E3%83%BC%E3%82%82%E3%81%8F%E3%82%93&ie=UTF-8&oe=UTF-8&hl=en&um=1&sa=N&tab=wi
>>
>> I think Scott mentioned at GitTogether that they paid the same artist
>> design some artwork for them including that tree munching monster and an
>> octopus.
>>
>> Scott do you care to elaborate ?
>
> I bought rights to the image from iStockPhoto, we can use it online
> for whatever we want to. The only restriction is that we can't sell
> stuff with the image on it. I have no idea what NHK is, nor do I know
> how TM/copyright issues would work in this regard - (the site is
> hosted in the US, has NHK registered TM for that here?) - but I doubt
> it really matters. If I get a cease and desist, I'll replace the
> image, but to me it doesn't seem close enough to infringe and I doubt
> they would care.
>
> Btw, I would also like to say in general that the response to this
> from emails sent to me personally (my address is at the bottom of the
> page) has been very positive and I've even received a few patches that
> are now live.
>
> Also, Miklos : your patch changes the format of the output and doesn't
> speed things up or anything, so I'm just sticking with the current
> script for now (unless I'm missing something).
>
> Boyd Gerber: I'm confused - the mailing list archive link on the home
> page points to the Gmane page, which is completely up to date. Is
> there a link I'm missing?
This is the link
You can also ask the Git community directly at our git@vger.kernel.org
mailing list. with the link below.
http://dir.gmane.org/gmane.comp.version-control.git
On this page the following...
Other mailing list archives for this list:
1. The Mail Archive
http://www.mail-archive.com/git@vger.kernel.org/
And this states this link
http://www.mail-archive.com/git@vger.kernel.org/
And the lastest is 2005 and earlier.
--
Boyd Gerber <gerberb@zenez.com> 801 849-0213
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
^ 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