Re: [git-users] Re: Rebasing problems

2013-02-03 Thread Dale R. Worley
[git version 1.7.7.6]

 From: Blind stoycho.slept...@gmail.com
 
 just use the -m option for the git log (same for diff-tree -m infact).

Ugh.  After the end of the procedure I posted, I executed git log
--graph -p -m.  The output consists of:

* commit 18786ae12592f49859509ee4b20bb83979f6ea2b
| Author: Dale Worley wor...@ariadne.com
| Date:   Sun Feb 3 14:37:52 2013 -0500
| 
| Commit T
| 
| diff --git a/file b/file
| index 5394052..d5647ae 100644
| --- a/file
| +++ b/file
| @@ -12,5 +12,6 @@
|  6.5
|  7
|  8
| +8.5
|  9
|  10
|
*   commit 3038718d4cb45df909a2a6a6b30c92dbc72fb2c8 (from 
75078b3232f72fbd21f8686ecdc27cffbd48aded)
|\  Merge: 75078b3 8418344
| | Author: Dale Worley wor...@ariadne.com
| | Date:   Sun Feb 3 14:37:52 2013 -0500
| | 
| | Commit S
| | 
| | diff --git a/file b/file
| | index fc8a02f..5394052 100644
| | --- a/file
| | +++ b/file
| | @@ -9,6 +9,7 @@
| |  5
| |  5.5
| |  6
| | +6.5
| |  7
| |  8
| |  9
| | 
| | 

Followed by an infinite series of lines like this:

| | 
| | 

Dale

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [git-users] Re: Rebasing problems

2013-02-03 Thread Dale R. Worley
 From: Blind stoycho.slept...@gmail.com
 
 there is still nothing wrong here,
 just use the -m option for the git log (same for diff-tree -m infact).

If you go to the end of the new branch (git checkout rebase, but at
the end of the script, that is where you are already), and look at the
file file, you will see the 7.5 line is not there.

Dale

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




Re: [git-users] Re: Rebasing problems

2013-02-03 Thread Blind
Maybe I didn't express myself clear :-), sorry. 
I was speaking for at this point, means if you stop (cut) your script at 
the point after adding T commit.
before the rebasings ...
... after the rebase all goes wrong, shure.

03 февруари 2013, неделя, 21:52:54 UTC+2, Dale Worley написа:

  From: Blind stoycho@gmail.com javascript: 
  
  there is still nothing wrong here, 
  just use the -m option for the git log (same for diff-tree -m 
 infact). 

 If you go to the end of the new branch (git checkout rebase, but at 
 the end of the script, that is where you are already), and look at the 
 file file, you will see the 7.5 line is not there. 

 Dale 


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.




[git-users] Re: Rebasing problems

2013-02-02 Thread Blind
you can try the same thing, but with adding --interactive to your $ git 
rebase --preserve-merges invocation.

so he will open-up your default editor with the following text:

pick (some SHA1) Commit P
pick (...) Commit Q
pick (...) Commit R
pick (...) Commit S
pick (...) Commit T

(note that the SHA1 of the S commit is the same as for the original S 
commit (fa07bef in your example),
so he still didn't lose his mind at this point.)

then you change the pick to edit in the line with Commit S, then save 
and exit the editor,
he will continue to work and he will stop at what he beleives is S 
commit, but is not really infact.

(you can do a $git show HEAD at this point to see that 5.5 and 6.5 are 
noticed, but no mention of 7.5.)

then you do $git checkout SHA1-OF-ORIGINAL-S (fa07bef in your example, 
but of course it will be something different now)

he will display some usefull information, endindg with HEAD is now at 
(fa07bef) Commit S

then you do $git rebase --continue

... and you end up with the expected picture, and most important - the file 
has hiw 7.5 line.


So generally speaking, I think its a bug of git rebase, he never really 
checks the merge commits to see if they introduce some changes themselves.

I think it is a good idea if you post this problem to the official git 
mailing list (http://news.gmane.org/gmane.comp.version-control.git)

Cheers,
Blind.

31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:

 I'm investigating how rebase works, and I'm finding that it doesn't 
 work well if the rebased branch contains merges.  Am I using rebase 
 incorrectly? 

 In particular, if there are merge commits on the old branch that 
 contain changes that are not contained in either of the commits that 
 are merged, rebase doesn't carry them properly into the new branch. 

 (This sort of merge is not unusual; there may be adjustments needed to 
 combine two sets of changes for reasons other than a purely textual 
 collision between the changes.) 

 As far as I can tell, rebase without --preserve-merges entirely 
 ignores merge commits on the old branch.  Rebase with 
 --perserve-merges seems to recreate the new merges de novo rather than 
 by examining the old merge to determine what it changes.  Neither of 
 these actions is optimal (IMHO). 

 As a test case, I've written the following shell script.  It's written 
 for Linux, but the comments should be clear enough to allow manually 
 executing the git commands on other systems.  The places where I think 
 Git is behaving poorly are marked with ***.  Following the script is 
 the output of my execution of the script. 

 The beginning of the script creates this commit structure: 

A---B---C---D master 
 \ 
  \   Q   
   \ / \ 
P   S---T dev 
 \ / 
  R   

 The goal is to rebase dev (calling it branch 'rebase') to the head of 
 master.  But getting the changes that are in S that are not in Q or R 
 carried into the new branch seems to be impossible. 

 -- 
 set -ve 

 # Create a temporary directory and go into it. 
 DIR=temp.$$ 
 mkdir $DIR 
 cd $DIR 

 # Create a Git repository. 
 git init 

 # Create a file containing the lines 1 to 10. 
 seq 1 10 file 
 git add file 
 git commit -m 'Commit A' 

 # Start the dev branch at commit A. 
 git branch dev HEAD 

 # Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
 # This sed command adds a line 1.5 before the line 2. 

 sed --in-place -e '/^2$/i1.5' file 
 git commit -a -m 'Commit B' 

 sed --in-place -e '/^3$/i2.5' file 
 git commit -a -m 'Commit C' 

 sed --in-place -e '/^4$/i3.5' file 
 git commit -a -m 'Commit D' 

 # Show the commit structure of master. 
 git log --graph --oneline master 
 git log --graph -p master 

 # Go to the dev branch and create commits with a non-trivial merge. 
 git checkout dev 

 sed --in-place -e '/^5$/i4.5' file 
 git commit -a -m 'Commit P' 

 git branch dev1 HEAD 

 sed --in-place -e '/^6$/i5.5' file 
 git commit -a -m 'Commit Q' 

 git checkout dev1 

 sed --in-place -e '/^7$/i6.5' file 
 git commit -a -m 'Commit R' 

 git checkout dev 

 # Merge commits Q and R, but add the additional line 7.5 (to simulate 
 # fixes that were needed to resolve the merge). 

 git merge --no-commit dev1 
 sed --in-place -e '/^8$/i7.5' file 
 git commit -a -m 'Commit S' 

 sed --in-place -e '/^9$/i8.5' file 
 git commit -a -m 'Commit T' 

 # Show the commit structure of dev. 
 git log --graph --oneline dev 
 # *** Note that the diffs do not show the line 7.5 added in commit S. 
 git log --graph -p dev 

 # Rebase the dev branch to the tip of master. 
 git checkout dev 
 git branch -f rebase dev 
 git checkout rebase 
 git rebase master 

 # Show the commit structure. 
 git log --graph --oneline 
 # *** Note that the line 7.5 added in commit S isn't carried into the new 
 

[git-users] Re: Rebasing problems

2013-02-02 Thread Blind
a very quick warning to my previous post:

as they say, don't do this at home kids,

it is completely illegal and will brake the whole rabase,

it was just to demonstrate that the S' commit was wrongly rebuilt by the 
rebase.

Blind.

02 февруари 2013, събота, 17:11:14 UTC+2, Blind написа:

 you can try the same thing, but with adding --interactive to your $ git 
 rebase --preserve-merges invocation.

 so he will open-up your default editor with the following text:

 pick (some SHA1) Commit P
 pick (...) Commit Q
 pick (...) Commit R
 pick (...) Commit S
 pick (...) Commit T

 (note that the SHA1 of the S commit is the same as for the original S 
 commit (fa07bef in your example),
 so he still didn't lose his mind at this point.)

 then you change the pick to edit in the line with Commit S, then 
 save and exit the editor,
 he will continue to work and he will stop at what he beleives is S 
 commit, but is not really infact.

 (you can do a $git show HEAD at this point to see that 5.5 and 6.5 are 
 noticed, but no mention of 7.5.)

 then you do $git checkout SHA1-OF-ORIGINAL-S (fa07bef in your example, 
 but of course it will be something different now)

 he will display some usefull information, endindg with HEAD is now at 
 (fa07bef) Commit S

 then you do $git rebase --continue

 ... and you end up with the expected picture, and most important - the 
 file has hiw 7.5 line.


 So generally speaking, I think its a bug of git rebase, he never really 
 checks the merge commits to see if they introduce some changes themselves.

 I think it is a good idea if you post this problem to the official git 
 mailing list (http://news.gmane.org/gmane.comp.version-control.git)

 Cheers,
 Blind.

 31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:

 I'm investigating how rebase works, and I'm finding that it doesn't 
 work well if the rebased branch contains merges.  Am I using rebase 
 incorrectly? 

 In particular, if there are merge commits on the old branch that 
 contain changes that are not contained in either of the commits that 
 are merged, rebase doesn't carry them properly into the new branch. 

 (This sort of merge is not unusual; there may be adjustments needed to 
 combine two sets of changes for reasons other than a purely textual 
 collision between the changes.) 

 As far as I can tell, rebase without --preserve-merges entirely 
 ignores merge commits on the old branch.  Rebase with 
 --perserve-merges seems to recreate the new merges de novo rather than 
 by examining the old merge to determine what it changes.  Neither of 
 these actions is optimal (IMHO). 

 As a test case, I've written the following shell script.  It's written 
 for Linux, but the comments should be clear enough to allow manually 
 executing the git commands on other systems.  The places where I think 
 Git is behaving poorly are marked with ***.  Following the script is 
 the output of my execution of the script. 

 The beginning of the script creates this commit structure: 

A---B---C---D master 
 \ 
  \   Q   
   \ / \ 
P   S---T dev 
 \ / 
  R   

 The goal is to rebase dev (calling it branch 'rebase') to the head of 
 master.  But getting the changes that are in S that are not in Q or R 
 carried into the new branch seems to be impossible. 

 -- 
 set -ve 

 # Create a temporary directory and go into it. 
 DIR=temp.$$ 
 mkdir $DIR 
 cd $DIR 

 # Create a Git repository. 
 git init 

 # Create a file containing the lines 1 to 10. 
 seq 1 10 file 
 git add file 
 git commit -m 'Commit A' 

 # Start the dev branch at commit A. 
 git branch dev HEAD 

 # Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
 # This sed command adds a line 1.5 before the line 2. 

 sed --in-place -e '/^2$/i1.5' file 
 git commit -a -m 'Commit B' 

 sed --in-place -e '/^3$/i2.5' file 
 git commit -a -m 'Commit C' 

 sed --in-place -e '/^4$/i3.5' file 
 git commit -a -m 'Commit D' 

 # Show the commit structure of master. 
 git log --graph --oneline master 
 git log --graph -p master 

 # Go to the dev branch and create commits with a non-trivial merge. 
 git checkout dev 

 sed --in-place -e '/^5$/i4.5' file 
 git commit -a -m 'Commit P' 

 git branch dev1 HEAD 

 sed --in-place -e '/^6$/i5.5' file 
 git commit -a -m 'Commit Q' 

 git checkout dev1 

 sed --in-place -e '/^7$/i6.5' file 
 git commit -a -m 'Commit R' 

 git checkout dev 

 # Merge commits Q and R, but add the additional line 7.5 (to simulate 
 # fixes that were needed to resolve the merge). 

 git merge --no-commit dev1 
 sed --in-place -e '/^8$/i7.5' file 
 git commit -a -m 'Commit S' 

 sed --in-place -e '/^9$/i8.5' file 
 git commit -a -m 'Commit T' 

 # Show the commit structure of dev. 
 git log --graph --oneline dev 
 # *** Note that the diffs do not show the line 7.5 

[git-users] Re: Rebasing problems

2013-02-01 Thread Blind
I tryed your thing, and yes in both cases we end up with a file without 7.5 
line in it ...
this is not good from my point of view...

git rebase --preserve-merges still keeps the S, 
but he keeps only the info of the changes introduced from the both parents, 
he forgot about your manual change.

I guess a further investigation at the point of:

git merge --no-commit dev1 
sed --in-place -e '/^8$/i7.5' file 
git commit -a -m 'Commit S' 

wil make sence.

I am still not sure if it is a git commit problem in case of middle of 
merge,
or maybe somebody forgot to diff-tree correctly the things...

I am surely very interested how this will turn out.

31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:

 I'm investigating how rebase works, and I'm finding that it doesn't 
 work well if the rebased branch contains merges.  Am I using rebase 
 incorrectly? 

 In particular, if there are merge commits on the old branch that 
 contain changes that are not contained in either of the commits that 
 are merged, rebase doesn't carry them properly into the new branch. 

 (This sort of merge is not unusual; there may be adjustments needed to 
 combine two sets of changes for reasons other than a purely textual 
 collision between the changes.) 

 As far as I can tell, rebase without --preserve-merges entirely 
 ignores merge commits on the old branch.  Rebase with 
 --perserve-merges seems to recreate the new merges de novo rather than 
 by examining the old merge to determine what it changes.  Neither of 
 these actions is optimal (IMHO). 

 As a test case, I've written the following shell script.  It's written 
 for Linux, but the comments should be clear enough to allow manually 
 executing the git commands on other systems.  The places where I think 
 Git is behaving poorly are marked with ***.  Following the script is 
 the output of my execution of the script. 

 The beginning of the script creates this commit structure: 

A---B---C---D master 
 \ 
  \   Q   
   \ / \ 
P   S---T dev 
 \ / 
  R   

 The goal is to rebase dev (calling it branch 'rebase') to the head of 
 master.  But getting the changes that are in S that are not in Q or R 
 carried into the new branch seems to be impossible. 

 -- 
 set -ve 

 # Create a temporary directory and go into it. 
 DIR=temp.$$ 
 mkdir $DIR 
 cd $DIR 

 # Create a Git repository. 
 git init 

 # Create a file containing the lines 1 to 10. 
 seq 1 10 file 
 git add file 
 git commit -m 'Commit A' 

 # Start the dev branch at commit A. 
 git branch dev HEAD 

 # Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
 # This sed command adds a line 1.5 before the line 2. 

 sed --in-place -e '/^2$/i1.5' file 
 git commit -a -m 'Commit B' 

 sed --in-place -e '/^3$/i2.5' file 
 git commit -a -m 'Commit C' 

 sed --in-place -e '/^4$/i3.5' file 
 git commit -a -m 'Commit D' 

 # Show the commit structure of master. 
 git log --graph --oneline master 
 git log --graph -p master 

 # Go to the dev branch and create commits with a non-trivial merge. 
 git checkout dev 

 sed --in-place -e '/^5$/i4.5' file 
 git commit -a -m 'Commit P' 

 git branch dev1 HEAD 

 sed --in-place -e '/^6$/i5.5' file 
 git commit -a -m 'Commit Q' 

 git checkout dev1 

 sed --in-place -e '/^7$/i6.5' file 
 git commit -a -m 'Commit R' 

 git checkout dev 

 # Merge commits Q and R, but add the additional line 7.5 (to simulate 
 # fixes that were needed to resolve the merge). 

 git merge --no-commit dev1 
 sed --in-place -e '/^8$/i7.5' file 
 git commit -a -m 'Commit S' 

 sed --in-place -e '/^9$/i8.5' file 
 git commit -a -m 'Commit T' 

 # Show the commit structure of dev. 
 git log --graph --oneline dev 
 # *** Note that the diffs do not show the line 7.5 added in commit S. 
 git log --graph -p dev 

 # Rebase the dev branch to the tip of master. 
 git checkout dev 
 git branch -f rebase dev 
 git checkout rebase 
 git rebase master 

 # Show the commit structure. 
 git log --graph --oneline 
 # *** Note that the line 7.5 added in commit S isn't carried into the new 
 branch. 
 git log --graph -p 

 # Rebase the dev branch to the tip of master using --preserve-merges. 
 git checkout dev 
 git branch -f rebase dev 
 git checkout rebase 
 git rebase --preserve-merges master 

 # Show the commit structure. 
 git log --graph --oneline 
 # *** Note that the line 7.5 added in commit S isn't carried into the new 
 branch. 
 git log --graph -p 
 -- 
 $ # Create a temporary directory and go into it. 
 $ DIR=temp.$$ 
 $ mkdir $DIR 
 $ cd $DIR 

 $ # Create a Git repository. 
 $ git init 
 Initialized empty Git repository in 
 /common/not-replicated/worley/T7/temp.21586/.git/ 

 $ # Create a file containing the lines 1 to 10. 
 $ seq 1 10 

Re: [git-users] Re: Rebasing problems

2013-02-01 Thread Philip Oakley
Is this what they call an 'Evil Merge' (git style) where the final content was 
not in either of the original commits. 

In such cases it's hard to attribute which source commit contained the data 
that is in the merge. 

It's as if an additional change was added, over and above choosing between 
which of the source commit changes should 'win' when line conflict.
  - Original Message - 
  From: Blind 
  To: git-users@googlegroups.com 
  Sent: Friday, February 01, 2013 5:07 PM
  Subject: [git-users] Re: Rebasing problems


  I tryed your thing, and yes in both cases we end up with a file without 7.5 
line in it ...
  this is not good from my point of view...


  git rebase --preserve-merges still keeps the S, 
  but he keeps only the info of the changes introduced from the both parents, 
  he forgot about your manual change.


  I guess a further investigation at the point of:


  git merge --no-commit dev1 
  sed --in-place -e '/^8$/i7.5' file 
  git commit -a -m 'Commit S' 



  wil make sence.


  I am still not sure if it is a git commit problem in case of middle of 
merge,
  or maybe somebody forgot to diff-tree correctly the things...


  I am surely very interested how this will turn out.

  31 януари 2013, четвъртък, 19:47:21 UTC+2, Dale Worley написа:
I'm investigating how rebase works, and I'm finding that it doesn't 
work well if the rebased branch contains merges.  Am I using rebase 
incorrectly? 

In particular, if there are merge commits on the old branch that 
contain changes that are not contained in either of the commits that 
are merged, rebase doesn't carry them properly into the new branch. 

(This sort of merge is not unusual; there may be adjustments needed to 
combine two sets of changes for reasons other than a purely textual 
collision between the changes.) 

As far as I can tell, rebase without --preserve-merges entirely 
ignores merge commits on the old branch.  Rebase with 
--perserve-merges seems to recreate the new merges de novo rather than 
by examining the old merge to determine what it changes.  Neither of 
these actions is optimal (IMHO). 

As a test case, I've written the following shell script.  It's written 
for Linux, but the comments should be clear enough to allow manually 
executing the git commands on other systems.  The places where I think 
Git is behaving poorly are marked with ***.  Following the script is 
the output of my execution of the script. 

The beginning of the script creates this commit structure: 

   A---B---C---D master 
\ 
 \   Q   
  \ / \ 
   P   S---T dev 
\ / 
 R   

The goal is to rebase dev (calling it branch 'rebase') to the head of 
master.  But getting the changes that are in S that are not in Q or R 
carried into the new branch seems to be impossible. 

-- 
set -ve 

# Create a temporary directory and go into it. 
DIR=temp.$$ 
mkdir $DIR 
cd $DIR 

# Create a Git repository. 
git init 

# Create a file containing the lines 1 to 10. 
seq 1 10 file 
git add file 
git commit -m 'Commit A' 

# Start the dev branch at commit A. 
git branch dev HEAD 

# Add lines 1.5, 2.5, and 3.5 in a series of commits on master. 
# This sed command adds a line 1.5 before the line 2. 

sed --in-place -e '/^2$/i1.5' file 
git commit -a -m 'Commit B' 

sed --in-place -e '/^3$/i2.5' file 
git commit -a -m 'Commit C' 

sed --in-place -e '/^4$/i3.5' file 
git commit -a -m 'Commit D' 

# Show the commit structure of master. 
git log --graph --oneline master 
git log --graph -p master 

# Go to the dev branch and create commits with a non-trivial merge. 
git checkout dev 

sed --in-place -e '/^5$/i4.5' file 
git commit -a -m 'Commit P' 

git branch dev1 HEAD 

sed --in-place -e '/^6$/i5.5' file 
git commit -a -m 'Commit Q' 

git checkout dev1 

sed --in-place -e '/^7$/i6.5' file 
git commit -a -m 'Commit R' 

git checkout dev 

# Merge commits Q and R, but add the additional line 7.5 (to simulate 
# fixes that were needed to resolve the merge). 

git merge --no-commit dev1 
sed --in-place -e '/^8$/i7.5' file 
git commit -a -m 'Commit S' 

sed --in-place -e '/^9$/i8.5' file 
git commit -a -m 'Commit T' 

# Show the commit structure of dev. 
git log --graph --oneline dev 
# *** Note that the diffs do not show the line 7.5 added in commit S. 
git log --graph -p dev 

# Rebase the dev branch to the tip of master. 
git checkout dev 
git branch -f rebase dev 
git checkout rebase 
git rebase master 

# Show the commit structure. 
git log --graph