* 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] 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: 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
* 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
* [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: 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] 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
* [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
* 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
* 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: 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: [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: [PATCH 0/3] "log --stdin" updates
From: Jeff King @ 2009-11-20 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1258716315-2213-1-git-send-email-gitster@pobox.com>
On Fri, Nov 20, 2009 at 03:25:12AM -0800, Junio C Hamano wrote:
> 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).
This looks like a good API feature, though I am curious about the
missing "4/3" that was the motivation (of course, with a feature
like this, it may be for your out-of-git script, but as I said, I am
curious :) ). Is it a response to
http://article.gmane.org/gmane.comp.version-control.git/133268
?
The implementation looks good from my cursory reading. Tests and docs
are of course missing. We don't seem to have any rev-list --stdin tests
already. Maybe even something as simple as:
git rev-list HEAD -- file >expect &&
(echo HEAD; echo --; echo file) | git rev-list --stdin >actual &&
test_cmp expect actual
For docs, maybe squash this in (it mentions the pathspecs, but also
loosens --stdin to be available for "git log" and friends, which should
have been part of 61ab67a).
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index bf66116..b44fdd9 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -243,12 +243,14 @@ endif::git-rev-list[]
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
on the command line as '<commit>'.
-ifdef::git-rev-list[]
--stdin::
In addition to the '<commit>' listed on the command
- line, read them from the standard input.
+ line, read them from the standard input. If a '--' separator is
+ seen, stop reading commits and start reading paths to limit the
+ result.
+ifdef::git-rev-list[]
--quiet::
Don't print anything to standard output. This form
^ permalink raw reply related
* Re: Default history simplification
From: Jeff King @ 2009-11-20 14:41 UTC (permalink / raw)
To: Tommy Wang; +Cc: git
In-Reply-To: <ae09c2a40911191530y626dd035q90de0212e0b4b6d8@mail.gmail.com>
On Thu, Nov 19, 2009 at 05:30:43PM -0600, Tommy Wang wrote:
> I'm working on a small perl script that needs to reproduce the results
> of the default git history simplification used by log & rev-list when
> a list of paths is given. It is important that I reproduce its
> results exactly. I would love to simply use the rev-list built-in to
> do my work for me; but I fear that I may have much too many path
> limiters than the linux command-line can handle (which if I'm correct,
> can only take so many arguments).
FYI, Junio just posted a patch for handling pathspec limiting over
--stdin, which would solve this problem for you.
http://article.gmane.org/gmane.comp.version-control.git/133333
-Peff
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Dmitry Potapov @ 2009-11-20 15:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: George Dennie, 'Jan Krüger', git
In-Reply-To: <7vmy2h904e.fsf@alter.siamese.dyndns.org>
On Thu, Nov 19, 2009 at 10:33:05PM -0800, Junio C Hamano wrote:
> Dmitry Potapov <dpotapov@gmail.com> writes:
>
> > It is more difficult to make this mistake with Git than many others
> > VCSes, because Git shows the list of files that are changed but not
> > committed as well as the list of untracked files when you try to commit
> > something.
>
> Not really in practice. Too many people carry their existing practice of
> using -m to write a useless single liner commit log message that they
> acquired while using their previous SCM.
Well, at least, Git allows to avoid this mistake and produce good commit
messages, but you are right it is difficult to break old bad habits...
> Arguably, useless log messages
> are less of a problem on systems like CVS/SVN because they do not do
> useful log summarization such as "log -- paths..." or "shortlog", so they
> can be excused for learning the practice in the first place, though.
I think quite often commits in CVS/SVN cannot be summarized, because a
single commit often contains what would be a short series of patches in
Git plus a few separated fix-ups that are completely unrelated to the
whole series. It is trivial to split your changes in a few separate
commits in Git, but it is difficult to do that with CVS/SVN.
> That incidentally is exactly why earlier we (mostly me and Linus)
> recommended people not to teach "commit -m" to new people, but of course
> nobody listened ;-).
Those who got used to '-m' in another VCS will quickly find it on their
own... BTW, Git User's Manual uses "git commit -m" 8 times in different
examples, largely to explain what is committed here, and I think it is
similar with other introductions to Git. Though, clearly '-m' is rarely
useful in practice...
Dmitry
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.15
From: Jonas Fonseca @ 2009-11-20 15:55 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091120135004.GA3919@debian.b2j>
On Fri, Nov 20, 2009 at 08:50, bill lam <cbill.lam@gmail.com> wrote:
> 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 ?
No, not if you want to build the man pages yourself.
How about adding a script or a make rule to optionally install man
pages from the release branch. For example:
install-release-doc-man:
for doc in $(MANDOC); do \
git checkout origin/release $$doc; \
done
$(MAKE) install-doc-man
--
Jonas Fonseca
^ permalink raw reply
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Clemens Buchacher @ 2009-11-20 15:58 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:
> Git is just plain wrong, because you can't split or merge repositories
> or pull subtrees of them.
I think you made an unfortunate choice of words here, because as others have
mentioned, splitting and merging subtrees is implemented already. Maybe you
were talking about checking out or cloning subtrees. To date, none of the
distributed version control systems are capable of doing that. And that is
one of the reasons why we have wrapper scripts like repo (although IIRC repo
does a lot more than just that).
AFAICS, there is no fundamental reason why this should be difficult to
support. Clearly, there are some odd situations to deal with. For example,
how to deal with merge conflicts that happen outside of the subtree that's
currently available? How to detect (modified) moves of files into the
available subtree?
But we could simply fail in these cases. The workarounds currently in use
are not able to do this either.
> 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.
I don't understand what you mean here.
> Will somebody please finish git itself instead of working around it, or
> use a source control system that's up to the job.
There is a desire to do this in the git community, as documented in [1].
However, it appears to be hard enough to do so that people had rather
implement custom solutions such as git-submodules, which are probably just
good enough for them.
Clemens
[1] http://git.or.cz/gitwiki/SoC2009Ideas#NarrowandSparseclonesupport
^ permalink raw reply
* [RFC/PATCH 0/2] Explain newbies the "commit before pull" flow
From: Matthieu Moy @ 2009-11-20 15:59 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
A colleague of mine asked me "why do I need to commit before I can
pull", and I was about to send a link to the user manual, when I
noticed I couldn't find any explanation about that there.
This little patch serie propose a few more sentence in the user
manual, and a little more verbose error message for those who don't
read the docs.
I'm not sure the wording is the best we can do. Native-speakers and
Git gurus are welcome to improve it ;-).
Matthieu Moy (2):
merge-recursive: point the user to commit when file would be
overwritten.
user-manual: Document that "git merge" doesn't like uncommited
changes.
Documentation/user-manual.txt | 14 +++++++++++---
merge-recursive.c | 6 ++++--
2 files changed, 15 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Matthieu Moy @ 2009-11-20 15:59 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>
We explain the user why uncommited changes can be problematic with merge,
and point to "commit" and "stash" for the solution.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/user-manual.txt | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..6b4a037 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1176,14 +1176,22 @@ How to merge
------------
You can rejoin two diverging branches of development using
-linkgit:git-merge[1]:
+linkgit:git-merge[1].
-------------------------------------------------
$ git merge branchname
-------------------------------------------------
merges the development in the branch "branchname" into the current
-branch. If there are conflicts--for example, if the same file is
+branch. Note that Git merges committed changes, but not the working
+tree itself. Therefore, if you have uncommitted changes touching the
+same files as the ones impacted by the merge, Git will refuse to
+proceed. Most of the time, you will want to commit your changes before
+you can merge, and if you don't, then linkgit:git-stash[1] can take
+these changes away while you're doing the merge, and reapply them
+afterwards.
+
+If there are conflicts--for example, if the same file is
modified in two different ways in the remote branch and the local
branch--then you are warned; the output may look something like this:
@@ -1679,7 +1687,7 @@ Sharing development with others
Getting updates with git pull
-----------------------------
-After you clone a repository and make a few changes of your own, you
+After you clone a repository and commit a few changes of your own, you
may wish to check the original repository for updates and merge them
into your own work.
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [PATCH 1/2] merge-recursive: point the user to commit when file would be overwritten.
From: Matthieu Moy @ 2009-11-20 15:59 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy
In-Reply-To: <1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>
The commit-before-pull is well accepted in the DVCS community, but is
confusing some new users. This should get them back in the right way when
the problem occurs.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
merge-recursive.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index f55b7eb..d5e0819 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -172,9 +172,11 @@ static int git_merge_trees(int index_only,
struct unpack_trees_options opts;
static const struct unpack_trees_error_msgs msgs = {
/* would_overwrite */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
+ "Please, commit your changes or stash them before you can merge.",
/* not_uptodate_file */
- "Your local changes to '%s' would be overwritten by merge. Aborting.",
+ "Your local changes to '%s' would be overwritten by merge. Aborting:\n"
+ "Please, commit your changes or stash them before you can merge.",
/* not_uptodate_dir */
"Updating '%s' would lose untracked files in it. Aborting.",
/* would_lose_untracked */
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [PATCH/resend] CVS Server: Support reading base and roots from environment
From: Phil Miller @ 2009-11-20 16:05 UTC (permalink / raw)
To: Git Maintainer; +Cc: Git Mailing List
The Gitosis single-account Git/ssh hosting system runs git commands
through git-shell after confirming that the connecting user is
authorized to access the requested repository. This works well for
upload-pack and receive-pack, which take a repository argument through
git-shell. This doesn't work so well for `cvs server', which is passed
through literally, with no arguments. Allowing arguments risks
sneaking in `--export-all', so that restriction should be maintained.
Despite that, passing a list of repository roots is necessary for
per-user access control by the hosting software, and passing a base
path improves usability without weakening security. Thus,
git-cvsserver needs to come up with these values at runtime by some
other means. Since git-shell preserves the environment for other
purposes, the environment can carry these arguments as well.
Thus, modify git-cvsserver to read $GIT_CVSSERVER_{BASE_PATH,ROOTS} in
the absence of equivalent command line arguments.
Signed-off-by: Phil Miller <mille121@illinois.edu>
---
git-cvsserver.perl | 21 ++++++++++++++++++++-
1 files changed, 20 insertions(+), 1 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 6dc45f5..9e58d2a 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -104,6 +104,7 @@ $log->info("--------------- STARTING -----------------");
my $usage =
"Usage: git cvsserver [options] [pserver|server] [<directory> ...]\n".
" --base-path <path> : Prepend to requested CVSROOT\n".
+ " Can be read from GIT_CVSSERVER_BASE_PATH\n".
" --strict-paths : Don't allow recursing into subdirectories\n".
" --export-all : Don't check for gitcvs.enabled in config\n".
" --version, -V : Print version information and exit\n".
@@ -111,7 +112,8 @@ my $usage =
"\n".
"<directory> ... is a list of allowed directories. If no directories\n".
"are given, all are allowed. This is an additional restriction, gitcvs\n".
- "access still needs to be enabled by the gitcvs.enabled config option.\n";
+ "access still needs to be enabled by the gitcvs.enabled config option.\n".
+ "Alternately, these directories may be specified in
GIT_CVSSERVER_ROOTS.\n";
my @opts = ( 'help|h|H', 'version|V',
'base-path=s', 'strict-paths', 'export-all' );
@@ -148,6 +150,23 @@ if ($state->{'export-all'} &&
!@{$state->{allowed_roots}}) {
die "--export-all can only be used together with an explicit whitelist\n";
}
+# Environment handling for running under git-shell
+if ($ENV{GIT_CVSSERVER_BASE_PATH}) {
+ if ($state->{'base-path'}) {
+ die "Cannot specify base path both ways.\n";
+ }
+ my $base_path = $ENV{GIT_CVSSERVER_BASE_PATH};
+ $state->{'base-path'} = $base_path;
+ $log->debug("Picked up base path '$base_path' from environment.\n");
+}
+if ($ENV{GIT_CVSSERVER_ROOTS}) {
+ if (@{$state->{allowed_roots}}) {
+ die "Cannot specify roots both ways: @ARGV\n";
+ }
+ my @allowed_root = split(',', $ENV{GIT_CVSSERVER_ROOTS});
+ $state->{allowed_roots} = [ @allowed_root ];
+}
+
# if we are called with a pserver argument,
# deal with the authentication cat before entering the
# main loop
--
1.5.6.3
^ permalink raw reply related
* [PATCH] git am/mailinfo: Don't look at in-body headers when rebasing
From: Lukas Sandström @ 2009-11-20 16:12 UTC (permalink / raw)
To: Jeff King; +Cc: Lukas Sandström, Philip Hofstetter, Junio C Hamano, git
In-Reply-To: <20091119153622.GC6877@coredump.intra.peff.net>
When we are rebasing we know that the header lines in the
patch are good and that we don't need to pick up any headers
from the body of the patch.
This makes it possible to rebase commits whose commit message
start with "From" or "Date".
Test vectors by Jeff King.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
---
Jeff King wrote:
> On Thu, Nov 19, 2009 at 09:51:36AM +0100, Lukas Sandström wrote:
> Thanks, it did end up being a pretty small change. Though I think we may
> be better off with _both_ patches. Your patch protects the message
> absolutely during rebasing, and my patch improves the heuristic when
> applying non-rebase patches.
>
I looked a bit at using your extra safety check, but it would be a change
in behavior to only accept valid email adresses, and mailinfo
is riddled with corner cases. If this changed is made someone
will propably complain, saying that they rely on invalid dates in their
commit messages.
I don't know when to apply your stricter check whithout breaking any tests.
>> @@ -771,6 +772,8 @@ static int handle_commit_msg(struct strbuf *line)
>> return 0;
>>
>> if (still_looking) {
>> + if (!use_inbody_headers)
>> + still_looking = 0;
>> strbuf_ltrim(line);
>> if (!line->len)
>> return 0;
>
> Hmm. But we still end up in this conditional for the very first line.
> Which I guess happens to work because the first line we feed is
> presumably the empty blank line (but I didn't check). Still, wouldn't it
> be more clear as:
>
> if (use_inbody_headers && still_looking) {
> ...
>
> in which case still_looking simply becomes irrelevant when the feature
> is disabled?
When rebasing the first line passed to handle_commit_msg will be the blank
line between the headers and commit message. This should be removed. I
rewrote this part to make it a bit more obvious.
>
>> +From nobody Mon Sep 17 00:00:00 2001
>> +From: A U Thor <a.u.thor@example.com>
>> +Subject: check bogus body header (from)
>> +Date: Fri, 9 Jun 2006 00:44:16 -0700
>> +
>> +From: bogosity
>> + - a list
>> + - of stuff
>> +---
>
> Since your feature is meant to prevent us looking at inbody headers no
> matter if they are valid-looking or not, wouldn't a better test be to
> actually have:
>
> From: Other Author <other@example.com>
>
> Otherwise, you don't know if it is your feature blocking it, or my patch
> (if it gets applied on top).
>
I kept the tests as is for now, since they show the problem
originally reported.
/Lukas
builtin-mailinfo.c | 12 +++++++++++-
git-am.sh | 13 ++++++++++---
t/t5100-mailinfo.sh | 6 +++++-
t/t5100/info0015 | 5 +++++
t/t5100/info0015--no-inbody-headers | 5 +++++
t/t5100/info0016 | 5 +++++
t/t5100/info0016--no-inbody-headers | 5 +++++
t/t5100/msg0015 | 2 ++
t/t5100/msg0015--no-inbody-headers | 3 +++
t/t5100/msg0016 | 2 ++
t/t5100/msg0016--no-inbody-headers | 4 ++++
t/t5100/patch0015 | 8 ++++++++
t/t5100/patch0015--no-inbody-headers | 8 ++++++++
t/t5100/patch0016 | 8 ++++++++
t/t5100/patch0016--no-inbody-headers | 8 ++++++++
t/t5100/sample.mbox | 33 +++++++++++++++++++++++++++++++++
16 files changed, 122 insertions(+), 5 deletions(-)
create mode 100644 t/t5100/info0015
create mode 100644 t/t5100/info0015--no-inbody-headers
create mode 100644 t/t5100/info0016
create mode 100644 t/t5100/info0016--no-inbody-headers
create mode 100644 t/t5100/msg0015
create mode 100644 t/t5100/msg0015--no-inbody-headers
create mode 100644 t/t5100/msg0016
create mode 100644 t/t5100/msg0016--no-inbody-headers
create mode 100644 t/t5100/patch0015
create mode 100644 t/t5100/patch0015--no-inbody-headers
create mode 100644 t/t5100/patch0016
create mode 100644 t/t5100/patch0016--no-inbody-headers
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index c90cd31..3c4f075 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -26,6 +26,7 @@ static struct strbuf charset = STRBUF_INIT;
static int patch_lines;
static struct strbuf **p_hdr_data, **s_hdr_data;
static int use_scissors;
+static int use_inbody_headers = 1;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
@@ -774,10 +775,17 @@ static int handle_commit_msg(struct strbuf *line)
strbuf_ltrim(line);
if (!line->len)
return 0;
+ }
+
+ if (use_inbody_headers && still_looking) {
still_looking = check_header(line, s_hdr_data, 0);
if (still_looking)
return 0;
- }
+ } else
+ /* Only trim the first (blank) line of the commit message
+ * when ignoring in-body headers.
+ */
+ still_looking = 0;
/* normalize the log message to UTF-8. */
if (metainfo_charset)
@@ -1033,6 +1041,8 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)
use_scissors = 1;
else if (!strcmp(argv[1], "--no-scissors"))
use_scissors = 0;
+ else if (!strcmp(argv[1], "--no-inbody-headers"))
+ use_inbody_headers = 0;
else
usage(mailinfo_usage);
argc--; argv++;
diff --git a/git-am.sh b/git-am.sh
index c132f50..96869a2 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -289,7 +289,7 @@ split_patches () {
prec=4
dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume= scissors=
+resolvemsg= resume= scissors= no_inbody_headers=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -322,7 +322,7 @@ do
--abort)
abort=t ;;
--rebasing)
- rebasing=t threeway=t keep=t scissors=f ;;
+ rebasing=t threeway=t keep=t scissors=f no_inbody_headers=t ;;
-d|--dotest)
die "-d option is no longer supported. Do not use."
;;
@@ -448,6 +448,7 @@ else
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
echo "$scissors" >"$dotest/scissors"
+ echo "$no_inbody_headers" >"$dotest/no_inbody_headers"
echo "$GIT_QUIET" >"$dotest/quiet"
echo 1 >"$dotest/next"
if test -n "$rebasing"
@@ -495,6 +496,12 @@ t)
f)
scissors=--no-scissors ;;
esac
+if test "$(cat "$dotest/no_inbody_headers")" = t
+then
+ no_inbody_headers=--no-inbody-headers
+else
+ no_inbody_headers=
+fi
if test "$(cat "$dotest/quiet")" = t
then
GIT_QUIET=t
@@ -549,7 +556,7 @@ do
# by the user, or the user can tell us to do so by --resolved flag.
case "$resume" in
'')
- git mailinfo $keep $scissors $utf8 "$dotest/msg" "$dotest/patch" \
+ git mailinfo $keep $no_inbody_headers $scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
stop_here $this
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index 0279d07..ebc36c1 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 14'
+ test `cat last` = 16'
check_mailinfo () {
mail=$1 opt=$2
@@ -30,6 +30,10 @@ do
if test -f "$TEST_DIRECTORY"/t5100/msg$mail--scissors
then
check_mailinfo $mail --scissors
+ fi &&
+ if test -f "$TEST_DIRECTORY"/t5100/msg$mail--no-inbody-headers
+ then
+ check_mailinfo $mail --no-inbody-headers
fi
'
done
diff --git a/t/t5100/info0015 b/t/t5100/info0015
new file mode 100644
index 0000000..0114f10
--- /dev/null
+++ b/t/t5100/info0015
@@ -0,0 +1,5 @@
+Author:
+Email:
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0015--no-inbody-headers b/t/t5100/info0015--no-inbody-headers
new file mode 100644
index 0000000..c4d8d77
--- /dev/null
+++ b/t/t5100/info0015--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/info0016 b/t/t5100/info0016
new file mode 100644
index 0000000..38ccd0d
--- /dev/null
+++ b/t/t5100/info0016
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: bogus
+
diff --git a/t/t5100/info0016--no-inbody-headers b/t/t5100/info0016--no-inbody-headers
new file mode 100644
index 0000000..f4857d4
--- /dev/null
+++ b/t/t5100/info0016--no-inbody-headers
@@ -0,0 +1,5 @@
+Author: A U Thor
+Email: a.u.thor@example.com
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
diff --git a/t/t5100/msg0015 b/t/t5100/msg0015
new file mode 100644
index 0000000..9577238
--- /dev/null
+++ b/t/t5100/msg0015
@@ -0,0 +1,2 @@
+- a list
+ - of stuff
diff --git a/t/t5100/msg0015--no-inbody-headers b/t/t5100/msg0015--no-inbody-headers
new file mode 100644
index 0000000..be5115b
--- /dev/null
+++ b/t/t5100/msg0015--no-inbody-headers
@@ -0,0 +1,3 @@
+From: bogosity
+ - a list
+ - of stuff
diff --git a/t/t5100/msg0016 b/t/t5100/msg0016
new file mode 100644
index 0000000..0d9adad
--- /dev/null
+++ b/t/t5100/msg0016
@@ -0,0 +1,2 @@
+and some content
+
diff --git a/t/t5100/msg0016--no-inbody-headers b/t/t5100/msg0016--no-inbody-headers
new file mode 100644
index 0000000..1063f51
--- /dev/null
+++ b/t/t5100/msg0016--no-inbody-headers
@@ -0,0 +1,4 @@
+Date: bogus
+
+and some content
+
diff --git a/t/t5100/patch0015 b/t/t5100/patch0015
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0015--no-inbody-headers b/t/t5100/patch0015--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0015--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016 b/t/t5100/patch0016
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/patch0016--no-inbody-headers b/t/t5100/patch0016--no-inbody-headers
new file mode 100644
index 0000000..ad64848
--- /dev/null
+++ b/t/t5100/patch0016--no-inbody-headers
@@ -0,0 +1,8 @@
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 13fa4ae..de10312 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -650,3 +650,36 @@ index b0b5d8f..461c47e 100644
convert_to_utf8(line, charset.buf);
--
1.6.4.1
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (from)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+From: bogosity
+ - a list
+ - of stuff
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
+From nobody Mon Sep 17 00:00:00 2001
+From: A U Thor <a.u.thor@example.com>
+Subject: check bogus body header (date)
+Date: Fri, 9 Jun 2006 00:44:16 -0700
+
+Date: bogus
+
+and some content
+
+---
+diff --git a/foo b/foo
+index e69de29..d95f3ad 100644
+--- a/foo
++++ b/foo
+@@ -0,0 +1 @@
++content
+
--
1.6.4.4
^ permalink raw reply related
* Re: [ANNOUNCE] tig-0.15
From: bill lam @ 2009-11-20 16:25 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30911200755l16b306cey16efb42fe9ba27da@mail.gmail.com>
On Fri, 20 Nov 2009, Jonas Fonseca wrote:
> install-release-doc-man:
> for doc in $(MANDOC); do \
> git checkout origin/release $$doc; \
> done
> $(MAKE) install-doc-man
Thanks it works. Could you also commit this to git?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: [PATCH] bash completion: add space between branch name and status flags
From: Junio C Hamano @ 2009-11-20 17:53 UTC (permalink / raw)
To: Roman Fietze; +Cc: Shawn O. Pearce, git
In-Reply-To: <200911201309.16193.roman.fietze@telemotive.de>
Roman Fietze <roman.fietze@telemotive.de> writes:
> 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)?
Perhaps.
> 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"
I think this line and the two changes to printf below is a big improvement
(unless we are using f for something else---I didn't look). But I think
the next line is wrong.
> + f=${f:+ $f}
The $r string is designed to be used as suffix from the beginning and
always has "|" in front of it as a delimiter, so if there is no w/i/s/u
(and I suspect many people do not use GIT_PS1_SHOWDIRTYSTATE and friends,
and these are _always_ empty for them) the above will begin with "|".
There is no need to steal one column from a typeable width from the
command line in such a case.
> 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
> }
To implement your stated goal (dirty/stash/untracked), you probably want
to do this instead...
local f="$w$i$s$u"
f="${f:+ $f}$r"
^ permalink raw reply
* Re: [PATCH 0/3] "log --stdin" updates
From: Junio C Hamano @ 2009-11-20 17:59 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20091120144030.GB5419@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Nov 20, 2009 at 03:25:12AM -0800, Junio C Hamano wrote:
>
>> 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).
>
> This looks like a good API feature, though I am curious about the
> missing "4/3" that was the motivation (of course, with a feature
> like this, it may be for your out-of-git script, but as I said, I am
> curious :) ). Is it a response to
>
> http://article.gmane.org/gmane.comp.version-control.git/133268
>
> ?
No. This series is a follow-up to $gmane/131971; I was suspicious that I
missed something for the API feature to be complete back then (and the
patch was not signed-off partly for that reason), and I found one thing
that was lacking.
^ 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