In ab2a1a32 Junio improved the reflog query logic to support obtaining the n-th prior value of a ref, but this was never documented in git-rev-parse. Now it is. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> --- Documentation/git-rev-parse.txt | 10 +++++++++- 1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt index 4eaf5a0..7bfbe1b 100644 --- a/Documentation/git-rev-parse.txt +++ ...

I'm guessing that the above was unintentional? -

Plain integer types without a fixed size can vary between platforms. Even though all common platforms use 32-bit ints, there is no guarantee that this won't change at some point. Furthermore, specifying an integer type with explicit size makes the definition of structures more obvious. --- pack.h | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/pack.h b/pack.h index 4814800..8aab5bb 100644 --- a/pack.h +++ b/pack.h @@ -10,9 +10,9 @@ #define PACK_VERSION 2 ...

Editors often give easier handling of patch files if the filename ends with .patch, so use it instead of .txt. Signed-off-by: Junio C Hamano <junkio@cox.net> --- Junio C Hamano <junkio@cox.net> writes: > "Josh Boyer" <jwboyer@gmail.com> writes: > >> On 1/17/07, Junio C Hamano <junkio@cox.net> wrote: >> >>> Two minor objections to changing the default are: (1) it's a >>> change and any change is bad ;-) and (2) the reason I changed it >>> to .txt before submitting the ...

This teaches "git-format-patch" to honor the --max-count parameter revision traversal machinery takes, so that you can say "git-format-patch -3" to process the three topmost commits from the current HEAD (or "git-format-patch -2 topic" to name a specific branch). Signed-off-by: Junio C Hamano <junkio@cox.net> --- * I think this is incompatible with --ignore-if-upstream, which I haven't bothered to look into yet. Likes, dislikes? builtin-log.c | 9 +++++++-- 1 files changed, ...

Hi, Uhm. What exactly _would_ be upstream? At the moment, for "--ignore-if-in-upstream" we handle _only_ ranges (a..b), where we treat the left part as the upstream, so we first parse all the diffs in b..a, and then ignore all commits in a..b which have an already-seen diff hash. However, if we want to do the logical analogue with "-22 HEAD", the It sure is supported by the principle of least surprise. Ciao, Dscho -

This adds --summary output in addition to the --stat to the output from git-format-patch by default. I think additions, removals and filemode changes are rare but notable events and always showing it makes sense. Signed-off-by: Junio C Hamano <junkio@cox.net> --- * An alternative would be to give --summary whenever --stat is asked for _any_ diff family of commands, which might make sense but I suspect is going too far. At least format-patch is a good place to add this since it ...

I do not think it is a bad idea to make the top-level README concise and sweet, but this has fallout in Documentation/git.txt which includes README and makes it into the Discussion section. The attached patch on top of yours would resurrect it. --- diff --git a/Documentation/Makefile b/Documentation/Makefile index 93c7024..9f2d242 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -71,14 +71,11 @@ doc.dep : $(wildcard *.txt) build-docdep.perl -include doc.dep ...

I see Junio beat me to it. Excellent :) josh -

David K

Julian Phillips <julian@quantumfyre.co.uk> wrote: It's a builtin in zsh and in ksh, and /not/ in tcsh here (Fedora rawhide) zsh-4.2.6-3.fc7 ksh-20060214-1.1 tcsh-6.14-13 It might be special configuration, but as they are mentioned in the manpages I'd guess not. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, ...

At least as far a OS X goes, it's installed on my machine (10.4.8) as /usr/bin/printf. I don't know if it's part of the Xcode packages, the "BSD Subsystem", or the core OS but I have a hard time imagining someone who didn't have them all installed using GIT. Also, it's man page identifies itself as "PRINTF(1) BSD General Commands Manual PRINTF(1)" so most, if not all, flavors of BSD and BSD-like should be alright. ~~ Brian -

printf is a bash builtin ... not sure about other shells. -- Julian --- A lifetime isn't nearly long enough to figure out what it's all about. -

Hi, All "patch" programs I know are happy without any massage. Ciao, Dscho -

Hi, [reCc'ing list] On Wed, 17 Jan 2007, Santi B

[...] perhaps? echo "* HEAD: resetted to $commit" Santi -

On Wednesday 2007 January 17 13:27, Santi B

... and only when HEAD is changed. Signed-off-by: Santi Béjar <sbejar@gmail.com> --- git-reset.sh | 19 +++++++++++++------ 1 files changed, 13 insertions(+), 6 deletions(-) diff --git a/git-reset.sh b/git-reset.sh index bf2a058..acefddc 100755 --- a/git-reset.sh +++ b/git-reset.sh @@ -24,6 +24,7 @@ do usage ;; *) + commit="$1" rev=$(git-rev-parse --verify "$1") || exit shift break @@ -84,14 +85,20 @@ fi git-update-ref -m "$GIT_REFLOG_ACTION" HEAD "$rev" ...

Having a suffix of "." when the user explicitly asked for none is somewhat confusing. Signed-off-by: Brian Gernhardt <benji@silverinsanity.com> --- builtin-log.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/builtin-log.c b/builtin-log.c index 04e3144..a60a987 100644 --- a/builtin-log.c +++ b/builtin-log.c @@ -276,7 +276,8 @@ static void reopen_stdout(struct commit *commit, int nr, int keep_subject) while (filename[len - 1] == '.' || filename[len - 1] == ...

I've considered it, but I do not think it is worth it. If we did so, the configuration would look like: [format] suffix = .txt which has a certain "Huh?" factor, and more importantly, a careless user would end up with a patchfile that is named: 0001-Introduce-git-format-patch-suffix-patchtxt which is I think much worse than not being able to say: 0001-Introduce-git-format-patch-suffix-patch But I do not care that much either way. -

The first part seems like the easiest way to allow --suffix="" actually remove the suffix while removing the "Huh?" factor you mentioned. In fact, having --suffix="" add a suffix of "." is somewhat confusing all on it's own. The second just seems like an easy way to keep stupid mistakes from occurring, but isn't needed. I'll still post the patch, but not add the extra DWIMmery. I think it's a better alternative than having to choose between putting "." in all the suffixes ...

Need to keep the length of that around for allocating string space and such. Is the flexibility worth the hassle? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 -

Hi, Why not static const char *file_extension = ".txt" Here, you would write and here: else if (!strncmp(argv[i], "--extension=", 12)) file_extension = argv[i] + 12; You'd call it with "--extension=.patch", and if you really want, you can make a config variable from it. Ciao, Dscho -

I think it is generally accepted on this list that that kind of DWIMmery is bad. -

Trivial patch. diff --git a/cache.h b/cache.h index 620b6a4..fda3f8e 100644 --- a/cache.h +++ b/cache.h @@ -317,7 +317,7 @@ void datestamp(char *buf, int bufsize); unsigned long approxidate(const char *); extern int setup_ident(void); -extern void ignore_missing_committer_name(); +extern void ignore_missing_committer_name(void); extern const char *git_author_info(int); extern const char *git_committer_info(int); @@ -400,7 +400,7 @@ extern void install_packed_git(struct packed_git ...

After all, my current implementation as "pull --to" mostly bypasses the fetch, so it probably makes sense to use a new command. However, "stg rebase <target>" does not sound right. I'm not very happy with "stg rebaseto <target>" (or rebase-to) either. "stg rebase --to <target>" may feel strange too (command without non-option arg), but may finally a good choice after all ? What do others think ? Best regards, -- Yann. -

Uwe Kleine-K

git push --exec=... is fine, but having it to specify every time is annoying. This sets the default remote program for pushing to remote <name>. Signed-off-by: Uwe Kleine-K

Please try again, starting from the "git fetch". I suspect the reason you think "merge FETCH_HEAD" does not work is because you lost FETCH_HEAD when you did "git pull . FETCH_HEAD", as I explained to you in an earlier message. -

Here (Fedora rawhide) /usr/bin/printf is part of coreutils. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 -

Hi, Hey, if others need that feature, I'm fine! And maybe I find myself in the need of exactly the same feature that I was opposed to, later in my life. Happened before, will happen again. Ciao, Dscho -

I did announce it way back when, but since it's included with new releases of Zsh there's really nothing interesting to add or link to. It's also in Zsh's CVS repository, but I do my updates here: http://git.bitwi.se/?p=dot-home.git;a=tree although I now realize that I haven't pushed some recent updates to that repository yet. nikolai -

Hi, So you want "git-repo-config --dump" to output something which has to be scanned for escaping sequences? If you call $ git repo-config -l you will _no longer_ see "\n"s, but rather newlines. I don't know why you insist on newlines, when a NUL makes perfect sense: Take everything until the next NUL. This is the key. Then take everything Yes, it returns "", but this is _wrong_. A single "[section] noval" _only_ makes sense as a boolean. The information lies in its ...

$ fatal: bad config file line <nn> in <config> The same with quoted: [someSection] qthisKey = "has\na\nvalue\with\nseveral\nnewlines" There is no escaping besides escaping " and escape character i.e. escaping \ in git config. Se "\n" would work as well as NUL. But only for "git repo-config --bool --get section.noval" output. Semantically equivalent to "true". -- Jakub Narebski Poland -

Then what did you mean in your mail from Jan 16, 2007 12:12 PM: How silly would that be: we parse an easy-to-read format, munge the easy-to-handle internal data format into another "easy-to-read" format which is then parsed by a script language into an easy-to-handle internal data format? No. NO. It is suboptimal because it's hard for computers to inspect. An optimal format would be accessible by all, whether human, machine, robot, android, what have you. I really don't like ...

Hi, No it would not: [someSection] but is equivalent to [section] noval = true Yes, this is not a boolean. The difference is that the callback function is called with NULL in the former case, and with "" in the latter. Hth, Dscho -

I meant to say "track", but somehow "fetch" got to my fingers. Old ages, perhaps. For different situations, there are different paths to choose to reach that ultimate "After All" (Zen? NO!). I offered one (little) path and expect to see more of bigger ones. That's the _why_ (and/or, the _why_ not). Quy -