git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* fatal: git-write-tree: not able to write tree
@ 2006-04-28  8:30 Len Brown
  2006-04-28  8:32 ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Len Brown @ 2006-04-28  8:30 UTC (permalink / raw)
  To: git

I'm trying to  use git-am to apply a patch series in a mailbox.

The first patch has a conflict, which I edit to fix, and and then invoke
git am --3way --interactive --signoff --utf8 --resolved

but it bails out with this:

drivers/acpi/thermal.c: unmerged (4829f067a3e7acfbeed8b230caac00b1ed4b8554)
drivers/acpi/thermal.c: unmerged (528d198c28512af1627cce481575f37a599c0fe8)
drivers/acpi/thermal.c: unmerged (db3bef1a3e51801128e7553f3e546c8272cc9ee1)
fatal: git-write-tree: not able to write tree

I've tried various incantations of git reset on the theory that there is some 
old state hanging around someplace, but have not been able to check in this 
file.

clues?

thanks,
-Len

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: fatal: git-write-tree: not able to write tree
  2006-04-28  8:30 Len Brown
@ 2006-04-28  8:32 ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2006-04-28  8:32 UTC (permalink / raw)
  To: Len Brown; +Cc: git

Len Brown <len.brown@intel.com> writes:

> I'm trying to  use git-am to apply a patch series in a mailbox.
>
> The first patch has a conflict, which I edit to fix, and and then invoke
> git am --3way --interactive --signoff --utf8 --resolved
>
> but it bails out with this:
>
> drivers/acpi/thermal.c: unmerged (4829f067a3e7acfbeed8b230caac00b1ed4b8554)
> drivers/acpi/thermal.c: unmerged (528d198c28512af1627cce481575f37a599c0fe8)
> drivers/acpi/thermal.c: unmerged (db3bef1a3e51801128e7553f3e546c8272cc9ee1)
> fatal: git-write-tree: not able to write tree
>
> I've tried various incantations of git reset on the theory that there is some 
> old state hanging around someplace, but have not been able to check in this 
> file.
>
> clues?

Please say "--resolved" after you have actually resolved them,
eh, meaning, (1) edit the working tree file into a desired
shape, and (2) git-update-index drivers/acpi/thermal.c.

I've considered making --resolved to do update-index for all
paths that are unmerged in the index, but that risks going
forward by mistake when you still have other paths to resolve,
so...

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: fatal: git-write-tree: not able to write tree
@ 2006-04-28  8:43 Brown, Len
  2006-04-28  9:01 ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: Brown, Len @ 2006-04-28  8:43 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: git

 
>> git am --3way --interactive --signoff --utf8 --resolved

>Please say "--resolved" after you have actually resolved them,
>eh, meaning, (1) edit the working tree file into a desired
>shape, and (2) git-update-index drivers/acpi/thermal.c.

Thanks Junio, once again, for your help, we're up and running!

I'm okay with git being conservative and not doing the update-index
for me.  Perhaps the thing to do here is to make the failure message
more useful?

"fatal: git-write-tree: not able to write tree"

everything after "fatal" here is effectively a string
of random characters to the hapless user.

thanks,
-Len

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: fatal: git-write-tree: not able to write tree
  2006-04-28  8:43 Brown, Len
@ 2006-04-28  9:01 ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2006-04-28  9:01 UTC (permalink / raw)
  To: Brown, Len; +Cc: git

"Brown, Len" <len.brown@intel.com> writes about the command "git
am -3 --resolved", after hand merging _but_ without update-index
to actually mark the paths that have been resolved, results in
"write-tree" failure.

> I'm okay with git being conservative and not doing the update-index
> for me.  Perhaps the thing to do here is to make the failure message
> more useful?
>
> "fatal: git-write-tree: not able to write tree"
>
> everything after "fatal" here is effectively a string
> of random characters to the hapless user.

That's very true.  Perhaps something like this?

-- >8 --
git-am --resolved: more usable error message.

After doing the hard work of hand resolving the conflicts in the
working tree, if the user forgets to run update-index to mark
the paths that have been resolved, the command gave an
unfriendly "fatal: git-write-tree: not able to write tree" error
message.  Catch the situation early and give more meaningful
message and suggestion.

Noticed and suggested by Len Brown.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-am.sh b/git-am.sh
index eab4aa8..872145b 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -376,6 +376,13 @@ do
 			echo "No changes - did you forget update-index?"
 			stop_here $this
 		fi
+		unmerged=$(git-ls-files -u)
+		if test -n "$unmerged"
+		then
+			echo "You still have unmerged paths in your index"
+			echo "did you forget update-index?"
+			stop_here $this
+		fi
 		apply_status=0
 		;;
 	esac

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: fatal: git-write-tree: not able to write tree
@ 2006-04-29 13:23 colin
  2006-04-29 18:34 ` Junio C Hamano
  0 siblings, 1 reply; 6+ messages in thread
From: colin @ 2006-04-29 13:23 UTC (permalink / raw)
  To: junkio; +Cc: git

diff --git a/git-am.sh b/git-am.sh
index eab4aa8..872145b 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -376,6 +376,13 @@ do
 			echo "No changes - did you forget update-index?"
 			stop_here $this
 		fi
+		unmerged=$(git-ls-files -u)
+		if test -n "$unmerged"
+		then
+			echo "You still have unmerged paths in your index"
+			echo "did you forget update-index?"
+			stop_here $this
+		fi
 		apply_status=0
 		;;
 	esac

Er... it's very non-obvious to me why you'd want to stick a workaround
here when you could instead fix git-write-tree to do it.  That seems
like The Right Thing.
(It would also be helpful to mention at least one unmerged file by name.)

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: fatal: git-write-tree: not able to write tree
  2006-04-29 13:23 fatal: git-write-tree: not able to write tree colin
@ 2006-04-29 18:34 ` Junio C Hamano
  0 siblings, 0 replies; 6+ messages in thread
From: Junio C Hamano @ 2006-04-29 18:34 UTC (permalink / raw)
  To: colin; +Cc: junkio, git

colin@horizon.com writes:

> diff --git a/git-am.sh b/git-am.sh
> index eab4aa8..872145b 100755
> --- a/git-am.sh
> +++ b/git-am.sh
> @@ -376,6 +376,13 @@ do
>  			echo "No changes - did you forget update-index?"
>  			stop_here $this
>  		fi
> +		unmerged=$(git-ls-files -u)
> +		if test -n "$unmerged"
> +		then
> +			echo "You still have unmerged paths in your index"
> +			echo "did you forget update-index?"
> +			stop_here $this
> +		fi
>  		apply_status=0
>  		;;
>  	esac
>
> Er... it's very non-obvious to me why you'd want to stick a workaround
> here when you could instead fix git-write-tree to do it.  That seems
> like The Right Thing.

As I said in an earlier message in the thread, I've considered
it, but that is a very risky thing to do, and write-tree is
definitely a wrong place to do it.  If we wanted to, the right
way would be to update-index using the output of "ls-files -u".

However, it would invite the user to mistakenly say --resolved
before resolving all paths.

> (It would also be helpful to mention at least one unmerged file by name.)

That is true.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2006-04-29 18:34 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-29 13:23 fatal: git-write-tree: not able to write tree colin
2006-04-29 18:34 ` Junio C Hamano
  -- strict thread matches above, loose matches on Subject: below --
2006-04-28  8:43 Brown, Len
2006-04-28  9:01 ` Junio C Hamano
2006-04-28  8:30 Len Brown
2006-04-28  8:32 ` Junio C Hamano

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).