On Fri, Apr 25, 2014 at 04:09:47PM -0700, a...@bellandwhistle.net wrote:
> >Andrew Ardill writes:
> >
> >As a data point, I have seen people add ".gitignore" to their
> >.gitignore file, as they don't want to share the file.
>
> Right, I've seen that too.
That something I am actually doing in my
On Thu, Apr 24, 2014 at 09:41:06AM -0400, Theodore Ts'o wrote:
> On Thu, Apr 24, 2014 at 03:23:54AM -0500, Felipe Contreras wrote:
> Creating a ~/.gitconfig file if one doesn't already is one I agree
> with, and at least on Unix systems, telling them that the config file
> lives in ~/.gitconfig, or
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> > Btw, can we please take away this discussion from ksummit-attendees? It's
> > got
> > absolutely nothing to do with kernel summit and is getting fairly annoyin
On Tue, Oct 29, 2013 at 10:09:53AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-10-28 at 09:59 +0100, Christoph Hellwig wrote:
> > Btw, can we please take away this discussion from ksummit-attendees? It's
> > got
> > absolutely nothing to do with kernel summit and is getting fairly annoyin
> So what's the converse of "fetch" (to rename git-ssh-push to)?
> Maybe "ship"?
The opposite of "fetch" is "throw" or "toss".
(Just avoid tossing cookies or off.)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
[A discussion on the git list about how to provide a hardlinked file
that *cannot* me modified by an editor, but must be replaced by
a new copy.]
[EMAIL PROTECTED] wrote all of:
>>> perhaps having a new 'immutable hardlink' feature in the Linux VFS
>>> would help? I
> Hell no.
>
> The commit _does_ specify the patch uniquely and exactly, so I really
> don't see the point. You can always get the patch by just doing a
>
> git diff $parent_tree $thistree
>
> so putting the patch in the comment is not an option.
Er... no.
One of darcs' big points is that
> One option for optimising this, if we really need to, might be to track
> the file back to its _first_ ancestor and use that as an identification.
> The SCM could store that identifier in the blob itself, or we could
> consider it an 'inode number' and store it in git's tree objects.
This sugges
8 matches
Mail list logo
