rebase --root conflicts with --committer-date-is-author-date
version:
git version 2.1.4
Linux wolke-w520 3.19.3-towo.1-siduction-amd64 #1 SMP PREEMPT siduction
3.19-9 (2015-03-26) x86_64 GNU/Linux
summary:
if i do `git rebase --committer-date-is-author-date --root', the
committer date is set to now, instead of set to the author date.
when rebasing onto the first commit, it works perfectly well.
reproduce:
set -x
cd
mkdir test
cd test
git init
echo line a; git add a; git commit -m 'jan1' --date '2015-01-01'
echo line a; git add a; git commit -m 'jan2' --date '2015-01-02'
echo line a; git add a; git commit -m 'jan3' --date '2015-01-03'
git log --format=format:%s-%cD-%aD%n
git rebase --committer-date-is-author-date HEAD^^
git log --format=format:%s-%cD-%aD%n
git rebase --committer-date-is-author-date --root
git log --format=format:%s-%cD-%aD%n
git rebase --committer-date-is-author-date HEAD^^
git log --format=format:%s-%cD-%aD%n
git rebase --committer-date-is-author-date --root
git log --format=format:%s-%cD-%aD%n
expected:
jan3-Sat, 03 Jan 2015 13:28:06 -0500-Sat, 3 Jan 2015 13:28:06 -0500
jan2-Sat, 02 Jan 2015 13:28:06 -0500-Fri, 2 Jan 2015 13:28:06 -0500
jan1-Sat, 01 Jan 2015 13:28:06 -0500-Thu, 1 Jan 2015 13:28:06 -0500
actual:
jan3-Sat, 11 Apr 2015 14:28:06 -0400-Sat, 3 Jan 2015 13:28:06 -0500
jan2-Sat, 11 Apr 2015 14:28:06 -0400-Fri, 2 Jan 2015 13:28:06 -0500
jan1-Sat, 11 Apr 2015 14:28:06 -0400-Thu, 1 Jan 2015 13:28:06 -0500
{full output: http://pastie.org/10086950}
sorry if dupe/wrong-venue/poorly-formatted/incomprehensible. i tried.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: move detection doesnt take filename into account
interesting that it considers suffixes {only suffixes following
periods?}. this is insufficient, in my opinion.
with all other things being equal, it ought to find the closest match
{using smith-waterman or some such algorithm}.
as a real-world use case, i have a repository with empty files that
mirrors the file structure of a directory containing large binary files.
when i move a dir, it seems to select the files renamed at random.
On 07/01/2014 05:16 AM, Robin Rosenberg wrote:
- Ursprungligt meddelande -
Från: Elliot Wolk elliot.w...@gmail.com
Till: git@vger.kernel.org
Skickat: måndag, 30 jun 2014 8:38:18
Ämne: move detection doesnt take filename into account
if you move two identical {e.g.: empty} files to two new locations in a
single commit, the move detection picks them {seemingly?} arbitrarily.
it should use a statistical algorithm to compare the filenames and pick
a likely match.
I think it does, but based on filename suffix. E.g. here is a rename of
three empty files with a suffix.
3 files changed, 0 insertions(+), 0 deletions(-)
rename 1.a = 2.a (100%)
rename 1.b = 2.b (100%)
rename 1.c = 2.c (100%)
-- robin
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: move detection doesnt take filename into account
thanks for the info! then i suppose my bug is a petition to have name similarity instead use a different statistical matching algorithm. On 07/01/2014 10:57 AM, Junio C Hamano wrote: Robin Rosenberg robin.rosenb...@dewire.com writes: I think it does, but based on filename suffix. E.g. here is a rename of three empty files with a suffix. 3 files changed, 0 insertions(+), 0 deletions(-) rename 1.a = 2.a (100%) rename 1.b = 2.b (100%) rename 1.c = 2.c (100%) This is not more than a chance. We tie-break rename source candidates that have the same content similarity score to a rename destination using name similarity, whose implementation has been diffcore-rename.c::basename_same(), which scores 1 if `basename $src` and `basename $dst` are the same and 0 otherwise, i.e. from 1.a to a/1.a is judged to be a better rename than from 1.a to a/2.a but otherwise there is nothing that favors rename from 1.a to 2.a over 1.a to 2.b. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
move detection doesnt take filename into account
if you move two identical {e.g.: empty} files to two new locations in a
single commit, the move detection picks them {seemingly?} arbitrarily.
it should use a statistical algorithm to compare the filenames and pick
a likely match.
my apologies in advance if this isnt the right venue or is improperly
formatted, or if this is extraneous noise, or widely known, etc.
+ cd /tmp
+ mkdir repo
+ cd repo
+ git init
Initialized empty Git repository in /tmp/repo/.git/
+ touch a1 b1 c1
+ git add a1 b1 c1
+ git commit -m 1
[master (root-commit) 72f8c89] 1
3 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a1
create mode 100644 b1
create mode 100644 c1
+ git mv a1 a2
+ git mv b1 b2
+ git mv c1 c2
+ git commit -m 2
[master 359da78] 2
3 files changed, 0 insertions(+), 0 deletions(-)
rename c1 = a2 (100%)
rename b1 = b2 (100%)
rename a1 = c2 (100%)
+ git log --name-status -M
commit 359da78caaaf06848ae32359abfeb87db35cdb30
Author: Elliot Wolk elliot.w...@gmail.com
Date: Mon Jun 30 02:26:49 2014 -0400
2
R100c1 a2
R100b1 b2
R100a1 c2
commit 72f8c89b418e3b1d13ec350f4c30b5088fc69e83
Author: Elliot Wolk elliot.w...@gmail.com
Date: Mon Jun 30 02:26:49 2014 -0400
1
A a1
A b1
A c1
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
