* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Daniel Barkalow @ 2008-10-12 20:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster, spearce
In-Reply-To: <alpine.DEB.1.00.0810111336350.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Sat, 11 Oct 2008, Johannes Schindelin wrote:
> Some confusing tutorials suggest that it would be a good idea to call
> something like this:
>
> git pull origin master:master
>
> While it might make sense to store what you want to merge, it typically
> is plain wrong. Especially so when the current branch is "master".
>
> Be at least a little bit helpful by refusing to fetch something into
> the current branch.
I think this is the right thing to do.
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> builtin-fetch.c | 20 ++++++++++++++++++++
> t/t5505-remote.sh | 2 +-
> t/t5510-fetch.sh | 6 ++++++
> 3 files changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index ee93d3a..d701550 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> @@ -534,6 +534,25 @@ static void find_non_local_tags(struct transport *transport,
> string_list_clear(&new_refs, 0);
> }
>
> +static void check_ref_map(struct ref *ref_map)
> +{
> + int flag;
> + unsigned char sha1[20];
> + const char *HEAD;
> +
> + if (is_bare_repository())
> + return;
> +
> + HEAD = resolve_ref("HEAD", sha1, 1, &flag);
> +
> + if (!HEAD || !(flag & REF_ISSYMREF))
> + return;
remote.h has a function for getting "the current branch", which would save
5 lines here:
struct branch *current_branch = branch_get(NULL);
if (!current_branch || is_bare_repository())
return;
> +
> + for (; ref_map; ref_map = ref_map->next)
> + if (ref_map->peer_ref && !strcmp(HEAD, ref_map->peer_ref->name))
!strcmp(current_branch->ref_name, ref_map->peer_ref->name)
(untested, and might be off by a "refs/" or something)
> + die("Refusing to fetch into current branch");
> +}
> +
> static int do_fetch(struct transport *transport,
> struct refspec *refs, int ref_count)
> {
> @@ -558,6 +577,7 @@ static int do_fetch(struct transport *transport,
> }
>
> ref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);
> + check_ref_map(ref_map);
>
> for (rm = ref_map; rm; rm = rm->next) {
> if (rm->peer_ref)
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-12 20:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081012200833.GC5255@spearce.org>
On Sun, Oct 12, 2008 at 10:08 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
>> After fixing clone -q I noticed that pull -q is does not do what
>> it's supposed to do and implemented --quiet/--verbose by
>> adding it to builtin-merge and fixing two places in builtin-fetch.
>
>> diff --git a/builtin-merge.c b/builtin-merge.c
>> index 38266ba..1f601d4 100644
>> --- a/builtin-merge.c
>> +++ b/builtin-merge.c
>> @@ -101,7 +102,7 @@ static struct strategy *get_strategy(const char *name)
>> struct cmdname *ent = main_cmds.names[i];
>> for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
>> if (!strncmp(ent->name, all_strategy[j].name, ent->len)
>> - && !all_strategy[j].name[ent->len])
>> + && !all_strategy[j].name[ent->len])
>
> This hunk seems to just be whitespace formatting. I'd rather not
> see it in a patch that is otherwise about --quiet/--verbose changes.
> One change per patch, please. ;-)
Hi Shawn, thanks for the quick review.
This is a problem caused by my automagic editor
configuration and an oversight. ACK.
>> @@ -282,18 +287,20 @@ static void squash_message(void)
>> if (prepare_revision_walk(&rev))
>> die("revision walk setup failed");
>>
>> - strbuf_init(&out, 0);
>> - strbuf_addstr(&out, "Squashed commit of the following:\n");
>> - while ((commit = get_revision(&rev)) != NULL) {
>> - strbuf_addch(&out, '\n');
>> - strbuf_addf(&out, "commit %s\n",
>> - sha1_to_hex(commit->object.sha1));
>> - pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
>> - NULL, NULL, rev.date_mode, 0);
>> + if(verbose || !quiet) {
>> + strbuf_init(&out, 0);
>> + strbuf_addstr(&out, "Squashed commit of the following:\n");
>> + while ((commit = get_revision(&rev)) != NULL) {
>> + strbuf_addch(&out, '\n');
>> + strbuf_addf(&out, "commit %s\n",
>> + sha1_to_hex(commit->object.sha1));
>> + pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
>> + NULL, NULL, rev.date_mode, 0);
>> + }
>> + write(fd, out.buf, out.len);
>> + close(fd);
>> + strbuf_release(&out);
>> }
>> - write(fd, out.buf, out.len);
>> - close(fd);
>> - strbuf_release(&out);
>
> This entire hunk strikes me as being completely wrong. The fd
> we are writing to is SQUASH_MSG. It was opened earlier in the
> function and should be closed, even if we put nothing into the
> file. Your change causes --quiet to leak the file descriptor.
>
> But even worse, I think your change causes SQUASH_MSG to lose its
> entire content, which makes "git merge --quiet --squash" behave
> very differently from what it does today, where it at least gives
> you a summary of the commits in the SQUASH_MSG file.
>
> IMHO this hunk shouldn't be here.
You are right, I was not 100% sure whether the assembled
message is only displayed or possibly also stored somewhere.
What would be the right place to quieten this one?
I should have tagged the mail as an RFC :-).
>> @@ -877,6 +885,8 @@ int cmd_merge(int argc, const char **argv, const
>> char *prefix)
>>
>> argc = parse_options(argc, argv, builtin_merge_options,
>> builtin_merge_usage, 0);
>> + if(!verbose && quiet)
>> + show_diffstat = 0;
>
> Formatting nit, use "if (".
ACK.
>> @@ -1019,11 +1029,11 @@ int cmd_merge(int argc, const char **argv,
>> const char *prefix)
>> char hex[41];
>>
>> strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
>> -
>> - printf("Updating %s..%s\n",
>> - hex,
>> - find_unique_abbrev(remoteheads->item->object.sha1,
>> - DEFAULT_ABBREV));
>> + if(verbose || !quiet)
>
> Formatting nit, use "if (".
ACK.
>> diff --git a/git-pull.sh b/git-pull.sh
>> index 75c3610..d84ceb5 100755
>> --- a/git-pull.sh
>> +++ b/git-pull.sh
>> @@ -16,13 +16,17 @@ cd_to_toplevel
>> test -z "$(git ls-files -u)" ||
>> die "You are in the middle of a conflicted merge."
>>
>> -strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
>> +quiet= verbose= strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
>
> This line got a little long, maybe put the two new ones on a new
> line so we don't overrun the 80 column margin and there's an easier
> to read diff?
ACK.
I will fix the obvious and see what I can come up with for the
pretty_print hunk.
^ permalink raw reply
* Re: [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-12 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: spearce, dpotapov, git
In-Reply-To: <7vskr1fvys.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Before you do that, can you explain why git_cygwin_config() should
> duplicate the setting of that variable instead of using the existing
> parser for that variable by calling git_default_config()?
>
>
I don't like traversing the same list of configuration variables / files
twice, each time looking for a different variable just so that one of
those traversals can use a standard function, rather than just
traversing once and getting exactly what this routine needs; this seems
wasteful to me. However, I am (obviously) not the maintainer of this
code so I will do this however it is desired.
Mark
^ permalink raw reply
* Re: [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Shawn O. Pearce @ 2008-10-12 20:08 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0810120954x2364054ahf2d49d6fbb7b0bb1@mail.gmail.com>
Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> After fixing clone -q I noticed that pull -q is does not do what
> it's supposed to do and implemented --quiet/--verbose by
> adding it to builtin-merge and fixing two places in builtin-fetch.
> diff --git a/builtin-merge.c b/builtin-merge.c
> index 38266ba..1f601d4 100644
> --- a/builtin-merge.c
> +++ b/builtin-merge.c
> @@ -101,7 +102,7 @@ static struct strategy *get_strategy(const char *name)
> struct cmdname *ent = main_cmds.names[i];
> for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
> if (!strncmp(ent->name, all_strategy[j].name, ent->len)
> - && !all_strategy[j].name[ent->len])
> + && !all_strategy[j].name[ent->len])
This hunk seems to just be whitespace formatting. I'd rather not
see it in a patch that is otherwise about --quiet/--verbose changes.
One change per patch, please. ;-)
> @@ -282,18 +287,20 @@ static void squash_message(void)
> if (prepare_revision_walk(&rev))
> die("revision walk setup failed");
>
> - strbuf_init(&out, 0);
> - strbuf_addstr(&out, "Squashed commit of the following:\n");
> - while ((commit = get_revision(&rev)) != NULL) {
> - strbuf_addch(&out, '\n');
> - strbuf_addf(&out, "commit %s\n",
> - sha1_to_hex(commit->object.sha1));
> - pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
> - NULL, NULL, rev.date_mode, 0);
> + if(verbose || !quiet) {
> + strbuf_init(&out, 0);
> + strbuf_addstr(&out, "Squashed commit of the following:\n");
> + while ((commit = get_revision(&rev)) != NULL) {
> + strbuf_addch(&out, '\n');
> + strbuf_addf(&out, "commit %s\n",
> + sha1_to_hex(commit->object.sha1));
> + pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
> + NULL, NULL, rev.date_mode, 0);
> + }
> + write(fd, out.buf, out.len);
> + close(fd);
> + strbuf_release(&out);
> }
> - write(fd, out.buf, out.len);
> - close(fd);
> - strbuf_release(&out);
This entire hunk strikes me as being completely wrong. The fd
we are writing to is SQUASH_MSG. It was opened earlier in the
function and should be closed, even if we put nothing into the
file. Your change causes --quiet to leak the file descriptor.
But even worse, I think your change causes SQUASH_MSG to lose its
entire content, which makes "git merge --quiet --squash" behave
very differently from what it does today, where it at least gives
you a summary of the commits in the SQUASH_MSG file.
IMHO this hunk shouldn't be here.
> @@ -877,6 +885,8 @@ int cmd_merge(int argc, const char **argv, const
> char *prefix)
>
> argc = parse_options(argc, argv, builtin_merge_options,
> builtin_merge_usage, 0);
> + if(!verbose && quiet)
> + show_diffstat = 0;
Formatting nit, use "if (".
> @@ -1019,11 +1029,11 @@ int cmd_merge(int argc, const char **argv,
> const char *prefix)
> char hex[41];
>
> strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
> -
> - printf("Updating %s..%s\n",
> - hex,
> - find_unique_abbrev(remoteheads->item->object.sha1,
> - DEFAULT_ABBREV));
> + if(verbose || !quiet)
Formatting nit, use "if (".
> diff --git a/git-pull.sh b/git-pull.sh
> index 75c3610..d84ceb5 100755
> --- a/git-pull.sh
> +++ b/git-pull.sh
> @@ -16,13 +16,17 @@ cd_to_toplevel
> test -z "$(git ls-files -u)" ||
> die "You are in the middle of a conflicted merge."
>
> -strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
> +quiet= verbose= strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
This line got a little long, maybe put the two new ones on a new
line so we don't overrun the 80 column margin and there's an easier
to read diff?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Junio C Hamano @ 2008-10-12 19:35 UTC (permalink / raw)
To: Mark Levedahl; +Cc: gitster, spearce, dpotapov, git
In-Reply-To: <1223837086-2864-1-git-send-email-mlevedahl@gmail.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Cygwin's POSIX emulation allows use of core.filemode true, unlike native
> Window's implementation of stat / lstat, and Cygwin/git users who have
> configured core.filemode true in various repositories will be very
> unpleasantly surprised to find that git is no longer honoring that option.
> So, this patch forces use of Cygwin's stat functions if core.filemode is
> set true, regardless of any other considerations.
>
> Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
> ---
> Updated to use trust_executable_bit as suggested on the list.
Before you do that, can you explain why git_cygwin_config() should
duplicate the setting of that variable instead of using the existing
parser for that variable by calling git_default_config()?
^ permalink raw reply
* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Shawn O. Pearce @ 2008-10-12 18:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0810111336350.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> diff --git a/builtin-fetch.c b/builtin-fetch.c
> index ee93d3a..d701550 100644
> --- a/builtin-fetch.c
> +++ b/builtin-fetch.c
> @@ -534,6 +534,25 @@ static void find_non_local_tags(struct transport *transport,
> string_list_clear(&new_refs, 0);
> }
>
> +static void check_ref_map(struct ref *ref_map)
> +{
> + int flag;
> + unsigned char sha1[20];
> + const char *HEAD;
> +
> + if (is_bare_repository())
> + return;
> +
> + HEAD = resolve_ref("HEAD", sha1, 1, &flag);
I'd rather see local variables named lowercase. Constants should
be the only thing that is all uppercase.
> @@ -558,6 +577,7 @@ static int do_fetch(struct transport *transport,
> }
>
> ref_map = get_ref_map(transport, refs, ref_count, tags, &autotags);
> + check_ref_map(ref_map);
This should only be called if update_head_ok is false. So maybe:
if (!update_head_ok)
check_ref_map(ref_map)
> diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
> index 9aae496..cd8b550 100755
> --- a/t/t5510-fetch.sh
> +++ b/t/t5510-fetch.sh
> @@ -323,4 +323,10 @@ test_expect_success 'auto tag following fetches minimum' '
> )
> '
>
> +test_expect_success 'refuse to fetch into the current branch' '
> +
> + test_must_fail git fetch . side:master
> +
> +'
> +
Repeat this test, but with --update-head-ok and expect success,
since the check_ref_map logic is conditional on that?
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fetch: refuse to fetch into the current branch in a non-bare repository
From: Shawn O. Pearce @ 2008-10-12 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vprm6iz6z.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Some confusing tutorials suggest that it would be a good idea to call
> > something like this:
> >
> > git pull origin master:master
> >
> > While it might make sense to store what you want to merge, it typically
> > is plain wrong.
>
> I am somewhat confused.
The description is confusing, yes. It should be about git fetch,
not git pull.
> This "confusion" has been there for very long time and (at least the
> scripted version of) git-pull/git-fetch pair has supported a workaround in
> the form of --update-head-ok option.
I think "git fetch url side:master" when master is the current branch
and we have omitted --update-head-ok is broken. Specifically Dscho's
last hunk which adds this test. The test fails on current master.
Looking at the code in builtin-fetch.c, the only usage of
update_head_ok is for output about the current branch. I think
it should have been used in at least one other spot, to decide if
the RHS of a refspec is valid for storage. Dscho's patch tries to
address that.
diff --git a/t/t5510-fetch.sh b/t/t5510-fetch.sh
index 9aae496..cd8b550 100755
--- a/t/t5510-fetch.sh
+++ b/t/t5510-fetch.sh
@@ -323,4 +323,10 @@ test_expect_success 'auto tag following fetches minimum' '
)
'
+test_expect_success 'refuse to fetch into the current branch' '
+
+ test_must_fail git fetch . side:master
+
+'
+
test_done
--
Shawn.
^ permalink raw reply related
* [PATCH] compat/cygwin.c - Use cygwin's stat if core.filemode == true
From: Mark Levedahl @ 2008-10-12 18:44 UTC (permalink / raw)
To: gitster; +Cc: spearce, dpotapov, git, Mark Levedahl
In-Reply-To: <20081012133934.GB21650@dpotapov.dyndns.org>
Cygwin's POSIX emulation allows use of core.filemode true, unlike native
Window's implementation of stat / lstat, and Cygwin/git users who have
configured core.filemode true in various repositories will be very
unpleasantly surprised to find that git is no longer honoring that option.
So, this patch forces use of Cygwin's stat functions if core.filemode is
set true, regardless of any other considerations.
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Updated to use trust_executable_bit as suggested on the list.
Documentation/config.txt | 4 +++-
compat/cygwin.c | 16 +++++++++++++---
2 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7161597..a3a9495 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -124,7 +124,9 @@ core.ignoreCygwinFSTricks::
one hierarchy using Cygwin mount. If true, Git uses native Win32 API
whenever it is possible and falls back to Cygwin functions only to
handle symbol links. The native mode is more than twice faster than
- normal Cygwin l/stat() functions. True by default.
+ normal Cygwin l/stat() functions. True by default, unless core.filemode
+ is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
+ POSIX emulation is required to support core.filemode.
core.trustctime::
If false, the ctime differences between the index and the
diff --git a/compat/cygwin.c b/compat/cygwin.c
index 423ff20..221d2f5 100644
--- a/compat/cygwin.c
+++ b/compat/cygwin.c
@@ -91,12 +91,17 @@ static int cygwin_stat(const char *path, struct stat *buf)
* functions should be used. The choice is determined by core.ignorecygwinfstricks.
* Reading this option is not always possible immediately as git_dir may be
* not be set yet. So until it is set, use cygwin lstat/stat functions.
+ * However, if core.filemode is true, we *must* use the Cygwin posix stat as
+ * the Windows stat fuctions do not determine posix filemode.
*/
static int native_stat = 1;
+extern int trust_executable_bit;
static int git_cygwin_config(const char *var, const char *value, void *cb)
{
- if (!strcmp(var, "core.ignorecygwinfstricks"))
+ if (!strcmp(var, "core.filemode"))
+ trust_executable_bit = git_config_bool(var, value);
+ else if (!strcmp(var, "core.ignorecygwinfstricks"))
native_stat = git_config_bool(var, value);
return 0;
}
@@ -105,8 +110,13 @@ static int init_stat(void)
{
if (have_git_dir()) {
git_config(git_cygwin_config, NULL);
- cygwin_stat_fn = native_stat ? cygwin_stat : stat;
- cygwin_lstat_fn = native_stat ? cygwin_lstat : lstat;
+ if (!trust_executable_bit && native_stat) {
+ cygwin_stat_fn = cygwin_stat;
+ cygwin_lstat_fn = cygwin_lstat;
+ } else {
+ cygwin_stat_fn = stat;
+ cygwin_lstat_fn = lstat;
+ }
return 0;
}
return 1;
--
1.6.0.2.535.g81f8.dirty
^ permalink raw reply related
* Re: [PATCH] Introduce core.keepHardLinks
From: Shawn O. Pearce @ 2008-10-12 18:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0810111344241.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> When a tracked file was hard linked, we used to break the hard link
> whenever Git writes to that file. Make that optional.
Why would anyone want to do this?
I cannot fathom why a user wants this much rope to hang themselves
with...
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 173386e..7bfe431 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -207,6 +207,10 @@ core.symlinks::
> file. Useful on filesystems like FAT that do not support
> symbolic links. True by default.
>
> +core.keepHardLinks::
> + If true, do not break hard links by deleting and recreating the
> + files. Off by default.
> +
> core.gitProxy::
> A "proxy command" to execute (as 'command host port') instead
> of establishing direct connection to the remote server when
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Uwe Kleine-König @ 2008-10-12 18:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <20081010165952.GI8203@spearce.org>
On Fri, Oct 10, 2008 at 09:59:52AM -0700, Shawn O. Pearce wrote:
> If the caller supplies --tags they want the lightweight, unannotated
> tags to be searched for a match. If a lightweight tag is closer
> in the history, it should be matched, even if an annotated tag is
> reachable further back in the commit chain.
>
> The same applies with --all when matching any other type of ref.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> This come out of the discussions earlier last week, where folks
> were confused about the meaning of --tags and wanted to see it
> behave as they expected, which was to match the nearest tag,
> no matter its "type".
>
> The code is unchanged from what I sent out before, but now it has
> updated test vectors and a commit message.
>
> Thoughts?
As I already told earlier, this is exactly how I would expect it.
> static int debug; /* Display lots of verbose info */
> -static int all; /* Default to annotated tags only */
> -static int tags; /* But allow any tags if --tags is specified */
> +static int all; /* Any valid ref can be used */
> +static int tags; /* Either lightweight or annotated tags */
Maybe the last comment should better read:
/* allow lightweight tags */
? Apart from this one nitpick:
Acked-By: Uwe Kleine-König <ukleinek@strlen.de>
Thanks
Uwe
^ permalink raw reply
* Re: [PATCH v2] correct verify_path for Windows
From: Alex Riesen @ 2008-10-12 18:18 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Johannes Sixt, Joshua Juran, Giovanni Funchal, git,
Shawn O. Pearce
In-Reply-To: <20081012135048.GC21650@dpotapov.dyndns.org>
Dmitry Potapov, Sun, Oct 12, 2008 15:50:48 +0200:
> On Sun, Oct 12, 2008 at 12:58:52AM +0200, Alex Riesen wrote:
> > 2008/10/11 Dmitry Potapov <dpotapov@gmail.com>:
> > >> > + /* On Windows, file names are case-insensitive */
> > >> > + case 'G':
> > >> > + if ((rest[1]|0x20) != 'i')
> > >> > + break;
> > >> > + if ((rest[2]|0x20) != 't')
> > >> > + break;
> > >>
> > >> We have tolower().
> > >
> > > I am aware of that, but I am not sure what we gain by using it. It seems
> > > it makes only code bigger and slow.
> >
> > It does? Care to look into git-compat-util.h?
>
> As a matter of fact, I did, and I see the following:
>
> #define sane_istest(x,mask) ((sane_ctype[(unsigned char)(x)] & (mask)) != 0)
> #define tolower(x) sane_case((unsigned char)(x), 0x20)
>
> static inline int sane_case(int x, int high)
> {
> if (sane_istest(x, GIT_ALPHA))
> x = (x & ~0x20) | high;
> return x;
> }
>
> So, it looks like an extra look up and an extra comparison here.
Does not look like much more code. But:
> > BTW, is it such a critical path?
>
> I am not sure whether it is critical or not. It is called for each
> name in path. So, if you have a long path, it may be called quite a
> few times per a single path. Also, some operation such 'git add' can
> call verify_path() more than once (IIRC, it was called thrice per each
> added file). But I have no numbers to tell whether it is noticeable or
> not.
I looked at the callers (briefly). Performance could be a problem: add
and checkout can work with real big file lists and long pathnames.
So ok, than. It is critical.
^ permalink raw reply
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Andreas Ericsson @ 2008-10-12 18:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <20081012180040.GC4856@spearce.org>
Shawn O. Pearce wrote:
> Andreas Ericsson <ae@op5.se> wrote:
>> Shawn O. Pearce wrote:
>>> If the caller supplies --tags they want the lightweight, unannotated
>>> tags to be searched for a match. If a lightweight tag is closer
>>> in the history, it should be matched, even if an annotated tag is
>>> reachable further back in the commit chain.
>>>
>>> The same applies with --all when matching any other type of ref.
>>>
>> In 99% of the cases, "--all" will then give back the currently
>> checked out branch unless a revision is specified, right?
>
> Yup.
>
> `git describe --all` or `git describe --all HEAD`
>
> would kick back the current branch you have checked out, assuming
> you have a real branch under refs/heads and not some detached HEAD.
>
> IMHO, that's what the user asked for.
>
True. I think this will raise questions of its usability though,
in particular if it considers remote branches too.
Otoh, I've never seen the use for "git describe --all" earlier
either, so I guess I think differently from those who want this
feature.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Fwd: git status options feature suggestion
From: Shawn O. Pearce @ 2008-10-12 18:05 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Michael J Gruber, Johannes Schindelin,
Caleb Cushing, git
In-Reply-To: <20081012064512.GA32597@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:
>
> > And just make it mimic whatever folks accustomed to "svn st" would expect,
> > modulo we would need two status letters to signal difference between
> > (HEAD, index), and (index, worktree). Perhaps three if you want to show
> > difference between (HEAD, worktree) while at it.
>
> I remember a long time ago you started on a parallel diff walker that
> could diff the working tree, the index, and a tree at once. Do you
> remember the issues with it?
>
> I think that would be the right tool here to show each file only once,
> but with multiple status flags. Something like:
>
> A M foo
I have a tool that I'll be open-sourcing later this year, but it does
something like that:
project foo/ branch master
Am foo
M- bar
R- orig => dest ( 95%)
Line coloring is red on lines with unstaged stuff in the working
directory (3rd column, lower case letters) and green on lines that
are fully staged (3rd column is a '-').
The tool is in Python, but I'm just scraping the output of
`diff-index -M --cached HEAD` and diff-files to get that
display. The status letters are exactly those given out by
diff-index/diff-files, but the diff-files output is lowercased.
Scott Chacon has seen the tool output and likes it; there's a tech
talk that will be posted on YouTube soon where he and I are sort
of talking about it.
Sorry I can't say too much more about it yet. But I'm trying to
say that both Scott and I like a denser display like this.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] describe: Make --tags and --all match lightweight tags more often
From: Shawn O. Pearce @ 2008-10-12 18:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Junio C Hamano, Pierre Habouzit, Erez Zilber
In-Reply-To: <48F12CF8.505@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Shawn O. Pearce wrote:
>> If the caller supplies --tags they want the lightweight, unannotated
>> tags to be searched for a match. If a lightweight tag is closer
>> in the history, it should be matched, even if an annotated tag is
>> reachable further back in the commit chain.
>>
>> The same applies with --all when matching any other type of ref.
>>
>
> In 99% of the cases, "--all" will then give back the currently
> checked out branch unless a revision is specified, right?
Yup.
`git describe --all` or `git describe --all HEAD`
would kick back the current branch you have checked out, assuming
you have a real branch under refs/heads and not some detached HEAD.
IMHO, that's what the user asked for.
--
Shawn.
^ permalink raw reply
* Re: tip tree clone fail
From: Shawn O. Pearce @ 2008-10-12 17:59 UTC (permalink / raw)
To: Jakub Narebski
Cc: Ingo Molnar, Petr Baudis, H. Peter Anvin, Wang Chen,
Thomas Gleixner, FNST-Lai Jiangshan, FJ-KOSAKI Motohiro, git,
Junio C Hamano
In-Reply-To: <m3tzbhk94k.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> Ingo Molnar <mingo@elte.hu> writes:
>
> > Soapbox: in fact it would be outright stupid to limit the kernel
> > source's availability artificially by not making HTTP a tier-one access
> > method.
>
> Hopefully there should soon be here "smart" HTTP server [...]
>
> It is WIP, but I'm not sure how far it is from completion.
Its still not even prototyped. I'm supposed to be spending my 20%
time at Google on the Git-in-HTTP documentation and implementation,
so I can feed patches to the list for review.
Sadly, my current 80% project has been demanding >120% of my time
these past 5 weeks, so I have not been able to touch the Git-in-HTTP
concept in that time period.
Most of my 80% project has to be wrapped up by this time next
week. Afterwards I'm going to try and dedicate at least a week
to Git-in-HTTP and get caught up. I sort of have to; its part of
my goals for my performance evaluation. Even if the list winds
up rejecting my implementation, I still have to put it out there
for discussion.
--
Shawn.
^ permalink raw reply
* Re: tip tree clone fail
From: Jakub Narebski @ 2008-10-12 17:37 UTC (permalink / raw)
To: Ingo Molnar
Cc: Petr Baudis, H. Peter Anvin, Wang Chen, Thomas Gleixner,
FNST-Lai Jiangshan, FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012165954.GA2317@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Soapbox: in fact it would be outright stupid to limit the kernel
> source's availability artificially by not making HTTP a tier-one access
> method.
>
> Fighting against HTTP-only firewalls is like constantly pointing it out
> to the popular press that they should say 'cracker' instead of 'hacker'.
> It is pointless and only hurts the availability our own project.
Hopefully there should soon be here "smart" HTTP server (as for
example CGI script), which encapsulates git protocol, modified for the
fact that HTTP is stateless protocol, in HTTP. It would unfortunately
require git installed on server.
It is WIP, but I'm not sure how far it is from completion.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: tip tree clone fail
From: Ingo Molnar @ 2008-10-12 16:59 UTC (permalink / raw)
To: Petr Baudis
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012153952.GV10544@machine.or.cz>
* Petr Baudis <pasky@suse.cz> wrote:
> On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
> > hm, -tip's .git/hooks/post-update already contained this, for the last 2
> > months:
> >
> > exec git update-server-info
> >
> > so ... _despite_ us having this in the git repo, the HTTP protocol still
> > does not work. Why?
>
> I think your problem is that HTTP does not know where to look for
> objects coming from alternates; IIRC this would work if you used
> relative paths in objects/info/alternates, or you can create
> objects/info/http-alternates like
>
> /pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
> /pub/scm/linux/kernel/git/sfr/linux-next.git/objects
ok, i've now set it up like this:
$ pwd
/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git
$ cat objects/info/alternates
/home/ftp/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/home/ftp/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
$ cat objects/info/http-alternates
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
and i've added "git update-server-info" to hooks/post-receive and made
it chmod +x.
that should be golden, right? I'm wondering why this isnt in the default
setup - i've been behind a limited corporate firewall in a former life
and having HTTP access is indeed very handy and pragmatic. Often hotel
WLANs are HTTP only as well.
Soapbox: in fact it would be outright stupid to limit the kernel
source's availability artificially by not making HTTP a tier-one access
method.
Fighting against HTTP-only firewalls is like constantly pointing it out
to the popular press that they should say 'cracker' instead of 'hacker'.
It is pointless and only hurts the availability our own project.
Ingo
^ permalink raw reply
* [PATCH] Teach/Fix git-pull/git-merge --quiet and --verbose
From: Tuncer Ayaz @ 2008-10-12 16:54 UTC (permalink / raw)
To: git
After fixing clone -q I noticed that pull -q is does not do what
it's supposed to do and implemented --quiet/--verbose by
adding it to builtin-merge and fixing two places in builtin-fetch.
I have not touched/adjusted contrib/completion/git-completion.bash
but can take a look if wanted. I think it needs one or two adjustions
anyway caused by recent --OPTIONS changes in master.
I've tested the following invocations with the below changes applied:
$ git pull
$ git pull -q
$ git pull -v
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 ++++++
builtin-fetch.c | 5 ++-
builtin-merge.c | 52 +++++++++++++++++++++++---------------
git-pull.sh | 10 +++++--
4 files changed, 49 insertions(+), 26 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..b5c2885 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -372,12 +372,13 @@ static int store_updated_refs(const char *url,
const char *remote_name,
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if ((verbose || !quiet) && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if(verbose || !quiet)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
diff --git a/builtin-merge.c b/builtin-merge.c
index 38266ba..1f601d4 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -44,6 +44,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, option_log, squash;
static int option_commit = 1, allow_fast_forward = 1;
static int allow_trivial = 1, have_message;
+static int quiet, verbose;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
static unsigned char head[20], stash[20];
@@ -101,7 +102,7 @@ static struct strategy *get_strategy(const char *name)
struct cmdname *ent = main_cmds.names[i];
for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
if (!strncmp(ent->name, all_strategy[j].name, ent->len)
- && !all_strategy[j].name[ent->len])
+ && !all_strategy[j].name[ent->len])
found = 1;
if (!found)
add_cmdname(¬_strategies, ent->name, ent->len);
@@ -152,6 +153,8 @@ static int option_parse_n(const struct option *opt,
}
static struct option builtin_merge_options[] = {
+ OPT__QUIET(&quiet),
+ OPT__VERBOSE(&verbose),
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
"do not show a diffstat at the end of the merge",
PARSE_OPT_NOARG, option_parse_n },
@@ -250,7 +253,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if(verbose || !quiet)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -262,7 +266,8 @@ static void squash_message(void)
struct commit_list *j;
int fd;
- printf("Squash commit -- not updating HEAD\n");
+ if(verbose || !quiet)
+ printf("Squash commit -- not updating HEAD\n");
fd = open(git_path("SQUASH_MSG"), O_WRONLY | O_CREAT, 0666);
if (fd < 0)
die("Could not write to %s", git_path("SQUASH_MSG"));
@@ -282,18 +287,20 @@ static void squash_message(void)
if (prepare_revision_walk(&rev))
die("revision walk setup failed");
- strbuf_init(&out, 0);
- strbuf_addstr(&out, "Squashed commit of the following:\n");
- while ((commit = get_revision(&rev)) != NULL) {
- strbuf_addch(&out, '\n');
- strbuf_addf(&out, "commit %s\n",
- sha1_to_hex(commit->object.sha1));
- pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
- NULL, NULL, rev.date_mode, 0);
+ if(verbose || !quiet) {
+ strbuf_init(&out, 0);
+ strbuf_addstr(&out, "Squashed commit of the following:\n");
+ while ((commit = get_revision(&rev)) != NULL) {
+ strbuf_addch(&out, '\n');
+ strbuf_addf(&out, "commit %s\n",
+ sha1_to_hex(commit->object.sha1));
+ pretty_print_commit(rev.commit_format, commit, &out, rev.abbrev,
+ NULL, NULL, rev.date_mode, 0);
+ }
+ write(fd, out.buf, out.len);
+ close(fd);
+ strbuf_release(&out);
}
- write(fd, out.buf, out.len);
- close(fd);
- strbuf_release(&out);
}
static int run_hook(const char *name)
@@ -333,14 +340,15 @@ static void finish(const unsigned char
*new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if(verbose || !quiet)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if ((verbose || !quiet) && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -877,6 +885,8 @@ int cmd_merge(int argc, const char **argv, const
char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if(!verbose && quiet)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1019,11 +1029,11 @@ int cmd_merge(int argc, const char **argv,
const char *prefix)
char hex[41];
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
-
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if(verbose || !quiet)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_init(&msg, 0);
strbuf_addstr(&msg, "Fast forward");
if (have_message)
diff --git a/git-pull.sh b/git-pull.sh
index 75c3610..d84ceb5 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+quiet= verbose= strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ quiet=-q ;;
+ -v|--verbose)
+ verbose=-v ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbose $quiet --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
@@ -181,5 +185,5 @@ merge_name=$(git fmt-merge-msg $log_arg
<"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
+exec git-merge $quiet $verbose $no_stat $no_commit $squash $no_ff
$log_arg $strategy_args \
"$merge_name" HEAD $merge_head
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH 2/2 v2] check-attr: Add --stdin-paths option
From: Dmitry Potapov @ 2008-10-12 16:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shawn O. Pearce
In-Reply-To: <gct3lk$s16$1@ger.gmane.org>
On Sun, Oct 12, 2008 at 05:04:21PM +0200, Jakub Narebski wrote:
> Dmitry Potapov wrote:
>
> >> And since its being
> >> used mostly by automated tools (gitk/git-gui) I wonder if a -z should
> >> also be supported for input termination with NUL instead of LF.
> >
> > I have added it, but after I did, I start to wonder whether it is the
> > right thing to do to unquote NUL terminated input line?
>
> I think that -z should be not quoted (like git-diff-tree or git-ls-tree
> _output_); if it is, then IMHO it is a bug.
I am sorry. I was obviously wrong about 'git checkout-index', as it does
not try to unquote if '-z' is specified. So, my previous patch was wrong.
The corrected patch is below.
It still uses the same output format whether '-z' is specified or not.
Maybe I should change that too to use '\0' as the separator if '-z' is
specified?
Dmitry
PS Please, add me to 'To:' or 'Cc:' when you reply to my email.
-- >8 --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Sun, 12 Oct 2008 18:08:43 +0400
Subject: [PATCH] check-attr: Add --stdin option
---
This patch is meant to be squash on top of dp/checkattr in pu.
Documentation/git-check-attr.txt | 8 ++++++--
builtin-check-attr.c | 15 ++++++++++-----
t/t0003-attributes.sh | 2 +-
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-check-attr.txt b/Documentation/git-check-attr.txt
index 0839a57..14e4374 100644
--- a/Documentation/git-check-attr.txt
+++ b/Documentation/git-check-attr.txt
@@ -9,7 +9,7 @@ git-check-attr - Display gitattributes information.
SYNOPSIS
--------
'git check-attr' attr... [--] pathname...
-'git check-attr' --stdin-paths attr... < <list-of-paths
+'git check-attr' --stdin [-z] attr... < <list-of-paths
DESCRIPTION
-----------
@@ -18,9 +18,13 @@ For every pathname, this command will list if each attr is 'unspecified',
OPTIONS
-------
---stdin-paths::
+--stdin::
Read file names from stdin instead of from the command-line.
+-z::
+ Only meaningful with `--stdin`; paths are separated with
+ NUL character instead of LF.
+
\--::
Interpret all preceding arguments as attributes, and all following
arguments as path names. If not supplied, only the first argument will
diff --git a/builtin-check-attr.c b/builtin-check-attr.c
index fa1e4d5..4921341 100644
--- a/builtin-check-attr.c
+++ b/builtin-check-attr.c
@@ -7,12 +7,16 @@
static int stdin_paths;
static const char * const check_attr_usage[] = {
"git check-attr attr... [--] pathname...",
-"git check-attr --stdin-paths attr... < <list-of-paths>",
+"git check-attr --stdin attr... < <list-of-paths>",
NULL
};
+static int null_term_line;
+
static const struct option check_attr_options[] = {
- OPT_BOOLEAN(0 , "stdin-paths", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN(0 , "stdin", &stdin_paths, "read file names from stdin"),
+ OPT_BOOLEAN('z', NULL, &null_term_line,
+ "input paths are terminated by a null character"),
OPT_END()
};
@@ -41,11 +45,12 @@ static void check_attr_stdin_paths(int cnt, struct git_attr_check *check,
const char** name)
{
struct strbuf buf, nbuf;
+ int line_termination = null_term_line ? 0 : '\n';
strbuf_init(&buf, 0);
strbuf_init(&nbuf, 0);
- while (strbuf_getline(&buf, stdin, '\n') != EOF) {
- if (buf.buf[0] == '"') {
+ while (strbuf_getline(&buf, stdin, line_termination) != EOF) {
+ if (line_termination && buf.buf[0] == '"') {
strbuf_reset(&nbuf);
if (unquote_c_style(&nbuf, buf.buf, NULL))
die("line is badly quoted");
@@ -90,7 +95,7 @@ int cmd_check_attr(int argc, const char **argv, const char *prefix)
if (cnt <= 0)
errstr = "No attribute specified";
else if (stdin_paths && doubledash < argc)
- errstr = "Can't specify files with --stdin-paths";
+ errstr = "Can't specify files with --stdin";
if (errstr) {
error (errstr);
usage_with_options(check_attr_usage, check_attr_options);
diff --git a/t/t0003-attributes.sh b/t/t0003-attributes.sh
index f6901b4..1c77192 100755
--- a/t/t0003-attributes.sh
+++ b/t/t0003-attributes.sh
@@ -60,7 +60,7 @@ a/b/h: test: a/b/h
a/b/d/g: test: a/b/d/*
EOF
- sed -e "s/:.*//" < expect | git check-attr --stdin-paths test > actual &&
+ sed -e "s/:.*//" < expect | git check-attr --stdin test > actual &&
test_cmp expect actual
'
--
1.6.0.2.521.g739d3
-- >8 --
^ permalink raw reply related
* Re: tip tree clone fail
From: Petr Baudis @ 2008-10-12 15:39 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012152427.GA4607@elte.hu>
On Sun, Oct 12, 2008 at 05:24:27PM +0200, Ingo Molnar wrote:
> hm, -tip's .git/hooks/post-update already contained this, for the last 2
> months:
>
> exec git update-server-info
>
> so ... _despite_ us having this in the git repo, the HTTP protocol still
> does not work. Why?
I think your problem is that HTTP does not know where to look for
objects coming from alternates; IIRC this would work if you used
relative paths in objects/info/alternates, or you can create
objects/info/http-alternates like
/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects
/pub/scm/linux/kernel/git/sfr/linux-next.git/objects
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: tip tree clone fail
From: Teemu Likonen @ 2008-10-12 15:36 UTC (permalink / raw)
To: Ingo Molnar
Cc: H. Peter Anvin, Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <20081012152427.GA4607@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * H. Peter Anvin <hpa@zytor.com> wrote:
>> post-update, rather than post-receive.
>>
>> The standard post-update.sample contains it, it just needs a rename.
>
> hm, -tip's .git/hooks/post-update already contained this, for the last 2
> months:
>
> exec git update-server-info
>
> so ... _despite_ us having this in the git repo, the HTTP protocol
> still does not work. Why?
I don't know why but I have experienced the same: post-update hook just
doesn't work. I described it here:
http://thread.gmane.org/gmane.comp.version-control.git/82351
Fortunately post-receive hooks works, so you could to try it instead.
^ permalink raw reply
* Re: tip tree clone fail
From: Ingo Molnar @ 2008-10-12 15:24 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Wang Chen, Thomas Gleixner, FNST-Lai Jiangshan,
FJ-KOSAKI Motohiro, git, Junio C Hamano
In-Reply-To: <48F20663.2040407@zytor.com>
* H. Peter Anvin <hpa@zytor.com> wrote:
> Ingo Molnar wrote:
>> * H. Peter Anvin <hpa@zytor.com> wrote:
>>
>>> Wang Chen wrote:
>>>>> So http transport is wreckaged. (git version 1.6.0.1 here, Wang is using
>>>>> 1.5.3.x)
>>>> My git version is 1.5.5.1, although it doesn't matter ;)
>>>>
>>> http transport requires that "git update-server-info" is done after
>>> each push. Otherwise, it ends up in a trainwreck.
>>
>> can i simply put "git update-server-info" into .git/hooks/post-receive
>> to solve this problem?
>>
>
> post-update, rather than post-receive.
>
> The standard post-update.sample contains it, it just needs a rename.
hm, -tip's .git/hooks/post-update already contained this, for the last 2
months:
exec git update-server-info
so ... _despite_ us having this in the git repo, the HTTP protocol still
does not work. Why?
Ingo
^ permalink raw reply
* [StGit PATCH 4/4] Tutorial: Write about rebasing
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 84 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 83 insertions(+), 1 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 46c78cf..2808462 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -533,7 +533,89 @@ index e324179..6398958 100644
Rebasing a patch series
-----------------------
-TODO:: rebase, ...
+While you are busy writing, submitting, and revising your patch
+series, other people will be doing the same thing. As a result, even
+though you started writing your patches on top of what was the latest
+history at the time, your stack base will grow ever more out of date.
+
+When you clone a repository,
+
+ $ stg clone http://homepage.ntlworld.com/cmarinas/stgit.git stgit
+
+you initially get one local branch, +master+. You also get a number of
+'remote' branches, one for each branch in the repository you cloned.
+In the case of the StGit repository, these are
++remotes/origin/stable+, +remotes/origin/master+, and
++remotes/origin/proposed+. +remotes+ means that it's not a local
+branch, just a snapshot of a branch in another repository; and
++origin+ is the default name for the first remote repository (you can
+set up more; see the man page for +git remote+).
+
+Right after cloning, +master+ and +remotes/origin/master+ point at the
+same commit. When you start writing patches, +master+ will advance,
+and always point at the current topmost patch, but
++remotes/origin/master+ will stay the same because it represents the
+master branch in the repository you cloned from -- your 'upstream'
+repository.
+
+Unless you are the only one working on the project, however, the
+upstream repository will not stay the same forever. New commits will
+be added to its branches; to update your clone, run
+
+ $ git remote update
+
+This will update all your remote branches, but won't touch your local
+branches. To get the latest changes into your local +master+ branch,
+use stglink:rebase[]:
+
+ $ stg rebase remotes/origin/master
+
+This command will do three things:
+
+ 1. Pop all patches, so that your local branch (+master+, in this
+ example) points at the stack base. This is the same commit that
+ +remotes/origin/master+ pointed at at the time you started
+ writing your patches.
+
+ 2. Set the stack base to the given commit (the current, updated
+ value of +remotes/origin/master+).
+
+ 3. Push the patches that were popped in the first step.
+
+The end result is that your patches are now applied on top of the
+latest version of +remotes/origin/master+.
+
+The primary reason for rebasing is to reduce the amount of conflicts
+between your work and others'. If one of your patches changes the same
+part of the same file as a patch someone else has written, you will
+get a conflict when you run stglink:rebase[] the next time after the
+other person's patch has been accepted upstream. It is almost always
+less work to rebase often and resolve these one at a time, rather than
+a whole lot at once. After all, you have to rebase eventually; if you
+mail out patches that are based on an outdated branch, everyone who
+tries to apply them has to resolve the conflicts instead. There are
+more effective ways to get popular.
+
+
+When your patches are accepted
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+If and when some or all of your patches are accepted upstream, you
+update and rebase just like usual -- but be sure to use the
++$$--merged$$+ flag to stglink:rebase[]:
+
+ $ git remote update
+ $ stg rebase --merged remotes/origin/master
+
+This flag makes the rebase operation better at detecting that your
+patches have been merged, at some cost in performance.
+
+The patches that had been merged will still be present in your patch
+stack after the rebase, but they will be empty, since the change they
+added is now already present in the stack base. Run stglink:clean[] to
+get rid of such empty patches if you don't want them hanging around:
+
+ $ stg clean
Importing patches
^ permalink raw reply related
* [StGit PATCH 3/4] Tutorial: Cover "stg mail"
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 100 ++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 96 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index e9d8b22..46c78cf 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -431,17 +431,109 @@ patches as patches.
Workflow: Tracking branch
=========================
+In the 'Development branch' workflow described above, we didn't have
+to worry about other people; we're working on our branch, they are
+presumably working on theirs, and when the time comes and we're ready
+to publish our branch, we'll probably end up merging our branch with
+those other peoples'. That's how Git is designed to work.
-Rebasing a patch series
------------------------
+Or rather, one of the ways Git is designed to work. An alternative,
+popular in e.g. the Linux kernel community (for which Git was
+originally created), is that contributors send their patches by e-mail
+to a mailing list. Others read the patches, try them out, and provide
+feedback; often, the patch author is asked to send a new and improved
+version of the patches. Once the project maintainer is satisfied that
+the patches are good, she'll 'apply' them to a branch and publish it.
-TODO:: rebase, ...
+StGit is ideally suited for the process of creating patches, mailing
+them out for review, revising them, mailing them off again, and
+eventually getting them accepted.
Getting patches upstream
------------------------
-TODO:: export, mail, ...
+We've already covered how to clone a Git repository and start writing
+patches. As for the next step, there are two commands you might use to
+get patches out of StGit: stglink:mail[] and stglink:export[].
+stglink:export[] will export your patches to a filesystem directory as
+one text file per patch, which can be useful if you are going to send
+the patches by something other than e-mail. Most of the time, though,
+stglink:mail[] is what you want.
+
+NOTE: Git comes with tools for sending commits via e-mail. Since StGit
+patches are Git commits, you can use the Git tools if you like them
+better for some reason.
+
+NOTE: For exporting single patches -- as opposed to a whole bunch of
+them -- you could also use stglink:show[] or stglink:diff[].
+
+Mailing a patch is as easy as this:
+
+ $ stg mail --to recipient@example.com <patches>
+
+You can list one or more patches, or ranges of patches. Each patch
+will be sent as a separate mail, with the first line of the commit
+message as subject line. Try mailing patches to yourself to see what
+the result looks like.
+
+NOTE: stglink:mail[] uses +sendmail+ on your computer to send the
+mails. If you don't have +sendmail+ properly set up, you can instruct
+it to use any SMTP server with the +$$--smtp-server$$+ flag.
+
+There are many command-line options to control exactly how mails are
+sent, as well as a message template you can modify if you want. The
+man page has all the details; I'll just mention two more here.
+
++$$--edit-cover$$+ will open an editor and let you write an
+introductory message; all the patch mails will then be sent as replies
+to this 'cover message'. This is usually a good idea if you send more
+than one patch, so that reviewers can get a quick overview of the
+patches you sent.
+
++$$--edit-patches$$+ will let you edit each patch before it is sent.
+You can change anything, but note that you are only editing the
+outgoing mail, not the patch itself; if you want to make changes to
+the patch, you probably want to use the regular StGit commands to do
+so. What this 'is' useful for, though, is to add notes for the patch
+recipients:
+
+----------------------------------------------------------------------
+From: Audrey U. Thor <author@example.com>
+Subject: [PATCH] First line of the commit message
+
+The rest of the commit message
+
+---
+
+Everything after the line with the three dashes and before the diff is
+just a comment, and not part of the commit message. If there's
+anything you want the patch recipients to see, but that shouldn't be
+recorded in the history if the patch is accepted, write it here.
+
+ stgit/main.py | 1 +
+ 1 files changed, 1 insertions(+), 0 deletions(-)
+
+
+diff --git a/stgit/main.py b/stgit/main.py
+index e324179..6398958 100644
+--- a/stgit/main.py
++++ b/stgit/main.py
+@@ -171,6 +171,7 @@ def _main():
+ sys.exit(ret or utils.STGIT_SUCCESS)
+
+ def main():
++ print 'My first patch!'
+ try:
+ _main()
+ finally:
+----------------------------------------------------------------------
+
+
+Rebasing a patch series
+-----------------------
+
+TODO:: rebase, ...
Importing patches
^ permalink raw reply related
* [StGit PATCH 2/4] Tutorial: Explain diffs a little bit better
From: Karl Hasselström @ 2008-10-12 15:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20081012150825.17648.3315.stgit@yoghurt>
Say that we use unified diffs, and point to the Wikipedia article
about them. We should probably explain this in more detail ourselves
when we get a proper user guide; but for the tutorial, this is
probably enough.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
Documentation/tutorial.txt | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt
index 103f3e4..e9d8b22 100644
--- a/Documentation/tutorial.txt
+++ b/Documentation/tutorial.txt
@@ -103,10 +103,11 @@ And voilà -- the patch is no longer empty:
_main()
finally:
-(I'm assuming you're already familiar with patches like this from Git,
-but it's really quite simple; in this example, I've added the +$$print
-'My first patch!'$$+ line to the file +stgit/main.py+, at around line
-171.)
+(I'm assuming you're already familiar with
+htmllink:http://en.wikipedia.org/wiki/Diff#Unified_format[unified
+diff] patches like this from Git, but it's really quite simple; in
+this example, I've added the +$$print 'My first patch!'$$+ line to the
+file +stgit/main.py+, at around line 171.)
Since the patch is also a regular Git commit, you can also look at it
with regular Git tools such as manlink:gitk[].
^ permalink raw reply related
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