llvm dev - Feb 2016 - RFC: Move the test-suite LLVM project to GitHub?

One thing to watch out for: by default, in git, only the commit date
(and not the *push date*) is part of the commit metadata.  This means
if I write a patch today and push it two months later, the commit date
on the commit will be skewed by two months.  We could fix this using a
hook, but then the complication is that as soon as the hook changes
the commit date to `date`, the SHA-1 of the newly edited commit will
change.

I'm not a git expert though, so it could be I'm overlooking something
obvious.

-- Sanjoy



On Thu, Feb 25, 2016 at 7:34 AM, Renato Golin via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 25 February 2016 at 15:01, Joachim Durchholz via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Well, PRs are a good way to discuss proposed patches, so you can take
the
>> discussion there. Particularly if the git hoster gives you all the web
forum
>> thingies you want, including the ability to be helpful with Markdown.
>> Also, a PR is easy to integrate once it's done.
>
> Phabricator, for better or worse, has all those qualities.
>
>
>> On the git side of things, you need to make sure that history isn't
>> rewritten official branches such as master.
>
> Someone mentioned server-side hooks, I think that settles the problem.
>
>
>> On many projects, people still go through PRs even if they have direct
write
>> access. Simply to make sure that a second pair of eyes have looked at
the
>> code before it goes in.
>
> With the amount of commits we have (~100 / day), that would be
> impossible. But we still do that with Phab on the more complicated
> bits.
>
> We're aware of the benefits of code review, etc. I was wondering if
> you had some technical issues with git not being suitable. It seems
> there isn't anything particularly broken, that some hooks can't
fix.
>
>
>> For that, public git hosting services are a no-brainer.
>> You need to look at permissions because you can't simply set up
gitolite,
>> you have to live with whatever the service offers.
>
> That's a small cost, I'd say. And we can always move providers
later
> on, which is a lot simpler with git than SVN.
>
>
>> The GitHub "flow" isn't the right one for every project,
so the tooling does
>> matter.
>
> As a first step, we're not planning on following the GitHub flow, just
> using the GitHub storage and bandwidth. :)
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


-- 
Sanjoy Das
http://playingwithpointers.com

Am 25.02.2016 um 17:25 schrieb Sanjoy Das:
> One thing to watch out for: by default, in git, only the commit date
> (and not the *push date*) is part of the commit metadata.  This means
> if I write a patch today and push it two months later, the commit date
> on the commit will be skewed by two months.
Option 1: Rewrite your local history so that the last commit was done on 
the day you push; the command is "git commit --amend".

Option 2: Edit the changelog to reflect that you pushed something. This 
is the cleanest option in the sense that if the push history is 
relevant, this should probably be in the changelog.

Option 3: Postpone the commit to the day you push. This is only feasible 
if you have that work in a separate tree that you don't need to touch 
between last commit and push. Even then this isn't the first thing that 
I'd do, but maybe your use case is better suited for that.

Option 4: When merging the topic branch into the master branch before 
pushing, do "git merge --no-ff". This will create a merge commit even
if
the merge would run as a fast-forward, non-commit-creating merge. This 
is the "official way" to achieve what you want, if you have push
rights.

 > We could fix this using a
 > hook, but then the complication is that as soon as the hook changes
 > the commit date to `date`, the SHA-1 of the newly edited commit will
 > change.

 From the various "cool tricks around git" websites that I have seen 
over time, most strongly advise against modifying the tree in hooks even 
when it's possible at all.
Most highlight that the committer will have to remember to git pull from 
origin, otherwise they will have to merge before the next push. I dimly 
recall having seen mentions of more troubles down that road, but I 
forgot the details.

On 25 February 2016 at 17:10, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Option 1: Rewrite your local history so that the last commit was done on
the
> day you push; the command is "git commit --amend".
By far the best option. Puts the work on people who care about dates.

Most of the time, though, we'll be doing interactive rebase, squash,
etc, so the dates and hashes will be fresh.

cheers,
--renato