* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-29 0:50 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Linus Torvalds
In-Reply-To: <17449.48630.370867.10251@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> 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.
>
> Could you check in your patch to the git.git repository, please?
The patch I sent was a total mess, and the one in "pu" right now
was somewhat cleaned up but was still far suboptimal. **Blush**
Most notably, the code from yesterday was re-injecting the
parents of the boundary commits into the list marked as
UNINTERESTING, which was unnecessary and stupid. This one just
pops boundary commits off the list after consuming it.
Here is a cleaned-up one for eyeballing.
Although I am reasonably sure that this does not affect the way
it works when --boundary is not given, I'd pretty much
appreciate an independent sanity check on this one. rev-list is
so fundamental to git.
-- >8 --
diff --git a/rev-list.c b/rev-list.c
index 441c437..f3a989c 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -7,9 +7,9 @@ #include "blob.h"
#include "diff.h"
#include "revision.h"
-/* bits #0-4 in revision.h */
+/* bits #0-5 in revision.h */
-#define COUNTED (1u<<5)
+#define COUNTED (1u<<6)
static const char rev_list_usage[] =
"git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"
@@ -51,6 +51,8 @@ static void show_commit(struct commit *c
printf("%lu ", commit->date);
if (commit_prefix[0])
fputs(commit_prefix, stdout);
+ if (commit->object.flags & BOUNDARY)
+ putchar('-');
fputs(sha1_to_hex(commit->object.sha1), stdout);
if (show_parents) {
struct commit_list *parents = commit->parents;
diff --git a/revision.c b/revision.c
index d7678cf..745b0d2 100644
--- a/revision.c
+++ b/revision.c
@@ -419,6 +419,27 @@ static void limit_list(struct rev_info *
continue;
p = &commit_list_insert(commit, p)->next;
}
+ if (revs->boundary) {
+ list = newlist;
+ while (list) {
+ struct commit *commit = list->item;
+ struct object *obj = &commit->object;
+ struct commit_list *parent = commit->parents;
+ if (obj->flags & (UNINTERESTING|BOUNDARY)) {
+ list = list->next;
+ continue;
+ }
+ while (parent) {
+ struct commit *pcommit = parent->item;
+ parent = parent->next;
+ if (!(pcommit->object.flags & UNINTERESTING))
+ continue;
+ pcommit->object.flags |= BOUNDARY;
+ p = &commit_list_insert(pcommit, p)->next;
+ }
+ list = list->next;
+ }
+ }
revs->commits = newlist;
}
@@ -591,6 +612,10 @@ int setup_revisions(int argc, const char
revs->no_merges = 1;
continue;
}
+ if (!strcmp(arg, "--boundary")) {
+ revs->boundary = 1;
+ continue;
+ }
if (!strcmp(arg, "--objects")) {
revs->tag_objects = 1;
revs->tree_objects = 1;
@@ -731,13 +756,17 @@ struct commit *get_revision(struct rev_i
do {
struct commit *commit = revs->commits->item;
- if (commit->object.flags & (UNINTERESTING|SHOWN))
+ if (commit->object.flags & SHOWN)
+ goto next;
+ if (!(commit->object.flags & BOUNDARY) &&
+ (commit->object.flags & UNINTERESTING))
goto next;
if (revs->min_age != -1 && (commit->date > revs->min_age))
goto next;
if (revs->max_age != -1 && (commit->date < revs->max_age))
return NULL;
- if (revs->no_merges && commit->parents && commit->parents->next)
+ if (revs->no_merges &&
+ commit->parents && commit->parents->next)
goto next;
if (revs->prune_fn && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
@@ -745,8 +774,19 @@ struct commit *get_revision(struct rev_i
rewrite_parents(commit);
}
/* More to go? */
- if (revs->max_count)
- pop_most_recent_commit(&revs->commits, SEEN);
+ if (revs->max_count) {
+ if (commit->object.flags & BOUNDARY) {
+ /* this is already uninteresting,
+ * so there is no point popping its
+ * parents into the list.
+ */
+ struct commit_list *it = revs->commits;
+ revs->commits = it->next;
+ free(it);
+ }
+ else
+ pop_most_recent_commit(&revs->commits, SEEN);
+ }
commit->object.flags |= SHOWN;
return commit;
next:
diff --git a/revision.h b/revision.h
index 6c2beca..61e6bc9 100644
--- a/revision.h
+++ b/revision.h
@@ -6,6 +6,7 @@ #define UNINTERESTING (1u<<1)
#define TREECHANGE (1u<<2)
#define SHOWN (1u<<3)
#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
+#define BOUNDARY (1u<<5)
struct rev_info;
@@ -32,7 +33,8 @@ struct rev_info {
blob_objects:1,
edge_hint:1,
limited:1,
- unpacked:1;
+ unpacked:1,
+ boundary:1;
/* special limits */
int max_count;
^ permalink raw reply related
* Re: git pull fails
From: Petr Baudis @ 2006-03-29 0:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu09igk1t.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Mar 29, 2006 at 02:40:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > If your current branch would really be a remote branch and you simply
> > git-fetched, your HEAD would change but not your working tree, and at
> > that moment things would become very confusing. Cogito would start
> > showing nonsensical stuff for cg-status and cg-diff (as well as
> > git-diff-tree HEAD output), but your index would at least still be
> > correct so I'm not sure how much attention do tools like git-diff pay to
> > it, the level of messup would be proportional to that.
>
> People want to leave tracking branches checked out, especially
> when they are not developers but are "update to the latest and
> compile the bleeding edge" types. Support for that mode of
> operation was invented long time ago and git-pull knows about
> it, and the idea was ported to git-cvsimport recently.
Why can't such people just have two branches, _especially_ if they are
the "update to the latest and compile the bleeding edge" types?
(Therefore well not likely to be familiar with the Git branching model
at all.)
I mean, sure, it's Core Git so the extra flexibility is nice. But I now
wonder, can you think of any plausible workflow where having one branch
instead of two would be an advantage?
Waah, cg-log git-fetch.sh, /update-head just showed me the change in
git-fetch-script from last August, with no extra work for me. The big
rename barrier annoyances finally gone forever!
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Matt McCutchen @ 2006-03-29 1:43 UTC (permalink / raw)
To: git
Dear git people,
I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
2.6.15 kernel repository (which was then at version 2.6.15.6) and making
several commits. Now I would like a Linux kernel based on 2.6.16 with
the same customizations. This seems to be a very simple task, but I
have been trying various combinations of git commands for several days
and have not figured out how to do it.
I believe that means I should pull the 2.6.16 kernel into the "origin"
branch and then rebase the "master" branch, merging my customizations
with 2.6.16. To this end, I switched my remote file to point to the
2.6.16 stable repository and tried to pull. The result was not what I
wanted. The situation is complicated by the fact that 2.6.15.6 is not
an ancestor of 2.6.16. The warning in the man page about branches that
are modified nonlinearly seems to apply.
How do I make my customized 2.6.16 kernel?
--
Matt McCutchen
hashproduct@verizon.net
http://hashproduct.metaesthetics.net/
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Linus Torvalds @ 2006-03-29 2:10 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1143596622.2481.10.camel@mattlaptop.metaesthetics.net>
On Tue, 28 Mar 2006, Matt McCutchen wrote:
>
> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits. Now I would like a Linux kernel based on 2.6.16 with
> the same customizations. This seems to be a very simple task, but I
> have been trying various combinations of git commands for several days
> and have not figured out how to do it.
>
> I believe that means I should pull the 2.6.16 kernel into the "origin"
> branch and then rebase the "master" branch,
Don't "Pull". "Fetch".
"Pull" implies a merge, which is not what you want.
> To this end, I switched my remote file to point to the
> 2.6.16 stable repository and tried to pull. The result was not what I
> wanted. The situation is complicated by the fact that 2.6.15.6 is not
> an ancestor of 2.6.16. The warning in the man page about branches that
> are modified nonlinearly seems to apply.
Just realize that you can have any number of branches, and instead of
forcing "origin" to be something that it simply is not, just create a new
branch called "linus".
Make that point to my tree, and do
git fetch linus
to update it. It really is that easy.
Exact commands something like this:
(1) Edit your .git/remotes/linus file so that it has the following
contents:
URL: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Pull: refs/heads/master:refs/heads/linus
(2) Use that to fetch my tree as the "linus" branch:
git fetch linus
and now you have at least a nice new branch that contains the "standard"
kernel. At which point you just need to do
(3) rebase the work since "origin" onto "linus":
git rebase --onto linus origin
I really really despise the "git rebase" command line syntax, and I find
it very non-inuitive, but what this does is take your current branch,
compare its contents to "origin" (ie where you started from), and then
just rebase the commits onto the state that is "linus".
[ Junio: syntax comments:
Personally, I think the rebase syntax sucks, because the _natural_ way
to do it is to just describe the set of commits to rebase the same way
we describe all _other_ commit sets: as a "begin..end" sequence.
So I think rebase _should_ work something like this:
git rebase origin.. [--onto] linus
ie just giving an arbitrary range. This is even more noticeable for
"git-format-patch", where that insane "<his> [<mine>]" syntax is even
worse, for no good reason, when again it should really just work like
"git diff" where giving a single revision implies a single revision, and
giving a range implies a range, and no strange "mine" vs "his" rules ]
Oh well. Syntax rant over.
Linus
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Shawn Pearce @ 2006-03-29 2:23 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1143596622.2481.10.camel@mattlaptop.metaesthetics.net>
Matt McCutchen <hashproduct@verizon.net> wrote:
> Dear git people,
>
> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits. Now I would like a Linux kernel based on 2.6.16 with
> the same customizations. This seems to be a very simple task, but I
> have been trying various combinations of git commands for several days
> and have not figured out how to do it.
>
> I believe that means I should pull the 2.6.16 kernel into the "origin"
> branch and then rebase the "master" branch, merging my customizations
> with 2.6.16. To this end, I switched my remote file to point to the
> 2.6.16 stable repository and tried to pull. The result was not what I
> wanted. The situation is complicated by the fact that 2.6.15.6 is not
> an ancestor of 2.6.16. The warning in the man page about branches that
> are modified nonlinearly seems to apply.
>
> How do I make my customized 2.6.16 kernel?
I think you want to use `git-fetch --force` to download origin but
not immediately merge it yet. This will bypass the not-an-ancestor
check you are running into.
Then you can perform the rebase yourself with:
# Export your local changes into a series of patches.
#
git-format-patch -k --stdout --full-index v2.6.16.6 >changes.mbox
# Checkout the new origin (2.6.16) into master.
#
git-reset --hard origin
# Now apply your patches.
#
git-am --binary -3 changes.mbox
If you get merge conflicts fix them up and restart with
`git-am --resolved`.
Note this is the logic of `git-rebase` except it doesn't require
you to actually have a common ancestor, while `git-rebase` does.
--
Shawn.
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-29 2:26 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git
In-Reply-To: <1143596622.2481.10.camel@mattlaptop.metaesthetics.net>
Matt McCutchen <hashproduct@verizon.net> writes:
> I made a customized Linux kernel based on 2.6.15.6 by cloning the stable
> 2.6.15 kernel repository (which was then at version 2.6.15.6) and making
> several commits. Now I would like a Linux kernel based on 2.6.16 with
> the same customizations.
Drawing ancestry graph would help visualizing what you want to
achieve. You have:
v2.6.15
---o
\
\
\
o---o---o v2.6.15.6
\
x---x---x v2.6.15.6-matt
where x---x---x are your own changes, and you want:
v2.6.15 v2.6.16
---o---o---o---...---o---o
\ \
\ y---y---y 2.6.16-matt
\
o---o---o v2.6.15.6
\
x---x---x 2.6.15.6-matt
to happen, where y---y---y are analogous to x---x---x.
Assuming your branches are:
origin - v2.6.15.6 (from stable team)
master - your changes (2.6.15.6-matt)
you could:
$ git fetch git://../torvalds/linux-2.6.git tag v2.6.16
$ git checkout -b 2.6.16-matt v2.6.16
$ git format-patch origin master | git am -3
Alternatively, you might want to do a real merge:
v2.6.15 v2.6.16
---o---o---o---...---o---o
\ \
\ \
\ m 2.6.16-matt
o---o---o v2.6.15.6 /
\ /
x---x---x 2.6.15.6-matt
Presumably the stable team backported safer changes from the
history between v2.6.15-v2.6.16, and the way things are fixed
are probably quite different from the equivalent fixes in the
development track that led to v2.6.16 (because what's being
patched has also changed), so it is very likely you would see
serious conflicts during this merge. If you do not understand
what the stable team did in order to reimplement certain fixes,
you would have a very difficult time deciding on how to resolve
conflicts with this merge.
At that point it would not be a git question but the kernel
question I am not qualified to answer ;-), but it might be an
interesting exercise.
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-29 2:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603281749060.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Oh well. Syntax rant over.
Yeah, inertia, backward compatibility wart, craziness.
^ permalink raw reply
* Re: How to switch kernel customizations from 2.6.15.6 to 2.6.16?
From: Junio C Hamano @ 2006-03-29 3:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603281749060.15714@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Personally, I think the rebase syntax sucks, because the _natural_ way
> to do it is to just describe the set of commits to rebase the same way
> we describe all _other_ commit sets: as a "begin..end" sequence.
I'd agree in general, and I am not happy about them.
But I have an excuse.
rev-parse's A..B notation was invented on June 13th (178cb24).
But format-patch was originally posted on May 30th:
http://article.gmane.org/gmane.comp.version-control.git/4279
before the convenience of rev-parse was invented ;-).
> So I think rebase _should_ work something like this:
>
> git rebase origin.. [--onto] linus
>
> ie just giving an arbitrary range.
In addition, both rebase and format-patch does a bit more than
straight his..mine.
*---x---x---o---o---o---o
\ ^mine
.---.---.---.
^his
We do _not_ want to process all six of his..mine commits when
doing "format-patch his mine" in the above picture, because
upstream might have accepted some of them already, and we filter
them out with git-cherry.
> This is even more noticeable for "git-format-patch", where
> that insane "<his> [<mine>]" syntax is even worse, for no
> good reason, when again it should really just work like "git
> diff" where giving a single revision implies a single
> revision, and giving a range implies a range, and no strange
> "mine" vs "his" rules ]
Having said that, you have been able to say format-patch A..B
C..D E..F for quite some time (since November 21, 2005).
Rebase is even more strange, especially with --onto. When you do
$ rebase --onto his origin mine
in this picture,
*---x---x---o---o---o---o
\ ^origin ^mine
.---.---.---.
^his
you are discarding two 'x' commits, and lost-found is the only
thing that would help you to recover them.
Unlike format-patch which takes ranges, rebase does not let you
say "rebase --onto base A..B C..D E..F"; what happens might be
too confusing, especially if B, D, F are not coming from the
current branch. The current branch is rewound to base and then
the chosen sets of patches are applied, which is kind-of scary.
It would feel safer to do:
$ git checkout -b newbranch base
$ git format-patch --stdout A..B C..D E..F | git am -3
and after making sure the result is really what you want
resetting the original branch to the current (newbranch) head.
^ permalink raw reply
* Re: Gitk strangeness..
From: Junio C Hamano @ 2006-03-29 6:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17449.48630.370867.10251@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> That's brilliant. Thank you! With the patch to gitk below, the
> graph display on Linus' example looks much saner.
Indeed this looks much saner. Thanks.
^ permalink raw reply
* Is 'merge' in your path?
From: Len Brown @ 2006-03-29 8:42 UTC (permalink / raw)
To: git
trying to do a merge on my laptop using git as of today,
but it bombs out. anybody seen this?
lenb@toshiba:~/src> git --version
git version 1.3-rc1.GIT
lenb@toshiba:~/src/linux-acpi-2.6> /lab/bin/git.update test
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Merging test with 224b148ef7c9a00642eb33dbdf62f2840bde974f
Merging:
9dc2a5c16ba732595afa926aabbf07efaef40b92 Pull trivial into test branch
224b148ef7c9a00642eb33dbdf62f2840bde974f Merge branch 'for-linus' of
master.kernel.org:/pub/scm/linux/kernel/git/scjody/ieee1394
found 1 common ancestor(s):
35ab0e88c63fb8e61013011560ad10e6200b5ee0 Merge branch 'release' of
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6
Removing arch/sparc64/lib/find_bit.c
Removing drivers/scsi/qla2xxx/ql6312.c
Removing include/asm-arm/arch-h720x/param.h
Removing include/asm-arm/arch-imx/irq.h
Removing drivers/usb/media/pwc/pwc-kiara.c
Removing include/asm-ppc/xparameters.h
Removing drivers/i2c/busses/i2c-frodo.c
Removing include/asm-arm/arch-lh7a40x/irq.h
Removing drivers/char/rio/riopcicopy.c
Auto-merging Documentation/kernel-parameters.txt
merge -L test/Documentation/kernel-parameters.txt -L
orig/Documentation/kernel-parameters.txt -L
224b148ef7c9a00642eb33dbdf62f2840bde974f/Documentation/kernel-parameters.txt .merge_file_2KLpUR .merge_file_H6NRcP .merge_file_WLV6HQ:
No such file or directory
Failed to execute 'merge'. merge(1) is used as the file-level merge tool. Is
'merge' in your path?
No merge strategy handled the merge.
lenb@toshiba:~/src/linux-acpi-2.6> which git-merge
/home/lenb/bin/git-merge
lenb@toshiba:~/src/linux-acpi-2.6> which git
/home/lenb/bin/git
lenb@toshiba:~/src/linux-acpi-2.6>
^ permalink raw reply
* Re: Is 'merge' in your path?
From: Andreas Ericsson @ 2006-03-29 8:47 UTC (permalink / raw)
To: Len Brown; +Cc: git
In-Reply-To: <200603290342.40970.len.brown@intel.com>
Len Brown wrote:
> trying to do a merge on my laptop using git as of today,
> but it bombs out. anybody seen this?
>
> lenb@toshiba:~/src> git --version
> git version 1.3-rc1.GIT
>
> lenb@toshiba:~/src/linux-acpi-2.6> /lab/bin/git.update test
> Trying really trivial in-index merge...
> fatal: Merge requires file-level merging
....
> Failed to execute 'merge'. merge(1) is used as the file-level merge tool. Is
> 'merge' in your path?
> No merge strategy handled the merge.
> lenb@toshiba:~/src/linux-acpi-2.6> which git-merge
> /home/lenb/bin/git-merge
> lenb@toshiba:~/src/linux-acpi-2.6> which git
> /home/lenb/bin/git
> lenb@toshiba:~/src/linux-acpi-2.6>
What does "which merge" tell you? If it turns up blank, you know the
problem. The merge program is usually found in the rcs package.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* RE: Is 'merge' in your path?
From: Brown, Len @ 2006-03-29 9:06 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
>What does "which merge" tell you? If it turns up blank, you know the
>problem. The merge program is usually found in the rcs package.
blank indeed. I guess I don't have rcs on this laptop.
thanks,
-Len
^ permalink raw reply
* Re: [PATCH] xdiff: Show function names in hunk headers.
From: Mark Wooding @ 2006-03-29 9:57 UTC (permalink / raw)
To: git
In-Reply-To: <7v4q1ihzio.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Asciidoc?
>
> . enumerated one
> this is one item
I thought about this, and decided that missing these was a good thing,
because item heads are probably too low-level. I'd rather go for
section or subsection headings.
> It's just a heuristic, so there are only two things we could
> sensibly do. Either we keep it absolutely stupid to save our
> code and sanity, or we give full configurability via -F regexp
> to the end users.
I'm already thinking about that...
-- [mdw]
^ permalink raw reply
* Re: Is 'merge' in your path?
From: Catalin Marinas @ 2006-03-29 10:01 UTC (permalink / raw)
To: Brown, Len; +Cc: Andreas Ericsson, git
In-Reply-To: <CFF307C98FEABE47A452B27C06B85BB6046AA9@hdsmsx411.amr.corp.intel.com>
"Brown, Len" <len.brown@intel.com> wrote:
>>What does "which merge" tell you? If it turns up blank, you know the
>>problem. The merge program is usually found in the rcs package.
>
> blank indeed. I guess I don't have rcs on this laptop.
Actually, I think git could use diff3 directly and not rely on "merge"
from rcs which seems to be equivalent to "diff3 -m -E" (it might even
call diff3, I'm not sure).
Are there any features in "merge" and not available in "diff3"?
--
Catalin
^ permalink raw reply
* Re: Is 'merge' in your path?
From: Romain Francoise @ 2006-03-29 10:14 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Andreas Ericsson, git
In-Reply-To: <tnxmzf9sh7k.fsf@arm.com>
Catalin Marinas <catalin.marinas@arm.com> writes:
> Are there any features in "merge" and not available in "diff3"?
`merge' from GNU RCS is just a wrapper around diff3.
--
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
^ permalink raw reply
* Re: [PATCH] Add ALL_LDFLAGS to the git target.
From: Johannes Schindelin @ 2006-03-29 11:42 UTC (permalink / raw)
To: Mark Wooding; +Cc: git
In-Reply-To: <slrne2jf9t.s3g.mdw@metalzone.distorted.org.uk>
Hi,
On Tue, 28 Mar 2006, Mark Wooding wrote:
> Jason Riedy <ejr@EECS.Berkeley.EDU> wrote:
>
> > P.S. For the whole finding-a-function-name business, some of
> > us are using git on fixed-format Fortran. Every non-comment
> > line begins with whitespace... ;) And in free format, many
> > people don't add that first indentation within subroutines.
>
> Urgh. So, which regex library do people want to use? ;-) (My vote's
> for pcre.)
My vote is against adding such a dependency for so little gain. We already
use regex.h (probably my fault).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Support for pickaxe matching regular expressions
From: Petr Baudis @ 2006-03-29 13:09 UTC (permalink / raw)
To: Linus Torvalds, Johannes Schindelin; +Cc: Mark Wooding, git
In-Reply-To: <20060329001633.GF27689@pasky.or.cz>
Dear diary, on Wed, Mar 29, 2006 at 02:16:33AM CEST, I got a letter
where Petr Baudis <pasky@suse.cz> said that...
> The regex.h library is a rather stupid interface and I like pcre too, but
> with any luck it will be everywhere we will want to run Git on, it being
> POSIX.2 and all. I'm not sure if we can expect platforms like AIX to
> conform to POSIX.2 or if win32 has regex.h. We might add a flag to
> Makefile if there is a portability trouble potential.
Dear diary, on Wed, Mar 29, 2006 at 01:42:00PM CEST, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> We already use regex.h (probably my fault).
Indeed, and since noone complained yet, the portability consideration is
apparently a non-issue.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* [PATCH] Unclutter cg status with --directory as GIT does
From: Paolo 'Blaisorblade' Giarrusso @ 2006-03-29 14:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Pass the new --directory option (from git 1.1) to git-ls-others for
list_untracked_files, as does git-status - it's very useful.
Probably this must be deferred to when the git 1.1 dependency is added, however
please queue it for then.
Thanks.
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
cg-Xlib | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/cg-Xlib b/cg-Xlib
index 2b93c11..3150470 100644
--- a/cg-Xlib
+++ b/cg-Xlib
@@ -274,7 +274,7 @@ list_untracked_files()
fi
local listdirs=
[ "$squashflag" = "squashdirs" ] && listdirs=--directory
- git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
+ git-ls-files -z --others --directory $listdirs "${EXCLUDE[@]}"
}
pick_id()
^ permalink raw reply related
* [PATCH] Pass --directory to git-ls-files for stg status
From: Paolo 'Blaisorblade' Giarrusso @ 2006-03-29 14:25 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
Requires GIT 1.1.0 at least (don't know if this was backported in 1.0).
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---
stgit/git.py | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/stgit/git.py b/stgit/git.py
index 40d54ef..e8c816d 100644
--- a/stgit/git.py
+++ b/stgit/git.py
@@ -194,8 +194,8 @@ def __tree_status(files = None, tree_id
if noexclude:
extra_exclude = base_exclude = []
- lines = _output_lines(['git-ls-files', '--others'] + base_exclude
- + extra_exclude)
+ lines = _output_lines(['git-ls-files', '--others', '--directory']
+ + base_exclude + extra_exclude)
cache_files += [('?', line.strip()) for line in lines]
# conflicted files
^ permalink raw reply related
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Petr Baudis @ 2006-03-29 14:54 UTC (permalink / raw)
To: Paolo 'Blaisorblade' Giarrusso; +Cc: git
In-Reply-To: <20060329142559.12059.52795.stgit@zion.home.lan>
Dear diary, on Wed, Mar 29, 2006 at 04:25:59PM CEST, I got a letter
where Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> said that...
> Pass the new --directory option (from git 1.1) to git-ls-others for
> list_untracked_files, as does git-status - it's very useful.
>
> Probably this must be deferred to when the git 1.1 dependency is added, however
> please queue it for then.
Uh, I'm confused. Cogito now depends on git-1.1, and
> diff --git a/cg-Xlib b/cg-Xlib
> index 2b93c11..3150470 100644
> --- a/cg-Xlib
> +++ b/cg-Xlib
> @@ -274,7 +274,7 @@ list_untracked_files()
> fi
> local listdirs=
> [ "$squashflag" = "squashdirs" ] && listdirs=--directory
> - git-ls-files -z --others $listdirs "${EXCLUDE[@]}"
> + git-ls-files -z --others --directory $listdirs "${EXCLUDE[@]}"
as you can see, if list_untracked_files was pssed the 'squashdirs'
option, it will already pass it. What cg command would you like to
squash dirs except cg-status?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Blaisorblade @ 2006-03-29 15:04 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060329145427.GI27689@pasky.or.cz>
On Wednesday 29 March 2006 16:54, Petr Baudis wrote:
> Dear diary, on Wed, Mar 29, 2006 at 04:25:59PM CEST, I got a letter
> where Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> said that...
> > Pass the new --directory option (from git 1.1) to git-ls-others for
> > list_untracked_files, as does git-status - it's very useful.
> > Probably this must be deferred to when the git 1.1 dependency is added,
> > however please queue it for then.
> Uh, I'm confused. Cogito now depends on git-1.1, and
> as you can see, if list_untracked_files was pssed the 'squashdirs'
> option, it will already pass it. What cg command would you like to
> squash dirs except cg-status?
Sorry, that's just an old patch then, I didn't note you did it yourself.
I wrote it before you had the 1.1 dependency and didn't notice you made
something similar.
Bye and sorry for the noise
--
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: [PATCH] Unclutter cg status with --directory as GIT does
From: Petr Baudis @ 2006-03-29 15:08 UTC (permalink / raw)
To: Blaisorblade; +Cc: git
In-Reply-To: <200603291704.14870.blaisorblade@yahoo.it>
Dear diary, on Wed, Mar 29, 2006 at 05:04:14PM CEST, I got a letter
where Blaisorblade <blaisorblade@yahoo.it> said that...
> Sorry, that's just an old patch then, I didn't note you did it yourself.
>
> I wrote it before you had the 1.1 dependency and didn't notice you made
> something similar.
Well, I've just applied your patch :-) :
commit 4e1cd8ac4815bdc3e6671a2a5a266a9ca675630d
author Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Thu, 19 Jan 2006 22:16:46 +0100
committer Petr Baudis <xpasky@machine.or.cz> Sat, 21 Jan 2006 02:21:13 +0100
Kind regards,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time. I think
I have forgotten this before.
^ permalink raw reply
* Git terminology
From: Sébastien Pierre @ 2006-03-29 10:21 UTC (permalink / raw)
To: Git ML
Hi all,
In the process of learning git, and browsing the docs, I realized that many particular terms are used, but I had difficulties finding their definitions.
Among those I found a bit arcane, there are (in no particular order) "refspec", "rebase", "rewound", "pickaxe", "refnames", "objectnames" ,"refnames", "fast-forward update".
Also, doing a "grep -rohE '<[a-z\-]+>' * | sort | uniq" in git source tree gave me the list of "parameter types" for git commands, where some would benefit from a formal definition : <base>, <blob>, <branch>, <branchname>, <comitish>, <tree>, <tree-ish>, <head>, <headsha>, <refspec>, and so on. Of course, some of these terms are already explained in the man pages, but it would be nice to have a "git terminlogy reference".
If some of you are willing to detail/explain/define those terms (and some others not mentioned here), I would be glad to collect the definitions and make a "git terminology" document.
-- Sébastien
^ permalink raw reply
* Re: Git terminology
From: J. Bruce Fields @ 2006-03-29 15:31 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: Git ML
In-Reply-To: <20060329052113.6a773480.sebastien@xprima.com>
On Wed, Mar 29, 2006 at 05:21:13AM -0500, Sébastien Pierre wrote:
> If some of you are willing to detail/explain/define those terms (and
> some others not mentioned here), I would be glad to collect the
> definitions and make a "git terminology" document.
See Documentation/glossary.txt. It's missing some of the terms your
looking for, but I'm sure patches would be accepted.
--b.
^ permalink raw reply
* Re: Git terminology
From: Junio C Hamano @ 2006-03-29 15:59 UTC (permalink / raw)
To: Sébastien Pierre; +Cc: git
In-Reply-To: <20060329052113.6a773480.sebastien@xprima.com>
Sébastien Pierre <sebastien@xprima.com> writes:
> In the process of learning git, and browsing the docs, I
> realized that many particular terms are used, but I had
> difficulties finding their definitions.
I had difficulties reading your message. Please fold your lines.
> Among those I found a bit arcane, there are (in no particular
> order) "refspec", "rebase", "rewound", "pickaxe", "refnames",
> "objectnames" ,"refnames", "fast-forward update".
I see some are missing from our glossary but some others are
found there.
refspec is used by fetch and push to describe the mapping
between remote ref and local ref. E.g. "git fetch $URL
refs/heads/master:refs/heads/origin" means "grab the master
branch head from there and store it as my origin branch head".
"git push $URL refs/heads/master:refs/heads/to-upstream" for
"publish my master branch head as to-upstream master head at
$URL".
Probably we can just say "ref" where we say "refname".
Probably we can just say "ref" where we say "refname".
A fast-forward is where you have a revision and you are
"merging" other's change that happen to be a descendant what you
have. In such a case, you do not make a new merge commit but
just update to his revision. That is:
o---o---o---o his o---o---o---o his
/ -> / \
o---o---o---o yours o---o---o---o-------* yours
updating to his needs a merge like above, but in this case:
o---o---o---o his o---o---o---o his = yours
/ -> /
o---o yours o---o
you just update to his.
A related concept is "being already up-to-date". In the latter
picture, if he attempts to "merge" your changes and notices he
is simply ahead of you (i.e. his revision is a descendant of
yours), nothing happens.
> If some of you are willing to detail/explain/define those
> terms (and some others not mentioned here), I would be glad to
> collect the definitions and make a "git terminology" document.
Thanks, and what J Bruce Fields already said.
^ 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