Re: [PATCHv3 6/6] entry.c: fix a memleak

On Mon, Mar 30, 2015 at 06:22:11PM -0700, Stefan Beller wrote: > From: John Keeping > > stream_blob_to_fd() always frees the filter now, so there is no memory > leak in entry.c:152 just before the `goto finish`. > > Signed-off-by: John Keeping > Signed-off-by: Stefan Beller > --- > > I adde

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Johannes Sixt writes: >> Junio C Hamano writes: [...] > The patch was discussed here: > http://thread.gmane.org/gmane.comp.version-control.git/198125 > > The reason that this has not progressed any further is this response > in the thread: > > http://thread.gmane.org/gmane.comp.version-control

Forcing git top-level

Hello I’ve copied a .git folder located at the root (/) of a filesystem, into another directory (/home/mydir). If I issue a git rev-parse —show-toplevel I got "/"... I would like to change the top-level to point to /home/mydir. I’ve also tried to bare clone the original .git folder, but the new

Allowing weak references to blobs and strong references to commits

Hi, Currently, in git-cinnabar[1], I'm using a private namespace (refs/cinnabar) for various different things: - references to all the imported heads (which may or may not match remote refs), - the last refs used for a fetch (part of the refspec protocol for remote-helpers) - a branch containi

[PATCH v3] config.c: split some variables to $GIT_DIR/config.worktree

.git/info/config.worktree is a pattern list that splits .git/config in to sets, the common set that does not match the patterns and the worktree set. In normal worktree, or in the main worktree when "git checkout --to" is used, both sets are stored in .git/config. Nothing interesting. In linked w

Re: [PATCH v3] config.c: split some variables to $GIT_DIR/config.worktree

On Tue, Mar 31, 2015 at 7:14 PM, Nguyễn Thái Ngọc Duy wrote: > The general principle is like in the last mail: .git/config is for > both shared and private keys of main worktree (i.e. nothing is > changed from today). .git/worktrees/xx/config.worktree is for > private keys only (and private k

Re: [PATCH] prune --worktrees: fix expire vs worktree existence condition

On Tue, Mar 31, 2015 at 3:47 AM, Max Kirillov wrote: > `git prune --worktrees` was pruning worktrees which were non-existent OR > expired, while it rather should prune those which are orphaned AND > expired, as git-checkout documentation describes. Fix it. > > Add test 'not prune proper checkouts'

Re: [PATCH] gitweb.conf.txt: fix typo

On 2014-04-03 at 22:49, git-pa...@agt-the-walker.net wrote: From: Jérôme Zago "build-time" is used everywhere else. Signed-off-by: Jérôme Zago You are right, it is variable set during build process, not after project is built. ACK (for what it is worth). Acked-by: Jakub Narebski ---

Re: [PATCH] t9814: Guarantee only one source exists in git-p4 copy tests

I'm on holiday this week, so I'll not get a chance to look at these properly until next week. Luke On 30 March 2015 at 04:03, Junio C Hamano wrote: > Vitor Antunes writes: > >> * Modify source file (file2) before copying the file. >> * Check that only file2 is the source in the output of "p4 f

[PATCH v2] enter_repo(): fix docs to match code

On Mon, Mar 30, 2015 at 07:44:08AM -0400, Jeff King wrote: > Yes, this was adjusted in b3256eb (standardize and improve lookup rules > for external local repos, 2012-02-02), but I failed to update the > comment. > > Your patch is certainly an improvement, but I think there are more > inaccuracies

RFC: git status --amend

Hi, for frontends or scripts it would be helpful to be able to use "git status" for getting the repository status compared to HEAD~1 instead of only HEAD (as provided by "git commit --amend" in the pre-filled commit message). Thus, I'm suggesting to add a "--amend" parameter (or a parameter with

[PATCH] improve documentation for some commands that use pathspecs

After being surprised that git-ls-files expands pathspecs, here's a patch that would have saved me. --- Documentation/git-ls-files.txt | 9 + Documentation/git-ls-tree.txt | 8 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/Documentation/git-ls-files.txt b/Documen

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Sergey Organov writes: > 1. How to calculate the set of commits to rebase. > > 2. How to rebase merge commits. > > Can we leave (1) for a while at its current state and focus on (2)? Perhaps. You would have to be careful though, so let me think aloud a bit... Suppose you started from an upstre

Re: [PATCH] improve documentation for some commands that use pathspecs

Joey Hess writes: > After being surprised that git-ls-files expands pathspecs, here's a patch > that would have saved me. > --- I have a vague recollection that we originally wanted to consistently say pathspec but some "user friendliness" folks wanted to avoid the term as much as possible---bla

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Junio C Hamano writes: > Sergey Organov writes: > >> 1. How to calculate the set of commits to rebase. >> >> 2. How to rebase merge commits. >> >> Can we leave (1) for a while at its current state and focus on (2)? > > Perhaps. You would have to be careful though, so let me think aloud > a bit.

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

Junio C Hamano writes: > I wonder if it will be the right way to get a correct result to > apply the difference to go from B to Z on top of an old commit when > you are side-porting. > > Imagine you want to backport the same X-Y history by redoing the > merge Z on top of another child of O (i.e.

[PATCH 0/6] implement @{push} shorthand

The basic idea is that in a triangular workflow, it's useful to be able to refer to both @{upstream} and "the place I would push to" with a shorthand. This idea was discussed over a year ago: http://thread.gmane.org/gmane.comp.version-control.git/240144/focus=240198 I've found it useful since t

[PATCH 1/6] remote.c: drop default_remote_name variable

When we read the remote config from disk, we update a default_remote_name variable if we see branch.*.remote config for the current branch. This isn't wrong, or even all that complicated, but it is a bit simpler (because it reduces our overall state) to just lazily compute the default when we need

Re: [PATCH v2] enter_repo(): fix docs to match code

Paul Tan writes: > On Mon, Mar 30, 2015 at 07:44:08AM -0400, Jeff King wrote: >> Yes, this was adjusted in b3256eb (standardize and improve lookup rules >> for external local repos, 2012-02-02), but I failed to update the >> comment. >> >> Your patch is certainly an improvement, but I think ther

[PATCH 3/6] remote.c: hoist branch.*.remote lookup out of remote_get_1

We'll want to use this logic as a fallback when looking up the pushremote, so let's pull it out into its own function. We don't technically need to make this available outside of remote.c, but doing so will provide a consistent API with pushremote_for_branch, which we will add later. Signed-off-b

[PATCH 2/6] remote.c: drop "remote" pointer from "struct branch"

When we create each branch struct, we fill in the "remote_name" field from the config, and then fill in the actual "remote" field based on that name. However, it turns out that nobody really cares about this field. The only two sites that access it are: 1. git-merge, which uses it to notice when

[PATCH 4/6] remote.c: provide per-branch pushremote name

When remote.c loads its config, it records the branch.*.pushremote for the current branch along with the global remote.pushDefault value, and then binds them into a single value: the default push for the current branch. We then pass this value (which may be NULL) to remote_get_1 when looking up a r

[PATCH 5/6] sha1_name: refactor upstream_mark

We will be adding new mark types in the future, so separate the suffix data from the logic. Signed-off-by: Jeff King --- sha1_name.c | 12 +--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/sha1_name.c b/sha1_name.c index 6d10f05..3741ca3 100644 --- a/sha1_name.c +++ b/sh

[PATCH 6/6] sha1_name: implement @{push} shorthand

In a triangular workflow, each branch may have two distinct points of interest: the @{upstream} that you normally pull from, and the destination that you normally push to. There isn't a shorthand for the latter, but it's useful to have. For instance, you may want to know which commits you haven't

Re: [PATCH v2] enter_repo(): fix docs to match code

On Tue, Mar 31, 2015 at 10:35:56AM -0700, Junio C Hamano wrote: > > In b3256eb (standardize and improve lookup rules for external local > > repos), enter_repo() was modified to use a different precedence ordering > > of suffixes for DWIM of the repository path, and to ensure that the > > repositor

Re: [PATCH v2] enter_repo(): fix docs to match code

Jeff King writes: > I'm not sure that's true. The precedence changed, and the "is it valid" > check changed. Yeah, I must have misread the review thread. I only noticed that the postimage does not have any lines that v1 changed from the original, but at the word level there indeed are these cha

Re: RFC: git status --amend

On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote: > for frontends or scripts it would be helpful to be able to use "git > status" for getting the repository status compared to HEAD~1 instead of > only HEAD (as provided by "git commit --amend" in the pre-filled commit > message). >

[PATCH v3] enter_repo(): fix docs to match code

Hi, On Wed, Apr 1, 2015 at 1:35 AM, Junio C Hamano wrote: > It appears to me that Peff's "squash" is nullifying everything you > did, so a more truthful attribution might be > > From: Jeff King > > commit log message > > S-o-b: Jeff > S-o-b: Paul Tan Thanks, didn

Re: Forcing git top-level

On Tue, Mar 31, 2015 at 11:25:58AM +0200, Cedric Gava wrote: > I’ve copied a .git folder located at the root (/) of a filesystem, > into another directory (/home/mydir). If I issue a git rev-parse > —show-toplevel I got "/"... > I would like to change the top-level to point to /home/mydir. Try ru

[PATCH] init: don't set core.worktree when initializing /.git

If you create a git repository in the root directory with "git init /", we erroneously write a core.worktree entry. That can be surprising if you later move the .git directory to another path (which usually moves the relative working tree, but is foiled if there is an explicit worktree set). The p

Re: RFC: git status --amend

Jeff King writes: > On Tue, Mar 31, 2015 at 04:59:27PM +0200, Sven Strickroth wrote: > >> for frontends or scripts it would be helpful to be able to use "git >> status" for getting the repository status compared to HEAD~1 instead of >> only HEAD (as provided by "git commit --amend" in the pre-fil

Re: [PATCHv3 3/6] line-log.c: fix a memleak

Stefan Beller writes: > On 30.03.2015 22:06, Junio C Hamano wrote: >> If add-line-range does not take ownership of >> parent_range from us, shouldn't we be freeing it whether we called >> it or not??? > > In my understanding it does take ownership of it. (According to my code > review on friday)

Re: [PATCHv3 6/6] entry.c: fix a memleak

John Keeping writes: > On Mon, Mar 30, 2015 at 06:22:11PM -0700, Stefan Beller wrote: >> From: John Keeping >> >> stream_blob_to_fd() always frees the filter now, so there is no memory >> leak in entry.c:152 just before the `goto finish`. >> >> Signed-off-by: John Keeping >> Signed-off-by: St

Re: [PATCH] init: don't set core.worktree when initializing /.git

Jeff King wrote: > No tests, as we would need to be able to write to "/" to do > so. t1509-root-worktree.sh is supposed to test the repository-at-/ case. But I wouldn't be surprised if it's bitrotted, since people don't set up a throwaway chroot or VM for tests too often. [...] > The current beh

Re: [PATCH] protocol upload-pack-v2

Junio C Hamano writes: > I have a feeling that it is a bit too premature to specify the > details at such a low level as "capaiblities are announced by > prefixing four-byte 'c', 'a', 'p', ':' in front" and "a multi-record > group has its element count at the beginning (or an end marker at > the

Re: Allowing weak references to blobs and strong references to commits

From: "Mike Hommey" [...] So I thought, since commits are already allowed in tree objects, for submodules, why not add a bit to the mode that would tell git that those commit object references are meant to always be there aka strong reference, as opposed to the current weak references for submo

Re: Allowing weak references to blobs and strong references to commits

Mike Hommey writes: > So I thought, since commits are already allowed in tree objects, for > submodules, why not add a bit to the mode that would tell git that > those commit object references are meant to always be there aka strong > reference, as opposed to the current weak references for submo

Re: [PATCH] gitweb.conf.txt: fix typo

Jakub Narębski writes: > On 2014-04-03 at 22:49, git-pa...@agt-the-walker.net wrote: >> From: Jérôme Zago >> >> "build-time" is used everywhere else. >> >> Signed-off-by: Jérôme Zago > > You are right, it is variable set during build process, > not after project is built. > > ACK (for what it i

Re: [PATCH 1/6] remote.c: drop default_remote_name variable

Jeff King writes: > When we read the remote config from disk, we update a > default_remote_name variable if we see branch.*.remote > config for the current branch. This isn't wrong, or even all > that complicated, but it is a bit simpler (because it > reduces our overall state) to just lazily com

Re: [PATCH 2/6] remote.c: drop "remote" pointer from "struct branch"

Jeff King writes: > When we create each branch struct, we fill in the > "remote_name" field from the config, and then fill in the > actual "remote" field based on that name. However, it turns > out that nobody really cares about this field. The only two > sites that access it are: > > 1. git-me

RE: Allowing weak references to blobs and strong references to commits

On March 31, 2015 3:55 PM Philip Oakley wrote: > From: "Mike Hommey" > [...] > > So I thought, since commits are already allowed in tree objects, for > > submodules, why not add a bit to the mode that would tell git that > > those commit object references are meant to always be there aka strong >

Clone from shallow bundle bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I made a shallow clone of my repo, then used git bundle create to pack it all into a bundle file, then cloned from that bundle. The initial shallow clone has a .git/shallow file that identifies it as a shallow clone ( and I guess keeps things from com

Re:Make 2015 the best one yourself!

only now, Make 2015 the best one yourself! http://www.google.com/url?q=%68%74tp%3A%2F%2F%63%63%62%6ftcc%2ec%6369.r%75%2F%23852%39%6e%64%35%6d%31%6c6%67%74o%77&sa=D&sntz=1&usg=AFQjCNHmdUNh2YMyh5HH4xz0siXbLrN_CQ -- To unsubs

Re: [PATCH 6/6] sha1_name: implement @{push} shorthand

Jeff King writes: > diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt > index 0796118..5d9df25 100644 > --- a/Documentation/revisions.txt > +++ b/Documentation/revisions.txt > @@ -98,6 +98,31 @@ some output processing may assume ref names in UTF-8. >`branch..merge`). A m

Re: [PATCH 6/6] sha1_name: implement @{push} shorthand

On Tue, Mar 31, 2015 at 1:38 PM, Jeff King wrote: > Signed-off-by: Jeff King > --- > diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt > index 0796118..5d9df25 100644 > --- a/Documentation/revisions.txt > +++ b/Documentation/revisions.txt > @@ -98,6 +98,31 @@ some output proc

Re: [PATCH 4/6] remote.c: provide per-branch pushremote name

Jeff King writes: > Let's make this more like the fetch-remote config. We'll > record the pushremote for each branch, and then explicitly > compute the correct remote for the current branch at the > time of reading. > > Signed-off-by: Jeff King > --- > remote.c | 41 +++-

VCS popularity

openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at and shows an estimated market share between Bazaar, CVS, Git,

Re: VCS popularity

On Tue, 31 Mar 2015, Øyvind A. Holm wrote: openhub.net (formerly ohloh.net) has an interesting comparison of the number of public repositories on the net, based on searches of popular hosting services. This comparison is available at and shows an es

Re: VCS popularity

On 1 April 2015 at 00:03, David Lang wrote: > On Tue, 31 Mar 2015, Øyvind A. Holm wrote: > > openhub.net (formerly ohloh.net) has an interesting comparison of > > the number of public repositories on the net, based on searches of > > popular hosting services. This comparison is available at > >

Re: Clone from shallow bundle bug

Phillip Susi writes: > I made a shallow clone of my repo, then used git bundle create to pack > it all into a bundle file, then cloned from that bundle. I think the introdution of shallow clone feature broke git bundle create by not teaching it that its shallow boundaries are prerequisite commit

Re: [PATCH 1/6] remote.c: drop default_remote_name variable

On Tue, Mar 31, 2015 at 01:37:35PM -0700, Junio C Hamano wrote: > > When we read the remote config from disk, we update a > > default_remote_name variable if we see branch.*.remote > > config for the current branch. This isn't wrong, or even all > > that complicated, but it is a bit simpler (becau

Re: [PATCH 2/6] remote.c: drop "remote" pointer from "struct branch"

On Tue, Mar 31, 2015 at 01:50:05PM -0700, Junio C Hamano wrote: > > Getting rid of it drops one potential source of confusion: > > is the value the match for "remote_name", or is it the > > remote we would fetch from when on that branch (i.e., does > > it fall back to "origin")? > > I had to read

[PATCH] git-p4: fix filetype detection on files opened exclusively

If a Perforce server is configured to automatically set +l (exclusive lock) on add of certain file types, git p4 submit will fail during getP4OpenedType, as the regex doesn't expect the trailing '*exclusive*' from p4 opened: //depot/file.png#1 - add default change (binary+l) *exclusive* Signed-of

Re: [PATCH 2/6] remote.c: drop "remote" pointer from "struct branch"

Jeff King writes: > On Tue, Mar 31, 2015 at 01:50:05PM -0700, Junio C Hamano wrote: > >> it first looked somewhat unnatural that you kept the name with which >> you need to trigger a search for the structure, instead of keeping >> the structure, one of whose field is its name already. > ... > Tha

Re: VCS popularity

On 1 April 2015 at 00:20, Junio C Hamano wrote: > Øyvind A. Holm writes: > > The graphs are pretty interesting: > > > > https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg > > Graphs of relative growth between the various version control systems. > > This plots us at

A kind reminder

Dear Invited Author, You could also upload your invited paper in our conferences in Zakynthos Island, Greece, July 16-20, 2015. Check them via www. inase. org and www. cscc. co Invited Paper implies journal publication in ISI (Web of Knowledge) and SCOPUS and double time of presentation during

Re: [PATCH 6/6] sha1_name: implement @{push} shorthand

On Tue, Mar 31, 2015 at 02:37:25PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt > > index 0796118..5d9df25 100644 > > --- a/Documentation/revisions.txt > > +++ b/Documentation/revisions.txt > > @@ -98,6 +98,31 @@ so

Re: [PATCH 6/6] sha1_name: implement @{push} shorthand

On Tue, Mar 31, 2015 at 05:41:02PM -0400, Eric Sunshine wrote: > On Tue, Mar 31, 2015 at 1:38 PM, Jeff King wrote: > > Signed-off-by: Jeff King > > --- > > diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt > > index 0796118..5d9df25 100644 > > --- a/Documentation/revisions.t

Re: Allowing weak references to blobs and strong references to commits

On Tue, Mar 31, 2015 at 01:23:23PM -0700, Junio C Hamano wrote: > Mike Hommey writes: > > > So I thought, since commits are already allowed in tree objects, for > > submodules, why not add a bit to the mode that would tell git that > > those commit object references are meant to always be there a

[ANNOUNCE] Git v2.3.5

The latest maintenance release Git v2.3.5 is now available at the usual places. It is comprised of 31 non-merge commits since v2.3.4, contributed by 11 people, 2 of which are new faces. This hopefully will be the last update for v2.3.x series before the next feature release v2.4, as we flushed al

Re: [PATCH 6/6] sha1_name: implement @{push} shorthand

Jeff King writes: >> > +static char *tracking_ref_for(struct remote *remote, const char *refname) >> > +{ >> > + char *ret; >> > + >> > + ret = apply_refspecs(remote->fetch, remote->fetch_refspec_nr, refname); >> > + if (!ret) >> > + die(_("@{push} has no local tracking branch for rem

Re: Allowing weak references to blobs and strong references to commits

Mike Hommey writes: > Octopus merges are limited to 16 parents. Huh? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Allowing weak references to blobs and strong references to commits

Mike Hommey wrote: > Octopus merges are limited to 16 parents. The note about this in fast-import is out of date (e.g., see t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How about this patch? -- >8-- Subject: fast-import doc: remove suggested 16-parent limit Merges with an abs

Re: Allowing weak references to blobs and strong references to commits

Jonathan Nieder wrote: > How > about this patch? I think I botched the wording. Here's a second try. -- >8 -- Subject: fast-import doc: remove suggested 16-parent limit Merges with an absurd number of parents are still a bad idea

Re: VCS popularity

On Wed, 1 Apr 2015, Øyvind A. Holm wrote: On 1 April 2015 at 00:20, Junio C Hamano wrote: Øyvind A. Holm writes: The graphs are pretty interesting: https://github.com/sunny256/openhub-repositories/blob/master/graph/relative.svg Graphs of relative growth between the various version control

Re: Allowing weak references to blobs and strong references to commits

On Tue, Mar 31, 2015 at 4:14 PM, Jonathan Nieder wrote: > Mike Hommey wrote: > >> Octopus merges are limited to 16 parents. > > The note about this in fast-import is out of date (e.g., see > t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How > about this patch? Ahh, I thought we

Trying to push into empty repo, get fatal: bad revision 'HEAD'

I have set up a remote repository like so: remote $ cat .git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true sharedrepository = 1 worktree = /srv/http/www.site.com [receive] denyNonFastforwards = true denyCurrentBranch = updateInstead This repo is em

[PATCH V2] t9814: Guarantee only one source exists in git-p4 copy tests

* Modify source file (file2) before copying the file. * Check that only file2 is the source in the output of "p4 filelog". * Remove all "case" statements and replace them with simple tests to check that source is "file2". Signed-off-by: Vitor Antunes --- t/t9814-git-p4-rename.sh | 46 +++

Re: Allowing weak references to blobs and strong references to commits

On Tue, Mar 31, 2015 at 04:14:49PM -0700, Jonathan Nieder wrote: > Mike Hommey wrote: > > > Octopus merges are limited to 16 parents. > > The note about this in fast-import is out of date (e.g., see > t/t7602-merge-octopus-many.sh and v1.6.0-rc0~194, 2008-06-27). How > about this patch? Aha! I

Re: Trying to push into empty repo, get fatal: bad revision 'HEAD'

Samuel Williams writes: > I would expect if you push to an empty repo, it would update it > (because denyCurrentBranch = updateInstead). Good finding. I think the current implementation of updateInstead is set up to bootstrap from an empty repository but only supports incremental updates once t

Re: bug & patch: exit codes from internal commands are handled incorrectly

Ping? The original version of this got some discussion, but this version - nothing. Thanks, Keni On Feb 1, 2015, at 5:32 PM, Kenneth Lorber wrote: > > On Dec 18, 2014, at 2:18 PM, Junio C Hamano wrote: > >> Kenneth Lorber writes: >> Bug: exit codes from (at least) internal commands

Re: bug & patch: exit codes from internal commands are handled incorrectly

On Tue, Mar 31, 2015 at 5:10 PM, Kenneth Lorber wrote: > Ping? The original version of this got some discussion, but this version - > nothing. Pong? I do not know what you meant by "this version". Have you followed Documentaiton/SubmittingPatches? Otherwise the mailing list may have dropped th

Re: Trying to push into empty repo, get fatal: bad revision 'HEAD'

Junio C Hamano writes: > Samuel Williams writes: > >> I would expect if you push to an empty repo, it would update it >> (because denyCurrentBranch = updateInstead). > > Good finding. > > I think the current implementation of updateInstead is set up to > bootstrap from an empty repository but on

[bug (maybe)] Applying patch with '---'

Hi List, So I was just sent a patch generated with 'git format-patch' that 'git am' fails to apply correctly. It applies but part of the commit message is lost. The problem is that the commit message has lines like --- Foo happened did some things to handle Foo --- Bar happened Still pro

Re: Clone from shallow bundle bug

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/31/2015 06:17 PM, Junio C Hamano wrote: > Phillip Susi writes: > >> I made a shallow clone of my repo, then used git bundle create to >> pack it all into a bundle file, then cloned from that bundle. > > I think the introdution of shallow clo

Re: Trying to push into empty repo, get fatal: bad revision 'HEAD'

Junio C Hamano writes: > A fix (or is it an enhancement) would probably look like this. > ... And this time with a pair of tests. It probably should be extended to make sure it fails when the pushed HEAD records paths that are floating in the working tree (as that would mean overwrting them), b

Re: [bug (maybe)] Applying patch with '---'

Chris Packham writes: > So I was just sent a patch generated with 'git format-patch' that 'git > am' fails to apply correctly. It applies but part of the commit > message is lost. > > The problem is that the commit message has lines like > > --- Foo happened > did some things to handle Foo >

Re: Clone from shallow bundle bug

Phillip Susi writes: > On 03/31/2015 06:17 PM, Junio C Hamano wrote: >> Phillip Susi writes: >> >>> I made a shallow clone of my repo, then used git bundle create to >>> pack it all into a bundle file, then cloned from that bundle. >> >> I think the introdution of shallow clone feature broke g