* Re: RFC: Subprojects
From: Alexander Litvinov @ 2006-01-12 5:25 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Simon Richter, git
In-Reply-To: <46a038f90601112046u13d7075dsc2108111e2462152@mail.gmail.com>
On Thursday 12 January 2006 10:46, Martin Langhoff wrote:
> > I really miss this feature. This is the last stopper for moving from CVS
> > to git for out project.
>
> What about using nested checkouts? They work great with git as-is,
> just add an .gitignore file.
>
> As Linus points out, there are many good reasons why a top-level
> commit should _not_ commit the nested subproject. And once you are
> observing that rule, what's left then? git status and git diff <HEAD>
> can show an aggregate of top-level and nested subprojects, but that's
> ease-of-use -- not something only.
>
> What is your show stopper?
I would agree to make separate commits for each sub project.
1. I need to have ability to make tags, branches thru all subprojects.
2. Update (pull) sould update each subproject, it is hard to update them by
hands.
3. The need of some sort of checkout script (can be solved by storing this
script in base project, but it would be much nicer allow git fetch all
subprojects)
Nothing else I can imagine.
^ permalink raw reply
* Re: RFC: Subprojects
From: Martin Langhoff @ 2006-01-12 4:46 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Simon Richter, git
In-Reply-To: <200601120919.08354.lan@ac-sw.com>
On 1/12/06, Alexander Litvinov <lan@ac-sw.com> wrote:
> On Wednesday 11 January 2006 21:58, Simon Richter wrote:
> > Hello,
> >
> > one thing that I have been missing so far in all SCM systems apart from
> > CVS (and there it's just coincidence) is the ability to include a
> > project as part of a bigger project.
>
> I really miss this feature. This is the last stopper for moving from CVS to
> git for out project.
What about using nested checkouts? They work great with git as-is,
just add an .gitignore file.
As Linus points out, there are many good reasons why a top-level
commit should _not_ commit the nested subproject. And once you are
observing that rule, what's left then? git status and git diff <HEAD>
can show an aggregate of top-level and nested subprojects, but that's
ease-of-use -- not something only.
What is your show stopper?
cheers,
martin
^ permalink raw reply
* Re: RFC: Subprojects
From: Alexander Litvinov @ 2006-01-12 3:19 UTC (permalink / raw)
To: Simon Richter; +Cc: git
In-Reply-To: <43C52B1F.8020706@hogyros.de>
On Wednesday 11 January 2006 21:58, Simon Richter wrote:
> Hello,
>
> one thing that I have been missing so far in all SCM systems apart from
> CVS (and there it's just coincidence) is the ability to include a
> project as part of a bigger project.
I really miss this feature. This is the last stopper for moving from CVS to
git for out project.
^ permalink raw reply
* Re: merging initial part of a branch?
From: Junio C Hamano @ 2006-01-12 1:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060112005531.GB14599@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
>> I haven't tried this for some time, but I presume
>>
>> $ git pull linus tag v2.6.15
>>
>> would do what you want.
>
> Yep! Thanks. The only documentation I can find for this is a slightly
> obscure bit in the git-pull man page which lists this as a "short-cut"
> notation. What is it a shortcut for? Is it possible to specify an
> arbitrary commit in place of the "tag v2.6.15" somehow?
The phrase "short-hand" refers to "linus" in the above example.
I.e. the name of the file in $GIT_DIR/remotes that records the
URL (among other things).
You can only say either "branchname" or "tag tagname" for pull,
because of the way underlying git native protocol works (it may
not be too hard to extend it, but I haven't looked into it nor
particularly interested in looking into it at the moment).
^ permalink raw reply
* Re: merging initial part of a branch?
From: J. Bruce Fields @ 2006-01-12 1:13 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git
In-Reply-To: <43C5A9F4.1040604@op5.se>
On Thu, Jan 12, 2006 at 01:59:32AM +0100, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> >Andreas Ericsson <ae@op5.se> writes:
> >>$ git format-patch -m -k v2.6.14..v2.6.15 --stdout > mega-mbox-patch
> >>$ git checkout our-own-branch
> >>$ git am -3 -k mega-mbox-patch
> >>
> >>That'll take some time though, so be sure to have a six-pack or two handy.
> >
> >
> >I do not think that should be done. You will create an
> >alternate history that way, not the true v2.6.15 history.
> >
>
> I took their request to mean that they already have patches of their own
> in that, so they'll never have v2.6.15 vanilla history anyway.
If I have some local changes, and do a git pull linus tag v2.6.15, I
find that the final commit in the result is a merge commit whose first
parent refers to my last commit, and whose second commit points to
Linus's v2.6.15 commit from the "vanilla history". Which is what I
think you really need for a history that makes sense and that can be
used by future merges.
--b.
^ permalink raw reply
* Re: merging initial part of a branch?
From: Andreas Ericsson @ 2006-01-12 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <7vu0cai98f.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Junio C Hamano wrote:
>>
>>
>>>I haven't tried this for some time, but I presume
>>> $ git pull linus tag v2.6.15
>>>would do what you want.
>>
>>If it doesn't you might be able to do
>>
>>$ git format-patch -m -k v2.6.14..v2.6.15 --stdout > mega-mbox-patch
>>$ git checkout our-own-branch
>>$ git am -3 -k mega-mbox-patch
>>
>>That'll take some time though, so be sure to have a six-pack or two handy.
>
>
> I do not think that should be done. You will create an
> alternate history that way, not the true v2.6.15 history.
>
I took their request to mean that they already have patches of their own
in that, so they'll never have v2.6.15 vanilla history anyway.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: merging initial part of a branch?
From: J. Bruce Fields @ 2006-01-12 0:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vek3epbs9.fsf@assigned-by-dhcp.cox.net>
On Wed, Jan 11, 2006 at 03:47:34PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
> > External kernel projects sometimes work only against major
> > releases--it's easier for their users/testers to find a major release
> > than a random git version, and at least in the early prototype stage, it
> > isn't critical to be working on the tip all the time.
> >
> > Is there a simple way to say, for example, "merge in all the upstream
> > changes up to v2.6.15"?
>
> I haven't tried this for some time, but I presume
>
> $ git pull linus tag v2.6.15
>
> would do what you want.
Yep! Thanks. The only documentation I can find for this is a slightly
obscure bit in the git-pull man page which lists this as a "short-cut"
notation. What is it a shortcut for? Is it possible to specify an
arbitrary commit in place of the "tag v2.6.15" somehow?
--b.
^ permalink raw reply
* Re: merging initial part of a branch?
From: Junio C Hamano @ 2006-01-12 0:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, J. Bruce Fields
In-Reply-To: <43C59FB6.20803@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Junio C Hamano wrote:
>
>> I haven't tried this for some time, but I presume
>> $ git pull linus tag v2.6.15
>> would do what you want.
>
> If it doesn't you might be able to do
>
> $ git format-patch -m -k v2.6.14..v2.6.15 --stdout > mega-mbox-patch
> $ git checkout our-own-branch
> $ git am -3 -k mega-mbox-patch
>
> That'll take some time though, so be sure to have a six-pack or two handy.
I do not think that should be done. You will create an
alternate history that way, not the true v2.6.15 history.
^ permalink raw reply
* Re: merging initial part of a branch?
From: Andreas Ericsson @ 2006-01-12 0:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, Git Mailing List
In-Reply-To: <7vek3epbs9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
>
>>External kernel projects sometimes work only against major
>>releases--it's easier for their users/testers to find a major release
>>than a random git version, and at least in the early prototype stage, it
>>isn't critical to be working on the tip all the time.
>>
>>Is there a simple way to say, for example, "merge in all the upstream
>>changes up to v2.6.15"?
>
>
> I haven't tried this for some time, but I presume
>
> $ git pull linus tag v2.6.15
>
> would do what you want.
>
If it doesn't you might be able to do
$ git format-patch -m -k v2.6.14..v2.6.15 --stdout > mega-mbox-patch
$ git checkout our-own-branch
$ git am -3 -k mega-mbox-patch
That'll take some time though, so be sure to have a six-pack or two handy.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] (Updated) Exec git programs without using PATH.
From: Andreas Ericsson @ 2006-01-12 0:11 UTC (permalink / raw)
To: git
In-Reply-To: <7vk6d6qwmn.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Michal Ostrowski <mostrows@watson.ibm.com> writes:
>
>
>>I briefly tried to consider if I could hide the various fork()+exec()
>>sequences behind something like the run_command*() interfaces (which
>>would move us down the direction of something "spawn()"-like). I found
>>that there's a lot of variation between the various paths in terms of
>>what happens between fork() and exec() on the various paths that does
>>not lend itself to such consolidation.
>>
>>I'd love to be convinced otherwise.
>
>
> Unfortunately I am with Michal on this one (both "eh, I do not
> think that is feasible" and "I'd love to be...").
>
> The run_command*() interfaces and its users were the best I
> could come up with as far as such consolidations could go when I
> did it.
>
Not being entirely knowledgeable on what spawn() actually does and how
its semantics differ from fork() and exec*() style API's (Google was
depressingly unhelpful and wikipedia dredged up froglings...), I've got
a decent "clone-lots-of-processes-and-multiplex-between-them" kind of
library lying around. Would it be of any use?
From the prototypes I've seen on spawn it doesn't seem to be much more
than a fork() + execve(), either closing or dup2'ing all the
file-descriptors, so I don't understand why that couldn't be implemented
for git. Some pointers, anyone?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] show-branch: make --topo-order noop and default.
From: Junio C Hamano @ 2006-01-12 0:05 UTC (permalink / raw)
To: git
It really does not make sense not doing --topo-order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Currently in "pu".
show-branch.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
d899f2bfc64b44e776a87f9c8fdd6abfe819690b
diff --git a/show-branch.c b/show-branch.c
index 9f7e188..f296a87 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -544,7 +544,6 @@ int main(int ac, char **av)
int no_name = 0;
int sha1_name = 0;
int shown_merge_point = 0;
- int topo_order = 0;
int no_current_branch = 0;
git_config(git_show_branch_config);
@@ -585,7 +584,8 @@ int main(int ac, char **av)
else if (!strcmp(arg, "--independent"))
independent = 1;
else if (!strcmp(arg, "--topo-order"))
- topo_order = 1;
+ /* noop */
+ ;
else
usage(show_branch_usage);
ac--; av++;
@@ -707,8 +707,7 @@ int main(int ac, char **av)
exit(0);
/* Sort topologically */
- if (topo_order)
- sort_in_topological_order(&seen);
+ sort_in_topological_order(&seen);
/* Give names to commits */
if (!sha1_name && !no_name)
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH] show-branch: always include the current branch.
From: Junio C Hamano @ 2006-01-12 0:05 UTC (permalink / raw)
To: git
By default, the command includes the current branch to the list
of revs to be shown, even when it is not given on the command
line. A new flag, --no-current, disables it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Currently in "pu".
Documentation/git-show-branch.txt | 13 ++++++++--
show-branch.c | 49 ++++++++++++++++++++++++++-----------
2 files changed, 46 insertions(+), 16 deletions(-)
95a7c01ab91b71f72b6d5d60da7659b2b625fa6d
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index 9cc44a8..90e2a5c 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -7,7 +7,10 @@ git-show-branch - Show branches and thei
SYNOPSIS
--------
-'git-show-branch [--all] [--heads] [--tags] [--topo-order] [--more=<n> | --list | --independent | --merge-base] [--no-name | --sha1-name] [<rev> | <glob>]...'
+[verse]
+git-show-branch [--all] [--heads] [--tags] [--topo-order] [--no-current]
+ [--more=<n> | --list | --independent | --merge-base]
+ [--no-name | --sha1-name] [<rev> | <glob>]...
DESCRIPTION
-----------
@@ -38,6 +41,11 @@ OPTIONS
Show all refs under $GIT_DIR/refs, $GIT_DIR/refs/heads,
and $GIT_DIR/refs/tags, respectively.
+--no-current::
+ By default, the command includes the current branch to
+ the list of revs to be shown even when it is not given
+ on the command line. This flag disables it.
+
--topo-order::
By default, the branches and their commits are shown in
reverse chronological order. This option makes them
@@ -133,7 +141,8 @@ it, having the following in the configur
------------
With this,`git show-branch` without extra parameters would show
-only the primary branches.
+only the primary branches. In addition, if you happen to be on
+your topic branch, it is shown as well.
diff --git a/show-branch.c b/show-branch.c
index f43c406..9f7e188 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -5,7 +5,7 @@
#include "refs.h"
static const char show_branch_usage[] =
-"git-show-branch [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [<refs>...]";
+"git-show-branch [--no-current] [--all] [--heads] [--tags] [--topo-order] [--more=count | --list | --independent | --merge-base ] [<refs>...]";
static int default_num = 0;
static int default_alloc = 0;
@@ -435,12 +435,12 @@ static void snarf_refs(int head, int tag
}
}
-static int rev_is_head(char *head_path, int headlen,
- char *name,
+static int rev_is_head(char *head_path, int headlen, char *name,
unsigned char *head_sha1, unsigned char *sha1)
{
int namelen;
- if ((!head_path[0]) || memcmp(head_sha1, sha1, 20))
+ if ((!head_path[0]) ||
+ (head_sha1 && sha1 && memcmp(head_sha1, sha1, 20)))
return 0;
namelen = strlen(name);
if ((headlen < namelen) ||
@@ -545,6 +545,7 @@ int main(int ac, char **av)
int sha1_name = 0;
int shown_merge_point = 0;
int topo_order = 0;
+ int no_current_branch = 0;
git_config(git_show_branch_config);
setup_git_directory();
@@ -573,6 +574,8 @@ int main(int ac, char **av)
extra = -1;
else if (!strcmp(arg, "--no-name"))
no_name = 1;
+ else if (!strcmp(arg, "--no-current"))
+ no_current_branch = 1;
else if (!strcmp(arg, "--sha1-name"))
sha1_name = 1;
else if (!strncmp(arg, "--more=", 7))
@@ -604,6 +607,34 @@ int main(int ac, char **av)
ac--; av++;
}
+ head_path_p = resolve_ref(git_path("HEAD"), head_sha1, 1);
+ if (head_path_p) {
+ head_path_len = strlen(head_path_p);
+ memcpy(head_path, head_path_p, head_path_len + 1);
+ }
+ else {
+ head_path_len = 0;
+ head_path[0] = 0;
+ }
+
+ if (!merge_base && !no_current_branch && head_path_p) {
+ int has_head = 0;
+ for (i = 0; !has_head && i < ref_name_cnt; i++) {
+ /* We are only interested in adding the branch
+ * HEAD points at.
+ */
+ if (rev_is_head(head_path,
+ head_path_len,
+ ref_name[i],
+ head_sha1, NULL))
+ has_head++;
+ }
+ if (!has_head) {
+ int pfxlen = strlen(git_path("refs/heads/"));
+ append_one_rev(head_path + pfxlen);
+ }
+ }
+
if (!ref_name_cnt) {
fprintf(stderr, "No revs to be shown.\n");
exit(0);
@@ -639,16 +670,6 @@ int main(int ac, char **av)
if (0 <= extra)
join_revs(&list, &seen, num_rev, extra);
- head_path_p = resolve_ref(git_path("HEAD"), head_sha1, 1);
- if (head_path_p) {
- head_path_len = strlen(head_path_p);
- memcpy(head_path, head_path_p, head_path_len + 1);
- }
- else {
- head_path_len = 0;
- head_path[0] = 0;
- }
-
if (merge_base)
return show_merge_base(seen, num_rev);
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH] show-branch: make the current branch stand out.
From: Junio C Hamano @ 2006-01-12 0:05 UTC (permalink / raw)
To: git
This changes the character used to mark the commits that is on the
branch from '+' to '*' for the current branch, to make it stand out.
When you have a handful branches with relatively long diversion, it
is easier to see which one is the current branch this way.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Currently in "pu".
Documentation/git-show-branch.txt | 6 ++-
Documentation/howto/revert-branch-rebase.txt | 24 +++++++-------
Documentation/tutorial.txt | 46 +++++++++++++-------------
show-branch.c | 5 ++-
t/t1200-tutorial.sh | 6 ++-
5 files changed, 45 insertions(+), 42 deletions(-)
825abb210cb5fd776a120589a1da41f6a06db191
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index 90e2a5c..a2b8eb9 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -103,7 +103,7 @@ and "mhf":
------------------------------------------------
$ git show-branch master fixes mhf
-! [master] Add 'git show-branch'.
+* [master] Add 'git show-branch'.
! [fixes] Introduce "reset type" flag to "git reset"
! [mhf] Allow "+remote:local" refspec to cause --force when fetching.
---
@@ -117,13 +117,13 @@ $ git show-branch master fixes mhf
+ [mhf~6] Retire git-parse-remote.
+ [mhf~7] Multi-head fetch.
+ [mhf~8] Start adding the $GIT_DIR/remotes/ support.
-+++ [master] Add 'git show-branch'.
+*++ [master] Add 'git show-branch'.
------------------------------------------------
These three branches all forked from a common commit, [master],
whose commit message is "Add 'git show-branch'. "fixes" branch
adds one commit 'Introduce "reset type"'. "mhf" branch has many
-other commits.
+other commits. The current branch is "master".
EXAMPLE
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
index 5a7e0cf..a83ce1c 100644
--- a/Documentation/howto/revert-branch-rebase.txt
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -32,16 +32,16 @@ merge introduced 5 commits or so:
------------------------------------------------
$ git show-branch --more=4 master master^2 | head
-! [master] Merge refs/heads/portable from http://www.cs.berkeley....
+* [master] Merge refs/heads/portable from http://www.cs.berkeley....
! [master^2] Replace C99 array initializers with code.
--
-+ [master] Merge refs/heads/portable from http://www.cs.berkeley....
-++ [master^2] Replace C99 array initializers with code.
-++ [master^2~1] Replace unsetenv() and setenv() with older putenv().
-++ [master^2~2] Include sys/time.h in daemon.c.
-++ [master^2~3] Fix ?: statements.
-++ [master^2~4] Replace zero-length array decls with [].
-+ [master~1] tutorial note about git branch
+* [master] Merge refs/heads/portable from http://www.cs.berkeley....
+*+ [master^2] Replace C99 array initializers with code.
+*+ [master^2~1] Replace unsetenv() and setenv() with older putenv().
+*+ [master^2~2] Include sys/time.h in daemon.c.
+*+ [master^2~3] Fix ?: statements.
+*+ [master^2~4] Replace zero-length array decls with [].
+* [master~1] tutorial note about git branch
------------------------------------------------
The '--more=4' above means "after we reach the merge base of refs,
@@ -193,8 +193,8 @@ $ git show-branch --more=1 master pu rc
+ [pu~4] Document "git cherry-pick" and "git revert"
+ [pu~5] Remove git-apply-patch-script.
+ [pu~6] Redo "revert" using three-way merge machinery.
- + [rc] Merge refs/heads/master from .
-+++ [master] Revert "Replace zero-length array decls with []."
- + [rc~1] Merge refs/heads/master from .
-+++ [master~1] Merge refs/heads/portable from http://www.cs.berkeley....
+ * [rc] Merge refs/heads/master from .
+++* [master] Revert "Replace zero-length array decls with []."
+ * [rc~1] Merge refs/heads/master from .
+++* [master~1] Merge refs/heads/portable from http://www.cs.berkeley....
------------------------------------------------
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index edd91cb..43a1975 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -968,8 +968,8 @@ $ git show-branch master mybranch
* [master] Merge work in mybranch
! [mybranch] Some work.
--
-+ [master] Merge work in mybranch
-++ [mybranch] Some work.
+* [master] Merge work in mybranch
+*+ [mybranch] Some work.
------------------------------------------------
The first two lines indicate that it is showing the two branches
@@ -1024,7 +1024,7 @@ $ git show-branch master mybranch
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
-++ [master] Merge work in mybranch
++* [master] Merge work in mybranch
------------------------------------------------
@@ -1199,9 +1199,9 @@ $ git show-branch --more=3 master mybran
! [master] Merge work in mybranch
* [mybranch] Merge work in mybranch
--
-++ [master] Merge work in mybranch
-++ [master^2] Some work.
-++ [master^] Some fun.
++* [master] Merge work in mybranch
++* [master^2] Some work.
++* [master^] Some fun.
------------
Remember, before running `git merge`, our `master` head was at
@@ -1223,8 +1223,8 @@ $ git show-branch
! [mybranch] Some work.
--
+ [mybranch] Some work.
-+ [master] Some fun.
-++ [mybranch^] New day.
+* [master] Some fun.
+*+ [mybranch^] New day.
------------
Now we are ready to experiment with the merge by hand.
@@ -1743,8 +1743,8 @@ $ git show-branch
+ [diff-fix] Fix rename detection.
+ [diff-fix~1] Better common substring algorithm.
+ [commit-fix] Fix commit message normalization.
- + [master] Release candidate #1
-+++ [diff-fix~2] Pretty-print messages.
+ * [master] Release candidate #1
+++* [diff-fix~2] Pretty-print messages.
------------
Both fixes are tested well, and at this point, you want to merge
@@ -1764,13 +1764,13 @@ $ git show-branch
! [diff-fix] Fix rename detection.
* [master] Merge fix in commit-fix
---
- + [master] Merge fix in commit-fix
-+ + [commit-fix] Fix commit message normalization.
- + [master~1] Merge fix in diff-fix
- ++ [diff-fix] Fix rename detection.
- ++ [diff-fix~1] Better common substring algorithm.
- + [master~2] Release candidate #1
-+++ [master~3] Pretty-print messages.
+ * [master] Merge fix in commit-fix
++ * [commit-fix] Fix commit message normalization.
+ * [master~1] Merge fix in diff-fix
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~2] Release candidate #1
+++* [master~3] Pretty-print messages.
------------
However, there is no particular reason to merge in one branch
@@ -1797,12 +1797,12 @@ $ git show-branch
! [diff-fix] Fix rename detection.
* [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
---
- + [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
-+ + [commit-fix] Fix commit message normalization.
- ++ [diff-fix] Fix rename detection.
- ++ [diff-fix~1] Better common substring algorithm.
- + [master~1] Release candidate #1
-+++ [master~2] Pretty-print messages.
+ * [master] Octopus merge of branches 'diff-fix' and 'commit-fix'
++ * [commit-fix] Fix commit message normalization.
+ +* [diff-fix] Fix rename detection.
+ +* [diff-fix~1] Better common substring algorithm.
+ * [master~1] Release candidate #1
+++* [master~2] Pretty-print messages.
------------
Note that you should not do Octopus because you can. An octopus
diff --git a/show-branch.c b/show-branch.c
index f296a87..03324aa 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -545,6 +545,7 @@ int main(int ac, char **av)
int sha1_name = 0;
int shown_merge_point = 0;
int no_current_branch = 0;
+ int head_at = -1;
git_config(git_show_branch_config);
setup_git_directory();
@@ -696,6 +697,8 @@ int main(int ac, char **av)
}
/* header lines never need name */
show_one_commit(rev[i], 1);
+ if (is_head)
+ head_at = i;
}
if (0 <= extra) {
for (i = 0; i < num_rev; i++)
@@ -725,7 +728,7 @@ int main(int ac, char **av)
if (1 < num_rev) {
for (i = 0; i < num_rev; i++)
putchar((this_flag & (1u << (i + REV_SHIFT)))
- ? '+' : ' ');
+ ? (i == head_at ? '*' : '+') : ' ');
putchar(' ');
}
show_one_commit(commit, no_name);
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index d7562e9..7879b49 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -118,8 +118,8 @@ cat > show-branch.expect << EOF
* [master] Merged "mybranch" changes.
! [mybranch] Some work.
--
-+ [master] Merged "mybranch" changes.
-++ [mybranch] Some work.
+* [master] Merged "mybranch" changes.
+*+ [mybranch] Some work.
EOF
git show-branch --topo-order master mybranch > show-branch.output
@@ -142,7 +142,7 @@ cat > show-branch2.expect << EOF
! [master] Merged "mybranch" changes.
* [mybranch] Merged "mybranch" changes.
--
-++ [master] Merged "mybranch" changes.
++* [master] Merged "mybranch" changes.
EOF
git show-branch --topo-order master mybranch > show-branch2.output
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH] Require packfiles to follow the naming convention (preparation).
From: Junio C Hamano @ 2006-01-12 0:05 UTC (permalink / raw)
To: git
Names of the packfiles will be required to be of the form
"pack-[0-9a-f]{40}.pack". This commit prepares a switch that I
can toggle to enforce the naming convention, but the switch is
currently toggled off.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Currently in "pu".
Documentation/git-convert-packs.txt | 2 -
Documentation/git.txt | 3 +
sha1_file.c | 51 ++++++++++++++++++++++
t/t5300-pack-object.sh | 81 +++++++++++++++++++----------------
4 files changed, 97 insertions(+), 40 deletions(-)
a8fe7257b8427d31cfcca0aa336335bb43689fc9
diff --git a/Documentation/git-convert-packs.txt b/Documentation/git-convert-packs.txt
index ba02641..ac82033 100644
--- a/Documentation/git-convert-packs.txt
+++ b/Documentation/git-convert-packs.txt
@@ -3,7 +3,7 @@ git-convert-packs(1)
NAME
----
-git-convert-packs - Renames packfiles created with pre 0.99.9 GIT
+git-convert-packs - Renames packfiles created with pre 0.99.9 GIT.
SYNOPSIS
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 92cfe0e..4ab07a4 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -350,6 +350,9 @@ gitlink:git-archimport[1]::
gitlink:git-convert-objects[1]::
Converts old-style git repository.
+gitlink:git-convert-packs[1]::
+ Renames packfiles created with pre 0.99.9 GIT.
+
gitlink:git-cvsimport[1]::
Salvage your data out of another SCM people love to hate.
diff --git a/sha1_file.c b/sha1_file.c
index 8bebbb2..22d56fc 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -346,6 +346,15 @@ static int pack_used_ctr;
static unsigned long pack_mapped;
struct packed_git *packed_git;
+/*
+ * 0: do not check, do not do anything.
+ * 1: check and warn, but do not reject.
+ * 2: check and reject if pack name is obsolete.
+ */
+#ifndef PACK_NAME_ENFORCEMENT_PHASE
+#define PACK_NAME_ENFORCEMENT_PHASE 0
+#endif
+
static int check_packed_git_idx(const char *path, unsigned long *idx_size_,
void **idx_map_)
{
@@ -357,6 +366,9 @@ static int check_packed_git_idx(const ch
int nr, i;
int fd;
struct stat st;
+#if PACK_NAME_ENFORCEMENT_PHASE
+ unsigned char packname[20];
+#endif
fd = open(path, O_RDONLY);
if (fd < 0)
@@ -365,6 +377,22 @@ static int check_packed_git_idx(const ch
close(fd);
return -1;
}
+
+#if PACK_NAME_ENFORCEMENT_PHASE
+ /* We require "...../pack-XXXX{40}XXXX.idx" now.
+ * 5-byte "pack-", 40-byte hex and 4-byte .idx.
+ */
+ i = strlen(path);
+ if (i < 49 || strcmp(path + i - 4, ".idx") ||
+ strncmp(path + i - 49, "pack-", 5) ||
+ get_sha1_hex(path + i - 44, packname))
+#if PACK_NAME_ENFORCEMENT_PHASE == 1
+ fprintf(stderr, "warning: index file name '%s' does not "
+ "match pack-X{40}.idx convention.\n", path);
+#else
+ return error("non index file '%s' ignored", path);
+#endif
+#endif
idx_size = st.st_size;
idx_map = mmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
@@ -397,7 +425,7 @@ static int check_packed_git_idx(const ch
return error("wrong index file size");
/*
- * File checksum.
+ * File checksum and index name.
*/
SHA1_Init(&ctx);
SHA1_Update(&ctx, idx_map, idx_size-20);
@@ -406,6 +434,27 @@ static int check_packed_git_idx(const ch
if (memcmp(sha1, idx_map + idx_size - 20, 20))
return error("index checksum mismatch");
+#if PACK_NAME_ENFORCEMENT_PHASE
+ SHA1_Init(&ctx);
+ for (i = 0; i < nr; i++) {
+ unsigned char *ent = (idx_map + 4*256) + i * 24 + 4;
+ SHA1_Update(&ctx, ent, 20);
+ }
+ SHA1_Final(sha1, &ctx);
+
+ if (memcmp(sha1, packname, 20)) {
+#if PACK_NAME_ENFORCEMENT_PHASE == 1
+ fprintf(stderr, "warning: index name '%s' does not match "
+ "contents of the pack '%s'\n",
+ path, sha1_to_hex(sha1));
+#else
+ return error("index name '%s' does not match "
+ "contents of the pack '%s'\n",
+ path, sha1_to_hex(sha1));
+#endif
+ }
+#endif
+
return 0;
}
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index de45ac4..77fd8d7 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -10,6 +10,8 @@ test_description='git-pack-object
TRASH=`pwd`
+mkdir test-1 test-2
+
test_expect_success \
'setup' \
'rm -f .git/index*
@@ -35,7 +37,7 @@ test_expect_success \
test_expect_success \
'pack without delta' \
- 'packname_1=$(git-pack-objects --window=0 test-1 <obj-list)'
+ 'packname_1=$(git-pack-objects --window=0 test-1/pack <obj-list)'
rm -fr .git2
mkdir .git2
@@ -45,8 +47,8 @@ test_expect_success \
"GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- git-unpack-objects -n <test-1-${packname_1}.pack &&
- git-unpack-objects <test-1-${packname_1}.pack"
+ git-unpack-objects -n <test-1/pack-${packname_1}.pack &&
+ git-unpack-objects <test-1/pack-${packname_1}.pack"
unset GIT_OBJECT_DIRECTORY
cd "$TRASH/.git2"
@@ -66,7 +68,8 @@ cd "$TRASH"
test_expect_success \
'pack with delta' \
'pwd &&
- packname_2=$(git-pack-objects test-2 <obj-list)'
+ packname_2=$(git-pack-objects test-2/pack <obj-list) &&
+ test "$packname_2" = "$packname_1"'
rm -fr .git2
mkdir .git2
@@ -76,8 +79,8 @@ test_expect_success \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- git-unpack-objects -n <test-2-${packname_2}.pack &&
- git-unpack-objects <test-2-${packname_2}.pack'
+ git-unpack-objects -n <test-2/pack-${packname_2}.pack &&
+ git-unpack-objects <test-2/pack-${packname_2}.pack'
unset GIT_OBJECT_DIRECTORY
cd "$TRASH/.git2"
@@ -101,7 +104,8 @@ test_expect_success \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- cp test-1-${packname_1}.pack test-1-${packname_1}.idx .git2/objects/pack && {
+ cp test-1/pack-${packname_1}.pack test-1/pack-${packname_1}.idx \
+ .git2/objects/pack && {
git-diff-tree --root -p $commit &&
while read object
do
@@ -116,8 +120,9 @@ test_expect_success \
'use packed deltified objects' \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
- rm -f .git2/objects/pack/test-?.idx &&
- cp test-2-${packname_2}.pack test-2-${packname_2}.idx .git2/objects/pack && {
+ rm -f .git2/objects/pack/pack-* &&
+ cp test-2/pack-${packname_2}.pack test-2/pack-${packname_2}.idx \
+ .git2/objects/pack && {
git-diff-tree --root -p $commit &&
while read object
do
@@ -131,47 +136,47 @@ unset GIT_OBJECT_DIRECTORY
test_expect_success \
'verify pack' \
- 'git-verify-pack test-1-${packname_1}.idx test-2-${packname_2}.idx'
+ 'git-verify-pack test-?/pack-${packname_1}.idx'
test_expect_success \
'corrupt a pack and see if verify catches' \
- 'cp test-1-${packname_1}.idx test-3.idx &&
- cp test-2-${packname_2}.pack test-3.pack &&
- if git-verify-pack test-3.idx
+ 'cp test-1/pack-${packname_1}.idx . &&
+ cp test-2/pack-${packname_2}.pack . &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
: PACK_SIGNATURE &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2 &&
- if git-verify-pack test-3.idx
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.pack count=1 bs=1 conv=notrunc seek=2 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
: PACK_VERSION &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7 &&
- if git-verify-pack test-3.idx
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.pack count=1 bs=1 conv=notrunc seek=7 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
: TYPE/SIZE byte of the first packed object data &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12 &&
- if git-verify-pack test-3.idx
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.pack count=1 bs=1 conv=notrunc seek=12 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
: sum of the index file itself &&
- l=`wc -c <test-3.idx` &&
+ l=`wc -c <pack-${packname_1}.idx` &&
l=`expr $l - 20` &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.idx count=20 bs=1 conv=notrunc seek=$l &&
- if git-verify-pack test-3.pack
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.idx count=20 bs=1 conv=notrunc seek=$l &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
@@ -180,19 +185,19 @@ test_expect_success \
test_expect_success \
'build pack index for an existing pack' \
- 'cp test-1-${packname_1}.pack test-3.pack &&
- git-index-pack -o tmp.idx test-3.pack &&
- cmp tmp.idx test-1-${packname_1}.idx &&
-
- git-index-pack test-3.pack &&
- cmp test-3.idx test-1-${packname_1}.idx &&
-
- cp test-2-${packname_2}.pack test-3.pack &&
- git-index-pack -o tmp.idx test-2-${packname_2}.pack &&
- cmp tmp.idx test-2-${packname_2}.idx &&
+ 'cp test-1/pack-${packname_1}.pack unknown.pack &&
+ git-index-pack -o tmp.idx unknown.pack &&
+ cmp tmp.idx test-1/pack-${packname_1}.idx &&
+
+ git-index-pack unknown.pack &&
+ cmp unknown.idx test-1/pack-${packname_1}.idx &&
+
+ cp test-2/pack-${packname_2}.pack unknown.pack &&
+ git-index-pack -o tmp.idx unknown.pack &&
+ cmp tmp.idx test-2/pack-${packname_2}.idx &&
- git-index-pack test-3.pack &&
- cmp test-3.idx test-2-${packname_2}.idx &&
+ git-index-pack unknown.pack &&
+ cmp unknown.idx test-2/pack-${packname_2}.idx &&
:'
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH - maint review] describe: do not silently ignore indescribable commits
From: Junio C Hamano @ 2006-01-12 0:05 UTC (permalink / raw)
To: git
We silently ignored indescribable commits without complaining.
Complain and die instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For 1.1.2
describe.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
8c23b6fae2e5cd8475885b015f0bb992d19921db
diff --git a/describe.c b/describe.c
index a0180f5..5548a16 100644
--- a/describe.c
+++ b/describe.c
@@ -124,10 +124,11 @@ static void describe(struct commit *cmit
if (n) {
printf("%s-g%s\n", n->path,
find_unique_abbrev(cmit->object.sha1, abbrev));
- break;
+ clear_commit_marks(cmit, SEEN);
+ return;
}
}
- clear_commit_marks(cmit, SEEN);
+ die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
}
int main(int argc, char **argv)
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH] convert-packs: futureproofing.
From: Junio C Hamano @ 2006-01-12 0:05 UTC (permalink / raw)
To: git
Names of packfiles are informally expected to be of the form
"pack-[0-9a-f]{40}.pack", with corresponding .idx file (the
core-level only requires the files are named ".pack" and ".idx"
respectively).
The hexadecimal part should be what git-pack-objects computed
when the pack was created originally, and it is the SHA1 sum
over sorted object names (i.e. 20-byte binary SHA1 checksum
each). However, git-pack-objects before v0.99.9 computed a
checksum over object names without sorting (i.e. the order
git-rev-list fed the object names), just to make pack names
unlikely to collide. The current git-pack-objects computes the
checksum differently, so that two packfiles that contain the
same set of objects are always given the same name. This was
done so that we can use the filename as an additional way to
verify the integrity of the pack.
Many packfiles in the wild were created with git before v0.99.9,
and they will fail this verification. The new command
git-convert-packs can be used to rename them to a name that
would have been given by git-pack-objects post v0.99.9.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* Currently in "pu".
.gitignore | 1
Documentation/git-convert-packs.txt | 41 +++++++++++++++++
Makefile | 2 -
convert-packs.c | 86 +++++++++++++++++++++++++++++++++++
4 files changed, 129 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-convert-packs.txt
create mode 100644 convert-packs.c
004e17155fe0a739857851cffc5efd3407af389c
diff --git a/.gitignore b/.gitignore
index 1a9090b..0d50843 100644
--- a/.gitignore
+++ b/.gitignore
@@ -19,6 +19,7 @@ git-clone-pack
git-commit
git-commit-tree
git-convert-objects
+git-convert-packs
git-count-objects
git-cvsexportcommit
git-cvsimport
diff --git a/Documentation/git-convert-packs.txt b/Documentation/git-convert-packs.txt
new file mode 100644
index 0000000..ba02641
--- /dev/null
+++ b/Documentation/git-convert-packs.txt
@@ -0,0 +1,41 @@
+git-convert-packs(1)
+====================
+
+NAME
+----
+git-convert-packs - Renames packfiles created with pre 0.99.9 GIT
+
+
+SYNOPSIS
+--------
+'git-convert-packs'
+
+DESCRIPTION
+-----------
+Older git-pack-objects named the resulting packfile with an SHA1
+hash of the object names without sorting them first (i.e. random
+unverifiable order), which meant that two packfiles that contain
+the same set of objects can be named differently. To make
+packfile reliably verifiable, future versions of GIT will
+require that the name of the packfile to match the SHA1 hash of
+the object names contained within, after sorting them, and will
+ignore packfiles whose names do not verify.
+
+This command takes no parameter; it inspects packfiles in the
+local repository, and renames the ones whose names do not match
+their contents. You need to rename older packfiles using this
+command before GIT starts complaining.
+
+
+Author
+------
+Written by Junio C Hamano <junkio@cox.net>
+
+Documentation
+--------------
+Documentation by the git-list <git@vger.kernel.org>.
+
+GIT
+---
+Part of the gitlink:git[7] suite
+
diff --git a/Makefile b/Makefile
index fa0cd83..6d5f293 100644
--- a/Makefile
+++ b/Makefile
@@ -123,7 +123,7 @@ SIMPLE_PROGRAMS = \
PROGRAMS = \
git-apply$X git-cat-file$X \
git-checkout-index$X git-clone-pack$X git-commit-tree$X \
- git-convert-objects$X git-diff-files$X \
+ git-convert-objects$X git-convert-packs$X git-diff-files$X \
git-diff-index$X git-diff-stages$X \
git-diff-tree$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-init-db$X \
diff --git a/convert-packs.c b/convert-packs.c
new file mode 100644
index 0000000..754599d
--- /dev/null
+++ b/convert-packs.c
@@ -0,0 +1,86 @@
+#include "cache.h"
+
+static int verify_pack_name(struct packed_git *p)
+{
+ SHA_CTX ctx;
+ unsigned char sha1[20];
+ int i, nr, len, bad;
+ const char *hex;
+ char *base_name;
+
+ nr = num_packed_objects(p);
+
+ SHA1_Init(&ctx);
+ for (i = 0; i < nr; i++) {
+ unsigned char *ent = (((unsigned char *)p->index_base) +
+ 4*256 + i * 24 + 4);
+ SHA1_Update(&ctx, ent, 20);
+ }
+ SHA1_Final(sha1, &ctx);
+ hex = sha1_to_hex(sha1);
+
+ base_name = strrchr(p->pack_name, '/');
+ if (base_name)
+ base_name++;
+ else
+ base_name = p->pack_name;
+
+ bad = 0;
+ /* We require "pack-X{40}.pack" these days before mapping
+ * the idx file, so the first two conditions of the if()
+ * statement are always false.
+ */
+ len = strlen(base_name);
+ if ((len != 50) ||
+ memcmp(base_name, "pack-", 5) ||
+ memcmp(base_name + 5, hex, 40)) {
+ char *newname;
+ int newlen;
+
+ fprintf(stderr, "pack '%s' does not match contents '%s'\n",
+ base_name, hex);
+ newname = xmalloc(base_name - p->pack_name + 52);
+ if (base_name != p->pack_name)
+ sprintf(newname, "%.*spack-%s.pack",
+ (base_name - p->pack_name), p->pack_name, hex);
+ else
+ sprintf(newname, "pack-%s.pack", hex);
+ newlen = strlen(newname);
+
+ /* Make sure there is no such pack and idx first. */
+ if (!access(newname, F_OK))
+ return error("But there is a pack with that name!");
+
+ memcpy(newname + newlen - 5, ".idx", 5);
+ if (!access(newname, F_OK))
+ return error("But there is an idx with that name!");
+
+ memcpy(newname + newlen - 5, ".pack", 5);
+ if (rename(p->pack_name, newname))
+ return error("But the pack cannot renamed somehow!");
+
+ /* Now we have renamed the pack, so let's rename the index */
+ memcpy(base_name + len - 5, ".idx", 5);
+ memcpy(newname + newlen - 5, ".idx", 5);
+
+ if (!access(newname, F_OK))
+ return error("But there is an idx with that name!");
+ else if (rename(p->pack_name, newname))
+ return error("But the idx cannot be renamed somehow!");
+
+ fprintf(stderr, "... renamed successfully.\n");
+ }
+ return bad;
+}
+
+int main(int ac, char **av)
+{
+ struct packed_git *p;
+
+ setup_git_directory();
+ prepare_packed_git();
+ for (p = packed_git; p; p = p->next)
+ if (p->pack_local)
+ verify_pack_name(p);
+ return 0;
+}
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH - maint review] name-rev: do not omit leading components of ref name.
From: Junio C Hamano @ 2006-01-12 0:04 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In a repository with mainto/1.0 (to keep maintaining the 1.0.X
series) and fixo/1.0 (to keep fixes that apply to both 1.0.X
series and upwards) branches, "git-name-rev mainto/1.0" answered
just "1.0" making things ambiguous. Show refnames unambiguously
like show-branch does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For 1.0.10 and 1.1.2
name-rev.c | 7 ++++---
t/t6010-merge-base.sh | 6 +++---
2 files changed, 7 insertions(+), 6 deletions(-)
2c817df25d54b557d6cac0800cacfd0a255cd56d
diff --git a/name-rev.c b/name-rev.c
index 65333d4..bbadb91 100644
--- a/name-rev.c
+++ b/name-rev.c
@@ -93,10 +93,11 @@ static int name_ref(const char *path, co
}
if (o && o->type == commit_type) {
struct commit *commit = (struct commit *)o;
- const char *p;
- while ((p = strchr(path, '/')))
- path = p+1;
+ if (!strncmp(path, "refs/heads/", 11))
+ path = path + 11;
+ else if (!strncmp(path, "refs/", 5))
+ path = path + 5;
name_rev(commit, strdup(path), 0, 0, deref);
}
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index c3a9680..1dce123 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t6010-merge-base.sh
@@ -46,14 +46,14 @@ H=$(doit 8 H $A $F)
test_expect_success 'compute merge-base (single)' \
'MB=$(git-merge-base G H) &&
- expr "$(git-name-rev "$MB")" : "[0-9a-f]* B"'
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
test_expect_success 'compute merge-base (all)' \
'MB=$(git-merge-base --all G H) &&
- expr "$(git-name-rev "$MB")" : "[0-9a-f]* B"'
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
test_expect_success 'compute merge-base with show-branch' \
'MB=$(git-show-branch --merge-base G H) &&
- expr "$(git-name-rev "$MB")" : "[0-9a-f]* B"'
+ expr "$(git-name-rev "$MB")" : "[0-9a-f]* tags/B"'
test_done
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH - maint review] show-branch: handle [] globs as well.
From: Junio C Hamano @ 2006-01-12 0:04 UTC (permalink / raw)
To: git
Earlier only '?' and '*' signalled the command that what the
user has given is a glob pattern. This prevented us to say:
$ git show-branch 'v0.99.[0-3]'
Now we notice '[' as well, so the above would work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For 1.0.10 and 1.1.2
show-branch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
87758f975b04233ba058750f7ea8ce63bb67297f
diff --git a/show-branch.c b/show-branch.c
index 15b1968..1935c44 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -492,7 +492,7 @@ static void append_one_rev(const char *a
append_ref(av, revkey);
return;
}
- if (strchr(av, '*') || strchr(av, '?')) {
+ if (strchr(av, '*') || strchr(av, '?') || strchr(av, '[')) {
/* glob style match */
int saved_matches = ref_name_cnt;
match_ref_pattern = av;
--
1.1.1-g8ecb
^ permalink raw reply related
* [PATCH - maint review] update-index: work with c-quoted name
From: Junio C Hamano @ 2006-01-12 0:04 UTC (permalink / raw)
To: git
update-index --stdin did not work with c-style quoted names even though
update-index --index-info did. This fixes the inconsistency.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* For 1.0.10 and 1.1.2
update-index.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
a94d9948da539fdafc26c74afb335b2fe9f8f21d
diff --git a/update-index.c b/update-index.c
index be87b99..a84a04f 100644
--- a/update-index.c
+++ b/update-index.c
@@ -534,10 +534,17 @@ int main(int argc, const char **argv)
struct strbuf buf;
strbuf_init(&buf);
while (1) {
+ char *path_name;
read_line(&buf, stdin, line_termination);
if (buf.eof)
break;
- update_one(buf.buf, prefix, prefix_length);
+ if (line_termination && buf.buf[0] == '"')
+ path_name = unquote_c_style(buf.buf, NULL);
+ else
+ path_name = buf.buf;
+ update_one(path_name, prefix, prefix_length);
+ if (path_name != buf.buf)
+ free(path_name);
}
}
if (active_cache_changed) {
--
1.1.1-g8ecb
^ permalink raw reply related
* What's cooking in git.git
From: Junio C Hamano @ 2006-01-12 0:04 UTC (permalink / raw)
To: git
I have queued the following for the maintenance branches.
For both 1.0.X and 1.1.X series:
- update-index: work with c-quoted name
- show-branch: handle [] globs as well.
- name-rev: do not omit leading components of ref name.
For 1.1.X series only:
- Add git-describe to .gitignore.
- describe: do not silently ignore indescribable commits
I plan to do 1.0.10 [*1*] and 1.1.2 sometime this weekend, along
with some other fixes that would appear until then.
On the development front, I have these in the proposed updates
branch:
- Exec git programs without using PATH (Michal Ostrowski).
This has been discussed for the last couple of days on the
list. I think C side is ready to go in, but I'd like to
decide what to do on the scripting side before merging it
into the master branch.
- Disable USE_SYMLINK_HEAD by default (Pavel Roskin).
This has been on hold for almost two months -- forever in git
timescale.
One offender that could have been broken by this change was
fixed recently (gitweb), so this can go in anytime now. Do
people still care about it? The argument for the change when
it was proposed was "then we only have to worry about one
format of .git/HEAD, not two", and it still is a valid
argument from Porcelain writers' point of view. To be
honest, since I do not do Porcelain, I am neutral about it.
- convert-packs: futureproofing.
- Require packfiles to follow the naming convention (preparation).
These two I have been holding for a while. I would
eventually like to force people to rename the packfiles
created by GIT older than v0.99.9 which has unverifiable
hexadecimal string in their names and these are the first
two baby steps toward that goal. If people object to the
idea of verifiable packname in general, please raise hand,
and I may be talked into shelving the whole thing.
- Documentation: show-branch.
- show-branch: always include the current branch
- show-branch: make --topo-order noop and default.
- show-branch: make the current branch stand out.
Here are mostly usability updates.
I'll send out some of the above patches to the list separately
for discussion and review.
[Footnote]
*1* 1.0.X series maintenance can largely be ignored by general
public, since I do not see any reason to stick to 1.0.X series.
1.1.X series does not have any backward incompatibility issues
as far as I know. I am doing 1.0.X series primarily as a
practice for myself, and to experiment with a maintainer
workflow like this:
- "fixo/1.0" topic branch queues fixes applicable for 1.0
series *and* *later* maintenance series.
- "fix" topic branch queues fixes applicable only for the
current maintenance series.
- "mainto/1.0" branch is used to cut releases for the 1.0.X
maintenance series from. This pulls from "fixo/1.0" topic
branch.
- "maint" branch is used to cut releases for the current
maintenance series from. This pulls from both "fix" topic
branch and "mainto/*" topic branches.
With this setup, I can first merge "fixo/1.0" to "mainto/1.0",
and then merge "mainto/1.0" and "fix" branches to "maint", to
come up with something like this:
$ git show-branch fix fixo/* maint mainto/*
! [fix] describe: do not silently ignore indescribable commits
! [fixo/1.0] name-rev: do not omit leading components of ref name.
* [maint] GIT 1.1.2 (not really -- just a demonstration)
! [mainto/1.0] GIT 1.0.10 (not really -- just a demonstration)
----
* [maint] GIT 1.1.2 (not really -- just a demonstration)
+ * [fix] describe: do not silently ignore indescribable commits
+ * [fix^] Add git-describe to .gitignore.
* [maint^] Merge fixes up to GIT 1.0.10 (not really)
*+ [mainto/1.0] GIT 1.0.10 (not really -- just a demonstration)
+*+ [fixo/1.0] name-rev: do not omit leading components of ref name.
+*+ [fixo/1.0^] update-index: work with c-quoted name
*+ [mainto/1.0^] GIT 1.0.9
* [maint~2] GIT 1.1.1
+*+ [fixo/1.0~2] glossary: explain "master" and "origin"
+ * [maint~3] GIT-VERSION-GEN: detect dirty tree and mark the ver...
+ * [maint~4] For release tarballs, include the proper version
+ * [maint~5] GIT 1.1.0
+ *+ [mainto/1.0~2] GIT 1.0.8
++*+ [fixo/1.0~3] mailsplit: allow empty input from stdin
^ permalink raw reply
* Re: merging initial part of a branch?
From: Junio C Hamano @ 2006-01-11 23:47 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Git Mailing List
In-Reply-To: <20060111230451.GH8618@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> External kernel projects sometimes work only against major
> releases--it's easier for their users/testers to find a major release
> than a random git version, and at least in the early prototype stage, it
> isn't critical to be working on the tip all the time.
>
> Is there a simple way to say, for example, "merge in all the upstream
> changes up to v2.6.15"?
I haven't tried this for some time, but I presume
$ git pull linus tag v2.6.15
would do what you want.
^ permalink raw reply
* qgit shows wrong popup
From: Pavel Roskin @ 2006-01-11 23:21 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
Hello, Marco!
Current qgit has a bug that manifests itself on stgit repositories.
Suppose I have two patches known to stgit, one is applied and the other
is not.
If the unapplied patch is selected and I right-click on the applied
patch below, I get a popup with "Push patch" disabled. If I select the
applied patch by the left click, then "Pop patch" appears in that place,
and it's enabled. Also, "Make Tag" appears in the menu.
Going from the applied patch to the unapplied one by the right click
results in having disabled "Pop patch" instead of the correct enabled
"Push patch".
Screenshots can be found at
http://red-bean.com/proski/qgit/
I found this comment in mainimpl.cpp:
// call an async context popup, DO NOT filter out event
// we append the event to main event loop queue so Qt can send
// currentChanged() signal to listViewLog before our popup is
populated
I guess the code doesn't work the way the comment says.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Proxy and authentication
From: Beber @ 2006-01-11 23:08 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90601111026j1fd6f8e2pcafb4437c4b458fe@mail.gmail.com>
On 1/11/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 1/12/06, Beber <beber.lkml@gmail.com> wrote:
> > Is there plan to allow proxy authentication and http/webdav remote
> > repository authentication ?
> > It seem that's it's quiet non-working for now.
>
> search the list archives for more detail, but
>
> export http_proxy=http://my.proxy.tld:8080/
> git foo
>
> should work. Have you tried embedding auth details in the url? Try
> http://user:pass@my.proxy.tld:8080/
Yes it works if you have a password without any strange characters
like @ : and so
>
> cheers,
>
>
> martin
>
^ permalink raw reply
* merging initial part of a branch?
From: J. Bruce Fields @ 2006-01-11 23:04 UTC (permalink / raw)
To: Git Mailing List
External kernel projects sometimes work only against major
releases--it's easier for their users/testers to find a major release
than a random git version, and at least in the early prototype stage, it
isn't critical to be working on the tip all the time.
Is there a simple way to say, for example, "merge in all the upstream
changes up to v2.6.15"?
It looks like git pull will only update me to the very tip of a branch.
I could create a new local branch that stops at v2.6.15, then pull from
that. Can I accomplish the same thing somehow with just one git pull?
Or is there some other convenient shorthand that I've missed?
--b.
^ permalink raw reply
* Re: [PATCH] stgit: fix clone
From: Chuck Lever @ 2006-01-11 22:47 UTC (permalink / raw)
To: cel; +Cc: Pavel Roskin, Catalin Marinas, git
In-Reply-To: <43C58916.6030409@citi.umich.edu>
[-- Attachment #1: Type: text/plain, Size: 482 bytes --]
Chuck Lever wrote:
> hi pavel-
>
> exactly where does the clone operation fail? is it at the checkout step?
>
> seems to me the "git clone" script should create an environment where
> "git-rev-parse --git-dir" ought to work correctly.
oops. i see it now.
stgit/main.py does a special stack.Series('master') just for the clone
command. it really shouldn't do this -- the crt_series.init() in the
clone command ought to be fixed to do this properly.
catalin, do you agree?
[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 451 bytes --]
begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Open Source NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763-4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668-1089
x-mozilla-html:FALSE
url:http://troy.citi.umich.edu/u/cel/
version:2.1
end:vcard
^ 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