How should files be moved in the glibc repository

How should files be moved in the glibc repository

[Steve Ellcey]

I have a question about moving files in GIT and how that should be
done in the glibc repository.  As part of the aarch64 ILP32 patches
that I am getting ready to submit I am creating some subdirectories
(ilp32 and lp64) and moving some existing files, mostly abilist files,
from the parent directory down to the lp64 directory.  Should I do a
'git mv' or a 'git rm / git add' to move these files?  Or does it matter?

Right now, in the patch I am creating, I do 'git rm/git add' and I noticed
that if I applied the patches to a clean tree, the files I removed do not
actually get removed from my source tree.

The files are not in the tree where I create the patch and if I do a 
git status they show up as deleted.  But when I create the patch there
does not seem to be anything in it that would record that these files
are deleted and if I apply the patch to a new git tree with the patch
command, the deleted files still appear in that tree.  The new files are
created as expected, but the old ones are not deleted.  This causes build
problems unless the deleted files are removed by hand.  Am I doing something
wrong when creating the patch?  Should I use 'git mv' instead?

Steve Ellcey
sellcey@caviumnetworks.com

Re: How should files be moved in the glibc repository

[Andreas Schwab]

On Nov 28 2016, Steve Ellcey <sellcey@cavium.com> wrote:

> 'git mv' or a 'git rm / git add' to move these files?  Or does it matter?

It doesn't matter.  Both do exactly the same.

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."

Re: How should files be moved in the glibc repository

[Yury Norov]

On Mon, Nov 28, 2016 at 07:00:35PM +0100, Andreas Schwab wrote:
> On Nov 28 2016, Steve Ellcey <sellcey@cavium.com> wrote:
> 
> > 'git mv' or a 'git rm / git add' to move these files?  Or does it matter?
> 
> It doesn't matter.  Both do exactly the same.
> 
> Andreas.

If you see garbage like this after moving files, try 'git clean -f'.
But be aware that it deletes all untracked files. And your tags, for
example, may disappear.

Yury

Re: How should files be moved in the glibc repository

[Steve Ellcey]

On Mon, 2016-11-28 at 19:00 +0100, Andreas Schwab wrote:
> On Nov 28 2016, Steve Ellcey <sellcey@cavium.com> wrote:
> 
> > 
> > 'git mv' or a 'git rm / git add' to move these files?  Or does it
> > matter?
> It doesn't matter.  Both do exactly the same.
> 
> Andreas.

I found my problem.  I was doing 'git diff' and not 'git diff HEAD'.
The 'git diff' command did not capture renames or deletes when creating
a patch, the 'git diff HEAD' command does capture them and then when I
apply that patch the old files are no longer there.

Steve Ellcey
sellcey@caviumnetworks.com

Re: How should files be moved in the glibc repository

[Zack Weinberg]

On Mon, Nov 28, 2016 at 1:34 PM, Steve Ellcey
<sellcey@caviumnetworks.com> wrote:
>
> I found my problem.  I was doing 'git diff' and not 'git diff HEAD'.
> The 'git diff' command did not capture renames or deletes when creating
> a patch, the 'git diff HEAD' command does capture them and then when I
> apply that patch the old files are no longer there.

Doing `git config --global diff.renames true` might sort this out.
Also, for patch submission `git format-patch` is better.

zw

Re: How should files be moved in the glibc repository

[Andreas Schwab]

On Nov 28 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote:

> I found my problem.  I was doing 'git diff' and not 'git diff HEAD'.

You should create a commit and then use format-patch.

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."

Re: How should files be moved in the glibc repository

[Andreas Schwab]

On Nov 28 2016, Zack Weinberg <zackw@panix.com> wrote:

> Doing `git config --global diff.renames true` might sort this out.

That doesn't change the semantics of the output.  With or without this
setting, git apply will do the same thing.  In git terms, renaming a
file is strictly the same as removing it under the old name and adding
it under the new name.

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."

Re: How should files be moved in the glibc repository

[Zack Weinberg]

On Mon, Nov 28, 2016 at 2:55 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Nov 28 2016, Zack Weinberg <zackw@panix.com> wrote:
>
>> Doing `git config --global diff.renames true` might sort this out.
>
> That doesn't change the semantics of the output.  With or without this
> setting, git apply will do the same thing.  In git terms, renaming a
> file is strictly the same as removing it under the old name and adding
> it under the new name.

I meant it might make `git diff` behave the same as `git diff HEAD`.

Re: How should files be moved in the glibc repository

[Mike Frysinger]

On Mon, Nov 28, 2016 at 3:39 PM, Zack Weinberg <zackw@panix.com> wrote:
> On Mon, Nov 28, 2016 at 2:55 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
>> On Nov 28 2016, Zack Weinberg <zackw@panix.com> wrote:
>>> Doing `git config --global diff.renames true` might sort this out.
>>
>> That doesn't change the semantics of the output.  With or without this
>> setting, git apply will do the same thing.  In git terms, renaming a
>> file is strictly the same as removing it under the old name and adding
>> it under the new name.
>
> I meant it might make `git diff` behave the same as `git diff HEAD`.

Andreas is correct -- i don't think it has any bearing on it

also, the man page says the default is "true" :)
-mike

Re: How should files be moved in the glibc repository

[Mike Frysinger]

On Mon, Nov 28, 2016 at 2:39 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Nov 28 2016, Steve Ellcey <sellcey@caviumnetworks.com> wrote:
>> I found my problem.  I was doing 'git diff' and not 'git diff HEAD'.
>
> You should create a commit and then use format-patch.

if sending to the list, i'd recommend using the -C/-M options -- it
makes the diff much easier to read/follow.  it'll just show metadata
lines indicating the rename rather than two full diffs -- one showing
you deleting the original and one showing you adding the new one.

i think setting the git-config diff.renames option Zack referenced to
"copy" will get you automatic -C behavior.  personally i create an
alias like:
$ git config --global alias.format-patch "format-patch -C -M"
-mike

Re: How should files be moved in the glibc repository

[Andreas Schwab]

On Nov 28 2016, Mike Frysinger <vapier@gentoo.org> wrote:

> also, the man page says the default is "true" :)

Only in a very recent version.

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."

Re: How should files be moved in the glibc repository

[Mike Frysinger]

On Mon, Nov 28, 2016 at 5:14 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> On Nov 28 2016, Mike Frysinger <vapier@gentoo.org> wrote:
>> also, the man page says the default is "true" :)
>
> Only in a very recent version.

ah i thought i had an old version since my corp system is Ubuntu
Trusty, and it tends to have crufty software.  but i guess it has some
weird bastardized snapshot of git.

everyone should be running the latest release of git though.  it's
where all the fun new features are.
-mike

Re: How should files be moved in the glibc repository

[Russ Allbery]

Zack Weinberg <zackw@panix.com> writes:
> Steve Ellcey <sellcey@caviumnetworks.com> wrote:

>> I found my problem.  I was doing 'git diff' and not 'git diff HEAD'.
>> The 'git diff' command did not capture renames or deletes when creating
>> a patch, the 'git diff HEAD' command does capture them and then when I
>> apply that patch the old files are no longer there.

> Doing `git config --global diff.renames true` might sort this out.
> Also, for patch submission `git format-patch` is better.

I suspect the problem that Steve is having is that git mv implicitly does
a git add of the moved file, so the diff is in the index and therefore no
longer shows up in git diff by default (which shows only differences not
added to the index).  git diff --cached will show the rename.

You'll be able to see the difference in git status.  The renames will show
up in the portion of the output for changes that one has already used git
add on.

-- 
Russ Allbery (eagle@eyrie.org)              <http://www.eyrie.org/~eagle/>

Re: How should files be moved in the glibc repository

[Andreas Schwab]

On Nov 29 2016, Russ Allbery <eagle@eyrie.org> wrote:

> I suspect the problem that Steve is having is that git mv implicitly does
> a git add of the moved file

Well, he compared it with git rm/add, which does the same.

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."

Re: How should files be moved in the glibc repository

[Steve Ellcey]

On Mon, 2016-11-28 at 20:25 -0800, Russ Allbery wrote:
> 
> I suspect the problem that Steve is having is that git mv implicitly does
> a git add of the moved file, so the diff is in the index and therefore no
> longer shows up in git diff by default (which shows only differences not
> added to the index).  git diff --cached will show the rename.
> 
> You'll be able to see the difference in git status.  The renames will show
> up in the portion of the output for changes that one has already used git
> add on.

I think this was the basis of my problem.  I thought 'git rm/add' might
be different than 'git mv' with respect to this but they aren't.  I had
never used the --cached option on diff before.  Of course in order to
use --cached I had to use 'git add' on all the files I modified so that
the patch included the files I modified as well as the ones I moved.
That was what I eventually did.

I did commit all my changes locally and run format-patch at one point,
that worked OK though I don't like how it uses the commit comment as
the text of the email since I would normally have different text and
comments in those two different places.  Yes, I realize I can edit the
email before I send it.  I didn't send my patch this way ultimitely
because I had committed my changes on the master branch (locally), then
before sending anything I wanted to update it with any changes from the
FSF tree so I did a 'git pull'.  That worked and it seemed to merge my
changes with the latest FSF changes but after I had done that I
couldn't figure out how to use format-patch to recreate my patch, i.e.
I couldn't figure out how to specify what version/diff to use when
building my patch.  When I just did 'git format-patch', or 'git format-
patch HEAD', or 'git format-patch HEAD~' I either got nothing or a
whole bunch of patches that were not my changes.  Maybe I should have
commited my changes on a local branch instead of on the local master
but I hadn't.

Steve Ellcey
sellcey@caviumnetworks.com

Re: How should files be moved in the glibc repository

[Joseph Myers]

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

On Tue, 29 Nov 2016, Steve Ellcey wrote:

> email before I send it.  I didn't send my patch this way ultimitely
> because I had committed my changes on the master branch (locally), then
> before sending anything I wanted to update it with any changes from the
> FSF tree so I did a 'git pull'.  That worked and it seemed to merge my

If you commit to local master, you should also use "git pull --rebase" 
rather than plain pull.  (We generally avoid merge commits on glibc 
master, keeping the history linear.)

-- 
Joseph S. Myers
joseph@codesourcery.com