* Re: Git - Pushing to a production website
From: Boyd Stephen Smith Jr. @ 2009-01-10 4:38 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109222344.3539138a@family.dyweni.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:
>Our company's website is stored in a GIT Repository.
Interesting. I like the thought.
>The repository is coded for our test server. When we push updates to
>the production server, have manually run a script to patch several
>files to make the code work on the production server (i.e. port
>numbers, etc).
>
>I'd like to write a script to email me whenever someone changes files
>on the production server without checking those changes back into git
>(i.e. running 'git status | grep "nothing to commit" ...').
>
>However, this approach get confused by the files patched to work
>correctly.
>
>Is there any way to 'save' those patched files so they don't get
>reported by 'git status', yet not mung up the git history every time
>we push out an update?
You could simply commit after running the perl script. You could even commit
to a branch so that it's (a little) less likely those changes get integrated
into master.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git - Pushing to a production website
From: 4jxDQ6FQee2H @ 2009-01-10 4:46 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901092238.06968.bss@iguanasuicide.net>
> You could simply commit after running the perl script. You could
> even commit to a branch so that it's (a little) less likely those
> changes get integrated into master.
How about this, ran by the post-update hook:
For the first update:
- Do a git pull
- Then create a new branch 'working' and checkout
- Apply the patches to 'working' and commit
This leaves 'working' == 'master^'
For subsequent updates:
- Compare the SHA1 hashes for 'working' and 'master^'.
- If they don't match, throw an error and exit
- Assuming they match, checkout 'master' and delete 'working'
- Do a git pull
- Then create a new branch 'working' and checkout
- Apply the patches to 'working' and commit
This would keep the working directory clean and allow future updates to
occur, if no one commits anything to git 'working'. If they did, the
script would exit and prevent the update requiring the developer to
review the commit logs and cherry-pick where necessary.
^ permalink raw reply
* Re: Git - Pushing to a production website
From: david @ 2009-01-10 5:58 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: 4jxDQ6FQee2H, git
In-Reply-To: <200901092238.06968.bss@iguanasuicide.net>
On Fri, 9 Jan 2009, Boyd Stephen Smith Jr. wrote:
> On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:
>> Our company's website is stored in a GIT Repository.
>
> Interesting. I like the thought.
>
>> The repository is coded for our test server. When we push updates to
>> the production server, have manually run a script to patch several
>> files to make the code work on the production server (i.e. port
>> numbers, etc).
>>
>> I'd like to write a script to email me whenever someone changes files
>> on the production server without checking those changes back into git
>> (i.e. running 'git status | grep "nothing to commit" ...').
>>
>> However, this approach get confused by the files patched to work
>> correctly.
>>
>> Is there any way to 'save' those patched files so they don't get
>> reported by 'git status', yet not mung up the git history every time
>> we push out an update?
>
> You could simply commit after running the perl script. You could even commit
> to a branch so that it's (a little) less likely those changes get integrated
> into master.
one nice thing about git commit is that if there are no changes it doesn't
make a commit.
I have a couple files on my desktop (firefox status files for example)
that I have a cron job do a commit on every min so that when firefox
crashes in a way that can't be recovered by it's 'restore old pages'
option I can go back and save things anyway.
David Lang
^ permalink raw reply
* Re: Git - Pushing to a production website
From: Boyd Stephen Smith Jr. @ 2009-01-10 5:04 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109224618.5d8c461c@family.dyweni.com>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
On Friday 2009 January 09 22:46:18 4jxDQ6FQee2H@dyweni.com wrote:
>> You could simply commit after running the perl script. You could
>> even commit to a branch so that it's (a little) less likely those
>> changes get integrated into master.
>
>How about this, ran by the post-update hook:
>
>For the first update:
>
> - Do a git pull
I'm not enitirely sure you want post-update doing the pull.
> - Then create a new branch 'working' and checkout
> - Apply the patches to 'working' and commit
>
>This leaves 'working' == 'master^'
Actually, it leaves HEAD == working and master == working^.
>For subsequent updates:
> - Compare the SHA1 hashes for 'working' and 'master^'.
> - If they don't match, throw an error and exit
> - Assuming they match, checkout 'master' and delete 'working'
> - Do a git pull
(See above)
> - Then create a new branch 'working' and checkout
> - Apply the patches to 'working' and commit
>
>
>This would keep the working directory clean and allow future updates to
>occur, if no one commits anything to git 'working'. If they did, the
>script would exit and prevent the update requiring the developer to
>review the commit logs and cherry-pick where necessary.
It wouldn't *completely* prevent changes to working as one could "git
commit --amend" and still have working^ == master. That said, if developers
get creative enough they can probably bypass most measures, at least those
based on a hook.
A privileged process for updates could stash the expected SHA for master and
working somewhere developers can't write. That should prevent even dedicated
developers from making unauthorized changes, modulo security/cryptographic
exploits.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git - Pushing to a production website
From: 4jxDQ6FQee2H @ 2009-01-10 5:30 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901092304.51986.bss@iguanasuicide.net>
> > - Do a git pull
>
> I'm not enitirely sure you want post-update doing the pull.
Really?
Let's say the website lives in /srv/www/htdocs
Let's also say the git repository lives in /srv/www/git
All developers pull/push from /srv/www/git (git@server:/srv/www/git)
The website is a clone of /srv/www/git and only tracks 'master'.
Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.
I'm referencing this article:
http://jblevins.org/log/tools/managing-websites-with-git
Would you recommend a different way to automatically push any changes
to 'master' down to the website?
>
> > - Then create a new branch 'working' and checkout
> > - Apply the patches to 'working' and commit
> >
> >This leaves 'working' == 'master^'
>
> Actually, it leaves HEAD == working and master == working^.
I'm sorry - I mixed up my terminology.
I am referring to the branch's log.
'working' has 1 more log entry than 'master'.
Example:
- git log master | grep ^commit | tail -n 2 | head -n 1
- git log working | grep ^commit | tail -n 1 | head -n 1
Both of these commands should return the same commit hash.
^ permalink raw reply
* Re: Git - Pushing to a production website
From: Boyd Stephen Smith Jr. @ 2009-01-10 5:54 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109233037.31198694@family.dyweni.com>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
On Friday 09 January 2009, 4jxDQ6FQee2H@dyweni.com wrote about 'Re: Git -
Pushing to a production website':
>> > - Do a git pull
>>
>> I'm not enitirely sure you want post-update doing the pull.
>
>Let's say the website lives in /srv/www/htdocs
>Let's also say the git repository lives in /srv/www/git
>
>All developers pull/push from /srv/www/git (git@server:/srv/www/git)
>
>The website is a clone of /srv/www/git and only tracks 'master'.
>Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.
Ah. I was assuming you were "git pull"ing in the repository that the hook
was running from. In this case you are "git pull"ing in a different
repository, which should be fine.
>> >This leaves 'working' == 'master^'
>>
>> Actually, it leaves HEAD == working and master == working^.
>
>I'm sorry - I mixed up my terminology.
>
>I am referring to the branch's log.
>
>'working' has 1 more log entry than 'master'.
Yes, which means working^ == master.
commit-ish^ means the first parent of commit-ish
commit-ish^2 means the second parent of commit-ish
commit-ish~2 means the "first grandparent" of commit-ish
>Example:
> - git log master | grep ^commit | tail -n 2 | head -n 1
> - git log working | grep ^commit | tail -n 1 | head -n 1
>
>Both of these commands should return the same commit hash.
As would:
- git rev-parse master
- git rev-parse working^
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #01; Mon, 05)
From: Junio C Hamano @ 2009-01-10 6:15 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Miklos Vajna, git
In-Reply-To: <2c6b72b30901092015l2405627aqf928e43c12eabc3c@mail.gmail.com>
"Jonas Fonseca" <jonas.fonseca@gmail.com> writes:
> On Tue, Jan 6, 2009 at 01:33, Junio C Hamano <gitster@pobox.com> wrote:
>> ----------------------------------------------------------------
>> * mv/apply-parse-opt (Sun Dec 28 00:03:57 2008 +0100) 1 commit
>> + parse-opt: migrate builtin-apply.
>
> This broke apply for me after updating to the current "next" earlier
> today. When requesting that the patch be read from stdin I get the
> following error message:
>
> > git diff | git apply -R -
> fatal: can't open patch '-': No such file or directory
Thanks. I think this patch would fix it.
Because the original option parser was incremental and immediate with
respect to "-", we used to be able to say:
$ git apply -p - --stat patch2.txt <patch1.txt
and the use of parseopt breaks such usage, even after this fix.
But I think it is a bit too crazy to support such backward compatibility.
builtin-apply.c | 19 +++++--------------
t/t4106-apply-stdin.sh | 26 ++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git c/builtin-apply.c w/builtin-apply.c
index cb988a3..2811c0f 100644
--- c/builtin-apply.c
+++ w/builtin-apply.c
@@ -3140,16 +3140,6 @@ static int git_apply_config(const char *var, const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static int option_parse_stdin(const struct option *opt,
- const char *arg, int unset)
-{
- int *errs = opt->value;
-
- *errs |= apply_patch(0, "<stdin>", options);
- read_stdin = 0;
- return 0;
-}
-
static int option_parse_exclude(const struct option *opt,
const char *arg, int unset)
{
@@ -3218,9 +3208,6 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
const char *whitespace_option = NULL;
struct option builtin_apply_options[] = {
- { OPTION_CALLBACK, '-', NULL, &errs, NULL,
- "read the patch from the standard input",
- PARSE_OPT_NOARG, option_parse_stdin },
{ OPTION_CALLBACK, 0, "exclude", NULL, "path",
"don´t apply changes matching the given path",
0, option_parse_exclude },
@@ -3302,7 +3289,11 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
const char *arg = argv[i];
int fd;
- if (0 < prefix_length)
+ if (!strcmp(arg, "-")) {
+ errs |= apply_patch(0, "<stdin>", options);
+ read_stdin = 0;
+ continue;
+ } else if (0 < prefix_length)
arg = prefix_filename(prefix, prefix_length, arg);
fd = open(arg, O_RDONLY);
diff --git c/t/t4106-apply-stdin.sh w/t/t4106-apply-stdin.sh
new file mode 100755
index 0000000..72467a1
--- /dev/null
+++ w/t/t4106-apply-stdin.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='git apply --numstat - <patch'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo hello >text &&
+ git add text &&
+ echo goodbye >text &&
+ git diff >patch
+'
+
+test_expect_success 'git apply --numstat - < patch' '
+ echo "1 1 text" >expect &&
+ git apply --numstat - <patch >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'git apply --numstat - < patch patch' '
+ for i in 1 2; do echo "1 1 text"; done >expect &&
+ git apply --numstat - < patch patch >actual &&
+ test_cmp expect actual
+'
+
+test_done
^ permalink raw reply related
* Re: Git - Pushing to a production website
From: Jacob Helwig @ 2009-01-10 6:41 UTC (permalink / raw)
To: Git; +Cc: 4jxDQ6FQee2H
In-Reply-To: <20090109222344.3539138a@family.dyweni.com>
On Fri, Jan 9, 2009 at 20:23, <4jxDQ6FQee2H@dyweni.com> wrote:
> Hi,
>
> Our company's website is stored in a GIT Repository.
>
> The repository is coded for our test server. When we push updates to
> the production server, have manually run a script to patch several
> files to make the code work on the production server (i.e. port
> numbers, etc).
>
Are these all static pages? If they're Perl/PHP/Ruby/whatever, why
not add tests for the Live vs. Dev? Check for an environment
variable, or a file on disk, etc, etc? That way any checks described
below won't get "confused" by the (no longer necessary) patches, and
you won't have to worry about rebasing commits, and any potential
conflicts there.
> I'd like to write a script to email me whenever someone changes files
> on the production server without checking those changes back into git
> (i.e. running 'git status | grep "nothing to commit" ...').
>
> However, this approach get confused by the files patched to work
> correctly.
>
> Is there any way to 'save' those patched files so they don't get
> reported by 'git status', yet not mung up the git history every time
> we push out an update?
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH/RFC v5 1/1] more cache effective symlink/directory detection
From: René Scharfe @ 2009-01-10 10:11 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Pete Harlan, Linus Torvalds, Junio C Hamano
In-Reply-To: <1231527954-868-2-git-send-email-barvik@broadpark.no>
Kjetil Barvik schrieb:
> - Also introduce a 'void clear_lstat_cache(void)' function, which
> should be used to clean the cache before usage. If for instance,
> you have changed the types of directories which should be cached,
> the cache could contain a path which was not wanted.
Is it possible to make the cache detect these situations automatically
by saving track_flags along with the cache contents? Not having to
clear the cache manually would be a major feature.
> --- a/cache.h
> +++ b/cache.h
> @@ -719,7 +719,29 @@ struct checkout {
> };
>
> extern int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *topath);
> -extern int has_symlink_leading_path(int len, const char *name);
> +
> +#define LSTAT_REG (1u << 0)
> +#define LSTAT_DIR (1u << 1)
> +#define LSTAT_NOENT (1u << 2)
> +#define LSTAT_SYMLINK (1u << 3)
> +#define LSTAT_LSTATERR (1u << 4)
> +#define LSTAT_ERR (1u << 5)
> +#define LSTAT_FULLPATH (1u << 6)
> +extern unsigned int lstat_cache(int len, const char *name,
> + unsigned int track_flags, int prefix_len_stat_func);
> +extern void clear_lstat_cache(void);
> +static inline unsigned int has_symlink_leading_path(int len, const char *name)
> +{
> + return lstat_cache(len, name, LSTAT_SYMLINK|LSTAT_DIR, -1) &
> + LSTAT_SYMLINK;
> +}
> +#define clear_symlink_cache() clear_lstat_cache()
> +static inline unsigned int has_symlink_or_noent_leading_path(int len, const char *name)
> +{
> + return lstat_cache(len, name, LSTAT_SYMLINK|LSTAT_NOENT|LSTAT_DIR, -1) &
> + (LSTAT_SYMLINK|LSTAT_NOENT);
> +}
> +#define clear_symlink_or_noent_cache() clear_lstat_cache()
What's the advantage of inlining the wrappers (expressed in units of
space and/or time)? The interface would be much nicer if you exported
the wrappers, only, and not all those constants along with them.
And why define aliases for clear_lstat_cache()?
> diff --git a/entry.c b/entry.c
> index aa2ee46a84033585d8e07a585610c5a697af82c2..293400cf5be63fd66b797a68e17bf953c600fe99 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -8,35 +8,28 @@ static void create_directories(const char *path, const struct checkout *state)
> const char *slash = path;
>
> while ((slash = strchr(slash+1, '/')) != NULL) {
> - struct stat st;
> - int stat_status;
> -
> len = slash - path;
> memcpy(buf, path, len);
> buf[len] = 0;
>
> - if (len <= state->base_dir_len)
> - /*
> - * checkout-index --prefix=<dir>; <dir> is
> - * allowed to be a symlink to an existing
> - * directory.
> - */
> - stat_status = stat(buf, &st);
> - else
> - /*
> - * if there currently is a symlink, we would
> - * want to replace it with a real directory.
> - */
> - stat_status = lstat(buf, &st);
> -
> - if (!stat_status && S_ISDIR(st.st_mode))
> + /* For 'checkout-index --prefix=<dir>', <dir> is
> + * allowed to be a symlink to an existing directory,
> + * therefore we must give 'state->base_dir_len' to the
> + * cache, such that we test path components of the
> + * prefix with stat() instead of lstat()
> + *
> + * We must also tell the cache to test the complete
> + * length of the buffer (the '|LSTAT_FULLPATH' part).
> + */
> + if (lstat_cache(len, buf, LSTAT_DIR|LSTAT_FULLPATH,
> + state->base_dir_len) &
> + LSTAT_DIR)
> continue; /* ok, it is already a directory. */
I'd say this usage is worth another wrapper.
Also, it's probably worth to split this patch up again. First switching
to your improved implementation of has_symlink_leading_path(), then
introducing has_symlink_or_noent_leading_path() and finally adding
LSTAT_FULLPATH and the fourth parameter of lstat_cache() etc. and using
this feature in entry.c seems like a nice incremental progression.
René
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2009-01-10 10:12 UTC (permalink / raw)
To: Junio C Hamano, Alexander Potashev; +Cc: git
In-Reply-To: <20090108231135.GB4185@roro3>
On Fri, Jan 09, 2009 at 02:11:35AM +0300, Kirill Smelkov wrote:
> Changes since v1:
>
> o incorporated Junio's description and code about padding
> o incorporated Junio's description and code about LWS between encoded
> words
> o incorporated tests from RFC2047 examples (one testresult is unclear
> -- see patch description)
>
>
> From: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> Subject: mailinfo: correctly handle multiline 'Subject:' header
[...]
Junio, All, just in case this again got spam-detected:
http://marc.info/?l=git&m=123145624611936&w=2
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH v2] t7501-commit.sh: explicitly check that -F prevents invoking the editor
From: Johannes Schindelin @ 2009-01-10 10:19 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, gitster
In-Reply-To: <1231522205-10510-1-git-send-email-dato@net.com.org.es>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 945 bytes --]
Hi,
On Fri, 9 Jan 2009, Adeodato Simó wrote:
> diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
> index 6e18a96..5998baf 100755
> --- a/t/t7500-commit.sh
> +++ b/t/t7500-commit.sh
> @@ -149,10 +149,7 @@ EOF
>
> test_expect_success '--signoff' '
> echo "yet another content *narf*" >> foo &&
> - echo "zort" | (
> - test_set_editor "$TEST_DIRECTORY"/t7500/add-content &&
> - git commit -s -F - foo
> - ) &&
> + echo "zort" | git commit -s -F - foo &&
> git cat-file commit HEAD | sed "1,/^$/d" > output &&
> test_cmp expect output
> '
AFAICT this still tests if -F - launches an editor, except that it _does_
launch the editor, waiting for the user to quit the editor. Which is bad.
In the end I think it is not worth all that effort (as the issue was fixed
long time ago, probably even before builtin-commit entered 'next'), so I'd
just leave the test as-is, documenting why the editor is set to
add-content.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Get format-patch to show first commit after root commit
From: Johannes Schindelin @ 2009-01-10 10:27 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <49679f61.1b068e0a.048f.70e4@mx.google.com>
Hi,
your mailing process has a problem; neither the recipients nor the subject
made it into the mail header.
On Fri, 9 Jan 2009, nathan.panike@gmail.com wrote:
> >From 65c4fed27fe9752ffd0e3b7cb6807561a4dd4601 Mon Sep 17 00: 00:00 2001
> From: Nathan W. Panike <nathan.panike@gmail.com>
> Date: Fri, 9 Jan 2009 11:53:43 -0600
> Subject: [PATCH] Get format-patch to show first commit after root commit
>
> Currently, the command
>
> git format-patch -1 e83c5163316f89bfbde
You do not need -1, and using 19 digits seems a bit arbitrary; the
convention seems to be 7 digits (that is what --abbrev-commit does).
>
> in the git repository creates an empty file. Instead, one is
> forced to do
>
> git format-patch -1 --root e83c5163316f89bfbde
>
> This seems arbitrary. This patch fixes this case, so that
>
> git format-patch -1 e83c5163316f89bfbde
>
> will produce an actual patch.
IMHO mentioning --root is misleading, as the real bug is the empty diff.
Apart from that, I like the patch, though.
Thanks,
Dscho
^ permalink raw reply
* Re: collapsing commits with rebase
From: nadim khemir @ 2009-01-10 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0901071608r190a723bma502b68c4ab81a08@mail.gmail.com>
On Thursday 08 January 2009 01.08.44 Geoff Russell wrote:
> Dear gits,
>
> I have a series of commits:
>
> A---B---C---D---E---F
>
> I want to collapse B---C---D into one single commit. git rebase -i B will
> allow me to do this, but I'm looking for a non-interactive incantation.
Hi Geoff, Could you please share with use the final (tested) solution? I'd be
interrested to see how you did implement plan B if you did.
Cheers, Nadim.
^ permalink raw reply
* Re: [PATCH v2] t7501-commit.sh: explicitly check that -F prevents invoking the editor
From: Adeodato Simó @ 2009-01-10 10:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901101117100.30769@pacific.mpi-cbg.de>
* Johannes Schindelin [Sat, 10 Jan 2009 11:19:43 +0100]:
> Hi,
Hello,
> > test_expect_success '--signoff' '
> > echo "yet another content *narf*" >> foo &&
> > - echo "zort" | (
> > - test_set_editor "$TEST_DIRECTORY"/t7500/add-content &&
> > - git commit -s -F - foo
> > - ) &&
> > + echo "zort" | git commit -s -F - foo &&
> > git cat-file commit HEAD | sed "1,/^$/d" > output &&
> > test_cmp expect output
> > '
> AFAICT this still tests if -F - launches an editor, except that it _does_
> launch the editor, waiting for the user to quit the editor. Which is bad.
The default value of VISUAL for the test suite is ":" AFAICS. Hence,
even if it's called, it will return immediately.
If it would be called, without my patch the "--signoff" test would fail,
but there would be no obvious reason as to why. Seeing "editor not
invoked if -F is given FAILED" is much more clear IMHO.
Also note that there plenty of places in the test suite where -F is
used, but VISUAL is not set explicitly.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Excuse me for thinking a banana-eating contest was about eating a banana!
-- Paris Geller
^ permalink raw reply
* Re: [PATCH] Get format-patch to show first commit after root commit
From: Johannes Schindelin @ 2009-01-10 10:35 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901101122570.30769@pacific.mpi-cbg.de>
Hi,
On Sat, 10 Jan 2009, Johannes Schindelin wrote:
> On Fri, 9 Jan 2009, nathan.panike@gmail.com wrote:
>
> > >From 65c4fed27fe9752ffd0e3b7cb6807561a4dd4601 Mon Sep 17 00: 00:00 2001
> > From: Nathan W. Panike <nathan.panike@gmail.com>
> > Date: Fri, 9 Jan 2009 11:53:43 -0600
> > Subject: [PATCH] Get format-patch to show first commit after root commit
> >
> > Currently, the command
> >
> > git format-patch -1 e83c5163316f89bfbde
>
> You do not need -1, and using 19 digits seems a bit arbitrary; the
> convention seems to be 7 digits (that is what --abbrev-commit does).
Sorry, the -1 is needed.
Ciao,
Dscho
^ permalink raw reply
* Re: collapsing commits with rebase
From: Geoff Russell @ 2009-01-10 10:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0901081205120.30769@pacific.mpi-cbg.de>
On 1/8/09, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 8 Jan 2009, Geoff Russell wrote:
>
> > On Thu, Jan 8, 2009 at 11:15 AM, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> >
>
> > > Alternatively, something like this should work for you:
> > >
> > > $ git checkout A
> > > $ git read-tree -u -m D
> > > $ git commit -m "My message"
> > > $ git cherry-pick E
> > > $ git cherry-pick F
> >
> > Plan B is looking good, because I'd generally like the commit message to
> > be the concatenation of the messages for B,C and D.
>
>
> Replace the commit call by this:
>
> $ for commit in B C D
> do
> git cat-file commit $commit | sed '1,/^$/d'
> # possibly add an empty line between the commit messages,
> # git commit will strip away empty lines at the end.
> done |
> git commit -F -
>
> Hth,
> Dscho
That makes sense, many thanks.
Cheers,
Geoff.
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Johannes Schindelin @ 2009-01-10 10:49 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Teemu Likonen
In-Reply-To: <1231549039-5236-1-git-send-email-trast@student.ethz.ch>
Hi,
On Sat, 10 Jan 2009, Thomas Rast wrote:
> diff.c | 199 +++++++++++++++++++++++++++++++++++----
!!!
BTW I did not really think about the issue you raised about the newlines,
as I seemed to remember that the idea was to substitute all non-word
characters with newlines, so that the offsets in the substituted text are
the same as in the original text.
So I still find your patch way too large, and it keeps growing,
unfortunately.
Ciao,
Dscho
^ permalink raw reply
* SSH_ASKPASS
From: Henk @ 2009-01-10 10:55 UTC (permalink / raw)
To: git
Hi,
I'm trying to get "git push" to use git-gui--askpass to ask me for the
password instead of promting me on the command promt. I need this because I
start the "git push" command from code and there is no terminal where ssh
can ask the user for a password. I tried writing the following tcl script
that allmost is what I need:
set env(SSH_ASKPASS) "C:/Program
Files/Git/libexec/git-core/git-gui--askpass"
exec ssh git@github.com
Ssh will now ask me for the password using git-gui--askpass. But now the
standardout is also shown in a dialog, and not on the standardout of the
process. Looking at the git-gui scripts didn't help me, because I have
absolutely zero experience in tcl.
I also tried not using a tcl script, but setting SSH_ASKPASS as an
environment variable in windows. This doesn't seem to work, ssh will still
prompt me for a password.
Anyone can help me write a script that asks for the password using
SSH_ASKPASS but still prints the output on standardout?
I use Windows btw.
Henk
--
View this message in context: http://n2.nabble.com/SSH_ASKPASS-tp2137400p2137400.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git - Pushing to a production website
From: David Aguilar @ 2009-01-10 11:04 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109222344.3539138a@family.dyweni.com>
On Fri, Jan 9, 2009 at 8:23 PM, <4jxDQ6FQee2H@dyweni.com> wrote:
> Hi,
>
> Our company's website is stored in a GIT Repository.
>
> The repository is coded for our test server. When we push updates to
> the production server, have manually run a script to patch several
> files to make the code work on the production server (i.e. port
> numbers, etc).
The simplest solution is to not track those files at all.
Instead of tracking app.conf, mv it to app.conf.sample
and track that instead. Likewise, add an entry for app.conf
in .gitignore.
When devs create new sandboxes they just
cp app.conf.sample app.conf
and all is well because app.conf is in .gitignore.
If you literally do 'git mv' in a sandbox and push it out then
be careful since pushing that change to production will do
exactly what it was told to do (remove the config).
it's a small price to pay for simplicity, though, so just
remember to keep a backup.
> I'd like to write a script to email me whenever someone changes files
> on the production server without checking those changes back into git
> (i.e. running 'git status | grep "nothing to commit" ...').
Having the config files in .gitignore eliminates a lot of work in
your update hooks and it makes writing this script much easier.
The only extra cost comes in having to manage the config files
separately from the application, but it's nothing that can't be
automated.
> However, this approach get confused by the files patched to work
> correctly.
>
> Is there any way to 'save' those patched files so they don't get
> reported by 'git status', yet not mung up the git history every time
> we push out an update?
>
> Thanks!
> --
--
David
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Thomas Rast @ 2009-01-10 11:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901101146230.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
Johannes Schindelin wrote:
> BTW I did not really think about the issue you raised about the newlines,
> as I seemed to remember that the idea was to substitute all non-word
> characters with newlines, so that the offsets in the substituted text are
> the same as in the original text.
Ok, so here's a very simple example: Suppose you have the word regex
'x+|y+' and compare these two lines:
A: xxyyxy
B: xyxyy
There are *no* non-word characters between consecutive words in this
case, so you *cannot* replace them with newlines. You cannot replace
some word character either, as should be obvious from the case of
one-letter words, as you would lose actual content. My counterexample
to your illustration patch exploited a similar border case: suppose
you decide to overwrite the first (instead of last) character of each
word, then you won't be able to tell "foo" from "\noo" in the input.
Unfortunately the space adjustement makes things even worse. The
existing method has the side-effect that it only inserts a single
newline between words separated by exactly one space, which runs them
together in the resulting line diff, for example
A: foo bar
B: baz quux
would result in
-foo
-bar
+baz
+quux
instead of (as my original attempts did) the arguably more correct,
but less readable
-foo
+bar
-baz
+quux
where the middle line is a context line for the space. So in addition
to the word-ending adjustments for the inserted newlines, I also have
to track the status of the space right after the word.
> So I still find your patch way too large
I can't think of a simpler way to do it, and yours unfortunately
doesn't work.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] Teach Git about the patience diff algorithm
From: Johannes Schindelin @ 2009-01-10 11:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Adeodato Simó, Linus Torvalds, Clemens Buchacher,
Pierre Habouzit, davidel, Francis Galiegue, Git ML
In-Reply-To: <7vvdsoyzej.fsf@gitster.siamese.dyndns.org>
Hi,
On Fri, 9 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Thu, 8 Jan 2009, Junio C Hamano wrote:
> >
> >> If we find the "common" context lines that have only blank and
> >> punctuation letters in Dscho output, turn each of them into "-" and "+",
> >> and rearrange them so that all "-" are together followed by "+", it will
> >> match Bzr output.
> >
> > So we'd need something like this (I still think we should treat curly
> > brackets the same as punctuation, and for good measure I just handled
> > everything that is not alphanumerical the same):
>
> I meant by punctuation to include curlies (my wording may have been wrong
> but from the example with " }" line it should have been obvious).
>
> But I agree with both points Linus raised. The criteria to pick what to
> pretend unmatching should be "small insignificant lines" (small goes for
> both size and also number of consecutive "insignificant" lines), and the
> coallescing should be done to join a block of consecutive changed lines of
> a significant size (so you do not join two 1 or 2-line "changed line"
> blocks by pretending that a 1-line unchanged insignificant line in between
> them is unmatching).
Of course, the number should be configurable as with the inter-hunk
context.
However, I'll not have much time to work on this feature, and it would
definitely need some experimenting to find the best parameters, e.g.
maximal number of inter-hunk lines, maybe even an inter-hunk/hunk ratio,
alnums, or as Linus suggests the length of the line (of which I am still
not convinced).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Get format-patch to show first commit after root commit
From: Alexander Potashev @ 2009-01-10 11:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathan W. Panike, git
In-Reply-To: <7vmye0yohu.fsf@gitster.siamese.dyndns.org>
Hello, Junio!
> I think the attached would be a better patch. We already have a
> configuration to control if we show the patch for a root commit by
> default, and we can use reuse it here. The configuration defaults to true
> these days.
>
> Because the code before the hunk must check if the user said "--root
> commit" or just "commit" from the command line and behave quite
> differently by looking at rev.show_root_diff, we cannot do this assignment
> before the command line parsing like other commands in the log family.
I think the problem was not only format-patch misbehaviour. If you use
"log.showroot = no", you still get an empty patch file, which is not
very good, because format-patch doesn't work very well, it creates
_corrupt_ patches! It's much better to not create the patch file at all
in this case.
However, it has nothing in common with your patch, but there's room for
another commit.
>
> builtin-log.c | 8 ++++++++
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git c/builtin-log.c w/builtin-log.c
> index 4a02ee9..2d2c111 100644
> --- c/builtin-log.c
> +++ w/builtin-log.c
> @@ -935,6 +935,14 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
> * get_revision() to do the usual traversal.
> */
> }
> +
> + /*
> + * We cannot move this anywhere earlier because we do want to
> + * know if --root was given explicitly from the comand line.
> + */
> + if (default_show_root)
> + rev.show_root_diff = 1;
> +
> if (cover_letter) {
> /* remember the range */
> int i;
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Johannes Schindelin @ 2009-01-10 11:37 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <gk8usj$slh$1@ger.gmane.org>
Hi,
On Sat, 10 Jan 2009, Jakub Narebski wrote:
> Thomas Rast wrote:
>
> > --color-words works (and always worked) by splitting words onto one
> > line each, and using the normal line-diff machinery to get a word
> > diff.
>
> Cannot we generalize diff machinery / use underlying LCS diff engine
> instead of going through line diff?
What do you think we're doing? libxdiff is pretty hardcoded to newlines.
That's why we're substituting non-word characters with newlines.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] format-patch: avoid generation of empty patches
From: Alexander Potashev @ 2009-01-10 11:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nathan W. Panike, git
In-Reply-To: <20090110113642.GA25723@myhost>
If 'log.showroot' is not set, format-patch shouldn't even try to create
a patch for the root commit.
Signed-off-by: Alexander Potashev <aspotashev@gmail.com>
---
builtin-log.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 4a02ee9..62134d4 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -972,6 +972,9 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
has_commit_patch_id(commit, &ids))
continue;
+ if (!commit->parents && !rev.show_root_diff)
+ break;
+
nr++;
list = xrealloc(list, nr * sizeof(list[0]));
list[nr - 1] = commit;
--
1.6.1.77.g569c.dirty
^ permalink raw reply related
* Re: [PATCH v2] make diff --color-words customizable
From: Johannes Schindelin @ 2009-01-10 11:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901101225.10719.trast@student.ethz.ch>
Hi,
On Sat, 10 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > BTW I did not really think about the issue you raised about the newlines,
> > as I seemed to remember that the idea was to substitute all non-word
> > characters with newlines, so that the offsets in the substituted text are
> > the same as in the original text.
>
> Ok, so here's a very simple example: Suppose you have the word regex
> 'x+|y+' and compare these two lines:
>
> A: xxyyxy
> B: xyxyy
Ah, I see.
> > So I still find your patch way too large
>
> I can't think of a simpler way to do it, and yours unfortunately doesn't
> work.
Well, the thing I tried to hint at: it is not good to have a monster
patch, as nobody will review it.
In your case, I imagine it would be much easier to get reviewers if you
had
patch 1/4 refactor color-words to allow for 0-character word
boundaries
patch 2/4 allow regular expressions to define what makes a word
patch 3/4 add option to specify word boundary regexps via
attributes
patch 4/4 test word boundary regexps
And I admit that I documented the code lousily, but that does not mean
that you should repeat that mistake.
Ciao,
Dscho
^ 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