* [PATCH] Document that using -M without other diff options is not a good idea
From: Miklos Vajna @ 2007-11-01 14:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just noticed that I used 'git log -M' in some scripts which is obviously bad.
People should not use that option without other diff options.
Documentation/diff-options.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index b1f528a..ed827f8 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -92,7 +92,9 @@
Break complete rewrite changes into pairs of delete and create.
-M::
- Detect renames.
+ Detect renames. It's no good using this option if you don't use diff
+ options like `--name-status`, `-p` or `--stat` as it will just slow
+ down the revision walker.
-C::
Detect copies as well as renames. See also `--find-copies-harder`.
--
1.5.3.5
^ permalink raw reply related
* [PATCH] Include diff options in the git-log manpage
From: Miklos Vajna @ 2007-11-01 14:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <1193929060-6183-1-git-send-email-vmiklos@frugalware.org>
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Recently I wanted to see what git log -M does but actually I was not able to
find it in the manpage, finally figured out that all the diff options are
missing from here.
Removing -p as it's already in diff-options.txt.
If this patch OK, then I would like to send a similar patch to
git-rev-list.txt, too.
Documentation/git-log.txt | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 5ec547c..4b1b982 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -27,6 +27,8 @@ OPTIONS
include::pretty-options.txt[]
+include::diff-options.txt[]
+
-<n>::
Limits the number of commits to show.
@@ -43,9 +45,6 @@ include::pretty-options.txt[]
commit. This option gives a better overview of the
evolution of a particular branch.
--p::
- Show the change the commit introduces in a patch form.
-
-g, \--walk-reflogs::
Show commits as they were recorded in the reflog. The log contains
a record about how the tip of a reference was changed.
--
1.5.3.5
^ permalink raw reply related
* Re: Where man git-format-patch sends me?
From: Johannes Schindelin @ 2007-11-01 14:38 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87lk9i2hkc.fsf@osv.gnss.ru>
Hi,
On Thu, 1 Nov 2007, Sergei Organov wrote:
> $ man git-format-patch
> [...]
> OPTIONS
> -p Generate patch (see section on generating patches)
>
> -u Synonym for "-p".
As you can easily see from Documentation/git-format-patch.txt, this part
is generated from the file Documentation/diff-options.txt.
Hth,
Dscho
^ permalink raw reply
* (unknown)
From: Heikki Orsila @ 2007-11-01 14:23 UTC (permalink / raw)
To: git
>From bd2d661c565062eacc80dda90f3978303308f9bb Mon Sep 17 00:00:00 2001
From: Heikki Orsila <heikki.orsila@iki.fi>
Date: Thu, 1 Nov 2007 16:21:39 +0200
Subject: [PATCH] Make git-clone obey "--" (end argument parsing)
---
Documentation/git-clone.txt | 2 +-
git-clone.sh | 5 ++++-
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 253f4f0..7fdcd42 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git-clone' [--template=<template_directory>]
[-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
- [--depth <depth>] <repository> [<directory>]
+ [--depth <depth>] [--] <repository> [<directory>]
DESCRIPTION
-----------
diff --git a/git-clone.sh b/git-clone.sh
index 0ea3c24..3f00693 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -14,7 +14,7 @@ die() {
}
usage() {
- die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]"
+ die "Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] [--] <repo> [<dir>]"
}
get_repo_base() {
@@ -160,6 +160,9 @@ while
*,--depth)
shift
depth="--depth=$1";;
+ *,--)
+ shift
+ break ;;
*,-*) usage ;;
*) break ;;
esac
--
1.5.3.4.498.g9c514-dirty
^ permalink raw reply related
* Re: [PATCH] git-filter-branch.txt: fix a typo.
From: Johannes Schindelin @ 2007-11-01 14:29 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87r6ja2j5w.fsf@osv.gnss.ru>
Hi,
On Thu, 1 Nov 2007, Sergei Organov wrote:
> -The function 'skip_commits' is defined as follows:
> +The function 'skip_commit' is defined as follows:
Yeah, sorry.
Thanks,
Dscho
^ permalink raw reply
* Re: Newbie: report of first experience with git-rebase.
From: Johannes Schindelin @ 2007-11-01 14:24 UTC (permalink / raw)
To: Sergei Organov; +Cc: Junio C Hamano, git
In-Reply-To: <87ve8m2mfn.fsf@osv.gnss.ru>
Hi,
On Thu, 1 Nov 2007, Sergei Organov wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >> On Wed, 31 Oct 2007, Sergei Organov wrote:
> >>
> >>> Yes, and that's the problem. Why 'git --continue' didn't just skip this
> >>> patch that *already became no-op* after conflict resolution and forced
> >>> me to explicitly use 'git --skip' instead?
> >>
> >> Isn't that obvious? To prevent you from accidentally losing a commit.
> >
> > In case it is not obvious...
> >
> > A rebase conflict resolution that results in emptiness is a
> > rather rare event (especially because rebase drops upfront the
> > identical changes from the set of commits to be replayed), but
> > it does happen.
>
> Funny how 2 of my first 3 commits suffer from this "rather rare event",
> and it was not Friday, 13 ;)
They are rare events. In your case I guess that subtly different versions
were _actually_ applied (such as white space fixes), which is why such a
rare event hit you.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] git-format-patch.txt: fix explanation of an example.
From: Sergei Organov @ 2007-11-01 14:21 UTC (permalink / raw)
To: git
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/git-format-patch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index c9857a2..dc5e9ba 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -168,7 +168,7 @@ git-format-patch origin::
is created in the current directory.
git-format-patch \--root origin::
- Extract all commits which that leads to 'origin' since the
+ Extract all commits which lead to 'origin' since the
inception of the project.
git-format-patch -M -B origin::
--
1.5.3.4
^ permalink raw reply related
* Re: Question on git-filter-branch
From: Alex Riesen @ 2007-11-01 14:20 UTC (permalink / raw)
To: Mike Hommey; +Cc: Bill Lear, git
In-Reply-To: <20071101133440.GA17239@glandium.org>
Mike Hommey, Thu, Nov 01, 2007 14:34:41 +0100:
> On Thu, Nov 01, 2007 at 07:19:05AM -0600, Bill Lear wrote:
> > >Just remove .git/refs/original/
> >
> > Ok, thanks. But, how do I remove the subdirectory?
> >
> > % rm -rf .git/refs/original
> > % git filter-branch --index-filter 'git update-index --remove sensitive_stuff' HEAD
> > Rewrite 6711f6a50605918326f67ca0c3402eab9a4c8571 (8/8)
> > WARNING: Ref 'refs/heads/master' is unchanged
>
> git-update-index --remove will remove files, not trees, so you need to
> use something like
> git-ls-files ensitive_stuff | xargs -d "\n" git-update-index --remove
> instead.
git ls-files -z sensitive_stuff | git update-index --remove -z --stdin
^ permalink raw reply
* Re: [PATCH] Show total transferred as part of throughput progress display
From: Nicolas Pitre @ 2007-11-01 14:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20071101035704.GA4518@spearce.org>
On Wed, 31 Oct 2007, Shawn O. Pearce wrote:
> We now show the total amount of data we have transferred over
> the network as part of the throughput meter, organizing it in
> "human friendly" terms like `ls -h` would do. Users can glance at
> this, see that the total transferred size is about 3 MiB, see the
> throughput of X KiB/sec, and determine a reasonable figure of about
> when the clone will be complete, assuming they know the rough size
> of the source repository or are able to obtain it.
Well, OK. But...
> This is also a helpful indicator that there is progress being made
> even if we stall on a very large object. The thoughput meter may
> remain relatively constant and the percentage complete and object
> count won't be changing, but the total transferred will be increasing
> as additional data is received for this object.
Currently if the object count is unchanged for an extended period of
time, the display_progress() function isn't called at all, so the
updated byte count (and rate) won't be displayed either. This needs a
fix, probably in a separate patch which I'll send right away.
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Well, your patch has issues. Please see comments below.
> diff --git a/progress.c b/progress.c
> index 23ee9f3..5c95091 100644
> --- a/progress.c
> +++ b/progress.c
> @@ -11,7 +11,11 @@ struct throughput {
> unsigned int avg_misecs;
> unsigned int last_misecs[TP_IDX_MAX];
> unsigned int idx;
> - char display[20];
> + unsigned int unit_size;
> + unsigned int unit_index;
> + unsigned int total_units;
> + unsigned int curr_bytes;
> + char display[40];
> };
>
> struct progress {
> @@ -24,6 +28,7 @@ struct progress {
> struct throughput *throughput;
> };
>
> +static const char *units[] = {"bytes", "KiB", "MiB", "GiB"};
> static volatile sig_atomic_t progress_update;
>
> static void progress_interval(int signum)
> @@ -113,12 +118,27 @@ void display_throughput(struct progress *progress, unsigned long n)
>
> if (!tp) {
> progress->throughput = tp = calloc(1, sizeof(*tp));
> - if (tp)
> + if (tp) {
> tp->prev_tv = tv;
> + tp->unit_size = 1;
> + }
> return;
> }
>
> tp->count += n;
> + tp->curr_bytes += n;
> + if (tp->curr_bytes > tp->unit_size) {
> + tp->total_units += tp->curr_bytes / tp->unit_size;
> + tp->curr_bytes = tp->curr_bytes % tp->unit_size;
> +
> + while (tp->total_units >= 1024
> + && tp->unit_index < ARRAY_SIZE(units)) {
> + tp->curr_bytes += (tp->total_units % 1024) * tp->unit_size;
> + tp->total_units = tp->total_units / 1024;
> + tp->unit_size *= 1024;
> + tp->unit_index++;
> + }
> + }
This whole block could be moved inside the "if (misecs > 512)"
conditional. There is no point performing that computation over and
over when the display isn't updated more than twice a second anyway.
> @@ -143,7 +163,13 @@ void display_throughput(struct progress *progress, unsigned long n)
> tp->avg_bytes += tp->count;
> tp->avg_misecs += misecs;
> snprintf(tp->display, sizeof(tp->display),
> - ", %lu KiB/s", tp->avg_bytes / tp->avg_misecs);
> + ", %3u.%2.2u %s %lu KiB/s",
The line is becoming quite long already, and I'd prefer if remote
messages like the pack-objects summary kept overwriting it entirely
while this line is bumped to the next line on screen for a prettier
display. So I'd prefer if there wasn't so many spaces inserted there.
What about something like ", %u.%2.2u %s | %lu KiB/s" instead?
Also I think that displaying fractional bytes, even if it is always 0,
is a bit weird.
> + tp->total_units,
> + tp->unit_size > 1
> + ? tp->curr_bytes / (tp->unit_size / 100)
This has integer truncation problems. Suppose tp->unit_size = 1024 and
tp->curr_bytes = 1023. You get 1023 / (1024 / 100) = 102 while the
desired result should be 99.
Overall I think your patch is also needlessly too complex.
this could be implemented in a much simpler way, such as follows:
diff --git a/progress.c b/progress.c
index 34a5961..1212be8 100644
--- a/progress.c
+++ b/progress.c
@@ -15,13 +15,14 @@
struct throughput {
struct timeval prev_tv;
+ size_t total;
unsigned long count;
unsigned long avg_bytes;
unsigned long last_bytes[TP_IDX_MAX];
unsigned int avg_misecs;
unsigned int last_misecs[TP_IDX_MAX];
unsigned int idx;
- char display[20];
+ char display[32];
};
struct progress {
@@ -128,6 +129,7 @@ void display_throughput(struct progress *progress, unsigned long n)
return;
}
+ tp->total += n;
tp->count += n;
/*
@@ -149,11 +151,32 @@ void display_throughput(struct progress *progress, unsigned long n)
misecs += (int)(tv.tv_usec - tp->prev_tv.tv_usec) / 977;
if (misecs > 512) {
+ unsigned l = sizeof(tp->display);
tp->prev_tv = tv;
tp->avg_bytes += tp->count;
tp->avg_misecs += misecs;
- snprintf(tp->display, sizeof(tp->display),
- ", %lu KiB/s", tp->avg_bytes / tp->avg_misecs);
+
+ if (tp->total > 1 << 30) {
+ l -= snprintf(tp->display, l, ", %u.%2.2u GiB",
+ (int)(tp->total >> 30),
+ (int)(tp->total & ((1 << 30) - 1)) / 10737419);
+ } else if (tp->total > 1 << 20) {
+ l -= snprintf(tp->display, l, ", %u.%2.2u MiB",
+ (int)(tp->total >> 20),
+ ((int)(tp->total & ((1 << 20) - 1))
+ * 100) >> 20);
+ } else if (tp->total > 1 << 10) {
+ l -= snprintf(tp->display, l, ", %u.%2.2u KiB",
+ (int)(tp->total >> 10),
+ ((int)(tp->total & ((1 << 10) - 1))
+ * 100) >> 10);
+ } else {
+ l -= snprintf(tp->display, l, ", %u bytes",
+ (int)tp->total);
+ }
+ snprintf(tp->display + sizeof(tp->display) - l, l,
+ " | %lu KiB/s", tp->avg_bytes / tp->avg_misecs);
+
tp->avg_bytes -= tp->last_bytes[tp->idx];
tp->avg_misecs -= tp->last_misecs[tp->idx];
tp->last_bytes[tp->idx] = tp->count;
Nicolas
^ permalink raw reply related
* [PATCH] Do no colorify test output if stdout is not a terminal
From: Alex Riesen @ 2007-11-01 14:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
like when the output is redirected into a file in a cron job.
---
t/test-lib.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 714de6e..603a8cd 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -60,6 +60,7 @@ esac
# . ./test-lib.sh
[ "x$TERM" != "xdumb" ] &&
+ [ -t 1 ] &&
tput bold >/dev/null 2>&1 &&
tput setaf 1 >/dev/null 2>&1 &&
tput sgr0 >/dev/null 2>&1 &&
--
1.5.3.4.549.g2789
^ permalink raw reply related
* Where man git-format-patch sends me?
From: Sergei Organov @ 2007-11-01 13:58 UTC (permalink / raw)
To: git
$ man git-format-patch
[...]
OPTIONS
-p Generate patch (see section on generating patches)
-u Synonym for "-p".
[...]
$
1. Saying "-p generates patch" suggests that without -p git-format-patch
will generate something else. It's rather confusing.
2. Where is this "section on generating patches"? I thought it could be
in man git-diff, but it is not.
--
Sergei.
^ permalink raw reply
* Re: Question on git-filter-branch
From: Bill Lear @ 2007-11-01 13:54 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20071101133440.GA17239@glandium.org>
On Thursday, November 1, 2007 at 14:34:41 (+0100) Mike Hommey writes:
>On Thu, Nov 01, 2007 at 07:19:05AM -0600, Bill Lear wrote:
>> >Just remove .git/refs/original/
>>
>> Ok, thanks. But, how do I remove the subdirectory?
>>
>> % rm -rf .git/refs/original
>> % git filter-branch --index-filter 'git update-index --remove sensitive_stuff' HEAD
>> Rewrite 6711f6a50605918326f67ca0c3402eab9a4c8571 (8/8)
>> WARNING: Ref 'refs/heads/master' is unchanged
>
>git-update-index --remove will remove files, not trees, so you need to
>use something like
>git-ls-files ensitive_stuff | xargs -d "\n" git-update-index --remove
>instead.
Oh yeah, now we're cookin' with gas:
% git filter-branch --index-filter 'git-ls-files sensitive_stuff | xargs -d "\n" git-update-index --remove' HEAD
Rewrite 6711f6a50605918326f67ca0c3402eab9a4c8571 (8/8)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
blake^master ~*/sensitive.clone ls
B D
Excellent.
Thanks for the help.
Bill
^ permalink raw reply
* Re: Question on git-filter-branch
From: Mike Hommey @ 2007-11-01 13:34 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18217.53833.710503.667761@lisa.zopyra.com>
On Thu, Nov 01, 2007 at 07:19:05AM -0600, Bill Lear wrote:
> >Just remove .git/refs/original/
>
> Ok, thanks. But, how do I remove the subdirectory?
>
> % rm -rf .git/refs/original
> % git filter-branch --index-filter 'git update-index --remove sensitive_stuff' HEAD
> Rewrite 6711f6a50605918326f67ca0c3402eab9a4c8571 (8/8)
> WARNING: Ref 'refs/heads/master' is unchanged
git-update-index --remove will remove files, not trees, so you need to
use something like
git-ls-files ensitive_stuff | xargs -d "\n" git-update-index --remove
instead.
Mike
^ permalink raw reply
* [PATCH] git-filter-branch.txt: fix a typo.
From: Sergei Organov @ 2007-11-01 13:24 UTC (permalink / raw)
To: git
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/git-filter-branch.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index ba9b4fb..385ecc9 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -219,7 +219,7 @@ git filter-branch --commit-filter '
fi' HEAD
------------------------------------------------------------------------------
-The function 'skip_commits' is defined as follows:
+The function 'skip_commit' is defined as follows:
--------------------------
skip_commit()
--
1.5.3.4
^ permalink raw reply related
* [PATCH] gitweb: Remove CGI::Carp::set_programname() call from t9500 gitweb test
From: Jakub Narebski @ 2007-11-01 13:23 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
It does appear to do nothing; gitweb is run as standalone program
and not as CGI script in this test. This call caused problems later.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
t/t9500-gitweb-standalone-no-errors.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index f7bad5b..1bf0988 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -31,7 +31,6 @@ our \$projects_list = "";
our \$export_ok = "";
our \$strict_export = "";
-CGI::Carp::set_programname("gitweb/gitweb.cgi");
EOF
cat >.git/description <<EOF
--
1.5.3.5
^ permalink raw reply related
* Re: Question on git-filter-branch
From: Bill Lear @ 2007-11-01 13:19 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20071101125845.GA27567@glandium.org>
On Thursday, November 1, 2007 at 13:58:45 (+0100) Mike Hommey writes:
>On Thu, Nov 01, 2007 at 06:55:37AM -0600, Bill Lear wrote:
>> In my repo, I have sensitive files A, C, and a directory full of
>> sensitive stuff I want to remove forever from the git repository.
>>
>> % ls
>> A B C D sensitive_stuff
>>
>> % git --version
>> git version 1.5.3.5
>>
>> % git filter-branch --index-filter 'git update-index --remove A' HEAD
>> Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
>> Ref 'refs/heads/master' was rewritten
>>
>> These refs were rewritten:
>> % ls
>> B C D sensitive_stuff
>>
>> % git status
>> # On branch master
>> nothing to commit (working directory clean)
>>
>> Ok, so I guess it has done what I wanted. So, I try to remove the
>> next file that has sensitive information in it:
>>
>> % git filter-branch --index-filter 'git update-index --remove C' HEAD
>> Namespace refs/original/ not empty
>
>Just remove .git/refs/original/
Ok, thanks. But, how do I remove the subdirectory?
% rm -rf .git/refs/original
% git filter-branch --index-filter 'git update-index --remove sensitive_stuff' HEAD
Rewrite 6711f6a50605918326f67ca0c3402eab9a4c8571 (8/8)
WARNING: Ref 'refs/heads/master' is unchanged
% ls sensitive_stuff
E F G
% git filter-branch --index-filter 'git update-index --remove sensitive_stuff/*' HEAD
Rewrite 6711f6a50605918326f67ca0c3402eab9a4c8571 (8/8)
WARNING: Ref 'refs/heads/master' is unchanged
% ls sensitive_stuff
E F G
% cd sensitive_stuff
% git filter-branch --index-filter 'git update-index --remove E F G' HEAD
fatal: Not a git repository: '.git'
You need to run this command from the toplevel of the working tree.
Bill
^ permalink raw reply
* Re: Managing /etc with git: Store ownership and time in git?
From: Jeff King @ 2007-11-01 13:10 UTC (permalink / raw)
To: Alexander Skwar; +Cc: git
In-Reply-To: <loom.20071101T123817-247@post.gmane.org>
On Thu, Nov 01, 2007 at 12:55:57PM +0000, Alexander Skwar wrote:
> I'd like to use git to manage the /etc directories of some servers.
> What's quite nice with git (in comparison to svn) is, that it
> out-of-the-box stores the permissions of a file. But it doesn't seem
It doesn't; git stores only the executable bit.
> like it stores the ownership (ie. user/group) of tracked content.
> Does anyone know how to cope with that "problem"?
Yes, convert your file metadata into a text format in a file in the
repository, and commit that.
> Oh, and it also seems that Git doesn't store the time information of
> files, does it? For tracking /etc, this would be very useful. Would
> anyone have a solution for this as well?
Same as above.
> What I'm thinking about right now is, to write a "hook" script which
> "dumps" the stats of the to-be added files in some "index" file. But
> that seems like a rather clumsy soltion...
That's more or less the solution that has been advocated. Search in the
list archives for /etc solutions; this topic comes up every few months.
-Peff
^ permalink raw reply
* Re: [PATCH] Don't use cpio in git-clone when not installed
From: Alexander Skwar @ 2007-11-01 13:06 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0710311742170.3342@woody.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
>
>
> On Wed, 31 Oct 2007, Mike Hommey wrote:
> > + if type cpio > /dev/null 2>&1; then
> > + local=yes
> > + fi
>
> Isn't "type" a bashism?
ksh also has type. But SUS states, that "command -v" can be used.
Options
[...]
-v
(On systems supporting the User Portability Utilities option.)
Write a string to standard output that indicates the pathname or
command that will be used by the shell, in the current shell
execution environment (see Shell Execution Environment ), to
invoke command_name, but do not invoke command_name.
* Utilities, regular built-in utilities, command_names
including a slash character, and any implementation-defined
functions that are found using the PATH variable (as
described in Command Search and Execution ), shall be
written as absolute pathnames.
* Shell functions, special built-in utilities, regular
built-in utilities not associated with a PATH search, and
shell reserved words shall be written as just their names.
* An alias shall be written as a command line that represents
its alias definition.
* Otherwise, no output shall be written and the exit status
shall reflect that the name was not found.
Regards,
Alexander
^ permalink raw reply
* Re: Managing /etc with git: Store ownership and time in git?
From: Miklos Vajna @ 2007-11-01 13:09 UTC (permalink / raw)
To: Alexander Skwar; +Cc: git
In-Reply-To: <loom.20071101T123817-247@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Thu, Nov 01, 2007 at 12:55:57PM +0000, Alexander Skwar <listen@alexander.skwar.name> wrote:
> I'd like to use git to manage the /etc directories of some servers.
http://git.or.cz/gitwiki/GitFaq#head-7e70881352ec207609dc4d7eedbd0532946a5825
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Managing /etc with git: Store ownership and time in git?
From: Alexander Skwar @ 2007-11-01 12:55 UTC (permalink / raw)
To: git
Hello.
I'd like to use git to manage the /etc directories of some servers.
What's quite nice with git (in comparison to svn) is, that it
out-of-the-box stores the permissions of a file. But it doesn't seem
like it stores the ownership (ie. user/group) of tracked content.
Does anyone know how to cope with that "problem"?
Oh, and it also seems that Git doesn't store the time information of
files, does it? For tracking /etc, this would be very useful. Would
anyone have a solution for this as well?
What I'm thinking about right now is, to write a "hook" script which
"dumps" the stats of the to-be added files in some "index" file. But
that seems like a rather clumsy soltion...
It would be great of someone could maybe share his solution!
Thanks a lot,
Alexander
^ permalink raw reply
* Re: Question on git-filter-branch
From: Mike Hommey @ 2007-11-01 12:58 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18217.52425.655322.52338@lisa.zopyra.com>
On Thu, Nov 01, 2007 at 06:55:37AM -0600, Bill Lear wrote:
> In my repo, I have sensitive files A, C, and a directory full of
> sensitive stuff I want to remove forever from the git repository.
>
> % ls
> A B C D sensitive_stuff
>
> % git --version
> git version 1.5.3.5
>
> % git filter-branch --index-filter 'git update-index --remove A' HEAD
> Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
> Ref 'refs/heads/master' was rewritten
>
> These refs were rewritten:
> % ls
> B C D sensitive_stuff
>
> % git status
> # On branch master
> nothing to commit (working directory clean)
>
> Ok, so I guess it has done what I wanted. So, I try to remove the
> next file that has sensitive information in it:
>
> % git filter-branch --index-filter 'git update-index --remove C' HEAD
> Namespace refs/original/ not empty
Just remove .git/refs/original/
Mike
^ permalink raw reply
* Question on git-filter-branch
From: Bill Lear @ 2007-11-01 12:55 UTC (permalink / raw)
To: git
In my repo, I have sensitive files A, C, and a directory full of
sensitive stuff I want to remove forever from the git repository.
% ls
A B C D sensitive_stuff
% git --version
git version 1.5.3.5
% git filter-branch --index-filter 'git update-index --remove A' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
% ls
B C D sensitive_stuff
% git status
# On branch master
nothing to commit (working directory clean)
Ok, so I guess it has done what I wanted. So, I try to remove the
next file that has sensitive information in it:
% git filter-branch --index-filter 'git update-index --remove C' HEAD
Namespace refs/original/ not empty
And there I am stuck: what do I do now?
I did also try this (on a fresh clone of the original repo):
% git filter-branch --index-filter 'git update-index --remove A C sensitive_stuff/*' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
% ls
B D sensitive_stuff/
% ls sensitive_stuff
E F G
So, that appears to have removed A and C, but it did nothing to the
files in the subdirectory. Is there a way to remove the files in the
subdirectory --- or, better, to simply remove the entire subdirectory?
I did try reading the man page for this, and the first example is
essentially what I want. It says "you will get the rewritten history
saved in HEAD", but I'm not sure what I'm supposed to do next.
Bill
^ permalink raw reply
* [PATCH] gitweb: Update config file example for snapshot feature in gitweb/INSTALL
From: Jakub Narebski @ 2007-11-01 12:45 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
Commit a3c8ab30a54c30a6a434760bedf04548425416ef by Matt McCutchen
"gitweb: snapshot cleanups & support for offering multiple formats"
introduced new format of $feature{'snapshot'}{'default'} value. Update
"Config file example" in gitweb/INSTALL accordingly.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/INSTALL | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/INSTALL b/gitweb/INSTALL
index 6328e26..9cd5b0a 100644
--- a/gitweb/INSTALL
+++ b/gitweb/INSTALL
@@ -116,7 +116,7 @@ GITWEB_CONFIG file:
$feature{'pickaxe'}{'default'} = [1];
$feature{'pickaxe'}{'override'} = 1;
- $feature{'snapshot'}{'default'} = ['x-gzip', 'gz', 'gzip'];
+ $feature{'snapshot'}{'default'} = ['zip', 'tgz'];
$feature{'snapshot'}{'override'} = 1;
--
1.5.3.5
^ permalink raw reply related
* Re: Newbie: report of first experience with git-rebase.
From: Sergei Organov @ 2007-11-01 12:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhck7gdzs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> On Wed, 31 Oct 2007, Sergei Organov wrote:
>>
>>> Yes, and that's the problem. Why 'git --continue' didn't just skip this
>>> patch that *already became no-op* after conflict resolution and forced
>>> me to explicitly use 'git --skip' instead?
>>
>> Isn't that obvious? To prevent you from accidentally losing a commit.
>
> In case it is not obvious...
>
> A rebase conflict resolution that results in emptiness is a
> rather rare event (especially because rebase drops upfront the
> identical changes from the set of commits to be replayed), but
> it does happen.
Funny how 2 of my first 3 commits suffer from this "rather rare event",
and it was not Friday, 13 ;)
--
Sergei.
^ permalink raw reply
* Re: Bug in git-show-branch, or in core-tutorial?
From: Sergei Organov @ 2007-11-01 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x5ictrx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think that is a simple typo of "these", not "three".
No, the explanation text explicitly mentions merge~1 revision that is
not there in the git-show-branch output, so those "three" is consistent
with explanation text itself, but not with git-show-branch output.
--
Sergei.
^ 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