Description
isomorphic-git/isomorphic-git#643 (comment)
I'm kind of confused by lots of thoughts 🤔
For instance, what if:
commit({ ...,
author: {
name: 'someone',
email: '...',
date: new Date('August 19, 2012 23:15:30')
},
committer: {
name: 'me'
email: '...'
}
})In this case, I guess the user has intended to set author's date to several years ago but apparently still wants to commit just now as himself, because the docs page says nothing about such a case though seeing author.date it says just "Default is the current date". But current implementation won't do that. This way the user is likely to get a misdated commit object accidentally. I don't know what is your design decision actually @wmhilton @mojavelinux, anyway I just followed to this behaviour in #643 with 5bc1d66.
Here's another instance:
commit({ ...,
author: {
name: 'someone',
email: '...'
}
})We expect the auther to be also the committer in this case, but what if the user didn't read the docs well and was to commit as himself using default values in .git/config, not author? This case is pretty hard to prevent from having unexpected commits. Although I don't think such a tiny edge case is worth supporting, acually.
Also what if:
commit({ ...,
author: {
name: 'someone',
email: '...'
},
committer: {
name: 'me'
email: '...',
date: new Date('August 19, 2012 23:15:30')
}
})I can't imagine the case author's date is later than committer's, however I'm not sure whether we should default it to committer's or now. For API consistency, we may want to choose the latter.
So... even though we don't make such breaking changes, we may want to write some explicit notes with highlighted style in the docs about them, and of course it's also possible to throw some errors for such ambiguous parameter patterns.