There are more strange things happening with dates. One example is
that `git commit --date=@4102444799` produces a commit with the
correct author date "Thu Dec 31 15:59:59 2099 -0800" (for my local
timezone which is Americas/Los_Angeles), while `git commit
--date=@4102444800` produces a commit wit
Hi,
Thanks for the answer.
So it means that it is a setting on the server side which can be
activated? (I guess it depends on the version of the server)
I did some reading in the topic. Are you talking about this setting
"uploadpack.allowReachableSHA1InWant", or did I misunderstood what I
read?
T
Antoine Queru writes:
> However, in the last version, if we want to deny an website,
> including all schemes, we can blacklist the url without the
> scheme. For example, "pushBlacklist = github.com". By doing so, this
> remote is not an url anymore, and it can't be differenced with a local
> rela
Emily Xie writes:
> For any command that takes a pathspec, passing an empty string will
> execute the command on all files in the current directory.
OK.
> This
> results in unexpected behavior.
Technically speaking, your expectation is what is wrong here. An
empty string as a pathspec matches
Dear Sir/Miss
本公司專業做中小微企業出口退税和单证報關出口物流运输，只要贵司拥有一般纳税人资质和能开17%的增值税专用发票，我司便能为贵司做退税；无论您有无进出口经营权，我司都可帮您做单证，
客户无需提供单证，只需提供货物清单，即可办理货物中国报关和香港清关；承运商品：玩具类，服装类，五金类，生活用品类，家具类等各种普通货物，敏感货物都可以承接。
以下報價為常見物流交貨報價，如有需要，歡迎來電詢價
1）散杂貨一般貿易退稅報關（单证報關）出口香港報價；
（一）中港散貨收费： RMB0.6/kg（最低收RMB200/單）
（二）報關费：RMB250
（三）检疫费及其杂费凭票据实报
David Lightle writes:
> I know that I have read that --ff-only and --no-ff are contradictory,
> but I believe that is somewhat ambiguously correct -- I believe the
> two flags contradict in the sense of "what to do with the merge
> commit", but not necessarily on the "when it can be done".
Tradi
Hello,
I am trying to build a git workflow in our enterprise and am almost
evenly torn between a "rebase workflow" and git-flow (which uses merge
instead of rebase, obviously). We are using Bitbucket for pull
requests as code reviews (right or wrong).
I apologize if my inexperience with git show
For any command that takes a pathspec, passing an empty string will
execute the command on all files in the current directory. This
results in unexpected behavior. For example, git add "" adds all
files to staging, while git rm -rf "" recursively removes all files
from the working tree and index. A
On Jun 20 2016, Junio C Hamano wrote:
> Nikolaus Rath writes:
>
>> What's the best way to find all commits in a branch A that have not been
>> cherry-picked from (or to) another branch B?
>>
>> I think I could format-patch all commits in every branch into separate
>> files, hash the Author and Da
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The first batch for this cycle has
Am 16.06.2016 um 06:37 schrieb Jeff King:
The ustar format has a fixed-length field for the size of
each file entry which is supposed to contain up to 11 bytes
of octal-formatted data plus a NUL or space terminator.
These means that the largest size we can represent is
0777, or 1 byte sh
Am 16.06.2016 um 06:37 schrieb Jeff King:
The ustar format represents timestamps as seconds since the
epoch, but only has room to store 11 octal digits. To
express anything larger, we need to use an extended header.
This is exactly the same case we fixed for the size field in
the previous commit
On Mon, Jun 20, 2016 at 03:11:23PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I still don't know how that screwed-up timestamp got _into_
> > a commit, so perhaps there is another bug lurking. I couldn't convince
> > git to parse anything beyond 2100, and committing with
> > GIT_AUT
Nikolaus Rath writes:
> What's the best way to find all commits in a branch A that have not been
> cherry-picked from (or to) another branch B?
>
> I think I could format-patch all commits in every branch into separate
> files, hash the Author and Date of each files, and then compare the two
> li
>
> >> ...
> >>
> >
> > Hello Rémi, thanks you for your input ! I'll make the appropriate changes
> > and send a new version as soon as i can !
>
> Hi Antoine,
>
> do you have an updated version already or is this the one I should look at?
> http://article.gmane.org/gmane.comp.version-control
Jeff King writes:
> I still don't know how that screwed-up timestamp got _into_
> a commit, so perhaps there is another bug lurking. I couldn't convince
> git to parse anything beyond 2100, and committing with
> GIT_AUTHOR_DATE='@5758122296 +' works just fine.
Interesting. The weirdest I c
+Cc: a bunch of folks who may know better how mergeinfo works in git-svn
Александр Овчинников wrote:
> Why git svn fetch try to handle mergeinfo changes when
> no-follow-parent is enabled?
It probably should not... --no-follow-parent isn't a common
config, though. Can you try the patch below?
The "show" tests are really only checking relative formats;
we should make that more clear.
This also frees up the "show" name to later check other
formats. We could later fold "relative" into a more generic
"show" command, but it's not worth it. Relative times are a
special case already because
On Mon, Jun 20, 2016 at 04:00:12PM -0400, Jeff King wrote:
> You _should_ be able to get the right answer by asking git for
> --date=local, but it doesn't seem to work. Looks like it is because our
> tm_to_time_t hits this code:
>
> if (year < 0 || year > 129) /* algo only works for 1970-2099 *
When we want to know the local timezone offset at a given
timestamp, we compute it by asking for localtime() at the
given time, and comparing the offset to GMT at that time.
However, there's some juggling between time_t and "struct
tm" which happens, which involves calling our own
tm_to_time_t().
We ended up testing some of these date formats throughout
the rest of the suite (e.g., via for-each-ref's
"$(authordate:...)" format), but we never did so
systematically. t0006 is the right place for unit-testing of
our date-handling code.
Signed-off-by: Jeff King
---
t/helper/test-date.c | 26 +
Torsten Bögershausen writes:
> There is a conflict in pu:
> "jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
>
> (And currently pu didn't compile)
Thanks for a report, but didn't I mention this breakage in the
What's cooking report already?
--
To unsubscribe from th
Hello,
What's the best way to find all commits in a branch A that have not been
cherry-picked from (or to) another branch B?
I think I could format-patch all commits in every branch into separate
files, hash the Author and Date of each files, and then compare the two
lists. But I'm hoping there's
Norbert Kiesel writes:
> For the record: the faulty commit is
> https://github.com/seandepagnier/weather_routing_pi/commit/23c07cc5d2be7ce68349f4b3719b6fa6fe90e0bf
That commit is part of master. Are you sure you don't have it already?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key
On Mon, Jun 20, 2016 at 09:49:47PM +0200, Eric Deplagne wrote:
> On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote:
> > On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
> >
> > > Hmm. On closer inspection that commit 23c07cc that github shows with
> > > date 2152-06-19 is alread
On Mon, Jun 20, 2016 at 03:46:49PM -0400, Jeff King wrote:
> So to answer my own questions:
>
> $ git cat-file commit 23c07cc | egrep '^author|committer'
> author Sean D'Epagnier 5758122296 -40643156
> committer Sean D'Epagnier 5758122296 -40643156
>
> Yes, the timezone really is that ri
On Mon, 20 Jun 2016 15:39:28 -0400, Jeff King wrote:
> On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
>
> > Hmm. On closer inspection that commit 23c07cc that github shows with
> > date 2152-06-19 is already in my local branch. I got confused because
> > locally it is shown with
Johannes Schindelin writes:
> On Sun, 19 Jun 2016, Lars Schneider wrote:
>
>> > On 18 Jun 2016, at 15:03, Johannes Schindelin
>> > wrote:
>> >
>> > As this developer has no access to MacOSX developer setups anymore,
>> > Travis becomes the best bet to run performance tests on that OS.
>>
>> We
On Mon, Jun 20, 2016 at 03:39:28PM -0400, Jeff King wrote:
> On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
>
> > Hmm. On closer inspection that commit 23c07cc that github shows with
> > date 2152-06-19 is already in my local branch. I got confused because
> > locally it is sho
On Mon, Jun 20, 2016 at 12:39 PM, Jeff King wrote:
> git cat-file commit 23c07cc | egrep '^author|committer'
author Sean D'Epagnier 5758122296 -40643156
committer Sean D'Epagnier 5758122296 -40643156
date --date='@5758122296' returns "Mon Jun 19 15:24:56 PDT 2152" which
is what is shown by git
On Mon, Jun 20, 2016 at 12:05:07PM -0700, Norbert Kiesel wrote:
> Hmm. On closer inspection that commit 23c07cc that github shows with
> date 2152-06-19 is already in my local branch. I got confused because
> locally it is shown with a different date: `git log -1 --format='%ci'
> 23c07cc` shows
Johannes Schindelin writes:
> Just like the pretty printing machinery, we should simply ignore empty
> lines at the beginning of the commit messages.
>
> This discrepancy was noticed when an early version of the rebase--helper
> produced commit objects with more than one empty line between the he
Johannes Schindelin writes:
> Earlier, we freopen()ed stdout in order to write patches to files.
> That forced us to duplicate stdout (naming it "realstdout") because we
> *still* wanted to be able to report the file names.
>
> As we do not abuse stdout that way anymore, we no longer need to
> du
Johannes Schindelin writes:
> On Windows, we have to juggle two different schemes of representing
> paths: the native, Windows paths (the only ones known to the main
> Git executable) on the one hand, and POSIX-ish ones used by the Bash
> through MSYS2's POSIX emulation layer on the other hand.
>
On Mon, Jun 20, 2016 at 11:41 AM, Norbert Kiesel wrote:
> Hi,
>
> I'm following an upstream repo on github. Today morning I saw a new
> commit there, but a `git pull` in my clone did not fetch it and
> instead said "Already up-to-date.". On closer inspection, github
> reports commit time as 2152
Johannes Schindelin writes:
> The recently introduced developer flags identified a couple of
> old-style function declarations in the Windows-specific code where
> the parameter list was left empty instead of specifying "void"
> explicitly. Let's just fix them.
Thanks. It's about time for them
Hmm. On closer inspection that commit 23c07cc that github shows with
date 2152-06-19 is already in my local branch. I got confused because
locally it is shown with a different date: `git log -1 --format='%ci'
23c07cc` shows "2106-02-07 06:28:56 -40643156" which is invalid.
My system is running D
Hi,
I'm following an upstream repo on github. Today morning I saw a new
commit there, but a `git pull` in my clone did not fetch it and
instead said "Already up-to-date.". On closer inspection, github
reports commit time as 2152-06-19. The same project has some other
commits with commit time in
On Mon, Jun 20, 2016 at 6:06 AM, Istvan Zakar wrote:
> Hello,
>
> I'm working on a relatively big project with many submodules. During
> cloning for testing I tried to decrease the amount of data need to be
> fetched from the server by using --shallow-submodules option in the clone
> command. It s
On Mon, Jun 20, 2016 at 09:59:58AM -0700, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
>
> Hi Junio, Peff,
>
> I thought about this patch squashed into
> "clone: do not let --depth imply --shallow-submodules" will actually test
> for the regression.
Yep, it looks good to me.
>
Using a subshell for just one git command is both a waste in compute
overhead (create a new process) as well as in line count.
Suggested-by: Jeff King
Signed-off-by: Stefan Beller
---
Junio,
This goes on top of the patch that I just sent
"[PATCH] shallow clone to not imply shallow submodule
On Mon, Jun 20, 2016 at 10:14:47AM -0700, Stefan Beller wrote:
> > This follows the style of the other tests, so it's the right thing here.
> > But as a style suggestion, I think:
> >
> > git -C super_clone/sub log --oneline >lines &&
> > test_line_count = 3 lines
> >
> > is nicer than the sub
On Mon, Jun 20, 2016 at 10:13 AM, Jeff King wrote:
> On Mon, Jun 20, 2016 at 09:59:58AM -0700, Stefan Beller wrote:
>
>> Signed-off-by: Stefan Beller
>> ---
>>
>> Hi Junio, Peff,
>>
>> I thought about this patch squashed into
>> "clone: do not let --depth imply --shallow-submodules" will actually
Johannes Schindelin writes:
> The diff options already know how to print the output anywhere else
> than stdout. The same is needed for log output in general, e.g.
> when writing patches to files in `git format-patch`. Let's allow
> users to use log_tree_commit() *without* changing global state v
On Mon, Jun 20, 2016 at 9:46 AM, Stefan Beller wrote:
> On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano wrote:
>> Here are the list of topics that are in the "private edition" I use
>> for every day work, grouped by where they sit in the the near-term
>> plan of merging them up to 'next' and then
Signed-off-by: Stefan Beller
---
Hi Junio, Peff,
I thought about this patch squashed into
"clone: do not let --depth imply --shallow-submodules" will actually test
for the regression.
Thanks,
Stefan
t/t5614-clone-submodules.sh | 17 -
1 file changed, 16 insertions(+), 1 dele
On Sun, Jun 19, 2016 at 3:52 PM, Junio C Hamano wrote:
> Here are the list of topics that are in the "private edition" I use
> for every day work, grouped by where they sit in the the near-term
> plan of merging them up to 'next' and then to 'master'.
>
> These will be merged to 'master' soonish.
Johannes Schindelin writes:
> When format-patch calls the diff machinery, want_color() is used to
> determine whether to use ANSI color sequences or not. If use_color is not
> set explicitly, isatty(1) is used to determine whether or not the user
> wants color. When stdout was freopen()ed, this i
Jeff King writes:
> I am on the fence regarding oidcpy/oidclr. I agree they _could_ be
> struct assignments, but it is also convenient to have concept wrapped up
> in a function, in case we ever want to do anything more complicated.
Also dedicated functions have documenation value. There are so
Is there a reason this e-mail never received an answer ?
http://permalink.gmane.org/gmane.comp.version-control.git/234153
Isn't this a bug ?
Thanks,
-- Mathieu
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo
Hello,
I'm working on a relatively big project with many submodules. During
cloning for testing I tried to decrease the amount of data need to be
fetched from the server by using --shallow-submodules option in the clone
command. It seems to check out the tip of the remote repo, and if it's not
Hi,
[sorry, Eric, forgot to Cc: you on the cover letter...]
On Mon, 20 Jun 2016, Johannes Schindelin wrote:
> Johannes Schindelin (7):
> log-tree: respect diffopt's configured output file stream
> line-log: respect diffopt's configured output file stream
> graph: respect the diffopt.file s
Dear Sir/Madam
Please I am not in a hurry but let us use the same heart.
Best Regards,
Mr. Udeij Haid
Please I am Very Sorry To Take A bit Of Your Time. Regards..docx
Description: MS-Word 2007 document
We just taught the relevant functions to respect the diffopt.file field,
to allow writing somewhere else than stdout. Let's make use of it.
Technically, we do not need to avoid that call in a builtin: we assume
that builtins (as opposed to library functions) are stand-alone programs
that may do wi
We rely on the auto-detection ("is stdout a terminal?") to determine
whether to use color in the output of format-patch or not. That happens
to work because we freopen() stdout when redirecting the output to files.
However, we are about to fix that work-around, in which case the
auto-detection has
Earlier, we freopen()ed stdout in order to write patches to files.
That forced us to duplicate stdout (naming it "realstdout") because we
*still* wanted to be able to report the file names.
As we do not abuse stdout that way anymore, we no longer need to
duplicate stdout, either.
Signed-off-by: J
This will be needed to avoid freopen() in `git format-patch`.
Signed-off-by: Johannes Schindelin
---
builtin/shortlog.c | 13 -
shortlog.h | 1 +
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/builtin/shortlog.c b/builtin/shortlog.c
index bfc082e..4c68ba7 100
The diff options already know how to print the output anywhere else
than stdout. The same is needed for log output in general, e.g.
when writing patches to files in `git format-patch`. Let's allow
users to use log_tree_commit() *without* changing global state via
freopen().
Signed-off-by: Johannes
When the caller overrides diffopt.file (which defaults to stdout),
the diff machinery already redirects its output, and the graph display
should also write to that file.
Signed-off-by: Johannes Schindelin
---
graph.c | 30 +-
1 file changed, 17 insertions(+), 13 delet
The idea is to allow callers to redirect log-tree's output to a file
without having to freopen() stdout (which would modify global state,
a big no-no-no for library functions).
I reviewed log-tree.c, graph.c, line-log.c, builtin/shortlog.c and
builtin/log.c line by line to ensure that all calls th
The diff machinery can optionally output to a file stream other than
stdout, by overriding diffopt.file. In such a case, the rest of the
log tree machinery should also write to that stream.
Currently, there is no user of the line level log that wants to
redirect output to a file. Therefore, one mi
On Mon, Jun 20, 2016 at 09:01:30AM +0200, Johannes Schindelin wrote:
> On Sun, 19 Jun 2016, Jeff King wrote:
>
> > I think traditionally we've avoided struct assignment because some
> > ancient compilers didn't do it. But it's in C89, and I suspect it's
> > crept into the code base anyway over th
Hi Eric,
On Mon, 20 Jun 2016, Eric Sunshine wrote:
> On Mon, Jun 20, 2016 at 2:26 AM, Johannes Schindelin
> wrote:
> > On Sun, 19 Jun 2016, Eric Sunshine wrote:
> >> On Sat, Jun 18, 2016 at 6:04 AM, Johannes Schindelin
> >> wrote:
> >> > if (output_directory) {
> >> > + re
On Sun, Jun 19, 2016 at 06:09:28PM -0700, Stefan Beller wrote:
> > I hadn't paid much attention to this topic originally, but was surprised
> > that "--depth 10" in the clone implies "--depth 1" in the submodule.
> > This is not really related to your patch (in fact, your patch makes the
> > logic
On Thu, 10 Mar 2016 07:28:50 +
Florian Manschwetus wrote:
> I tried to setup git-http-backend with iis, as iis provides proper
> impersonation for cgi under windows, which leads to have the
> filesystem access performed with the logon user, therefore the
> webserver doesn't need generic acces
On Thu, 31 Mar 2016 10:20:28 -0700
Zachary Turner wrote:
> I dug into this some more, and as surprising as it is, I believe the
> release of Git 2.8.0 is just busted. I had an installer for 2.7.0
> lying around, so after uninstalling 2.8.0 and re-installing 2.7.0,
> everything works fine.
>
> I
On Sat, 28 May 2016 16:47:06 +0300
matveevma wrote:
> Can i add SSH id_rsa.pub to GIT by shell terminal?
Hi!
First things first: this list has nothing to do neither with Github nor
with shells of any sort. Please note that Github it not Git, it rather
is a hosting for Git projects, so if you h
> On 20 Jun 2016, at 01:51, Junio C Hamano wrote:
>
> Junio C Hamano writes:
>
>> Michael Haggerty writes:
>>
>>> According to [1], something in that test seems to have been trying to run
>>>
>>>git update-ref -d git-p4-tmp/6
>>>
>>> Similarly in the other failed test.
>>
>> Ah, OK, t
= SUMMARY ==
My public git.git is available here[1]. I regularly keep pushing my work so
anyone interested can track me there. Feel free to participate in the
discussions going on PRs with my mentors. Your comments are valuable.
Why git svn fetch try to handle mergeinfo changes when no-follow-parent is
enabled?
Git try to follow parents regardless of this option value.
If branch created without this option then git will follow parent succesfully
If branch created with this option then git try to follow and fail with "cann
Hi Peff,
On Sun, 19 Jun 2016, Jeff King wrote:
> I think traditionally we've avoided struct assignment because some
> ancient compilers didn't do it. But it's in C89, and I suspect it's
> crept into the code base anyway over the years without anyone
> complaining.
I fear that's my fault, at leas
71 matches
Mail list logo
