Re: [RFC] should these two topics graduate to 'master' soon?

So, like, Junio C Hamano said: > There are two topics that are marked as "Will cook in 'next'" for > practically forever in the "What's cooking" reports. The world may > have become ready for one or both of them, in which case we should > do the merge not too late in the cycle. > > * jc/merge-dro

Re: [PATCH] t2027: avoid using pipes

So, like, Prathamesh Chavan said: > The exit code of the upstream of a pipe is ignored thus we should avoid > using it. By writing out the output of the git command to a file, we > can test the exit codes of both the commands. > > Signed-off-by: Prathamesh > --- > t/t2027-worktree-list.sh | 14 +

Re: url..insteadOf vs. submodules

So, like, Junio C Hamano said: > Stefan Beller writes: > > > Do we want to invent a special value for url.*.insteadOf to mean > > "look up in superproject, so I don't have to keep > > a copy that may get stale" ? > > My gut feeling is that we should do the selective/filtered include > Peff m

Re: Fetch/push lets a malicious server steal the targets of "have" lines

So, like, Junio C Hamano said: > Matt McCutchen writes: > > > Then the server generates a commit X3 that lists Y2 as a parent, even > > though it doesn't have Y2, and advances 'x' to X3. The victim fetches > > 'x': > > > >victim server > > > > Y1---Y2---

Re: Git Miniconference at Plumbers

So, like, David Bainbridge said: > Hi, > > The subject matter of the conference looks really interesting but I am > unlikely to be able to attend, unfortunately. > > The subjects being covered like the current State of Git and the > Future of Git, for example, deserve much wider exposure, and I w

Re: Git Miniconference at Plumbers

So, like, Jeff King said: > On Tue, Sep 06, 2016 at 12:42:04PM -0500, Jon Loeliger wrote: > > > I have recently been enlisted by folks at the Linux Foundation to > > help run a Miniconference on Git at the Plumbers Conference [*] > > this fall. > > I see the confer

Git Miniconference at Plumbers

Folks, I have recently been enlisted by folks at the Linux Foundation to help run a Miniconference on Git at the Plumbers Conference [*] this fall. We currently have both Junio Hamano and Josh Triplett signed up to do talks. Hopefully, though not confirmed yet, Junio will give us a brief "State

Re: [PATCH 12/13] Remove irrelevant reference from "Tying it all together"

gt; > index 0d3f04e..08d8c91 100644 > > --- a/Documentation/user-manual.txt > > +++ b/Documentation/user-manual.txt > > @@ -3908,8 +3908,7 @@ save the note about that state, in practice we tend t > o just write the > > result to the file pointed at by `.git/HEAD`, so that

Re: [PATCH] Remove dead link

g oddly self-referential about this quip being removed from the document. Perhaps we should notify the Boy from "Paradise By The Dashboard Light" that he can rest easily now without the Girl as it seems the end of time has come at last. Acked-by: Jon Loeliger jdl -- To

Re: question git & branches

On Mon, 2005-08-29 at 10:03, Linus Torvalds wrote: > (Both "git branch" and "git checkout -b " that reate a new This of course, is Git's answer to the long standing UNIX tradition. Whereas UNIX would creat() files, Git will reate() branches. > Linus jdl - To uns

git-fsck-cache cleaning

Hi GITers, So, after you dink around in a GIT tree for a while, and you discover little bloblets left around by using git-fsck-cache, what do you do? How can you clean up afterwards? Specifically, I have a GIT tree that shows some dangling blobs that are unreferenced in my tree. Not sure how th