Rebase problems

Rebase problems

[Maaartin]

I'm using git for a project I'm working on alone (and I really like it), so I 
could rebase a lot, if I hadn't the following problems.

There's a file containing the timestamp which gets compiled in, so the 
executable can show it's version. Sometimes, I need to set it couple of times a 
day, sometimes only once a week. For each such timestamp I create a tag, so I 
can track it to the source easily. The timestamp is an important piece of 
information, so I put the containing file under version control. The downside is 
that I often get a conflict in this file halting my rebase. Is there a way how 
to ignore or automatically resolve all conflicts in this file (any resolution 
strategy is fine, as it will be overwritten anyway).

The second problem is problem of cygwin. While most of the operations git run in 
fractions of seconds, the most trivial rebase may take one minute or alike. Any 
idea what different things rebase do?

Re: Rebase problems

[Wincent Colaiuta]

On 08/11/2010, at 19:19, Maaartin wrote:

> I'm using git for a project I'm working on alone (and I really like it), so I 
> could rebase a lot, if I hadn't the following problems.
> 
> There's a file containing the timestamp which gets compiled in, so the 
> executable can show it's version. Sometimes, I need to set it couple of times a 
> day, sometimes only once a week. For each such timestamp I create a tag, so I 
> can track it to the source easily. The timestamp is an important piece of 
> information, so I put the containing file under version control. The downside is 
> that I often get a conflict in this file halting my rebase. Is there a way how 
> to ignore or automatically resolve all conflicts in this file (any resolution 
> strategy is fine, as it will be overwritten anyway).

Rhetorical questions follow; no need for you to answer:

- Why is the timestamp an "important" piece of information?

- Have you considered that, for versioning purposes (ie. knowing _what_ source code was compiled to produce the product), the commit hash or the output of "git describe" may be much more useful than a disconnected timestamp?

- Regardless of whether you use a timestamp, a commit hash, or the output of "git describe", why can't it be inserted at compile time rather than stored in the repo?

- If you are really enamored of timestamps, would extracting the latest commit timestamp out of the repo be enough?

- Do these repeated merge conflicts set off "code smell" alarm bells for you (really, "process smell"), and make you suspect that there might be something wrong with what you are trying to do?

Cheers,
Wincent

Re: Rebase problems

[Maaartin-1]

On 10-11-08 19:33, Wincent Colaiuta wrote:
> On 08/11/2010, at 19:19, Maaartin wrote:
> 
>> I'm using git for a project I'm working on alone (and I really like it), so I 
>> could rebase a lot, if I hadn't the following problems.
>>
>> There's a file containing the timestamp which gets compiled in, so the 
>> executable can show it's version. Sometimes, I need to set it couple of times a 
>> day, sometimes only once a week. For each such timestamp I create a tag, so I 
>> can track it to the source easily. The timestamp is an important piece of 
>> information, so I put the containing file under version control. The downside is 
>> that I often get a conflict in this file halting my rebase. Is there a way how 
>> to ignore or automatically resolve all conflicts in this file (any resolution 
>> strategy is fine, as it will be overwritten anyway).
> 
> Rhetorical questions follow; no need for you to answer:

However, I will. I've asked myself some of them already.

Addendum: It looks like your question were the right ones, the problem
seems to be solved now in a very easy way.

> - Why is the timestamp an "important" piece of information?

I need the timestamp (or something else) in order to match the
problematic version to the source.

> - Have you considered that, for versioning purposes (ie. knowing _what_ source code was compiled to produce the product), the commit hash or the output of "git describe" may be much more useful than a disconnected timestamp?

Sure, I have considered it and I haven't ruled it out (I'm quite new to
git). The timestamp is something the customer can understand better and
has got used to during the past 5 yeas. It gets also stored in some
database columns, whose type I had to change. Using tags I can relate
the timestamp to the commit.

In any case I need to embed the information in the executable, which was
impossible for a hash in a committed file. However, I don't want to
commit it, anyway... so probably it's the way to go.

The output of git describe is quite unusable for this purpose, since the
customer would happily drop the hash which can lead to ambiguities.
Giving him only the SHA-1 would be safer.

> - Regardless of whether you use a timestamp, a commit hash, or the output of "git describe", why can't it be inserted at compile time rather than stored in the repo?

I could do it using an untracked file, which would eliminate my problem.
The downside is that then--assuming using the timestamp--I'd have to
rely on the tags or some logfile. No, there's no downside as I see after
having read your next line.

> - If you are really enamored of timestamps, would extracting the latest commit timestamp out of the repo be enough?

Sure it would, I was mostly ignoring the commit timestamp until now, and
didn't notice that I'm using a different timestamp for the executable
without any reason. Now I need just trivial changes.

> - Do these repeated merge conflicts set off "code smell" alarm bells for you (really, "process smell"), and make you suspect that there might be something wrong with what you are trying to do?

Partly, starting using the timestamp was a huge improvement many years
ago and I was quite happy with it until now. OTOH, git is new to me so I
was thinking about changing what I'm doing with git or finding some new
option there instead.

Now, I can have my timestamp and eat it, thank you.

Re: Rebase problems

[Maaartin]

Maaartin-1 <grajcar1 <at> seznam.cz> writes:

> On 10-11-08 19:33, Wincent Colaiuta wrote:
> > - If you are really enamored of timestamps, would extracting the latest 
commit timestamp out of the repo be enough?
> 
> Sure it would, I was mostly ignoring the commit timestamp until now, and
> didn't notice that I'm using a different timestamp for the executable
> without any reason. Now I need just trivial changes.

Time to comment on myself:

It works nice, but there's a small problem. I can't take the author date since 
it gets preserved across rebases, so I could get non-unique dates. The committer 
date corresponds with the time I actually create the executable, and I really 
not going to produce more than one executable per second, so it works nicely. 
Except for rebase, which can create a lot of commits with the same committer 
date quickly.

Currently I'm using cygwin and rebase is slow like hell, but when I switch to 
Linux, I'll need something to ensure that there'll be no two commits with the 
same committer date. I think even a one second sleep could do for me, but can I 
arrange for it easily?

Re: Rebase problems

[Andreas Schwab]

Maaartin <grajcar1@seznam.cz> writes:

> There's a file containing the timestamp which gets compiled in, so the 
> executable can show it's version. Sometimes, I need to set it couple of times a 
> day, sometimes only once a week. For each such timestamp I create a tag, so I 
> can track it to the source easily. The timestamp is an important piece of 
> information, so I put the containing file under version control. The downside is 
> that I often get a conflict in this file halting my rebase. Is there a way how 
> to ignore or automatically resolve all conflicts in this file (any resolution 
> strategy is fine, as it will be overwritten anyway).

If you already have a tag for every timestamp, why not autogenerate the
timestamp from the tag?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

rebase problems

[Sven Verdoolaege]

Recently, rebasing has stopped working for me.
Here is an example:

bash-3.00$ git-show-branch origin HEAD
! [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
 ! [HEAD] propagate LinearizationType typo fix.
--
 + [HEAD] propagate LinearizationType typo fix.
 + [HEAD^] LinearizationType: typo
 + [HEAD~2] espam::DecomposeChannels: actually decompose the channel if valid.
 + [HEAD~3] DecomposeChannels: split channel and check whether result is a pair of fifos.
 + [HEAD~4] Use proper class for LinearizationType.
 + [HEAD~5] espam/../DecomposeChannels: partial implementation.
 + [HEAD~6] espam: add flag for channel decomposition.
+  [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
++ [HEAD~7] espam/../IndexVector::toString: include contents of IndexVector.
bash-3.00$ git rebase origin

Applying 'espam::DecomposeChannels: actually decompose the channel if valid.'

error: pa/espam/operations/transformations/DecomposeChannels.java: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Trying simple merge.
Simple merge failed, trying Automatic merge.
ERROR: pa/espam/operations/transformations/DecomposeChannels.java: Not handling case 09322db769adbc03bfd4f3ac2720c6d1db5a85b1 ->  -> 32da8b1de4205c4adb0da50648a0a00d60b67582
fatal: merge program failed
Failed to merge in the changes.
Patch failed at 0007.
0001-espam-add-flag-for-channel-decomposition.txt


I'm not sure what rebase is doing here, but the only change in origin
modified a file untouched by the changes in HEAD, so there shouldn't
be any conflict whatsoever.
Apparently it's trying to apply the change in HEAD~2 without having
applied the earlier changes (which and the file named above).

skimo

PS: I'll try and look into the gitk thing this evening.

Re: rebase problems

[Junio C Hamano]

Sven Verdoolaege <skimo@kotnet.org> writes:

> Recently, rebasing has stopped working for me.
> Here is an example:
>
> bash-3.00$ git-show-branch origin HEAD
> ! [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
>  ! [HEAD] propagate LinearizationType typo fix.
> --
>  + [HEAD] propagate LinearizationType typo fix.
>  + [HEAD^] LinearizationType: typo
>  + [HEAD~2] espam::DecomposeChannels: actually decompose the channel if valid.
>  + [HEAD~3] DecomposeChannels: split channel and check whether result is a pair of fifos.
>  + [HEAD~4] Use proper class for LinearizationType.
>  + [HEAD~5] espam/../DecomposeChannels: partial implementation.
>  + [HEAD~6] espam: add flag for channel decomposition.
> +  [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
> ++ [HEAD~7] espam/../IndexVector::toString: include contents of IndexVector.
> bash-3.00$ git rebase origin
>
> Applying 'espam::DecomposeChannels: actually decompose the channel if valid.'
>
> error: pa/espam/operations/transformations/DecomposeChannels.java: does not exist in index
> Using index info to reconstruct a base tree...
> Falling back to patching base and 3-way merge...
> Trying simple merge.
> Simple merge failed, trying Automatic merge.
> ERROR: pa/espam/operations/transformations/DecomposeChannels.java: Not handling case 09322db769adbc03bfd4f3ac2720c6d1db5a85b1 ->  -> 32da8b1de4205c4adb0da50648a0a00d60b67582
> fatal: merge program failed
> Failed to merge in the changes.
> Patch failed at 0007.
> 0001-espam-add-flag-for-channel-decomposition.txt
>
>
> I'm not sure what rebase is doing here, but the only change in origin
> modified a file untouched by the changes in HEAD, so there shouldn't
> be any conflict whatsoever.
> Apparently it's trying to apply the change in HEAD~2 without having
> applied the earlier changes (which and the file named above).

What it should be doing (although I have not seen this kind of
breakage myself, there could be a bug that makes rebase not to
do what it should be doing) is:

 - save the original HEAD to .git/ORIG_HEAD
 - reset the tree to origin without switching branches
 - prepare patches for changes ~6, ~5, ... brings in
 - feed that to git-am, which saves the 7 patches in
   .dotest/0001 through .dotest/0007 and starts applying them.

As the first thing to do after you see something like this,
please stash away ORIG_HEAD, like this:

	$ git branch before-rebase-precious ORIG_HEAD

After this, if you choose not to rebase for whatever reason,
including "rebase is broken X-<", you could do

	$ git-reset --hard before-rebase-precious

to come back to the state before trying rebase.

The output seems very inconsistent I am not sure why the first
message says "Applying HEAD~2", not HEAD~6.    What patches do
you see in .dotest/ directory, and are they numbered in the
right order?  HEAD~6 should be numbered 0001 and that should be
the first one that was applied.

Re: rebase problems

[Sven Verdoolaege]

On Mon, Nov 28, 2005 at 12:19:40PM -0800, Junio C Hamano wrote:
> The output seems very inconsistent I am not sure why the first
> message says "Applying HEAD~2", not HEAD~6.    What patches do
> you see in .dotest/ directory, and are they numbered in the
> right order?  HEAD~6 should be numbered 0001 and that should be
> the first one that was applied.

Ah!  It seems .dotest still contained some stuff from a previous
(expectedly) failed rebase.

Rebase worked after rm -rf'ing .dotest

Maybe rebase should clean up .dotest or at least warn about
an existing .dotest ?

Thanks,
skimo

Re: rebase problems

[Junio C Hamano]

Sven Verdoolaege <skimo@kotnet.org> writes:

> On Mon, Nov 28, 2005 at 12:19:40PM -0800, Junio C Hamano wrote:
>> The output seems very inconsistent I am not sure why the first
>> message says "Applying HEAD~2", not HEAD~6.    What patches do
>> you see in .dotest/ directory, and are they numbered in the
>> right order?  HEAD~6 should be numbered 0001 and that should be
>> the first one that was applied.
>
> Ah!  It seems .dotest still contained some stuff from a previous
> (expectedly) failed rebase.
>
> Rebase worked after rm -rf'ing .dotest
>
> Maybe rebase should clean up .dotest or at least warn about
> an existing .dotest ?

Thanks, you are right.  I was coming to the same conclusion.

There are a few more problems in the current rebase.

 - If the branch being rebased is fully in sync with the master
   (i.e. there is no patch to apply), it fails with a mysterious
   message "fatal: cannot read mbox".

 - If the branch being rebased is already a proper descendant of
   the master, it still goes ahead and rebases.  This is
   unnecessary.

I think something like this is necessary.

-- >8 --
[PATCH] rebase: one safety net, one bugfix and one optimization.

When a .dotest from a previously failed rebase or patch
application exists, rebase got confused and tried to apply
mixture of what was already there and what is being rebased.
Check the existence of the directory and barf.

It failed with an mysterious "fatal: cannot read mbox" message
if the branch being rebased is fully in sync with the base.
Also if the branch is a proper descendant of the base, there is
no need to run rebase logic.  Prevent these from happening by
checking where the merge-base is.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 git-rebase.sh |   28 +++++++++++++++++++++++++++-
 1 files changed, 27 insertions(+), 1 deletions(-)

applies-to: fe523a4df93cce3e5c5b0266b9d3f1cbea009afa
7f4bd5d831ea838668d1de5f5af022f763230eee
diff --git a/git-rebase.sh b/git-rebase.sh
index 2bc3a12..638ff0d 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -5,9 +5,25 @@
 
 . git-sh-setup
 
-# The other head is given
+# Make sure we do not have .dotest
+if mkdir .dotest
+then
+	rmdir .dotest
+else
+	echo >&2 '
+It seems that I cannot create a .dotest directory, and I wonder if you
+are in the middle of patch application or another rebase.  If that is not
+the case, please rm -fr .dotest and run me again.  I am stopping in case
+you still have something valuable there.'
+	exit 1
+fi
+
+# The other head is given.  Make sure it is valid.
 other=$(git-rev-parse --verify "$1^0") || exit
 
+# Make sure we have HEAD that is valid.
+head=$(git-rev-parse --verify "HEAD^0") || exit
+
 # The tree must be really really clean.
 git-update-index --refresh || exit
 diff=$(git-diff-index --cached --name-status -r HEAD)
@@ -23,6 +39,16 @@ case "$#" in
 	git-checkout "$2" || exit
 esac
 
+# If the HEAD is a proper descendant of $other, we do not even need
+# to rebase.  Make sure we do not do needless rebase.  In such a
+# case, merge-base should be the same as "$other".
+mb=$(git-merge-base "$other" "$head")
+if test "$mb" = "$other"
+then
+	echo >&2 "Current branch `git-symbolic-ref HEAD` is up to date."
+	exit 0
+fi
+
 # Rewind the head to "$other"
 git-reset --hard "$other"
 git-format-patch -k --stdout --full-index "$other" ORIG_HEAD |
---
0.99.9.GIT