* Re: [PATCH] cache-tree: do not cache empty trees
From: Jonathan Nieder @ 2011-02-05 10:14 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, Ilari Liusvaara, Jakub Narebski, Dmitry S. Kravtsov,
Shawn Pearce
In-Reply-To: <1296899427-1394-1-git-send-email-pclouds@gmail.com>
Hi,
Some quick nits to save myself time. The basic idea of the patch
seems sound.
Nguyễn Thái Ngọc Duy wrote:
> --- /dev/null
> +++ b/t/t1013-read-tree-empty.sh
> @@ -0,0 +1,38 @@
> +#!/bin/sh
> +
> +test_description='read-tree with empty trees'
> +
> +. ./test-lib.sh
> +
> +T1=f4ec99e8174c01eab488469b4c2680500bbb18da
> +T2=4b825dc642cb6eb9a060e54bf8d69288fbee4904
What are these trees? Do they need to be hardcoded?
> +
> +test_expect_success 'setup' '
> + printf "40000 empty\0\x4b\x82\x5d\xc6\x42\xcb\x6e\xb9\xa0\x60\xe5\x4b\xf8\xd6\x92\x88\xfb\xee\x49\x04" >newtree &&
printf '\xab' is unfortunately unportable. I suppose
this should rather say something like
test_unequal () {
printf '%s\n' "$1" >bad &&
printf '%s\n' "$2" >actual &&
! test_cmp bad actual
}
empty_tree=$(git mktree </dev/null) &&
tree_with_empty_subtree=$(
echo "040000 tree $empty_tree empty" |
git mktree
) &&
test_unequal "$empty_tree" "$tree_with_empty_subtree"
> +test_expect_success 'ls-tree T1 (with empty tree)' '
> + git ls-tree $T1 >actual &&
> + cat <<EOF >expected &&
> +040000 tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 empty
> +EOF
> + test_cmp expected actual
> +'
echo "040000 tree $empty_tree empty" >expect &&
git ls-tree "$tree_with_empty_subtree" >actual &&
test_cmp expect actual
> +
> +test_expect_success 'write-tree removes empty tree' '
> + git read-tree "$T1" &&
> + git write-tree >actual
> + echo $T2 >expected
> + test_cmp expected actual
> +'
git read-tree "$tree_with_empty_subtree" &&
...
Sane?
Jonathan
^ permalink raw reply
* Re: [PATCH] Add support for merging from upstream by default.
From: Andreas Schwab @ 2011-02-05 10:03 UTC (permalink / raw)
To: Jared Hance; +Cc: git
In-Reply-To: <1296866721-27818-1-git-send-email-jaredhance@gmail.com>
Jared Hance <jaredhance@gmail.com> writes:
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 42fff38..a69b69f 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -37,6 +37,7 @@ struct strategy {
> };
>
> static const char * const builtin_merge_usage[] = {
> + "git merge",
Doesn't that form take options as well?
> "git merge [options] <remote>...",
IOW, how about changing that to
"git merge [options] [<remote>...]",
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH] cache-tree: do not cache empty trees
From: Nguyễn Thái Ngọc Duy @ 2011-02-05 9:50 UTC (permalink / raw)
To: git, Ilari Liusvaara
Cc: Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov, Shawn Pearce,
Nguyễn Thái Ngọc Duy
In-Reply-To: <1296894611-29398-1-git-send-email-pclouds@gmail.com>
Current index does not support empty trees. But users can construct
empty trees directly using plumbing. When empty trees are checked out,
things become inconsistent:
- If cache-tree somehow is invalidated, when a tree is read to index,
empty trees disappear. When we write trees back, empty trees will
be gone.
- If cache-tree is generated by read-tree and remains valid by the
time trees are written back, empty trees remain.
Let's do it in a consistent way, always disregard empty trees in
index. If users choose to create empty trees their own way, they
should not use index at all.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Scratch the first version. This one actually works.
cache-tree.c | 9 +++++++++
t/t1013-read-tree-empty.sh | 38 ++++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t1013-read-tree-empty.sh
diff --git a/cache-tree.c b/cache-tree.c
index f755590..03732ad 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -621,9 +621,18 @@ static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
struct tree *subtree = lookup_tree(entry.sha1);
if (!subtree->object.parsed)
parse_tree(subtree);
+ if (!hashcmp(entry.sha1, (unsigned char *)EMPTY_TREE_SHA1_BIN)) {
+ warning("empty tree detected! Will be removed from new commits");
+ cnt = -1;
+ break;
+ }
sub = cache_tree_sub(it, entry.path);
sub->cache_tree = cache_tree();
prime_cache_tree_rec(sub->cache_tree, subtree);
+ if (sub->cache_tree->entry_count == -1) {
+ cnt = -1;
+ break;
+ }
cnt += sub->cache_tree->entry_count;
}
}
diff --git a/t/t1013-read-tree-empty.sh b/t/t1013-read-tree-empty.sh
new file mode 100755
index 0000000..a9279f0
--- /dev/null
+++ b/t/t1013-read-tree-empty.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='read-tree with empty trees'
+
+. ./test-lib.sh
+
+T1=f4ec99e8174c01eab488469b4c2680500bbb18da
+T2=4b825dc642cb6eb9a060e54bf8d69288fbee4904
+
+test_expect_success 'setup' '
+ printf "40000 empty\0\x4b\x82\x5d\xc6\x42\xcb\x6e\xb9\xa0\x60\xe5\x4b\xf8\xd6\x92\x88\xfb\xee\x49\x04" >newtree &&
+ git hash-object -w -t tree newtree >actual &&
+ echo $T1 >expected
+ test_cmp expected actual
+'
+
+test_expect_success 'ls-tree T1 (with empty tree)' '
+ git ls-tree $T1 >actual &&
+ cat <<EOF >expected &&
+040000 tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904 empty
+EOF
+ test_cmp expected actual
+'
+
+test_expect_success 'write-tree removes empty tree' '
+ git read-tree "$T1" &&
+ git write-tree >actual
+ echo $T2 >expected
+ test_cmp expected actual
+'
+
+test_expect_success 'ls-tree T2 (without empty tree)' '
+ git ls-tree $T2 >actual &&
+ : >expected &&
+ test_cmp expected actual
+'
+
+test_done
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* Apply Patch giving warnings in windows
From: ashish.mittal @ 2011-02-05 8:44 UTC (permalink / raw)
To: git
Hello members,
I created a patch on ubuntu using 'git format-patch -1' for my last commit.
When I did 'git apply --check patch_name', I got 'warning: file_name of type
100644, expected 100755'. The execution bit of the files was set. I set the
filemode in config to true using 'git config core.filemode true'. The git
apply --check was giving no more warnings. But I get same warnings on
Windows even after setting the filemode to true and false both. Can anyone
guide me regarding this?
Thanks,
Ashish Mittal
--
View this message in context: http://git.661346.n2.nabble.com/Apply-Patch-giving-warnings-in-windows-tp5995091p5995091.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* [PATCH] cache-tree: do not cache empty trees
From: Nguyễn Thái Ngọc Duy @ 2011-02-05 8:30 UTC (permalink / raw)
To: git, Ilari Liusvaara
Cc: Jakub Narebski, Jonathan Nieder, Dmitry S. Kravtsov, Shawn Pearce,
Nguyễn Thái Ngọc Duy
Current index does not support empty trees. But users can construct
empty trees directly using plumbing. When empty trees are checked out,
things become inconsistent:
- If cache-tree somehow is invalidated, when a tree is read to index,
empty trees disappear. When we write trees back, empty trees will
be gone.
- If cache-tree is generated by read-tree and remains valid by the
time trees are written back, empty trees remain.
Let's do it in a consistent way, always disregard empty trees in
index. If users choose to create empty trees their own way, they
should not use index at all.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
On Wed, Feb 2, 2011 at 2:09 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> Yes, writing to index/working area. IIRC, having such entry in tree causes
> a "ghost directory". I don't exactly recall what such thing broke, but I
> remember that it broke something (merging?)...
>
> Those ghosts also had annoying tendency to persist between commits. Commits
> didn't kill them. Rm didn't work. You had to create something on top/inside to
> get rid of them.
That's probably because of cache-tree. Empty trees can't exist in
index so an operation "trees -> index -> trees" will remove empty
trees.
But read-tree can preserve the exact structure of original trees
(including empty trees) so if that particular path is untouched,
empty trees will remain.
Perhaps a patch like this for pre-1.8.0?
cache-tree.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/cache-tree.c b/cache-tree.c
index f755590..f717793 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -621,6 +621,8 @@ static void prime_cache_tree_rec(struct cache_tree *it, struct tree *tree)
struct tree *subtree = lookup_tree(entry.sha1);
if (!subtree->object.parsed)
parse_tree(subtree);
+ if (!hashcmp(entry.sha1, (unsigned char *)EMPTY_TREE_SHA1_BIN))
+ continue;
sub = cache_tree_sub(it, entry.path);
sub->cache_tree = cache_tree();
prime_cache_tree_rec(sub->cache_tree, subtree);
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* Re: [PATCH] Add case insensitive support in matching pathspec
From: Nguyen Thai Ngoc Duy @ 2011-02-05 7:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwrlgzryj.fsf@alter.siamese.dyndns.org>
2011/2/4 Junio C Hamano <gitster@pobox.com>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> On top of nd/struct-pathspec, but requires jj/icase-directory. I can
>> rebase the series on top of master if it causes too many conflicts.
>
> I am in the middle of rewinding 'next' and have already rebased the topic;
> I will queue the result in 'pu' so could you check the result when it is
> pushed out later?
Checked. Looks good to me.
--
Duy
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Pete Harlan @ 2011-02-05 7:43 UTC (permalink / raw)
To: David Aguilar; +Cc: Jay Soffian, Jakub Narebski, git@vger.kernel.org
In-Reply-To: <4928FF12-E593-4CDB-AC68-B4078CC5920E@gmail.com>
On 02/02/2011 03:33 PM, David Aguilar wrote:
> I don't like where this is going. Users are not always right. Touch
> .gitignore and be done with it. This is a big change with
> negligible benefits. I don't understand why this is needed.
I worked for a huge company that was converting a large project to
Git. They had a wiki about the conversion. There was a section
titled "Git Gotchas" that had one entry: Git Doesn't Track Empty
Directories.
This has come up as something to be worked around in each of the
conversions to Git I've been part of.
And unlike other things Git doesn't track, such as permissions or
modification times, I can't argue that Git's behavior here is superior
to what they were expecting. I'd love to see this feature in Git if
only to make the issue go away. And I don't think it's a slippery
slope, that once this is in then they'll be clamoring for resource
forks and ACLs. Developers know some things aren't handled by SCMs,
they just don't think that includes directories.
--Pete
^ permalink raw reply
* Re: moving to a git-backed wiki
From: david @ 2011-02-05 7:00 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20110204143421.GA6449@gnu.kitenet.net>
On Fri, 4 Feb 2011, Joey Hess wrote:
> Jeff King wrote:
>> If it sounds like I'm handwaving away scalability problems, I am. I'd be
>> curious to see some performance numbers for gollum or ikiwiki versus
>> more traditional wiki formats.
>
> Ikiwiki builds static pages, this tends to mean it doesn't have
> performance, because there is little more to perform than
> httpd < file > network :)
> So I've routinely had ikiwiki sites slashdotted, and not noticed.
I think you mean it doesn't have performance _problems_ ;-)
David Lang
> Ikiwiki is not enormously fast in the rare cases when it does have to
> run as a CGI, but little of that has to do with git. About the worst
> case is that saving a page edit leads to a git commit -- if git
> decides to gc the repository right then, it could make the save stall
> for a while. There are easy ways to avoid that. (ie, git gc in cron job)
> In general, though ikiwiki as a CGI is fast enough to not be annoying --
> although it won't scale to a site the size of wikipedia.
>
> Since I'm lazy, ikiwiki does not include a history or diff viewer. It
> just points off to gitweb or a similar tool. As you say, gitweb can be
> fast enough, and really most wiki users do read their current content,
> or maybe make an edit; digging in the history is comparatively rare.
> And once users realize the wiki is in git, they can use gitk to dig in
> the history without using any server resources. :)
>
> The feature I like best with using git for a wiki (besides ease of
> branching) is that it can actually make a legitimate use of the
> woefully underused git push over git:// feature. Ikiwiki can be
> configured to check such pushes, running via the pre-receive hook. This
> allows it to limit the changes that can be pushed anonymously to changes
> that could be made using the web interface. So if you've chosen to lock
> some pages, or virus filter attachments, or whatever, in the web side of
> the wiki, that all applies to the anonymous git pushes too. Details at
> <http://ikiwiki.info/tips/untrusted_git_push/>
>
>
^ permalink raw reply
* nesting refs (Re: [1.8.0] Provide proper remote ref namespaces)
From: Nguyen Thai Ngoc Duy @ 2011-02-05 4:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johan Herland, git, Sverre Rabbelier, Jeff King, Nicolas Pitre
On Sat, Feb 5, 2011 at 5:39 AM, Junio C Hamano <gitster@pobox.com> wrote:
> While you are talking about drastic reorganization (and rewriting the ref
> code to support it), another possible Sub-proposal we may want to consider
> is to allow "next" and "next/foo" at the same time.
Oh yeah.. how about "next/.ref" and "next/foo/.ref"? Ref search code
can be modified to check both "next" and "next/.ref" when "next" is
requested. Old git basically won't work with new ref style, so there's
not much compatibility issue.
We can also add "next/.summary" to save a brief description of a ref.
But then it would be lost in packed-refs, hm..
--
Duy
^ permalink raw reply
* Re: [PATCH] Add case insensitive support in matching pathspec
From: Nguyen Thai Ngoc Duy @ 2011-02-05 4:14 UTC (permalink / raw)
To: Junio C Hamano, Joshua Jensen; +Cc: Johannes Sixt, git
In-Reply-To: <7vei7nxuw5.fsf@alter.siamese.dyndns.org>
On Sat, Feb 5, 2011 at 6:06 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>>> core.ignorecase should be honored only when files on the filesystem are
>>> matched, IMO.
>>
>> Names in index, just as same as match_pathspec().
>
> If the matched entities are names in the index, they should already be
> canonical and we shouldn't be matching with icase, no?
The patterns are case-insensitive. The example given in 21444f is "git
ls-files mydir" should also match MyDir/* in index. Although by
modifying match_one(), it affects more than just git-ls-files. I'm not
the original author, so Joshua, was that patch to fix git-ls-files
only?
--
Duy
^ permalink raw reply
* Re: [idea] separate .git dir and the working tree
From: Mike Gant @ 2011-02-05 3:23 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTik4MjnpOzPdGy7ZDiH0in4e1DpjrhQFOHjUiEEE@mail.gmail.com>
On Sat, Feb 05, 2011 at 10:53:58AM +0800, redstun wrote:
> First please shout if this is a known feature :-)
>
> I think separating the .git directory from its working tree could
> increase the safety of the data to one more level higher.
>
> We might have a git variable set to specify (a shared place) where to
> put the .git directories (or the data inside it), then use
> "/path/to/working/tree" as (or the seed to calculate) a hash key to
> map from the (.git directory in the) shared place to the working tree
> directory.
>
> Or we may have just a few data (that can be re-created) stored in the
> .git directory along with the working tree, and most of the revision
> history stored in the shared place.
GIT_DIR and GIT_WORK_TREE might be what you are looking for. Explanation
of usage in 'man git'
HTH
Mike
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Martin von Zweigbergk @ 2011-02-05 3:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.1101311459000.8580@xanadu.home>
On Mon, 31 Jan 2011, Nicolas Pitre wrote:
> 2) Create a build/ directory, or bin/ if prefered, to hold the result of
> the build.
I don't care much about the other items on the list, but I do agree
with this one. The biggest reason I like this is because it makes it
easier to tab complete. In all the cases so far that I have tab
completed "git-rebase--i" to open it in an editor or to run some git
command on it, I have wanted "git-rebase--interactive.sh"; I have
never wanted the build result.
It is also nice to have one less file to edit (.gitignore) when you
add a new source file, but that is of course much less important.
Are there any arguments against this part of Nicolas's proposal?
Btw, this is not really related to 1.8.0, is it? It seems to me like
it could be done at any time...
/Martin
^ permalink raw reply
* [idea] separate .git dir and the working tree
From: redstun @ 2011-02-05 2:53 UTC (permalink / raw)
To: git
First please shout if this is a known feature :-)
I think separating the .git directory from its working tree could
increase the safety of the data to one more level higher.
We might have a git variable set to specify (a shared place) where to
put the .git directories (or the data inside it), then use
"/path/to/working/tree" as (or the seed to calculate) a hash key to
map from the (.git directory in the) shared place to the working tree
directory.
Or we may have just a few data (that can be re-created) stored in the
.git directory along with the working tree, and most of the revision
history stored in the shared place.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-05 1:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy,
Nicolas Pitre
In-Reply-To: <7vpqr7xw4z.fsf@alter.siamese.dyndns.org>
On Friday 04 February 2011, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > - Remote heads have moved into refs/remotes/$remote/heads/*, hence
> > invalidating shorthand remote head names, like "origin/master". We
> > should change the lookup code, so that a shorthand ref of the form
> > "$remote/$head" where "$remote" happens to match a configured remote
> > is eventually expanded into lookup for
> > "refs/remotes/$remote/heads/$head" [3].
>
> Keeping 'origin/next' usable is a _must_, _if_ we were to go this route.
Of course.
> > - All fetch refspecs should be given explicitly.
>
> What do you mean by this?
Today, when you fetch from a remote, the config typically says
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ...
But this fetch refspec does not tell the full story. In addition to mapping
origin's refs/heads/* into refs/remotes/origin/*, it also fetches origin's
HEAD into refs/remotes/origin/HEAD, and anything in origin's refs/tags/*
that happen to point to a fetched object is fetched into refs/tags/* (aka.
auto-following tags). These other fetches are not explicitly specified in
the config, but "magically" happen anyway. Instead of having such implicit
refspecs, I'd rather have all fetch refspecs listed explicitly in the
config, like this (for replicating current layout):
[remote "origin"]
fetch = +HEAD:refs/remotes/origin/HEAD
fetch = +refs/heads/*:refs/remotes/origin/*
fetch = ~refs/tags/*:refs/tags/*
url = ...
or this (in the proposed new layout):
[remote "origin"]
fetch = +HEAD:refs/remotes/origin/HEAD
fetch = +refs/heads/*:refs/remotes/origin/heads*
fetch = +refs/tags/*:refs/remotes/origin/tags/*
url = ...
> > Sub-proposal: While we are changing the default refspecs, we should
> > also consider whether we want to keep the auto-following behavior that
> > Git currently does for tags (don't fetch tags that refer to objects
> > not otherwise fetched by another refspec). If we simply make an
> > explicit "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will
> > lose the auto- following behavior. If we do want to keep the
> > auto-following behavior, we could for example add a "~" prefix to the
> > refspec to trigger auto-following behavior (i.e. this refspec only
> > applies to refs that happen to point at objects fetched by way of a
> > different refspec). See
> > http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160
> > 795 for more details.
>
> You seem to envision "auto-follow" to slurp remote tags in
> remotes/origin/$tag namespace. What should "git fetch --tags $from_there"
> do?
I would propose that "git fetch --tags $from_there" follows these steps:
1. Enumerate the (implicit or explicit) fetch refspecs for the given remote.
2. Map "refs/tags/*" through the refspecs to find where the remote tags
should be stored in the local repo.
3. If the matching refspec starts with "~" (auto-following), disregard the
"~" (since --tags disables auto-following).
4. Slurp remote tags into the location found in step #2.
Since we map through the refspec, the remote tags end up where the user
expect to find them: in refs/tags/* for old-style remotes, or in
refs/remotes/$from_there/tags/* for new-style remotes.
> For some reason, many people seem to be enthused about splitting the tag
> namespace, but I am not sure if that is a good thing in general.
> Branches are moving pointers for people to flip around in their local
> repositories, and it makes sense to say "My master is a bit ahead of the
> public one", but what would we gain by making it _easier_ to add and
> exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4
> vs refs/tags/v1.7.4), other than the extra confusion?
First, I should state that making tags into moving pointers is not something
I support, nor is it part of this proposal. Tags should still very much
refuse to be moved (except when forced).
Having said that, there are real situations where users encounter collisions
in the shared tag namespace. A rare (but plausible) scenario arise when two
developers create (and publish) conflicting tags in their repos. A more
common scenario that I have encountered at $dayjob, is where two parallel
(semi-related) projects are developed in separate repos (with different
versioning because of separate release schedules), and I need to interface
with both repos from a single local repo. Each of the remote repos have
their own "v1.0" tag, but my repo can only hold one such tag. Which of those
tags end up "winning" in my local repo depends on my fetch order.
Git already has code to discover ambiguous ref names, and we have powerful
tools for inspecting the history and diffs between local and remote
branches. But because we conflate tags into a single namespace, we cannot
easily use these tools when circumstances conspire to produce conflicting
tags.
Putting remote tags into separate namespaces allows us to use the same tools
that we use on remote branches, to discover and inspect conflicting tags
when (if only rarely) they do happen.
Another advantage of splitting tags into separate namespaces is that the
"source" or "domain" of a tag becomes slightly less foggy: Consider a tag
"foo" that may exist as refs/remotes/origin/tags/foo (remote/public) and/or
as refs/tags/foo (local/private). If it exists only locally, it may be a
hint that this is a "private" tag (not intended for public consumption). If
it exists only remotely, it's obviously a public tag. If it exists both
locally and remotely (without conflict), it may indicate that this is a
public tag that was originally created in this repo.
> While you are talking about drastic reorganization (and rewriting the ref
> code to support it), another possible Sub-proposal we may want to
> consider is to allow "next" and "next/foo" at the same time.
Interesting. I haven't followed this discussion lately (if there has been
any), but I guess we need to find a new way to organize loose refs that
doesn't cause file vs. directory problems. Obviously, the packed-refs format
should have no inherent problem with these refs, but I guess we can't drop
loose ref support completely.
One sort-of-workaround could be to detect when "next" vs. "next/foo"
happens, and simply force one of them to be a packed ref.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git to p4 conversion
From: Vitor Antunes @ 2011-02-05 1:11 UTC (permalink / raw)
To: Tor Arvid Lund; +Cc: Endre Czirbesz, git, Ian Wienand
In-Reply-To: <AANLkTi=onuZtGWPTYvw_-rKsR6t-R2UquAUPLHAm-TVV@mail.gmail.com>
Hi Tor,
On Sat, Feb 5, 2011 at 12:53 AM, Tor Arvid Lund <torarvid@gmail.com> wrote:
> I... wonder if we're maybe talking past one another here...
>
> Let's take a few things from the top, just in case... If we think
> about the perforce setup (before we start doing any git stuff)... You
> have a perforce workspace/client-spec, right? That is - a setup that
> tells perforce where you want the files to be placed on your hard
> drive when you do a standard "p4 sync". Let's call it ~/p4root/ and
> let us say that your project will then be synced by perforce to
> ~/p4root/myproj/
>
> When you want to do a git-p4 clone, you should definitely be *outside*
> of ~/p4root/ . Let's say we have a ~/gitroot/ as well. So do cd
> ~/gitroot/ so that the git-p4 clone will be under ~/gitroot/myproj/ ;
> and then do all the git-p4 stuff (clone, add remote, fetch, rebase,
> sync, submit).
>
> I think Vitors point was that before you do git-p4 submit, you should
> clean - not ~/gitroot/myproj - but ~/p4root/myproj/.
>
> This is probably not something that you need to do everytime you want
> to submit back to perforce, but since we have had some rounds with
> trial-and-error with this, we have probably placed some dirty files
> inside the perforce folders... Make sure that you don't have files
> opened in perforce before you sync.
>
> Clearer? More confused? Best of luck anyway :)
>
> -- Tor Arvid
>
Yeah, I think we're in sync here. I'm almost sure your (much more
detailed) instructions will solve Endre's problem :)
Kind regards,
--
Vitor Antunes
^ permalink raw reply
* Re: git to p4 conversion
From: Tor Arvid Lund @ 2011-02-05 0:53 UTC (permalink / raw)
To: Endre Czirbesz; +Cc: Vitor Antunes, git, Ian Wienand
In-Reply-To: <AANLkTimJm81V0D8_j3OfZTcEkyn_jd6_QB2nv8T69JBY@mail.gmail.com>
On Fri, Feb 4, 2011 at 5:52 PM, Endre Czirbesz <endre@czirbesz.hu> wrote:
> Hi Vitor,
>
> 2011/2/4 Vitor Antunes <vitor.hda@gmail.com>:
>>> I dropped the whole directory, and then recreated it, I do not know
>>> any better 'cleanup'. :)
>>
>> Which directory did you drop? Was is the git repository or the P4 workspace?
>> You need to clean up the later. Basically, a "rm -rf
>> path/to/p4_workspace" and a "p4 sync -f" should do the trick :)
>
> It is almost the same in my case. :)
> My p4 client root is ~/work/, my project dir is ~/work/projdir (and at
> the moment this is the only directory within ~/work/), and I dropped
> the latter.
> And then it was created again by git-p4 clone.
I... wonder if we're maybe talking past one another here...
Let's take a few things from the top, just in case... If we think
about the perforce setup (before we start doing any git stuff)... You
have a perforce workspace/client-spec, right? That is - a setup that
tells perforce where you want the files to be placed on your hard
drive when you do a standard "p4 sync". Let's call it ~/p4root/ and
let us say that your project will then be synced by perforce to
~/p4root/myproj/
When you want to do a git-p4 clone, you should definitely be *outside*
of ~/p4root/ . Let's say we have a ~/gitroot/ as well. So do cd
~/gitroot/ so that the git-p4 clone will be under ~/gitroot/myproj/ ;
and then do all the git-p4 stuff (clone, add remote, fetch, rebase,
sync, submit).
I think Vitors point was that before you do git-p4 submit, you should
clean - not ~/gitroot/myproj - but ~/p4root/myproj/.
This is probably not something that you need to do everytime you want
to submit back to perforce, but since we have had some rounds with
trial-and-error with this, we have probably placed some dirty files
inside the perforce folders... Make sure that you don't have files
opened in perforce before you sync.
Clearer? More confused? Best of luck anyway :)
-- Tor Arvid
^ permalink raw reply
* [PATCH] Add support for merging from upstream by default.
From: Jared Hance @ 2011-02-05 0:45 UTC (permalink / raw)
To: git; +Cc: Jared Hance
Adds the option merge.defaultupstream to add support for merging from the
upstream branch by default. The upstream branch is found using
branch.[name].upstream.
---
So it turns out that the old code _did_ work with options; I had thought it
hadn't because I relied on !argc == 0, but since argc is decreased after parsing
options anyway, it isn't a problem. This update fixes the usage as Junio
suggested, since it does support options.
builtin/merge.c | 41 +++++++++++++++++++++++++++++++++++------
1 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 42fff38..a69b69f 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -37,6 +37,7 @@ struct strategy {
};
static const char * const builtin_merge_usage[] = {
+ "git merge",
"git merge [options] <remote>...",
"git merge [options] <msg> HEAD <remote>",
NULL
@@ -58,6 +59,8 @@ static int option_renormalize;
static int verbosity;
static int allow_rerere_auto;
static int abort_current_merge;
+static int default_upstream;
+static const char *upstream_branch;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -519,8 +522,15 @@ static int git_merge_config(const char *k, const char *v, void *cb)
builtin_merge_usage, 0);
free(buf);
}
-
- if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
+ else if(branch && !prefixcmp(k, "branch.") &&
+ !prefixcmp(k + 7, branch) &&
+ !strcmp(k + 7 + strlen(branch), ".upstream")) {
+ return git_config_string(&upstream_branch, k, v);
+ }
+
+ if (!strcmp(k, "merge.defaultupstream"))
+ default_upstream = git_config_bool(k, v);
+ else if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
show_diffstat = git_config_bool(k, v);
else if (!strcmp(k, "pull.twohead"))
return git_config_string(&pull_twohead, k, v);
@@ -983,9 +993,28 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (!allow_fast_forward && fast_forward_only)
die("You cannot combine --no-ff with --ff-only.");
- if (!argc)
- usage_with_options(builtin_merge_usage,
- builtin_merge_options);
+ if (!argc) {
+ if(default_upstream && upstream_branch) {
+ struct object *o;
+ struct commit *commit;
+
+ o = peel_to_type(upstream_branch, 0, NULL, OBJ_COMMIT);
+ if (!o)
+ die("%s - not something we can merge", argv[i]);
+ commit = lookup_commit(o->sha1);
+ commit->util = (void *)upstream_branch;
+ remotes = &commit_list_insert(commit, remotes)->next;
+
+ strbuf_addf(&buf, "GITHEAD_%s", sha1_to_hex(o->sha1));
+ setenv(buf.buf, upstream_branch, 1);
+ strbuf_reset(&buf);
+ }
+ else {
+ usage_with_options(builtin_merge_usage,
+ builtin_merge_options);
+
+ }
+ }
/*
* This could be traditional "merge <msg> HEAD <commit>..." and
@@ -1048,7 +1077,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
- if (head_invalid || !argc)
+ if (head_invalid || (!argc && !(default_upstream && upstream_branch)))
usage_with_options(builtin_merge_usage,
builtin_merge_options);
--
1.7.4
^ permalink raw reply related
* Re: [PATCH] Support different branch layouts in git-p4
From: Tor Arvid Lund @ 2011-02-05 0:37 UTC (permalink / raw)
To: Ian Wienand; +Cc: git
In-Reply-To: <4D489068.2040704@vmware.com>
On Tue, Feb 1, 2011 at 11:59 PM, Ian Wienand <ianw@vmware.com> wrote:
> 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.
Hi, Ian! We haven't met, but thank you for the patch, and for trying
to help make git better.
Now, I have to say that I don't particularly like it, and here's why I
will vote against this patch:
For starters, I don't think that I like git-p4 being taught to solve
problems that seem to be caused by a poor/unfortunate perforce layout.
Especially since *your* type of poor perforce layout will probably be
poor in a very different way from the next guy with a poor layout :)
For instance, you have hard-coded that you replace the first and
second directory name... It is very easy to imagine people having
deeper trees than that...
But then I started thinking about it a bit more... It was me who added
the --use-client-spec option back in the day. The support for that
stuff really should be better than what I made at the time. The
client-spec format contains lines like
//depot/... //local-root/...
-//depot/dontcare/... //local-root/dontcare/...
//depot/foo/branch/... //local-root/branch/foo/...
//depot/moo/branch/... //local-root/branch/moo/...
Please observe that the two last lines look like what I think *your*
client-spec should look like. This would map the foo/branch and
moo/branch in the perforce depot to branch/foo and branch/moo on the
client side.
Of course, today this will not work with git-p4 clone. The
--use-client-spec option, as I implemented it, simply filters out all
that stuff that matches the pattern lines that starts with "-". So the
names of all files will match the patterns on the left-hand side in
the client-spec. A solution which I think would work well for
everyone, is if files would be placed according to the right-hand
patterns in the client-spec.
That should be a much more elegant and generic solution. Whatcha
think? If you want to take a whack at hacking that into place, I will
help guide the way if needed (if others are not opposed to such an
idea) :)
-- Tor Arvid
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] Add case insensitive support in matching pathspec
From: Junio C Hamano @ 2011-02-04 23:06 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Johannes Sixt, git, Joshua Jensen
In-Reply-To: <AANLkTi=8-NibvV0NMCpA_KN6+x3GNa0mDr87jtWki_-S@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>> core.ignorecase should be honored only when files on the filesystem are
>> matched, IMO.
>
> Names in index, just as same as match_pathspec().
If the matched entities are names in the index, they should already be
canonical and we shouldn't be matching with icase, no?
^ permalink raw reply
* [PATCH/RFC] Add support for merging from upstream by default.
From: Jared Hance @ 2011-02-04 23:01 UTC (permalink / raw)
To: git; +Cc: Jared Hance
In-Reply-To: <7vsjw957fq.fsf_-_@alter.siamese.dyndns.org>
Adds the option merge.defaultupstream to add support for merging from the
upstream branch by default. The upstream branch is found using
branch.[name].upstream.
---
This is just testing code; it works but I'm not yet sure if it breaks other
things. I tried to code it so it doesn't.
Note: First time using git send-email; I hope I set it up correctly with the
In-reply-to and Cc's and such.
builtin/merge.c | 41 +++++++++++++++++++++++++++++++++++------
1 files changed, 35 insertions(+), 6 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 42fff38..a69b69f 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -37,6 +37,7 @@ struct strategy {
};
static const char * const builtin_merge_usage[] = {
+ "git merge",
"git merge [options] <remote>...",
"git merge [options] <msg> HEAD <remote>",
NULL
@@ -58,6 +59,8 @@ static int option_renormalize;
static int verbosity;
static int allow_rerere_auto;
static int abort_current_merge;
+static int default_upstream;
+static const char *upstream_branch;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -519,8 +522,15 @@ static int git_merge_config(const char *k, const char *v, void *cb)
builtin_merge_usage, 0);
free(buf);
}
-
- if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
+ else if(branch && !prefixcmp(k, "branch.") &&
+ !prefixcmp(k + 7, branch) &&
+ !strcmp(k + 7 + strlen(branch), ".upstream")) {
+ return git_config_string(&upstream_branch, k, v);
+ }
+
+ if (!strcmp(k, "merge.defaultupstream"))
+ default_upstream = git_config_bool(k, v);
+ else if (!strcmp(k, "merge.diffstat") || !strcmp(k, "merge.stat"))
show_diffstat = git_config_bool(k, v);
else if (!strcmp(k, "pull.twohead"))
return git_config_string(&pull_twohead, k, v);
@@ -983,9 +993,28 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
if (!allow_fast_forward && fast_forward_only)
die("You cannot combine --no-ff with --ff-only.");
- if (!argc)
- usage_with_options(builtin_merge_usage,
- builtin_merge_options);
+ if (!argc) {
+ if(default_upstream && upstream_branch) {
+ struct object *o;
+ struct commit *commit;
+
+ o = peel_to_type(upstream_branch, 0, NULL, OBJ_COMMIT);
+ if (!o)
+ die("%s - not something we can merge", argv[i]);
+ commit = lookup_commit(o->sha1);
+ commit->util = (void *)upstream_branch;
+ remotes = &commit_list_insert(commit, remotes)->next;
+
+ strbuf_addf(&buf, "GITHEAD_%s", sha1_to_hex(o->sha1));
+ setenv(buf.buf, upstream_branch, 1);
+ strbuf_reset(&buf);
+ }
+ else {
+ usage_with_options(builtin_merge_usage,
+ builtin_merge_options);
+
+ }
+ }
/*
* This could be traditional "merge <msg> HEAD <commit>..." and
@@ -1048,7 +1077,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
- if (head_invalid || !argc)
+ if (head_invalid || (!argc && !(default_upstream && upstream_branch)))
usage_with_options(builtin_merge_usage,
builtin_merge_options);
--
1.7.4
^ permalink raw reply related
* Re: [1.8.0] Re: reorganize the mess that the source tree has become
From: Drew Northup @ 2011-02-04 22:47 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Miles Bader, Hilco Wijbenga, git, Nicolas Pitre, George Spelvin,
Eugene Sajine
In-Reply-To: <20110204181550.GA14173@vidovic>
On Fri, 2011-02-04 at 19:15 +0100, Nicolas Sebrecht wrote:
> The 04/02/11, Miles Bader wrote:
> > Hilco Wijbenga <hilco.wijbenga@gmail.com> writes:
> > > Quite frankly, I'm surprised there are (presumably experienced)
> > > developers who do not immediately see the value of a little
> > > organization. Surely, given the use of code conventions, formatting
> > > rules, etcetera, the obvious one step further is to also organize
> > > where the files go?
> >
> > I think one of the problems is that what's been suggested seems like
> > window-dressing. Moving everything into src/ and calling it "organized"
> > doesn't actually accomplish much other than perhaps making the README
> > file more visible to newbs; things are _still_ a mess, just a mess with
> > four more letters...
>
> So it would be an ordered mess, at least. The current amount of files in
> the root directory do make things harder for people not already familiar
> with the content. FMHO, moving the source files into a subdirectory
> could be only a first step to the good direction.
Nicolas,
Having once upon a time (in CVS days) taken over a project that was
neatly organized into tons of folders I can say that more folders is not
always better.
If you are organizing things into modules by folders, and those things
are mutually exclusive pre-compilation then doing so may make sense. If
the folders ADD value to the project by adding organization--as opposed
to hiding disorganization--then they may have value.
>From my meager hacking thus far (working on making utf-16 a more
user-friendly experience out-of-the-box) I have found that none of this
is true (thus far) with the git codebase. In fact the one thing that
would have been useful is more in-code--and/or separate
API-ish--documentation (it took me waaaay too long to figure out how git
add, aka git-add, works), but I am too much of a realist to expect that
to change much. I most certainly DO NOT recommend that a mess of patches
be submitted to Junio to fix it (document what you are working on as you
see fit; I work on too many things to not document fairly extensively).
I approach codebase reorganization the same way. I have seen the
destructive things it can do to a project when it becomes an end unto
itself separate from the primary focus. In fact, what killed that first
project I mentioned was an argument about something that was not part of
the primary purpose of the project which exploded with a fury resembling
a religious confrontation. I do not want to see that happen to Git. I
didn't want to see that project die either, but when you exasperate
enough of the core developers that's what happens.
(My first job as project leader was to get it off of our CVS host, the
second was to find it a nice grave over at nongnu.org. I never did get
CVS import to work. I never did convince any of the core developers that
it was still worth working on.)
--
-Drew Northup
________________________________________________
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Junio C Hamano @ 2011-02-04 22:39 UTC (permalink / raw)
To: Johan Herland
Cc: git, Sverre Rabbelier, Jeff King, Nguyen Thai Ngoc Duy,
Nicolas Pitre
In-Reply-To: <201102020322.00171.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> - Remote tags are now stored separate from local tags. When looking up a
> shorthand tag name (e.g. v1.7.4), we should consult local tags
> (refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See
> [2] for more details.
> - Remote heads have moved into refs/remotes/$remote/heads/*, hence
> invalidating shorthand remote head names, like "origin/master". We should
> change the lookup code, so that a shorthand ref of the form "$remote/$head"
> where "$remote" happens to match a configured remote is eventually expanded
> into lookup for "refs/remotes/$remote/heads/$head" [3].
Keeping 'origin/next' usable is a _must_, _if_ we were to go this route.
> - We might want to generalize the handling of "$remote/$head" into allowing
> shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as
> well (provided, of course, that they match unambiguously).
>
> - All fetch refspecs should be given explicitly.
What do you mean by this?
> Sub-proposal: While we are changing the default refspecs, we should also
> consider whether we want to keep the auto-following behavior that Git
> currently does for tags (don't fetch tags that refer to objects not
> otherwise fetched by another refspec). If we simply make an explicit
> "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will lose the auto-
> following behavior. If we do want to keep the auto-following behavior, we
> could for example add a "~" prefix to the refspec to trigger auto-following
> behavior (i.e. this refspec only applies to refs that happen to point at
> objects fetched by way of a different refspec). See
> http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795
> for more details.
You seem to envision "auto-follow" to slurp remote tags in remotes/origin/$tag
namespace. What should "git fetch --tags $from_there" do?
For some reason, many people seem to be enthused about splitting the tag
namespace, but I am not sure if that is a good thing in general. Branches
are moving pointers for people to flip around in their local repositories,
and it makes sense to say "My master is a bit ahead of the public one",
but what would we gain by making it _easier_ to add and exchange many tags
with the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4),
other than the extra confusion?
While you are talking about drastic reorganization (and rewriting the ref
code to support it), another possible Sub-proposal we may want to consider
is to allow "next" and "next/foo" at the same time.
^ permalink raw reply
* Re: [PATCH] git pull: Remove option handling done by fetch
From: Johannes Sixt @ 2011-02-04 22:26 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4D4C5EBC.2090100@web.de>
On Freitag, 4. Februar 2011, Jens Lehmann wrote:
> In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options
> "--[no-]recurse-submodules" had been added to git-pull.sh. This was not
> necessary because all options to "git fetch" are passed to it and handled
> there, so lets remove them.
>
> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
> ---
>
> I noticed this while implementing the on-demand recursive fetch.
>
> git-pull.sh | 10 ++--------
> 1 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/git-pull.sh b/git-pull.sh
> index eb87f49..20a3bbe 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -38,7 +38,7 @@ test -z "$(git ls-files -u)" || die_conflict
> test -f "$GIT_DIR/MERGE_HEAD" && die_merge
>
> strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
> -log_arg= verbosity= progress= recurse_submodules=
> +log_arg= verbosity= progress=
> merge_args=
> curr_branch=$(git symbolic-ref -q HEAD)
> curr_branch_short="${curr_branch#refs/heads/}"
> @@ -105,12 +105,6 @@ do
> --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
> rebase=false
> ;;
> - --recurse-submodules)
> - recurse_submodules=--recurse-submodules
> - ;;
> - --no-recurse-submodules)
> - recurse_submodules=--no-recurse-submodules
> - ;;
> --d|--dr|--dry|--dry-|--dry-r|--dry-ru|--dry-run)
> dry_run=--dry-run
> ;;
> @@ -223,7 +217,7 @@ test true = "$rebase" && {
> done
> }
> orig_head=$(git rev-parse -q --verify HEAD)
> -git fetch $verbosity $progress $dry_run $recurse_submodules
> --update-head-ok "$@" || exit 1
>> +git fetch $verbosity $progress $dry_run
> --update-head-ok "$@" || exit 1 test -z "$dry_run" || exit 0
>
> curr_head=$(git rev-parse -q --verify HEAD)
Huh? What will, for example,
git pull --recurse-submodules --no-ff origin
do before and after your patch? Doesn't your patch force users to
write --[no-]recurse-submodules last?
-- Hannes
^ permalink raw reply
* Re: git-blame.el: does not show one-line summary in echo area
From: Kevin Ryde @ 2011-02-04 21:49 UTC (permalink / raw)
To: David Kågedal
Cc: Jakub Narebski, Sergei Organov, Andreas Schwab, git,
Martin Nordholts, Alexandre Julliard, Xavier Maillard,
Jonathan Nieder
In-Reply-To: <87r5bom7g3.fsf@krank.kagedal.org>
David Kågedal <davidk@lysator.liu.se> writes:
>
> But we can
> of course let the echo area grow to two lines, or even three.
Though xemacs 21 can't grow it, and emacs doesn't if you turn off
message-truncate-lines.
If message-truncate-lines is nil or unbound you might collapse out
newlines or perhaps ellipsize or something.
^ permalink raw reply
* in the news with Delta Cooling Towers...
From: Tom Ryder @ 2011-02-04 21:45 UTC (permalink / raw)
To: git
Hi,
Delta Cooling Towers is in the news again!
Below is an on-line published article generated for Delta Cooling Towers.
The magazine is Construction Week Online.
http://www.constructionweekonline.com/article-10384-maintenance-for-cooling-towers/
Here is another on-line published article generated.
The magazine is HVAC News Online.
http://news.hvacnews.com/2011/01/new-engineered-plastic-cooling-tower-helps-keep-tenants-fresh-in-broiling-la-heat-wave.html
Thanks,
Tom Ryder
Customer Support and Business Development
Delta Cooling Towers, Inc.
41 Pine Street, PO Box 315
Rockaway, NJ 07866
Tel: 973-586-2201 x204
FAX: 973-586-2243 / 973-586-9156
Toll-Free: 1-800-BUY-DELTA
tryder@deltacooling.com
www.deltacooling.com
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you would like to be removed from this list, please reply with the word 'remove' as the subject.
^ 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