* git ls-files --with is very hard if not impossible to find when reading man page
From: Marc Weber @ 2011-02-01 23:33 UTC (permalink / raw)
To: git
Hi
I knew about git-ls. But searching the man page for both: commit and
hash or such didn't tell me about hte --with flag (which cirwin told me
on irc).
Is it worth adding to the man page?
Or is the option that common that most users just know about it?
Marc Weber
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: A Large Angry SCM @ 2011-02-01 23:25 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git
In-Reply-To: <201102012339.31684.trast@student.ethz.ch>
On 02/01/2011 05:39 PM, Thomas Rast wrote:
> A Large Angry SCM wrote:
>> On 01/31/2011 04:44 PM, Thomas Rast wrote:
>>>
>>> Since the remote branches in some sense reflect the "last known state"
>>> of the remote, it would make sense to also update them to whatever a
>>> two-argument fetch got.
>>
>> If this is proposing to break:
>>
>> get-fetch ${REPO} ${SRC_REF}:${DST_REF}
>>
>> then I am against this since that form _is_ used and *is* plumbing.
>
> You're mixing up the two proposals. This one is to teach
>
> git fetch repo foo
>
> to update refs/remotes/repo/foo with the new value (maybe we should
> also have it update in the foo:bar case, but I haven't thought that
> through).
>
> The other one is to forbid 'git pull repo foo:bar' and would not
> change git-fetch at all.
>
I'm not concerned about the pull proposal (I haven't really thought
about it, yet) but I am concerned that your proposal may break (as in
change the behavior of) the case I identified above.
^ permalink raw reply
* Re: [1.8.0] split largest remaining scripts, gitk and gitweb
From: Jakub Narebski @ 2011-02-01 23:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vsjw7xuy3.fsf@alter.siamese.dyndns.org>
Dnia wtorek 1. lutego 2011 23:15, Junio C Hamano napisał:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Two largest files in git repository are gitk and gitweb, see the
> > ...
> > What do you think?
>
> What does this have to do anything with 1.8.0? Isn't this all internal
> implementation that can be brought in without affecting end users?
In the case of gitk we have "prior art" i.e. git-gui, which got split.
In the case of gitweb I am not sure if there having multiple files to
install wouldn't be inconvenient for users (though with "install-gitweb"
target...)
Anyway, I have posted this in subthread of
[1.8.0] reorganize the mess that the source tree has become
because it is also code reorganization.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [1.8.0] Remote tag namespace
From: Johan Herland @ 2011-02-01 23:15 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <20110201181428.GA6579@sigill.intra.peff.net>
On Tuesday 01 February 2011, Jeff King wrote:
> On Tue, Feb 01, 2011 at 05:44:50PM +0700, Nguyen Thai Ngoc Duy wrote:
> > OK I'm not familiar with tag code, but I can try.
> >
> > Proposal:
> >
> > Reserve refs/remote-tags namespace to store tags from remotes. Its
> > structure is the same as in refs/remotes. When pulling tags, put them
> > in refs/remote-tags/<remote> instead of refs/tags.
> > Tag dereference code will be taught about refs/remote-tags with
> > similar deref order as in remote branches.
>
> There are similar questions around remote notes refs. Should there also
> be a refs/remote-notes? And there was some discussion recently about
> fetching remote replace refs.
>
> Should we perhaps be massaging refs/remotes into a structure to handle
> all of these things? Like:
>
> refs/remotes/origin/HEAD (-> refs/remotes/origin/heads/master)
> refs/remotes/origin/heads/master
> refs/remotes/origin/tags/v1.7.4
> refs/remotes/origin/notes/commit
> refs/remotes/origin/replace/f67e92af477a2255b64a1ece33d9d126e763fe9b
>
> i.e., make refs/remotes/* an actual mirror of selected parts of the
> remote's refs/ hierarchy. And then figure out sane rules for merging
> those namespaces into the ref lookup procedure. For heads and tags,
> probably some tweaking of the lookup rules in dwim_ref; for
> replacements, probably you would want to manually say "I am interested
> in this replace" and copy or symref-link it into your refs/ hierarchy.
I fully agree.
In addition - as discussed in http://thread.gmane.org/gmane.comp.version-
control.git/160503/focus=160795 - we should also tweak the refspec format to
make tag auto-following explicit in the refspec.
> And probably something similar with notes.
(going slightly offtopic with the notes discussion here)
I've been thinking that notes should be organized much in the same fashion
as branches/heads. There should be remote notes refs that should only be
updated from the remote, and there should be local notes refs in
refs/notes/*. You should be able to configure upstream relationships between
local notes refs and remote notes refs (e.g. notes.foo.remote and
notes.foo.merge), and auto-merge them on "git notes pull".
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [1.8.0] Remote tag namespace
From: Sverre Rabbelier @ 2011-02-01 23:14 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, Git Mailing List, Nicolas Pitre
In-Reply-To: <20110201181428.GA6579@sigill.intra.peff.net>
Heya,
On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote:
> i.e., make refs/remotes/* an actual mirror of selected parts of the
> remote's refs/ hierarchy. And then figure out sane rules for merging
> those namespaces into the ref lookup procedure.
Jeff, Nguy, are either of you interested in writing up a new/modifying
this proposal to be about namespacing everything? I think it
definitely makes sense to have a namespace for notes, replaces, as
well as tags, especially since it would also allow us to propagate
these by default (at least to the refs/remotes namespace), and think
it's a good idea to go all the way if we're going to do this at all
(or we'll have the same discussion again later for notes and replaces,
and whatever comes after that).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Support different branch layouts in git-p4
From: Ian Wienand @ 2011-02-01 22:59 UTC (permalink / raw)
To: git
Hi,
I think the addition to the git-p4.txt in the diff explains the
reasoning behind the patch best. In short, we have a repository
layout
//depot/foo/branch
//depot/moo/branch
where we require projects 'foo' and 'moo' to be alongside each other.
We can do this with p4 views, but currently have to have 'foo' and
'moo' in separate git repos.
This just munges the incoming paths to either put the branch as the
top level directory, or just remove it entirely if you don't need it.
I've tested it locally, but I don't really have a wide variety of p4
environments to expose it too.
-i
Signed-off-by: Ian Wienand <ianw@vmware.com>
---
contrib/fast-import/git-p4 | 35 +++++++++++++++++++++++-
contrib/fast-import/git-p4.txt | 58 ++++++++++++++++++++++++++++++++++++++++
2 files changed, 92 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..4bd40f8 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -848,6 +848,10 @@ class P4Sync(Command):
optparse.make_option("--max-changes", dest="maxChanges"),
optparse.make_option("--keep-path", dest="keepRepoPath", action='store_true',
help="Keep entire BRANCH/DIR/SUBDIR prefix during import"),
+ optparse.make_option("--branch-path", dest="branchPath", type='choice',
+ choices=('none', 'first'),
+ default=None,
+ help="Remove the branch dir (none) or move it above project dir (first)"),
optparse.make_option("--use-client-spec", dest="useClientSpec", action='store_true',
help="Only sync files that are included in the Perforce Client Spec")
]
@@ -917,6 +921,20 @@ class P4Sync(Command):
if path.startswith(p):
path = path[len(p):]
+ # reorg to move/remove branch from the output filename -- kind
+ # of like how you can set your view in your p4 client
+ if self.keepRepoPath and self.branchPath == 'first':
+ # move the second element first, so what was was
+ # "//depot/proj/branch/file" becomes "branch/proj/file".
+ path = re.sub("^([^/]+/)([^/]+/)", r'\2\1', path)
+ elif self.keepRepoPath and self.branchPath == 'none':
+ # remove the second element, so what was
+ # "//depot/proj/branch/file" becomes "proj/file"
+ path = re.sub("^([^/]+/)([^/]+/)", r'\2', path)
+ elif self.branchPath:
+ sys.stderr.write("branchPath without keepRepoPath?")
+ sys.exit(1)
+
return path
def splitFilesIntoBranches(self, commit):
@@ -940,7 +958,6 @@ class P4Sync(Command):
relPath = self.stripRepoPath(path, self.depotPaths)
for branch in self.knownBranches.keys():
-
# add a trailing slash so that a commit into qt/4.2foo doesn't end up in qt/4.2
if relPath.startswith(branch + "/"):
if branch not in branches:
@@ -1283,12 +1300,24 @@ class P4Sync(Command):
if self.keepRepoPath:
option_keys['keepRepoPath'] = 1
+ # since we're just saving the dict keys, append the branchPath
+ # option to the key
+ if self.branchPath:
+ option_keys['branchPath_%s' % self.branchPath] = 1
+
d["options"] = ' '.join(sorted(option_keys.keys()))
def readOptions(self, d):
self.keepRepoPath = (d.has_key('options')
and ('keepRepoPath' in d['options']))
+ # restore the branchpath option; is one of "none" and "first"
+ if (d.has_key('options')):
+ if ('branchPath_none' in d['options']):
+ self.branchPath = 'none'
+ elif ('branchPath_first' in d['options']):
+ self.branchPath = 'first'
+
def gitRefForBranch(self, branch):
if branch == "main":
return self.refPrefix + "master"
@@ -1775,6 +1804,10 @@ class P4Clone(P4Sync):
sys.stderr.write("Must specify destination for --keep-path\n")
sys.exit(1)
+ if self.branchPath and not self.keepRepoPath:
+ sys.stderr.write("Must specify --keep-path for --branch-path\n")
+ sys.exit(1)
+
depotPaths = args
if not self.cloneDestination and len(depotPaths) > 1:
diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
index 49b3359..669c63c 100644
--- a/contrib/fast-import/git-p4.txt
+++ b/contrib/fast-import/git-p4.txt
@@ -191,6 +191,64 @@ git-p4.useclientspec
git config [--global] git-p4.useclientspec false
+Dealing with different repository layouts
+=========================================
+
+Perforce clients can map views of projects and branches in different
+ways which your build system may rely on. Say your code is organised
+as two projects "foo" and "moo" which have a common branch
+
+//depot/foo/branch/...
+//depot/moo/branch/...
+
+and you require both "foo" and "moo" projects in your git repository,
+there are several options.
+
+Firstly, you could simply clone each project as a completely separate
+git tree. However, if the two projects are dependent on each other
+this can be annoying for both sync -- you must remember to sync both
+"foo" and "moo" to keep everything consistent -- and submit -- a
+change that should logically be a single changeset across "foo" and
+"moo" will have to be broken up (breaking bisection too).
+
+Another option is to simply specify multiple depots
+
+ git p4 sync //depot/foo/branch //depot/moo/branch
+
+which will import "foo" and "moo" into the same directory.
+
+To keep the projects separate, the --keep-path option used as
+
+ git p4 sync --keep-path --destination /tmp/boo/ //depot/foo/branch //depot/moo/branch
+
+will create a layout of
+
+ /tmp/boo/foo/branch/...
+ /tmp/boo/moo/branch/...
+
+However, some build systems may rely on p4's ability to specify
+destinations for views in your client. The --branch-path flag, which
+requires the --keep-path flag, allows two additional layout options.
+
+ git p4 sync --keep-path --destination /tmp/boo --branch-path=none //depot/foo/branch //depot/moo/branch
+
+will remove the branch name entirely, leaving you with a directory
+that looks like
+
+ /tmp/boo/foo/...
+ /tmp/boo/moo/...
+
+and
+
+ git p4 sync --keep-path --destination /tmp/boo --branch-path=first //depot/foo/branch //depot/moo/branch
+
+will give you each of the projects under a directory named for their
+common branch
+
+ /tmp/boo/branch/foo/...
+ /tmp/boo/branch/moo/...
+
+
Implementation Details...
=========================
--
1.7.2.3
^ permalink raw reply related
* big files in git was: Re: Features from GitSurvey 2010
From: david @ 2011-02-01 22:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <201102011451.17456.jnareb@gmail.com>
On Tue, 1 Feb 2011, Jakub Narebski wrote:
> On Sun, 30 Jan 2011, Jonathan Nieder wrote:
>> Hi Dmitry,
>>
>> Dmitry S. Kravtsov wrote:
>>
>>> I want to dedicate my coursework at University to implementation of
>>> some useful git feature. So I'm interesting in some kind of list of
>>> development status of these features
>> [...]
>>> Or I'll be glad to know what features are now 'free' and what are
>>> currently in active development.
>>
>> Interesting question. The short answer is that they are all "free".
>> Generally people seem to be happy to learn of an alternative approach
>> to what they have been working on.
>>
>> [For the following pointers, the easiest way to follow up is probably
>> to search the mailing list archives.]
>>
>>> better support for big files (large media)
>>
>> For a conservative approach, you might want to get in touch with Sam
>> Hocevar, Nicolas Pitre, and Miklos Vajna. The idea is to stream big
>> files directly to pack and not waste time trying to compress them.
>
> There is also, supposedly stalled, git-bigfiles project.
why is the clean/smudge approach that came through the list a week or two
ago not acceptable?
While people talked about how it would be nice to store the large files on
$remote_destination, just create a .git/bigfiles and store them in there.
with the ability to pass the filename to the clean/smudge scripts, you can
even avoid the copy (replacing it with a mv) and have a working, if
bare-bones system.
Then people can create/submit enhanced versions of these scripts that
store the large files elsewhere if they want, but we would be past the
"git can't handle large files" into "git handles large files less
efficiently", which is a much better place to be.
If nobody else has time to take those e-mails and create a set of
clean/smudge scripts, I'll do so later this week (unless there is some
reason why they wouldn't be acceptable)
I guess the only question is how to tell what files need to be handled
this way, but can't we have something in .gitattributes about the file
size? (and if that's a problem for checking files out, have the stored
file be a sparse file, that way it's large, but doesn't take much space on
sane filesystems)
David Lang
^ permalink raw reply
* Re: moving to a git-backed wiki
From: J.H. @ 2011-02-01 22:48 UTC (permalink / raw)
To: Jay Soffian; +Cc: Jeff King, Scott Chacon, Junio C Hamano, git
In-Reply-To: <AANLkTikfzzELUaN3B+20rh9D51St8mUYs4p-WYjp8JVV@mail.gmail.com>
On 02/01/2011 02:36 PM, Jay Soffian wrote:
> On Tue, Feb 1, 2011 at 3:11 PM, Jeff King <peff@peff.net> wrote:
>> https://github.com/peff/foo/wiki
>
> A git-backed git wiki would be great. As a related matter, the hosting
> infrastructure for https://git.wiki.kernel.org/index.php/Main_Page
> seems overloaded. About half the time I try to access it, it's either
> down completely or very slow to respond. If the wiki were git-backed I
> could get to it even if the central site were down. :-)
The wiki will almost universally have a "central site" no matter what
the backend. Personally I see little advantage to having a git backed
wiki myself.
Speaking to the slowness, it's caused by at least 2 different kernel
related bugs on the two boxes that run the wikis that I haven't had
enough time to track down to nail to specific developers to fix. I have
20u of equipment sitting in my apartment that is heading to Portland in
the next two weeks to eliminate the bits I'm pretty sure are the root
cause of the problems.
Trust me when I say it's not only been a thorn in my side, and something
I've been rather angry at several people about, but it's something that
has kept me up at night trying to get fixed.
> That said, didn't the wiki just migrate to Mediawiki recently?
It did.
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Thomas Rast @ 2011-02-01 22:39 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Junio C Hamano, git
In-Reply-To: <4D4875B2.4070008@gmail.com>
A Large Angry SCM wrote:
> On 01/31/2011 04:44 PM, Thomas Rast wrote:
> >
> > Since the remote branches in some sense reflect the "last known state"
> > of the remote, it would make sense to also update them to whatever a
> > two-argument fetch got.
>
> If this is proposing to break:
>
> get-fetch ${REPO} ${SRC_REF}:${DST_REF}
>
> then I am against this since that form _is_ used and *is* plumbing.
You're mixing up the two proposals. This one is to teach
git fetch repo foo
to update refs/remotes/repo/foo with the new value (maybe we should
also have it update in the foo:bar case, but I haven't thought that
through).
The other one is to forbid 'git pull repo foo:bar' and would not
change git-fetch at all.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: moving to a git-backed wiki
From: Jay Soffian @ 2011-02-01 22:36 UTC (permalink / raw)
To: Jeff King; +Cc: Scott Chacon, Junio C Hamano, git
In-Reply-To: <20110201201144.GA16003@sigill.intra.peff.net>
On Tue, Feb 1, 2011 at 3:11 PM, Jeff King <peff@peff.net> wrote:
> https://github.com/peff/foo/wiki
A git-backed git wiki would be great. As a related matter, the hosting
infrastructure for https://git.wiki.kernel.org/index.php/Main_Page
seems overloaded. About half the time I try to access it, it's either
down completely or very slow to respond. If the wiki were git-backed I
could get to it even if the central site were down. :-)
That said, didn't the wiki just migrate to Mediawiki recently?
j.
^ permalink raw reply
* Re: [1.8.0] Remove deprecated commands
From: Junio C Hamano @ 2011-02-01 22:16 UTC (permalink / raw)
To: René Scharfe; +Cc: git
In-Reply-To: <4D4852EE.6080605@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> The following four commands have been marked as deprecated in
> command-list.txt for quite some time[*]:
>
> command deprecated since replaced by
> ---------------- ---------------- ---------------------
> git-lost-found 2007-11-08 git fsck --lost-found
> git-peek-remote 2007-11-24 git ls-remote
> git-repo-config 2008-01-17 git config
> git-tar-tree 2007-11-08 git archive
>
> Let's just remove them. There's a risk that someone is still using the
> old commands, of course, but they have been deprecated long enough now.
Sounds fine.
^ permalink raw reply
* Re: [1.8.0] split largest remaining scripts, gitk and gitweb
From: Junio C Hamano @ 2011-02-01 22:15 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <m38vxzaa03.fsf_-_@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Two largest files in git repository are gitk and gitweb, see the
> ...
> What do you think?
What does this have to do anything with 1.8.0? Isn't this all internal
implementation that can be brought in without affecting end users?
^ permalink raw reply
* Re: [1.8.0] make two-argument fetch update remote branches
From: Junio C Hamano @ 2011-02-01 22:09 UTC (permalink / raw)
To: Jay Soffian; +Cc: Thomas Rast, git
In-Reply-To: <AANLkTi=Y9PBs_jXyCiAL9YLA8Y_jzWwqxw63hKm7fVBO@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Would it make sense to group the pre-1.8 compatibility switches
> together in some way, if there will be several of them? Maybe
>
> [compat]
> fetchUpdateRemoteNamespace = false
> ...
I don't think so.
If these configuration variables are expected to be removed in some
future, such a layout might make sense, but what is proposed is to default
them to a different behaviour from today at 1.8.0 boundary, and we are not
going to remove the ability to invoke the current behaviour with these
variables. It would make it a lot easier to find and understand if the
variables are grouped by functionality like all the other regular
variables, as these new ones are after all regular ones.
Just thinking aloud, too.
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Junio C Hamano @ 2011-02-01 21:53 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Pitre, git
In-Reply-To: <20110201014807.GA2722@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Jan 31, 2011 at 07:29:54PM -0500, Nicolas Pitre wrote:
>
>> > Yes, we do suck at rename following. The problem is that it is partially
>> [...]
>> This is no excuse not to do proper source tree reorganization.
>
> I think this is the crux of our disagreement. I don't agree that your
> proposal is any way more "proper" than what is there now. Leaving the
> rename issue aside (i.e., if we were starting a new project), I would
> still be slightly against a src/ directory. I find them annoying.
>
> But I don't care _that_ much, and I would rather not waste either of our
> time debating it more. I would much rather you spend your time on
> pack v4. :)
I am with you, both counts on this topic. I don't necessarily agree that
having sources at the top-level is bad, I don't want to see Nico wasting
his time arguing, and I do see some value in the proposal that gives us an
opportunity for dogfooding (but we already have done so with builtin/ and
it was not all that annoying---I think the timing was rather good and the
tree was semi-quiescent).
Ehh, that makes it not "both" but "two and half" counts ;-).
As long as the new directories are named sanely (one of the things I
detest is abbreviated uppercase silliness like "Src", "Lib"), I am fine
with the proposal. Also I have a mild preference to keep build-products
next to the source (i.e. no separate "obj" directory).
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-01 21:51 UTC (permalink / raw)
To: Shawn Pearce
Cc: Nguyen Thai Ngoc Duy, Jakub Narebski, Jonathan Nieder,
Dmitry S. Kravtsov, git
In-Reply-To: <AANLkTi=KUpYJBRMp9ti0h+g6a0iTw4D113rTgfTpR8C4@mail.gmail.com>
On Tue, 1 Feb 2011, Shawn Pearce wrote:
> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > Narrow/Subtree clone is still just an idea, but can pack cache support
> > be made to resumable initial narrow clone too?
>
> This would be very hard to do. We could do cached packs for a popular
> set of path specifications (e.g. Documentation/ if documentation only
> editing is common), but once we start getting random requests for path
> specifications that we cannot predict in advance and pre-pack we'd
> have to fall back to the normal enumerate code path.
Also... people interested in Narrow clones are likely to be shallow
clone users too, right?
Nicolas
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-01 21:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Shawn Pearce, Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov,
git, Junio C Hamano
In-Reply-To: <AANLkTi=oTL2_ObcyKRb7bf7ZMPZoa1BU7uNH5pJRQtVC@mail.gmail.com>
On Wed, 2 Feb 2011, Nguyen Thai Ngoc Duy wrote:
> - push support for shallow clone (Elijah approach does not base on
> shallow clone, so it's non-issue)
Push support from a shallow clone should be really simple. Either you
can update the remote, or you can't. If your local history does include
the remote branch head you wish to update then there is nothing
currently that would prevent the push from proceeding as implemented
today. If the remote head is outside the history subset you have
locally then the push simply cannot proceed.
Nicolas
^ permalink raw reply
* [1.8.0] Handle submodule config options consistently in diff plumbing
From: Jens Lehmann @ 2011-02-01 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vwrll57ha.fsf@alter.siamese.dyndns.org>
Proposal:
Handle the submodule options "diff.ignoreSubmodules" and
"submodule.<name>.ignore" consistently in diff plumbing.
I see two basic ways to change the behavior of the plumbing diff
commands:
a) Let them use the "diff.ignoreSubmodules" configuration too.
b) Don't let them use the "submodule.<name>.ignore" entries either.
But if we go that way, we might have to revert the default of
recursing into populated submodules too, as it might cause
unexpected behavior when all configuration options introduced
to control that recursion are just ignored unless explicitly
told otherwise.
History:
When the submodule recursion for the diff commands was introduced,
all diff commands - including plumbing - learned to recurse into
submodules by default. This was done to mark submodules with
uncommitted changes as dirty so no user could accidentally forget
to commit his changes there before pushing in the superproject.
Some time after that "--ignore-submodules" learned some values to
achieve more control over what conditions mark a submodule dirty.
Then the "submodule.<name>.ignore" option was added to .git/config
and the .gitmodules file to to be able to specify these values for
one or more submodules. In a later commit the "diff.ignoreSubmodules"
option was added, but the plumbing diff commands weren't taught to
use that config option.
Risks:
a) Those scripts which depend on the plumbing commands to ignore
the setting from "diff.ignoreSubmodules" will break.
b) All scripts written or changed since 1.7.0 which depend on the
current behavior to recurse into submodules and use the
"submodule.<name>.ignore" entries will be broken.
Me thinks the risks are much smaller when doing a), as people who
learned to use the recursive behavior since 1.7.0 will see that
changed under their feet when we do b) and I expect much more code
to rely on the recursion than on the "diff.ignoreSubmodules"
setting. And doing a) would fix a real life problem too, see [1].
Migration plan:
a) During the 1.7.x series a new "noconfig" value is added for the
"--ignore-submodules" command line option for people who don't
want user configuration to interfere with the recursion, e.g. in
scripts (turning off the recursion is already implemented, just
use the "--ignore-submodules" option). And then starting with
1.8.0 "diff.ignoreSubmodules" will be used by diff plumbing.
b) During the 1.7.x series a new value for "--ignore-submodules"
called "porcelain" is added which enables recursion and also
tells diff plumbing use all configuration settings. Then all
relevant call sites (like git gui, gitk and PS1 from completion
and others) are changed to use this option. Changing the default
behavior to ignore "submodule.<name>.ignore" and to not recurse
anymore will be done in the 1.8.0 release.
Personally I'm in favor of solution a), but lets hear what other
people say.
[1] http://thread.gmane.org/gmane.comp.version-control.git/164166/focus=164172
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Nicolas Pitre @ 2011-02-01 21:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Jonathan Nieder, Dmitry S. Kravtsov, git
In-Reply-To: <201102011451.17456.jnareb@gmail.com>
On Tue, 1 Feb 2011, Jakub Narebski wrote:
> On Sun, 30 Jan 2011, Jonathan Nieder wrote:
> > Dmitry S. Kravtsov wrote:
> >
> > > resumable clone/fetch (and other remote operations)
> >
> > Jakub Narebski seems to be interested in this and Nicolas Pitre has
> > given some good advice about it. You can get something usable today
> > by putting up a git bundle for download over HTTP or rsync, so it is
> > possible that this just involves some UI (porcelain) and documentation
> > work to become standard practice.
>
> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;
> I was only interested party posting comments, but no code.
No, I'm not working on that. I provided suggestions on how to go about
it in the past:
1) The git-archive based solution:
http://article.gmane.org/gmane.comp.version-control.git/126431
Relatively simple to implement, with questionable efficiency if you
care about the full history, but perfectly suited for shallow clones
which is what people with flaky connections should aim for anyway.
2) The bundle based solution:
http://article.gmane.org/gmane.comp.version-control.git/164699
(see towards the end of the message)
This was about BitTorrent distribution, but any resumable transport
can be applied to the bundle.
Extremely simple to implement, as this all can be scripted on top of
existing tools. Good for the bulk of history, but there is always a
risk for problems during the update of the repository from the
bundle's state up to the most recent commits which has to fall back
to the non resumable smart Git protocol.
There is also some possibility that the cache pack work might be
leveraged to provide a resumable clone solution similar to #2 above, but
that would of course share the same flaws.
> Again, this feature is not very easy to implement, and would require
> knowledge of git internals including "smart" git transport ("Pro Git"
> book can help there).
The two proposed solutions above require no prior knowledge of the smart
Git protocol, and they should be pretty simple to implement. Certainly
in the reach of a GSOC student.
> > > GitTorrent Protocol, or git-mirror
> >
> > Sam Vilain and Jonas Fonseca did some good work on this, but it's
> > stalled.
>
> There was some recent discussion on this on git mailing llist, but
> without any code.
>
> One would need to know similar areas as for "resumable clone" feature.
> Plus some knowledge on P2P transport in GitTorrent case.
Again, please see
http://article.gmane.org/gmane.comp.version-control.git/164699
This is simple, and with guaranteed results. Why no one was interested
in implementing that yet I don't know.
Nicolas
^ permalink raw reply
* Re: [PATCH 3/3] vcs-svn: Refactor dump_export code into dispatch table
From: Junio C Hamano @ 2011-02-01 21:29 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Ramkumar Ramachandra, Git List, David Barr, Sverre Rabbelier
In-Reply-To: <20110201174241.GB3771@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Heh. I think that Junio was suggesting making the _parser_
> table-driven, meaning something like
>
> ... node_kinds[] = {
> { "100644", sizeof("100644"), "file" },
> ...
> };
Yes, and thanks.
^ permalink raw reply
* Re: [PATCH] t5526: Fix wrong argument order in "git config"
From: Junio C Hamano @ 2011-02-01 21:28 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Git Mailing List, Libor Pechacek
In-Reply-To: <4D46E88D.1020806@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> This fixes a typo where the "git config" arguments "-f" and "--unset" were
> swapped leading to the creation of a "--unset" file.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> Now that 1.7.4 is out and somebody else already stumbled across this
> typo I introduced ...
Thanks.
>
> t/t5526-fetch-submodules.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/t/t5526-fetch-submodules.sh b/t/t5526-fetch-submodules.sh
> index 884a5e5..a5f4585 100755
> --- a/t/t5526-fetch-submodules.sh
> +++ b/t/t5526-fetch-submodules.sh
> @@ -124,7 +124,7 @@ test_expect_success "--recurse-submodules overrides fetchRecurseSubmodules setti
> (
> cd downstream &&
> git fetch --recurse-submodules >../actual.out 2>../actual.err &&
> - git config -f --unset .gitmodules submodule.submodule.fetchRecurseSubmodules true &&
> + git config --unset -f .gitmodules submodule.submodule.fetchRecurseSubmodules &&
> git config --unset submodule.submodule.fetchRecurseSubmodules
> ) &&
> test_cmp expect.out actual.out &&
> --
> 1.7.3.4.27.g3921d.dirty
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Junio C Hamano @ 2011-02-01 21:28 UTC (permalink / raw)
To: René Scharfe; +Cc: Junio C Hamano, Francis Moreau, git, Johannes Sixt
In-Reply-To: <4D4477E4.6020006@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Subject: revision: let --full-history keep half-interesting merges
>
> Don't simplify merges away that have at least one parent with changes in
> the interesting subset of files if --full-history has been specified.
> The previous behaviour hid merges with one uninteresting parent, which
> could lead to history that removed code to become undetectable.
I think this patch makes a lot more sense than what I've seen in this
thread (including mine).
> E.g., this command run against the Linux kernel repo only found one
> merge that brought the specified function in (and the regular commit
> which added it in the first place), but missed the 92 merges that
> removed it, as well as 67 other merges that added it back:
>
> $ git log -m --full-history -Sblacklist_iommu \
> v2.6.26..v2.6.29 -- drivers/pci/intel-iommu.c
>
> Reported-by: Francis Moreau <francis.moro@gmail.com>
> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Thanks.
> ---
> revision.c | 2 ++
> t/t6016-rev-list-graph-simplify-history.sh | 1 +
> 2 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/revision.c b/revision.c
> index 7b9eaef..84c231b 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -434,6 +434,8 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
> case REV_TREE_OLD:
> case REV_TREE_DIFFERENT:
> tree_changed = 1;
> + if (!revs->simplify_history)
> + return;
> pp = &parent->next;
> continue;
> }
> diff --git a/t/t6016-rev-list-graph-simplify-history.sh b/t/t6016-rev-list-graph-simplify-history.sh
> index f7181d1..50ffcf4 100755
> --- a/t/t6016-rev-list-graph-simplify-history.sh
> +++ b/t/t6016-rev-list-graph-simplify-history.sh
> @@ -168,6 +168,7 @@ test_expect_success '--graph --full-history --simplify-merges -- bar.txt' '
> echo "|\\ " >> expected &&
> echo "| * $C4" >> expected &&
> echo "* | $A5" >> expected &&
> + echo "* | $A4" >> expected &&
> echo "* | $A3" >> expected &&
> echo "|/ " >> expected &&
> echo "* $A2" >> expected &&
> --
> 1.7.3.4
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Junio C Hamano @ 2011-02-01 21:27 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Shawn Pearce, Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov,
git
In-Reply-To: <AANLkTi=oTL2_ObcyKRb7bf7ZMPZoa1BU7uNH5pJRQtVC@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:
> ...
>> I think Junio has already started thinking about this one.
>
> I need to get nd/pathspec right and implement negative pathspecs
> before returning to this feature.
I don't think we need negative pathspecs before going forward.
I wanted a unified "We have a path; is it inside this set of pathspecs?"
(and its sibling, "We have a leading path and a name_entry taken from that
tree; is it inside this set of pathspecs?"), and with that we can run:
$ git clone git://k.org/pub/scm/git/git.git -- Documentation '*.sh'
that would limit the clone (not just checkout) to the given parts of the
tree. By recording the pathspecs in the repository (and initially making
it frozen---we can design extending the scope in later rounds), we can
limit "fsck", "unpack-trees", "log", etc. all using the unified pathspec
API.
We may later want to add negative or imaginary pathspecs to the mix, but
as long as the unified pathspec API understands that, the narrow-clone
part should be able to be unaware of that.
So I think that is (or at least _should be_ if the pathspec API is done
right) pretty much orthogonal.
^ permalink raw reply
* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Jay Soffian @ 2011-02-01 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7hdj1mo7.fsf@alter.siamese.dyndns.org>
On Tue, Feb 1, 2011 at 4:15 PM, Junio C Hamano <gitster@pobox.com> wrote:
> IOW, I don't think
>
>> (master)$ git branch --set-upstream origin/master
>> Branch origin/master set up to track local branch master.
>
> is a sane behaviour from day one, and is simply a bug. Changing this
> behaviour would merely be a bugfix, not a flag-day event that changes an
> established behaviour.
Okay, our emails criss-crossed. I agree with that, but my other email
proposes adding -u <name> with correct behavior and just deprecating
--set-upstream. I suppose we could instead (or in addition) just fix
--set-upstream.
I guess please reply to the other email so we don't keep criss-crossing. :-)
j.
^ permalink raw reply
* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Junio C Hamano @ 2011-02-01 21:15 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <AANLkTinUn2SMijphe3EmPMVOOwBjPB5ffFwwqZVxQmW0@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Proposal:
>
> Currently it is very easy to misinvoke --set-upstream if you assume it
> takes an argument:
>
> e.g.
>
> (master)$ git branch --set-upstream origin/master
> Branch origin/master set up to track local branch master.
With "git branch <name>" (or for that matter "git branch -d <name>"), we
are manipulating some attribute of the branch <name> (namely, "what does
it point at", "does it exist?") not of the current branch. So it is
natural to expect that some attribute of the named branch origin/master is
being changed.
> In order to make its usage unambiguous, and to allow it to be used w/o
> specifying the current branch, require it to take an argument like so:
>
> (master)$ git branch --set-upstream=origin/master
Even though I think I understand the issue you are trying to tackle, I
think your proposal seems to make things worse. In either "--set-upstream
A" or "--set-upstream=A", it is unclear if you are manipulating "what
other branch does this follow" attribute of A or the current branch.
I think it was a misdesign to allow --set-upstream without argument to
default to the current branch. Wouldn't it be simpler to just fix the
parser so that "--set-upstream A" and "--set-upstream=A" both mean the
same thing? The branch whose attribute is manipulated defaults to the
current one in either case.
IOW, I don't think
> (master)$ git branch --set-upstream origin/master
> Branch origin/master set up to track local branch master.
is a sane behaviour from day one, and is simply a bug. Changing this
behaviour would merely be a bugfix, not a flag-day event that changes an
established behaviour.
But that may be just me. I don't use --set-upstream myself, and people
may have learned to be comfortable with the current behaviour.
If there are people who want to keep the current behaviour, please
speak up. Then we can introduce the usual migration procedure to
first add a configuration to flip the behaviour (default off),
then warn if you use 0-argument --set-upstream to default to the
current branch without setting the configuration, and eventually
flip the default to always require argument to --set-upstream.
> (I've misinvoked it so often, I've had to train myself to always
> invoke it this way: git branch master --set-upstream origin/master)
If "git branch master --set-upstream origin/master" is accepted, we have
another bug in its parser to fix. The canonical command line should
always be dashed-options, then refs and then pathspecs.
^ permalink raw reply
* Re: [1.8.0] Change branch --set-uptream to take an argument
From: Jay Soffian @ 2011-02-01 21:14 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqzkqg5dsq.fsf@bauges.imag.fr>
On Tue, Feb 1, 2011 at 4:01 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> Currently it is very easy to misinvoke --set-upstream if you assume it
>> takes an argument:
>
> Your proposal sounds interesting, but I'd like to see something more
> global: right now, some commands take a --track option and other take
> a --set-upstream. In short, I'd like to see this --track deprecated
> (since it's not actually about remote-tracking ...).
There are a few things at work here. --track/--no-track are used to
override the branch.autosetupmerge configuration and are supported by
checkout and branch. --set-upstream is only supported by branch, and
is subtly different from --track.
There is also branch.autosetuprebase, for which there is no
command-line option to override.
These options/configs control how branch.<name>.{merge,remote,rebase}
are set. --track/--no-track only take effect when the branch is
created. --set-upstream can be used when the branch is created, or
after the fact.
(Aside, the names of the config params are starting to look
sub-optimal, but it's probably not worth the pain of changing them.)
I suppose a more comprehensive proposal looks like this:
1. Deprecate --track and --no-track (remove from documentation and
usage). I wonder if anyone ever uses them?
2. Deprecate --set-upstream as its usage is confusing.
3. Add -u <name> to both checkout and branch to specify the upstream
branch. It is used with checkout -b in cases where an upstream would
not normally be configured, either because it's not the default
according to branch.autosetupmerge or because the start-point is not a
branch. It is used with branch when creating a branch in a similar
manner to how it's used with checkout when creating a branch, but may
also be used to reset the upstream after the fact like so:
$ git branch -u <upstream> [<branch>]
4. Add --pull-default={rebase,merge} to both checkout and branch used
for setting/unsetting branch.<name>.rebase during initial branch
creation, or after the fact in the case of git-branch. It is an error
to try to set --pull-default if the upstream is not configured, either
automatically or via -u.
>> (Though I'm not sure whether the options parser allows for both
>> --set-upstream and --set-upstream=<arg>)
>
> There are already many instances of this. When <arg> is mandatory, you
> can write either --option <arg> or --option=<arg> (like "git log
> --grep pattern" Vs "git log --grep=pattern"), and when <arg> is
> optional, you can write either --option alone, or --option=<arg> (like
> "git diff --color-words" and "git diff --color-words=.").
Sorry. What I meant was that you'd need the ability to differentiate
between "--set-upstream=foo" and "--set-upstream foo" due to
git-branch's existing semantics. Right now:
$ git branch --set-upstream topic origin/master
Creates topic from origin/master and sets topic's upstream to
origin/master. If --set-upstream suddenly starts taking an argument,
that means something completely different: create a new branch named
origin/master starting at HEAD and set its upstream to "topic".
I think we're better off just deprecating --set-upstream and
introducing the more convenient -u.
j.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox