* Re: git-cvsimport "you may need to merge manually"
From: smurf @ 2006-03-17 7:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86fylh20x6.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
Hi,
Randal L. Schwartz:
> Yeah, this doesn't make sense. It used to "Just Work". I can
> certainly add "git reset --hard" to my workflow, if that's the real
> work around. And if so, the manpage should document that.
>
The real workaround is not to import into live branches,
which is not a git-cvs-specific problem, so I didn't add that
to its manpage.
I'm not opposed to an appropriate patch if you think its necessary.
If you do, keep in mind that there are other git-*import scripts out
there which presumably have the same problem. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
That which is good to be done, cannot be done too soon; and if it is
neglected to be done early, it will frequently happen that it will not be done
at all.
-- Bishop Mant
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 8:06 UTC (permalink / raw)
To: smurf; +Cc: Randal L. Schwartz, git
In-Reply-To: <20060317064618.GG14562@smurf.noris.de>
smurf@smurf.noris.de writes:
> Junio C Hamano:
>> ..., and you are expected to say:
>>
>> $ git pull . origin
>>
> Exactly.
I think the second and subsequent run of "git cvsimport"
currently is similar to "git fetch", but earlier one that tried
to do checkout was probably similar to "git pull". I think most
people would expect it to behave more like "git pull",
i.e. fetch from the upstream (that happens to be CVS) and merge
that into your branch. It may not be operated that way
correctly and that might have been the reason we removed the
"master updates" code, but if that is the case I'd rather fix it
properly.
>> assuming that you are on "master" branch and cvsimoprt tracks
>> CVS head with "origin" branch, that is.
>>
>> Smurf, help?
>>
> What for? You got it, after all. *g*
Not really, I am afraid. There is one snag _if_ you use the
current branch as the tracking branch. Merlyn's setup is
exactly that -- he has "master" which is given to the command
with -o flag. The branch head commit is already updated, but
the index and working tree is not.
Now, unlike git-fetch, git-cvsimport _requires_ you to have a
pristine tracking branch (otherwise we cannot discard already
seen patchsets from what we read from CVSPS), and leaving that
tracking branch checked out is calling for trouble because you
might be tempted to make your own commit on top of it. So we
could argue that one solution would be to forbid importing into
the current branch.
But that breaks well behaving people who are used to leave a
tracking branch checked out _and_ promises not to touch that
branch head from the git side.
So what I would suggest is to do something like this:
- Before starting to interpret CVSPS output, keep the commit
object name of the current branch tip.
- After we are done, read the current branch tip. If they are
different, we updated the current branch tip without matching
the index and working tree, so we match them just like
git-pull does. Otherwise, we run 'git-merge' to merge the
$opt_o branch into the current branch.
That is, perhaps, like this untested patch. What do you think?
-- >8 --
cvsimport: act more like pull, not fetch
After updating tracking branches with upstream CVS changes, if
the current branch is one of the tracking branches, match the
index and working tree just like "git-pull" that was started
with one of the tracking branches checked out. Otherwise, merge
the trunk ($opt_o) branch into the current branch. This would
match users' expectation more closely.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 02d1928..b9cebaf 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -453,6 +453,7 @@ chdir($git_tree);
my $last_branch = "";
my $orig_branch = "";
my %branch_date;
+my $tip_at_start = undef;
my $git_dir = $ENV{"GIT_DIR"} || ".git";
$git_dir = getwd()."/".$git_dir unless $git_dir =~ m#^/#;
@@ -487,6 +488,7 @@ unless(-d $git_dir) {
$last_branch = "master";
}
$orig_branch = $last_branch;
+ $tip_at_start = `git-rev-parse --verify HEAD`;
# populate index
system('git-read-tree', $last_branch);
@@ -873,7 +875,18 @@ if (defined $orig_git_index) {
# Now switch back to the branch we were in before all of this happened
if($orig_branch) {
- print "DONE; you may need to merge manually.\n" if $opt_v;
+ print "DONE.\n" if $opt_v;
+ my $tip_at_end = `git-rev-parse --verify HEAD`;
+ if ($tip_at_start ne $tip_at_end) {
+ print "Fetched into the current branch.\n" if $opt_v;
+ system(qw(git-read-tree -u -m),
+ $tip_at_start, $tip_at_end);
+ die "Fast-forward update failed: $?\n" if $?;
+ }
+ else {
+ system(qw(git-merge cvsimport HEAD), "refs/heads/$opt_o");
+ die "Could not merge $opt_o into the current branch.\n" if $?;
+ }
} else {
$orig_branch = "master";
print "DONE; creating $orig_branch branch\n" if $opt_v;
^ permalink raw reply related
* Re: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 8:08 UTC (permalink / raw)
To: smurf; +Cc: git
In-Reply-To: <20060317072602.GH14562@smurf.noris.de>
smurf@smurf.noris.de writes:
> The real workaround is not to import into live branches,
> which is not a git-cvs-specific problem, so I didn't add that
> to its manpage.
Yes. I sufferred the same problem when I did git-fetch/git-pull,
and there is a clever/ugly workaround for that.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Mark Wooding @ 2006-03-17 10:51 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7z97rdr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> and the above would not break things.
Indeed. I just translated Junio's `git_exec' shell function into a
one-liner.
-- [mdw]
^ permalink raw reply
* Re: Possible --remove-empty bug
From: Marco Costalba @ 2006-03-17 10:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0603131058270.3618@g5.osdl.org>
On 3/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> However, to be honest, the only reason to ever use --remove-empty is for
> rename detection, and Frederik's approach of doing that through the
> library interface directly is actually a much superior option. So we might
> as well drop the compilcation of --remove-empty entirely, unless somebody
> has already started using it.
>
In case of a rather recent file --remove-empty option gives a good
speed up in history loading with git-rev-list. So qgit uses that
option.
Annotation in qgit it is little different from blame algorithm because
it works from oldest revision to latest instead of the contrary. This
is due because it calculates in one pass _all_ the annotations of all
the different revisions of a given file, starting from file history,
i.e. 'git-rev-list file_path' output.
The GUI interface of qgit let's the user quickly jump between two file
revisions. So the corresponding annotations should be already prepared
to make it snappy.
> The _real_ optimization would be to make the pathname based pruning be
> done incrementally instead of having to build up the whole tree.
Anything that speeds-up file git-rev-list history loading surely gives
a big boost to all annotation/blame stuff. I have made some profiling
on qgit (the public git repo version that is much faster, not the
qgit1.1 released one) and I found that 50% to 70% of the time is spent
on git-rev-list, of the remaining the 80% is spent on git-diff-tree -p
patch loading and only a small amount is spent on actually calculate
the annotation.
Of course these numbers can vary a little according to file/repo, but
the big picture stays the same.
Marco
^ permalink raw reply
* Re: [PATCH 1/4] Simplify wildcards for match files to be ignored
From: Jonas Fonseca @ 2006-03-17 17:19 UTC (permalink / raw)
To: Horst von Brand; +Cc: Petr Baudis, git
In-Reply-To: <200603110008.k2B08aCO004834@laptop11.inf.utfsm.cl>
Horst von Brand <vonbrand@inf.utfsm.cl> wrote Fri, Mar 10, 2006:
> Jonas Fonseca <fonseca@diku.dk> wrote:
> > Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> >
> > ---
> >
> > Documentation/Makefile | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/Documentation/Makefile b/Documentation/Makefile
> > index 3aad2fb..661c259 100644
> > --- a/Documentation/Makefile
> > +++ b/Documentation/Makefile
> > @@ -1,4 +1,4 @@
> > -CG_IGNORE=$(wildcard ../cg-X* ../cg-*.orig ../cg-*.rej ../cg-*.in)
> > +CG_IGNORE=$(wildcard ../cg-X* ../cg-*.*)
>
> Nope. Better be specific in what you delete. It is not exactly
> performance-critical...
The intention was to ignore also cg-*.patch, but then ignoring any file
with a dot in makes sense and avoids a lot more errors when building
documentation in a dirty tree.
--
Jonas Fonseca
^ permalink raw reply
* Re: git-reset and clones
From: Jon Loeliger @ 2006-03-17 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paul, Git List
In-Reply-To: <7v4q1x95yo.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:
>
> You used to have something like this:
>
>
> o---o---o---A
> / ^ your HEAD used to point at here
> ---o---o---o
>
> and you forgot other people already have the commit chain up to
> commit A. But you rewound and did cleanups:
>
> o---o---o---A
> /
> ---o---o---o---o---o---B
> ^ your HEAD now points at here
>
> People who track your HEAD have A and your updated head B does
> not fast forward. Oops.
>
> The recovery consists of two steps. The first step is more
> important. To find what commits you lost that others already
> may have. You may be lucky and remember A's commit object name,
> but when I did that I had to ask around on the list X-<.
>
> The second step is a single command:
>
> $ git merge -s ours 'Graft the lost side branch back in' \
> HEAD A
>
> where A is the object name of that commit. On your current
> branch, this creates a merge commit between A and B (your
> current HEAD), taking the tree object from B.
>
> o---o---o---A
> / \
> ---o---o---o---o---o---B---M
Junio,
Can you explain a bit more why the "ours" strategy
comes into play here? I _think_ I understand, but
I'd like to hear a bit more explanation, please.
How is this different from just merging in A directly?
> You want to keep the contents of the cleaned-up HEAD, so that is
> why you are taking the tree from B.
And the "ours" strategy effectively says, "Favor the B
side of things when pulling in the A parts", right?
> With this commit M, you are
> telling the outside world that it is OK if they start from a
> commit on the now-recovered side branch.
This is mystical to me. How is the "A" (ie, side branch)
now in a "recovered" state?
Thanks,
jdl
^ permalink raw reply
* Re: git-reset and clones
From: Junio C Hamano @ 2006-03-17 20:39 UTC (permalink / raw)
To: Jon Loeliger; +Cc: paul, Git List
In-Reply-To: <1142623141.17536.225.camel@cashmere.sps.mot.com>
Jon Loeliger <jdl@freescale.com> writes:
>> ... On your current
>> branch, this creates a merge commit between A and B (your
>> current HEAD), taking the tree object from B.
>>
>> o---o---o---A
>> / \
>> ---o---o---o---o---o---B---M
>
> Can you explain a bit more why the "ours" strategy
> comes into play here? I _think_ I understand, but
> I'd like to hear a bit more explanation, please.
> How is this different from just merging in A directly?
>> You want to keep the contents of the cleaned-up HEAD, so that is
>> why you are taking the tree from B.
>
> And the "ours" strategy effectively says, "Favor the B
> side of things when pulling in the A parts", right?
Yes, it is stronger than that. "ours" says: "the tree from our
head commit B *is* the resulting tree -- whatever we are merging
into us does not matter".
>> With this commit M, you are
>> telling the outside world that it is OK if they start from a
>> commit on the now-recovered side branch.
>
> This is mystical to me. How is the "A" (ie, side branch)
> now in a "recovered" state?
Although their effects are superseded (B^{tree} == M^{tree}),
they are still in the ancestry chain.
To a downstream person who were lucky enough not to have made
commits on A yet, next pull from you would have involved merging
B and A.
If the upstream did not do the magic "ours" merge, the git-fetch
step would refuse to update the remote tracking branch head, so
the downstream person needs to force the fetch. After forcing
the fetch, the merge would have involved resolving the conflicts
coming from 3-way merge in this:
o---o---o---A---N
/ /
---o---o---o---o---o---B---'
Because the forked track leading to B was either to fix mistakes
or clean things up the upstream originally did in the track
leading to A, the commits on the tracks leading to A and B from
their fork point are almost guaranteed to have conflicting
changes, and resolution of that conflict is forced on the
downstream person. Worse yet, from this point on, since the
upstream discarded the track that contains A, the branch
downstream person has will _never_ converge to upstream branch,
even though the downstream person did _no_ development of his
own in the meantime. This is *B*A*D*.
If there is a magic "ours" merge, the downstream person's
repository records A as the last tip on the tracking branch, and
git-fetch sees the updated head M is a descendant of it, so it
simply fast-forwards:
o---o---o---A
/ \
---o---o---o---o---o---B---M
Now, if the downstream was unlucky and have commits based on A,
the story is a bit different, but the principles are the same.
Without the "ours" merge M, you will get this:
o---o---o---A---X---N
/ /
---o---o---o---o---o---B-------'
When creating the merge N, even if the change between A and X
(i.e. the downstream's own work) does not touch the paths that
differ between A and B, the downstream is forced to resolve
conflicts between A and B. This is unnecessary burden for him.
The upstream should have cleaned up his own mess.
With the "ours" merge M, you will get this:
o---o---o---A---X---N
/ \ /
---o---o---o---o---o---B---M---'
The downstream does not need to worry about the conflicts
between A and B. It has been already resolved at M.
Especially, if the change between A and X does not touch the
paths that differ in A and B, conflict resolution would be
purely about his own work.
In either case, since the downstream has his own development,
the heads of their branches never converge until the upstream
buys his changes (i.e. pull from the downstream that has "N"
commit), but that is not a problem but a feature and does not
have anything to do with this "oops, rewound by mistake" issue.
^ permalink raw reply
* Re: git-reset and clones
From: Jon Loeliger @ 2006-03-17 21:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: paul, Git List
In-Reply-To: <7vslpgztzc.fsf@assigned-by-dhcp.cox.net>
On Fri, 2006-03-17 at 14:39, Junio C Hamano wrote:
> > And the "ours" strategy effectively says, "Favor the B
> > side of things when pulling in the A parts", right?
>
> Yes, it is stronger than that. "ours" says: "the tree from our
> head commit B *is* the resulting tree -- whatever we are merging
> into us does not matter".
Aha! This all makes much more sense now suddenly.
Thank you.
>
> o---o---o---A---N
> / /
> ---o---o---o---o---o---B---'
>
> Because the forked track leading to B was either to fix mistakes
> or clean things up the upstream originally did in the track
> leading to A, the commits on the tracks leading to A and B from
> their fork point are almost guaranteed to have conflicting
> changes, and resolution of that conflict is forced on the
> downstream person. Worse yet, from this point on, since the
> upstream discarded the track that contains A, the branch
> downstream person has will _never_ converge to upstream branch,
> even though the downstream person did _no_ development of his
> own in the meantime. This is *B*A*D*.
Wow. Yeah. Bad.
> If there is a magic "ours" merge, the downstream person's
> repository records A as the last tip on the tracking branch, and
> git-fetch sees the updated head M is a descendant of it, so it
> simply fast-forwards:
That's beautiful. I get it. This has been an
extraordinarily helpful explanation (for me)!
Thank you!
jdl
^ permalink raw reply
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-17 21:21 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Junio C Hamano, paul, Git List
In-Reply-To: <1142623141.17536.225.camel@cashmere.sps.mot.com>
I'm in sort of shallow waters, hoping that Junio or Linus will come
along and pull me off the shores in case I mis-step and say something
stupid that would have made an amusing pictograph had it been done right
by a cartoonist.
Jon Loeliger wrote:
> On Thu, 2006-03-16 at 20:10, Junio C Hamano wrote:
>
>
>>You used to have something like this:
>>
>>
>> o---o---o---A
>> / ^ your HEAD used to point at here
>> ---o---o---o
>>
>>and you forgot other people already have the commit chain up to
>>commit A. But you rewound and did cleanups:
>>
>> o---o---o---A
>> /
>> ---o---o---o---o---o---B
>> ^ your HEAD now points at here
>>
>>People who track your HEAD have A and your updated head B does
>>not fast forward. Oops.
>>
>>The recovery consists of two steps. The first step is more
>>important. To find what commits you lost that others already
>>may have. You may be lucky and remember A's commit object name,
>>but when I did that I had to ask around on the list X-<.
>>
>>The second step is a single command:
>>
>> $ git merge -s ours 'Graft the lost side branch back in' \
>> HEAD A
>>
>>where A is the object name of that commit. On your current
>>branch, this creates a merge commit between A and B (your
>>current HEAD), taking the tree object from B.
>>
>> o---o---o---A
>> / \
>> ---o---o---o---o---o---B---M
>
>
> Junio,
>
> Can you explain a bit more why the "ours" strategy
> comes into play here? I _think_ I understand, but
> I'd like to hear a bit more explanation, please.
> How is this different from just merging in A directly?
>
"Ours" is an algorithm you can invent yourself and pass as the defautl
merge strategy (useful if you know you'll always keep upstream as-is or
some such).
>
>>You want to keep the contents of the cleaned-up HEAD, so that is
>>why you are taking the tree from B.
>
>
> And the "ours" strategy effectively says, "Favor the B
> side of things when pulling in the A parts", right?
>
Yes, and/or no. "Ours"' is still whatever you want it to be. Perhaps we
should add some new strategies, like "favour-current" and "favour-new".
>
>> With this commit M, you are
>>telling the outside world that it is OK if they start from a
>>commit on the now-recovered side branch.
>
>
> This is mystical to me. How is the "A" (ie, side branch)
> now in a "recovered" state?
>
Because the commits pullers already have are now inside the respository
history, as seen by average pullers (again). The merge between "master"
(or some such) and "new-devel" (or some such) happen to coincide, which
means they share a mutual merge-base, which means they're both part of
the same chain of developemnt. If you intend to disimiss most of the
changes between (fork-point) and (point-of-new-weird-rebase) this might
not be the best solution, but...
Sorry, but to me this is friaday night and currently I can't logically
differ between a bluewhale and a kangaroo [*1]
/exon
[1]
Sadly, this has been empirically proven. [*2]
[2]
At some other time. I'm no *that* drunk right now.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 1/2] blame: Nicer output
From: Fredrik Kuivinen @ 2006-03-17 21:49 UTC (permalink / raw)
To: git; +Cc: junkio
As pointed out by Junio, it may be dangerous to cut off people's names
after 15 bytes. If the name is encoded in an encoding which uses more
than one byte per code point we may end up with outputting garbage.
Instead of trying to do something smart, just output the entire name.
We don't gain much screen space by chopping it off anyway.
Furthermore, only output the file name if we actually found any
renames.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 35 ++++++++++++++++++++++++++++++-----
1 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/blame.c b/blame.c
index 1fb5070..8af4b54 100644
--- a/blame.c
+++ b/blame.c
@@ -742,6 +742,8 @@ int main(int argc, const char **argv)
struct commit_info ci;
const char *buf;
int max_digits;
+ size_t longest_file, longest_author;
+ int found_rename;
const char* prefix = setup_git_directory();
@@ -818,6 +820,25 @@ int main(int argc, const char **argv)
for (max_digits = 1, i = 10; i <= num_blame_lines + 1; max_digits++)
i *= 10;
+ longest_file = 0;
+ longest_author = 0;
+ found_rename = 0;
+ for (i = 0; i < num_blame_lines; i++) {
+ struct commit *c = blame_lines[i];
+ struct util_info* u;
+ if (!c)
+ c = initial;
+ u = c->object.util;
+
+ if (!found_rename && strcmp(filename, u->pathname))
+ found_rename = 1;
+ if (longest_file < strlen(u->pathname))
+ longest_file = strlen(u->pathname);
+ get_commit_info(c, &ci);
+ if (longest_author < strlen(ci.author))
+ longest_author = strlen(ci.author);
+ }
+
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
struct util_info* u;
@@ -828,14 +849,18 @@ int main(int argc, const char **argv)
u = c->object.util;
get_commit_info(c, &ci);
fwrite(sha1_to_hex(c->object.sha1), sha1_len, 1, stdout);
- if(compability)
+ if(compability) {
printf("\t(%10s\t%10s\t%d)", ci.author,
format_time(ci.author_time, ci.author_tz), i+1);
- else
- printf(" %s (%-15.15s %10s %*d) ", u->pathname,
- ci.author, format_time(ci.author_time,
- ci.author_tz),
+ } else {
+ if (found_rename)
+ printf(" %-*.*s", longest_file, longest_file,
+ u->pathname);
+ printf(" (%-*.*s %10s %*d) ",
+ longest_author, longest_author, ci.author,
+ format_time(ci.author_time, ci.author_tz),
max_digits, i+1);
+ }
if(i == num_blame_lines - 1) {
fwrite(buf, blame_len - (buf - blame_contents),
^ permalink raw reply related
* [PATCH 2/2] blame: Fix git-blame <directory>
From: Fredrik Kuivinen @ 2006-03-17 21:49 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20060317214928.23075.76032.stgit@c165>
Before this patch git-blame <directory> gave non-sensible output. (It
assigned blame to some random file in <directory>) Abort with an error
message instead.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/blame.c b/blame.c
index 8af4b54..9c97aec 100644
--- a/blame.c
+++ b/blame.c
@@ -180,11 +180,13 @@ static int get_blob_sha1_internal(unsign
unsigned mode, int stage);
static unsigned char blob_sha1[20];
+static const char* blame_file;
static int get_blob_sha1(struct tree *t, const char *pathname,
unsigned char *sha1)
{
int i;
const char *pathspec[2];
+ blame_file = pathname;
pathspec[0] = pathname;
pathspec[1] = NULL;
memset(blob_sha1, 0, sizeof(blob_sha1));
@@ -209,6 +211,10 @@ static int get_blob_sha1_internal(unsign
if (S_ISDIR(mode))
return READ_TREE_RECURSIVE;
+ if (strncmp(blame_file, base, baselen) ||
+ strcmp(blame_file + baselen, pathname))
+ return -1;
+
memcpy(blob_sha1, sha1, 20);
return -1;
}
^ permalink raw reply related
* [PATCH] Add git-show reference
From: Jon Loeliger @ 2006-03-18 0:21 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git.txt | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
e202e207b8da1ac771a98f039cdfac70ad9ea0d2
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 8610d36..de3934d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -329,6 +329,9 @@ gitlink:git-revert[1]::
gitlink:git-shortlog[1]::
Summarizes 'git log' output.
+gitlink:git-show[1]::
+ Show one commit log and its diff.
+
gitlink:git-show-branch[1]::
Show branches and their commits.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Call out the two different uses of git-branch and fix a typo.
From: Jon Loeliger @ 2006-03-18 0:24 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-branch.txt | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
1a4336ee2a807d4ccc23d97c7b5c2dce2d4ef116
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 4cd0cb9..71ecd85 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -7,16 +7,20 @@ git-branch - Create a new branch, or rem
SYNOPSIS
--------
-'git-branch' [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]]
+[verse]
+'git-branch' [[-f] <branchname> [<start-point>]]
+'git-branch' (-d | -D) <branchname>
DESCRIPTION
-----------
If no argument is provided, show available branches and mark current
branch with star. Otherwise, create a new branch of name <branchname>.
-
If a starting point is also specified, that will be where the branch is
created, otherwise it will be created at the current HEAD.
+With a `-d` or `-D` option, `<branchname>` will be deleted.
+
+
OPTIONS
-------
-d::
@@ -39,7 +43,7 @@ OPTIONS
Examples
~~~~~~~~
-Start development off of a know tag::
+Start development off of a known tag::
+
------------
$ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Document the default source of template files.
From: Jon Loeliger @ 2006-03-18 0:24 UTC (permalink / raw)
To: git
Also explain a bit more about how the template option works.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-init-db.txt | 18 +++++++++++++-----
1 files changed, 13 insertions(+), 5 deletions(-)
d86b69902d855748ff636d2debbf9524c6f09c04
diff --git a/Documentation/git-init-db.txt b/Documentation/git-init-db.txt
index ea4d849..aeb1115 100644
--- a/Documentation/git-init-db.txt
+++ b/Documentation/git-init-db.txt
@@ -14,7 +14,8 @@ SYNOPSIS
OPTIONS
-------
--template=<template_directory>::
- Provide the directory in from which templates will be used.
+ Provide the directory from which templates will be used.
+ The default template directory is `/usr/share/git-core/templates`.
--shared::
Specify that the git repository is to be shared amongst several users.
@@ -22,9 +23,17 @@ OPTIONS
DESCRIPTION
-----------
-This simply creates an empty git repository - basically a `.git` directory
-and `.git/object/??/`, `.git/refs/heads` and `.git/refs/tags` directories,
-and links `.git/HEAD` symbolically to `.git/refs/heads/master`.
+This command creates an empty git repository - basically a `.git` directory
+with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
+templated files.
+An initial `HEAD` file that references the HEAD of the master branch
+is also created.
+
+If `--template=<template_directory>` is specified, `<template_directory>`
+is used as the source of the template files rather than the default.
+The template files include some directory structure, some suggested
+"exclude patterns", and copies of non-executing "hook" files. The
+suggested patterns and hook files are all modifiable and extensible.
If the `$GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
@@ -38,7 +47,6 @@ repository. When specifying `--shared` t
is set to 'true' so that directories under `$GIT_DIR` are made group writable
(and g+sx, since the git group may be not the primary group of all users).
-
Running `git-init-db` in an existing repository is safe. It will not overwrite
things that are already there. The primary reason for rerunning `git-init-db`
is to pick up newly added templates.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Reference git-commit-tree for env vars.
From: Jon Loeliger @ 2006-03-18 0:25 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-commit.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
4b5717172191a526600010ddfe9a4747fa9c33d2
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 214ed23..d04b342 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -18,6 +18,10 @@ Updates the index file for given paths,
VISUAL and EDITOR environment variables to edit the commit log
message.
+Several environment variable are used during commits. They are
+documented in gitlink:git-commit-tree[1].
+
+
This command can run `commit-msg`, `pre-commit`, and
`post-commit` hooks. See link:hooks.html[hooks] for more
information.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Clarify git-rebase example commands.
From: Jon Loeliger @ 2006-03-18 0:25 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-rebase.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
f59f6f2e8da2e6260ad9585734010b5ea1cd7c2a
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 4d5b546..b36276c 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -25,7 +25,7 @@ Assume the following history exists and
/
D---E---F---G master
-From this point, the result of the following commands:
+From this point, the result of either of the following commands:
git-rebase master
git-rebase master topic
@@ -36,7 +36,7 @@ would be:
/
D---E---F---G master
-While, starting from the same point, the result of the following
+While, starting from the same point, the result of either of the following
commands:
git-rebase --onto master~1 master
@@ -58,7 +58,7 @@ OPTIONS
<upstream>::
Upstream branch to compare against.
-<head>::
+<branch>::
Working branch; defaults to HEAD.
Author
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Fix minor typo.
From: Jon Loeliger @ 2006-03-18 0:25 UTC (permalink / raw)
To: git
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-show-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
0ccfbeb321dbebc70c2203cb801079a90255b2df
diff --git a/Documentation/git-show-branch.txt b/Documentation/git-show-branch.txt
index d3b6e62..f115b45 100644
--- a/Documentation/git-show-branch.txt
+++ b/Documentation/git-show-branch.txt
@@ -141,7 +141,7 @@ it, having the following in the configur
------------
-With this,`git show-branch` without extra parameters would show
+With this, `git show-branch` without extra parameters would show
only the primary branches. In addition, if you happen to be on
your topic branch, it is shown as well.
--
1.2.4.gdd7be
^ permalink raw reply related
* [PATCH] Rewrite synopsis to clarify the two primary uses of git-checkout.
From: Jon Loeliger @ 2006-03-18 0:26 UTC (permalink / raw)
To: git
Fix a few typo/grammar problems.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
---
Documentation/git-checkout.txt | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
3a8c8dc1832fcffe58cdc4894959f67d91c6a924
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 556e733..dc821bb 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -7,15 +7,18 @@ git-checkout - Checkout and switch to a
SYNOPSIS
--------
-'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]
+[verse]
+'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>]
+'git-checkout' [-m] [<branch>] <paths>...
DESCRIPTION
-----------
-When <paths> are not given, this command switches branches, by
+When <paths> are not given, this command switches branches by
updating the index and working tree to reflect the specified
branch, <branch>, and updating HEAD to be <branch> or, if
-specified, <new_branch>.
+specified, <new_branch>. Using -b will cause <new_branch> to
+be created.
When <paths> are given, this command does *not* switch
branches. It updates the named paths in the working tree from
@@ -29,17 +32,17 @@ given paths before updating the working
OPTIONS
-------
-f::
- Force an re-read of everything.
+ Force a re-read of everything.
-b::
Create a new branch and start it at <branch>.
-m::
- If you have local modifications to a file that is
- different between the current branch and the branch you
- are switching to, the command refuses to switch
- branches, to preserve your modifications in context.
- With this option, a three-way merge between the current
+ If you have local modifications to one or more files that
+ are different between the current branch and the branch to
+ which you are switching, the command refuses to switch
+ branches in order to preserve your modifications in context.
+ However, with this option, a three-way merge between the current
branch, your working tree contents, and the new branch
is done, and you will be on the new branch.
+
@@ -82,7 +85,7 @@ $ git checkout -- hello.c
------------
. After working in a wrong branch, switching to the correct
-branch you would want to is done with:
+branch would be done using:
+
------------
$ git checkout mytopic
--
1.2.4.gdd7be
^ permalink raw reply related
* Subprojects: a user perspective
From: R. Steve McKown @ 2006-03-18 2:11 UTC (permalink / raw)
To: git
We are looking to migrate from CVS to a distributed VCS like git. I've read
the discussions on this list WRT subprojects and wanted to present another
user's perspective. The history of this list is active, so I apologize if my
post is redundant or unwanted. Send flames my way! ;^)
Our repository is relatively large and extensively uses the CVS vendor branch
feature to use and track software components managed by other groups, such as
the linux kernel, openssl, busybox, uclibc, etc. These are the tasks that we
perform to manage components:
1. Occasionally import new revisions of components we use into
the component's private branch (like an incoming branch).
This provides a version history of each component's "pristine
source" as used within the project over its lifetime.
2. Each component gets a subdirectory in the project branch(es).
Component versions are merged from the component's incoming
branch into this subdirectory as new components or component
revisions are incorporated into the project.
3. Local modifications, as necessary, are made to component
code within the project branch(es), not the incoming
branches which only hold pristine sources.
4. Patches of local changes made to a component, like for
submission to the upstream maintainer, are built by diffing
a project branch's component subdir with the component's
incoming branch.
I think git can do all of this if the component incoming branches have the
same path information as the project branches. In other words, if the
project places the busybox component at /src/components/busybox, then the
busybox incoming branch must place the busybox code
into /src/component/busybox.
So, in terms of adding specific support for subprojects, the only thing I see
that could be improved would be the ability to reference a sub-tree in git
operations that currently expect a tree (aka tree-ish or refspec parameters).
I liked Junio's concept of subproject linking, but only because it provided a
way to conceptually address a sub-tree.
With sub-tree addressing, a component branch could be naturally rooted, and
diffing its head against the a project branch head at the component's subdir:
git diff linux-incoming proj-branch@/src/components/linux
or merging a new linux version into the project:
git checkout linux-incoming
#suck in a new linux release from upstream
git commit -a
git tag linux-2.4.16
git checkout master
git pull . linux-2.4.16:.@/src/components/linux
All the best,
Steve
^ permalink raw reply
* [PATCH] 3% tighter packs for free
From: Nicolas Pitre @ 2006-03-18 3:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This patch makes for 3.4% smaller pack with the git repository, and
a bit more than 3% smaller pack with the kernel repository.
And so with _no_ measurable CPU difference.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/diff-delta.c b/diff-delta.c
index aaee7be..1188b31 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -136,7 +136,8 @@ void *diff_delta(void *from_buf, unsigne
unsigned long *delta_size,
unsigned long max_size)
{
- unsigned int i, outpos, outsize, inscnt, hash_shift;
+ unsigned int i, outpos, outsize, hash_shift;
+ int inscnt;
const unsigned char *ref_data, *ref_top, *data, *top;
unsigned char *out;
struct index *entry, **hash;
@@ -222,6 +223,20 @@ void *diff_delta(void *from_buf, unsigne
unsigned char *op;
if (inscnt) {
+ while (moff && ref_data[moff-1] == data[-1]) {
+ if (msize == 0x10000)
+ break;
+ /* we can match one byte back */
+ msize++;
+ moff--;
+ data--;
+ outpos--;
+ if (--inscnt)
+ continue;
+ outpos--; /* remove count slot */
+ inscnt--; /* make it -1 */
+ break;
+ }
out[outpos - inscnt - 1] = inscnt;
inscnt = 0;
}
^ permalink raw reply related
* Re: First dumb question to the list :)
From: Jeff King @ 2006-03-18 4:25 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30603160949l655c4f9blb1e202eaf22fbfe@mail.gmail.com>
On Thu, Mar 16, 2006 at 06:49:16PM +0100, Paolo Ciarrocchi wrote:
> performed a simple cg-clone git://URItoLinus2.6 linux2.6
> [...]
> What I want to do is to simply keep my repository aligned with Linus
> so I simply have to do:
> cd linus2.6
> cg-fetch
> [...]
> How can I confg git in order to, by default, use git instead of rsync ?
It should use the git protocol by default; cg-clone will make an
'origin' branch (cogito doesn't support .git/remotes/ yet) pointing to
the original source. Future 'cg-fetch' invocations default to the origin
branch.
Try using 'cg-branch-ls' to see what's on your origin branch.
> Now my dumb question is... since I want to build that kernel do I have
> to locally clone/copy it in order to don't modify any file on my local
> tree?
> If I don't do so, I guess git/cogito will not be happy when I run
> cg-fetch, right?
cg-fetch just pulls Linus' changes to your 'origin' head. You will then
have to cg-merge the changes into your branch. You can do both at once
with cg-update. If there are conflits, then cogito will notify you.
-Peff
^ permalink raw reply
* How to find a revision's branch name
From: Marco Costalba @ 2006-03-18 6:02 UTC (permalink / raw)
To: junkio; +Cc: git
In today git archive, todo branch.
$ git-rev-list -n1 --header b14e2494b8a70737066f4ade4df1b5559e81b44b
b14e2494b8a70737066f4ade4df1b5559e81b44b
tree 1baa1f8405d1fef90fe95f2477133a69adec288b
parent 8158d510c641e2354cf24a10bc3e994c7a1e3125
author Junio C Hamano <junkio@cox.net> 1137562948 -0800
committer Junio C Hamano <junkio@cox.net> 1137562948 -0800
TODO updates 2006-01-17.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Is it possible to get branch name from a revision sha?
Something like
$ git branch b14e2494b8a70737066f4ade4df1b5559e81b44b
todo
I need this to correctly annotate files not in HEAD tree. Currently qgit runs
git-rev-list --header --topo-order --parents --remove-empty HEAD -- <path>
to get a file history. But this fails if <path> is not found in HEAD. The right
command to run in our case should be:
git-rev-list --header --topo-order --parents --remove-empty todo -- <path>
So I need to get 'todo' branch name from a given revision sha's.
BTW also git blame fails (gracefully) if revision is not in HEAD:
$ git blame b14e2494b8a70737066f4ade4df1b5559e81b44b
b14e2494b8a70737066f4ade4df1b5559e81b44b not found in HEAD
Thanks
Marco
^ permalink raw reply
* Re: How to find a revision's branch name
From: Junio C Hamano @ 2006-03-18 6:37 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550603172202ia4b69f2he5562b826e491426@mail.gmail.com>
Marco Costalba <mcostalba@gmail.com> writes:
> Is it possible to get branch name from a revision sha?
> Something like
>
> $ git branch b14e2494b8a70737066f4ade4df1b5559e81b44b
> todo
That is in general impossible.
$ git show-branch master~1 next pu
! [master~1] blame: Nicer output
! [next] Merge branch 'jc/cvsimport' into next
! [pu] Merge branch 'jc/cvsimport' into next
---
-- [next] Merge branch 'jc/cvsimport' into next
++ [next^2] cvsimport: honor -i and non -i upon subsequent
imports
-- [next^] Merge branch 'jc/fetch' into next
++ [next^^2] fetch: exit non-zero when fast-forward check
fails.
-- [next~2] Merge branch 'ew/abbrev' into next
++ [next~2^2] ls-files: add --abbrev[=<n>] option
++ [next~2^2^] ls-tree: add --abbrev[=<n>] option
++ [next^2^] blame: Fix git-blame <directory>
+++ [master~1] blame: Nicer output
$ git rev-parse --verify master~1
88a8b7955666ed8fa5924fadbb3bb58984eaa6af
Now what should this command say?
$ git branch --tell 88a8b7955666ed8fa5924fadbb3bb58984eaa6af
It is not head of any branch. Should it say master~1?
next^2~1? pu^2~1?
The closest thing is name-rev, which tries to give you the
simplest. It may or may not match what you want:
$ git name-rev 88a8b7955666ed8fa5924fadbb3bb58984eaa6af
88a8b7955666ed8fa5924fadbb3bb58984eaa6af master~1
$ git name-rev `git rev-parse --verify b14e24`
b14e2494b8a70737066f4ade4df1b5559e81b44b todo~16
However.
> I need this to correctly annotate files not in HEAD
> tree. Currently qgit runs git-rev-list --header --topo-order
> --parents --remove-empty HEAD -- <path>
>
> to get a file history. But this fails if <path> is not found
> in HEAD. The right command to run in our case should be:
> git-rev-list --header --topo-order --parents --remove-empty
> todo -- <path>
... I wonder why you care. Wouldn't this work just as well?
$ git rev-list --header --topo-order --parents --remove-empty \
--all -- <path>
It lists 70 commits at the moment.
^ permalink raw reply
* Re: Possible --remove-empty bug
From: Junio C Hamano @ 2006-03-18 6:40 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, Linus Torvalds
In-Reply-To: <e5bfff550603170257u21ee6583jabe5a6409cc40766@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> On 3/13/06, Linus Torvalds <torvalds@osdl.org> wrote:
>>
>> However, to be honest, the only reason to ever use --remove-empty is for
>> rename detection, and Frederik's approach of doing that through the
>> library interface directly is actually a much superior option. So we might
>> as well drop the compilcation of --remove-empty entirely, unless somebody
>> has already started using it.
>
> In case of a rather recent file --remove-empty option gives a good
> speed up in history loading with git-rev-list. So qgit uses that
> option.
So you _do_ use it, and I think I still have that remove-empty
stuff held back in "next" branch. Should I unleash it?
^ 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