The server I run various git snapshots on recently got upgraded to git 1.5.6, and I started getting a lot more mail from cron than usual. It seems that passing -q to git-clone at some point changed from 'silent' to 'slightly less noisy'. Only the difference is so slight that it may as well be nil.. Here's a normal clone.. Initialize git/.git Initialized empty Git repository in /home/davej/git-trees/git/.git/ remote: Counting objects: 76925, done. remote: Compressing objects: 100% (25373/25373),...

When the change is not about implementation detail (in which case you do want to name the source file and perhaps even a function name), but about a new feature that is visible to the end-users of a command, we'd want the message talk in terms of what the new feature does, not how the new feature is invoked nor where it is implemented. In other words, something like these are preferred: git-bundle: add --stdin Teach git-bundle to read tips and basis from standard input and don't say ...

Some other commands might like to support the --stdin option like git-rev-list. Since they don't want to depend on builtin-rev-list, the function has to be somewhere else. Signed-off-by: Adam Brewster <asb@bu.edu> --- builtin-rev-list.c | 17 ----------------- revision.c | 17 +++++++++++++++++ 2 files changed, 17 insertions(+), 17 deletions(-) mode change 100644 => 100755 builtin-rev-list.c mode change 100644 => 100755 revision.c diff --git a/builtin-rev-list.c b/b...

Apparently I'm dumber than I thought. Here's what they look like without random and unnecessary mode changes. The patch to add git-basis under contrib is not affected. The real reason read_revisions_from_stdin moved to revision.c is because I was asked to do it that way. If my commit message doesn't accurately describe the reason for the change, go ahead and edit the message, or let me know what the real reason is so I can provide a better message. Adam --

Teach git-bundle to read revision arguments from stdin like git-rev-list. This patch allows the caller to feed the revision parameters to git-bundle from its standard input. This way, a script do not have to worry about limitation of the length of command line. Documentation/git-bundle.txt says that git-bundle takes arguments acceptable to git-rev-list. Obviously some arguments that git-rev-list handles don't make sense for git-bundle (e.g. --bisect) but --stdin is pretty reasonable. Signed-o...

Git-basis is a perl script that remembers bases for use by git-bundle. This script shouldn't be needed because git-push and git-remote should do this kind of work. Unfortunately they currently don't so some might find this script useful. Signed-off-by: Adam Brewster <asb@bu.edu> --- contrib/basis/git-basis.perl | 77 ++++++++++++++++++++++++++++++++++++ contrib/basis/git-basis.txt | 90 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 167 insertions(+), 0 deletions(-) c...

The test failed on AIX (and likely other OS, such as apparently OSX) where wc -l outputs whitespace. Also, avoid unnecessary eval in conflict_count(). Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Changed. Mike, could you please confirm that this solves your problem as well? t/t7601-merge-pull-config.sh | 14 +++++++------- 1 files changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh index 32585f8..95b...

On Sat, Jul 05, 2008 at 02:57:12PM +0200, Johannes Schindelin <Johannes.Sch= As a user I would think that it tells git-merge to first try 'recursive' then 'theirs'. Of course you can still say that users should read the documentation, but... ;-)

How would you do the equivalent of git pull -s recursive -Xsubtree="My Playpen/" -Xours with the syntax? Note that the current scripted "pull" and "merge" has a limitation that it does not allow $IFS in -X<option> but that is not a designed-in limitation but purely comes from a lazy implementation . Also I do not see why -X<option> is not easy with parseopt() as Dscho claimed in the original message in this thread... --

As a policy on a project that I manage, almost every commit warrants a change to our NEWS (changelog) file, which end-users can browse to get an in-depth idea of the changes that have happened from the last release. If it's an added feature, the changelog includes a description of how to use it; if it's a fixed bug, it briefly describes what happened. Internal changes may or may not get added, depending on the visibility of the APIs affected. Something that I've noticed recently, as we've started m...

Sounds like a good first-step. It's very unlikely that we're going to bother writing our own merge strategy for the NEWS file, so if union ends up being more trouble than its worth, we'll probably end sticking with manual merges. Pieter also suggested (for some reason, I don't see the post on this list) the git-merge-changelog driver from Gnu Savannah. Unfortunately, the log format is a little different from ours (entries are sorted into BC-incompatible, features, bugfixes and internal changes), ...

These patches are related to the git_config_string "janitorial" work. There may be more cleanup possible, but these are the straightforward changes. Brian Hetro (5): builtin-commit.c: Use 'git_config_string' to get 'commit.template' builtin-log.c: Use 'git_config_string' to get 'format.subjectprefix' and 'format.suffix' convert.c: Use 'git_config_string' to get 'smudge' and 'clean' diff.c: Use 'git_config_string' to get 'diff.external' http.c: Use 'git_config_string' to clean up S...

Signed-off-by: Brian Hetro <whee@smaertness.net> --- builtin-log.c | 16 ++++------------ 1 files changed, 4 insertions(+), 12 deletions(-) diff --git a/builtin-log.c b/builtin-log.c index 9979e37..430d876 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -234,12 +234,8 @@ static int git_log_config(const char *var, const char *value, void *cb) { if (!strcmp(var, "format.pretty")) return git_config_string(&fmt_pretty, var, value); - if (!strcmp(var, "format.subjectprefix")) {...

Signed-off-by: Brian Hetro <whee@smaertness.net> --- diff.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/diff.c b/diff.c index 803fbba..6a39b39 100644 --- a/diff.c +++ b/diff.c @@ -153,12 +153,8 @@ int git_diff_ui_config(const char *var, const char *value, void *cb) diff_auto_refresh_index = git_config_bool(var, value); return 0; } - if (!strcmp(var, "diff.external")) { - if (!value) - return config_error_nonbool(var); - external_diff_cmd...

New users sometimes import a project and then immediately try to use the imported repository as a central shared repository. This provides pointers about setting up a bare repository for that in the parts of the documentation dealing with CVS migration. Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> --- I sent an earlier version of this patch about two weeks ago, but never got any feedback about it. This version rewords a couple of things and expands the commit message a littl...

As pointed out by Linus, this strategy tries to take the best merge base, but 'recursive' just does it better. If one needs something more than 'resolve' then he/she should really use 'recursive' and not 'stupid'. Given that it may still serve as a good example, don't remove it, just move it to contrib/examples. --- Oops, I forgot -M with format-patch. .gitignore | 1 - Makefile | 3 +-- .../examples/g...

Yes, I had something similar at one point (but not in compat). However, not all of these warnings are solved by the above. For example, the changes to builtin-fast-export.c, builtin-pack-objects.c, and pack-check.c do not involve ntohl() at all. (some hunks in other files do not involve ntohl() either). When the PRIu32 macro idea was suggested (I think it was Simon 'corecode' Schubert who first mentioned it), I thought it would look so ugly, no one would agree to such a patch... Having implement...

So you will check every 1ms to see if there are new dead children, but why is this necessary? --

Hmm. The question was not about the millisecond typo, but about why time-out at all. We would need to somehow break out of poll() after handling the SIGCHLD signal and I guess timing the syscall out would be the most obvious way, but somehow it felt awkward. Another way would be to set up a pipe to ourself that is included in the poll() and write a byte to the pipe from the signal handler. --

There is not a huge lot of possible meanings of "seq" in the given context. Somehow I find it hard to believe someone will be confused by a backend command with a short name "seq" (seq-uence-something?) It'll make the lines shorter, less need to wrap them. BTW, what does "am" (git am) mean? --

I always thought of it as "apply mbox". -- Thomas Adam --

Mentored-by: Christian Couder <chriscool@tuxfamily.org> Mentored-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Stephan Beyer <s-beyer@gmx.net> --- This contains some feedback of Jakub. Documentation/git-sequencer.txt | 387 +++++++++++++++++++++++++++++++++++++++ 1 files changed, 387 insertions(+), 0 deletions(-) create mode 100644 Documentation/git-sequencer.txt diff --git a/Documentation/git-sequencer.txt b/Documentation/git-sequencer.txt new file mode 100644...

I do not think we take a single letter abbrev so it should be fine. --

The test failed on AIX (and likely other OS, such as apparently OSX) where wc -l outputs whitespace. Signed-off-by: Mike Ralphson <mike@abacus.co.uk> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> --- Here is the same, with backticks avoided, and with a proper commit message. t/t7601-merge-pull-config.sh | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t7601-merge-pull-config.sh b/t/t7601-merge-pull-config.sh index 32585f8..12f71ad 100755 ---...