cg-update with local uncommitted changes

cg-update with local uncommitted changes

[Marcel Holtmann]

Hi Petr,

when doing a cg-update and I have local uncommitted changes it fails
with the "... needs update" message. From some previous posts on the
mailing list I got the impression that it is possible to pull updates
into the local repository with changed files. At the moment I am using
the following sequence:

	cg-diff > patch
	cg-cancel
	cg-update origin
	cat patch | patch -p1
	rm patch

The problem with this sequence is when I have added or removed files
from my repository. This needs a lot of manual fixing.

With Bitkeeper it was possible to pull changes as long as they don't
affect local uncommitted files.

Any ideas on how to implement or if it exists on how to use it?

Regards

Marcel

Re: cg-update with local uncommitted changes

[Petr Baudis]

Dear diary, on Mon, May 30, 2005 at 04:25:14PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,

Hello,

> when doing a cg-update and I have local uncommitted changes it fails
> with the "... needs update" message. From some previous posts on the
> mailing list I got the impression that it is possible to pull updates
> into the local repository with changed files. At the moment I am using
> the following sequence:
> 
> 	cg-diff > patch
> 	cg-cancel
> 	cg-update origin
> 	cat patch | patch -p1
> 	rm patch
> 
> The problem with this sequence is when I have added or removed files
> from my repository. This needs a lot of manual fixing.
> 
> With Bitkeeper it was possible to pull changes as long as they don't
> affect local uncommitted files.
> 
> Any ideas on how to implement or if it exists on how to use it?

does it really fail? "... needs update" is not an error but something
between informative and warning message. (I've just committed a change
which silences it in this case.)

If the update did indeed fail, could you show the complete output,
please?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-update with local uncommitted changes

[Marcel Holtmann]

Hi Petr,

> > when doing a cg-update and I have local uncommitted changes it fails
> > with the "... needs update" message. From some previous posts on the
> > mailing list I got the impression that it is possible to pull updates
> > into the local repository with changed files. At the moment I am using
> > the following sequence:
> > 
> > 	cg-diff > patch
> > 	cg-cancel
> > 	cg-update origin
> > 	cat patch | patch -p1
> > 	rm patch
> > 
> > The problem with this sequence is when I have added or removed files
> > from my repository. This needs a lot of manual fixing.
> > 
> > With Bitkeeper it was possible to pull changes as long as they don't
> > affect local uncommitted files.
> > 
> > Any ideas on how to implement or if it exists on how to use it?
> 
> does it really fail? "... needs update" is not an error but something
> between informative and warning message. (I've just committed a change
> which silences it in this case.)
> 
> If the update did indeed fail, could you show the complete output,
> please?

I used the latest cg-update on a test repository and now it works, but I
found odd cases when I have files added/deleted that are not committed
yet. For the added case I saw this:

Warning: uncommitted local changes, trying to bring them forward
The next patch would create the file test.c,
which already exists!  Skipping patch.
1 out of 1 hunk ignored -- saving rejects to file test.c.rej
Adding file test.c

I also think that it would be great if we cancel the merge if the local
changes conflict with the files in the merge. This is how Bitkeeper does
it and I think it is the only safe way, because if something fails or
rejects we may destroy the local changes.

Regards

Marcel

Re: cg-update with local uncommitted changes

[Zack Brown]

On Mon, May 30, 2005 at 04:25:14PM +0200, Marcel Holtmann wrote:
> Hi Petr,
> 
> when doing a cg-update and I have local uncommitted changes it fails
> with the "... needs update" message.

I don't see failures, but I do see the "needs update" message often when
I do cg-update. If I run cg-update a second time it says the tree is fully
up-to-date. However, if I then do a cg-diff, I will see tons of diff output.
This is on a tree (the kernel) that I haven't modified at all, I only track it
with cg-update.

I also track Cogito, and I use the latest form of all git and Cogito tools.
Maybe somewhere along the line I've corrupted my repo by using incompatible
versions of the git/Cogito toolset.

I've noticed if I do a fresh cg-clone the problem seems to go away.

Be well,
Zack

> From some previous posts on the
> mailing list I got the impression that it is possible to pull updates
> into the local repository with changed files. At the moment I am using
> the following sequence:
> 
> 	cg-diff > patch
> 	cg-cancel
> 	cg-update origin
> 	cat patch | patch -p1
> 	rm patch
> 
> The problem with this sequence is when I have added or removed files
> from my repository. This needs a lot of manual fixing.
> 
> With Bitkeeper it was possible to pull changes as long as they don't
> affect local uncommitted files.
> 
> Any ideas on how to implement or if it exists on how to use it?
> 
> Regards
> 
> Marcel
> 
> 
> -
> 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

-- 
Zack Brown

Re: cg-update with local uncommitted changes

[Marcel Holtmann]

Hi Petr,

> > > when doing a cg-update and I have local uncommitted changes it fails
> > > with the "... needs update" message. From some previous posts on the
> > > mailing list I got the impression that it is possible to pull updates
> > > into the local repository with changed files. At the moment I am using
> > > the following sequence:
> > > 
> > > 	cg-diff > patch
> > > 	cg-cancel
> > > 	cg-update origin
> > > 	cat patch | patch -p1
> > > 	rm patch
> > > 
> > > The problem with this sequence is when I have added or removed files
> > > from my repository. This needs a lot of manual fixing.
> > > 
> > > With Bitkeeper it was possible to pull changes as long as they don't
> > > affect local uncommitted files.
> > > 
> > > Any ideas on how to implement or if it exists on how to use it?
> > 
> > does it really fail? "... needs update" is not an error but something
> > between informative and warning message. (I've just committed a change
> > which silences it in this case.)
> > 
> > If the update did indeed fail, could you show the complete output,
> > please?
> 
> I used the latest cg-update on a test repository and now it works

let me be more specific. It only works in the fast forward case. If we
actually must merge the trees, because I have local committed changes
and not committed changes, I see this:

link 74966c42ddd874192c318acfc5f013e56c50606a
link b27ddcd47e293557e0605b98b2a1e8429035cdc5
link 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80
Tree change: f345b0a066572206aac4a4f9a57d746e213b6bff:74966c42ddd874192c318acfc5f013e56c50606a
:100644 100644 f5deac7be59e7eeab8657fd9ae706fd6a57daed2 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80 M      README

Applying changes...
usage.c: needs update
cg-merge: merge blocked: local changes

I changed the README in test1 repository and committed it. Then I
changed Makefile in test2 repository and committed it. After that I
modified usage.c and left it uncommitted. Then I pulled in the README
change from test1 repository.

Regards

Marcel

Re: cg-update with local uncommitted changes

[Dan Holmsand]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

Marcel Holtmann wrote:
> I also think that it would be great if we cancel the merge if the local
> changes conflict with the files in the merge. This is how Bitkeeper does
> it and I think it is the only safe way, because if something fails or
> rejects we may destroy the local changes.

I definitely agree (been bitten by patching gone wild a couple of times...).

This patch would make cg-merge and cg-admin-uncommit refuse to do 
anything if there are conflicting uncommitted changes. Note: this only 
applies to fast-forward merging, as cg-merge otherwise bails out if 
there are *any* uncommitted changes (which is perhaps going to far).

/dan

[PATCH] Make tree_timewarp safe, by refusing to handle conflicts.

Signed-off-by: Dan Holmsand <holmsand@gmail.com>


[-- Attachment #2: merge.patch.txt --]
[-- Type: text/plain, Size: 2855 bytes --]

diff --git a/cg-Xlib b/cg-Xlib
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -50,47 +50,22 @@ showdate () {
 }
 
 
-# Usage: tree_timewarp DIRECTION_STR ROLLBACK_BOOL BASE BRANCH
+# Usage: tree_timewarp BASE BRANCH
 tree_timewarp () {
-	dirstr=$1; shift
-	rollback=$1; shift
-	base=$1; shift
-	branch=$1; shift
-
-	patchfile=$(mktemp -t gituncommit.XXXXXX)
-	if [ "$rollback" ]; then
-		cg-diff >$patchfile
-		[ -s "$patchfile" ] &&
-			echo "Warning: uncommitted local changes, trying to bring them $dirstr" >&2
-	else
-		# XXX: This may be suboptimal, but it is also non-trivial to keep
-		# the adds/removes properly.  So this is just a quick hack to get it
-		# working without much fuss.
-		cg-diff -r $branch >$patchfile
-	fi
-
-	git-read-tree -m "$branch" || die "$branch: bad commit"
-	echo "$branch" > $_git/HEAD
-
-	# Kill gone files
-	git-diff-tree -z -r $base $branch | xargs -0 bash -c '
-		while [ "$1" ]; do
-			header="$1"; shift
-			file="$1"; shift
-
-			# match ":100755 000000 14d43b1abf... 000000000... D"
-			if echo "$header" | egrep "^:([^ ][^ ]* ){4}D" >/dev/null; then
-				rm -- "$file"
-			fi
-		done
-	' padding
-	git-checkout-cache -f -a
-
-	# FIXME: Can produce bogus "contains only garbage" messages.
-	cat $patchfile | cg-patch
-	rm $patchfile
+	local conflicts base=$1 branch=$2
 
 	git-update-cache --refresh >/dev/null
+	conflicts=$( (git-diff-tree -r $base $branch; 
+		git-diff-cache -r HEAD) | cut -f2- | sort | uniq -d )
+	[ -z "$conflicts" ] || 
+		die "conflicting uncommitted changes: $conflicts"
+
+	git-read-tree -m $branch || die "read-tree failed"
+	git-diff-tree -r $base $branch | cut -f5- -d' ' | grep '^[NM]' | 
+	cut -f2- | tr \\n \\0 | xargs -0 git-checkout-cache -u -f --
+	git-diff-tree -r $base $branch | cut -f5- -d' ' | grep '^[D]' | 
+	cut -f2- | tr \\n \\0 | xargs -0 rm -f --
+	echo "$branch" > $_git/HEAD
 }
 
 
diff --git a/cg-admin-uncommit b/cg-admin-uncommit
--- a/cg-admin-uncommit
+++ b/cg-admin-uncommit
@@ -39,10 +39,15 @@ commit=$(commit-id "$1") || exit 1
 git-rev-list $base | grep -q $commit || \
 	die "$commit: not an ancestor of HEAD"
 
-parent=$(parent-id "$commit") || exit 1
+parent=$(parent-id "$commit" | head -n 1) || exit 1
 [ "$parent" ] || die "cannot rewind behind the initial commit"
 
 
 echo "Rewinding $base (HEAD) -> $parent" >&2
 
-tree_timewarp "backwards" "$rollback_tree" $base $parent
+if [ "$rollback_tree" ]; then
+	tree_timewarp $base $parent
+else
+	git-read-tree -m $parent || die "git-read-tree failed"
+	echo "$parent" > $_git/HEAD
+fi
diff --git a/cg-merge b/cg-merge
--- a/cg-merge
+++ b/cg-merge
@@ -65,7 +65,7 @@ if [ "$head" = "$base" ]; then
 	echo "Fast-forwarding $base -> $branch" >&2
 	echo -e "\ton top of $head..." >&2
 
-	tree_timewarp "forward" "yes, rollback (or rather rollforth) the tree!" $base $branch
+	tree_timewarp $base $branch
 
 	exit 0
 fi

Re: cg-update with local uncommitted changes

[Petr Baudis]

Dear diary, on Tue, May 31, 2005 at 12:31:28AM CEST, I got a letter
where Dan Holmsand <holmsand@gmail.com> told me that...
> Marcel Holtmann wrote:
> >I also think that it would be great if we cancel the merge if the local
> >changes conflict with the files in the merge. This is how Bitkeeper does
> >it and I think it is the only safe way, because if something fails or
> >rejects we may destroy the local changes.
> 
> I definitely agree (been bitten by patching gone wild a couple of times...).
> 
> This patch would make cg-merge and cg-admin-uncommit refuse to do 
> anything if there are conflicting uncommitted changes. Note: this only 
> applies to fast-forward merging, as cg-merge otherwise bails out if 
> there are *any* uncommitted changes (which is perhaps going to far).

Well, non-fast-forward cg-merge will do cg-commit and it would blend the
unrelated previously uncommitted changes into that, which is not what
you want.

> [PATCH] Make tree_timewarp safe, by refusing to handle conflicts.
> 
> Signed-off-by: Dan Holmsand <holmsand@gmail.com>

I don't really think this makes any sense. What do you then do when you
want to do some merging of the local uncommitted changes and upstream
update?

How have you been bitten, and how could we destroy the local changes?
You get rejects and patch will be pretty vocal about it, so then you
just go and resolve them. The correct direction is to make it do a
three-way merge, not make it do no merge at all.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-update with local uncommitted changes

[Petr Baudis]

Dear diary, on Mon, May 30, 2005 at 09:25:41PM CEST, I got a letter
where Zack Brown <zbrown@tumblerings.org> told me that...
> On Mon, May 30, 2005 at 04:25:14PM +0200, Marcel Holtmann wrote:
> > Hi Petr,
> > 
> > when doing a cg-update and I have local uncommitted changes it fails
> > with the "... needs update" message.
> 
> I don't see failures, but I do see the "needs update" message often when
> I do cg-update. If I run cg-update a second time it says the tree is fully
> up-to-date. However, if I then do a cg-diff, I will see tons of diff output.
> This is on a tree (the kernel) that I haven't modified at all, I only track it
> with cg-update.

This is strange. I've just did a cg-update on a kernel tree I've left
untouched for more than a week (and I've even locally modified one file)
and everything went fine.

> I also track Cogito, and I use the latest form of all git and Cogito tools.
> Maybe somewhere along the line I've corrupted my repo by using incompatible
> versions of the git/Cogito toolset.

That's entirely possible given the big output format changes from some
git tools. Hopefully most of those problems should be already fixed.

> I've noticed if I do a fresh cg-clone the problem seems to go away.

Tip of the day: cg-cancel will fix almost any working state messup (any
messup as long as you have proper commit id in your refs/heads/master
file).

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-update with local uncommitted changes

[Dan Holmsand]

Petr Baudis wrote:
> Dear diary, on Tue, May 31, 2005 at 12:31:28AM CEST, I got a letter
> where Dan Holmsand <holmsand@gmail.com> told me that...
>>This patch would make cg-merge and cg-admin-uncommit refuse to do 
>>anything if there are conflicting uncommitted changes. Note: this only 
>>applies to fast-forward merging, as cg-merge otherwise bails out if 
>>there are *any* uncommitted changes (which is perhaps going to far).
> 
> 
> Well, non-fast-forward cg-merge will do cg-commit and it would blend the
> unrelated previously uncommitted changes into that, which is not what
> you want.

cg-merge should obviously only commit the files touched by the 
"slow-forward" merge (note: this is not a big deal for me, I have no 
problem with cogito saying "no" once too often. It's when it tries and 
fails that trouble starts).

>>[PATCH] Make tree_timewarp safe, by refusing to handle conflicts.

> I don't really think this makes any sense. What do you then do when you
> want to do some merging of the local uncommitted changes and upstream
> update?

I've never really wanted to do that. I commit, then merge.

> How have you been bitten, and how could we destroy the local changes?
> You get rejects and patch will be pretty vocal about it, so then you
> just go and resolve them. The correct direction is to make it do a
> three-way merge, not make it do no merge at all.

Huh? When I get to the patch rejects, the merge will have happened and 
the local changes pretty much be gone forever. And it's really easy to 
miss the .rej files altogether.

I'd much prefer not having to worry before doing cg-merge/update, then 
to have to salvage old stuff from .rej files. And three-way merges don't 
really solve this; they may work more often, but when they fail, data is 
potentially lost. Why take the chance?

/dan

Re: cg-update with local uncommitted changes

[Petr Baudis]

Dear diary, on Mon, May 30, 2005 at 09:27:24PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,

Hello,

> let me be more specific. It only works in the fast forward case. If we
> actually must merge the trees, because I have local committed changes
> and not committed changes, I see this:
> 
> link 74966c42ddd874192c318acfc5f013e56c50606a
> link b27ddcd47e293557e0605b98b2a1e8429035cdc5
> link 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80
> Tree change: f345b0a066572206aac4a4f9a57d746e213b6bff:74966c42ddd874192c318acfc5f013e56c50606a
> :100644 100644 f5deac7be59e7eeab8657fd9ae706fd6a57daed2 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80 M      README
> 
> Applying changes...
> usage.c: needs update
> cg-merge: merge blocked: local changes
> 
> I changed the README in test1 repository and committed it. Then I
> changed Makefile in test2 repository and committed it. After that I
> modified usage.c and left it uncommitted. Then I pulled in the README
> change from test1 repository.

yes, and that is all right. If you are actually doing the merge with
commit, you need to have the tree clean before, since any changes you
make to the tree are counted as conflict fixes, and you don't want your
older changes to mix into that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor

Re: cg-update with local uncommitted changes

[Marcel Holtmann]

Hi Petr,

> > let me be more specific. It only works in the fast forward case. If we
> > actually must merge the trees, because I have local committed changes
> > and not committed changes, I see this:
> > 
> > link 74966c42ddd874192c318acfc5f013e56c50606a
> > link b27ddcd47e293557e0605b98b2a1e8429035cdc5
> > link 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80
> > Tree change: f345b0a066572206aac4a4f9a57d746e213b6bff:74966c42ddd874192c318acfc5f013e56c50606a
> > :100644 100644 f5deac7be59e7eeab8657fd9ae706fd6a57daed2 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80 M      README
> > 
> > Applying changes...
> > usage.c: needs update
> > cg-merge: merge blocked: local changes
> > 
> > I changed the README in test1 repository and committed it. Then I
> > changed Makefile in test2 repository and committed it. After that I
> > modified usage.c and left it uncommitted. Then I pulled in the README
> > change from test1 repository.
> 
> yes, and that is all right. If you are actually doing the merge with
> commit, you need to have the tree clean before, since any changes you
> make to the tree are counted as conflict fixes, and you don't want your
> older changes to mix into that.

but not if the merge does not conflict with the local changes. This is
what Bitkeeper is doing. It lets you pull new stuff as long as it does
not conflict with your local uncommitted changes. Actually I liked that
feature a lot, because I was able the follow the latest Linux mainline
tree and work on my stuff.

Regards

Marcel

Re: cg-update with local uncommitted changes

[Petr Baudis]

Dear diary, on Thu, Jun 02, 2005 at 11:26:54PM CEST, I got a letter
where Marcel Holtmann <marcel@holtmann.org> told me that...
> Hi Petr,
> 
> > > let me be more specific. It only works in the fast forward case. If we
> > > actually must merge the trees, because I have local committed changes
> > > and not committed changes, I see this:
> > > 
> > > link 74966c42ddd874192c318acfc5f013e56c50606a
> > > link b27ddcd47e293557e0605b98b2a1e8429035cdc5
> > > link 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80
> > > Tree change: f345b0a066572206aac4a4f9a57d746e213b6bff:74966c42ddd874192c318acfc5f013e56c50606a
> > > :100644 100644 f5deac7be59e7eeab8657fd9ae706fd6a57daed2 568ad7814e266f84b4ac28c15a0cadfb2fdb6c80 M      README
> > > 
> > > Applying changes...
> > > usage.c: needs update
> > > cg-merge: merge blocked: local changes
> > > 
> > > I changed the README in test1 repository and committed it. Then I
> > > changed Makefile in test2 repository and committed it. After that I
> > > modified usage.c and left it uncommitted. Then I pulled in the README
> > > change from test1 repository.
> > 
> > yes, and that is all right. If you are actually doing the merge with
> > commit, you need to have the tree clean before, since any changes you
> > make to the tree are counted as conflict fixes, and you don't want your
> > older changes to mix into that.
> 
> but not if the merge does not conflict with the local changes. This is
> what Bitkeeper is doing. It lets you pull new stuff as long as it does
> not conflict with your local uncommitted changes. Actually I liked that
> feature a lot, because I was able the follow the latest Linux mainline
> tree and work on my stuff.

Well, I guess we could allow this to happen if there are no conflicts
whatsoever, but as soon as _any_ conflicts appear in the tree, we would
have to bail out screaming panic, asking you to commit your stuff.
Actually, if you've already committed something locally, why don't you
commit everything locally and keep some uncommitted changes on the top?

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor