* Re: [PATCH v2] pull: Document the "--[no-]recurse-submodules" options
From: Junio C Hamano @ 2011-02-07 21:42 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List
In-Reply-To: <4D5047BD.6030304@web.de>
Jens Lehmann <Jens.Lehmann@web.de> writes:
> diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
> index 695696d..ab0dbfc 100644
> --- a/Documentation/fetch-options.txt
> +++ b/Documentation/fetch-options.txt
> @@ -64,11 +64,11 @@ ifndef::git-pull[]
> downloaded. The default behavior for a remote may be
> specified with the remote.<name>.tagopt setting. See
> linkgit:git-config[1].
> -endif::git-pull[]
>
> --[no-]recurse-submodules::
> This option controls if new commits of all populated submodules should
> be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
> +endif::git-pull[]
>
> ifndef::git-pull[]
> --submodule-prefix=<path>::
Hmph, why not enclose the three of them inside a single ifndef here?
> diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
> index 3046691..b33e6be 100644
> --- a/Documentation/git-pull.txt
> +++ b/Documentation/git-pull.txt
> @@ -84,6 +84,15 @@ must be given before the options meant for 'git fetch'.
> --verbose::
> Pass --verbose to git-fetch and git-merge.
>
> +--[no-]recurse-submodules::
> + This option controls if new commits of all populated submodules should
> + be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
> + That might be necessary to get the data needed for merging submodule
> + commits, a feature git learned in 1.7.3. Notice that the result of a
> + merge will not be checked out in the submodule, "git submodule update"
> + has to be called afterwards to bring the work tree up to date with the
> + merge result.
Ok.
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Junio C Hamano @ 2011-02-07 21:49 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, Junio C Hamano, Sebastian Pipping, Git ML
In-Reply-To: <20110207210257.GA14963@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So I think there is less "we do it one way, and this is the outlier" and
> more "we are horribly inconsistent".
Yeah, didn't I say I used to be the third camp which I find is hard to
jusitify, and am open to consistency either way?
^ permalink raw reply
* Re: [msysGit] Re: [PATCH v4 5/5] mingw_rmdir: set errno=ENOTEMPTY when appropriate
From: Junio C Hamano @ 2011-02-07 21:54 UTC (permalink / raw)
To: kusmabite
Cc: Heiko Voigt, Junio C Hamano, Johannes Sixt, Pat Thoyts, msysgit,
git, Johannes Schindelin
In-Reply-To: <AANLkTi=ntgYOW58pPnt-azMw6rFZfJjDW3OaCgLsvJp6@mail.gmail.com>
Erik Faye-Lund <kusmabite@gmail.com> writes:
> On Mon, Feb 7, 2011 at 10:18 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
> ...
>> I think Johannes was referring to the case when a directory is busy.
>> E.g. a process is running that has its working directory inside that
>> directory. In that case ENOTEMPTY was not returned even though the
>> directory is not empty. Thats what I read from the patch.
>
> I don't think that's the case either:
> $ echo "int main() { while (1); }" | gcc -x c - -o foo/bin.exe
> [kusma@HUE-PC:/git@work/xgetenv]
> $ foo/bin.exe &
> [2] 3188
> [kusma@HUE-PC:/git@work/xgetenv]
> $ ./a.exe
> rmdir: Directory not empty
> errno: 41 (expected 41)
I don't do windows, but I think Heiko is talking about running some
process inside the directory that is getting removed. Assuming that your
a.exe is to remove the 'foo' directory, you would need to run ./bin.exe
after going into 'foo' directory, perhaps like this:
$ (cd foo && ./bin.exe) &
$ ./a.exe
^ permalink raw reply
* Re: [msysGit] Re: [PATCH v4 5/5] mingw_rmdir: set errno=ENOTEMPTY when appropriate
From: Erik Faye-Lund @ 2011-02-07 21:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Heiko Voigt, Johannes Sixt, Pat Thoyts, msysgit, git,
Johannes Schindelin
In-Reply-To: <7vk4hbtsro.fsf@alter.siamese.dyndns.org>
On Mon, Feb 7, 2011 at 10:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Erik Faye-Lund <kusmabite@gmail.com> writes:
>
>> On Mon, Feb 7, 2011 at 10:18 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>> ...
>>> I think Johannes was referring to the case when a directory is busy.
>>> E.g. a process is running that has its working directory inside that
>>> directory. In that case ENOTEMPTY was not returned even though the
>>> directory is not empty. Thats what I read from the patch.
>>
>> I don't think that's the case either:
>> $ echo "int main() { while (1); }" | gcc -x c - -o foo/bin.exe
>> [kusma@HUE-PC:/git@work/xgetenv]
>> $ foo/bin.exe &
>> [2] 3188
>> [kusma@HUE-PC:/git@work/xgetenv]
>> $ ./a.exe
>> rmdir: Directory not empty
>> errno: 41 (expected 41)
>
> I don't do windows, but I think Heiko is talking about running some
> process inside the directory that is getting removed. Assuming that your
> a.exe is to remove the 'foo' directory, you would need to run ./bin.exe
> after going into 'foo' directory, perhaps like this:
>
> $ (cd foo && ./bin.exe) &
> $ ./a.exe
Of course, silly me:
$ ./a.exe
rmdir: Permission denied
errno: 13 (expected 41)
Thanks for clearing that up, now I'm on board :)
^ permalink raw reply
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Jonathan Nieder @ 2011-02-07 22:00 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Jeff King, Martin von Zweigbergk, git
In-Reply-To: <AANLkTinmqTi4cYbR6PtSxt6itCvFQDuT_sE1tjx45a3h@mail.gmail.com>
Sverre Rabbelier wrote:
> Now _that_ is an excellent usability improvement, assuming we want to
> encourage detaching HEAD... do we?
Yes.
-- 8<
Subject: commit: document --detach synonym for "git checkout foo^{commit}"
For example, one might use this when making a temporary merge to test
that two topics work well together.
This patch just documents the option. It is not meant for application
without an implementation and tests for the option.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-checkout.txt | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 880763d..698ae6c 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -9,6 +9,7 @@ SYNOPSIS
--------
[verse]
'git checkout' [-q] [-f] [-m] [<branch>]
+'git checkout' [-q] [-f] [-n] [--detach] [<commit>]
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' --patch [<tree-ish>] [--] [<paths>...]
@@ -22,9 +23,10 @@ branch.
'git checkout' [<branch>]::
'git checkout' -b|-B <new_branch> [<start point>]::
+'git checkout' [--detach] [<commit>]::
This form switches branches by updating the index, working
- tree, and HEAD to reflect the specified branch.
+ tree, and HEAD to reflect the specified branch or commit.
+
If `-b` is given, a new branch is created as if linkgit:git-branch[1]
were called and then checked out; in this case you can
@@ -115,6 +117,13 @@ explicitly give a name with '-b' in such a case.
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
+--detach::
+ Rather than checking out a branch to work on it, check out a
+ commit for inspection and discardable experiments.
+ This is the default behavior of "git checkout <commit>" when
+ <commit> is not a branch name. See the "DETACHED HEAD" section
+ below for details.
+
--orphan::
Create a new 'orphan' branch, named <new_branch>, started from
<start_point> and switch to it. The first commit made on this
@@ -204,7 +213,7 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
-Detached HEAD
+DETACHED HEAD
-------------
It is sometimes useful to be able to 'checkout' a commit that is
--
1.7.4
^ permalink raw reply related
* [PATCH v3] pull: Document the "--[no-]recurse-submodules" options
From: Jens Lehmann @ 2011-02-07 22:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List
In-Reply-To: <7vsjvzttbs.fsf@alter.siamese.dyndns.org>
In commits be254a0ea9 and 7dce19d374 the handling of the new fetch options
"--[no-]recurse-submodules" had been added to git-pull.sh. But they were
not documented as the pull options they now are, so let's fix that.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
Am 07.02.2011 22:42, schrieb Junio C Hamano:
> Hmph, why not enclose the three of them inside a single ifndef here?
Sure!
Documentation/fetch-options.txt | 2 --
Documentation/git-pull.txt | 9 +++++++++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index 695696d..f37276e 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -64,13 +64,11 @@ ifndef::git-pull[]
downloaded. The default behavior for a remote may be
specified with the remote.<name>.tagopt setting. See
linkgit:git-config[1].
-endif::git-pull[]
--[no-]recurse-submodules::
This option controls if new commits of all populated submodules should
be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
-ifndef::git-pull[]
--submodule-prefix=<path>::
Prepend <path> to paths printed in informative messages
such as "Fetching submodule foo". This option is used
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index 3046691..b33e6be 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -84,6 +84,15 @@ must be given before the options meant for 'git fetch'.
--verbose::
Pass --verbose to git-fetch and git-merge.
+--[no-]recurse-submodules::
+ This option controls if new commits of all populated submodules should
+ be fetched too (see linkgit:git-config[1] and linkgit:gitmodules[5]).
+ That might be necessary to get the data needed for merging submodule
+ commits, a feature git learned in 1.7.3. Notice that the result of a
+ merge will not be checked out in the submodule, "git submodule update"
+ has to be called afterwards to bring the work tree up to date with the
+ merge result.
+
Options related to merging
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
1.7.4.47.g87a200
^ permalink raw reply related
* Re: [PATCH 1/8] git-p4: test script
From: Pete Wyckoff @ 2011-02-07 22:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1v3kwpm9.fsf@alter.siamese.dyndns.org>
gitster@pobox.com wrote on Sun, 06 Feb 2011 18:22 -0800:
> Pete Wyckoff <pw@padd.com> writes:
[..]
> Use of two global variables with short names makes me feel "yeek!".
>
> (p4 -h && p4d -h) >/dev/null 2>/dev/null ||
> {
> ...
> test_done
> }
Much nicer. Thanks.
> > + p4d -q -d -r "$db" -p $P4DPORT &&
> > + # wait for it to finish its initialization
> > + sleep 1 &&
>
> Is there a guarantee that "1" is sufficiently long for everybody?
>
> Otherwise this will be a flaky test that sometimes passes and sometimes
> doesn't, which we try to avoid.
>
> If the answer is "empirically 1 second is sufficient for 99.9% of people",
> then I would have to guess that it is 0.8 second too long for majority of
> people, in which case I would like to see us try harder to make it both
> reliable and efficient.
>
> Isn't there a "noop" command a client can issue against a working server
> that fails when the server is not ready (or waits until the server becomes
> ready)?
There is a noop ("p4 info") that I can use to test. But turns
out I was wrong in even needing to sleep or wait for the "info"
test to complete. In trying to get it to race, I found that p4d
is well-behaved. Strace confirms that it does bind/listen before
daemonizing. So that sleep can be removed.
I'll wait a while in case other comments come in, then send the
updated series to you.
-- Pete
^ permalink raw reply
* Re: Can't find the revelant commit with git-log
From: Junio C Hamano @ 2011-02-07 22:51 UTC (permalink / raw)
To: René Scharfe; +Cc: Francis Moreau, git, Johannes Sixt
In-Reply-To: <4D4477E4.6020006@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> 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 &&
Thanks for a patch with a test; I am not sure if this is quite correct,
though.
A4 has three parents, C2, A3 and B2, and does not introduce any change
with respect to bar.txt. A6 has bar.txt identical to that of A5, but we
cannot omit it because we are showing its two parents (A5 and C4), and
that is why we show it. A4 isn't even gets shown as a merge, so I don't
understand why we need to show it?
Don't we need to also adjust the simplify-merges codepath to take this
change into account, or something?
^ permalink raw reply
* Re: [PATCH] Support different branch layouts in git-p4
From: Tor Arvid Lund @ 2011-02-07 23:27 UTC (permalink / raw)
To: Ian Wienand; +Cc: git@vger.kernel.org
In-Reply-To: <4D4F3738.7010603@vmware.com>
On Mon, Feb 7, 2011 at 1:05 AM, Ian Wienand <ianw@vmware.com> wrote:
> On 04/02/11 16:37, Tor Arvid Lund wrote:
>> 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.
>
> I do think this //depot/project/branch type layout is pretty typical,
> although I admit I don't have a lot of experience with alternative p4
> setups.
You may be right, although I suspect that
//depot/department/project/branch may be equally typical. At my
$dayjob, we have gone through several "reorganizations" of the
perforce layouts. I'm the guy that never likes any of them ;)
>> 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.
>
> I did consider this at first. My only issue is that it is a bit
> confusing to use the client spec for filtering (and in this case
> re-writing), but not for actually selecting the depots to clone, which
> I still need to replicate on the command line. However that is a much
> larger change.
>
> What do you think of this one?
In general, me thinks me likes it :-)
(and it turned out much smaller than I would have originally guessed)
I should probably mention that I haven't tested your patch at all. I
will have a pretty rough week at work, so it would be great if anyone
else feels like chiming in on this one... But I have some quick
observations below:
> ---
>
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 04ce7e3..eb9620c 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -878,6 +878,7 @@ class P4Sync(Command):
> self.cloneExclude = []
> self.useClientSpec = False
> self.clientSpecDirs = []
> + self.clientName = None
>
> if gitConfig("git-p4.syncFromOrigin") == "false":
> self.syncWithOrigin = False
> @@ -910,6 +911,22 @@ class P4Sync(Command):
> return files
>
> def stripRepoPath(self, path, prefixes):
> + if self.useClientSpec:
> +
> + # if using the client spec, we use the output directory
> + # specified in the client. For example, a view
> + # //depot/foo/branch/... //client/branch/foo/...
> + # will end up putting all foo/branch files into
> + # branch/foo/
> + for val in self.clientSpecDirs:
> + if path.startswith(val[0]):
> + # replace the depot path with the client path
> + path = path.replace(val[0], val[1][1])
> + # now strip out the client (//client/...)
> + path = re.sub("^(//[^/]+/)", '', path)
> + # the rest is all path
> + return path
> +
> if self.keepRepoPath:
> prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
>
> @@ -1032,7 +1049,7 @@ class P4Sync(Command):
> includeFile = True
> for val in self.clientSpecDirs:
> if f['path'].startswith(val[0]):
> - if val[1] <= 0:
> + if val[1][0] <= 0:
> includeFile = False
> break
>
> @@ -1474,20 +1491,36 @@ class P4Sync(Command):
> temp = {}
> for entry in specList:
> for k,v in entry.iteritems():
> + if k.startswith("Client"):
> + self.clientName = v
> +
> if k.startswith("View"):
> if v.startswith('"'):
> start = 1
> else:
> start = 0
> index = v.find("...")
> +
> + # save the "client view"; i.e the RHS of the view
> + # line that tells the client where to put the
> + # files for this view.
> + cv = v[index+4:] # +4 to remove previous '... '
This feels less robust than what we might want. Isn't the format of a
client-spec line either:
-?//depot/path[/...]\s+//client/path[/...]\n
or
-?"//depot/path with spaces/path[/...]"\s+"//client/path with spaces/path[/...]"
.. where -? means an optional '-' char, and \s+ is
'whatever-length-and-kind-of-whitespace'. I'm just guessing from
memory regarding these patterns, but assuming that the section
separator is exactly the string '... ' seems risky, no? :)
> + cv_index = cv.find("...")
> + cv=cv[:cv_index]
What if a line doesn't end with "..." ? Maybe add an "if cv_index >= 0"
> +
> + # now save the view; +index means included, -index
> + # means it should be filtered out.
> v = v[start:index]
> if v.startswith("-"):
> v = v[1:]
> - temp[v] = -len(v)
> + include = -len(v)
> else:
> - temp[v] = len(v)
> + include = len(v)
> +
> + temp[v] = (include, cv)
> +
> self.clientSpecDirs = temp.items()
> - self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
> + self.clientSpecDirs.sort( lambda x, y: abs( y[1][0] ) - abs( x[1][0] ) )
>
> def run(self, args):
> self.depotPaths = []
> diff --git a/contrib/fast-import/git-p4.txt b/contrib/fast-import/git-p4.txt
> index 49b3359..e09da44 100644
> --- a/contrib/fast-import/git-p4.txt
> +++ b/contrib/fast-import/git-p4.txt
> @@ -191,6 +191,11 @@ git-p4.useclientspec
>
> git config [--global] git-p4.useclientspec false
>
> +The P4CLIENT environment variable should be correctly set for p4 to be
> +able to find the relevant client. This client spec will be used to
> +both filter the files cloned by git and set the directory layout as
> +specified in the client (this implies --keep-path style semantics).
> +
> Implementation Details...
> =========================
>
>
Aight. I need some sleep now. Nice work so far, Ian! :)
-- Tor Arvid
^ permalink raw reply
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Junio C Hamano @ 2011-02-07 23:37 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Sverre Rabbelier, Jeff King, Martin von Zweigbergk, git
In-Reply-To: <20110207220030.GA19357@elie>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Sverre Rabbelier wrote:
>
>> Now _that_ is an excellent usability improvement, assuming we want to
>> encourage detaching HEAD... do we?
>
> Yes.
>
> -- 8<
> Subject: commit: document --detach synonym for "git checkout foo^{commit}"
>
> For example, one might use this when making a temporary merge to test
> that two topics work well together.
>
> This patch just documents the option. It is not meant for application
> without an implementation and tests for the option.
On top of v1.7.3.5-1-g0cb6ad3 (uk/checkout-ambiguous-ref)...
builtin/checkout.c | 12 +++++++++---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 953abdd..141f6a3 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -685,6 +685,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
char *conflict_style = NULL;
int patch_mode = 0;
int dwim_new_local_branch = 1;
+ int force_detach = 0;
struct option options[] = {
OPT__QUIET(&opts.quiet),
OPT_STRING('b', NULL, &opts.new_branch, "branch",
@@ -692,6 +693,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
OPT_STRING('B', NULL, &opts.new_branch_force, "branch",
"create/reset and checkout a branch"),
OPT_BOOLEAN('l', NULL, &opts.new_branch_log, "create reflog for new branch"),
+ OPT_BOOLEAN(0, "detach", &force_detach, "detach the HEAD at named commit"),
OPT_SET_INT('t', "track", &opts.track, "set upstream info for new branch",
BRANCH_TRACK_EXPLICIT),
OPT_STRING(0, "orphan", &opts.new_orphan_branch, "new branch", "new unparented branch"),
@@ -726,6 +728,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.new_branch && opts.new_branch_force)
die("-B cannot be used with -b");
+ if ((opts.new_branch || opts.new_orphan_branch) && force_detach)
+ die("--detach cannot be used with -b/-B/--orphan");
+
/* copy -B over to -b, so that we can just check the latter */
if (opts.new_branch_force)
opts.new_branch = opts.new_branch_force;
@@ -834,7 +839,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
new.name = arg;
setup_branch_path(&new);
- if (check_ref_format(new.path) == CHECK_REF_FORMAT_OK &&
+ if (!force_detach &&
+ check_ref_format(new.path) == CHECK_REF_FORMAT_OK &&
resolve_ref(new.path, branch_rev, 1, NULL))
hashcpy(rev, branch_rev);
else
^ permalink raw reply related
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Jeff King @ 2011-02-07 23:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Sverre Rabbelier, Martin von Zweigbergk, git
In-Reply-To: <7vaai7s9g4.fsf@alter.siamese.dyndns.org>
On Mon, Feb 07, 2011 at 03:37:15PM -0800, Junio C Hamano wrote:
> > Subject: commit: document --detach synonym for "git checkout foo^{commit}"
> >
> > For example, one might use this when making a temporary merge to test
> > that two topics work well together.
> >
> > This patch just documents the option. It is not meant for application
> > without an implementation and tests for the option.
>
> On top of v1.7.3.5-1-g0cb6ad3 (uk/checkout-ambiguous-ref)...
Well, I started on tests and your email came just as I was about to
actually implement. So here are the tests. We didn't seem to have any
explicit checkout-detached tests before, so I tried to cover existing
methods in addition to the new option (which means Martin will need to
tweak one of the tests below when implementing his proposal).
Jonathan, do you want to roll all of these up into a single patch?
---
t/t2020-checkout-detach.sh | 62 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100755 t/t2020-checkout-detach.sh
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
new file mode 100755
index 0000000..886e186
--- /dev/null
+++ b/t/t2020-checkout-detach.sh
@@ -0,0 +1,62 @@
+#!/bin/sh
+
+test_description='checkout into detached HEAD state'
+. ./test-lib.sh
+
+check_detached() {
+ ! git symbolic-ref -q HEAD >/dev/null
+}
+
+check_not_detached() {
+ ! check_detached
+}
+
+reset() {
+ git checkout master &&
+ check_not_detached
+}
+
+test_expect_success 'setup' '
+ test_commit one &&
+ test_commit two &&
+ git branch branch &&
+ git tag tag
+'
+
+test_expect_success 'checkout branch does not detach' '
+ reset &&
+ git checkout branch &&
+ check_not_detached
+'
+
+test_expect_success 'checkout tag detaches' '
+ reset &&
+ git checkout tag &&
+ check_detached
+'
+
+test_expect_success 'checkout branch by full name detaches' '
+ reset &&
+ git checkout refs/heads/branch &&
+ check_detached
+'
+
+test_expect_success 'checkout non-ref detaches' '
+ reset &&
+ git checkout branch^ &&
+ check_detached
+'
+
+test_expect_success 'checkout ref^0 detaches' '
+ reset &&
+ git checkout branch^0 &&
+ check_detached
+'
+
+test_expect_success 'checkout --detach detaches' '
+ reset &&
+ git checkout --detach branch &&
+ check_detached
+'
+
+test_done
--
1.7.4.rc2.27.gd0787
^ permalink raw reply related
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Jonathan Nieder @ 2011-02-08 0:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sverre Rabbelier, Martin von Zweigbergk, git
In-Reply-To: <20110207234526.GA28336@sigill.intra.peff.net>
Jeff King wrote:
> Jonathan, do you want to roll all of these up into a single patch?
Sounds good.
> +++ b/t/t2020-checkout-detach.sh
[...]
> +check_detached() {
> + ! git symbolic-ref -q HEAD >/dev/null
> +}
> +
> +check_not_detached() {
> + ! check_detached
> +}
To be pedantic, I'll put
check_detached () {
test_must_fail git symbolic-ref -q HEAD >/dev/null
}
check_not_detached () {
git symbolic-ref -q HEAD >/dev/null
}
and add some more paranoid tests:
test_expect_success 'checkout --detach without branch name detaches' '
reset &&
git checkout --detach &&
check_detached
'
test_expect_success 'checkout --detach catches error in usage' '
reset &&
git checkout master &&
test_must_fail git checkout --detach tag nonsense &&
check_not_detached
'
test_expect_success 'checkout --detach moves HEAD' '
reset &&
git checkout one &&
git checkout --detach two &&
git diff --exit-code HEAD &&
git diff --exit-code two
'
^ permalink raw reply
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Martin von Zweigbergk @ 2011-02-08 0:22 UTC (permalink / raw)
To: Heiko Voigt; +Cc: Martin von Zweigbergk, git
In-Reply-To: <20110207211127.GG63976@book.hvoigt.net>
On Mon, 7 Feb 2011, Heiko Voigt wrote:
> Hallo Martin,
>
> On Mon, Feb 07, 2011 at 06:01:51AM -0500, Martin von Zweigbergk wrote:
> > Proposal:
> >
> > 'git checkout refs/heads/foo' (or 'git checkout heads/foo' for that
> > matter) does not check out the branch, but instead detaches HEAD at
> > foo. This is quite counter-intuitive (at least to me) and the same
> > functionality can be achieved by using e.g. foo~0. Change the behavior
> > so that the branch is actually checked out. This also applies to
> > e.g. 'git rebase master refs/heads/topic', which currently rebases a
> > detached HEAD. There are probably other examples as well that I'm not
> > aware of.
>
> Just to clarify: You are not proposing that 'git checkout origin/master'
> would also not checkout to a detached head, right? Because that is a
> feature I am using frequently to test branches that have been pushed by
> another developer to a remote server. If that would create a new local
> branch that would be confusing.
Nope, I'm not proposing that. I wouldn't want that either.
/Martin
^ permalink raw reply
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Jeff King @ 2011-02-08 0:28 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Sverre Rabbelier, Martin von Zweigbergk, git
In-Reply-To: <20110208000151.GA19944@elie>
On Mon, Feb 07, 2011 at 06:01:52PM -0600, Jonathan Nieder wrote:
> > Jonathan, do you want to roll all of these up into a single patch?
>
> Sounds good.
Thanks.
> To be pedantic, I'll put
> [...]
All look good to me.
-Peff
^ permalink raw reply
* Re: [1.8.0] git checkout refs/heads/foo checks out branch foo
From: Martin von Zweigbergk @ 2011-02-08 0:31 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Jonathan Nieder, Sverre Rabbelier,
Martin von Zweigbergk, git
In-Reply-To: <20110207234526.GA28336@sigill.intra.peff.net>
On Mon, 7 Feb 2011, Jeff King wrote:
> On Mon, Feb 07, 2011 at 03:37:15PM -0800, Junio C Hamano wrote:
>
> > > Subject: commit: document --detach synonym for "git checkout foo^{commit}"
> > >
> > > For example, one might use this when making a temporary merge to test
> > > that two topics work well together.
> > >
> > > This patch just documents the option. It is not meant for application
> > > without an implementation and tests for the option.
> >
> > On top of v1.7.3.5-1-g0cb6ad3 (uk/checkout-ambiguous-ref)...
>
> Well, I started on tests and your email came just as I was about to
> actually implement. So here are the tests. We didn't seem to have any
> explicit checkout-detached tests before, so I tried to cover existing
> methods in addition to the new option (which means Martin will need to
> tweak one of the tests below when implementing his proposal).
Oops, I didn't know writing a proposal meant signing up to do it as
well ;-). But seriously, this seems like a relatively small change, so
it will hopefully be a good reason for me to push myself to get
started with the C code as well.
^ permalink raw reply
* [PATCH] rebase: use @{upstream} if no upstream specified
From: Martin von Zweigbergk @ 2011-02-08 0:37 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Yann Dirson, Martin von Zweigbergk
'git rebase' without arguments is currently not supported. Make it
default to 'git rebase @{upstream}'. That is also what 'git pull
[--rebase]' defaults to, so it only makes sense that 'git rebase'
defaults to the same thing.
Defaulting to @{upstream} will make it possible to run e.g. 'git
rebase -i' without arguments, which is probably a quite common use
case. It also improves the scenario where you have multiple branches
that rebase against a remote-tracking branch, where you currently have
to choose between the extra network delay of 'git pull' or the
slightly awkward keys to enter 'git rebase @{u}'.
Helped-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Applies on top of the rebase refactoring series I sent yesterday, see
http://thread.gmane.org/gmane.comp.version-control.git/166161/
Documentation/config.txt | 2 +-
Documentation/git-rebase.txt | 11 +++++++++--
git-rebase.sh | 35 +++++++++++++++++++++++++++++------
t/t3400-rebase.sh | 25 +++++++++++++++++--------
4 files changed, 56 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c5e1835..b4e65b8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -646,7 +646,7 @@ branch.<name>.remote::
branch.<name>.merge::
Defines, together with branch.<name>.remote, the upstream branch
- for the given branch. It tells 'git fetch'/'git pull' which
+ for the given branch. It tells 'git fetch'/'git pull'/'git rebase' which
branch to merge and can also affect 'git push' (see push.default).
When in branch <name>, it tells 'git fetch' the default
refspec to be marked for merging in FETCH_HEAD. The value is
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 96680c8..d3e998d 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git rebase' [-i | --interactive] [options] [--onto <newbase>]
- <upstream> [<branch>]
+ [<upstream>] [<branch>]
'git rebase' [-i | --interactive] [options] --onto <newbase>
--root [<branch>]
@@ -21,6 +21,12 @@ If <branch> is specified, 'git rebase' will perform an automatic
`git checkout <branch>` before doing anything else. Otherwise
it remains on the current branch.
+If <upstream> is not specified, the upstream configured in
+branch.<name>.remote and branch.<name>.merge options will be used; see
+linkgit:git-config[1] for details. If you are currently not on any
+branch or if the current branch does not have a configured upstream,
+the rebase will abort.
+
All changes made by commits in the current branch but that are not
in <upstream> are saved to a temporary area. This is the same set
of commits that would be shown by `git log <upstream>..HEAD` (or
@@ -216,7 +222,8 @@ leave out at most one of A and B, in which case it defaults to HEAD.
<upstream>::
Upstream branch to compare against. May be any valid commit,
- not just an existing branch name.
+ not just an existing branch name. Defaults to the configured
+ upstream for the current branch.
<branch>::
Working branch; defaults to HEAD.
diff --git a/git-rebase.sh b/git-rebase.sh
index be9ec2a..5975642 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--no-ff] [--onto <newbase>] (<upstream>|--root) [<branch>] [--quiet | -q]'
+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--no-ff] [--onto <newbase>] [<upstream>|--root] [<branch>] [--quiet | -q]'
LONG_USAGE='git-rebase replaces <branch> with a new branch of the
same name. When the --onto option is provided the new branch starts
out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
@@ -144,6 +144,25 @@ run_pre_rebase_hook () {
fi
}
+error_on_missing_default_upstream () {
+ branch_name=$(git symbolic-ref -q HEAD)
+ if test -z "$branch_name"
+ then
+ die "You are not currently on a branch, so I cannot use any
+'branch.<branchname>.merge' in your configuration file.
+Please specify which upstream branch you want to use on the command
+line and try again (e.g. 'git rebase <upstream branch>').
+See git-rebase(1) for details."
+ else
+ die "You asked me to rebase without telling me which branch you
+want to rebase against, and 'branch.${branch_name#refs/heads/}.merge' in
+your configuration file does not tell me, either. Please
+specify which branch you want to use on the command line and
+try again (e.g. 'git rebase <upstream branch>').
+See git-rebase(1) for details."
+ fi
+}
+
test -f "$apply_dir"/applying &&
die 'It looks like git-am is in progress. Cannot rebase.'
@@ -345,8 +364,6 @@ and run me again. I am stopping in case you still have something
valuable there.'
fi
-test $# -eq 0 && test -z "$rebase_root" && usage
-
if test -n "$interactive_rebase"
then
type=interactive
@@ -362,9 +379,15 @@ fi
if test -z "$rebase_root"
then
- # The upstream head must be given. Make sure it is valid.
- upstream_name="$1"
- shift
+ case "$#" in
+ 0)
+ upstream_name=$(git rev-parse --symbolic-full-name --verify -q \
+ @{upstream}) || error_on_missing_default_upstream
+ ;;
+ *) upstream_name="$1"
+ shift
+ ;;
+ esac
upstream=`git rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
upstream_arg="$upstream_name"
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index 349eebd..3bd4a84 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -158,15 +158,24 @@ test_expect_success 'Show verbose error when HEAD could not be detached' '
'
rm -f B
-test_expect_success 'dump usage when upstream arg is missing' '
- git checkout -b usage topic &&
+test_expect_success 'fail when upstream arg is missing and not on branch' '
+ git checkout topic &&
test_must_fail git rebase 2>error1 &&
- grep "[Uu]sage" error1 &&
- test_must_fail git rebase --abort 2>error2 &&
- grep "No rebase in progress" error2 &&
- test_must_fail git rebase --onto master 2>error3 &&
- grep "[Uu]sage" error3 &&
- ! grep "can.t shift" error3
+ grep "You are not currently on a branch" error1
+'
+
+test_expect_success 'fail when upstream arg is missing and not configured' '
+ git checkout -b no-config topic &&
+ test_must_fail git rebase 2>error2 &&
+ grep "branch.no-config.merge" error2
+'
+
+test_expect_success 'default to @{upstream} when upstream arg is missing' '
+ git checkout -b default topic &&
+ git config branch.default.remote .
+ git config branch.default.merge refs/heads/master
+ git rebase &&
+ test "$(git rev-parse default~1)" = "$(git rev-parse master)"
'
test_expect_success 'rebase -q is quiet' '
--
1.7.4.rc2.33.g8a14f
^ permalink raw reply related
* rebase planning: determining blobs changed by multiple branches
From: Neal Kreitzinger @ 2011-02-08 0:41 UTC (permalink / raw)
To: git
We have 15 branches that are unmerged, but are based on the same published
history. They branched off at different points in the history. Each branch
is comprised of a single squashed commit (except for master). How can I
compare all 15 branches with the tip of master to see which file merges
(blobs) they have in common?
a-------b-------c-------d-------e-------f-------g-------i-------j-------k-------l
| | | | | |
| | |---k1
| | | | | |
| |---j1
| | | | | |
|---i1
| | | | |
|---g1
| | | | |---e1
| | | | |---e2
| | | | |---e3
| | | |---d1
| | | |---d2
| | | |---d3
| | |---c1
| | |---c2
| |---b1
| |---b2
|---a1
The goal is to create a sane plan for rebasing. If the question is insane
as it is stated, then please advise on any sane ways to approach this
besides just rebasing one-by-one and making the last poor branch wait till
the end to rebase with a ton of conflicts. I'm dealing with users who
refuse to do frequent rebases, so a plan the minimizes rebases while getting
the most out of each rebase is desired, if practical.
v/r,
Neal
^ permalink raw reply
* [PATCH/WIP] checkout: introduce --detach synonym for "git checkout foo^{commit}"
From: Jonathan Nieder @ 2011-02-08 0:52 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sverre Rabbelier, Martin von Zweigbergk, git
In-Reply-To: <20110207234526.GA28336@sigill.intra.peff.net>
From: Junio C Hamano <gitster@pobox.com>
For example, one might use this when making a temporary merge to
test that two topics work well together.
Patch by Junio, tests from Jeff King.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jeff King wrote:
> Jonathan, do you want to roll all of these up into a single patch?
Okay, here it is. Two of the new tests fail. :)
Documentation/git-checkout.txt | 13 +++++-
builtin/checkout.c | 8 +++-
t/t2020-checkout-detach.sh | 89 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 107 insertions(+), 3 deletions(-)
create mode 100755 t/t2020-checkout-detach.sh
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 22d3611..d162117 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -9,6 +9,7 @@ SYNOPSIS
--------
[verse]
'git checkout' [-q] [-f] [-m] [<branch>]
+'git checkout' [-q] [-f] [-m] [--detach] [<commit>]
'git checkout' [-q] [-f] [-m] [[-b|-B|--orphan] <new_branch>] [<start_point>]
'git checkout' [-f|--ours|--theirs|-m|--conflict=<style>] [<tree-ish>] [--] <paths>...
'git checkout' --patch [<tree-ish>] [--] [<paths>...]
@@ -22,9 +23,10 @@ branch.
'git checkout' [<branch>]::
'git checkout' -b|-B <new_branch> [<start point>]::
+'git checkout' [--detach] [<commit>]::
This form switches branches by updating the index, working
- tree, and HEAD to reflect the specified branch.
+ tree, and HEAD to reflect the specified branch or commit.
+
If `-b` is given, a new branch is created as if linkgit:git-branch[1]
were called and then checked out; in this case you can
@@ -115,6 +117,13 @@ explicitly give a name with '-b' in such a case.
Create the new branch's reflog; see linkgit:git-branch[1] for
details.
+--detach::
+ Rather than checking out a branch to work on it, check out a
+ commit for inspection and discardable experiments.
+ This is the default behavior of "git checkout <commit>" when
+ <commit> is not a branch name. See the "DETACHED HEAD" section
+ below for details.
+
--orphan::
Create a new 'orphan' branch, named <new_branch>, started from
<start_point> and switch to it. The first commit made on this
@@ -204,7 +213,7 @@ leave out at most one of `A` and `B`, in which case it defaults to `HEAD`.
-Detached HEAD
+DETACHED HEAD
-------------
It is sometimes useful to be able to 'checkout' a commit that is
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 953abdd..526abb9 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -685,6 +685,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
char *conflict_style = NULL;
int patch_mode = 0;
int dwim_new_local_branch = 1;
+ int force_detach = 0;
struct option options[] = {
OPT__QUIET(&opts.quiet),
OPT_STRING('b', NULL, &opts.new_branch, "branch",
@@ -692,6 +693,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
OPT_STRING('B', NULL, &opts.new_branch_force, "branch",
"create/reset and checkout a branch"),
OPT_BOOLEAN('l', NULL, &opts.new_branch_log, "create reflog for new branch"),
+ OPT_BOOLEAN(0, "detach", &force_detach, "detach the HEAD at named commit"),
OPT_SET_INT('t', "track", &opts.track, "set upstream info for new branch",
BRANCH_TRACK_EXPLICIT),
OPT_STRING(0, "orphan", &opts.new_orphan_branch, "new branch", "new unparented branch"),
@@ -726,6 +728,9 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.new_branch && opts.new_branch_force)
die("-B cannot be used with -b");
+ if ((opts.new_branch || opts.new_orphan_branch) && force_detach)
+ die("--detach cannot be used with -b/-B/--orphan");
+
/* copy -B over to -b, so that we can just check the latter */
if (opts.new_branch_force)
opts.new_branch = opts.new_branch_force;
@@ -834,7 +839,8 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
new.name = arg;
setup_branch_path(&new);
- if (check_ref_format(new.path) == CHECK_REF_FORMAT_OK &&
+ if (!force_detach &&
+ check_ref_format(new.path) == CHECK_REF_FORMAT_OK &&
resolve_ref(new.path, branch_rev, 1, NULL))
hashcpy(rev, branch_rev);
else
diff --git a/t/t2020-checkout-detach.sh b/t/t2020-checkout-detach.sh
new file mode 100755
index 0000000..e57f253
--- /dev/null
+++ b/t/t2020-checkout-detach.sh
@@ -0,0 +1,89 @@
+#!/bin/sh
+
+test_description='checkout into detached HEAD state'
+. ./test-lib.sh
+
+check_detached () {
+ test_must_fail git symbolic-ref -q HEAD >/dev/null
+}
+
+check_not_detached () {
+ git symbolic-ref -q HEAD >/dev/null
+}
+
+reset () {
+ git checkout master &&
+ check_not_detached
+}
+
+test_expect_success 'setup' '
+ test_commit one &&
+ test_commit two &&
+ git branch branch &&
+ git tag tag
+'
+
+test_expect_success 'checkout branch does not detach' '
+ reset &&
+ git checkout branch &&
+ check_not_detached
+'
+
+test_expect_success 'checkout tag detaches' '
+ reset &&
+ git checkout tag &&
+ check_detached
+'
+
+test_expect_success 'checkout branch by full name detaches' '
+ reset &&
+ git checkout refs/heads/branch &&
+ check_detached
+'
+
+test_expect_success 'checkout non-ref detaches' '
+ reset &&
+ git checkout branch^ &&
+ check_detached
+'
+
+test_expect_success 'checkout ref^0 detaches' '
+ reset &&
+ git checkout branch^0 &&
+ check_detached
+'
+
+test_expect_success 'checkout --detach detaches' '
+ reset &&
+ git checkout --detach branch &&
+ check_detached
+'
+
+test_expect_failure 'checkout --detach without branch name' '
+ reset &&
+ git checkout --detach &&
+ check_detached
+'
+
+test_expect_failure 'checkout --detach errors out for extra argument' '
+ reset &&
+ git checkout master &&
+ test_expect_code 129 git checkout --detach tag nonsense &&
+ check_not_detached
+'
+
+test_expect_success 'checkout --detached and -b are incompatible' '
+ check_not_detached &&
+ test_must_fail git checkout --detach -b newbranch tag &&
+ check_not_detached
+'
+
+test_expect_success 'checkout --detach moves HEAD' '
+ reset &&
+ git checkout one &&
+ git checkout --detach two &&
+ git diff --exit-code HEAD &&
+ git diff --exit-code two
+'
+
+test_done
--
1.7.4
^ permalink raw reply related
* What's cooking in git.git (Feb 2011, #02; Mon, 7)
From: Junio C Hamano @ 2011-02-08 0:55 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'.
--------------------------------------------------
[New Topics]
* pw/p4 (2011-02-05) 8 commits
- git-p4: support clone --bare
- git-p4: decode p4 wildcard characters
- git-p4: better message for "git-p4 sync" when not cloned
- git-p4: reinterpret confusing p4 message
- git-p4: accommodate new move/delete type in p4
- git-p4: add missing newline in initial import message
- git-p4: fix key error for p4 problem
- git-p4: test script
Will be re-rolled after collecting comments (Petw Wyckoff, 2011-02-07).
--------------------------------------------------
[Stalled]
* nd/index-doc (2010-09-06) 1 commit
- doc: technical details about the index file format
Half-written but it is a good start. I may need to give some help in
describing more recent index extensions.
* cb/ignored-paths-are-precious (2010-08-21) 1 commit
- checkout/merge: optionally fail operation when ignored files need to be overwritten
This needs tests; also we know of longstanding bugs in related area that
needs to be addressed---they do not have to be part of this series but
their reproduction recipe would belong to the test script for this topic.
It would hurt users to make the new feature on by default, especially the
ones with subdirectories that come and go.
* jk/tag-contains (2010-07-05) 4 commits
- Why is "git tag --contains" so slow?
- default core.clockskew variable to one day
- limit "contains" traversals based on commit timestamp
- tag: speed up --contains calculation
The idea of the bottom one is probably Ok, except that the use of object
flags needs to be rethought, or at least the helper needs to be moved to
builtin/tag.c to make it clear that it should not be used outside the
current usage context.
* jc/rename-degrade-cc-to-c (2011-01-06) 3 commits
- diffcore-rename: fall back to -C when -C -C busts the rename limit
- diffcore-rename: record filepair for rename src
- diffcore-rename: refactor "too many candidates" logic
IIRC, this was a weather-baloon "if you wanted to, this may be how you
would do it" without test updates. People who care need to help moving
things forward.
* jc/rerere-remaining (2011-01-06) 1 commit
- rerere "remaining"
Just a handful of weatherballoon patches without proper tests, in response
to feature/minor fix requests.
* ab/p4 (2011-01-11) 1 commit
- git-p4: correct indenting and formatting
Lacks sign-off but is trivial.
* tr/maint-branch-no-track-head (2010-12-14) 1 commit
- branch: do not attempt to track HEAD implicitly
Probably needs a re-roll to exclude either (1) any ref outside the
hierarchies for branches (i.e. refs/{heads,remotes}/), or (2) only refs
outside refs/ hierarchies (e.g. HEAD, ORIG_HEAD, ...). The latter feels
safer and saner.
* mz/rebase (2010-12-28) 31 commits
- rebase -i: remove unnecessary state rebase-root
- rebase -i: don't read unused variable preserve_merges
- git-rebase--am: remove unnecessary --3way option
- rebase -m: don't print exit code 2 when merge fails
- rebase -m: remember allow_rerere_autoupdate option
- rebase: remember strategy and strategy options
- rebase: remember verbose option
- rebase: extract code for writing basic state
- rebase: factor out sub command handling
- rebase: make -v a tiny bit more verbose
- rebase -i: align variable names
- rebase: show consistent conflict resolution hint
- rebase: extract am code to new source file
- rebase: extract merge code to new source file
- rebase: remove $branch as synonym for $orig_head
- rebase -i: support --stat
- rebase: factor out call to pre-rebase hook
- rebase: factor out clean work tree check
- rebase: factor out reference parsing
- rebase: reorder validation steps
- rebase -i: remove now unnecessary directory checks
- rebase: factor out command line option processing
- rebase: align variable content
- rebase: align variable names
- rebase: stricter check of standalone sub command
- rebase: act on command line outside parsing loop
- rebase: improve detection of rebase in progress
- rebase: remove unused rebase state 'prev_head'
- rebase: read state outside loop
- rebase: refactor reading of state
- rebase: clearer names for directory variables
Re-roll posted, but I haven't picked it up yet.
* ab/i18n (2010-10-07) 161 commits
- po/de.po: complete German translation
- po/sv.po: add Swedish translation
- gettextize: git-bisect bisect_next_check "You need to" message
- gettextize: git-bisect [Y/n] messages
- gettextize: git-bisect bisect_replay + $1 messages
- gettextize: git-bisect bisect_reset + $1 messages
- gettextize: git-bisect bisect_run + $@ messages
- gettextize: git-bisect die + eval_gettext messages
- gettextize: git-bisect die + gettext messages
- gettextize: git-bisect echo + eval_gettext message
- gettextize: git-bisect echo + gettext messages
- gettextize: git-bisect gettext + echo message
- gettextize: git-bisect add git-sh-i18n
- gettextize: git-stash drop_stash say/die messages
- gettextize: git-stash "unknown option" message
- gettextize: git-stash die + eval_gettext $1 messages
- gettextize: git-stash die + eval_gettext $* messages
- gettextize: git-stash die + eval_gettext messages
- gettextize: git-stash die + gettext messages
- gettextize: git-stash say + gettext messages
- gettextize: git-stash echo + gettext message
- gettextize: git-stash add git-sh-i18n
- gettextize: git-submodule "blob" and "submodule" messages
- gettextize: git-submodule "path not initialized" message
- gettextize: git-submodule "[...] path is ignored" message
- gettextize: git-submodule "Entering [...]" message
- gettextize: git-submodule $errmsg messages
- gettextize: git-submodule "Submodule change[...]" messages
- gettextize: git-submodule "cached cannot be used" message
- gettextize: git-submodule $update_module say + die messages
- gettextize: git-submodule die + eval_gettext messages
- gettextize: git-submodule say + eval_gettext messages
- gettextize: git-submodule echo + eval_gettext messages
- gettextize: git-submodule add git-sh-i18n
- gettextize: git-pull "rebase against" / "merge with" messages
- gettextize: git-pull "[...] not currently on a branch" message
- gettextize: git-pull "You asked to pull" message
- gettextize: git-pull split up "no candidate" message
- gettextize: git-pull eval_gettext + warning message
- gettextize: git-pull eval_gettext + die message
- gettextize: git-pull die messages
- gettextize: git-pull add git-sh-i18n
- gettext docs: add "Testing marked strings" section to po/README
- gettext docs: the Git::I18N Perl interface
- gettext docs: the git-sh-i18n.sh Shell interface
- gettext docs: the gettext.h C interface
- gettext docs: add "Marking strings for translation" section in po/README
- gettext docs: add a "Testing your changes" section to po/README
- po/pl.po: add Polish translation
- po/hi.po: add Hindi Translation
- po/en_GB.po: add British English translation
- po/de.po: add German translation
- Makefile: only add gettext tests on XGETTEXT_INCLUDE_TESTS=YesPlease
- gettext docs: add po/README file documenting Git's gettext
- gettextize: git-am printf(1) message to eval_gettext
- gettextize: git-am core say messages
- gettextize: git-am "Apply?" message
- gettextize: git-am clean_abort messages
- gettextize: git-am cannot_fallback messages
- gettextize: git-am die messages
- gettextize: git-am eval_gettext messages
- gettextize: git-am multi-line getttext $msg; echo
- gettextize: git-am one-line gettext $msg; echo
- gettextize: git-am add git-sh-i18n
- gettext tests: add GETTEXT_POISON tests for shell scripts
- gettext tests: add GETTEXT_POISON support for shell scripts
- Makefile: MSGFMT="msgfmt --check" under GNU_GETTEXT
- Makefile: add GNU_GETTEXT, set when we expect GNU gettext
- gettextize: git-shortlog basic messages
- gettextize: git-revert split up "could not revert/apply" message
- gettextize: git-revert literal "me" messages
- gettextize: git-revert "Your local changes" message
- gettextize: git-revert basic messages
- gettextize: git-notes "Refusing to %s notes in %s" message
- gettextize: git-notes GIT_NOTES_REWRITE_MODE error message
- gettextize: git-notes basic commands
- gettextize: git-gc "Auto packing the repository" message
- gettextize: git-gc basic messages
- gettextize: git-describe basic messages
- gettextize: git-clean clean.requireForce messages
- gettextize: git-clean basic messages
- gettextize: git-bundle basic messages
- gettextize: git-archive basic messages
- gettextize: git-status "renamed: " message
- gettextize: git-status "Initial commit" message
- gettextize: git-status "Changes to be committed" message
- gettextize: git-status shortstatus messages
- gettextize: git-status "nothing to commit" messages
- gettextize: git-status basic messages
- gettextize: git-push "prevent you from losing" message
- gettextize: git-push basic messages
- gettextize: git-tag tag_template message
- gettextize: git-tag basic messages
- gettextize: git-reset "Unstaged changes after reset" message
- gettextize: git-reset reset_type_names messages
- gettextize: git-reset basic messages
- gettextize: git-rm basic messages
- gettextize: git-mv "bad" messages
- gettextize: git-mv basic messages
- gettextize: git-merge "Wonderful" message
- gettextize: git-merge "You have not concluded your merge" messages
- gettextize: git-merge "Updating %s..%s" message
- gettextize: git-merge basic messages
- gettextize: git-log "--OPT does not make sense" messages
- gettextize: git-log basic messages
- gettextize: git-grep "--open-files-in-pager" message
- gettextize: git-grep basic messages
- gettextize: git-fetch split up "(non-fast-forward)" message
- gettextize: git-fetch update_local_ref messages
- gettextize: git-fetch formatting messages
- gettextize: git-fetch basic messages
- gettextize: git-diff basic messages
- gettextize: git-commit advice messages
- gettextize: git-commit "enter the commit message" message
- gettextize: git-commit print_summary messages
- gettextize: git-commit formatting messages
- gettextize: git-commit "middle of a merge" message
- gettextize: git-commit basic messages
- gettextize: git-checkout "Switched to a .. branch" message
- gettextize: git-checkout "HEAD is now at" message
- gettextize: git-checkout describe_detached_head messages
- gettextize: git-checkout: our/their version message
- gettextize: git-checkout basic messages
- gettextize: git-branch "(no branch)" message
- gettextize: git-branch "git branch -v" messages
- gettextize: git-branch "Deleted branch [...]" message
- gettextize: git-branch "remote branch '%s' not found" message
- gettextize: git-branch basic messages
- gettextize: git-add refresh_index message
- gettextize: git-add "remove '%s'" message
- gettextize: git-add "pathspec [...] did not match" message
- gettextize: git-add "Use -f if you really want" message
- gettextize: git-add "no files added" message
- gettextize: git-add basic messages
- gettextize: git-clone "Cloning into" message
- gettextize: git-clone basic messages
- gettext tests: test message re-encoding under C
- po/is.po: add Icelandic translation
- gettext tests: mark a test message as not needing translation
- gettext tests: test re-encoding with a UTF-8 msgid under Shell
- gettext tests: test message re-encoding under Shell
- gettext tests: add detection for is_IS.ISO-8859-1 locale
- gettext tests: test if $VERSION exists before using it
- gettextize: git-init "Initialized [...] repository" message
- gettextize: git-init basic messages
- gettext tests: skip lib-gettext.sh tests under GETTEXT_POISON
- gettext tests: add GETTEXT_POISON=YesPlease Makefile parameter
- gettext.c: use libcharset.h instead of langinfo.h when available
- gettext.c: work around us not using setlocale(LC_CTYPE, "")
- builtin.h: Include gettext.h
- Makefile: use variables and shorter lines for xgettext
- Makefile: tell xgettext(1) that our source is in UTF-8
- Makefile: provide a --msgid-bugs-address to xgettext(1)
- Makefile: A variable for options used by xgettext(1) calls
- gettext tests: locate i18n lib&data correctly under --valgrind
- gettext: setlocale(LC_CTYPE, "") breaks Git's C function assumptions
- gettext tests: rename test to work around GNU gettext bug
- gettext: add infrastructure for translating Git with gettext
- builtin: use builtin.h for all builtin commands
- tests: use test_cmp instead of piping to diff(1)
- t7004-tag.sh: re-arrange git tag comment for clarity
It is getting ridiculously painful to keep re-resolving the conflicts with
other topics in flight, even with the help with rerere.
Needs a bit more minor work to get the basic code structure right.
--------------------------------------------------
[Cooking]
* hv/mingw-fs-funnies (2011-02-07) 5 commits
- mingw_rmdir: set errno=ENOTEMPTY when appropriate
- mingw: add fallback for rmdir in case directory is in use
- mingw: make failures to unlink or move raise a question
- mingw: work around irregular failures of unlink on windows
- mingw: move unlink wrapper to mingw.c
Rerolled and seems ready to move forward. Will merge to 'next'.
* nd/struct-pathspec (2011-01-31) 22 commits
- t6004: add pathspec globbing test for log family
- t7810: overlapping pathspecs and depth limit
- grep: drop pathspec_matches() in favor of tree_entry_interesting()
- grep: use writable strbuf from caller for grep_tree()
- grep: use match_pathspec_depth() for cache/worktree grepping
- grep: convert to use struct pathspec
- Convert ce_path_match() to use match_pathspec_depth()
- Convert ce_path_match() to use struct pathspec
- struct rev_info: convert prune_data to struct pathspec
- pathspec: add match_pathspec_depth()
- tree_entry_interesting(): optimize wildcard matching when base is matched
- tree_entry_interesting(): support wildcard matching
- tree_entry_interesting(): fix depth limit with overlapping pathspecs
- tree_entry_interesting(): support depth limit
- tree_entry_interesting(): refactor into separate smaller functions
- diff-tree: convert base+baselen to writable strbuf
- glossary: define pathspec
- Move tree_entry_interesting() to tree-walk.c and export it
- tree_entry_interesting(): remove dependency on struct diff_options
- Convert struct diff_options to use struct pathspec
- diff-no-index: use diff_tree_setup_paths()
- Add struct pathspec
(this branch is used by en/object-list-with-pathspec.)
* en/object-list-with-pathspec (2010-09-20) 2 commits
- Add testcases showing how pathspecs are handled with rev-list --objects
- Make rev-list --objects work together with pathspecs
(this branch uses nd/struct-pathspec.)
The above two were rebased on 1.7.4; will merge to 'next'.
* tr/merge-unborn-clobber (2010-08-22) 1 commit
(merged to 'next' on 2011-02-03 at ccfc03d)
+ Exhibit merge bug that clobbers index&WT
* jc/unpack-trees (2010-12-22) 2 commits
(merged to 'next' on 2011-02-03 at 5bd48f8)
+ unpack_trees(): skip trees that are the same in all input
+ unpack-trees.c: cosmetic fix
* jc/fsck-fixes (2011-01-26) 2 commits
(merged to 'next' on 2011-02-03 at 98e1c63)
+ fsck: do not give up too early in fsck_dir()
+ fsck: drop unused parameter from traverse_one_object()
* tr/diff-words-test (2011-01-18) 4 commits
(merged to 'next' on 2011-02-03 at d346665)
+ t4034 (diff --word-diff): add a minimum Perl drier test vector
+ t4034 (diff --word-diff): style suggestions
+ userdiff: simplify word-diff safeguard
+ t4034: bulk verify builtin word regex sanity
I thought this was Ok; further comments, anybody?
* rr/fi-import-marks-if-exists (2011-01-15) 1 commit
(merged to 'next' on 2011-02-03 at 8c9d4ce)
+ fast-import: Introduce --import-marks-if-exists
Looked reasonable.
* jn/unpack-lstat-failure-report (2011-01-12) 2 commits
(merged to 'next' on 2011-02-03 at 76586d2)
+ unpack-trees: handle lstat failure for existing file
+ unpack-trees: handle lstat failure for existing directory
Looked reasonable.
* ef/alias-via-run-command (2011-01-07) 1 commit
(merged to 'next' on 2011-02-03 at 4ce47ce)
+ alias: use run_command api to execute aliases
Will merge to 'master' shortly.
* uk/checkout-ambiguous-ref (2011-02-07) 2 commits
- NEEDS TESTS: commit: document --detach synonym for "git checkout foo^{commit}"
(merged to 'next' on 2011-02-03 at 9044724)
+ checkout: fix bug with ambiguous refs
Will merge the first one to 'master' shortly.
* cb/setup (2010-12-27) 1 commit
(merged to 'next' on 2011-02-03 at 073980f)
+ setup: translate symlinks in filename when using absolute paths
Will merge to 'master' shortly.
* ae/better-template-failure-report (2010-12-18) 1 commit
(merged to 'next' on 2011-02-03 at 3b269c9)
+ Improve error messages when temporary file creation fails
Will merge to 'master' shortly.
* jn/cherry-pick-strategy-option (2010-12-10) 1 commit
(merged to 'next' on 2011-02-03 at 1c10f16)
+ cherry-pick/revert: add support for -X/--strategy-option
Will merge to 'master' shortly.
^ permalink raw reply
* Re: [PATCH/WIP] checkout: introduce --detach synonym for "git checkout foo^{commit}"
From: Jonathan Nieder @ 2011-02-08 0:55 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Sverre Rabbelier, Martin von Zweigbergk, git
In-Reply-To: <20110208005238.GB24340@elie>
Jonathan Nieder wrote:
> Jeff King wrote:
>
>> Jonathan, do you want to roll all of these up into a single patch?
>
> Okay, here it is.
Ah, should have mentioned: this applies on top of a merge of
en/and-cascade-tests~25 (aka v1.7.4-rc0~65^2~19, test-lib: make
test_expect_code a test command, 2010-10-03) and
uk/checkout-ambiguous-ref.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-08 0:59 UTC (permalink / raw)
To: Jeff King
Cc: git, Matthieu Moy, Dmitry Potapov, Junio C Hamano,
Sverre Rabbelier, Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <20110207201912.GB13461@sigill.intra.peff.net>
On Monday 07 February 2011, Jeff King wrote:
> On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:
> > This is the same technique we use when talking about branch names: On
> > this mailing list, nobody is confused when I refer to 'maint',
> > 'master', 'next' and 'pu'. Still, in our own work repos (at least in
> > mine), these branches are actually called "refs/remotes/origin/<name>"
> > (commonly referred to by their shorthands "origin/<name>"). Here we
> > are, juggling the same kind of namespaces that I propose for tags, and
> > it seems to work well without causing much confusion.
>
> Just playing devil's advocate for a moment: isn't this namespace
> distinction one of the more confusing things in git for new users? That
> is, I have seen new-ish git users say "OK, so I cloned from upstream.
> How come I can't say "git log maint" now?" Or it used to be "how come I
> can't "git checkout maint" now?" The latter is now handled by some very
> specific magic in "git checkout", but in general ref lookup does not
> automagically look in remotes namespaces, and it has caused some
> confusion.
>
> So here we are introducing more distinction between project-wide names
> and per-remote names. I absolutely think it's the right thing to do from
> a "keep it simple, orthogonal, and distributed" perspective. But we also
> need to recognize we are making some common use cases more confusing. In
> the case of remote-tracking branches, we ended up adding some porcelain
> features to make common actions (like checking out a local branch from a
> remote) more seamless. But there is still some confusion among new
> users.
>
> I'm sort of rambling as I'm not quite sure yet what this means for the
> tags proposal, but a few questions I think are important to consider
> are:
>
> 1. Where have we succeeded and where have we failed with making
> separate-remotes / tracking branches seamless to the user (as
> opposed to something like a system where
> fetching from upstream fetches straight into your master branch
> (which has its own problems, but would be conceptually very
> simple)? Do those failures apply in this case, and if so how can we
> do better?
>
> 2. Can we apply new ideas for handling separate-remote tags to the
> branches case? Obviously one big proposal is searching in the
> per-remote tag namespace for refs. Should we be doing the same with
> heads?
I pretty much completely agree with your train of thought.
First, although the separate-remotes may at first be confusing to newbies
coming from a centralized VCS, I don't think this is the _main_ source of
confusion. And, as you imply, we cannot eliminate this kind of conceptual
confusion in any case, without violating core DVCS principles (like Bazaar
does in its "centralized workflow"). The best way to address this is, as you
say, by keeping it "simple, orthogonal, and distributed" (and try very hard
to keep the common use cases minimally affected).
We should instead look at what other (and preferrable fixable) sources of
confusion we have in this area. Answering Git questions from colleagues at
$dayjob, they often describe how they tried to accomplish something in Git,
and I sometimes find myself giving a reply of the following form: "Yes, what
you tried does make sense from your POV, but in this situation Git actually
does this other thing instead, so instead you have to do ...". I don't like
giving answers like this, because I get this nagging feeling that the
problem is Git's fault, and not the user's. So, to enumerate some of these
inconsistencies (I'm sure there are more that I cannot recall, right now):
- Lack of consistency in the ref namespace (refs/remotes/$remote/* vs.
refs/tags/*). Also not clear from the current layout where to add new types
of refs (e.g. notes, replace). My proposal tries to address this issue.
- Lack of consistency in which fetch refspecs must be listed in the
configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal
tries to address this as well.
- Lack of consistency in porcelain interfaces. Some of these have been fixed
in recent Git version, but some are yet to be fixed: E.g. some find the use
of FETCH_HEAD confusing (when does fetch update the remote refs, and when
does it update FETCH_HEAD instead?). Others (myself included) wonder why
'git push' by default updates remote branches with matching names, while
'git pull' relies on the explicitly configured upstreams to update the local
refs. (FWIW, I've mitigated this last complaint insisting that all users at
$dayjob run "git config --global push.default tracking" immediately after
installing Git.) There are other UI inconsistencies too that escape me ATM.
When it comes to your second question, I believe it's definitely worth
looking closer at whether we can exploit unambiguity across namespaces for
all types of refs (not just tags). I expect there are some non-trivial
issues down that road (some of these being discussed elsewhere in this
thread), but we may still end up with something better.
Thanks for the feedback! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: rebase planning: determining blobs changed by multiple branches
From: Marc Weber @ 2011-02-08 0:59 UTC (permalink / raw)
To: git
In-Reply-To: <iiq3kb$aiv$1@dough.gmane.org>
Hi Neal,
I'm not quite sure what you want to do?
rebase all branches on top of commit l so that they are up to date?
Why do you want to find common blobs?
If the same conflict happens you could use gitrere and reuse a conflict
resolution.
git ls-files --with $HASH
gives you a list of files
git diff --name-only
should give you a nice list of modified files.
So using the intersection of ls-files of branch and tip should give you
common files. Substracting changed files using --name-only should yield
the files which were not modified.
Maybe there are nicer solutions though.
Rebasing is always bad. Have you considered using top-git?
This way you can merge with tip and create the rebased patches using the
export function.
Marc Weber
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-08 1:06 UTC (permalink / raw)
To: Johan Herland
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102070429.05033.johan@herland.net>
On Mon, Feb 07, 2011 at 04:29:04AM +0100, Johan Herland wrote:
>
> As I understand your view (I do apologize if I somehow misrepresent it), you
> want Git to assume that the common practice of one semantic namespace is
> followed. Furthermore, you also want to enforce that practice where
> possible, while still improving the handling of the uncommon (but
> theoretically inevitable) case (warning and presumably guiding the user when
> a tag conflict occurs).
Yes, you are correct. I consider a single tag namespace as the common
case, but it should be possible to have more than one namespace for
those who needs that. I think our disagreement is due to the fact that
you believe that if someone added another remote, he or she wants
another namespace for tags, but I think it depends on whether you treat
different remotes as one project or different semi-related projects.
There is a fundamental difference between branches and tags is that
branches are often different (like each co-worker can publish each own
master that he or she tested), but tags should have same tags as long as
we work on the same project, otherwise it will lead to confusion.
>
> > 2. It complicates things for users (as Matthieu wrote above).
>
> I guess this depends on your POV. Fundamentally, I do NOT want to change how
> people refer to tags. I only want to provide them the possibility of doing
> so when ambiguity is present.
IMHO, there are two fundamentally two different use cases:
- one project with many remotes
- two (probably semi-related) projects in the same repo
In the first case, having two tags pointing to different commits is an
obvious mistake that should be fixed as soon as possible. I do not think
that different namespaces are necessary to fix that (or at least I do
not see how it helps), but my main concern was that resolution of a tag
conflict may be postponed (because they appear in different namespaces),
but that does not resolve the confusion and may only prolong it.
>
> > 3. git fetch cannot report a tag clash if it happens
>
> Yes it can: For each tag fetched from the remote, if resolving its shorthand
> name ("v1.7.4") results in ambiguity (i.e. there exists a conflicting tag
> elsewhere in this repo), then warn the user about this conflict, and explain
> how to refer to each tag candidate using the full ref name. Also explain how
> the user may resolve the ambiguity by creating a local tag
> ("refs/tags/v1.7.4") pointing to the preferred target.
It it is possible then I do not have any serious objection here...
> > So, IMHO, the proper solution should be ability to specify the desired
> > namespace for any remote repository, like this:
> >
> > remote.<name>.tagNameSpace = foo
>
> Interesting. I'm not sure what "foo" means in this context. Would I use it
> like this?:
>
> remote.origin.tagNameSpace = refs/tags
I was not sure about the specific when I wrote this, so I just put "foo",
but it could be something like you wrote above.
>
> (to place origin's tags in refs/tags/*)
>
> If so, what's the difference between this option, and using this?:
>
> remote.origin.fetch = refs/tags/*:refs/tags/*
I have not tried that, but I suspect that it will cause that all tags
will be fetched even if they are not belong to tracked branches, i.e.
"git fetch" will work as "git fetch -t". But maybe I am wrong here.
Dmitry
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-08 1:20 UTC (permalink / raw)
To: Bernhard R. Link
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre, Johan Herland
In-Reply-To: <20110207190551.GA25413@pcpool00.mathematik.uni-freiburg.de>
On Mon, Feb 07, 2011 at 08:05:51PM +0100, Bernhard R. Link wrote:
>
> So there are those "local tags", which are not to be shared with others.
> Does that mean an user should always have two repositories, one with
> those tags for themselves and one without those tags for each other?
Well, I believe that the best practice is that each developer has
his/her own private repo and there is also a "bare" repo to which
is used to share results with others. In this way, local tags are
stay only inside one's private repo.
If you need to fetch directly from someone working repository, you can
use "git fetch --no-tags", but obviously it is not an optimal solution
if you also need to fetch global tags from it, because you will have
to specify them explicitly.
> > > Granted, if we leave all tags in a single namespace, I can still work around
> > > this by manually futzing with the configured refspecs to create ad hoc
> > > namespaces. But I _really_ hate it when I'm forced to hack around the tool,
> > > because the tool thinks it "knows better".
> >
> > I believe that the right interface when the common case is simple, but
> > an uncommon case is still possible to handle. I don't think that
> > currently git meets this criterion, but making tag namespaces based on
> > the remote name strikes me as a really bad idea. Tags are attributes of
> > a project and not particular remote.
>
> Global tags are. Local tags are not.
Sure. I probably should have said that I'd consider only global tags in
the rest of my email, because local tags should not be normally visible
outside of one's repo.
> And even for global tags it can be interesting to see which remote has
> them, without having to manually look at all those remotes.
I am not sure why it should be interesting. I mean as long as you do
not have tag clashes, you should not need to know that. And if you
really need to know that, you can use "git ls-remote" to check actual
references.
>
> > IMHO, it is very confusing, especially for people whose script was
> > suddenly broken by those namespaces.
>
> Like it was when remotes where introduced?
How many people used git back then and how many people are using now?
Have you forgotten what happened when the dash was removed from git
commands? There was endless cry about breaking git, though all what
those people need to do is to add one directory to their PATH to have
git dash commands back.
So, what may be okay for a young and immature project (used by a small
group of enthusiasts) may be not okay for a tool on which many people
rely. Most people who use git now do not read ReleaseNotes. They just
install a ready package for their favorite distro and expect everything
to work as before.
So, I think any changes should be introduced as gradual as possible.
Dmitry
^ permalink raw reply
* Re: [PATCH] Support different branch layouts in git-p4
From: Pete Wyckoff @ 2011-02-08 1:22 UTC (permalink / raw)
To: Ian Wienand; +Cc: Tor Arvid Lund, git
In-Reply-To: <4D4F3738.7010603@vmware.com>
ianw@vmware.com wrote on Sun, 06 Feb 2011 16:05 -0800:
> I did consider this at first. My only issue is that it is a bit
> confusing to use the client spec for filtering (and in this case
> re-writing), but not for actually selecting the depots to clone, which
> I still need to replicate on the command line. However that is a much
> larger change.
>
> What do you think of this one?
>
> In this case, my client view is
>
> //depot/project/branch/... //client/branch/project/...
> //depot/project2/branch/... //client/branch/project2/...
>
> and my git directory layout ends up as
>
> branch/project/...
> branch/project2/...
We had such terrible p4 mappings too, before the last
rearrangement put us into a single-line view spec. I think
it would help others to include such support, though.
Back then, I hacked together similar code to deal with the
annoyance. My code was not pretty and not complete, either.
If you look at "p4 help views", they have lots of oddities
that in theory should be accounted for here. It doesn't
even mention the thing about quotes, but obviously that is
supported. Wildcards ... and * can appear multiple
times. And %%[1-9] can be used to reorder the path. Also the
order of lines matters, and "+" can be used to merge entries.
Whew.
In practice, I think you get most everything we care about. A
few comments below, beyond the bits that Tor Arvid caught.
-- Pete
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> index 04ce7e3..eb9620c 100755
> --- a/contrib/fast-import/git-p4
> +++ b/contrib/fast-import/git-p4
> @@ -878,6 +878,7 @@ class P4Sync(Command):
> self.cloneExclude = []
> self.useClientSpec = False
> self.clientSpecDirs = []
> + self.clientName = None
Unused.
> if gitConfig("git-p4.syncFromOrigin") == "false":
> self.syncWithOrigin = False
> @@ -910,6 +911,22 @@ class P4Sync(Command):
> return files
>
> def stripRepoPath(self, path, prefixes):
> + if self.useClientSpec:
> +
> + # if using the client spec, we use the output directory
> + # specified in the client. For example, a view
> + # //depot/foo/branch/... //client/branch/foo/...
> + # will end up putting all foo/branch files into
> + # branch/foo/
> + for val in self.clientSpecDirs:
> + if path.startswith(val[0]):
> + # replace the depot path with the client path
> + path = path.replace(val[0], val[1][1])
> + # now strip out the client (//client/...)
> + path = re.sub("^(//[^/]+/)", '', path)
> + # the rest is all path
> + return path
That's clever. Better than having to remember Client: and build
//client/ out of it. You could do this down in getClientSpec()
so that val[1] starts with the git-relative path.
> if self.keepRepoPath:
> prefixes = [re.sub("^(//[^/]+/).*", r'\1', prefixes[0])]
>
> @@ -1032,7 +1049,7 @@ class P4Sync(Command):
> includeFile = True
> for val in self.clientSpecDirs:
> if f['path'].startswith(val[0]):
> - if val[1] <= 0:
> + if val[1][0] <= 0:
> includeFile = False
> break
>
> @@ -1474,20 +1491,36 @@ class P4Sync(Command):
> temp = {}
> for entry in specList:
> for k,v in entry.iteritems():
> + if k.startswith("Client"):
> + self.clientName = v
Oh maybe here is where you thought you would need client, but
don't.
> if k.startswith("View"):
> if v.startswith('"'):
> start = 1
> else:
> start = 0
> index = v.find("...")
> +
> + # save the "client view"; i.e the RHS of the view
> + # line that tells the client where to put the
> + # files for this view.
> + cv = v[index+4:] # +4 to remove previous '... '
> + cv_index = cv.find("...")
> + cv=cv[:cv_index]
> +
> + # now save the view; +index means included, -index
> + # means it should be filtered out.
> v = v[start:index]
> if v.startswith("-"):
> v = v[1:]
> - temp[v] = -len(v)
> + include = -len(v)
> else:
> - temp[v] = len(v)
> + include = len(v)
> +
> + temp[v] = (include, cv)
> +
> self.clientSpecDirs = temp.items()
> - self.clientSpecDirs.sort( lambda x, y: abs( y[1] ) - abs( x[1] ) )
> + self.clientSpecDirs.sort( lambda x, y: abs( y[1][0] ) - abs( x[1][0] ) )
^ 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