* Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.
From: Peter Krefting @ 2009-11-16 8:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nanako Shiraishi, Thomas Rast, Nicolas Sebrecht, Baz,
Git Mailing List, Johannes.Schindelin, B.Steinbrink
In-Reply-To: <7vk4xsqhkv.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Even though I still think -Xours/-Xtheirs are nonsense options in the
> context of source code management, I suspect that they might be exactly
> what Peter needs in this situation.
Yes, it sounds like it would. That is not something I would use for source
code management, but it would fit this, and some other use-cases I have,
quite nicely.
I tend to use Git not only for source code management, but also for document
synchronisation across machines which may, or may not, be connected to a
network at any given time. Git is very nice for that sort of work.
> ; otherwise Peter's web site is seriously broken from the security point
> of view and no SCM can fix that),
Indeed. If it that was the case, I deserve whatever problems I get :-)
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH v2] Speed up bash completion loading
From: Stephen Boyd @ 2009-11-16 8:28 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Junio C Hamano, Kirill Smelkov, Sverre Rabbelier, Shawn O. Pearce,
git
In-Reply-To: <20091115102912.GA4100@progeny.tock>
Jonathan Nieder wrote:
>
> Junio C Hamano wrote:
>> Jonathan Nieder <jrnieder@gmail.com> writes:
>>
>>> __git_compute_merge_strategies ()
>>> {
>>> - : ${__git_merge_strategies=$(__git_list_merge_strategies)}
>>> + __git_merge_strategies=$(__git_list_merge_strategies)
>> Wouldn't
>>
>> : ${__gms:=$(command)}
>>
>> run command only until it gives a non-empty string?
>
> Yes. :)
Why not do this for all of the lists and not just the merge strategies?
^ permalink raw reply
* Re: how to make gitk to use specified history information
From: Liu Yubao @ 2009-11-16 8:38 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20091116T090441-576@post.gmane.org>
Eric Raible wrote:
> Liu Yubao <yubao.liu <at> gmail.com> writes:
>
>> I want to obtain an outline of history information, for example:
>>
>> a - b - c - d - h -i -j
>> \ /
>> e- f - g
>>
>> I simplify the graph like this:
>>
>> a - c - d - j
>> \ /
>> g
>
> "gitk --simplify-by-decoration"?
>
> - Eric
>
Thanks, but that gets "a - g - j" which isn't what I want.
(g and j are heads of two branches).
The command sequence to produce that full revision graph:
#!/bin/bash
d=/tmp/t$$
rm -rf $d && mkdir $d && cd $d || exit 1
doit () {
for s in $@; do
echo $s >> a.txt
git add a.txt
git commit -q -m $s
done
}
git init
doit a b c
git checkout -b t HEAD~2
doit e f g
git checkout master
git merge t
doit d h i j
gitk &
^ permalink raw reply
* [PATCH] Document git-svn's first-parent rule
From: Thomas Rast @ 2009-11-16 10:15 UTC (permalink / raw)
To: git; +Cc: Eric Wong
git-svn has the following rule to detect the SVN base for its
operations: find the first git-svn-id line reachable through
first-parent ancestry. IOW,
git log --grep=^git-svn-id: --first-parent -1
Document this, as it is very important when using merges with git-svn.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
Documentation/git-svn.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index 1812890..6da4151 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -735,6 +735,16 @@ merges you've made. Furthermore, if you merge or pull from a git branch
that is a mirror of an SVN branch, 'dcommit' may commit to the wrong
branch.
+If you do merge, note the following rule: 'git svn dcommit' will
+attempt to commit on top of the SVN commit named in
+------------------------------------------------------------------------
+git log --grep=^git-svn-id: --first-parent -1
+------------------------------------------------------------------------
+You 'must' therefore ensure that the most recent commit of the branch
+you want to dcommit to is the 'first' parent of the merge. Chaos will
+ensue otherwise, especially if the first parent is an older commit on
+the same SVN branch.
+
'git clone' does not clone branches under the refs/remotes/ hierarchy or
any 'git svn' metadata, or config. So repositories created and managed with
using 'git svn' should use 'rsync' for cloning, if cloning is to be done
--
1.6.5.2.427.ge73cb
^ permalink raw reply related
* [PATCH] Expand ~ and ~user in core.excludesfile, commit.template
From: Matthieu Moy @ 2009-11-16 10:07 UTC (permalink / raw)
To: git; +Cc: Matthieu Moy, Karl Chen
These config variables are parsed to substitute ~ and ~user with getpw
entries.
user_path() refactored into new function expand_user_path(), to allow
dynamically allocating the return buffer.
Original patch by Karl Chen, modified by Matthieu Moy.
Signed-off-by: Karl Chen <quarl@quarl.org>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
The original thread was here:
http://thread.gmane.org/gmane.comp.version-control.git/93250/focus=94276
My version is made a bit simpler by using strbuf for string
manipulation in expand_user_path.
I'm not sure I fully adressed Junio's point here:
http://thread.gmane.org/gmane.comp.version-control.git/93250/focus=94276
> I do not see any strong reason why the single caller of user_path() has to
> keep using the static allocation. Would it help to reduce the complexity
> of your expand_user_path() implementation, if we fixed the caller along
> the lines of this patch (untested, but just to illustrate the point)?
>
> [...]
> --- i/path.c
> +++ w/path.c
> @@ -221,19 +221,22 @@ char *enter_repo(char *path, int strict)
> if (PATH_MAX <= len)
> return NULL;
> if (path[0] == '~') {
> - if (!user_path(used_path, path, PATH_MAX))
> + char *newpath = expand_user_path(path);
> [...]
I'm just copying back into the static buffer to let enter_repo() do
the same string manipulation as it used to do (concatenate with .git
suffixes). I think the whole enter_repo could use strbuf instead of
static buffers, but that's a different point (probably made easier by
my patch).
Documentation/config.txt | 4 ++-
builtin-commit.c | 2 +-
cache.h | 2 +
config.c | 11 +++++-
path.c | 84 +++++++++++++++++++++++++++------------------
5 files changed, 66 insertions(+), 37 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..c37b51d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -380,7 +380,8 @@ Common unit suffixes of 'k', 'm', or 'g' are supported.
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
- of files which are not meant to be tracked. See
+ of files which are not meant to be tracked. "~" and "~user"
+ are expanded to the user's home directory. See
linkgit:gitignore[5].
core.editor::
@@ -670,6 +671,7 @@ color.ui::
commit.template::
Specify a file to use as the template for new commit messages.
+ "~" and "~user" are expanded to the user's home directory.
diff.autorefreshindex::
When using 'git-diff' to compare with work tree
diff --git a/builtin-commit.c b/builtin-commit.c
index d525b89..09d2840 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -999,7 +999,7 @@ static int git_commit_config(const char *k, const char *v, void *cb)
struct wt_status *s = cb;
if (!strcmp(k, "commit.template"))
- return git_config_string(&template_file, k, v);
+ return git_config_pathname(&template_file, k, v);
return git_status_config(k, v, s);
}
diff --git a/cache.h b/cache.h
index 71a731d..42f7cd8 100644
--- a/cache.h
+++ b/cache.h
@@ -645,6 +645,7 @@ int set_shared_perm(const char *path, int mode);
#define adjust_shared_perm(path) set_shared_perm((path), 0)
int safe_create_leading_directories(char *path);
int safe_create_leading_directories_const(const char *path);
+extern char *expand_user_path(const char *path);
char *enter_repo(char *path, int strict);
static inline int is_absolute_path(const char *path)
{
@@ -903,6 +904,7 @@ extern unsigned long git_config_ulong(const char *, const char *);
extern int git_config_bool_or_int(const char *, const char *, int *);
extern int git_config_bool(const char *, const char *);
extern int git_config_string(const char **, const char *, const char *);
+extern int git_config_pathname(const char **, const char *, const char *);
extern int git_config_set(const char *, const char *);
extern int git_config_set_multivar(const char *, const char *, const char *, int);
extern int git_config_rename_section(const char *, const char *);
diff --git a/config.c b/config.c
index c644061..0fcc4ce 100644
--- a/config.c
+++ b/config.c
@@ -351,6 +351,15 @@ int git_config_string(const char **dest, const char *var, const char *value)
return 0;
}
+int git_config_pathname(const char **dest, const char *var, const char *value) {
+ if (!value)
+ return config_error_nonbool(var);
+ *dest = expand_user_path(value);
+ if (!*dest)
+ die("Failed to expand user dir in: '%s'", value);
+ return 0;
+}
+
static int git_default_core_config(const char *var, const char *value)
{
/* This needs a better name */
@@ -474,7 +483,7 @@ static int git_default_core_config(const char *var, const char *value)
return git_config_string(&editor_program, var, value);
if (!strcmp(var, "core.excludesfile"))
- return git_config_string(&excludes_file, var, value);
+ return git_config_pathname(&excludes_file, var, value);
if (!strcmp(var, "core.whitespace")) {
if (!value)
diff --git a/path.c b/path.c
index 047fdb0..009c8e0 100644
--- a/path.c
+++ b/path.c
@@ -11,6 +11,7 @@
* which is what it's designed for.
*/
#include "cache.h"
+#include "strbuf.h"
static char bad_path[] = "/bad-path/";
@@ -207,43 +208,49 @@ int validate_headref(const char *path)
return -1;
}
-static char *user_path(char *buf, char *path, int sz)
+static inline struct passwd *getpw_str(const char *username, size_t len)
{
+ if (len == 0)
+ return getpwuid(getuid());
+
struct passwd *pw;
- char *slash;
- int len, baselen;
+ char *username_z = xmalloc(len + 1);
+ memcpy(username_z, username, len);
+ username_z[len] = '\0';
+ pw = getpwnam(username_z);
+ free(username_z);
+ return pw;
+}
- if (!path || path[0] != '~')
- return NULL;
- path++;
- slash = strchr(path, '/');
- if (path[0] == '/' || !path[0]) {
- pw = getpwuid(getuid());
- }
- else {
- if (slash) {
- *slash = 0;
- pw = getpwnam(path);
- *slash = '/';
- }
- else
- pw = getpwnam(path);
- }
- if (!pw || !pw->pw_dir || sz <= strlen(pw->pw_dir))
- return NULL;
- baselen = strlen(pw->pw_dir);
- memcpy(buf, pw->pw_dir, baselen);
- while ((1 < baselen) && (buf[baselen-1] == '/')) {
- buf[baselen-1] = 0;
- baselen--;
- }
- if (slash && slash[1]) {
- len = strlen(slash);
- if (sz <= baselen + len)
- return NULL;
- memcpy(buf + baselen, slash, len + 1);
+/*
+ * Return a string with ~ and ~user expanded via getpw*. If buf != NULL, then
+ * it is a newly allocated string. Returns NULL on getpw failure or if
+ * path is NULL.
+ */
+char *expand_user_path(const char *path)
+{
+ struct strbuf user_path = STRBUF_INIT;
+ char * first_slash = strchrnul(path, '/');
+ char * to_copy;
+ if (path == NULL)
+ goto return_null;
+
+ if (path[0] == '~') {
+ const char *username = path + 1;
+ size_t username_len = first_slash - username;
+ struct passwd *pw = getpw_str(username, username_len);
+ if (!pw)
+ goto return_null;
+ strbuf_add(&user_path, pw->pw_dir, strlen(pw->pw_dir));
+ to_copy = first_slash;
+ } else if (path[0] != '/') {
+ to_copy = path;
}
- return buf;
+ strbuf_add(&user_path, to_copy, strlen(to_copy));
+ return strbuf_detach(&user_path, NULL);
+return_null:
+ strbuf_release(&user_path);
+ return NULL;
}
/*
@@ -291,8 +298,17 @@ char *enter_repo(char *path, int strict)
if (PATH_MAX <= len)
return NULL;
if (path[0] == '~') {
- if (!user_path(used_path, path, PATH_MAX))
+ char *newpath = expand_user_path(path);
+ if (!newpath || (PATH_MAX - 10 < strlen(newpath))) {
+ if (path != newpath)
+ free(newpath);
return NULL;
+ }
+ /* Copy back into the static buffer. A pity
+ since newpath was not bounded, but other
+ branches of the if are limited by PATH_MAX
+ anyway. */
+ strcpy(used_path, newpath); free(newpath);
strcpy(validated_path, path);
path = used_path;
}
--
1.6.5.2.152.gbbe9e
^ permalink raw reply related
* Re: git am and CRLF files
From: Nanako Shiraishi @ 2009-11-16 10:50 UTC (permalink / raw)
To: Stefan Naewe; +Cc: git@vger.kernel.org
In-Reply-To: <4B01004A.8060600@atlas-elektronik.com>
Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com>
>> A repository with some UNIX (LF) and some Windows (CRLF) files.
>> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>>
>> My problem:
>>
>> 'git am' can't handle changes in CRLF files because the patch
>> gets converted (by git mailsplit) to contain only LF.
>
>> Stefan
>
> Does anyone have any comment on this ?
This was done very much on purpose.
The "am" command is meant to handle e-mailed patches, and traditionally
mails are known to clobber carriage returns.
See commit c2ca1d79dbd54b06a05e5d14a897699e59dc9f9f
Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
It is not that uncommon to have mails with DOS line-ending, notably
Thunderbird and web mailers like Gmail (when saving what they call
"original" message). So modify mailsplit to convert CRLF line-endings to
just LF.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Nanako Shiraishi @ 2009-11-16 10:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brian Collins, Jeff King
In-Reply-To: <B7C4E16C-B15D-4A7B-873A-B6BD0FDAD8C8@gmail.com>
Quoting Brian Collins <bricollins@gmail.com>
> You will have to excuse me, this is my first patch and I don't know if
> this is the right place to post this. Apologies in advance if I'm in
> the wrong place.
>
> git-grep currently throws an error when you combine the -F and -i
> flags. This isn't in line with how GNU grep handles it. This patch
> allows the simultaneous use of those flags.
Junio, may I ask what happened to this patch?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Doc: mention the crlf attribute in config autocrlf section
From: Nanako Shiraishi @ 2009-11-16 10:50 UTC (permalink / raw)
To: Matthew Ogilvie; +Cc: git, gitster
In-Reply-To: <1258223700-4009-1-git-send-email-mmogilvi_git@miniinfo.net>
Quoting Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> The reverse reference has long existed, and the autocrlf description
> was actually obsolete and wrong (saying only file content is used),
> not just incomplete.
What do you mean by "reverse reference"?
> Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
> ---
> Documentation/config.txt | 7 ++++---
> 1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index d1e2120..0dc6b12 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -169,9 +169,10 @@ core.autocrlf::
> writing to the filesystem. The variable can be set to
> 'input', in which case the conversion happens only while
> reading from the filesystem but files are written out with
> - `LF` at the end of lines. Currently, which paths to consider
> - "text" (i.e. be subjected to the autocrlf mechanism) is
> - decided purely based on the contents.
> + `LF` at the end of lines. A file is considered
> + "text" (i.e. be subjected to the autocrlf mechanism) based on
> + the file's `crlf` attribute, or if `crlf` is unspecified,
> + based on the file's contents. See linkgit:gitattributes[5].
>
> core.safecrlf::
> If true, makes git check if converting `CRLF` as controlled by
The updated text looks correct to me.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* dirty code to get an outline of commit history with gitk [Was: how to make gitk to use specified history information]
From: Liu Yubao @ 2009-11-16 10:58 UTC (permalink / raw)
To: Eric Raible; +Cc: git, Junio C Hamano
In-Reply-To: <loom.20091116T090441-576@post.gmane.org>
Eric Raible wrote:
> Liu Yubao <yubao.liu <at> gmail.com> writes:
>
>> I want to obtain an outline of history information, for example:
>>
>> a - b - c - d - h -i -j
>> \ /
>> e- f - g
>>
>> I simplify the graph like this:
>>
>> a - c - d - j
>> \ /
>> g
>
> "gitk --simplify-by-decoration"?
>
> - Eric
>
Hi, I get a very dirty implementation, see
http://jff.googlecode.com/svn/trunk/utils/git-branch-graph/
http://jff.googlecode.com/files/gitk-branch-graph--all.png
http://jff.googlecode.com/files/gitk--all.png
These are just to show my expectation, the code is very very very dirty,
I hope git and gitk will add this feature in an elegant and efficent way.
^ permalink raw reply
* Re: Idea for git-touch
From: Luís Sousa @ 2009-11-16 10:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4AFD26ED.4020602@op5.se>
Andreas Ericsson wrote:
> On 11/12/2009 06:13 PM, Luís Sousa wrote:
>> Yeah, but still need some copy&paste of message :)
>>
>> Jan Krüger wrote:
>>> On Thu, 12 Nov 2009 17:05:21 +0000, Luís Sousa <llsousa@ualg.pt> wrote:
>>>> But still preserves the original date, isn't it?
>>>
>>> Yes, and I just remembered that, too. Sorry. Today is not my day.
>>>
>>> Even so, you can still save one command:
>>>
>>> git reset --soft HEAD^
>>> git commit
>>>
>
Thanks, but still preserves timestamp.
> Make that
>
> git reset --soft HEAD^ && git commit -C ORIG_HEAD
>
> and you won't have to bother with copy-pasting.
>
^ permalink raw reply
* Re: git am and CRLF files
From: Stefan Naewe @ 2009-11-16 11:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git@vger.kernel.org
In-Reply-To: <20091116195036.6117@nanako3.lavabit.com>
On 11/16/2009 11:50 AM, Nanako Shiraishi wrote:
> Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com>
>
>>> A repository with some UNIX (LF) and some Windows (CRLF) files.
>>> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>>>
>>> My problem:
>>>
>>> 'git am' can't handle changes in CRLF files because the patch
>>> gets converted (by git mailsplit) to contain only LF.
>>> Stefan
>> Does anyone have any comment on this ?
>
> This was done very much on purpose.
>
> The "am" command is meant to handle e-mailed patches, and traditionally
> mails are known to clobber carriage returns.
>
> See commit c2ca1d79dbd54b06a05e5d14a897699e59dc9f9f
>
> Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
>
> It is not that uncommon to have mails with DOS line-ending, notably
> Thunderbird and web mailers like Gmail (when saving what they call
> "original" message). So modify mailsplit to convert CRLF line-endings to
> just LF.
>
I've noticed that.
But converting everything just breaks git am for CRLF files, doesn't it ?
Wouldn't it be possible (and sensible) to not convert the diff text, but
only the rest (mail text, headers, etc.) ?
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Change is inevitable, except from a vending machine.
^ permalink raw reply
* Re: git am and CRLF files
From: Erik Faye-Lund @ 2009-11-16 11:43 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Stefan Naewe, git@vger.kernel.org
In-Reply-To: <20091116195036.6117@nanako3.lavabit.com>
On Mon, Nov 16, 2009 at 11:50 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com>
>
>>> A repository with some UNIX (LF) and some Windows (CRLF) files.
>>> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>>>
>>> My problem:
>>>
>>> 'git am' can't handle changes in CRLF files because the patch
>>> gets converted (by git mailsplit) to contain only LF.
>>
>>> Stefan
>>
>> Does anyone have any comment on this ?
>
> This was done very much on purpose.
>
> The "am" command is meant to handle e-mailed patches, and traditionally
> mails are known to clobber carriage returns.
>
According to RFC 5322, email messages use CRLF as the
newline-sequence. In order to be able to distinguish between CRLF and
LF in an e-mail patch, the message needs to be use some
transfer-encoding that preserves newline style (like base64).
Perhaps this would be better fixed by having format-patch (or prehaps
the MUA ?) base64-encode the message body if the file contains
non-LF-newlines, and normalizing CRLF to LF before transport-decoding?
Or does some MUAs transport-decode before storing the message to disk?
I realize this might make it a bit tricky to review patches that
contains CRLF-newlines before mailing them out, but perhaps inspecting
the format-patch output is the wrong place to do this?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-16 12:00 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Junio C Hamano, git
In-Reply-To: <4B006549.8050803@gmail.com>
On Sun, Nov 15, 2009 at 9:32 PM, Johan 't Hart <johanthart@gmail.com> wrote:
> Junio C Hamano schreef:
>>
>> Johan 't Hart <johanthart@gmail.com> writes:
>>>>
>>>> I've been somehow confused by the git-pull man page, which says:
>>>>
>>>> A parameter <ref> without a colon is equivalent to <ref>: when
>>>> pulling/fetching, so it merges <ref> into the current branch without
>>>> storing the remote branch anywhere locally
>>>>
>
>> Thanks for clearing it up.
>>
>> I was puzzled by the above pointing-finger because I wanted to see where a
>> misinformation originated from to fix it at the source. But still don't
>> see anything wrong with it.
>>
>
> My guess is that he was confused by '<ref>:' not meaning '<ref>:<ref>'. But
> I can't speak for him ofcource :)
>
Well, I don't remember how I started to think that:
<src>:
was equivalent to
<src>:<current-branch>
so, assuming I'm on branch 'foo':
$ git pull --rebase origin master:
was equivalent to
$ git pull --rebase origin master:foo
hence my confusion, which certainly due to my lack of attention
(sorry) when reading the man page.
> Refspecs confused me too at the beginning... But knowing more and more about
> git, it seems that this part of the docs look OK to me.. At most an example
> might make things a little more clear, but I doubt it is necessary.
Perhaps, the definition of a refspec with an empty string for <dst>
might be clearer if defined on its own. For example, doing this in the
git-pull man page:
<refspec>
The format of a <refspec> parameter is an ....
The remote ref that matches <src> is fetched,
if <dst> is not empty string, the local ref that
matches it is fast
forwarded using <src>. If the optional plus + is
used, the local ref is
updated even if it does not result in a fast forward update.
if <dst> is an empty string the fetched <src> is
merged into the
current branch without updating any local refs. In
this case the
optional + has no meaning.
Note
....
Some short-cut notations are also supported.
. A parameter <src> (<ref> without the ':<dst>' part)
is equivalent
to '<src>:' (a ref with an empty string for <dst>).
--
Francis
^ permalink raw reply
* Git graph with branch labels for all paths in text environment
From: rhlee @ 2009-11-16 12:03 UTC (permalink / raw)
To: git
Hi git forum,
Is there anyway to to view a text based git grah that shows all paths with
the branch labels? Like a on gitk but ncurses based?
I can get all paths in git log --graph, but I can't get the branch labels.
I can get all branch labels in tig, but only for the current branch.
Is there any feature that has the best of both worlds in a text-based
environment? I ask to text-based as I only have shell access to the server,
an X Windows environment.
Regards,
Richard
--
View this message in context: http://n2.nabble.com/Git-graph-with-branch-labels-for-all-paths-in-text-environment-tp4011651p4011651.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-16 12:17 UTC (permalink / raw)
To: Johan 't Hart; +Cc: git
In-Reply-To: <4AFF3D4D.7000308@gmail.com>
On Sun, Nov 15, 2009 at 12:29 AM, Johan 't Hart <johanthart@gmail.com> wrote:
> This does not update any remote tracking branches, but it will rebase your
> foo branch on the remote master branch (which is what you want)
> It could also be done with:
>
> git pull --rebase origin master:origin/master
>
> This will also update your remote tracking branch refs/remotes/origin/master
> to match the master branch on the remote repo. Your foo branch will then be
> rebased onto it.
BTW, this seems to be not exact.
$ git pull --rebase origin master:origin/master
fetches the 'master' branch on the remote repo, then creates a new
branch 'origin/master', which is updated with the fetched branch.
To update the remote tracking branch refs/remotes/origin/master, I
need to issue:
$ git pull --rebase origin master:remotes/origin/master
BTW2, it looks like if the <dst> local ref doesn't exist the it will
be created. This something that appears very lately in the man page
(actually I can see the information only in the last example). This
could be part of the <refspec> defintion.
Thanks
--
Francis
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: Santi Béjar @ 2009-11-16 12:23 UTC (permalink / raw)
To: rhlee; +Cc: git
In-Reply-To: <1258373038892-4011651.post@n2.nabble.com>
On Mon, Nov 16, 2009 at 1:03 PM, rhlee <richard@webdezign.co.uk> wrote:
>
> Hi git forum,
>
> Is there anyway to to view a text based git grah that shows all paths with
> the branch labels? Like a on gitk but ncurses based?
For third-party tools you can check:
http://git-scm.com/tools
>
> I can get all paths in git log --graph, but I can't get the branch labels.
Have you tried --decorate?
I have an alias for this:
alias.logk = log --graph --pretty=oneline --abbrev-commit --decorate
HTH,
Santi
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Johannes Schindelin @ 2009-11-16 12:35 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Björn Steinbrink
In-Reply-To: <efd7770d166a97481e8e31e407b9c2da02a341e5.1258309432.git.trast@student.ethz.ch>
Hi,
On Sun, 15 Nov 2009, Thomas Rast wrote:
> Using the "ours" strategy with rebase just discards all changes, turning
> <branch> into <upstream> (or <newbase> if given). This is unlikely to
> be what the user wants, so simply refuse to do it.
"Unlikely" or "impossible"?
Besides, I find it rather arbitrary that the "ours" strategy is refused,
but none of the user-provided merge strategies. IOW disallowing "ours"
may very well foster unreasonable expectations.
Ciao,
Dscho
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: Bill Lear @ 2009-11-16 13:30 UTC (permalink / raw)
To: Santi Béjar; +Cc: rhlee, git
In-Reply-To: <adf1fd3d0911160423q4e21126dm37be7838f0ce8379@mail.gmail.com>
On Monday, November 16, 2009 at 13:23:10 (+0100) Santi Béjar writes:
>On Mon, Nov 16, 2009 at 1:03 PM, rhlee <richard@webdezign.co.uk> wrote:
>> Is there anyway to to view a text based git grah that shows all paths with
>> the branch labels? Like a on gitk but ncurses based?
>
>For third-party tools you can check:
>
>http://git-scm.com/tools
Anything that can print this?:
H---I---J topicB
/
E---F---G topicA
/
A---B---C---D master
I've always liked the text-based format that keeps things in-line, as
above. Very readable. I thought someone on this list posted
something about a tool that could produce such graphs from
reasonably-sized git repos. Anyone have such a thing?
Bill
^ permalink raw reply
* Re: pushing remote branches
From: Lorenzo Bettini @ 2009-11-16 15:27 UTC (permalink / raw)
To: git
In-Reply-To: <2e24e5b90911150304i1472ed13k6c60611ef2e9ba19@mail.gmail.com>
Sitaram Chamarty wrote:
>
>> Thus, if I had
>>
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = git@...
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "experiments"]
>> remote = origin
>> merge = refs/heads/experiments
>>
>> instead of
>>
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = git://...
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "experiments"]
>> remote = origin
>> merge = refs/heads/experiments
>>
>> I would have been able to push also to branch experiments? Without having
>> to add
>>
>> [remote "experiments"]
>> url = git@...
>> fetch = +refs/heads/experiments:refs/remotes/experiments/experiments
>>
>> ?
>
> (by the way: do you mean refs/remotes/origin/experiments in that last
> line above?)
>
no, it's just like I wrote it...
you mean in
[remote "experiments"]
url = git@gitorious.org...
fetch =
+refs/heads/experiments:refs/remotes/experiments/experiments
or in
[branch "experiments"]
remote = origin
merge = refs/heads/experiments
?
> Anyway to answer your question, I do not see the refspec line as the issue
> here, but the URL for the repo, which determines how you access it.
so this would have been enough:
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = git://...
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "experiments"]
>> remote = origin
>> merge = refs/heads/experiments
?
thanks
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: Michael J Gruber @ 2009-11-16 15:27 UTC (permalink / raw)
To: Bill Lear; +Cc: Santi Béjar, rhlee, git
In-Reply-To: <19201.21478.127959.431877@lisa.zopyra.com>
Bill Lear venit, vidit, dixit 16.11.2009 14:30:
> On Monday, November 16, 2009 at 13:23:10 (+0100) Santi Béjar writes:
>> On Mon, Nov 16, 2009 at 1:03 PM, rhlee <richard@webdezign.co.uk> wrote:
>>> Is there anyway to to view a text based git grah that shows all paths with
>>> the branch labels? Like a on gitk but ncurses based?
>>
>> For third-party tools you can check:
>>
>> http://git-scm.com/tools
>
> Anything that can print this?:
>
> H---I---J topicB
> /
> E---F---G topicA
> /
> A---B---C---D master
>
> I've always liked the text-based format that keeps things in-line, as
> above. Very readable. I thought someone on this list posted
> something about a tool that could produce such graphs from
> reasonably-sized git repos. Anyone have such a thing?
You really mean horizontally? I know those wide screen monitors are
becoming ubiquitious, but still...
Or are you more after the "in-line" part in the sense that "each branch
is on its line"? This is a bit difficult to define, though (the graph
above is linear, e.g.).
Michael
^ permalink raw reply
* [PATCH 0/2] diffcore-break optimizations
From: Jeff King @ 2009-11-16 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On one of my more ridiculously gigantic repositories, I recently tried
to make a commit that ran git out of memory while trying to commit. The
repository has about 3 gigabytes of data, and I made a small-ish change
to every file. Pathological, yes, but I think we can do better than
chugging for 5 minutes and dying.
The culprit turned out to be memory usage in diffcore-break, which is on
by default for "git status" (and for the "git commit" template message).
It wants to have every changed blob in memory at once, which is just
silly.
The patches are:
[1/2]: diffcore-break: free filespec data as we go
This addresses the memory consumption issue. If you have enough
memory, it doesn't actually yield a speed improvement, but nor does it
show any slowdown for practical workloads.
There is a theoretical slowdown when doing -B -M, because the rename
phase has to re-fetch the blobs from the object store. However, I
wasn't able to measure any slowdown for real-world cases (like "git
log --summary -M -B >/dev/null" on git.git).
I did manage to produce the slowdown on a pathological case: ten
20-megabyte files, each copied with a slight modification to another
file, and then replaced with totally different contents (so each one
will be broken and then trigger an inexact rename). That diff went
from 16s to 17s.
But I improved that and more with the next optimization.
[2/2]: diffcore-break: save cnt_data for other phases
We already do this in rename detection, and since they use the same
data format, there is little reason not to do so. My pathological case
above went from 17s down to 12s. I wasn't able to detect any speedup
or slowdown for sane cases.
So I doubt anybody will even notice this, but I think since we can
address pathological cases, we might as well (and as you will see, the
code change is quite small).
All of that being said, I was able to do my commit, but I still had to
wait five minutes for it to chug through 3G of data. :) I am tempted to
add a "quick" mode to git-commit, but perhaps such a ridiculous case is
rare enough not to worry about. I worked around it by writing my commit
message separately and using "git commit -F".
-Peff
^ permalink raw reply
* [PATCH 1/2] diffcore-break: free filespec data as we go
From: Jeff King @ 2009-11-16 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091116155331.GA30719@coredump.intra.peff.net>
As we look at each changed file and consider breaking it, we
load the blob data and make a decision about whether to
break, which is independent of any other blobs that might
have changed. However, we keep the data in memory while we
consider breaking all of the other files. Which means that
both versions of every file you are diffing are in memory at
the same time.
This patch instead frees the blob data as we finish with
each file pair, leading to much lower memory usage.
Signed-off-by: Jeff King <peff@peff.net>
---
As I noted in the cover letter, this can actually slow things down
slightly for some pathological cases, but I think the reduced memory
consumption is worth it. I couldn't come up with a real-world case where
it made any difference to the speed.
One other thing where _thought_ I might cause a slowdown was in fetching
the blobs for doing patch generation. But it turns out we drop the blobs
already after the diffcore merge, so they weren't living that long
anyway.
diffcore-break.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index d7097bb..15562e4 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -204,12 +204,16 @@ void diffcore_break(int break_score)
dp->score = score;
dp->broken_pair = 1;
+ diff_free_filespec_data(p->one);
+ diff_free_filespec_data(p->two);
free(p); /* not diff_free_filepair(), we are
* reusing one and two here.
*/
continue;
}
}
+ diff_free_filespec_data(p->one);
+ diff_free_filespec_data(p->two);
diff_q(&outq, p);
}
free(q->queue);
--
1.6.5.2.187.g29317
^ permalink raw reply related
* [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Jeff King @ 2009-11-16 16:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091116155331.GA30719@coredump.intra.peff.net>
The "break" phase works by counting changes between two
blobs with the same path. We do this by splitting the file
into chunks (or lines for text oriented files) and then
keeping a count of chunk hashes.
The "rename" phase counts changes between blobs at two
different paths. However, it uses the exact same set of
chunk hashes (which are immutable for a given sha1).
The rename phase can therefore use the same hash data as
break. Unfortunately, we were throwing this data away after
computing it in the break phase. This patch instead attaches
it to the filespec and lets it live through the rename
phase, working under the assumption that most of the time
that breaks are being computed, renames will be too.
We only do this optimization for files which have actually
been broken, as those ones will be candidates for rename
detection (and it is a time-space tradeoff, so we don't want
to waste space keeping useless data).
Signed-off-by: Jeff King <peff@peff.net>
---
Note the two assumptions above:
1. If we are running break, we will probably run rename detection.
2. We are not looking for inexact copies, which could re-use data even
for non-broken pairs.
We could test both of those assumptions by peeking at the other
diff_options that have been set up, but that would involve some code
restructuring. I'm also not sure it is worth it.
For (1), if we don't do rename detection, the next thing we will do is
the diffcore merge, which will then free the data anyway. So we are
really just carrying around the extra cnt_data through the break, and it
is much smaller than the actual blob data.
For (2), keep in mind that this is just a heuristic. We may not have any
good rename candidates anyway, or we may find an exact rename. So it is
just a guess as to which data might be useful. Keeping all the data for
all pairs, broken or not, may be pushing us too far along the time-space
tradeoff.
diffcore-break.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index 15562e4..3a7b60a 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -69,7 +69,7 @@ static int should_break(struct diff_filespec *src,
return 0; /* we do not break too small filepair */
if (diffcore_count_changes(src, dst,
- NULL, NULL,
+ &src->cnt_data, &dst->cnt_data,
0,
&src_copied, &literal_added))
return 0;
@@ -204,8 +204,8 @@ void diffcore_break(int break_score)
dp->score = score;
dp->broken_pair = 1;
- diff_free_filespec_data(p->one);
- diff_free_filespec_data(p->two);
+ diff_free_filespec_blob(p->one);
+ diff_free_filespec_blob(p->two);
free(p); /* not diff_free_filepair(), we are
* reusing one and two here.
*/
--
1.6.5.2.187.g29317
^ permalink raw reply related
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Jeff King @ 2009-11-16 16:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git, Brian Collins
In-Reply-To: <20091116195050.6117@nanako3.lavabit.com>
On Mon, Nov 16, 2009 at 07:50:50PM +0900, Nanako Shiraishi wrote:
> Quoting Brian Collins <bricollins@gmail.com>
>
> > You will have to excuse me, this is my first patch and I don't know if
> > this is the right place to post this. Apologies in advance if I'm in
> > the wrong place.
> >
> > git-grep currently throws an error when you combine the -F and -i
> > flags. This isn't in line with how GNU grep handles it. This patch
> > allows the simultaneous use of those flags.
>
> Junio, may I ask what happened to this patch?
I think I owed it another review.
I just looked it over and the idea and implementation look sane to me.
There were a few minor problems with the submission:
1. The patch was line-wrapped; I had to de-munge it manually to apply.
2. The original submission had cover-letter material mixed in with the
commit message. The follow-up version had no commit message at all.
3. No signed-off-by. Brian, can you please acknowledge the DCO with a
signoff?
4. The patch introduced some stray trailing whitespace.
5. There were a few style fixups, like omitting braces for a
single-line conditional.
To save Junio time, here is a version that fixes all of those things. I
think it's probably worth applying to 'next'.
-- >8 --
From: Brian Collins <bricollins@gmail.com>
Date: Fri, 6 Nov 2009 01:22:35 -0800
Subject: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
git-grep currently throws an error when you combine the -F
and -i flags. This isn't in line with how GNU grep handles
it. This patch allows the simultaneous use of those flags.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-grep.c | 8 +++++---
grep.c | 13 ++++++++++---
grep.h | 2 ++
t/t7002-grep.sh | 9 +++++++++
4 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 1df25b0..a2616fc 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -367,7 +367,7 @@ static int external_grep(struct grep_opt *opt, const char **paths, int cached)
push_arg("-h");
if (opt->regflags & REG_EXTENDED)
push_arg("-E");
- if (opt->regflags & REG_ICASE)
+ if (opt->caseless)
push_arg("-i");
if (opt->binary == GREP_BINARY_NOMATCH)
push_arg("-I");
@@ -706,8 +706,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_GROUP(""),
OPT_BOOLEAN('v', "invert-match", &opt.invert,
"show non-matching lines"),
- OPT_BIT('i', "ignore-case", &opt.regflags,
- "case insensitive matching", REG_ICASE),
+ OPT_BOOLEAN('i', "ignore-case", &opt.caseless,
+ "case insensitive matching"),
OPT_BOOLEAN('w', "word-regexp", &opt.word_regexp,
"match patterns only at word boundaries"),
OPT_SET_INT('a', "text", &opt.binary,
@@ -830,6 +830,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
external_grep_allowed = 0;
if (!opt.pattern_list)
die("no pattern given.");
+ if (!opt.fixed && opt.caseless)
+ opt.regflags |= REG_ICASE;
if ((opt.regflags != REG_NEWLINE) && opt.fixed)
die("cannot mix --fixed-strings and regexp");
compile_grep_patterns(&opt);
diff --git a/grep.c b/grep.c
index 5d162da..bbb0d18 100644
--- a/grep.c
+++ b/grep.c
@@ -41,6 +41,7 @@ static void compile_regexp(struct grep_pat *p, struct grep_opt *opt)
int err;
p->word_regexp = opt->word_regexp;
+ p->caseless = opt->caseless;
if (opt->fixed || is_fixed(p->pattern))
p->fixed = 1;
@@ -262,9 +263,15 @@ static void show_name(struct grep_opt *opt, const char *name)
printf("%s%c", name, opt->null_following_name ? '\0' : '\n');
}
-static int fixmatch(const char *pattern, char *line, regmatch_t *match)
+
+static int fixmatch(const char *pattern, char *line, int caseless, regmatch_t *match)
{
- char *hit = strstr(line, pattern);
+ char *hit;
+ if (caseless)
+ hit = strcasestr(line, pattern);
+ else
+ hit = strstr(line, pattern);
+
if (!hit) {
match->rm_so = match->rm_eo = -1;
return REG_NOMATCH;
@@ -326,7 +333,7 @@ static int match_one_pattern(struct grep_pat *p, char *bol, char *eol,
again:
if (p->fixed)
- hit = !fixmatch(p->pattern, bol, pmatch);
+ hit = !fixmatch(p->pattern, bol, p->caseless, pmatch);
else
hit = !regexec(&p->regexp, bol, 1, pmatch, eflags);
diff --git a/grep.h b/grep.h
index f6eecc6..24b7d44 100644
--- a/grep.h
+++ b/grep.h
@@ -32,6 +32,7 @@ struct grep_pat {
enum grep_header_field field;
regex_t regexp;
unsigned fixed:1;
+ unsigned caseless:1;
unsigned word_regexp:1;
};
@@ -64,6 +65,7 @@ struct grep_opt {
regex_t regexp;
int linenum;
int invert;
+ int caseless;
int status_only;
int name_only;
int unmatch_name_only;
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ae5290a..24a9445 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -411,4 +411,13 @@ test_expect_success 'grep from a subdirectory to search wider area (2)' '
)
'
+cat >expected <<EOF
+hello.c: return 0;
+EOF
+
+test_expect_success 'grep -Fi' '
+ git grep -Fi rEtUrN >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.6.5.2.187.g29317
^ permalink raw reply related
* Advice/help needed
From: Ian Hobson @ 2009-11-16 16:27 UTC (permalink / raw)
To: git
Hi all,
I am trying to switch to GIT (from SVN), and have become sorely
confused. I am not sure of the best way to solve the problem I have,
(nor how to actually implement a solution when one is chosen).
I am building a web application in php. There are 2 (soon to be four)
versions each slightly different for different customers. Each needs
testing when installed in "/" and "/dir" on the web site.
So far I have one system that in installed in a git repo on a Linux VM
with a share. This way I can develop in windows where I am familiar,
serve the files under linux (to match the production environment) and
run unit tests using phpUnit. The test files are all in a sub-directory
of the main directory. The application is served from a directory in the
website, so I could have different directories for different purposes,
but I have not had to use this yet.
Before release, I fetch and merge the files into a second installation
under windows, where I can serve it from the root. This forms a second
level of test. I release by copying the files with FTP (so that test
files and the GIT repo don't go on the production server).
This arrangement only works because I have been able to set up the
configuration files, database users and similar so they are all the same
on each installation. With 4 similar versions this will no longer be
possible.
What I want to be able to do is control all 4 versions in the same
manner, keep all file - common, different and test - in git, and have
checkout worry about changing versions.
My thoughts are to have 4 branches, one for each customer. 99% of all
changes will be needed by all (or at least most)
of the customers (P,W,S and E). How can I make a change to master and
then use git to apply those changes to the four branches, without losing
the differences between branches?
For example (if this is the best way) go from this
O-----O-----A-----B-----C (master)
\----P
\---W
\--S
\-E
to first this, where D is the net effect of A B and C (this is for ease
of reading logs, and commit messages),
O-----O-----D (head)
\----P
\---W
\--S
\-E
and then to this, (without editing all the files four times?)
O-----O-----D (head)
\----P-----D'
\---W----D''
\--S-----D'''
\-E-----D''''
Or would I be better having 4 repositories, one for each customer? Then
I need to pull changes and cherry pick the changes I want for each
customer?
I am the only developer, so the processes need to be simple so I am not
faced with sorting out my own errors! :)
Regards
Ian
^ 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