* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-31 1:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Alex Riesen, git, Linus Torvalds
In-Reply-To: <17452.28122.129442.49226@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Alex Riesen writes:
>
>> The old gitk produced a denser graph, which wasn't perfect too, but
>> had a higher count of visible commit titles (and this is two-monitor
>> setup, too).
>
> I just pushed a new version which does better on this.
Thanks. Pulled, merged and pushed out..
^ permalink raw reply
* Re: [PATCH] cvsimport: use git-update-ref when updating
From: Junio C Hamano @ 2006-03-31 1:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0603301405160.18852@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This simplifies code, and also fixes a subtle bug: when importing in a
> shared repository, where another user last imported from CVS, cvsimport
> used to complain that it could not open <branch> for update.
The second hunk look sensible but I do not know about "use Fcntl"
since I do not see anything you are adding that starts to use it...
^ permalink raw reply
* [PATCH/RFC 2/2] Make path-limiting be incremental when possible.
From: Linus Torvalds @ 2006-03-31 1:05 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0603301648530.27203@g5.osdl.org>
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes it things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/revision.c b/revision.c
index 0330f9f..0e3f074 100644
--- a/revision.c
+++ b/revision.c
@@ -702,7 +702,13 @@ int setup_revisions(int argc, const char
if (revs->prune_data) {
diff_tree_setup_paths(revs->prune_data);
revs->prune_fn = try_to_simplify_commit;
- revs->limited = 1;
+
+ /*
+ * If we fix up parent data, we currently cannot
+ * do that on-the-fly.
+ */
+ if (revs->parents)
+ revs->limited = 1;
}
return left;
@@ -763,23 +769,32 @@ struct commit *get_revision(struct rev_i
do {
struct commit *commit = revs->commits->item;
+
+ revs->commits = revs->commits->next;
+ /*
+ * If we haven't done the list limiting, we need to look at
+ * the parents here
+ */
+ if (!revs->limited)
+ add_parents_to_list(revs, commit, &revs->commits);
if (commit->object.flags & SHOWN)
- goto next;
+ continue;
if (!(commit->object.flags & BOUNDARY) &&
(commit->object.flags & UNINTERESTING))
- goto next;
+ continue;
if (revs->min_age != -1 && (commit->date > revs->min_age))
- goto next;
+ continue;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
if (revs->no_merges &&
commit->parents && commit->parents->next)
- goto next;
+ continue;
if (revs->prune_fn && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
- goto next;
- rewrite_parents(commit);
+ continue;
+ if (revs->parents)
+ rewrite_parents(commit);
}
/* More to go? */
if (revs->max_count) {
@@ -792,13 +807,9 @@ struct commit *get_revision(struct rev_i
revs->commits = it->next;
free(it);
}
- else
- pop_most_recent_commit(&revs->commits, SEEN);
}
commit->object.flags |= SHOWN;
return commit;
-next:
- pop_most_recent_commit(&revs->commits, SEEN);
} while (revs->commits);
return NULL;
}
^ permalink raw reply related
* [PATCH/RFC 1/2] Move "--parent" parsing into generic revision.c library code
From: Linus Torvalds @ 2006-03-31 0:52 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Move "--parent" parsing into generic revision.c library code
Not only do we do it in both rev-list.c and git.c, the revision walking
code will soon want to know whether we should rewrite parenthood
information or not.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is the trivial part. The next email will contain the real meat of the
change, which starts doing path limiting incrementally, and makes doing
things like
git log drivers/
on the kernel a hell of a lot more pleasant, because it starts outputting
the log immediately instead of pausing for about 20 seconds before it has
parsed all of the history and then outputting it all in one go.
There's a HUGE difference to the "feel" of doing pathname limiting
git-rev-list options. Not very well tested, but at least this initial
preparatory patch is "obviously safe".
diff --git a/git.c b/git.c
index 0b40e30..72039c6 100644
--- a/git.c
+++ b/git.c
@@ -283,7 +283,6 @@ static int cmd_log(int argc, const char
char *buf = xmalloc(LOGSIZE);
static enum cmit_fmt commit_format = CMIT_FMT_DEFAULT;
int abbrev = DEFAULT_ABBREV;
- int show_parents = 0;
const char *commit_prefix = "commit ";
argc = setup_revisions(argc, argv, &rev, "HEAD");
@@ -294,9 +293,6 @@ static int cmd_log(int argc, const char
if (commit_format == CMIT_FMT_ONELINE)
commit_prefix = "";
}
- else if (!strcmp(arg, "--parents")) {
- show_parents = 1;
- }
else if (!strcmp(arg, "--no-abbrev")) {
abbrev = 0;
}
@@ -317,7 +313,7 @@ static int cmd_log(int argc, const char
while ((commit = get_revision(&rev)) != NULL) {
printf("%s%s", commit_prefix,
sha1_to_hex(commit->object.sha1));
- if (show_parents) {
+ if (rev.parents) {
struct commit_list *parents = commit->parents;
while (parents) {
struct object *o = &(parents->item->object);
diff --git a/rev-list.c b/rev-list.c
index f3a989c..19a547a 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -39,7 +39,6 @@ struct rev_info revs;
static int bisect_list = 0;
static int verbose_header = 0;
static int abbrev = DEFAULT_ABBREV;
-static int show_parents = 0;
static int show_timestamp = 0;
static int hdr_termination = 0;
static const char *commit_prefix = "";
@@ -54,7 +53,7 @@ static void show_commit(struct commit *c
if (commit->object.flags & BOUNDARY)
putchar('-');
fputs(sha1_to_hex(commit->object.sha1), stdout);
- if (show_parents) {
+ if (revs.parents) {
struct commit_list *parents = commit->parents;
while (parents) {
struct object *o = &(parents->item->object);
@@ -336,10 +335,6 @@ int main(int argc, const char **argv)
commit_prefix = "";
else
commit_prefix = "commit ";
- continue;
- }
- if (!strcmp(arg, "--parents")) {
- show_parents = 1;
continue;
}
if (!strcmp(arg, "--timestamp")) {
diff --git a/revision.c b/revision.c
index abc8745..0330f9f 100644
--- a/revision.c
+++ b/revision.c
@@ -596,6 +596,10 @@ int setup_revisions(int argc, const char
revs->limited = 1;
continue;
}
+ if (!strcmp(arg, "--parents")) {
+ revs->parents = 1;
+ continue;
+ }
if (!strcmp(arg, "--dense")) {
revs->dense = 1;
continue;
diff --git a/revision.h b/revision.h
index 61e6bc9..0caeecf 100644
--- a/revision.h
+++ b/revision.h
@@ -34,7 +34,8 @@ struct rev_info {
edge_hint:1,
limited:1,
unpacked:1,
- boundary:1;
+ boundary:1,
+ parents:1;
/* special limits */
int max_count;
^ permalink raw reply related
* [PATCH] cg-log: Remove unpleasant DEL characters.
From: Mark Wooding @ 2006-03-31 0:08 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
There's a Bash bug (I'm running 3.1.5(1)-release from Debian testing) as
follows:
$ foo=@; echo "<${foo:1}>" | cat -v
<^?>
Without this fix, less gives me ugly standout `^?' markers for every
blank line in a commit message.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
cg-log | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-log b/cg-log
index 5d5407b..b3374e4 100755
--- a/cg-log
+++ b/cg-log
@@ -181,7 +181,7 @@ process_commit_line()
{
if [ "$key" = "%" ] || [ "$key" = "%$colsignoff" ]; then
# The fast common case
- [ "$state" = silent ] || msg="$msg ${rest:1}
+ [ "$state" = silent ] || msg="$msg ${rest#?}
"
return
fi
^ permalink raw reply related
* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-30 23:46 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20060330205759.GA27131@steel.home>
Alex Riesen writes:
> The old gitk produced a denser graph, which wasn't perfect too, but
> had a higher count of visible commit titles (and this is two-monitor
> setup, too).
I just pushed a new version which does better on this.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Johannes Schindelin @ 2006-03-30 23:20 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne2o8lr.l0.mdw@metalzone.distorted.org.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 752 bytes --]
Hi,
On Thu, 30 Mar 2006, Mark Wooding wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>
> > Does anybody know what is going on?
>
> I'll try staring at the Tcl source code some time. I'm rather too busy
> tonight, though.
>
> There's also some very strange geometry management oddness going on in
> gitk. I'll try to sort that out too.
That has been discussed. My feeling is that this is a bug of Tk with
regard to rootless X servers. I never came around to do a proper patch,
but I have explicit -height and -width arguments to all frames and
panedwindows.
If you want to start working on it, I attached my current patch, which is
good enough for me, but note that it changes the geometry subtly everytime
gitk is called...
Hth,
Dscho
[-- Attachment #2: Type: TEXT/plain, Size: 1642 bytes --]
[PATCH] gitk: make geometry less weird on cygwin and macosx
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
gitk | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gitk b/gitk
index 03cd475..7339069 100755
--- a/gitk
+++ b/gitk
@@ -373,13 +373,13 @@ proc makewindow {rargs} {
set geometry(ctexth) [expr {($texth - 8) /
[font metrics $textfont -linespace]}]
}
- frame .ctop.top
+ frame .ctop.top -height $geometry(canvh)
frame .ctop.top.bar
pack .ctop.top.bar -side bottom -fill x
set cscroll .ctop.top.csb
scrollbar $cscroll -command {allcanvs yview} -highlightthickness 0
pack $cscroll -side right -fill y
- panedwindow .ctop.top.clist -orient horizontal -sashpad 0 -handlesize 4
+ panedwindow .ctop.top.clist -orient horizontal -sashpad 0 -handlesize 4 -height $geometry(canvh)
pack .ctop.top.clist -side top -fill both -expand 1
.ctop add .ctop.top
set canv .ctop.top.clist.canv
@@ -449,9 +449,10 @@ proc makewindow {rargs} {
# for making sure type==Exact whenever loc==Pickaxe
trace add variable findloc write findlocchange
- panedwindow .ctop.cdet -orient horizontal
+ panedwindow .ctop.cdet -orient horizontal \
+ -height [expr $geometry(ctexth)*$linespc+4]
.ctop add .ctop.cdet
- frame .ctop.cdet.left
+ frame .ctop.cdet.left -width [expr $geometry(ctextw)*[font measure $textfont "0"]+8]
set ctext .ctop.cdet.left.ctext
text $ctext -bg white -state disabled -font $textfont \
-width $geometry(ctextw) -height $geometry(ctexth) \
^ permalink raw reply related
* Re: Gitk strangeness..
From: Paul Mackerras @ 2006-03-30 22:33 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20060330205759.GA27131@steel.home>
Alex Riesen writes:
> Well... Could you take a look at these screenshots, please?
> http://home.arcor.de/fork0/bug/gitk1.jpg (this one is BIG, 400k, 2456x949)
> http://home.arcor.de/fork0/bug/gitk2.jpg
> http://home.arcor.de/fork0/bug/gitk3.jpg
Yes, I was just looking last night at the part of the git.git graph
that you have there in gitk1.jpg. That's an artifact of some changes
I made to make sure there was a vertical line segment just before an
arrow. The reason for doing that is that Tk 8.4 seems to just punt on
drawing an arrow on the end of a diagonal line segment. The old gitk
just removed trailing diagonal segments of the line, but I thought I
could do better than that.
I'll try another approach.
Paul.
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Matt McCutchen @ 2006-03-30 21:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603300919280.27203@g5.osdl.org>
On Thu, 2006-03-30 at 09:32 -0800, Linus Torvalds wrote:
> The beauty of git should be (and maybe that's not entirely true simply
> because of practical concerns) that there really need not be any notion of
> "more official".
I understand this, and it is one of several reasons why I prefer git to
other version control systems. However, I thought there would be a
single official kernel repository even if git didn't require it. Junio
explained to me that both yours and the stable one are official for
different purposes. I think I will use the stable one because it is
current enough for my needs.
> - the more fundamental one is that when you start mixing branches, you
> have to be very careful if you expect the upstream projects to pull the
> changes _back_. [...]
True. It might help several branches coordinate development if a commit
could be marked as "equivalent" to another commit so that, if both were
involved in a merge, one could be thrown out.
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: Gitk strangeness..
From: Alex Riesen @ 2006-03-30 20:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <17449.48630.370867.10251@cargo.ozlabs.ibm.com>
Paul Mackerras, Wed, Mar 29, 2006 00:51:34 +0200:
> Junio C Hamano writes:
>
> > How about this alternative patch, then? It turned out to be
> > quite convoluted as I feared.
>
> That's brilliant. Thank you! With the patch to gitk below, the
> graph display on Linus' example looks much saner.
>
Well... Could you take a look at these screenshots, please?
http://home.arcor.de/fork0/bug/gitk1.jpg (this one is BIG, 400k, 2456x949)
http://home.arcor.de/fork0/bug/gitk2.jpg
http://home.arcor.de/fork0/bug/gitk3.jpg
The compressed repository is being uploaded there:
http://home.arcor.de/fork0/bug/ggg.tar.bz2 (~6Mb)
The old gitk produced a denser graph, which wasn't perfect too, but
had a higher count of visible commit titles (and this is two-monitor
setup, too).
^ permalink raw reply
* Re: Possible --boundary bug
From: Marco Costalba @ 2006-03-30 20:55 UTC (permalink / raw)
To: junkio; +Cc: git
In-Reply-To: <e5bfff550603301034r58b38500ie5897ed06fce6e9a@mail.gmail.com>
Sorry, the good description is below, please ignore the wrong previous one.
On 3/30/06, Marco Costalba <mcostalba@gmail.com> wrote:
> Trying to convert qgit to use the new and cool --boundary option I
> found this one:
>
> From git tree
>
> $ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
> grep eb38cc689e8
> -e646de0d14bac20ef6e156c1742b9e62fb0b9020
> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
> 4b953cdc04fec8783e2c654a671005492fda9b01
> 5ca5396c9ecba947c8faac7673195d309a6ba2ea
> eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
>
> and also
>
> $ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
> grep c64965750
> 8c0db2f5193153ea8a51bb45b0512c5a3889023b
> 21a02335f821c89a989cf0b533d2ae0adb6da16e
> c649657501bada28794a30102d9c13cc28ca0e5e
>
It seems the lines:
-c649657501bada28794a30102d9c13cc28ca0e5e .......
and
-eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4 ......
are missing though the two revs are boundary revs.
Marco
P.S: Sorry for lengthy output but --abbrev option:
git-rev-list --boundary --topo-order --abbrev=8 --parents 5aa44d5..ab57c8d
does seems to work only for prettyprinted parent names, I guess this
from patches log messages because is not documented.
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Christopher Faylor @ 2006-03-30 20:13 UTC (permalink / raw)
To: Junio C Hamano, Mark Wooding, git
In-Reply-To: <7v8xqr3iwt.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 30, 2006 at 10:08:02AM -0800, Junio C Hamano wrote:
>Mark Wooding <mdw@distorted.org.uk> writes:
>
>> From: Mark Wooding <mdw@distorted.org.uk>
>>
>> For some reason, the Cygwin Tcl's `exec' command has trouble running
>> scripts...
>
>Yup, I've seen this and have a "personal edition" workaround
>exactly like yours. I haven't bothered to put it in even "pu",
>because I am reluctant to add an workaround to a problem I do
>not understand (and I haven't bothered to try understanding the
>problem which happens only on Windows ;-).
>
>Does anybody know what is going on?
Currently, Cygwin's tcl is a pure windows version which uses
CreateProcess to run stuff. It doesn't know about scripts and possibly
doesn't even know about cygwin paths.
cgf
^ permalink raw reply
* Possible --boundary bug
From: Marco Costalba @ 2006-03-30 18:34 UTC (permalink / raw)
To: junkio; +Cc: git
Trying to convert qgit to use the new and cool --boundary option I
found this one:
>From git tree
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep eb38cc689e8
-e646de0d14bac20ef6e156c1742b9e62fb0b9020
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
4b953cdc04fec8783e2c654a671005492fda9b01
5ca5396c9ecba947c8faac7673195d309a6ba2ea
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
and also
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep c64965750
8c0db2f5193153ea8a51bb45b0512c5a3889023b
21a02335f821c89a989cf0b533d2ae0adb6da16e
c649657501bada28794a30102d9c13cc28ca0e5e
But perhaps correct output should be:
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep eb38cc689e8
-e646de0d14bac20ef6e156c1742b9e62fb0b9020
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
-4b953cdc04fec8783e2c654a671005492fda9b01
5ca5396c9ecba947c8faac7673195d309a6ba2ea
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
and
$ git-rev-list --boundary --topo-order --parents 5aa44d5..ab57c8d |
grep c64965750
-8c0db2f5193153ea8a51bb45b0512c5a3889023b
21a02335f821c89a989cf0b533d2ae0adb6da16e
c649657501bada28794a30102d9c13cc28ca0e5e
It seems the '-' flag is mistakenly missing because of boundary revs:
c649657501bada28794a30102d9c13cc28ca0e5e and
eb38cc689e84a8fd01c1856e889fe8d3b4f1bfb4
Marco
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Mark Wooding @ 2006-03-30 18:26 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xqr3iwt.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Does anybody know what is going on?
I'll try staring at the Tcl source code some time. I'm rather too busy
tonight, though.
There's also some very strange geometry management oddness going on in
gitk. I'll try to sort that out too.
-- [mdw]
^ permalink raw reply
* Re: [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Junio C Hamano @ 2006-03-30 18:08 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <20060330123151.25779.73775.stgit@metalzone.distorted.org.uk>
Mark Wooding <mdw@distorted.org.uk> writes:
> From: Mark Wooding <mdw@distorted.org.uk>
>
> For some reason, the Cygwin Tcl's `exec' command has trouble running
> scripts...
Yup, I've seen this and have a "personal edition" workaround
exactly like yours. I haven't bothered to put it in even "pu",
because I am reluctant to add an workaround to a problem I do
not understand (and I haven't bothered to try understanding the
problem which happens only on Windows ;-).
Does anybody know what is going on?
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-30 17:32 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1143687710.2524.1.camel@mattlaptop.metaesthetics.net>
On Wed, 29 Mar 2006, Matt McCutchen wrote:
>
> Perhaps this is just politics, but which kernel repository is more
> official, and why? Linus's or the one I have been using,
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git
> ?
The beauty of git should be (and maybe that's not entirely true simply
because of practical concerns) that there really need not be any notion of
"more official".
You can fetch multiple different git trees from different sources into the
same git tree, and then keep them _all_ around equally as different
branches. You can move fixes between the different branches with "git
cherry-pick", and you can merge different branches with "git merge"
Now, the reason I say "_should_ be" rather than "is" is two-fold:
- right now, a lot of the infrastructure is simply set up more towards
the "one single source repository" model. When you do a "git clone", it
kind of makes the origin special. That's how all the documentation is
written, and that's also the only remote branch that git creates
_automatically_ for you.
This really isn't a technical issue: the git code code doesn't care
about any special "original" repository. But the fact that you have to
create the ".git/remotes/linus" file by hand, and that all the examples
in the docs end up talking about a single "origin" branch means that
people _think_ of git as a "single origin" thing.
- the more fundamental one is that when you start mixing branches, you
have to be very careful if you expect the upstream projects to pull the
changes _back_. In particular, that's where you have to think twice (or
three times) about doing a "git merge" (or a "git pull", which
implicitly merges for you if it's not a pure fast-forward).
In particular, the fact that _you_ want to merge two trees that came
from different sources does _not_ imply that either of the two sources
might want to merge with each other. So if you merge the two together,
you may find it impossible to have either of them then pull from you:
they way want your changes, but they might not like the merge you did,
because they have different policies about that work than you did.
So while the first point is purely a "mental model" issue and about lack
of helper scripts, the second point is fundamental.
For example, in your case it was almost certainly the right thing to do to
cherry-pick your changes from the 2.6.15.6 branch onto the development
branch, because I simply don't want to merge the 2.6.15.6 stuff into the
standard tree: part of the _rules_ for the stable branch is that the
things it fixes should have been fixed in the development tree already, so
merging the stable tree should always be unnecessary (and often clash,
although _hopefully_ in many cases the fixes in the stable tree are 1:1
identical and will merge beautifully).
Anyway: from a technical standpoint, no tree should be "special" or "more
official" for git usage. But when merging data back to any of those trees
that aren't special, the source/history of the data is important to keep
in mind. Branch "a" may not be any more special than branch "b", but when
you push changes back to the source of branch "a", the history of those
changes (relative to what the source was) is meaningful.
Linus
^ permalink raw reply
* [PATCH] git-clone: exit early if repo isn't specified
From: Yasushi SHOJI @ 2006-03-30 17:01 UTC (permalink / raw)
To: git
Subject: [PATCH] git-clone: exit early if repo isn't specified
git-clone without a repo isn't useful at all. print message and get
out asap.
This patch also move the variable 'local' to where other variables are
initialized.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
git-clone.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
a222289a855194280aade24baa005de9e55667d0
diff --git a/git-clone.sh b/git-clone.sh
index a731d15..7b05fd9 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -98,6 +98,7 @@ close FH;
'
quiet=
+local=no
use_local=no
local_shared=no
no_checkout=
@@ -155,6 +156,13 @@ do
shift
done
+repo="$1"
+if test -z "$repo"
+then
+ echo >&2 'you must specify a repository to clone.'
+ exit 1
+fi
+
# --bare implies --no-checkout
if test yes = "$bare"
then
@@ -178,8 +186,6 @@ fi
# Turn the source into an absolute path if
# it is local
-repo="$1"
-local=no
if base=$(get_repo_base "$repo"); then
repo="$base"
local=yes
--
1.3.0.rc1.gb8abc
^ permalink raw reply related
* [PATCH] Make git-clone to take long double-dashed origin option (--origin)
From: Yasushi SHOJI @ 2006-03-30 17:00 UTC (permalink / raw)
To: git
Subject: [PATCH] Make git-clone to take long double-dashed origin option (--origin)
git-clone currently take option '-o' to specify origin. this patch
makes git-clone to take double-dashed option '--origin' and other
abbreviations in addtion to the current single-dashed option.
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com>
---
git-clone.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
6585a854a571f3978652c06cc746b3d9e501359d
diff --git a/git-clone.sh b/git-clone.sh
index 6887321..a731d15 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -9,7 +9,7 @@ # See git-sh-setup why.
unset CDPATH
usage() {
- echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [-o <name>] [-n] <repo> [<dir>]"
+ echo >&2 "Usage: $0 [--use-separate-remote] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [-n] <repo> [<dir>]"
exit 1
}
@@ -127,7 +127,7 @@ while
shift; reference="$1" ;;
*,--reference=*)
reference=`expr "$1" : '--reference=\(.*\)'` ;;
- *,-o)
+ *,-o|*,--or|*,--ori|*,--orig|*,--origi|*,--origin)
case "$2" in
*/*)
echo >&2 "'$2' is not suitable for an origin name"
@@ -138,7 +138,7 @@ while
exit 1
}
test -z "$origin_override" || {
- echo >&2 "Do not give more than one -o options."
+ echo >&2 "Do not give more than one --origin options."
exit 1
}
origin_override=yes
@@ -160,7 +160,7 @@ if test yes = "$bare"
then
if test yes = "$origin_override"
then
- echo >&2 '--bare and -o $origin options are incompatible.'
+ echo >&2 '--bare and --origin $origin options are incompatible.'
exit 1
fi
if test t = "$use_separate_remote"
--
1.3.0.rc1.gb8abc
^ permalink raw reply related
* head_points_at checked in as 47874d6
From: Yasushi SHOJI @ 2006-03-30 15:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi Junio,
Would you kindly explain what you are intended to do with the
following code checked in as 47874d6d9a7f49ade6388df049597f03365961ca ?
# The name under $remote_top the remote HEAD seems to point at
head_points_at=$(
(
echo "master"
cd "$GIT_DIR/$remote_top" &&
find . -type f -print | sed -e 's/^\.\///'
) | (
done=f
while read name
do
test t = $done && continue
branch_tip=`cat "$GIT_DIR/$remote_top/$name"`
if test "$head_sha1" = "$branch_tip"
then
echo "$name"
done=t
fi
done
)
)
What I don't understand are:
- why do we have to do 'echo "master"' for the top of the loop? is
this an optimization?
- why do we keep looping after done=t?
I just noticed this when I tried to clone a repo _without_ master
branch.
Thanks for your time. And sorry for my ignorants.
--
yashi
^ permalink raw reply
* Re: [PATCH] Ability to automaticaly push tags to remote repositories.
From: Krzysiek Pawlik @ 2006-03-30 14:18 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <442BD562.3030207@people.pl>
[-- Attachment #1.1: Type: text/plain, Size: 182 bytes --]
Krzysiek Pawlik wrote:
> Comments, suggestions?
Broken when there are no tags. Attached patch fixes it.
--
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
[-- Attachment #1.2: fix-no-tags.patch --]
[-- Type: text/plain, Size: 1025 bytes --]
Fix auto-push of tags when there are no tags.
---
commit eff67bafe333c28c238feb614f098b987216ffb0
tree 8758ae4a2eace9c4fdf64ec89c1f983871097a74
parent 6e581cf43ccf7236ea47ac4ba9b51df9cda3c671
author Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 16:10:26 +0200
committer Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 16:10:26 +0200
cg-push | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-push b/cg-push
index 865cbd5..40016c1 100755
--- a/cg-push
+++ b/cg-push
@@ -60,7 +60,7 @@ if [ "${auto_push_tags}" = "yes" ]; then
if [ ! -d "$_git/cogito-tags-pushed" ]; then
mkdir "$_git/cogito-tags-pushed" || die "can't create cache for pushed tags"
fi
- for i in `cg-tag-ls | awk '{print $1}'`; do
+ for i in `cg-tag-ls 2> /dev/null | awk '{print $1}'`; do
if [ ! -f "$_git/cogito-tags-pushed/${i}" ]; then
echo "Adding ${i} to list of tags to push"
tags[${#tags[@]}]="refs/tags/${i}"
\f
!-------------------------------------------------------------flip-
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply related
* [PATCH] Ability to automaticaly push tags to remote repositories.
From: Krzysiek Pawlik @ 2006-03-30 12:56 UTC (permalink / raw)
To: Git Mailing List
[-- Attachment #1: Type: text/plain, Size: 688 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- From `cg-push --long-help`:
- -t TAG::
Tells cg-push to also push the given tag. Note that in the
future, cg-push should push tags automatically. Also note
that even if you pass `cg-push` the '-t' arguments, your
HEAD is still pushed as well in addition to the tags.
One of possible ways of doing it is in attached patch. Comments,
suggestions?
- --
Krzysiek Pawlik (Nelchael)
RLU #322999 GPG Key ID: 0xBC555551
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFEK9Vigo/w9rxVVVERAvXkAJ42ESjs3REY0ECqIYlbz+9WX/3+ZQCfSQs/
B4X6U2io0Wq0/0oiolpUW1g=
=3ZR7
-----END PGP SIGNATURE-----
[-- Attachment #2: cg-push-tags.patch --]
[-- Type: text/plain, Size: 1475 bytes --]
Ability to automaticaly push tags to remote repositories.
---
commit 6e581cf43ccf7236ea47ac4ba9b51df9cda3c671
tree b440cb8e4629c5c77e38fb6179992b52edf8c861
parent 891c6d85f38a326e91d62906e1696a38d28fb105
author Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 14:48:36 +0200
committer Krzysiek Pawlik <kpawlik@silvermedia.pl> Thu, 30 Mar 2006 14:48:36 +0200
cg-push | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/cg-push b/cg-push
index 4332b28..865cbd5 100755
--- a/cg-push
+++ b/cg-push
@@ -43,17 +43,32 @@ send_pack_update()
locbranch="$_git_head"
tags=()
+auto_push_tags=yes
while optparse; do
if optparse -r=; then
locbranch="$OPTARG"
[ "$(cg-object-id -c "$locbranch")" ] || exit 1
elif optparse -t=; then
tags[${#tags[@]}]="refs/tags/$OPTARG"
+ auto_push_tags=no
else
optfail
fi
done
+if [ "${auto_push_tags}" = "yes" ]; then
+ if [ ! -d "$_git/cogito-tags-pushed" ]; then
+ mkdir "$_git/cogito-tags-pushed" || die "can't create cache for pushed tags"
+ fi
+ for i in `cg-tag-ls | awk '{print $1}'`; do
+ if [ ! -f "$_git/cogito-tags-pushed/${i}" ]; then
+ echo "Adding ${i} to list of tags to push"
+ tags[${#tags[@]}]="refs/tags/${i}"
+ touch "$_git/cogito-tags-pushed/${i}"
+ fi
+ done
+fi
+
[ ${#ARGS[@]} -gt 1 ] && die "too many arguments, I can push only one branch at once"
name="${ARGS[0]}"
\f
!-------------------------------------------------------------flip-
^ permalink raw reply related
* [PATCH] gitk: Use git wrapper to run git-ls-remote.
From: Mark Wooding @ 2006-03-30 12:31 UTC (permalink / raw)
To: git
From: Mark Wooding <mdw@distorted.org.uk>
For some reason, the Cygwin Tcl's `exec' command has trouble running
scripts. Fix this by using the C `git' wrapper. Other GIT programs run
by gitk are written in C already, so we don't need to incur a
performance hit of going via the wrapper (which I'll bet isn't pretty
under Cygwin).
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
gitk | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index f4c6624..ac85d1c 100755
--- a/gitk
+++ b/gitk
@@ -359,7 +359,7 @@ proc readrefs {} {
foreach v {tagids idtags headids idheads otherrefids idotherrefs} {
catch {unset $v}
}
- set refd [open [list | git-ls-remote [gitdir]] r]
+ set refd [open [list | git ls-remote [gitdir]] r]
while {0 <= [set n [gets $refd line]]} {
if {![regexp {^([0-9a-f]{40}) refs/([^^]*)$} $line \
match id path]} {
^ permalink raw reply related
* [PATCH] cvsimport: use git-update-ref when updating
From: Johannes Schindelin @ 2006-03-30 12:06 UTC (permalink / raw)
To: git, junkio
This simplifies code, and also fixes a subtle bug: when importing in a
shared repository, where another user last imported from CVS, cvsimport
used to complain that it could not open <branch> for update.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
git-cvsimport.perl | 7 ++-----
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 3728294..957af13 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -15,6 +15,7 @@ # You can change that with the '-o' opti
use strict;
use warnings;
+use Fcntl;
use Getopt::Std;
use File::Spec;
use File::Temp qw(tempfile);
@@ -677,11 +678,7 @@ my $commit = sub {
waitpid($pid,0);
die "Error running git-commit-tree: $?\n" if $?;
- open(C,">$git_dir/refs/heads/$branch")
- or die "Cannot open branch $branch for update: $!\n";
- print C "$cid\n"
- or die "Cannot write branch $branch for update: $!\n";
- close(C)
+ system("git-update-ref refs/heads/$branch $cid") == 0
or die "Cannot write branch $branch for update: $!\n";
if($tag) {
^ permalink raw reply related
* Re: sending git-format-patch files with mailx.
From: Junio C Hamano @ 2006-03-30 9:14 UTC (permalink / raw)
To: David Ho; +Cc: git
In-Reply-To: <4dd15d180603291236j4ca4654fvbe5b6375e8623081@mail.gmail.com>
"David Ho" <davidkwho@gmail.com> writes:
> Very stupid question.
>
> I have patches created by git-format-patch. However I suppose I can
> send it off directly using mailx, but I have a hard time figuring how
> this is done.
>
> Someone here can probably answer this in a second.
Perhaps:
$ mailx -s 'my subject' upstream@maintainer.example.com
~r 0001-my-patch.txt
(that's tilde r).
But I thought we had a command for that: git-send-email. I
admit I haven't used it for anything real, though, since I do
not have an upstream maintainer anymore.
^ permalink raw reply
* [PATCH] contrib/git-svn: force GIT_DIR to an absolute path
From: Eric Wong @ 2006-03-30 6:37 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Eric Wong
We chdir internally, so we need a consistent GIT_DIR variable.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
contrib/git-svn/git-svn.perl | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
40a9f8f87bbf041966c61431536186d03acefb50
diff --git a/contrib/git-svn/git-svn.perl b/contrib/git-svn/git-svn.perl
index 3e5733e..59dd504 100755
--- a/contrib/git-svn/git-svn.perl
+++ b/contrib/git-svn/git-svn.perl
@@ -9,7 +9,11 @@ use vars qw/ $AUTHOR $VERSION
$GIT_DIR $REV_DIR/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '0.11.0';
-$GIT_DIR = $ENV{GIT_DIR} || "$ENV{PWD}/.git";
+
+use Cwd qw/abs_path/;
+$GIT_DIR = abs_path($ENV{GIT_DIR} || '.git');
+$ENV{GIT_DIR} = $GIT_DIR;
+
# make sure the svn binary gives consistent output between locales and TZs:
$ENV{TZ} = 'UTC';
$ENV{LC_ALL} = 'C';
@@ -69,7 +73,6 @@ GetOptions(%opts, 'help|H|h' => \$_help,
$GIT_SVN ||= $ENV{GIT_SVN_ID} || 'git-svn';
$GIT_SVN_INDEX = "$GIT_DIR/$GIT_SVN/index";
-$ENV{GIT_DIR} ||= $GIT_DIR;
$SVN_URL = undef;
$REV_DIR = "$GIT_DIR/$GIT_SVN/revs";
$SVN_WC = "$GIT_DIR/$GIT_SVN/tree";
--
1.3.0.rc1.g709a5
^ permalink raw reply related
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