* Re: [PATCH] let core.excludesfile default to ~/.gitignore.
From: Stefan Naewe @ 2009-11-20 14:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git@vger.kernel.org, gitster@pobox.com
In-Reply-To: <1258723430-31684-1-git-send-email-Matthieu.Moy@imag.fr>
On 11/20/2009 2:23 PM, Matthieu Moy wrote:
> It seems this is the value most users set, so let's make it the default.
I like the idea but would suggest to use ~/.gitexcludes instead.
That way it doesn't clash with .gitignore if your $HOME is
under git-control.
Regards
Stefan
--
----------------------------------------------------------------
/dev/random says: INTERLACE: To tie two boots together.
^ permalink raw reply
* Re: Name/documentation on git-log --full-diff is insufficient
From: Tim Henigan @ 2009-11-20 14:19 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Phil Miller, Git Mailing List
In-Reply-To: <20091120140138.GB23718@genesis.frugalware.org>
On Fri, Nov 20, 2009 at 9:01 AM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Nov 19, 2009 at 05:26:33PM -0600, Phil Miller <mille121@illinois.edu> wrote:
>> PS: I sent in a patch for git-cvsserver a week ago, and have seen no
>> response or action on it. Is there something I should have done
>> differently?
>
> From MaintNotes:
>
> "If you sent a patch that you did not hear from anybody for three days,
> that is a very good indication that it was dropped on the floor ---
> please do not hesitate to remind me."
...also as noted in 'Documentation/SubmittingPatches':
- Patches should be placed inline in your email rather than attached.
- Patches should be addressed to both:
* gitster@pobox.com
* git@vger.kernel.org
You should also double-check your patch against the rest of the
guidelines in 'SubmittingPatches', to be sure it will apply cleanly.
^ permalink raw reply
* Re: Name/documentation on git-log --full-diff is insufficient
From: Miklos Vajna @ 2009-11-20 14:01 UTC (permalink / raw)
To: Phil Miller; +Cc: Git Mailing List
In-Reply-To: <81f018ac0911191526o1cfa8e56r79f8db33256a4e9c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Thu, Nov 19, 2009 at 05:26:33PM -0600, Phil Miller <mille121@illinois.edu> wrote:
> PS: I sent in a patch for git-cvsserver a week ago, and have seen no
> response or action on it. Is there something I should have done
> differently?
From MaintNotes:
"If you sent a patch that you did not hear from anybody for three days,
that is a very good indication that it was dropped on the floor ---
please do not hesitate to remind me."
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-20 13:50 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20091120133117.GA26917@diku.dk>
On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> Build with asciidoc-8.4.5
..
> Update asciidoc table syntax to the one supported by version 8.4.4
sciidoc -aversion=0.15-dirty -asysconfdir=/usr/etc -b docbook -d manpage tigmanual.7.txt
FAILED: /home/bill/src/tig/manual.txt: line 314: illegal [paradef-default] options: header: header
make: *** [tigmanual.7.xml] Error 1
May be the asciidoc 8.2.7 in debian lenny is not new enough. make install-doc
failed with the above message. Any workaround other than upgrading asciidoc ?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-20 13:31 UTC (permalink / raw)
To: git
Hello,
After a long time of silence, here is a brand new version of tig with
changes that has accummulated since version 0.14.1. It mainly brings
minor improvements for tweaking tig usage via keybindings and options.
Thanks to everybody who provided patches.
What is tig?
------------
Tig is an ncurses-based text-mode interface for git. It functions mainly
as a git repository browser, but can also assist in staging changes for
commit at chunk level and act as a pager for output from various git
commands.
- Homepage: http://jonas.nitro.dk/tig/
- Manual: http://jonas.nitro.dk/tig/manual.html
- Tarballs: http://jonas.nitro.dk/tig/releases/
- Git URL: git://repo.or.cz/tig.git
- Gitweb: http://repo.or.cz/w/tig.git
Release notes
-------------
Incompatibilities:
- Setting the cursor color no longer automatically sets the text to
bold. The old 'lazy' behavior was a bug.
- Remove check for git-repo-config, which was officially deprecated in
git version 1.5.4. The configure script no longer depends on git
being installed.
Improvements:
- Provide the manual as a man page named tigmanual(7).
- Add ability to toggle between showing shorter dates (without time
info) and relative dates. Use 'D' to toggle between date formats.
- Show the active (instead of the default) keybindings in the help
view. Furthermore, honor the keymap when suggesting actions in the
help messages.
- Add branch view for choosing which branch to display in the main
view. Bound to 'H' by default.
- Tree view: show entry to parent directory ('..') when running from
subdirectory.
- Tree view: sort entries by name, date or author. Toggling is bound to
'i' by default, with 'I' controlling whether or not to sort in
ascending order.
- Make height of the lower view in a split view configurable by setting
the 'split-view-height' variable to a number or a percentage.
Defaults to 2/3 of the total view height.
- Allow multiple text attributes for color commands:
color cursor white blue underline bold
Bug fixes:
- Blame view: fix loading of blame data when opened from the tree view
and CWD is not the repo root. (Debian bug 540766)
- Tree view: fix searching.
Change summary
--------------
The diffstat and log summary for changes made in this release.
.gitignore | 1 +
INSTALL | 40 +-
Makefile | 13 +-
NEWS | 39 ++
TODO | 3 -
VERSION | 2 +-
configure.ac | 7 -
contrib/aspell.dict | 8 +-
manual.txt | 249 ++++----
tig.1.txt | 2 +-
tig.c | 1549 ++++++++++++++++++++++++++++++-------------
tigmanual.7.txt | 20 +
tigrc.5.txt | 365 +++++------
13 files changed, 1497 insertions(+), 801 deletions(-)
Giuseppe Bilotta (2):
Fix previous/next with branch+main view
Predefined external command: git commit
Ingmar Vanhassel (1):
Makefile: Fix typo in 157ebf54
Jeff King (1):
Add missing NULL in blame_grep
Jonas Fonseca (40):
Add small cache for author names to reduce memory foot-print
Reduce memory and startup time by storing author times as time_t
Simplify searching in view lines by defining grep_text utility
Define a tree_grep and fixing searching
Make the granular allocators more customizable using macros
Remove the need for alloc variables
Define an allocator for run requests
Update the current branch information when reloading all references
Fix a potential problem with reading tokens larger then BUFSIZ
Add primitive branch view
Minor fix to always sort even if allocation fails in get_refs
Use temporary variable in refs loop in main_draw
Branch view: fix loading to handle when two branches have same commit
Add support for sorting tree entries by name, date or author
Add support for sorting branch entries by name, date and author
Fix reloading of references to not cause access to freed memory
Restore the branch view position after refreshing
Add simple support for showing menues and use it for showing option menu
Use menus with the commit subject to present selectable commit parents
Fix memory allocation check in open_commit_parent_menu
Manual: document that :<number> jumps to the line number
Remove macros which are only used for default option values
Allow multiple text attributes for color commands
Build with asciidoc-8.4.5
Show the active (instead of the default) keybindings in the help view
Merge remote branch 'samb/short-dates'
NEWS: Mention date-shorten feature
Add support for displaying relative dates
Fix draw_date to not format anything when time arg is NULL
Fix loading of blame data when opened from the tree view
NEWS: Improve bug fix description
Update asciidoc table syntax to the one supported by version 8.4.4
tigmanual(7): provide the manual as a man page
Remove build dependency on git from the configure script
begin_update: simplify control flow
run_io_dir: take dir argument
run_io_rd_dir: obsolete by switching call sites to run_io_rd_dir
io_open: take path as a vararg format
Status view: special case revert of unmerged entries with no physical file
tig-0.15
Samuel Bronson (1):
Add an option (and toggle) for shortening the date column by skipping the time.
Sebastian Harl (1):
Fixed some uninitialized variable warnings
Tilo Schwarz (1):
Make height of split view configurable
bill lam (1):
Fix whitespace
--
Jonas Fonseca
^ permalink raw reply
* [PATCH] let core.excludesfile default to ~/.gitignore.
From: Matthieu Moy @ 2009-11-20 13:23 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
It seems this is the value most users set, so let's make it the default.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
A funny experiment:
http://www.google.com/search?q=core.excludesfile+-%22~/.gitignore%22
Results 1 - 10 of about 3,890 for core.excludesfile -"~/.gitignore"
http://www.google.com/search?q=core.excludesfile+%22~/.gitignore%22
Results 1 - 10 of about 7,990 for core.excludesfile "~/.gitignore"
So, most of the time someone mentions core.excludesfile on the web,
~/.gitignore is mentionned right after.
I'd have expected a place near config.c to set the default value for
any config variable, but I can't find such thing, so I guess the
caller is the one that should set the default, which is what I do in
the patch.
Documentation/config.txt | 1 +
dir.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 39d1226..0c55e52 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -384,6 +384,7 @@ core.excludesfile::
of files which are not meant to be tracked. "~/" is expanded
to the value of `$HOME` and "~user/" to the specified user's
home directory. See linkgit:gitignore[5].
+ Default: ~/.gitignore.
core.editor::
Commands such as `commit` and `tag` that lets you edit
diff --git a/dir.c b/dir.c
index d0999ba..dcea6ad 100644
--- a/dir.c
+++ b/dir.c
@@ -914,9 +914,16 @@ void setup_standard_excludes(struct dir_struct *dir)
dir->exclude_per_dir = ".gitignore";
path = git_path("info/exclude");
+ if (!excludes_file) {
+ const char *home = getenv("HOME");
+ char *user_gitignore = malloc(strlen(home) + strlen("/.gitignore") + 1);
+ strcpy(user_gitignore, home);
+ strcat(user_gitignore, "/.gitignore");
+ excludes_file = user_gitignore;
+ }
if (!access(path, R_OK))
add_excludes_from_file(dir, path);
- if (excludes_file && !access(excludes_file, R_OK))
+ if (!access(excludes_file, R_OK))
add_excludes_from_file(dir, excludes_file);
}
--
1.6.5.2.152.gbbe9e
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Jakub Narebski @ 2009-11-20 12:46 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
Adrian May <adrian.alexander.may@gmail.com> writes:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them. It doesn't have the kind of triggers you
> need to assert change control either, and these bolt-on scripts are
> just making life messy. Will somebody please finish git itself instead
> of working around it, or use a source control system that's up to the
> job.
Your complaing have the same sense as complaining that gcc does not
include functionality of Makefile, because you just can't manage
larger projects without it (or equivalent).
Do one thing, and do it well.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] bash completion: add space between branch name and status flags
From: Roman Fietze @ 2009-11-20 12:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Hello Shawn, hello git list members,
Wouldn't it improve the readability of the bash prompt, if there would
be a space between the branch name and the status flags (dirty, stash,
untracked)?
Signed-off-by: Roman Fietze <roman.fietze@telemotive.de>
---
contrib/completion/git-completion.bash | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-
completion.bash
index bd66639..407176b 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -169,10 +169,12 @@ __git_ps1 ()
fi
fi
+ local f="$w$i$s$u$r"
+ f=${f:+ $f}
if [ -n "${1-}" ]; then
- printf "$1" "$c${b##refs/heads/}$w$i$s$u$r"
+ printf "$1" "$c${b##refs/heads/}$f"
else
- printf " (%s)" "$c${b##refs/heads/}$w$i$s$u$r"
+ printf " (%s)" "$c${b##refs/heads/}$f"
fi
fi
}
--
1.6.4.2
Roman
--
Roman Fietze Telemotive AG Büro Mühlhausen
Breitwiesen 73347 Mühlhausen
Tel.: +49(0)7335/18493-45 http://www.telemotive.de
^ permalink raw reply related
* Re: Ambiguous ref names
From: Jeenu V @ 2009-11-20 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpr7dzckl.fsf@alter.siamese.dyndns.org>
On Fri, Nov 20, 2009 at 4:29 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeenu V <jeenuv@gmail.com> writes:
>
>> On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> [...]
>>> It could be that you have a tag and a branch that are both named a.b.c,
>>> though.
>>
>> Hm, right. But I'm getting this from an existing local repo of mine. I
>> can't see any tags; 'git tag -l' is empty. Is there any more info that
>> I can provide?
>
> man git-for-each-ref?
It does list all refs that I know of, but I don't see any duplicate entries.
--
:J
^ permalink raw reply
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Petr Baudis @ 2009-11-20 11:50 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
On Fri, Nov 20, 2009 at 06:51:32PM +0800, Adrian May wrote:
> It doesn't have the kind of triggers you
> need to assert change control either, and these bolt-on scripts are
> just making life messy.
Can you elaborate?
Petr "Pasky" Baudis
^ permalink raw reply
* [PATCH] submodule.c: Squelch a "use before assignment" warning
From: David Aguilar @ 2009-11-20 11:33 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <7v8we17ha9.fsf@alter.siamese.dyndns.org>
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) compiler
(and probably others) mistakenly thinks variable 'right' is used
before assigned. Work around it by giving it a fake initialization.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
submodule.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/submodule.c b/submodule.c
index 461faf0..86aad65 100644
--- a/submodule.c
+++ b/submodule.c
@@ -38,7 +38,7 @@ void show_submodule_summary(FILE *f, const char *path,
const char *del, const char *add, const char *reset)
{
struct rev_info rev;
- struct commit *commit, *left = left, *right;
+ struct commit *commit, *left = left, *right = right;
struct commit_list *merge_bases, *list;
const char *message = NULL;
struct strbuf sb = STRBUF_INIT;
--
1.6.5.3.171.ge36e
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Johannes Schindelin @ 2009-11-20 11:31 UTC (permalink / raw)
To: Adrian May; +Cc: git
In-Reply-To: <65e170e70911200251q2ec5ec87rc37577dddfd3317d@mail.gmail.com>
Hi,
On Fri, 20 Nov 2009, Adrian May wrote:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them.
You are plain wrong, because that is possible. Did you maybe forget to do
your homework before coming here and shouting around as if you were right?
> It doesn't have the kind of triggers you need to assert change control
> either, and these bolt-on scripts are just making life messy.
To the contrary, these "bolt-on scripts" are superior to other solutions,
because they give the savvy user freedom to do _anything_ a program can
do.
> Will somebody please finish git itself instead of working around it, or
> use a source control system that's up to the job.
You obviously do not understand Open Source. If you have an itch, scratch
it, or pay somebody to scratch it for you.
> PS: In both cases, I had problems pulling the code.
If you had problems pulling the code, there are two possible sources of
problems: the program or a PEBCAK.
Ciao,
Dscho
P.S.: Feels fine to vent for me, too.
^ permalink raw reply
* [PATCH 3/3] Make --stdin option to "log" family read also pathspecs
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
Similar to the command line arguments, after giving zero or more revs, you can
feed a line "--" and then feed pathspecs one at a time.
With this
(
echo ^maint
echo --
echo Documentation
) | git log --stat --oneline --stdin master -- t
lists commits that touch Documentation/ or t/ between maint and master.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 68 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 4410a45..8750c20 100644
--- a/revision.c
+++ b/revision.c
@@ -953,9 +953,38 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
return 0;
}
-static void read_revisions_from_stdin(struct rev_info *revs)
+static void read_pathspec_from_stdin(struct rev_info *revs, struct strbuf *sb, const char ***prune_data)
+{
+ const char **prune = *prune_data;
+ int prune_nr;
+ int prune_alloc;
+
+ /* count existing ones */
+ if (!prune)
+ prune_nr = 0;
+ else
+ for (prune_nr = 0; prune[prune_nr]; prune_nr++)
+ ;
+ prune_alloc = prune_nr; /* not really, but we do not know */
+
+ while (strbuf_getwholeline(sb, stdin, '\n') != EOF) {
+ int len = sb->len;
+ if (len && sb->buf[len - 1] == '\n')
+ sb->buf[--len] = '\0';
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr++] = xstrdup(sb->buf);
+ }
+ if (prune) {
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr] = NULL;
+ }
+ *prune_data = prune;
+}
+
+static void read_revisions_from_stdin(struct rev_info *revs, const char ***prune)
{
struct strbuf sb;
+ int seen_dashdash = 0;
strbuf_init(&sb, 1000);
while (strbuf_getwholeline(&sb, stdin, '\n') != EOF) {
@@ -964,11 +993,18 @@ static void read_revisions_from_stdin(struct rev_info *revs)
sb.buf[--len] = '\0';
if (!len)
break;
- if (sb.buf[0] == '-')
+ if (sb.buf[0] == '-') {
+ if (len == 2 && sb.buf[1] == '-') {
+ seen_dashdash = 1;
+ break;
+ }
die("options not supported in --stdin mode");
+ }
if (handle_revision_arg(sb.buf, revs, 0, 1))
die("bad revision '%s'", sb.buf);
}
+ if (seen_dashdash)
+ read_pathspec_from_stdin(revs, &sb, prune);
strbuf_release(&sb);
}
@@ -1220,6 +1256,34 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
ctx->argc -= n;
}
+static void append_prune_data(const char ***prune_data, const char **av)
+{
+ const char **prune = *prune_data;
+ int prune_nr;
+ int prune_alloc;
+
+ if (!prune) {
+ *prune_data = av;
+ return;
+ }
+
+ /* count existing ones */
+ for (prune_nr = 0; prune[prune_nr]; prune_nr++)
+ ;
+ prune_alloc = prune_nr; /* not really, but we do not know */
+
+ while (*av) {
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr++] = *av;
+ av++;
+ }
+ if (prune) {
+ ALLOC_GROW(prune, prune_nr+1, prune_alloc);
+ prune[prune_nr] = NULL;
+ }
+ *prune_data = prune;
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -1294,7 +1358,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
}
if (read_from_stdin++)
die("--stdin given twice?");
- read_revisions_from_stdin(revs);
+ read_revisions_from_stdin(revs, &prune_data);
continue;
}
@@ -1322,7 +1386,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
for (j = i; j < argc; j++)
verify_filename(revs->prefix, argv[j]);
- prune_data = argv + i;
+ append_prune_data(&prune_data, argv + i);
break;
}
}
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* [PATCH 2/3] setup_revisions(): do not call get_pathspec() too early
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
This is necessary because in the next patch I'll allow pathspecs to be fed
from the standard input, and pathspecs taken from the command line (and
converted via get_pathspec() already) in revs->prune_data too early gets
in the way when we want to append from the standard input.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/revision.c b/revision.c
index f5b735f..4410a45 100644
--- a/revision.c
+++ b/revision.c
@@ -1230,6 +1230,7 @@ void parse_revision_opt(struct rev_info *revs, struct parse_opt_ctx_t *ctx,
int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def)
{
int i, flags, left, seen_dashdash, read_from_stdin;
+ const char **prune_data = NULL;
/* First, search for "--" */
seen_dashdash = 0;
@@ -1240,7 +1241,7 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
argv[i] = NULL;
argc = i;
if (argv[i + 1])
- revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
+ prune_data = argv + i + 1;
seen_dashdash = 1;
break;
}
@@ -1321,12 +1322,14 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
for (j = i; j < argc; j++)
verify_filename(revs->prefix, argv[j]);
- revs->prune_data = get_pathspec(revs->prefix,
- argv + i);
+ prune_data = argv + i;
break;
}
}
+ if (prune_data)
+ revs->prune_data = get_pathspec(revs->prefix, prune_data);
+
if (revs->def == NULL)
revs->def = def;
if (revs->show_merge)
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* [PATCH 1/3] read_revision_from_stdin(): use strbuf
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
It is so 2005 (and Linus ;-) to have a fixed 1000-byte buffer that
reads from the user. Let's use strbuf to unlimit the input length.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 18 ++++++++++--------
1 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/revision.c b/revision.c
index 45c5de8..f5b735f 100644
--- a/revision.c
+++ b/revision.c
@@ -955,19 +955,21 @@ int handle_revision_arg(const char *arg, struct rev_info *revs,
static void read_revisions_from_stdin(struct rev_info *revs)
{
- char line[1000];
+ struct strbuf sb;
- while (fgets(line, sizeof(line), stdin) != NULL) {
- int len = strlen(line);
- if (len && line[len - 1] == '\n')
- line[--len] = '\0';
+ strbuf_init(&sb, 1000);
+ while (strbuf_getwholeline(&sb, stdin, '\n') != EOF) {
+ int len = sb.len;
+ if (len && sb.buf[len - 1] == '\n')
+ sb.buf[--len] = '\0';
if (!len)
break;
- if (line[0] == '-')
+ if (sb.buf[0] == '-')
die("options not supported in --stdin mode");
- if (handle_revision_arg(line, revs, 0, 1))
- die("bad revision '%s'", line);
+ if (handle_revision_arg(sb.buf, revs, 0, 1))
+ die("bad revision '%s'", sb.buf);
}
+ strbuf_release(&sb);
}
static void add_grep(struct rev_info *revs, const char *ptn, enum grep_pat_token what)
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* [PATCH 0/3] "log --stdin" updates
From: Junio C Hamano @ 2009-11-20 11:25 UTC (permalink / raw)
To: git
These three come on top of 61ab67a (Teach --stdin option to "log" family,
2009-11-03), which gave "--stdin" to the log family of commands (e.g. log,
rev-list). The earlier patch allowed you to feed only the revs (which was
what gitk originally wanted), but after zero or more revs (one rev per
line), you can now feed a line that consists of "--" and then pathspecs
(one path per line).
The whole series probably need to be updated to learn -z option to read
NUL terminated input.
Junio C Hamano (3):
read_revision_from_stdin(): use strbuf
setup_revisions(): do not call get_pathspec() too early
Make --stdin option to "log" family read also pathspecs
revision.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 82 insertions(+), 13 deletions(-)
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 11:02 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johan Herland, git, spearce
In-Reply-To: <7vk4xl1nkl.fsf@alter.siamese.dyndns.org>
By the way, we could probably use this to make the command sequence even
shorter.
I have to warn that this has never been used in real life, unlike the
"checkout A...B" one --- caveat emptor.
Also I didn't bother touching up "rebase -i"; it is left as an excercise
to the readers ;-)
-- >8 --
Subject: [PATCH] "rebase --onto A...B" replays history on the merge base between A and B
This is in spirit similar to "checkout A...B". To re-queue a new set of
patches for a series that the original author prepared to apply on 'next'
on the same base as before, you would do something like this:
$ git checkout next^0
$ git am -s rerolled-series.mbox
$ git rebase --onto next...jh/notes next
The first two commands recreates commits to be rebased as the original
author intended (i.e. applies directly on top of 'next'), and the rebase
command replays that history on top of the same commit the series being
replaced was built on (which is typically much older than the tip of
'next').
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-rebase.sh | 19 ++++++++++++++++++-
1 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 6830e16..570e2b6 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -34,6 +34,8 @@ set_reflog_action rebase
require_work_tree
cd_to_toplevel
+LF='
+'
OK_TO_SKIP_PRE_REBASE=
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
@@ -417,7 +419,22 @@ fi
# Make sure the branch to rebase onto is valid.
onto_name=${newbase-"$upstream_name"}
-onto=$(git rev-parse --verify "${onto_name}^0") || exit
+if left=$(expr "$onto_name" : '\(.*\)\.\.\.') &&
+ right=$(expr "$onto_name" : '\.\.\.\(.*\)$') &&
+ : ${left:=HEAD} ${right:=HEAD} &&
+ onto=$(git merge-base "$left" "$right")
+then
+ case "$onto" in
+ ?*"$LF"?*)
+ die "$onto_name: there are more than one merge bases"
+ ;;
+ '')
+ die "$onto_name: there is no merge base"
+ ;;
+ esac
+else
+ onto=$(git rev-parse --verify "${onto_name}^0") || exit
+fi
# If a hook exists, give it a chance to interrupt
run_pre_rebase_hook "$upstream_arg" "$@"
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* Re: Ambiguous ref names
From: Junio C Hamano @ 2009-11-20 10:59 UTC (permalink / raw)
To: Jeenu V; +Cc: Junio C Hamano, git
In-Reply-To: <5195c8760911200248v1f3d6b56q78987edfceae5541@mail.gmail.com>
Jeenu V <jeenuv@gmail.com> writes:
> On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> [...]
>> It could be that you have a tag and a branch that are both named a.b.c,
>> though.
>
> Hm, right. But I'm getting this from an existing local repo of mine. I
> can't see any tags; 'git tag -l' is empty. Is there any more info that
> I can provide?
man git-for-each-ref?
^ permalink raw reply
* Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Adrian May @ 2009-11-20 10:51 UTC (permalink / raw)
To: git
In-Reply-To: <2d707e8c-2561-470c-beba-c81e16ac441c@k17g2000yqh.googlegroups.com>
Git is just plain wrong, because you can't split or merge repositories
or pull subtrees of them. It doesn't have the kind of triggers you
need to assert change control either, and these bolt-on scripts are
just making life messy. Will somebody please finish git itself instead
of working around it, or use a source control system that's up to the
job.
Adrian.
PS: In both cases, I had problems pulling the code.
^ permalink raw reply
* Re: Ambiguous ref names
From: Jeenu V @ 2009-11-20 10:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl6h3319.fsf@alter.siamese.dyndns.org>
On Fri, Nov 20, 2009 at 3:56 PM, Junio C Hamano <gitster@pobox.com> wrote:
> [...]
> It could be that you have a tag and a branch that are both named a.b.c,
> though.
Hm, right. But I'm getting this from an existing local repo of mine. I
can't see any tags; 'git tag -l' is empty. Is there any more info that
I can provide?
FWIW, I'm running Git under Cygwin.
--
:J
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 10:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johan Herland, git, spearce
In-Reply-To: <20091120192800.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
>> Step 0. Apply as you specified on top of 'next'
>>
>> $ git checkout next^0
>> $ git am -s your-10-patches
>> $ M=$(git describe)
>>
>> Step 1. Rebase back to the bottom of the old series
>>
>> $ git checkout next...jh/notes
>
> What do three-dots mean in this command?
>
>> $ git rebase --onto HEAD next $M
>> $ N=$(git describe)
Heh, good eyes.
I forgot that I had this toy hidden from the general public.
-- >8 --
Subject: [PATCH] "checkout A...B" switches to the merge base between A and B
When flipping commits around on topic branches, I often end up doing
this sequence:
* Run "log --oneline next..jc/frotz" to find out the first commit
on 'jc/frotz' branch not yet merged to 'next';
* Run "checkout $that_commit^" to detach HEAD to the parent of it;
* Rebuild the series on top of that commit; and
* "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify.
Introduce a new syntax to "git checkout" to name the commit to switch to,
to make the first two steps easier. When the branch to switch to is
specified as A...B (you can omit either A or B but not both, and HEAD
is used instead of the omitted side), the merge base between these two
commits are computed, and if there is one unique one, we detach the HEAD
at that commit.
With this, I can say "checkout next...jc/frotz".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 7 +++++--
cache.h | 1 +
sha1_name.c | 42 ++++++++++++++++++++++++++++++++++++++++++
t/t2012-checkout-last.sh | 27 ++++++++++++++++++++++++++-
4 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..7167111 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -690,7 +690,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
* case 3: git checkout <something> [<paths>]
*
* With no paths, if <something> is a commit, that is to
- * switch to the branch or detach HEAD at it.
+ * switch to the branch or detach HEAD at it. As a special case,
+ * if <something> is A...B (missing A or B means HEAD but you can
+ * omit at most one side), and if there is a unique merge base
+ * between A and B, A...B names that merge base.
*
* With no paths, if <something> is _not_ a commit, no -t nor -b
* was given, and there is a tracking branch whose name is
@@ -716,7 +719,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (!strcmp(arg, "-"))
arg = "@{-1}";
- if (get_sha1(arg, rev)) {
+ if (get_sha1_mb(arg, rev)) {
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
if (!patch_mode &&
diff --git a/cache.h b/cache.h
index 71a731d..f8df15a 100644
--- a/cache.h
+++ b/cache.h
@@ -703,6 +703,7 @@ extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
extern int interpret_branch_name(const char *str, struct strbuf *);
+extern int get_sha1_mb(const char *str, unsigned char *sha1);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..d5a240c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -794,6 +794,48 @@ release_return:
return retval;
}
+int get_sha1_mb(const char *name, unsigned char *sha1)
+{
+ struct commit *one, *two;
+ struct commit_list *mbs;
+ unsigned char sha1_tmp[20];
+ const char *dots;
+ int st;
+
+ dots = strstr(name, "...");
+ if (!dots)
+ return get_sha1(name, sha1);
+ if (dots == name)
+ st = get_sha1("HEAD", sha1_tmp);
+ else {
+ struct strbuf sb;
+ strbuf_init(&sb, dots - name);
+ strbuf_add(&sb, name, dots - name);
+ st = get_sha1(sb.buf, sha1_tmp);
+ strbuf_release(&sb);
+ }
+ if (st)
+ return st;
+ one = lookup_commit_reference_gently(sha1_tmp, 0);
+ if (!one)
+ return -1;
+
+ if (get_sha1(dots[3] ? (dots + 3) : "HEAD", sha1_tmp))
+ return -1;
+ two = lookup_commit_reference_gently(sha1_tmp, 0);
+ if (!two)
+ return -1;
+ mbs = get_merge_bases(one, two, 1);
+ if (!mbs || mbs->next)
+ st = -1;
+ else {
+ st = 0;
+ hashcpy(sha1, mbs->item->object.sha1);
+ }
+ free_commit_list(mbs);
+ return st;
+}
+
/*
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
* notably "xyz^" for "parent of xyz"
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index 87b30a2..b44de9d 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='checkout can switch to last branch'
+test_description='checkout can switch to last branch and merge base'
. ./test-lib.sh
@@ -91,4 +91,29 @@ test_expect_success 'switch to twelfth from the last' '
test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch13"
'
+test_expect_success 'merge base test setup' '
+ git checkout -b another other &&
+ echo "hello again" >>world &&
+ git add world &&
+ git commit -m third
+'
+
+test_expect_success 'another...master' '
+ git checkout another &&
+ git checkout another...master &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
+test_expect_success '...master' '
+ git checkout another &&
+ git checkout ...master &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
+test_expect_success 'master...' '
+ git checkout another &&
+ git checkout master... &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
test_done
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* Re: [RFC/PATCHv8 00/10] git notes
From: Johannes Schindelin @ 2009-11-20 10:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Johan Herland, git, spearce
In-Reply-To: <20091120192800.6117@nanako3.lavabit.com>
Hi,
On Fri, 20 Nov 2009, Nanako Shiraishi wrote:
> Quoting Junio C Hamano <gitster@pobox.com>
>
> > So here is what I did tonight.
> >
> > Step 0. Apply as you specified on top of 'next'
> >
> > $ git checkout next^0
> > $ git am -s your-10-patches
> > $ M=$(git describe)
> >
> > Step 1. Rebase back to the bottom of the old series
> >
> > $ git checkout next...jh/notes
>
> What do three-dots mean in this command?
Maybe it means "go back to the bottom of the old series"? ;-) IIUC it is
the equivalent of
$ git checkout $(git merge-base next jh/notes)
Hth,
Dscho
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Nanako Shiraishi @ 2009-11-20 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, spearce
In-Reply-To: <7vk4xl5y3z.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> So here is what I did tonight.
>
> Step 0. Apply as you specified on top of 'next'
>
> $ git checkout next^0
> $ git am -s your-10-patches
> $ M=$(git describe)
>
> Step 1. Rebase back to the bottom of the old series
>
> $ git checkout next...jh/notes
What do three-dots mean in this command?
> $ git rebase --onto HEAD next $M
> $ N=$(git describe)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Ambiguous ref names
From: Junio C Hamano @ 2009-11-20 10:26 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <5195c8760911200218v5b75d690hbaaf00b44c8df6af@mail.gmail.com>
Jeenu V <jeenuv@gmail.com> writes:
> If I've two branches a.b.c and a.b.c.d, why does 'git checkout'
> complains about ambiguous ref names?
Because it doesn't???
: demo; git init
Initialized empty Git repository in /var/tmp/gomi/twelve/.git/
: demo/master; >f
: demo/master; git add f
: demo/master; git commit -a -m 'initial'
[master (root-commit) cb1d5f2] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 f
: demo/master; git branch a.b.c
: demo/master; git branch a.b.c.d
: demo/master; git checkout a.b.c
Switched to branch 'a.b.c'
It could be that you have a tag and a branch that are both named a.b.c,
though.
^ permalink raw reply
* Ambiguous ref names
From: Jeenu V @ 2009-11-20 10:18 UTC (permalink / raw)
To: git
Hi,
I'm re-posting this from the git-users Google Groups:
If I've two branches a.b.c and a.b.c.d, why does 'git checkout'
complains about ambiguous ref names? For example, if I'm in a.b.c.d,
896 $ git checkout a.b.c
warning: refname 'a.b.c' is ambiguous.
Switched to branch "a.b.c"
Is this some kind of a side effect of commit abbreviation? If so is
this kind of branch naming considered unsafe? Is there a way to make
git accept ref names verbatim, even if there's potential operation
that'd fail because of ambiguity?
--
:J
^ 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