Re: [PATCH] pathspec: warn on empty strings as pathspec

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

Re；跨境电子商务物流供应商，天天有港車直派香港四號碼頭邦威安舍倉庫.

Dear Sir/Miss 本公司專業做中小微企業出口退税和单证報關出口物流运输，只要贵司拥有一般纳税人资质和能开17%的增值税专用发票，我司便能为贵司做退税；无论您有无进出口经营权，我司都可帮您做单证， 客户无需提供单证，只需提供货物清单，即可办理货物中国报关和香港清关；承运商品：玩具类，服装类，五金类，生活用品类，家具类等各种普通货物，敏感货物都可以承接。 以下報價為常見物流交貨報價，如有需要，歡迎來電詢價 1）散杂貨一般貿易退稅報關（单证報關）出口香港報價； （一）中港散貨收费： RMB0.6/kg（最低收RMB200/單） （二）報關费：RMB250

Re: Fast-forward able commit, otherwise fail

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

Fast-forward able commit, otherwise fail

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

[PATCH] pathspec: warn on empty strings as pathspec

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.

Re: How to find commits unique to a branch

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

What's cooking in git.git (Jun 2016, #07; Mon, 20)

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

Re: [PATCH 1/2] archive-tar: write extended headers for file sizes >= 8GB

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

Re: [PATCH 2/2] archive-tar: write extended headers for far-future mtime

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

Re: [PATCH 0/3] fix local_tzoffset with far-in-future dates

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

Re: How to find commits unique to a branch

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

Re: [RFC/PATCH] push: deny policy to prevent pushes to unwanted remotes.

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

Re: [PATCH 0/3] fix local_tzoffset with far-in-future dates

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.

Re: may be bug in svn fetch no-follow-parent

+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

[PATCH 1/3] t0006: rename test-date's "show" to "relative"

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

[PATCH 0/3] fix local_tzoffset with far-in-future dates

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

[PATCH 3/3] local_tzoffset: detect errors from tm_to_time_t

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().

[PATCH 2/3] t0006: test various date formats

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

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

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

How to find commits unique to a branch

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

Re: unable to pull from remote if commit date is in the future

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,

Re: unable to pull from remote if commit date is in the future

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

Re: unable to pull from remote if commit date is in the future

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

Re: unable to pull from remote if commit date is in the future

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

Re: [PATCH] perf: accommodate for MacOSX

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

Re: unable to pull from remote if commit date is in the future

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

Re: unable to pull from remote if commit date is in the future

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'

Re: unable to pull from remote if commit date is in the future

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

Re: [PATCH] Make find_commit_subject() more robust

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

Re: [PATCH v2 7/7] format-patch: use stdout directly

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

Re: [PATCH 1/1] mingw: work around t2300's assuming non-Windows paths

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

Re: unable to pull from remote if commit date is in the future

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

Re: [PATCH] mingw: let the build succeed with DEVELOPER=1

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.

Re: unable to pull from remote if commit date is in the future

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

unable to pull from remote if commit date is in the future

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

Re: Problem with --shallow-submodules option

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

Re: [PATCH] shallow clone to not imply shallow submodules

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

[PATCH] t5614: don't use subshells

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

Re: [PATCH] shallow clone to not imply shallow submodules

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

Re: [PATCH] shallow clone to not imply shallow submodules

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

Re: [PATCH v2 1/7] log-tree: respect diffopt's configured output file stream

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()

Re: Short-term plans for the post 2.9 cycle

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

[PATCH] shallow clone to not imply shallow submodules

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

Re: Short-term plans for the post 2.9 cycle

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

Re: [PATCH 5/5] format-patch: avoid freopen()

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

Re: [PATCH v2 0/8] object_id part 4

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

git stash doesn't always save work dir as-is: bug?

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

Problem with --shallow-submodules option

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

Re: [PATCH v2 0/7] Let log-tree and friends respect diffopt's `file` field

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

With Good Faith...

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

[PATCH v2 6/7] format-patch: avoid freopen()

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

[PATCH v2 5/7] format-patch: explicitly switch off color when writing to files

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

[PATCH v2 7/7] format-patch: use stdout directly

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:

[PATCH v2 4/7] shortlog: support outputting to streams other than stdout

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

[PATCH v2 1/7] log-tree: respect diffopt's configured output file stream

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:

[PATCH v2 3/7] graph: respect the diffopt.file setting

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

[PATCH v2 0/7] Let log-tree and friends respect diffopt's `file` field

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

[PATCH v2 2/7] line-log: respect diffopt's configured output file stream

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

Re: [PATCH v2 0/8] object_id part 4

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

Re: [PATCH 5/5] format-patch: avoid freopen()

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: > >> >

Re: [BUG REPORT] git 2.9.0 clone --recursive fails on cloning a submodule

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

Re: Problem with git-http-backend.exe as iis cgi

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 >

Re: Problem with Integrated Vim Editor on Win 10

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, >

Re: ssh key

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

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

> 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

[GSOC Update] Week 7

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

may be bug in svn fetch no-follow-parent

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

Re: [PATCH v2 0/8] object_id part 4

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

Re: [PATCH] perf: accommodate for MacOSX

Hi Lars, 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

Re: [PATCH 5/5] format-patch: avoid freopen()

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: [PATCH 5/5] format-patch: avoid freopen()

Hi Eric, On Sun, 19 Jun 2016, Eric Sunshine wrote: > On Sat, Jun 18, 2016 at 6:04 AM, Johannes Schindelin > wrote: > > 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. > >

Re: What's cooking in git.git (Jun 2016, #05; Thu, 16)

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) (I will hopefully be able to do a separate review of the smudge/clean patch) (And jo...@joeyh.name is not reachable from web.de) -- To unsubscribe from