* Re: More merge questions (why doesn't this work?)
From: Junio C Hamano @ 2005-12-02 22:00 UTC (permalink / raw)
To: git
In-Reply-To: <20051202213214.27282.qmail@science.horizon.com>
<linux <at> horizon.com> writes:
> + git merge 'Merge a, b, c' master a b c
> Trying simple merge with a
> Trying simple merge with b
> Trying simple merge with c
> Simple merge did not work, trying automatic merge.
> Removing c
> fatal: merge program failed
> No merge strategy handled the merge.
I think this is the same problem I fixed yesterday after the breakage report
from Luben Tuikov. You need the ce3ca275452cf069eb6451d6f5b0f424a6f046aa commit.
Sorry about that.
Could you try the latest and see if it still breaks?
^ permalink raw reply
* Re: More merge questions
From: linux @ 2005-12-02 21:56 UTC (permalink / raw)
To: git; +Cc: junkio, linux
In-Reply-To: <7vbqzz2qc8.fsf@assigned-by-dhcp.cox.net>
Just thinking about the difference between 2-way and 3-way merge...
*Mostly* a 2-way merge is just a 3-way merge where one of the ways
is taken from the index rather than from a tree. But there
are some subtle differences.
This diffierence is what forces octopus merge to form intermediate tree
objects when doing its merges. If there was a way to merge directly
into the index, octopus merge wouldn't have to make intermediate tree
objects that would have to be garbage-collected later.
(Indeed, I originally assumed that Octopus did all its merges in the
index; it's only when I traced the code that I saw it calls git-write-tree
multiple times.)
Is the time saved, and space not wasted, worth implementing a 2-way merge
that more exactly matches 3-way? It should be fairly straightforward
to share the actual merging code.
Opinions solicited.
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: Junio C Hamano @ 2005-12-02 21:41 UTC (permalink / raw)
To: git
In-Reply-To: <4390B64E.20601@zytor.com>
H. Peter Anvin <hpa <at> zytor.com> writes:
> Actually, it turns out the two servers were running different versions;
> one 0.99.9j and one 0.99.9k. They're both running 0.99.9j now.
>
> 0.99.9k is clearly bad.
This is troublesome, since I do not think it is hitting the one that was
causing trouble for the snapshotting procedure, and I cannot seem to reproduce
it with random set of flags and parameters myself.
I know you run it with --inetd, but what other parameters do you run it with,
and in what kind of environment? Specifically:
- do you use whitelist, like "git-daemon --inetd --export-all /pub/scm"?
- if so, are any symlinks involved in /pub area?
- if so, does adding real path like /mnt/real/pub/scm for /pub/scm help?
- do you run with --strict-paths?
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: linux @ 2005-12-02 21:32 UTC (permalink / raw)
To: junkio, linux; +Cc: git
In-Reply-To: <7vbqzz2qc8.fsf@assigned-by-dhcp.cox.net>
> We earlier agreed that the table in t/t1000 test should go and
> superseded by trivial-merge.txt, so what the table says right
> now is a non-issue, but we _might_ want to revisit the issue of
> what should happen in case #8 and #10 sometime in the future, as
> the last three lines of trivial-merge.txt mentions. I'd say we
> should leave things as they are for now, though.
But back to my original problem... I don't much care whether it's
done as a trivial merge or a non-trivial merge, but why the #%@#$ can't
it be done as an automatic merge?
As I said, I'm trying to build (and write down) a mental model, so the
behaviour of git can be predicted. My mental model says this should
work. It doesn't. Therefore my mental model is incorrect, and I
don't actually understand what it's doing.
#!/bin/bash -xe
rm -rf .git
git-init-db
echo "File A" > a
echo "File B" > b
echo "File C" > c
git-add a b c
git-commit -a -m "Octopus test repository"
git-checkout -b a
echo "Modifications to a" >> a
git-commit -a -m "Modified file a"
git-checkout -b b master
echo "Modifications to b" >> b
git-commit -a -m "Modified file b"
git-checkout -b c master
rm c
git-commit -a -m "Deleted file c"
git-checkout master
git merge "Merge a, b, c" master a b c
produces...
+ git merge 'Merge a, b, c' master a b c
Trying simple merge with a
Trying simple merge with b
Trying simple merge with c
Simple merge did not work, trying automatic merge.
Removing c
fatal: merge program failed
No merge strategy handled the merge.
> *3* I did that, and it renders HTML side nicer, but it breaks
> manpages X-<. Inputs from asciidoc gurus are appreciated.
I tried adding " +" at end-of-line, which is supposed to force a
line break, but that didn't have any effect.
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: H. Peter Anvin @ 2005-12-02 21:02 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: git
In-Reply-To: <20051202211250.GA11384@mipter.zuzino.mipt.ru>
Alexey Dobriyan wrote:
>
> Heisenbug :-\. I'll send IP next time.
>
Actually, it turns out the two servers were running different versions;
one 0.99.9j and one 0.99.9k. They're both running 0.99.9j now.
0.99.9k is clearly bad.
-hpa
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: Alexey Dobriyan @ 2005-12-02 21:12 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <43909963.60901@zytor.com>
On Fri, Dec 02, 2005 at 10:58:43AM -0800, H. Peter Anvin wrote:
> Alexey Dobriyan wrote:
> >$ git pull
> >Already up-to-date.
> >$ git pull
> >Already up-to-date.
> >$ git pull
> >Already up-to-date.
> >$ git pull
> >fatal: unexpected EOF
> >Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> >$ git pull
> >fatal: unexpected EOF
> >Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> >$ git pull
> >Already up-to-date.
> >$ git pull
> >fatal: unexpected EOF
> >Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> >$ git pull
> >fatal: unexpected EOF
> >Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> >
> >Ditto for "git fetch --tags".
> >
> >Can somebody explain what's going on?
> >
>
> Do you know which IP address is aborting? There are two servers behind
> git.kernel.org.
Heisenbug :-\. I'll send IP next time.
~/linux/linux-linus $ while true; do git pull; done
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
Already up-to-date.
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: Junio C Hamano @ 2005-12-02 20:32 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: git
In-Reply-To: <20051202130911.GY8383MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
>> 3. It does not matter; nobody types that command by hand.
I should have said "nobody should need to type that, otherwise
fix your Porcelain".
> I do. git commit won't let me commit an empty tree, or at
> least I haven't figured out how to make it do that.
You are right, at least for the initial commit (for subsequent
commits it happily commits an empty tree).
Now why anybody would want to it is a different matter. Is it
because you would want to record that your project started from
scratch, as opposed to some import from an existing non
versioned (or versioned by another SCM) working tree?
> I also used it when, after resolving a merge initiated by
> cg-merge, cogito (or at least the version I had installed
> at the time) wouldn't let me commit it because a new file
> I had pulled in contained non-ascii characters in its name.
That sounds like a simple Porcelain bug and I hope neither
Cogito or git wouldn't have that problem now.
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: Junio C Hamano @ 2005-12-02 20:31 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051202113713.11618.qmail@science.horizon.com>
linux@horizon.com writes:
> Um, I'm looking at the one-side remove case, which t/t1000 calls
>
> O A B result index requirements
> -------------------------------------------------------------------
> 10 exists O==A missing remove ditto
> ------------------------------------------------------------------
>
> while trivial-merge.txt says is:
>
> case ancest head remote result
> ----------------------------------------
> 10 ancest^ ancest (empty) no merge
>
> I assumed the test case was probably more accurate, given that it's coupled
> to code which actually verifies the behaviour.
You are right. And the test expects something different from
that table in t/t1000 test. Relevant are the lines for ND (one
side No action the other Delete) in the "expected" file. The
test expects the result to be unmerged.
Interesting is that it did so from the day one [*1*]. The very
original read-tree 3-way was quite conservative and left more
things unmerged for the policy script to handle, and it is not
surprising it started like this, but during the course of the
project I thought read-tree was made to collapse more cases in
index. I am a bit surprised we did not loosen it ever since
[*2*]. Thanks for pointing out the discrepancy.
We earlier agreed that the table in t/t1000 test should go and
superseded by trivial-merge.txt, so what the table says right
now is a non-issue, but we _might_ want to revisit the issue of
what should happen in case #8 and #10 sometime in the future, as
the last three lines of trivial-merge.txt mentions. I'd say we
should leave things as they are for now, though.
> --reset::
> -
> - Same as -m except that unmerged entries will be silently ignored.
> + Same as -m except that unmerged entries will be silently overwritten
> + (instead of failing).
Thanks.
> "Do something really complicated and then commit it to the repository"
> is a frightening concept. "Do something really complicated and
> then stop and wait for you to see if it was what you expected" is
> a lot more comforting.
Fair enough.
>>> 7) The git-tag man page could use a little better description of -a.
>
>> Please. It should have the same "OPTIONS" section as others do.
>
> I know NOTHING about asciidoc, and really wish I could fix its
> lack-of-line-break problem:
Thanks for pointing that one ont. I think Josef recently did
similar linebreak on git-mv page. I'll try and see if I can
mimic what he did [*3*].
> diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
> index 95de436..7635b1e 100644
> --- a/Documentation/git-tag.txt
> +++ b/Documentation/git-tag.txt
Thanks; applied.
[Footnotes]
*1* A pickaxe example:
$ git whatchanged -p -S'100644 1 ND
100644 2 ND'
shows only two commits. One is the first version of the test,
and the other is to adjust for the output format from
*2* Further archaeology revealed that I did loosening primarily
for the 2-way side, and did not touch much about 3-way merge
other than what used to be marked with ALT. There was no 10ALT
ever so it shows that my memory is simply faulty ;-).
*3* I did that, and it renders HTML side nicer, but it breaks
manpages X-<. Inputs from asciidoc gurus are appreciated.
^ permalink raw reply
* Re: How can I specify a non-standard TCP port for a git+ssh connection?
From: linux @ 2005-12-02 19:31 UTC (permalink / raw)
To: aj, git, torvalds
Actually, you don't need any git support. ssh allows you to set up
"virtual hosts" with any combination of options you like.
Host <virtual>
HostName <physical>
Port <nonstandard>
User <whoever>
IdentityFile <custom>
ForwardAgent no
So typing "ssh <virtual>" will have the effect of
ssh <whoever>@<physical> -p <nonstandard> -i <custom> -a
Quite often, you let <virtual> == <physical>, so it's "custom settings
for talking to this host", but you can have multiple different virtual
names that all map to the same physical host.
But the point is that as long as you can pass a hostname through to ssh,
you can carry as many custom settings as you like with it.
^ permalink raw reply
* Re: git pull aborts in 50% of cases
From: H. Peter Anvin @ 2005-12-02 18:58 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: git
In-Reply-To: <20051202190412.GA10757@mipter.zuzino.mipt.ru>
Alexey Dobriyan wrote:
> $ git pull
> Already up-to-date.
> $ git pull
> Already up-to-date.
> $ git pull
> Already up-to-date.
> $ git pull
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> $ git pull
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> $ git pull
> Already up-to-date.
> $ git pull
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git
> $ git pull
> fatal: unexpected EOF
> Fetch failure: git://git.kernel.org/pub/scm/git/git.git
>
> Ditto for "git fetch --tags".
>
> Can somebody explain what's going on?
>
Do you know which IP address is aborting? There are two servers behind
git.kernel.org.
-hpa
^ permalink raw reply
* git pull aborts in 50% of cases
From: Alexey Dobriyan @ 2005-12-02 19:04 UTC (permalink / raw)
To: git
$ git pull
Already up-to-date.
$ git pull
Already up-to-date.
$ git pull
Already up-to-date.
$ git pull
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
$ git pull
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
$ git pull
Already up-to-date.
$ git pull
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
$ git pull
fatal: unexpected EOF
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
Ditto for "git fetch --tags".
Can somebody explain what's going on?
^ permalink raw reply
* Re: How can I specify a non-standard TCP port for a git+ssh connection?
From: Linus Torvalds @ 2005-12-02 16:07 UTC (permalink / raw)
To: Andreas Jochens; +Cc: git
In-Reply-To: <20051202124801.GA20332@andaco.de>
On Fri, 2 Dec 2005, Andreas Jochens wrote:
>
> is there a simple way to specify a non-standard TCP port for a git+ssh
> connection?
Use the ".ssh/config" file ;)
> The following small patch would allow to use an URL like
> 'git+ssh://user@hostname:port/path' to specify an arbitrary
> port for the ssh connection.
Maybe. On the other hand, I think we'd be better off with perhaps some
way to just specify arbitrary options to the "ssh" program. Sometimes you
might want to specify identity-files etc too.
Linus
^ permalink raw reply
* Re: [Question] Fetching a new branch from remote
From: Carl Baldwin @ 2005-12-02 15:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6eoinqa.fsf@assigned-by-dhcp.cox.net>
The documentation below does make this more clear. Now that you've
explained it I can see it useful to fetch a remote head without creating
a local one. I simply hadn't thought of this scenerio.
Thank you for the explanation.
Cheers,
Carl
On Thu, Dec 01, 2005 at 12:09:01PM -0800, Junio C Hamano wrote:
> Carl Baldwin <cnb@fc.hp.com> writes:
>
> > I would expect this to do it:
> >
> > % git fetch -f <url> new-branch
> >
> > But, it doesn't.
> >
> > Actually, I just noticed that this accomplishes the desired result...
> >
> > % git fetch <url> new-branch:new-branch
>
> First, '-f' means "allow overriding the fast-forward check when
> updating an existing branch". This can be done per refspec by
> saying "+rbranch:lbranch" but if you are fetching more than one
> remote branches at once (especially through "remotes" shorthand)
> the option can be used to allow override of all of them.
>
> A single token <refspec> defaults to "<refspec>:" (meaning,
> "fetch but do not muck with our branches") is deliberate. When
> I get a pull request "please pull from git://u/r/l/ send2junio branch",
> I do not "git pull git://u/r/l/ send2junio" right away, but do
> "git fetch git://u/r/l/ send2junio" and inspect FETCH_HEAD with
> various combinations of "git diff master..FETCH_HEAD" and
> friends. I do _not_ want it to create send2junio branch in my
> repository with that. Also "git pull git://u/r/l/ send2junio"
> would internally run "git fetch git://u/r/l/ send2junio" and
> then runs merge, and I do not want that to create send2junio
> branch in my repository either. The latter could be prevented by
> adding an extra flag to git-fetch to tell it not to default
> a single token <refspec> to "<refspec>:<refspec>" and pass that
> flag from git-pull, though.
>
> I just found out that the documentation for '-f' flag is simply
> missing. I'd propose to add the following. Thanks for noticing.
>
> -- >8 --
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index a25d04a..200c9b2 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -4,6 +4,11 @@
> option old data in `.git/FETCH_HEAD` will be overwritten.
>
> -f, \--force::
> + When `git-fetch` is used with `<rbranch>:<lbranch>`
> + refspec, it refuses to update the local branch
> + `<lbranch>` unless the remote branch `<rbranch>` it
> + fetches is a descendant of `<lbranch>`. This option
> + overrides that check.
>
> -t, \--tags::
> By default, the git core utilities will not fetch and store
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: resolve (merge) problems
From: Luben Tuikov @ 2005-12-02 13:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk6eo9jag.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > $python -V
> > Python 2.4.2
> > $which python
> > /usr/local/bin/python
>
> Since you do not want to use /usr/bin/python but from your own
> location /usr/local/bin/python, I presume you built git with
>
> $ make PYTHON_PATH=/usr/local/bin/python
>
> among other installation specific override needed on your
> machine?
Oops :-) (lol)
Thanks,
Luben
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: Sven Verdoolaege @ 2005-12-02 13:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: linux, git
In-Reply-To: <7vacfj6c4l.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 02, 2005 at 02:12:42AM -0800, Junio C Hamano wrote:
> linux@horizon.com writes:
> > 3) Dumb question: why does "git-commit-tree" need "-p" before the
> > parent commit arguments? Isn't just argv[2]..argv[argc-1]
> > good enough?
>
> 3. It does not matter; nobody types that command by hand.
>
I do. git commit won't let me commit an empty tree, or at
least I haven't figured out how to make it do that.
I also used it when, after resolving a merge initiated by
cg-merge, cogito (or at least the version I had installed
at the time) wouldn't let me commit it because a new file
I had pulled in contained non-ascii characters in its name.
skimo
^ permalink raw reply
* How can I specify a non-standard TCP port for a git+ssh connection?
From: Andreas Jochens @ 2005-12-02 12:48 UTC (permalink / raw)
To: git
Hello,
is there a simple way to specify a non-standard TCP port for a git+ssh
connection?
The following small patch would allow to use an URL like
'git+ssh://user@hostname:port/path' to specify an arbitrary
port for the ssh connection.
Regards
Andreas Jochens
connect.c | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index 93f6f80..4b640dd 100644
--- a/connect.c
+++ b/connect.c
@@ -560,7 +560,7 @@ static int git_proxy_connect(int fd[2],
int git_connect(int fd[2], char *url, const char *prog)
{
char command[1024];
- char *host, *path = url;
+ char *host, *port = NULL, *path = url;
char *colon = NULL;
int pipefd[2][2];
pid_t pid;
@@ -597,6 +597,10 @@ int git_connect(int fd[2], char *url, co
path = strdup(ptr);
*ptr = '\0';
+ if ((colon = strchr(host, ':'))) {
+ *colon = '\0';
+ port = colon + 1;
+ }
}
if (protocol == PROTO_GIT) {
@@ -626,7 +630,11 @@ int git_connect(int fd[2], char *url, co
ssh_basename = ssh;
else
ssh_basename++;
- execlp(ssh, ssh_basename, host, command, NULL);
+ if (port)
+ execlp(ssh, ssh_basename, "-p", port, host,
+ command, NULL);
+ else
+ execlp(ssh, ssh_basename, host, command, NULL);
}
else
execlp("sh", "sh", "-c", command, NULL);
^ permalink raw reply related
* Re: More merge questions (why doesn't this work?)
From: linux @ 2005-12-02 11:37 UTC (permalink / raw)
To: junkio; +Cc: git, linux
In-Reply-To: <20051202091946.1631.qmail@science.horizon.com>
> Yes. The reason is git-read-tree's behaviour was changed
> underneath while octopus was looking elsewhere ;-). See
> Documentation/technical/trivial-merge.txt, last couple of
> lines.
> There are two schools of thoughts about "both sides remove"
> (case #10) case.
Um, I'm looking at the one-side remove case, which t/t1000 calls
O A B result index requirements
-------------------------------------------------------------------
10 exists O==A missing remove ditto
------------------------------------------------------------------
while trivial-merge.txt says is:
case ancest head remote result
----------------------------------------
10 ancest^ ancest (empty) no merge
I assumed the test case was probably more accurate, given that it's coupled
to code which actually verifies the behaviour.
> Some people argued that "the branches might
> have renamed that path to different paths and might indicate a
> rename/rename conflict" (meaning read-tree should not consider
> it trivial, and leave that to upper level "policy layer" to
> decide). merge-one-file policy simply says "no, they both
> wanted to remove them". If I recall correctly, read-tree itself
> merged this case before multi-base rewrite happened (if you are
> curious, run 'git whatchanged -p read-tree.c' and look for
> "Rewrite read-tree").
Aren't you talking about case #6?
O A B result index requirements
-------------------------------------------------------------------
6 exists missing missing remove must not exist.
------------------------------------------------------------------
case ancest head remote result
----------------------------------------
6 ancest+ (empty) (empty) no merge
>> 1) The MAJOR difference between "git checkout" and "git reset --hard"
> True. "git reset --hard" should be used without <rev> by
> novices and with <rev> after they understand what they are
> doing (it is used for rewinding/warping heads).
For the longest time I had been under the delusion that
"git-checkout <branch> *" and "git-reset --hard <branch>"
were very similar operations (modulo your comments about
deleting files): overwrite the index and working directory
files with the versions from that branch.
It's hard to say how much I managed to confuse myself by
damaging test repositories while I didn't understand what was
going on.
>> 2) Don't use "git branch" to create branches, unless you really
>> *don't* want to switch to them. Use "git checkout -b".
> Because...? "git branch foo && git checkout foo" may be
> suboptimal to type, but it is not _wrong_; it does not do
> anything bad or incorrect.
Yes, I know it works. I suggest avoiding it because there's a much
more convenient alternative and I kept forgetting the second half and
checking my changes in to the wrong branch.
>> 3) Dumb question: why does "git-commit-tree" need "-p" before the
>> parent commit arguments? Isn't just argv[2]..argv[argc-1]
>> good enough?
> 1. Why not?
> 3. It does not matter; nobody types that command by hand.
Because it's a real pain to get it properly quoted and set up
in a shell script. "$@" is a lot simpler and easier, and
old /bin/sh only has the one array which provides that magic
quoting behaviour.
(Admittedly, you usually pass the arguments through git-rev-parse
first, and are then guaranteed no embedded whitespace.)
> 4. It allows us to later add some other flags to commit-tree
> (none planned currently).
Making it disappear wouldn't preclude having more options, either,
any more than the variable number of arguments to cp(1) or mv(1)...
>> 4) If the "git-read-tree" docs for "--reset", does "ignored" mean
>> "not overwritten" or "overwritten"?
> That sentence is very poorly written; a better paraphrasing is
> appreciated.
diff --git a/Documentation/git-read-tree.txt b/Documentation/git-read-tree.txt
index 8b91847..47e2f93 100644
--- a/Documentation/git-read-tree.txt
+++ b/Documentation/git-read-tree.txt
@@ -31,8 +31,8 @@ OPTIONS
Perform a merge, not just a read.
--reset::
-
- Same as -m except that unmerged entries will be silently ignored.
+ Same as -m except that unmerged entries will be silently overwritten
+ (instead of failing).
-u::
After a successful merge, update the files in the work
@@ -47,7 +47,6 @@ OPTIONS
trees that are not directly related to the current
working tree status into a temporary index file.
-
<tree-ish#>::
The id of the tree object(s) to be read/merged.
>> 5) The final "error" message on "git-merge --no-commit" is a bit
>> alarming for a newbie who uses it...
> First of all, --no-commit is not meant to be used by newbies,
> but you are right.
Well, I can tell you that it's very very attractive to newbies.
The first 5 or 10 times I tried git-merge, I used --no-commit.
(My surprise was mostly that there wasn't a one-letter -x form.)
"Do something really complicated and then commit it to the repository"
is a frightening concept. "Do something really complicated and
then stop and wait for you to see if it was what you expected" is
a lot more comforting.
>> 6) The "pickaxe" options are being a bit confusing, and the fact they're
>> only documented in cvs-migration.txt doesn't help.
> Docs of git-diff-* family have OPTIONS section, at the end of
> which refers you to the diffcore documentation. Suggestions to
> a better organization and a patch is appropriate here.
That's a bigger job; I'll work on it when I've finished the docs I'm
writing right. :-)
>> 7) The git-tag man page could use a little better description of -a.
> Please. It should have the same "OPTIONS" section as others do.
I know NOTHING about asciidoc, and really wish I could fix its
lack-of-line-break problem:
GIT-BISECT(1) GIT-BISECT(1)
NAME
git-bisect - Find the change that introduced a bug
SYNOPSIS
git bisect start git bisect bad <rev> git bisect good <rev> git bisect
reset [<branch>] git bisect visualize git bisect replay <logfile> git
bisect log
but emulating what I saw elsewhere...
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 95de436..7635b1e 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -10,6 +10,26 @@ SYNOPSIS
--------
'git-tag' [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <name> [<head>]
+OPTIONS
+-------
+-a::
+ Make an unsigned (anotation) tag object
+
+-s::
+ Make a GPG-signed tag, using the default e-mail address's key
+
+-u <key-id>::
+ Make a GPG-signed tag, using the given key
+
+-f::
+ Replace an existing tag with the given name (instead of failing)
+
+-d::
+ Delete an existing tag with the given name
+
+-m <msg>::
+ Use the given tag message (instead of prompting)
+
DESCRIPTION
-----------
Adds a 'tag' reference in .git/refs/tags/
@@ -23,7 +43,7 @@ creates a 'tag' object, and requires the
in the tag message.
Otherwise just the SHA1 object name of the commit object is
-written (i.e. an lightweight tag).
+written (i.e. a lightweight tag).
A GnuPG signed tag object will be created when `-s` or `-u
<key-id>` is used. When `-u <key-id>` is not used, the
^ permalink raw reply related
* Re: More merge questions (why doesn't this work?)
From: Junio C Hamano @ 2005-12-02 10:12 UTC (permalink / raw)
To: linux; +Cc: git
In-Reply-To: <20051202091946.1631.qmail@science.horizon.com>
linux@horizon.com writes:
> Which should be case 10 of the t/t1000-read-tree-m-3way.sh
> table and succeed.
Yes. The reason is git-read-tree's behaviour was changed
underneath while octopus was looking elsewhere ;-). See
Documentation/technical/trivial-merge.txt, last couple of
lines.
There are two schools of thoughts about "both sides remove"
(case #10) case. Some people argued that "the branches might
have renamed that path to different paths and might indicate a
rename/rename conflict" (meaning read-tree should not consider
it trivial, and leave that to upper level "policy layer" to
decide). merge-one-file policy simply says "no, they both
wanted to remove them". If I recall correctly, read-tree itself
merged this case before multi-base rewrite happened (if you are
curious, run 'git whatchanged -p read-tree.c' and look for
"Rewrite read-tree").
> 1) The MAJOR difference between "git checkout" and "git reset --hard"
True. "git reset --hard" should be used without <rev> by
novices and with <rev> after they understand what they are
doing (it is used for rewinding/warping heads).
> 2) Don't use "git branch" to create branches, unless you really
> *don't* want to switch to them. Use "git checkout -b".
Because...? "git branch foo && git checkout foo" may be
suboptimal to type, but it is not _wrong_; it does not do
anything bad or incorrect.
> 3) Dumb question: why does "git-commit-tree" need "-p" before the
> parent commit arguments? Isn't just argv[2]..argv[argc-1]
> good enough?
1. Why not?
2. I myself wondered about it long time ago.
3. It does not matter; nobody types that command by hand.
4. It allows us to later add some other flags to commit-tree
(none planned currently).
> 4) If the "git-read-tree" docs for "--reset", does "ignored" mean
> "not overwritten" or "overwritten"?
That sentence is very poorly written; a better paraphrasing is
appreciated.
$ git whatchanged -S--reset \
read-tree.c Documentation/git-read-tree.txt
shows logs for 438195ccedce7270cf5ba167a940c90467cb72d7 commit
(run "git-cat-file commit 438195cc" to read it). It ignores
existing unmerged entries when reconstructing the index from the
given tree ("git-read-tree -m", given an unmerged index, refuses
to operate, but "--reset" *ignores* the unmerged ones hence it
does not refuse to operate).
> 5) The final "error" message on "git-merge --no-commit" is a bit
> alarming for a newbie who uses it...
First of all, --no-commit is not meant to be used by newbies,
but you are right. Patches to make the failure message
conditional are welcome. It should switch on these three cases:
- "--no-commit" option is given, but a merge conflict would
have prevented autocommit anyway;
- "--no-commit" option is given, but automerge succeeded;
- conflict prevented autocommit.
> 6) The "pickaxe" options are being a bit confusing, and the fact they're
> only documented in cvs-migration.txt doesn't help.
Docs of git-diff-* family have OPTIONS section, at the end of
which refers you to the diffcore documentation. Suggestions to
a better organization and a patch is appropriate here.
> 7) The git-tag man page could use a little better description of -a.
Please. It should have the same "OPTIONS" section as others do.
^ permalink raw reply
* Re: [RFC] Using sticky directories to control access to branches.
From: Junio C Hamano @ 2005-12-02 9:35 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <439013F1.4070600@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>> It _might_ make sense to have a contrib/examples subdirectory in
>> git.git project and keep a collection of examples like this.
>> Anybody else interested?
>>
>
> I am. Ten thousand brains usually do a better job than one in thinking
> up cool and nifty stuff. :)
Good. Another place (and probably better one) is
Documentation/howto/.
^ permalink raw reply
* Re: [RFC] Using sticky directories to control access to branches.
From: Andreas Ericsson @ 2005-12-02 9:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Carl Baldwin
In-Reply-To: <7vwtio9u8f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> It _might_ make sense to have a contrib/examples subdirectory in
> git.git project and keep a collection of examples like this.
>
> Anybody else interested?
>
I am. Ten thousand brains usually do a better job than one in thinking
up cool and nifty stuff. :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: More merge questions (why doesn't this work?)
From: linux @ 2005-12-02 9:19 UTC (permalink / raw)
To: git; +Cc: junkio, linux
In-Reply-To: <7vek4xsx49.fsf@assigned-by-dhcp.cox.net>
I was playing with the implications of the "deleted file in the
index is not a conflict" merge rule, and came up with the following
octopus test which fails to work. Note line 2 when choosing a
directory to run it in!
#!/bin/bash -xe
rm -rf .git
git-init-db
echo "File A" > a
echo "File B" > b
echo "File C" > c
git-add a b c
git-commit -a -m "Octopus test repository"
git-checkout -b a
echo "Modifications to a" >> a
git-commit -a -m "Modified file a"
git-checkout -b b master
echo "Modifications to b" >> b
git-commit -a -m "Modified file b"
git-checkout -b c master
rm c
git-commit -a -m "Deleted file c"
git-checkout master
#git merge --no-commit "" master c b a
#git merge --no-commit "" master a b c
git-rev-parse a b c > .git/FETCH_HEAD
git-octopus
(Commented out are the first few things I tried.)
Can someone tell me why this doesn't work? It should be a simple
in-index merge.
Right after the incomplete merge (I hacked this into the
git-octopus script), git-ls-files -s produces
100644 8fb437b77759c7709c122fbc8ba43f720e1fbc0a 0 a
100644 b3418f25da4393974aa205e2863f012e5b503369 0 b
100644 df78d3d51c369e1d2f1eadb73464aadd931d56b4 1 c
100644 df78d3d51c369e1d2f1eadb73464aadd931d56b4 2 c
Which should be case 10 of the t/t1000-read-tree-m-3way.sh
table and succeed.
Other things I've discovered...
1) The MAJOR difference between "git checkout" and "git reset --hard"
are that git-checkout takes a *head* as an argument and changes the
.git/HEAD *symlink* to point to that head (ln -sf refs/heads/<head>
.git/HEAD). "git reset" takes a *commit* (<rev>) as an argument and
changes the head that .git/HEAD points to to have that commit as its
hew tip (git-rev-parse <rev> > .git/HEAD)
All the other behavioural differences are relatively minor, and
appropriate for this big difference.
2) Don't use "git branch" to create branches, unless you really
*don't* want to switch to them. Use "git checkout -b".
3) Dumb question: why does "git-commit-tree" need "-p" before the
parent commit arguments? Isn't just argv[2]..argv[argc-1]
good enough?
4) If the "git-read-tree" docs for "--reset", does "ignored" mean
"not overwritten" or "overwritten"?
5) The final "error" message on "git-merge --no-commit" is a bit
alarming for a newbie who uses it because they don't quite trust
git's enough to enable auto-commit. And it should be changed
from ""Automatic merge failed/prevented; fix up by hand" to
"fix up and commit by hand".
Or how about:
"Automatic commit prevented; edit and commit by hand."
which actually tells the truth.
6) The "pickaxe" options are being a bit confusing, and the fact they're
only documented in cvs-migration.txt doesn't help.
7) The git-tag man page could use a little better description of -a.
^ permalink raw reply
* [PATCH] git-merge documentation: conflicting merge leaves higher stages in index
From: Junio C Hamano @ 2005-12-02 9:16 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xv39a8z.fsf@assigned-by-dhcp.cox.net>
This hopefully concludes the latest updates that changes the
behaviour of the merge on an unsuccessful automerge. Instead of
collapsing the conflicted path in the index to show HEAD, we
leave it unmerged, now that diff-files can compare working tree
files with higher stages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-merge.txt | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
e8be26e9282e346b01aa41fd7ab0b5f7bf7dcfc3
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index c117404..0cac563 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -108,10 +108,12 @@ When there are conflicts, these things h
2. Cleanly merged paths are updated both in the index file and
in your working tree.
-3. For conflicting paths, the index file records the version
- from `HEAD`. The working tree files have the result of
- "merge" program; i.e. 3-way merge result with familiar
- conflict markers `<<< === >>>`.
+3. For conflicting paths, the index file records up to three
+ versions; stage1 stores the version from the common ancestor,
+ stage2 from `HEAD`, and stage3 from the remote branch (you
+ can inspect the stages with `git-ls-files -u`). The working
+ tree files have the result of "merge" program; i.e. 3-way
+ merge result with familiar conflict markers `<<< === >>>`.
4. No other changes are done. In particular, the local
modifications you had before you started merge will stay the
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] merge-one-file: make sure we do not mismerge symbolic links.
From: Junio C Hamano @ 2005-12-02 9:15 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xv39a8z.fsf@assigned-by-dhcp.cox.net>
We ran "merge" command on O->A, O->B, A!=B case without verifying
the path involved is not a symlink.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-merge-one-file.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
01655e7c9a0b05d930aa7e27e74f75e086005bfc
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 906098d..c262dc6 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -58,6 +58,14 @@ case "${1:-.}${2:-.}${3:-.}" in
# Modified in both, but differently.
#
"$1$2$3" | ".$2$3")
+
+ case ",$6,$7," in
+ *,120000,*)
+ echo "ERROR: $4: Not merging symbolic link changes."
+ exit 1
+ ;;
+ esac
+
src2=`git-unpack-file $3`
case "$1" in
'')
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH] merge-one-file: make sure we create the merged file.
From: Junio C Hamano @ 2005-12-02 9:14 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xv39a8z.fsf@assigned-by-dhcp.cox.net>
The "update-index followed by checkout-index" chain served two
purposes -- to collapse the index to "our" version, and make
sure that file exists in the working tree. In the recent update
to leave the index unmerged on conflicting path, we wanted to
stop doing the former, but we still need to do the latter (we
allow merging to work in an un-checked-out working tree).
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-merge-one-file.sh | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
7afd8d297cd0c24e51188181769b56e0fb0f4171
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 9a049f4..906098d 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -79,7 +79,13 @@ case "${1:-.}${2:-.}${3:-.}" in
;;
esac
- merge "$4" "$orig" "$src2"
+ # Create the working tree file, with the correct permission bits.
+ # we can not rely on the fact that our tree has the path, because
+ # we allow the merge to be done in an unchecked-out working tree.
+ rm -f "$4" &&
+ git-cat-file blob "$2" >"$4" &&
+ case "$6" in *7??) chmod +x "$4" ;; esac &&
+ merge "$4" "$orig" "$src2"
ret=$?
rm -f -- "$orig" "$src2"
--
0.99.9.GIT
^ permalink raw reply related
* Re: What's new in git.git master branch
From: Fredrik Kuivinen @ 2005-12-02 8:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7v7jao9hln.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 01, 2005 at 09:46:12PM -0800, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
> > Fredrik Kuivinen <freku045@student.liu.se> writes:
> >
> >> It turns out that this change breaks the directory/file conflict
> >> handling in git-merge-recursive.
> >>
> >> git-ls-tree -r -z <tree SHA1>
> >>
> >> Should we do it that way or should ls-tree be changed?
> >
> > Ouch. Sorry, I should have been more careful.
>
> So we updated ls-tree to take -t flag which shows tree entries
> under -r flag. I'd appreciate if you test the attached patch.
With the patch tt works properly again. Thanks :)
> > Also I think I broke the case where base trees need to be merged
> > in 58cce8a8 commit (I changed processEntry not to collapse the
> > index entry when file content changes cannot be automerged, but
> > that change has to be done only for the final merge, and merges
> > between base trees must collapse to be able to write the index
> > file out as a tree).
>
> I think that the above worry was unfounded, because the
> updateFileExt call I removed to prevent it from collapsing the
> unmerged entries was in effect only in !cacheOnly case
> (i.e. callDepth == 0).
Yes, the code is correct. You can apply the following patch to make it
a bit simpler.
- Fredrik
--
merge-recursive: Clean up index updates
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
git-merge-recursive.py | 5 +----
1 files changed, 1 insertions(+), 4 deletions(-)
66b1a0157f25629b35ecf300450618a230741218
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index b7fb096..4f061da 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -825,10 +825,7 @@ def processEntry(entry, branch1Name, bra
cleanMerge = False
output('CONFLICT (content): Merge conflict in', path)
- if cacheOnly:
- updateFile(False, sha, mode, path)
- else:
- updateFileExt(sha, mode, path, updateCache=False, updateWd=True)
+ updateFile(False, sha, mode, path)
else:
die("ERROR: Fatal merge failure, shouldn't happen.")
--
0.99.9.GIT
^ permalink raw reply related
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