* 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
* Re: What's new in git.git master branch
From: Fredrik Kuivinen @ 2005-12-02 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Fredrik Kuivinen, git
In-Reply-To: <7vmzjljgwo.fsf@assigned-by-dhcp.cox.net>
On Thu, Dec 01, 2005 at 01:38:47AM -0800, Junio C Hamano wrote:
> Currently, rename result is recorded by using "git-update-index
> --cacheinfo" to populate the index. This method unfortunately
> can only create a stage0 entry. We can go two ways. One way is
> to support "register this mode/sha1 tuple at stageN for path" to
> update-index. Another would be for merge-recursive to first
> construct three trees with the final directory structure
> (i.e. prepare three temporary trees with renames applied) and
> run read-tree 3-way merge on these temporary trees. I suspect
> the former is probably of lesser impact. Thoughts?
If we really want to do this then the former is certainly easier from
the perspective of git-merge-recursive.
- Fredrik
^ permalink raw reply
* Re: git-name-rev off-by-one bug
From: Junio C Hamano @ 2005-12-02 8:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7vslte1y5z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> 2. merge-one-file leaves unmerged index entries.
>
> Regarding #2, in an earlier message you said something about
> "patch to do that was just broken" which I did not understand; I
> think your patch I am replying to is doing the right thing. That
> case arm is dealing with a path that exists in "our" branch and
> the working tree blob should be the same as recorded in the
> HEAD, so I did not have to do the unpack-cat-chmod like I did in
> mine. Am I simply confused?
The only difference is that, from the old tradition, we are
supposed to allow the merge to happen in an unchecked-out
working tree [*1*]. The version you did and I merged in the
master branch breaks that, while the patch I posted keeps that
premise.
I can throw in my change on top of what is already commited for
now to "fix" this, but do we still care about the "merge should
succeed in an unchecked-out working tree" rule, or does it not
matter anymore these days?
One thing is that the check with "git diff" to show diff between
half-merged and stage2 after a failed merge does not work very
well in a sparsely checked out working tree, because the real
change is buried among tons of deletes ("diff --diff-filter=UM"
helps, though [*2*]).
[Footnote]
*1* ... and that is why we special case a non-existent working
tree file as if it is clean with the index. After a merge, you
would end up with a sparsely checked-out working tree that
contains only the files that were involved in the merge.
*2* Maybe --diff-filter should always include U in the output,
because it is rare and when an unmerged entry exists the user
would always want to see it.
^ permalink raw reply
* Re: minor problems in git.c
From: Alex Riesen @ 2005-12-02 8:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1x0wb936.fsf@assigned-by-dhcp.cox.net>
On 12/2/05, Junio C Hamano <junkio@cox.net> wrote:
> >> Shouldn't you check the return value of snprintf
> >
> > Probably. For the case where length of a git-command-name +
> > --exec-prefix together are longer than PATH_MAX.
>
> Combined, something like this.
Thanks!
^ permalink raw reply
* Re: What's new in git.git master branch
From: Junio C Hamano @ 2005-12-02 5:46 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <7vmzjljgwo.fsf@assigned-by-dhcp.cox.net>
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.
> 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).
-- >8 --
[PATCH] merge-recursive: adjust git-ls-tree use for the latest.
You need to pass -t flag if you want to see tree objects in
"git-ls-tree -r" output these days. This change broke the tree
structure reading code in git-merge-recursive used to detect D/F
conflicts.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-merge-recursive.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
a6b51f11ab7f7f838a9b17f81059eebfc36e4c84
diff --git a/git-merge-recursive.py b/git-merge-recursive.py
index e599b11..b7fb096 100755
--- a/git-merge-recursive.py
+++ b/git-merge-recursive.py
@@ -98,7 +98,7 @@ getFilesRE = re.compile(r'^([0-7]+) (\S+
def getFilesAndDirs(tree):
files = Set()
dirs = Set()
- out = runProgram(['git-ls-tree', '-r', '-z', tree])
+ out = runProgram(['git-ls-tree', '-r', '-z', '-t', tree])
for l in out.split('\0'):
m = getFilesRE.match(l)
if m:
--
0.99.9.GIT
^ permalink raw reply related
* Re: What's new in git.git master branch
From: Junio C Hamano @ 2005-12-02 5:45 UTC (permalink / raw)
To: Fredrik Kuivinen; +Cc: git
In-Reply-To: <7vmzjljgwo.fsf@assigned-by-dhcp.cox.net>
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.
> 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).
^ permalink raw reply
* Re: resolve (merge) problems
From: Junio C Hamano @ 2005-12-02 5:09 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051202020512.99856.qmail@web31811.mail.mud.yahoo.com>
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?
^ permalink raw reply
* Re: resolve (merge) problems
From: Luben Tuikov @ 2005-12-02 2:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsog9s5e.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Ok, if your patch below resolves the bug (please see my
> > other email just posted) please submit it. (I'm hitting
> > this bug everytime there's a file deleted from the
> > kernel tree and I try to merge.)
>
> Sorry to hear that. The patch I sent you is already pushed out
> and mirrored the public machines.
Yes, I pulled right after I posted and saw you pushed it.
>
> The failure from '-s recursive' (lack of heapq) makes me suspect
> that your Python installation is too old. The 'resolve' method
> you've been using should work fine for this case;
$python -V
Python 2.4.2
$which python
/usr/local/bin/python
>otherwise
> replace '-s recursive' in the message from Linus with '-s
> resolve' for the 'git merge' commandline, like this:
>
> $ git merge -s resolve "merge linus' tree" HEAD master
Ok, I'll try this next time I hit this problem.
Thanks,
Luben
^ permalink raw reply
* Re: resolve (merge) problems
From: Junio C Hamano @ 2005-12-02 1:58 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051202015039.93047.qmail@web31811.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> Ok, if your patch below resolves the bug (please see my
> other email just posted) please submit it. (I'm hitting
> this bug everytime there's a file deleted from the
> kernel tree and I try to merge.)
Sorry to hear that. The patch I sent you is already pushed out
and mirrored the public machines.
The failure from '-s recursive' (lack of heapq) makes me suspect
that your Python installation is too old. The 'resolve' method
you've been using should work fine for this case; otherwise
replace '-s recursive' in the message from Linus with '-s
resolve' for the 'git merge' commandline, like this:
$ git merge -s resolve "merge linus' tree" HEAD master
^ permalink raw reply
* Re: resolve (merge) problems
From: Luben Tuikov @ 2005-12-02 1:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd9sb9ie.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> However, there is a bug recently introduced in the
> merge-one-file script.
Ok, if your patch below resolves the bug (please see my
other email just posted) please submit it. (I'm hitting
this bug everytime there's a file deleted from the
kernel tree and I try to merge.)
Thanks,
Luben
>
> Although the conflict resolution procedure I described applies
> if you really had a real conflicting merge, I suspect your merge
> should not have failed in the first place.
>
> case "${1:-.}${2:-.}${3:-.}" in
> #
> # Deleted in both or deleted in one and unchanged in the other
> #
> "$1.." | "$1.$1" | "$1$1.")
> if [ "$2" ]; then
> echo "Removing $4"
> fi
> if test -f "$4"; then
> rm -f -- "$4" &&
> rmdir -p "$(expr "$4" : '\(.*\)/')" 2>/dev/null
> fi &&
> exec git-update-index --remove -- "$4"
> ;;
>
> The faliure code from "rmdir -p" leaks up and makes
> git-update-index to be skipped. Here is a fix.
>
> -- >8 --
> [PATCH] merge-one-file fix
>
> 9ae2172aed289f2706a0e88288909fa47eddd7e7 used "rmdir -p"
> carelessly, causing the "git-update-index --remove" to be
> skipped.
>
> ---
> diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
> index 739a072..9a049f4 100755
> --- a/git-merge-one-file.sh
> +++ b/git-merge-one-file.sh
> @@ -26,7 +26,7 @@ case "${1:-.}${2:-.}${3:-.}" in
> fi
> if test -f "$4"; then
> rm -f -- "$4" &&
> - rmdir -p "$(expr "$4" : '\(.*\)/')" 2>/dev/null
> + rmdir -p "$(expr "$4" : '\(.*\)/')" 2>/dev/null || :
> fi &&
> exec git-update-index --remove -- "$4"
> ;;
>
>
>
> -
> 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
* Re: resolve (merge) problems
From: Luben Tuikov @ 2005-12-02 1:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512011556480.3099@g5.osdl.org>
--- Linus Torvalds <torvalds@osdl.org> wrote:
> Well, first off, you would probably have been better off with the smarter
> recursive merge instead of the old "git resolve":
>
> git merge -s recursive "merge linus' tree" HEAD master
>
> (the "-s recursive" isn't really needed, it _should_ be the default).
>
> You can re-try that by doing a "git reset --hard" (to get rid of the
> partial merge) and just starting over.
Ok, what I've been doing is:
git-read-tree --reset -u <last committish>
git-checkout-index -u -f -a
to "roll-back" the index to the last "good" state.
(but I guess that has the same effect)
Then I re-tried the new git merge, and got this:
$git merge -s recursive "merge linus' tree" HEAD master
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Traceback (most recent call last):
File "/home/luben/bin/git-merge-recursive", line 10, in ?
from heapq import heappush, heappop
ImportError: No module named heapq
Automatic merge failed/prevented; fix up by hand
The git I have is latest: b34403aa97047f90c0cdd5177e63a8e7530e3388
> > The output from git-diff-index is:
>
> Don't. You'll see all the changes relative to HEAD, which _includes_ all
> the stuff that got cleanly merged.
>
> Instead, do just a
>
> git diff
>
> or perhaps
>
> git-diff-files --name-status
>
> which will show much better what is going on. In this case, I suspect that
> the problem is that my branch removed "poodle_defconfig", and you had
> changes in it, no? Or maybe there were conflicts in atmdev_init.c, so they
> got left in an unmerged state..
The former. Simple deletion. I've noticed that
I've those problems only when the file has been completely
deleted in the tree I'm trying to merge (from).
The index is left in a state where the file doesn't
exist in the working tree but is in the index.
Not sure if this is a general problem. I'd like to
note though that the branches are in _different_ directories, (different index and HEAD of
course),
but everything else is shared (symlinks).
>
> Regardless, the git-diff-files interface should show you which files are
> unmerged and need to be fixed up.
>
> Just fix them up: either remove them, or edit them to taste, and then do
> "git-update-index <filename>" (add the "--remove" option if you deleted
> the file), and then finish it off when you're happy with a "git commit".
>
> That _should_ fix it all up.
Ok, that worked. The sequence I did is:
$git reset --hard
$git resolve HEAD master "merge linus' tree"
Trying to merge deda498710e190c7922c2634ed630ee64ce86c05 into
6fea38404a5ce270d73df9cde561135defe9ab39 using 5666c0947ede0432ba5148570aa66ffb9febff5b.
Simple merge failed, trying Automatic merge
Auto-merging MAINTAINERS.
Removing drivers/net/sk98lin/skcsum.c
fatal: merge program failed
Automatic merge failed, fix up by hand
$git-diff-files --name-status
U drivers/net/sk98lin/skcsum.c
D drivers/net/sk98lin/skcsum.c
$git-update-index --remove drivers/net/sk98lin/skcsum.c
$git commit -s "merge linus' tree"
And that worked. But at some point it did the right
thing only with "git resolve ..." What has changed?
Thanks,
Luben
^ permalink raw reply
* Re: [RFC] Using sticky directories to control access to branches.
From: Junio C Hamano @ 2005-12-02 1:13 UTC (permalink / raw)
To: git; +Cc: Carl Baldwin
In-Reply-To: <20051201154222.GB18993@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> I have tweaked the script a little. I thought I'd send to the list in
> case anyone was following this. If not, then safely ignore this.
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?
^ permalink raw reply
* Re: minor problems in git.c
From: Junio C Hamano @ 2005-12-02 1:07 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0512010602l63ecev1ba03fb90d06e071@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>> Shouldn't you check the return value of snprintf
>
> Probably. For the case where length of a git-command-name +
> --exec-prefix together are longer than PATH_MAX.
Combined, something like this.
-- >8 --
Subject: git wrapper: more careful argument stuffing
From: Alex Riesen <raa.lkml@gmail.com>
Date: Thu, 1 Dec 2005 13:48:35 +0100
- Use stderr for error output
- Build git_command more careful
- ENOENT is good enough for check of failed exec to show usage, no
access() check needed
[jc: Originally from Alex Riesen with inputs from Sven
Verdoolaege mixed in.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
6e3f1bf88fdce10ba5c0274e017667d21bb68359
diff --git a/git.c b/git.c
index 0b10b6e..878c359 100644
--- a/git.c
+++ b/git.c
@@ -283,16 +283,21 @@ int main(int argc, char **argv, char **e
len = strlen(git_command);
prepend_to_path(git_command, len);
- strncat(&git_command[len], "/git-", sizeof(git_command) - len);
- len += 5;
- strncat(&git_command[len], argv[i], sizeof(git_command) - len);
-
- if (access(git_command, X_OK))
- usage(exec_path, "'%s' is not a git-command", argv[i]);
+ len += snprintf(git_command + len, sizeof(git_command) - len,
+ "/git-%s", argv[i]);
+ if (sizeof(git_command) <= len) {
+ fprintf(stderr, "git: command name given is too long (%d)\n", len);
+ exit(1);
+ }
/* execve() can only ever return if it fails */
execve(git_command, &argv[i], envp);
- printf("Failed to run command '%s': %s\n", git_command, strerror(errno));
+
+ if (errno == ENOENT)
+ usage(exec_path, "'%s' is not a git-command", argv[i]);
+
+ fprintf(stderr, "Failed to run command '%s': %s\n",
+ git_command, strerror(errno));
return 1;
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: resolve (merge) problems
From: Junio C Hamano @ 2005-12-02 0:58 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051202000715.8100.qmail@web31810.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <junkio@cox.net> wrote:
>> Easier to read is:
>>
>> $ git-diff-files --name-status
>
> Ok this is what it shows:
>
> $git-diff-files --name-status
> U arch/arm/configs/poodle_defconfig
> D arch/arm/configs/poodle_defconfig
> U drivers/atm/atmdev_init.c
> D drivers/atm/atmdev_init.c
>
> Unmerged and deleted? Is this correct?
Yes, the first lets you notice it is unmerged, and the second
says the file does not remain in the working tree.
However, there is a bug recently introduced in the
merge-one-file script.
Although the conflict resolution procedure I described applies
if you really had a real conflicting merge, I suspect your merge
should not have failed in the first place.
case "${1:-.}${2:-.}${3:-.}" in
#
# Deleted in both or deleted in one and unchanged in the other
#
"$1.." | "$1.$1" | "$1$1.")
if [ "$2" ]; then
echo "Removing $4"
fi
if test -f "$4"; then
rm -f -- "$4" &&
rmdir -p "$(expr "$4" : '\(.*\)/')" 2>/dev/null
fi &&
exec git-update-index --remove -- "$4"
;;
The faliure code from "rmdir -p" leaks up and makes
git-update-index to be skipped. Here is a fix.
-- >8 --
[PATCH] merge-one-file fix
9ae2172aed289f2706a0e88288909fa47eddd7e7 used "rmdir -p"
carelessly, causing the "git-update-index --remove" to be
skipped.
---
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 739a072..9a049f4 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -26,7 +26,7 @@ case "${1:-.}${2:-.}${3:-.}" in
fi
if test -f "$4"; then
rm -f -- "$4" &&
- rmdir -p "$(expr "$4" : '\(.*\)/')" 2>/dev/null
+ rmdir -p "$(expr "$4" : '\(.*\)/')" 2>/dev/null || :
fi &&
exec git-update-index --remove -- "$4"
;;
^ permalink raw reply related
* [PATCH] Fast-forwarding does a git.switch() even when it forwarded no patches
From: Chuck Lever @ 2005-12-02 0:15 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
In-Reply-To: <20051202001141.9140.23252.stgit@dexter.citi.umich.edu>
The git.switch() in forward_patches() is not needed when no patches have
been fast forwarded. This is a significant speed up.
Signed-off-by: Chuck Lever <cel@netapp.com>
---
stgit/stack.py | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/stgit/stack.py b/stgit/stack.py
index 3fd6a46..3cc37c5 100644
--- a/stgit/stack.py
+++ b/stgit/stack.py
@@ -735,6 +735,9 @@ class Series:
forwarded+=1
unapplied.remove(name)
+ if forwarded == 0:
+ return 0
+
git.switch(top)
append_strings(self.__applied_file, names[0:forwarded])
^ permalink raw reply related
* [PATCH] unneeded processing in forward_patches() ??
From: Chuck Lever @ 2005-12-02 0:11 UTC (permalink / raw)
To: catalin.marinas; +Cc: git
i was wondering why "stg push" takes so long to decide not to use
fast-forward.
it turns out that when forward_patches() has not been able to fast-
forward any patches, it still does a git.switch() and rewrites the
unapplied file even though nothing has changed. on a big working
directory, this 'no-op' can take a while.
following is a simple patch that addresses the problem. does this appear
to be a reasonable optimization (in terms of correctness)?
-- Chuck Lever
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
^ permalink raw reply
* Re: resolve (merge) problems
From: Linus Torvalds @ 2005-12-02 0:07 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git
In-Reply-To: <20051201231844.59450.qmail@web31801.mail.mud.yahoo.com>
On Thu, 1 Dec 2005, Luben Tuikov wrote:
>
> $git resolve HEAD master "merge linus' tree"
> Trying to merge 5666c0947ede0432ba5148570aa66ffb9febff5b into
> 32df3299405fb7054b76346899f3db2fa29150fb using 458af5439fe7ae7d95ca14106844e61f0795166c.
> Simple merge failed, trying Automatic merge
> Removing arch/arm/configs/poodle_defconfig
> Removing drivers/atm/atmdev_init.c
> fatal: merge program failed
> Automatic merge failed, fix up by hand
>
> How do I proceed from here?
Well, first off, you would probably have been better off with the smarter
recursive merge instead of the old "git resolve":
git merge -s recursive "merge linus' tree" HEAD master
(the "-s recursive" isn't really needed, it _should_ be the default).
You can re-try that by doing a "git reset --hard" (to get rid of the
partial merge) and just starting over.
> The output from git-diff-index is:
Don't. You'll see all the changes relative to HEAD, which _includes_ all
the stuff that got cleanly merged.
Instead, do just a
git diff
or perhaps
git-diff-files --name-status
which will show much better what is going on. In this case, I suspect that
the problem is that my branch removed "poodle_defconfig", and you had
changes in it, no? Or maybe there were conflicts in atmdev_init.c, so they
got left in an unmerged state..
Regardless, the git-diff-files interface should show you which files are
unmerged and need to be fixed up.
Just fix them up: either remove them, or edit them to taste, and then do
"git-update-index <filename>" (add the "--remove" option if you deleted
the file), and then finish it off when you're happy with a "git commit".
That _should_ fix it all up.
Linus
^ permalink raw reply
* Re: resolve (merge) problems
From: Luben Tuikov @ 2005-12-02 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3blccqtz.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Easier to read is:
>
> $ git-diff-files --name-status
Ok this is what it shows:
$git-diff-files --name-status
U arch/arm/configs/poodle_defconfig
D arch/arm/configs/poodle_defconfig
U drivers/atm/atmdev_init.c
D drivers/atm/atmdev_init.c
Unmerged and deleted? Is this correct?
Luben
^ permalink raw reply
* Re: resolve (merge) problems
From: Junio C Hamano @ 2005-12-01 23:58 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051201231844.59450.qmail@web31801.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> $ git resolve HEAD master "merge linus' tree"
> Trying to merge 5666c0947ede0432ba5148570aa66ffb9febff5b into
> 32df3299405fb7054b76346899f3db2fa29150fb using 458af5439fe7ae7d95ca14106844e61f0795166c.
> Simple merge failed, trying Automatic merge
> Removing arch/arm/configs/poodle_defconfig
> Removing drivers/atm/atmdev_init.c
> fatal: merge program failed
> Automatic merge failed, fix up by hand
>
> How do I proceed from here?
>
> The output from git-diff-index is:
>
> $git-diff-index --name-status HEAD
> M Documentation/usb/error-codes.txt
> M Makefile
> M arch/arm/configs/corgi_defconfig
> U arch/arm/configs/poodle_defconfig
> M arch/arm/configs/spitz_defconfig
Easier to read is:
$ git-diff-files --name-status
which would tell you that there two files have conflicting
changes:
U arch/arm/configs/poodle_defconfig
U drivers/atm/atmdev_init.c
and you would hopefully not see anything else (you saw tons of
paths only because you compared against HEAD, which shows not
just conflicts but everything the merge brought in).
$ git diff arch/arm/configs/poodle_defconfig drivers/atm/atmdev_init.c
would give you the diff between your version (before merging)
and the half-merged file with conflict markers. Resolve them
just like you would resolve conflicting changes. I would
usually just open these files in an editor, and pick one of the
sections between <<< == >>> these markers.
One nifty tool I saw suggested on the list recently was xxdiff:
$ xxdiff -U arch/arm/configs/poodle_defconfig
No matter how you would resolve, the first goal of yours is to
get these files in your working tree into a good shape, which
may involve compiling and testing. Once you have these files in
a good enough shape, you tell git that you are done with them:
$ git update-index \
arch/arm/configs/poodle_defconfig drivers/atm/atmdev_init.c
and commit.
$ git commit
The commit message editor would loudly warn you that you are
committing a merge, but that is OK because that is what you are
doing. You might want to describe how you resolved (which side
you picked) the conflicting changes in the log, in addition to
the standard boilerplate "merged that branch" message.
^ permalink raw reply
* resolve (merge) problems
From: Luben Tuikov @ 2005-12-01 23:18 UTC (permalink / raw)
To: git
Hi,
$git resolve HEAD master "merge linus' tree"
Trying to merge 5666c0947ede0432ba5148570aa66ffb9febff5b into
32df3299405fb7054b76346899f3db2fa29150fb using 458af5439fe7ae7d95ca14106844e61f0795166c.
Simple merge failed, trying Automatic merge
Removing arch/arm/configs/poodle_defconfig
Removing drivers/atm/atmdev_init.c
fatal: merge program failed
Automatic merge failed, fix up by hand
How do I proceed from here?
The output from git-diff-index is:
$git-diff-index --name-status HEAD
M Documentation/usb/error-codes.txt
M Makefile
M arch/arm/configs/corgi_defconfig
U arch/arm/configs/poodle_defconfig
M arch/arm/configs/spitz_defconfig
M arch/arm/kernel/head.S
M arch/arm/mach-pxa/Kconfig
M arch/arm/mach-realview/core.c
M arch/arm/mm/consistent.c
M arch/arm/tools/mach-types
M arch/frv/kernel/semaphore.c
M arch/frv/mb93090-mb00/pci-irq.c
M arch/frv/mm/init.c
M arch/frv/mm/pgalloc.c
M arch/i386/kernel/io_apic.c
M arch/i386/kernel/reboot.c
M arch/ia64/kernel/ia64_ksyms.c
M arch/ia64/kernel/kprobes.c
M arch/ia64/kernel/traps.c
M arch/m32r/kernel/io_mappi3.c
M arch/m32r/kernel/setup_mappi3.c
M arch/m32r/kernel/sys_m32r.c
M arch/powerpc/kernel/ppc_ksyms.c
M arch/powerpc/kernel/process.c
M arch/powerpc/kernel/prom_init.c
M arch/powerpc/kernel/vdso.c
M arch/ppc/kernel/ppc_ksyms.c
M arch/ppc/kernel/process.c
M arch/sparc/mm/generic.c
M arch/sparc64/mm/generic.c
M drivers/atm/Kconfig
M drivers/atm/Makefile
A drivers/atm/adummy.c
U drivers/atm/atmdev_init.c
M drivers/atm/atmtcp.c
M drivers/atm/lanai.c
M drivers/char/drm/drm_context.c
M drivers/char/mem.c
M drivers/cpufreq/cpufreq.c
M drivers/hwmon/w83792d.c
M drivers/md/md.c
M drivers/md/raid1.c
M drivers/md/raid10.c
M drivers/md/raid5.c
M drivers/md/raid6main.c
M drivers/media/video/Kconfig
M drivers/media/video/cx88/Kconfig
M drivers/media/video/cx88/Makefile
M drivers/media/video/saa7134/Kconfig
M drivers/media/video/saa7134/Makefile
M drivers/message/fusion/mptbase.c
M drivers/message/fusion/mptbase.h
M drivers/mmc/mmc.c
M drivers/mtd/chips/cfi_cmdset_0001.c
M drivers/mtd/chips/cfi_probe.c
M drivers/mtd/chips/sharp.c
M drivers/mtd/devices/block2mtd.c
M drivers/mtd/devices/ms02-nv.c
M drivers/mtd/ftl.c
M drivers/mtd/maps/Kconfig
M drivers/mtd/maps/Makefile
M drivers/mtd/maps/ixp4xx.c
M drivers/mtd/maps/nettel.c
M drivers/mtd/maps/pci.c
M drivers/mtd/maps/physmap.c
M drivers/mtd/maps/sc520cdp.c
M drivers/mtd/nand/nandsim.c
M drivers/mtd/rfd_ftl.c
M drivers/pcmcia/m32r_cfc.c
M drivers/scsi/megaraid.c
M drivers/serial/8250.c
M drivers/serial/8250_pci.c
M drivers/serial/serial_core.c
M drivers/serial/serial_cs.c
M drivers/usb/atm/cxacru.c
M drivers/usb/atm/usbatm.c
M drivers/usb/core/hcd-pci.c
M drivers/usb/core/hcd.c
M drivers/usb/core/hcd.h
M drivers/usb/host/ehci-pci.c
M drivers/usb/host/ehci-q.c
M drivers/usb/host/ehci-sched.c
M drivers/usb/host/ohci-hcd.c
M drivers/usb/host/ohci-hub.c
M drivers/usb/host/ohci-pci.c
M drivers/usb/host/uhci-hcd.c
M drivers/video/Kconfig
M drivers/video/cirrusfb.c
M drivers/video/console/fbcon_ccw.c
M drivers/video/console/fbcon_rotate.h
M fs/9p/vfs_inode.c
M fs/cifs/CHANGES
M fs/cifs/README
M fs/cifs/TODO
M fs/cifs/cifsfs.c
M fs/cifs/cifssmb.c
M fs/cifs/dir.c
M fs/cifs/inode.c
M fs/cifs/misc.c
M fs/cifs/netmisc.c
M fs/cifs/transport.c
M fs/dquot.c
M fs/exec.c
M fs/ext3/resize.c
M fs/fuse/dir.c
M fs/hfsplus/hfsplus_fs.h
M fs/hfsplus/hfsplus_raw.h
M fs/hfsplus/options.c
M fs/hfsplus/super.c
M fs/jffs2/fs.c
M fs/jffs2/super.c
M fs/proc/task_mmu.c
M fs/reiserfs/inode.c
M fs/reiserfs/journal.c
M include/asm-arm/arch-s3c2410/regs-gpio.h
M include/asm-arm/arch-sa1100/io.h
M include/asm-frv/hardirq.h
M include/asm-frv/ide.h
M include/asm-frv/page.h
M include/asm-frv/semaphore.h
M include/asm-frv/thread_info.h
M include/asm-ia64/page.h
M include/asm-m32r/atomic.h
M include/asm-m32r/ide.h
M include/asm-m32r/mappi3/mappi3_pld.h
M include/asm-m32r/system.h
M include/asm-sparc64/pgtable.h
M include/linux/atmdev.h
M include/linux/cn_proc.h
M include/linux/cpu.h
M include/linux/memory.h
M include/linux/mm.h
M include/linux/mmc/protocol.h
M include/linux/mtd/cfi.h
M include/linux/rmap.h
M include/linux/sched.h
M include/linux/serial_core.h
M include/linux/swap.h
M kernel/cpu.c
M kernel/fork.c
M kernel/posix-cpu-timers.c
M kernel/power/main.c
M kernel/ptrace.c
M kernel/workqueue.c
M lib/genalloc.c
M mm/fremap.c
M mm/madvise.c
M mm/memory.c
M mm/mempolicy.c
M mm/msync.c
M mm/nommu.c
M mm/page_alloc.c
M mm/rmap.c
M mm/thrash.c
M mm/vmscan.c
M net/atm/atm_misc.c
M net/atm/common.c
M net/atm/common.h
M net/atm/resources.c
M net/atm/resources.h
M net/ipv4/fib_hash.c
M net/ipv4/fib_semantics.c
M net/ipv4/icmp.c
M net/ipv4/ip_gre.c
M net/ipv4/ip_output.c
M net/ipv4/ipvs/ip_vs_conn.c
M net/ipv4/ipvs/ip_vs_ctl.c
M net/ipv4/ipvs/ip_vs_proto_tcp.c
M net/ipv4/netfilter/ip_conntrack_amanda.c
M net/ipv4/netfilter/ip_conntrack_core.c
M net/ipv4/netfilter/ip_conntrack_ftp.c
M net/ipv4/netfilter/ip_conntrack_irc.c
M net/ipv4/netfilter/ip_conntrack_proto_icmp.c
M net/ipv4/netfilter/ip_conntrack_proto_sctp.c
M net/ipv4/netfilter/ip_conntrack_proto_tcp.c
M net/ipv4/netfilter/ip_nat_core.c
M net/ipv4/netfilter/ip_tables.c
M net/ipv4/netfilter/ipt_LOG.c
M net/ipv4/proc.c
M net/ipv4/route.c
M net/ipv4/tcp.c
M net/ipv6/addrconf.c
M net/ipv6/icmp.c
M net/ipv6/ip6_output.c
M net/ipv6/ipv6_sockglue.c
M net/ipv6/netfilter/ip6_tables.c
Thanks,
Luben
^ permalink raw reply
* [PATCH] ls-tree: --name-only
From: Junio C Hamano @ 2005-12-01 22:56 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512011354500.3099@g5.osdl.org>
Fingers of some "git diff" users are trained to do --name-only
which git-ls-tree unfortunately does not take. With this,
cd sub/directory && git-ls-tree -r --name-only HEAD -- ..
would show only the paths but not object names nor modes. I
threw in another synonym --name-status only for usability, but
obviously ls-tree does not do any comparison so what it does is
the same as --name-only.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Linus Torvalds <torvalds@osdl.org> writes:
> That brings up another issue. I typed
>
> git-ls-tree -r --name-only ..
>
> and it obviously didn't work. That's kind of sad. I use that quite a lot
> for "git diff", for example, because quite often I want to see the files,
> but I don't care about anything else.
ls-tree.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
c639a5548a5d8414b55202592885449f66ee2f33
diff --git a/ls-tree.c b/ls-tree.c
index 07db863..dae377d 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -12,11 +12,12 @@ static int line_termination = '\n';
#define LS_RECURSIVE 1
#define LS_TREE_ONLY 2
#define LS_SHOW_TREES 4
+#define LS_NAME_ONLY 8
static int ls_options = 0;
const char **pathspec;
static const char ls_tree_usage[] =
- "git-ls-tree [-d] [-r] [-t] [-z] <tree-ish> [path...]";
+ "git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] <tree-ish> [path...]";
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -64,7 +65,8 @@ static int show_tree(unsigned char *sha1
else if (ls_options & LS_TREE_ONLY)
return 0;
- printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
+ if (!(ls_options & LS_NAME_ONLY))
+ printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
write_name_quoted(base, baselen, pathname, line_termination, stdout);
putchar(line_termination);
return retval;
@@ -92,6 +94,13 @@ int main(int argc, const char **argv)
case 't':
ls_options |= LS_SHOW_TREES;
break;
+ case '-':
+ if (!strcmp(argv[1]+2, "name-only") ||
+ !strcmp(argv[1]+2, "name-status")) {
+ ls_options |= LS_NAME_ONLY;
+ break;
+ }
+ /* otherwise fallthru */
default:
usage(ls_tree_usage);
}
--
0.99.9.GIT
^ permalink raw reply related
* Re: git-ls-remotes slightly broken
From: Junio C Hamano @ 2005-12-01 22:40 UTC (permalink / raw)
To: Lukas Sandström; +Cc: git
In-Reply-To: <438F76EA.2030104@etek.chalmers.se>
Lukas Sandström <lukass@etek.chalmers.se> writes:
> The commit e8cc80d03934cc607e3a4d89a05350c238dbf9c5 broke git-ls-remote.
>
> git-sh-setup is no longer included, thus I get the following error.
>
> # cg-fetch
> Fetching pack (head and objects)...
> Fetching tags...
> fatal: unexpected EOF
> /home/lukas/bin/git-ls-remote: line 73: die: command not found
> Up to date.
Sorry, and thanks for the report. Should be fixed with
1abacf3b5b53f6cde7148862234d451cd88d0de3 commit.
^ permalink raw reply
* Re: git-ls-remotes slightly broken
From: Junio C Hamano @ 2005-12-01 22:37 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Git Mailing List
In-Reply-To: <438F76EA.2030104@etek.chalmers.se>
Thanks.
^ permalink raw reply
* git-ls-remotes slightly broken
From: Lukas Sandström @ 2005-12-01 22:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Lukas Sandström
The commit e8cc80d03934cc607e3a4d89a05350c238dbf9c5 broke git-ls-remote.
git-sh-setup is no longer included, thus I get the following error.
# cg-fetch
Fetching pack (head and objects)...
Fetching tags...
fatal: unexpected EOF
/home/lukas/bin/git-ls-remote: line 73: die: command not found
Up to date.
/Lukas
^ permalink raw reply
* Re: documentation issues
From: Chuck Lever @ 2005-12-01 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64q8fqm8.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Junio C Hamano wrote:
>>also, git-diff-index supports a "-r" option, but that doesn't seem to be
>>documented on this page.
>
>
> What Chris Shoemaker said is right.
>
> But we could do this instead if you want. I am neutral myself.
thanks for clarifying.
StGIT does use "git-diff-index -r" in git.__tree_status(). i think it
can be safely removed.
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 445 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard
^ 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