* Re: git-PS1 bash prompt setting
From: Sean @ 2006-11-27 12:56 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, git, Theodore Tso
In-Reply-To: <20061127065400.GA19174@spearce.org>
On Mon, 27 Nov 2006 01:54:00 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> I'm using something like this, and will be adding it to
> git-completion.bash tonight:
>
> __git_ps1 ()
> {
> local b="$(git symbolic-ref HEAD 2>/dev/null)"
> if [ -n "$b" ]; then echo "(${b##refs/heads/})"; fi
> }
> PS1='[\u@\h \W$(__git_ps1)]\$ '
>
> it works very well...
Yeah, when I first coded it I even looked at making it a bash loadable
to make it perform better but found the prototype to run acceptably,
so never bothered. If Git does get a --show-ps1 option, people will
still be able to roll their own version to tweak the output format
as you did above. Hopefully the standard format will work for most
though.
^ permalink raw reply
* git: how to produce context diffs?
From: Bruno Haible @ 2006-11-27 14:16 UTC (permalink / raw)
To: Junio C Hamano, git
Hi,
Is this a bug in git-diff? The git-diff-files.html says:
" When the environment variable GIT_EXTERNAL_DIFF is not set ...
For example, if you prefer context diff:
GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
This doesn't work for me with git-1.4.4:
$ unset GIT_EXTERNAL_DIFF
$ export GIT_DIFF_OPTS=-c
$ git-diff-index -p HEAD
diff --git a/configure.ac b/configure.ac
index 74901dc..d222ded 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1,5 +1,5 @@
dnl Process this file with autoconf to produce a configure script.
-AC_INIT(hello, 2.1.1, bug-gnu-hello@gnu.org)
+AC_INIT(hello, 2.1.2, bug-gnu-hello@gnu.org)
AC_CONFIG_SRCDIR([src/hello.c])
AC_PREREQ(2.52)
Expected output:
$ git-diff-index -p HEAD
index 74901dc..d222ded 100644
diff --git a/configure.ac b/configure.ac
*** a/configure.ac
--- b/configure.ac
***************
*** 1,5 ****
dnl Process this file with autoconf to produce a configure script.
! AC_INIT(hello, 2.1.1, bug-gnu-hello@gnu.org)
AC_CONFIG_SRCDIR([src/hello.c])
AC_PREREQ(2.52)
--- 1,5 ----
dnl Process this file with autoconf to produce a configure script.
! AC_INIT(hello, 2.1.2, bug-gnu-hello@gnu.org)
AC_CONFIG_SRCDIR([src/hello.c])
AC_PREREQ(2.52)
(Really, while I find -u diffs fine for tiny changes, I find them unreadable
for rewrites of larger blocks, and cannot live without -c for these.)
When I look at diff.c around
const char *diffopts = getenv("GIT_DIFF_OPTS");
it appears that only unified diffs are supported??
^ permalink raw reply related
* Re: git: how to produce context diffs?
From: Jakub Narebski @ 2006-11-27 14:27 UTC (permalink / raw)
To: git
In-Reply-To: <200611271516.30425.bruno@clisp.org>
Bruno Haible wrote:
> Is this a bug in git-diff? The git-diff-files.html says:
>
> " When the environment variable GIT_EXTERNAL_DIFF is not set ...
> For example, if you prefer context diff:
> GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
>
> This doesn't work for me with git-1.4.4:
Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
but it means "combined diff" (for merges), not "context diff".
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] revision traversal: Add --refs=<pattern> option
From: Sergey Vlasov @ 2006-11-27 15:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, catalin.marinas, git, Sergey Vlasov
In-Reply-To: <7vzmadl5b0.fsf@assigned-by-dhcp.cox.net>
Add the --refs=<pattern> option, which can be used to select a
subset of refs matching the specified glob pattern.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
If --all-branches is too specific for the mentioned use case,
what about adding a more general glob pattern match?
Documentation/git-rev-list.txt | 9 +++++++++
revision.c | 21 ++++++++++++++++++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index ec43c0b..d5f99ef 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -17,6 +17,7 @@ SYNOPSIS
[ \--remove-empty ]
[ \--not ]
[ \--all ]
+ [ \--refs=<pattern> ]
[ \--stdin ]
[ \--topo-order ]
[ \--parents ]
@@ -179,6 +180,14 @@ limiting may be applied.
Pretend as if all the refs in `$GIT_DIR/refs/` are listed on the
command line as '<commit>'.
+--refs='pattern'::
+
+ Pretend as if all the refs in `$GIT_DIR/refs/` matching the
+ specified glob pattern are listed on the command line as
+ '<commit>'. The initial `refs/` part is skipped when matching,
+ but the subsequent `heads/`, `tags/` or `remotes/` part is
+ included in the text to match.
+
--stdin::
In addition to the '<commit>' listed on the command
diff --git a/revision.c b/revision.c
index 993bb66..240ff59 100644
--- a/revision.c
+++ b/revision.c
@@ -7,6 +7,7 @@
#include "refs.h"
#include "revision.h"
#include <regex.h>
+#include <fnmatch.h>
#include "grep.h"
static char *path_name(struct name_path *path, const char *name)
@@ -464,18 +465,28 @@ static void limit_list(struct rev_info *
static int all_flags;
static struct rev_info *all_revs;
+static const char *all_pattern;
static int handle_one_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data)
{
- struct object *object = get_reference(all_revs, path, sha1, all_flags);
+ struct object *object;
+
+ if (all_pattern) {
+ if (strncmp(path, "refs/", 5))
+ return 0;
+ if (fnmatch(all_pattern, path + 5, 0))
+ return 0;
+ }
+ object = get_reference(all_revs, path, sha1, all_flags);
add_pending_object(all_revs, object, "");
return 0;
}
-static void handle_all(struct rev_info *revs, unsigned flags)
+static void handle_all(struct rev_info *revs, unsigned flags, const char *pattern)
{
all_revs = revs;
all_flags = flags;
+ all_pattern = pattern;
for_each_ref(handle_one_ref, NULL);
}
@@ -800,7 +811,11 @@ int setup_revisions(int argc, const char
continue;
}
if (!strcmp(arg, "--all")) {
- handle_all(revs, flags);
+ handle_all(revs, flags, NULL);
+ continue;
+ }
+ if (!strncmp(arg, "--refs=", 7)) {
+ handle_all(revs, flags, arg + 7);
continue;
}
if (!strcmp(arg, "--not")) {
--
1.4.4.1.gb0b0
^ permalink raw reply related
* Re: git: how to produce context diffs?
From: Sean @ 2006-11-27 15:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ekesgt$6jq$1@sea.gmane.org>
On Mon, 27 Nov 2006 15:27:20 +0100
Jakub Narebski <jnareb@gmail.com> wrote:
> Bruno Haible wrote:
>
> > Is this a bug in git-diff? The git-diff-files.html says:
> >
> > " When the environment variable GIT_EXTERNAL_DIFF is not set ...
> > For example, if you prefer context diff:
> > GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
> >
> > This doesn't work for me with git-1.4.4:
>
> Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
> but it means "combined diff" (for merges), not "context diff".
Indeed. That documentation predates built-in diff completely.
It appears the only valid options now are "-u XX" and "--unified=XX".
These options are never passed to diff, but rather used to control
the internal diff. Strangely, it appears that gitk is even passing
incorrect parameters via GIT_DIFF_OPTS.
Unless i've really missed something, the above documentation should be
reworked to remove mention of running diff altogether, and should mention
that the GIT_DIFF_OPTS only has two valid settings.
^ permalink raw reply
* Re: Some tips for doing a CVS importer
From: Jon Smirl @ 2006-11-27 15:20 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Git Mailing List, dev, Shawn Pearce
In-Reply-To: <456ACAF3.1050608@alum.mit.edu>
On 11/27/06, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> I am currently the main (and pretty much the only) cvs2svn maintainer.
> Development has been proceeding more slowly lately because (1) I'm very
> busy with my day job, and (2) nobody has stepped forward to help.
>
> Jon Smirl wrote:
> > #1) There needs to be a tool that can accurately import the
> > repository. cvs2svn does not do this. The good programmers working on
> > git could probably whip this out in a week or two if they wanted to.
> > cvs2svn is very close but they refuse to solve the symbol dependency
> > problem.
>
> Jon, I wish you wouldn't portray as obstinacy what is simply a lack of
> resources. I would like very much to support other cvs2svn output
> formats. I think it would be great if other projects could benefit from
> our work. Most of the work I've been doing on cvs2svn lately has been
> towards supporting other output SCMs.
cvs2avn is a nice piece of code, it is a worthy goal to have a
univeral conversion tool.
>
> Jon Smirl wrote:
> > I gave up on my cvs2git code, cvs2svn has been refactored so badly
> > that it was too much trouble tracking. It would be easier to write it
> > again. Most of the smarts from the import process is in the
> > git-fastimport code which Shawn has. cvs2svn underwent a major
> > algorithm change after I wrote the first version of git2svn.
>
> I hope that by "badly" you mean "extensively" and not "poorly" :-\ If
> you mean "poorly", then I'd like to hear your feedback/suggestions.
Extensively, the dependency rewrite changed things some much that my
patches were basically worthless. I tried merging them and gave up, it
would be more efficient to rewrite them or builld hooks in the right
places.
>
> A large amount of refactoring has been needed to make the change to
> dependency-based conversion possible, and a lot more to help support
> different output formats. I understand that this causes difficulties
> for people trying to do parallel development, but most of the
> refactoring was done before your first appearance on the cvs2svn mailing
> lists. If you had let us know what you were working on, I would have
> avoided making conflicting changes (as I did with Oswald Buddenhagen's
> commit-dependencies changes).
>
> Jon Smirl wrote:
> > I have tried all of the available CVS importers. None of them are
> > without problems. If anyone is interested in writing one for git here
> > are some ideas on how to structure it.
> >
> > 1) there is a working lex/yacc for CVS in the parsecvs source code
> > 2) The first time you parse a CVS file record everything and don't
> > parse it again.
> > 3) When the file is first parsed use the deltas to generate the
> > revisions and feed them to git-fastimport, just remember the SHA1 or
> > an id in the import code. This is a critical step to getting decent
> > performance.
> > 4) If you do #1 and #2 you don't need to store CVS revision numbers
> > and file names in memory. Because of that you can can easily do a
> > Mozilla import in 2GB, probably 1GB.
> > 5) When comparing CVS revisions only use the CVS timestamps as a last
> > resort, instead use the dependency information in the CVS file
> > 6) Match up commits by using an sha1 of the author and commit message
> > 7) After all files are loaded, match up the symbols and insert them
> > into the dependency chains, if any of the symbols depend on a branch
> > commit the symbol lies on the branch, otherwise the symbol is on the
> > trunk,
> > 8) Do a topological sort to build the change set commit tree
> > 9) when you hit a loop in the tree break up delta change sets until
> > the loop can be removed, don't break up symbol change sets.
> > 10) Mozilla has some large commits that were made over dial up. Commit
> > change sets can span hours. All of these commits need to be merged
> > into a single change set.
> > 11) An algorithm needs to be developed for detecting branches merging
> > back into the trunk
> > 12) cvs2svn has excellent test cases, use them to test the new
> > importer. The cvs2svn code is quite nice but it doesn't handle #7
>
> Most of this is possible now using cvs2svn, but it is not enough.
>
> But first there is a problem with your point #9. It is in general not
> possible to avoid breaking up symbol changesets, even if you are willing
> to massacre the revision changesets. CVS allows cases like this:
We don't know how often this case occurs until more alogirthms are
tried. All I know is that 60% of the Mozilla symbols end up needing
copies. And for the few cases I decoded things by hand I was able to
rearrange things so that copies were not needed. It is likely that
some symbols in Mozilla will need copies to construct them, it is a
question of degree, I don't believe copies are required for 60% of the
symbols.
>
> file1:
>
> 1.1
> 1.2 ----> branch "A"
> 1.2.0.1
> 1.2.0.2 ----> branch "B"
>
> file2:
>
> 1.1
> 1.2 ----> branch "B"
> 1.2.0.1
> 1.2.0.2 ----> branch "A"
>
> Clearly there is no way to create symbols "A" and "B" both in a single
> changeset.
>
> But even disallowing cases like the one above, it is often very
> questionable whether you want to avoid breaking up symbol commits at all
> costs. For example, CVS allows
>
>
> January: file1<1.1> file2<1.1>
> February: file1<1.1> tagged "T"
> March: file1<1.2>
> November: file2<1.2>
> December: file2<1.2> tagged "T"
>
> In such a case, the only way to avoid splitting up the creation of tag
> "T" would be to pretend that the commit file1<1.2> didn't occur in March
> but rather in November.
>
> The bottom line is that cvs2svn should do a better job of handling
> symbols, but even then the git importer will necessarily have to deal
> with some unusual CVS cases.
The unusal cases can be made into branches. If I remember correctly
Mozilla has about 300 symbols with "BRANCH" in the name. But the
converted repositories are ending up with over 2,000 branches. When
you load this into the git visualization tools it is obvious that the
bowl of spaghetti caused by 2,000 branches is not a repository a human
would have created.
>
> > Processing the symbols is integral to deciding how to build the change
> > sets. Right now cvs2svn ignores the symbol dependency information and
> > builds the change sets in a way that forces the mini-branches. That
> > causes 60% of the 2,000 symbols in Mozilla CVS to end up as little
> > branches. Look at the three commit example in the other thread to see
> > exactly what the problem is.
> >
> > SVN hides the mini branch by creating a symbol like this:
> >
> > Symbol XXX, change set 70
> > copy All from change set 50
> > copy file A from change set 55
> > copy file B,C from change set 60
> > copy file D from change set 61
> > copy file E,F,G from change set 63
> > copy file H from change set 67
> >
> > It has to do all of those copies because the change sets weren't
> > constructed while taking symbol dependency information into account.
> >
> > Symbol XXX can't copy from change set 69 because commits from after
> > the symbol was created are included in change sets 51-69.
>
> The vast majority of the mixed-source symbol creations have nothing to
> do with honoring symbol dependencies, but rather with the fact the
> cvs2svn is not so clever about deducing which branch should be used as
> the source for a symbol (CVS often does not record this information
> unambiguously).
>
> Changes needed for git import:
>
> The symbol dependency problem that Jon has focused on is IMO just the
> least significant of three main changes that have to be made to support
> git output from cvs2svn:
>
> 1. The symbol dependency problem. Occasionally symbols are created in
> an order that is inconsistent with the CVS dependency graph. We want to
> fix this in any case (even for SVN). Work done so far: the symbol
> dependency graph is already generated and recorded when the repository
> is parsed, and the symbol dependencies are carried through the
> conversion (though not yet used).
>
> 2. Symbols are often created using multiple branches as sources, when
> they could be created from a single branch. This happens because in
> many cases CVS doesn't record unambiguously which branch was tagged, and
> cvs2svn's heuristics are not especially clever. A patch has been
> submitted to fix this problem, but unfortunately it doesn't apply to
> HEAD anymore. See
>
> http://cvs2svn.tigris.org/servlets/ReadMsg?list=dev&msgNo=1441
>
> for a discussion. (The main difficulty with picking better sources for
> symbols is that the obvious approaches all require tons of intermediate
> storage.) I am currently trying to understand symbol handling in
> cvs2svn well enough that I can port the patch to trunk.
I'm happy to give new alogorithm a try as they are developed.
>
> 3. The default current output format of cvs2svn is a single dump file
> with file revisions in commit order. For the distributed SCMs, it is
> usually far more efficient to generate the file revisions file-by-file
> (non-chronologically) during the initial parse of the CVS files, and
> refer to the revisions by hash for the rest of the conversion. In
> October I added a bunch of hooks to cvs2svn to make this possible. Work
> remaining: code to reconstruct file text from CVS text + deltas,
> including proper handling of line-end conventions and keyword
> expansion/unexpansion, and of course the code to output the
> reconstructed snapshots in a git-consumable format.
This is a major benefit for git conversion, but it hasn't been a big
issues with the cvs2svn code. Hooks will be helpful.
--
Jon Smirl
^ permalink raw reply
* Mozilla, git and Windows
From: Jon Smirl @ 2006-11-27 15:28 UTC (permalink / raw)
To: Git Mailing List
In the other thread we are discussing the conversion of Mozilla CVS to
git format. This is something that has to be done but it is not the
only issue. Without a native Windows port they won't even consider
using git. There is also the risk that the features needed by Mozilla
will be completed after they choose to use a different SCM.
Even if we implement all of the needed features git still needs to win
the competition against the other possible choices. The last I heard
the leading candiate is SVN/SVK.
--
Jon Smirl
^ permalink raw reply
* Re: [PATCH 4/10] Add current branch in PS1 support to git-completion.bash.
From: Sean @ 2006-11-27 15:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061127084128.GD19745@spearce.org>
On Mon, 27 Nov 2006 03:41:28 -0500
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Many users want to display the current branch name of the current git
> repository as part of their PS1 prompt, much as their PS1 prompt might
> also display the current working directory name.
>
> We don't force our own PS1 onto the user. Instead we let them craft
> their own PS1 string and offer them the function __git_ps1 which they
> can invoke to obtain either "" (when not in a git repository) or
> "(%s)" where %s is the name of the current branch, as read from HEAD,
> with the leading refs/heads/ removed.
Suppose it doesn't hurt to include support for this in git completion
scripts. It doesn't look like __git_ps1 is a proper name though,
perhaps __git_branch or __git_current_branch would be better?
^ permalink raw reply
* Re: Mozilla, git and Windows
From: Andy Whitcroft @ 2006-11-27 15:34 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910611270728p36e58e08w6cc7a2989b7843ce@mail.gmail.com>
Jon Smirl wrote:
> In the other thread we are discussing the conversion of Mozilla CVS to
> git format. This is something that has to be done but it is not the
> only issue. Without a native Windows port they won't even consider
> using git. There is also the risk that the features needed by Mozilla
> will be completed after they choose to use a different SCM.
>
> Even if we implement all of the needed features git still needs to win
> the competition against the other possible choices. The last I heard
> the leading candiate is SVN/SVK.
Do we need to worry too much about taking over the world in one day?
Yes of course git is _the_ superior solution etc, but too many new users
at once is always painful.
I think you are more likely to win letting them convert over to SVN.
From there people naturally start using git mirrors from the SVN trunk.
Cirtainly I have two projects which do not use git, one in CVS and one
in SVN. I just svnimport that and work in git. I am confident with
time the project will migrate, but I am happy other git users are happy
all without it being the tool of choice.
-apw
^ permalink raw reply
* Re: git: how to produce context diffs?
From: Sean @ 2006-11-27 15:38 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <ekesgt$6jq$1@sea.gmane.org>
On Mon, 27 Nov 2006 15:27:20 +0100
Jakub Narebski <jnareb@gmail.com> wrote:
> Bruno Haible wrote:
>
> > Is this a bug in git-diff? The git-diff-files.html says:
> >
> > " When the environment variable GIT_EXTERNAL_DIFF is not set ...
> > For example, if you prefer context diff:
> > GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
> >
> > This doesn't work for me with git-1.4.4:
>
> Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
> but it means "combined diff" (for merges), not "context diff".
Indeed. That documentation predates built-in diff completely.
It appears the only valid options now are "-u XX" and "--unified=XX".
These options are never passed to diff, but rather used to control
the internal diff. Strangely, it appears that gitk is even passing
incorrect parameters via GIT_DIFF_OPTS.
Unless i've really missed something, the above documentation should be
reworked to remove mention of running diff altogether, and should mention
that the GIT_DIFF_OPTS only has two valid settings.
^ permalink raw reply
* Re: git: how to produce context diffs?
From: Jakub Narebski @ 2006-11-27 16:05 UTC (permalink / raw)
To: Sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP01B6529D1821EEBC0A6E6FAEE60@CEZ.ICE>
Sean wrote:
> On Mon, 27 Nov 2006 15:27:20 +0100
> Jakub Narebski <jnareb@gmail.com> wrote:
>
>> Bruno Haible wrote:
>>
>>> Is this a bug in git-diff? The git-diff-files.html says:
>>>
>>> " When the environment variable GIT_EXTERNAL_DIFF is not set ...
>>> For example, if you prefer context diff:
>>> GIT_DIFF_OPTS=-c git-diff-index -p HEAD "
>>>
>>> This doesn't work for me with git-1.4.4:
>>
>> Yes, the bug in documentation, I think. There is an option '-c' to git-diff,
>> but it means "combined diff" (for merges), not "context diff".
>
> Indeed. That documentation predates built-in diff completely.
>
> It appears the only valid options now are "-u XX" and "--unified=XX".
Which both mean the same.
> These options are never passed to diff, but rather used to control
> the internal diff. Strangely, it appears that gitk is even passing
> incorrect parameters via GIT_DIFF_OPTS.
Which, in convoluted way is said in documentation (the fact that
GIT_DIFF_OPTS affect internal diff).
> Unless i've really missed something, the above documentation should be
> reworked to remove mention of running diff altogether, and should mention
> that the GIT_DIFF_OPTS only has two valid settings.
For now.
--
Jakub Narebski
^ permalink raw reply
* Re: Mozilla, git and Windows
From: Jon Smirl @ 2006-11-27 16:13 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Git Mailing List
In-Reply-To: <456B057E.4000904@shadowen.org>
On 11/27/06, Andy Whitcroft <apw@shadowen.org> wrote:
> Jon Smirl wrote:
> > In the other thread we are discussing the conversion of Mozilla CVS to
> > git format. This is something that has to be done but it is not the
> > only issue. Without a native Windows port they won't even consider
> > using git. There is also the risk that the features needed by Mozilla
> > will be completed after they choose to use a different SCM.
> >
> > Even if we implement all of the needed features git still needs to win
> > the competition against the other possible choices. The last I heard
> > the leading candiate is SVN/SVK.
>
> Do we need to worry too much about taking over the world in one day?
> Yes of course git is _the_ superior solution etc, but too many new users
> at once is always painful.
>
> I think you are more likely to win letting them convert over to SVN.
> From there people naturally start using git mirrors from the SVN trunk.
> Cirtainly I have two projects which do not use git, one in CVS and one
> in SVN. I just svnimport that and work in git. I am confident with
> time the project will migrate, but I am happy other git users are happy
> all without it being the tool of choice.
The SVN version of the Mozilla repository is about 3GB. It takes
around a week of CPU time for svnimport to process it.
--
Jon Smirl
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Linus Torvalds @ 2006-11-27 16:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqmtmlkv.fsf@assigned-by-dhcp.cox.net>
On Sun, 26 Nov 2006, Junio C Hamano wrote:
>
> I think "networking" vs "packet filtering" largely depends on
> how the networking subsystem you pull from is managed. If
> netfilter comes as e-mailed patches to DaveM and are applied
> onto the trunk of networking subsystem, we will face exactly the
> same problem as we have with Andrew's patchbomb to your trunk.
Most of the subsystems end up using patches - they're simply better ways
to move things around and have people comment on them than saying "please
pull on this tree to see my suggestion". I do it myself: even when I
_generate_ the diff in my tree, I will often just do a
git diff > ~/diff
and then import the thing into my mailer, and say "Maybe something like
this?".
So I think patches are fundamentally the core way to get things in the
periphery into just about any system. Maybe we do it more than most just
because we're so _used_ to them, but I actually think that if the kernel
does it more than most (and I'm not sure it does), it's simply because the
thing about patches is that they really _work_.
So yes, the network subsystem tends to be entirely linear by the time it
hits me. That's true of a lot of other subsystems too (SCSI etc). There's
a _few_ subsystems that actually have real topic branches: ACPI and
network driver development comes to mind, but it seems to actually be the
exception rather than the rule.
(I think that a lot of people work like I occasionally do: they do have
their own local branches for some stuff, but they end up re-linearizing
and keeping them active with "git rebase", so the branches really are
purely local, rather than something that is visible in the end result).
But the REAL reason I'd love to see a smarter "data-mining" git log
(whether it does things by bayesian clustering or any other kind of
grouping technology) is that this is actually something that people ask
for: when I make my "git shortlog" for major releases, the thing is often
thousands of lines long, and it would be _beautiful_ if that could be
data-mined somewhat more intelligently.
So, for example, do a simple
git shortlog v2.6.17..v2.6.18
(with the shortlog in "next" that can do this - btw, why doesn't it
default to using PAGER like "git log" does?), and realize that it's about
8500 lines of stuff, and nobody can really be expected to read it. It's
not a "shortlog" in other words.
So what would a _nice_ "shortlog" do? I'd _love_ to see ways to make it
more concise, more "short" for something like this. Look at the output as
a _non_kernel_ person, and what does it tell you? Not a lot. It's just too
big.
Examples of what I think would be _really_ useful (much more so than
going by "topic branches", even if they existed):
- Clustering.
The author-based clustering does work, but it would be even better to
cluster by other methods ("subsystem" - either by subdirectory, or by
noticing filename patters, or even patterns in the patches: there's a
lot of academic work on clustering human text, perhaps not as much on
clustering patches).
- Shortening
The "shortlog" often isn't. It's wonderful for small things as-is, but
once it reaches a hundred lines or more, it's less so. It would often
be nice to be able to say "only show the 100 biggest patches" (or
preferably something smarter like "the 25 biggest clusters, with a
short 4-line clustering explanation", but even just the "biggest
patches" is useful in itself and much simpler)
- External annotations (eventually)
One of the things that people like LWN editor Jonathan Corbet would
want is a way to say which patches are "important". But the thing is,
"importance" is (a) fleeting and (b) not necessarily as obvious when
the commit is made as it is afterwards. So you cannot (and must not)
mark things "important" at commit-time, and it thus can't really be
part of the repo itself, but at the same time, this is definitely
something that _could_ be somehow logged/annotated externally.
Now, I realize that these are all pipe-dreams, but so was my old "a better
annotate than annotate" a year or two ago. So I'm not saying that people
should work on this, I'm just saying that it's worth perhaps thinking
about, because I think the git model does actually give us the power to
_do_ things like this. Eventually.
And the reason? Performance! Git is fast enough that we really _can_
afford to do things like "generate diffs for every single commit in the
range v2.6.17..v2.6.18" and it takes me just 20 seconds to do on a
reasonable machine with "git log -p". So good performance means that we
can _afford_ to do a diffstat for everything (or, just raw diffs to make
it even cheaper - quite often you care more about _which_ files and how
many files something touched than the actual size of the diff in those
files itself), and using that diffstat to some day generate shortlogs that
are more useful for people like Jonathan Corbet and others that just want
to get an overview of "what happened"?
^ permalink raw reply
* Re: [PATCH] git-cvsimport: add suport for CVS pserver method HTTP/1.x proxying
From: Ignacio Arenaza @ 2006-11-27 16:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcwpawvg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I deliberately left out the style changes to avoid cluttering
> the patch; as I said in my first response, that should come as a
> separate patch that does not change anything else.
Ok, I've had a look at git-cvsimport.perl and I can't come up with a
consistent style for the 'if () {' sentence. According to grep there
are 50 instances of 'if(...)' and 39 instances of 'if (...)', so I
don't know which is the preferred one. And I can't find a CodingStyle
document either.
Which way should I fix them? And should I fix the whole file, or just
the ones in my original patch?
Saludos. Iñaki.
--
School of Management
Mondragon University
20560 Oñati - Spain
+34 943 718009 (ext. 225)
^ permalink raw reply
* Re: [PATCH 9/10] Allow completion of --committer and --author arguments to git log.
From: Shawn Pearce @ 2006-11-27 16:46 UTC (permalink / raw)
To: Nicolas Vilz; +Cc: Junio C Hamano, git
In-Reply-To: <20061127102831.GA5428@fry.bender.fht>
Nicolas Vilz <niv@iaglans.de> wrote:
> On Mon, Nov 27, 2006 at 03:42:28AM -0500, Shawn O. Pearce wrote:
> > This is just a cute hack, but we can (easily) complete the parameter
> > to --author or --committer in bash by asking for all possible authors
> > or committers in this project from git log and offering them up as
> > valid choices.
> >
> > We replace spaces with dots as this prevents names with spaces from
> > appearing as two parameters rather than one, yet it still matches the
> > space in the field.
>
> is it hard to train bash-completion to use "" and spaces instead of
> replacing spaces by dots? Besides, great feature, thank you for that...
> that's very handy.
I tried. Bash did not listen. :-)
I tried "", '', \<sp>. None of them carried into the completion.
Obviously I was doing something wrong, but right now I don't know
what that was. I spent 22 minutes on it and just caved in with
dots when it worked and nothing else did.
--
^ permalink raw reply
* Re: [PATCH 4/10] Add current branch in PS1 support to git-completion.bash.
From: Shawn Pearce @ 2006-11-27 16:51 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git
In-Reply-To: <20061127103111.4835bffc.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Mon, 27 Nov 2006 03:41:28 -0500
> "Shawn O. Pearce" <spearce@spearce.org> wrote:
>
> > Many users want to display the current branch name of the current git
> > repository as part of their PS1 prompt, much as their PS1 prompt might
> > also display the current working directory name.
> >
> > We don't force our own PS1 onto the user. Instead we let them craft
> > their own PS1 string and offer them the function __git_ps1 which they
> > can invoke to obtain either "" (when not in a git repository) or
> > "(%s)" where %s is the name of the current branch, as read from HEAD,
> > with the leading refs/heads/ removed.
>
> Suppose it doesn't hurt to include support for this in git completion
> scripts. It doesn't look like __git_ps1 is a proper name though,
> perhaps __git_branch or __git_current_branch would be better?
I actually started with the name __git_current_branch but changed
my mind on that and went with __git_ps1.
My rationale at the time was probably not correct (it was early this
morning) but I figured that the current branch name is "master"
while __git_ps1 prints " (master)". Therefore __git_ps1 is not
really printing the current branch, its printing the current branch
and other stuff. So I went with a name which implied its purpose.
--
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Shawn Pearce @ 2006-11-27 17:02 UTC (permalink / raw)
To: Sean; +Cc: Johannes Schindelin, git, Theodore Tso
In-Reply-To: <20061127075650.81a5a850.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Mon, 27 Nov 2006 01:54:00 -0500
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > I'm using something like this, and will be adding it to
> > git-completion.bash tonight:
> >
> > __git_ps1 ()
> > {
> > local b="$(git symbolic-ref HEAD 2>/dev/null)"
> > if [ -n "$b" ]; then echo "(${b##refs/heads/})"; fi
> > }
> > PS1='[\u@\h \W$(__git_ps1)]\$ '
> >
> > it works very well...
>
> Yeah, when I first coded it I even looked at making it a bash loadable
> to make it perform better but found the prototype to run acceptably,
> so never bothered.
When I originally coded the first version of __git_ps1 I was using
it on a Cygwin system, where the fork+exec of the external script
can take a little while. The time to fork+exec two programs (script
and then git) is huge compared to just fork+exec of git by itself,
so I coded it as a function. On the other hand my Mac OS X system
doesn't even blink at either implementation.
> If Git does get a --show-ps1 option, people will
> still be able to roll their own version to tweak the output format
> as you did above. Hopefully the standard format will work for most
> though.
I'm not sure that's worth implementing in the core code.
Most shells that will let you invoke a command as part of their
prompt generation will also let you use builtin functions and do
some basic string manipulation (e.g. like I do above with bash).
At which point it is say 5 lines of shell (nicely formatted) to
craft a prompt string vs. 15-20 lines of C to parse the option,
read HEAD, and craft a prompt string.
If someone else contributes a --show-ps1 option that is useable as
a replacement for my __git_ps1 I'll gladly jump on board and change
to using it, but I just don't see a reason to write it myself.
--
^ permalink raw reply
* Re: git: how to produce context diffs?
From: Sean @ 2006-11-27 17:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611271705.36479.jnareb@gmail.com>
On Mon, 27 Nov 2006 17:05:35 +0100
Jakub Narebski <jnareb@gmail.com> wrote:
> > It appears the only valid options now are "-u XX" and "--unified=XX".
>
> Which both mean the same.
Yes, I guess I should have said that. The point was really that you
can't pass any-diff-option and expect it to work.
> Which, in convoluted way is said in documentation (the fact that
> GIT_DIFF_OPTS affect internal diff).
The idea is to make it less convoluted. It directly says that -c should
work _because_ it use to work when the options were passed to external
diff. It's not just -c that won't work, none of the other myriad external
diff options will work either.
> > Unless i've really missed something, the above documentation should be
> > reworked to remove mention of running diff altogether, and should mention
> > that the GIT_DIFF_OPTS only has two valid settings.
>
> For now.
Well the documentation can be updated later if additional options
are added.
^ permalink raw reply
* Re: [PATCH 4/10] Add current branch in PS1 support to git-completion.bash.
From: Sean @ 2006-11-27 17:26 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061127165122.GB6616@spearce.org>
On Mon, 27 Nov 2006 11:51:23 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> I actually started with the name __git_current_branch but changed
> my mind on that and went with __git_ps1.
>
> My rationale at the time was probably not correct (it was early this
> morning) but I figured that the current branch name is "master"
> while __git_ps1 prints " (master)". Therefore __git_ps1 is not
> really printing the current branch, its printing the current branch
> and other stuff. So I went with a name which implied its purpose.
Ahh, I had missed that, it makes some sense. Although it goes a bit
against the commit message that the user is free to construct whatever
PS1 format they like (ie. they're stuck with parenthesis around the
branch name).
Just thinking out loud, what about allowing __git_ps1 to take a
format string of its own? It could parse options like "(\b)"
to mean git branch surrounded by parenthesis. But you could
also do "[\b]" or "!\b" if you preferred.
Then adding additional options would be easy, like "\r" for
repo relative path etc... and the user really could create just
about any git prompt they wanted. Of course, if __git_ps1
sees it's not in a git directory, it would always return an
empty string.
But that's maybe all too complicated to be worthwhile. It's
something that could be considered for the git --show-ps1 option
though.
^ permalink raw reply
* Re: [PATCH 4/10] Add current branch in PS1 support to git-completion.bash.
From: Shawn Pearce @ 2006-11-27 17:31 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, git
In-Reply-To: <20061127122653.3e801d7a.seanlkml@sympatico.ca>
Sean <seanlkml@sympatico.ca> wrote:
> On Mon, 27 Nov 2006 11:51:23 -0500
> Shawn Pearce <spearce@spearce.org> wrote:
>
> > I actually started with the name __git_current_branch but changed
> > my mind on that and went with __git_ps1.
> >
> > My rationale at the time was probably not correct (it was early this
> > morning) but I figured that the current branch name is "master"
> > while __git_ps1 prints " (master)". Therefore __git_ps1 is not
> > really printing the current branch, its printing the current branch
> > and other stuff. So I went with a name which implied its purpose.
>
> Ahh, I had missed that, it makes some sense. Although it goes a bit
> against the commit message that the user is free to construct whatever
> PS1 format they like (ie. they're stuck with parenthesis around the
> branch name).
>
> Just thinking out loud, what about allowing __git_ps1 to take a
> format string of its own? It could parse options like "(\b)"
> to mean git branch surrounded by parenthesis. But you could
> also do "[\b]" or "!\b" if you preferred.
I did that. :-)
If you read the implementation of __git_ps1 the default format is
" (%s)" but you can pass anything you want as the first parameter.
--
^ permalink raw reply
* Re: git-PS1 bash prompt setting
From: Sean @ 2006-11-27 17:38 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, git, Theodore Tso
In-Reply-To: <20061127170249.GC6616@spearce.org>
On Mon, 27 Nov 2006 12:02:49 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> When I originally coded the first version of __git_ps1 I was using
> it on a Cygwin system, where the fork+exec of the external script
> can take a little while. The time to fork+exec two programs (script
> and then git) is huge compared to just fork+exec of git by itself,
> so I coded it as a function. On the other hand my Mac OS X system
> doesn't even blink at either implementation.
For sure, that's probably the reason that it was suggested to be
included as a built-in, it would reduce the overhead.
> I'm not sure that's worth implementing in the core code.
> Most shells that will let you invoke a command as part of their
> prompt generation will also let you use builtin functions and do
> some basic string manipulation (e.g. like I do above with bash).
> At which point it is say 5 lines of shell (nicely formatted) to
> craft a prompt string vs. 15-20 lines of C to parse the option,
> read HEAD, and craft a prompt string.
Well, as per my previous message, it might be a little more worthwhile
if it did things like parse an additional format string which let
you reference config variables and relative directory etc.
It would give a lot of flexibility as to what someone wanted to
use as their PS1 when inside a git repo.
> If someone else contributes a --show-ps1 option that is useable as
> a replacement for my __git_ps1 I'll gladly jump on board and change
> to using it, but I just don't see a reason to write it myself.
Yeah.. __git_ps1 could just call "git --show-ps1" if it ever comes
into existence ;o)
^ permalink raw reply
* Re: [PATCH 4/10] Add current branch in PS1 support to git-completion.bash.
From: Sean @ 2006-11-27 17:45 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20061127173136.GD6616@spearce.org>
On Mon, 27 Nov 2006 12:31:36 -0500
Shawn Pearce <spearce@spearce.org> wrote:
> I did that. :-)
>
> If you read the implementation of __git_ps1 the default format is
> " (%s)" but you can pass anything you want as the first parameter.
lol, you're good. I'm back to thinking it's slightly misnamed though,
as that %s can only ever mean branch. But it's really a minor nit,
sorry for the noise. Good work.
^ permalink raw reply
* Re: [PATCH 3/3] git-fetch: allow glob pattern in refspec
From: Michael Loeffler @ 2006-11-27 18:14 UTC (permalink / raw)
To: git
In-Reply-To: <7vzmaik4mi.fsf@assigned-by-dhcp.cox.net>
hi,
Am Mittwoch, den 22.11.2006, 23:24 -0800 schrieb Junio C Hamano:
> This adds Andy's refspec glob. You can have a single line:
>
> Pull: refs/heads/*:refs/remotes/origin/*
How about using extended regex for this, something like this:
Pull: refs/heads/master:refs/remotes/origin/master
Pull: refs/tags/v(.*):refs/tags/origin/v\1
...
> +expand_refs_wildcard () {
> + for ref
> + do
...
How about using something like:
echo "$ls_remote_result" | sed -n -r -e "s:$ref: p"
Using $ref as a part of the sed expression is not a good idea (.* should
not match past the ':'), but something like this maybe. What do you
think?
bye
^ permalink raw reply
* Re: git: how to produce context diffs?
From: Thomas Kolejka @ 2006-11-27 18:33 UTC (permalink / raw)
To: Bruno Haible; +Cc: git, junkio
In-Reply-To: <200611271516.30425.bruno@clisp.org>
Hello,
I'm using the following script 'external-diff.sh':
--
# path old-file old-hex old-mode new-file new-hex new-mode
# $1 $2 $3 $4 $5 $6 $7
old_hex=$3
new_hex=`git-hash-object $5`
if [ "$old_hex" = "$new_hex" ]
then
exit 0
fi
echo "diff --git a/$1 b/$1"
echo "index ${old_hex:0:7}..${new_hex:0:7} $4"
diff -L a/$1 -L b/$1 -pc $2 $5
exit 0
--
which can be called by:
export GIT_EXTERNAL_DIFF=external-diff.sh
git-diff-index master -p > my.patch
Bye,
Thomas Kolejka
--
"Ein Herz für Kinder" - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de
Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's C
^ permalink raw reply
* Re: Mozilla, git and Windows
From: Robin Rosenberg @ 2006-11-27 16:37 UTC (permalink / raw)
To: Jon Smirl; +Cc: Andy Whitcroft, Git Mailing List
In-Reply-To: <9e4733910611270813g4ff982b0tbe6b57d1d49ca9f7@mail.gmail.com>
måndag 27 november 2006 17:13 skrev Jon Smirl:
> On 11/27/06, Andy Whitcroft <apw@shadowen.org> wrote:
> > I think you are more likely to win letting them convert over to SVN.
> > From there people naturally start using git mirrors from the SVN trunk.
> > Cirtainly I have two projects which do not use git, one in CVS and one
> > in SVN. I just svnimport that and work in git. I am confident with
> > time the project will migrate, but I am happy other git users are happy
> > all without it being the tool of choice.
>
> The SVN version of the Mozilla repository is about 3GB. It takes
> around a week of CPU time for svnimport to process it.
You can track parts of an SVN repo using git-svn. You rarely need the
whole history to start working on a project.
In addition some nice soul with too much hardware will probably make an import
and publish it and track it so everybody won't have to. We see a lot of
git-tracked repos SVN/CVS already.
^ 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