* [PATCH] Disconnect stash from its base commit
From: Nanako Shiraishi @ 2008-07-02 10:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Olivier Marin
In-Reply-To: <7vskuuoygp.fsf@gitster.siamese.dyndns.org>
A stash records the state of the files in the working tree as a merge
between the HEAD and another commit that records the state of the index,
that in turn is a child commit of the HEAD commit. In order to later
apply (or pop) the stash, however, only the tree objects of these three
commits are necessary.
This patch changes the structure of a stash to use a parentless new commit
that has the same tree as the HEAD commit, in place of the HEAD commit.
This way, a stash does not keep the history that leads to the HEAD commit
reachable, even if the stash is kept forever.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
The patch in the message Olivier quoted alone will be insufficient. This
is an update to that patch.
Documentation/git-stash.txt | 14 +++++++-------
git-stash.sh | 3 +++
t/t3903-stash.sh | 2 +-
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt
index 23ac331..17c65e9 100644
--- a/Documentation/git-stash.txt
+++ b/Documentation/git-stash.txt
@@ -101,18 +101,18 @@ DISCUSSION
----------
A stash is represented as a commit whose tree records the state of the
-working directory, and its first parent is the commit at `HEAD` when
-the stash was created. The tree of the second parent records the
+working directory, and its first parent is the commit that has the same
+tree as the `HEAD`. The tree of the second parent records the
state of the index when the stash is made, and it is made a child of
-the `HEAD` commit. The ancestry graph looks like this:
+the first commit. The ancestry graph looks like this:
.----W
/ /
- -----H----I
+ H*---I
-where `H` is the `HEAD` commit, `I` is a commit that records the state
-of the index, and `W` is a commit that records the state of the working
-tree.
+where `H{asterisk}` is a commit with the same tree as the `HEAD`, `I` is
+a commit that records the state of the index, and `W` is a commit that
+records the state of the working tree.
EXAMPLES
diff --git a/git-stash.sh b/git-stash.sh
index 4938ade..8f374b3 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -54,6 +54,9 @@ create_stash () {
fi
msg=$(printf '%s: %s' "$branch" "$head")
+ # create the base commit that is parentless
+ b_commit=$(printf 'base of %s\n' "$msg" | git commit-tree "HEAD:")
+
# state of the index
i_tree=$(git write-tree) &&
i_commit=$(printf 'index on %s\n' "$msg" |
diff --git a/t/t3903-stash.sh b/t/t3903-stash.sh
index 54d99ed..b083c04 100755
--- a/t/t3903-stash.sh
+++ b/t/t3903-stash.sh
@@ -32,7 +32,7 @@ index 0cfbf08..00750ed 100644
EOF
test_expect_success 'parents of stash' '
- test $(git rev-parse stash^) = $(git rev-parse HEAD) &&
+ test $(git rev-parse stash^^{tree}) = $(git rev-parse HEAD^{tree}) &&
git diff stash^2..stash > output &&
test_cmp output expect
'
--
1.5.6
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* [PATCH/rfc] gitweb: open files (e.g. indextext.html) in utf8 mode
From: Gerrit Pape @ 2008-07-02 12:13 UTC (permalink / raw)
To: git, Junio C Hamano
From: =?utf-8?q?Recai=20Okta=C5=9F?= <roktas@debian.org>
gitweb used to use utf8 only in stdout. As a result, included files
like indextext.html appeared garbled if they contain utf8 characters.
Now utf8 is also used when reading files.
The patch was submitted through
http://bugs.debian.org/487465
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
gitweb/gitweb.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..96cb4e0 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -16,7 +16,7 @@ use Encode;
use Fcntl ':mode';
use File::Find qw();
use File::Basename qw(basename);
-binmode STDOUT, ':utf8';
+use open qw(:std :utf8);
BEGIN {
CGI->compile() if $ENV{'MOD_PERL'};
--
1.5.6
^ permalink raw reply related
* how do I remove a tag on a remote repository I pushed to ?
From: Christian MICHON @ 2008-07-02 12:52 UTC (permalink / raw)
To: Git Mailing List
Hi,
I've a repo on github and apparently I used characters not accepted by
github web interface (if I clone the repo, it's ok).
This is a repo where I push to.
I've seen here how to remove remote branches, but was there any hint
on how to perform the same removal on remote tags ?
Thanks in advance.
--
Christian
--
http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside !
^ permalink raw reply
* Re: [PATCH] git-add--interactive: manual hunk editing mode
From: Johannes Schindelin @ 2008-07-02 13:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Thomas Rast, git
In-Reply-To: <20080702083214.GA22301@sigill.intra.peff.net>
Hi,
On Wed, 2 Jul 2008, Jeff King wrote:
> On Wed, Jul 02, 2008 at 01:08:09AM -0700, Junio C Hamano wrote:
>
> > > So if the problem is "old perl", I don't think it is an issue. Are
> > > there modern perl installations in the wild that don't have
> > > File::Temp?
> >
> > The thing is, I think I heard quite similar explanation why Test::More
> > is safe to use when the patch to add t/t9700 was submit. Then what
> > happened?
>
> ISTR the Test::More problem was reported by Linus, who is a Fedora user?
> I tried searching for any reasonable information on which of the core
> perl modules are installed by default on Fedora systems, but didn't come
> up with anything useful.
>
> I really have no clue as to what is out there, and I suspect we must
> either play it totally safe, or push the limits and wait for people to
> complain about breakage.
I wonder why bother trying to import things when you do not need them to
begin with! I mean, it is _obvious_ that in this case, we want .git/ to
be writable _anyway_, so why not stick with a fixed name in that?
Ciao,
Dscho
^ permalink raw reply
* Re: how do I remove a tag on a remote repository I pushed to ?
From: Miklos Vajna @ 2008-07-02 13:24 UTC (permalink / raw)
To: Christian MICHON; +Cc: Git Mailing List
In-Reply-To: <46d6db660807020552x400b8f3x81f8bf6970729b0c@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 269 bytes --]
On Wed, Jul 02, 2008 at 02:52:58PM +0200, Christian MICHON <christian.michon@gmail.com> wrote:
> I've seen here how to remove remote branches, but was there any hint
> on how to perform the same removal on remote tags ?
The same way:
git push origin :refs/tags/mytag
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] completion.bash: add 'skip' and 'run' to git-bisect
From: Dmitry Potapov @ 2008-07-02 13:29 UTC (permalink / raw)
To: Git Mailing List; +Cc: Dmitry Potapov
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
contrib/completion/git-completion.bash | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index ebf7cde..3d15434 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -511,7 +511,7 @@ _git_add ()
_git_bisect ()
{
- local subcommands="start bad good reset visualize replay log"
+ local subcommands="start bad good skip reset visualize replay log run"
local subcommand="$(__git_find_subcommand "$subcommands")"
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
@@ -519,7 +519,7 @@ _git_bisect ()
fi
case "$subcommand" in
- bad|good|reset)
+ bad|good|reset|skip)
__gitcomp "$(__git_refs)"
;;
*)
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH] completion.bash: add 'skip' and 'run' to git-bisect
From: Shawn O. Pearce @ 2008-07-02 13:35 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Git Mailing List
In-Reply-To: <1215005390-1506-1-git-send-email-dpotapov@gmail.com>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Keeping up with the subcommands is a challenge. ;-)
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index ebf7cde..3d15434 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -511,7 +511,7 @@ _git_add ()
>
> _git_bisect ()
> {
> - local subcommands="start bad good reset visualize replay log"
> + local subcommands="start bad good skip reset visualize replay log run"
> local subcommand="$(__git_find_subcommand "$subcommands")"
> if [ -z "$subcommand" ]; then
> __gitcomp "$subcommands"
> @@ -519,7 +519,7 @@ _git_bisect ()
> fi
>
> case "$subcommand" in
> - bad|good|reset)
> + bad|good|reset|skip)
> __gitcomp "$(__git_refs)"
> ;;
> *)
> --
--
Shawn.
^ permalink raw reply
* Re: [PATCH/rfc] gitweb: open files (e.g. indextext.html) in utf8 mode
From: Jakub Narebski @ 2008-07-02 13:37 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Junio C Hamano, Recai Oktaş
In-Reply-To: <20080702121317.10819.qmail@bca5b84cb0e0a0.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> From: =?utf-8?q?Recai=20Okta=C5=9F?= <roktas@debian.org>
You don't need to use quoted-printable in 'From:' header embedded in
the mail body. It should probably read
From: "Recai Oktaş" <roktas@debian.org>
(provided that you can use utf-8 in email).
> gitweb used to use utf8 only in stdout. As a result, included files
> like indextext.html appeared garbled if they contain utf8 characters.
> Now utf8 is also used when reading files.
It would better read as:
Gitweb used to use utf8 mode only on STDOUT (actually ":utf8" output
layer), relying on using to_utf8(...) to convert input data from uft8
to Perl internal form. As a result, included files such as $home_text
(indextext.html in default build configuration), or repository's
README.html appeared garbled if they did contain UTF-8 characters.
Now uft8 mode is used for all open invovations, also when reading files.
> The patch was submitted through
> http://bugs.debian.org/487465
>
Probably should have here
Reported-by: Recai Oktaş <roktas@debian.org>
> Signed-off-by: Gerrit Pape <pape@smarden.org>
> ---
> gitweb/gitweb.perl | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 90cd99b..96cb4e0 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -16,7 +16,7 @@ use Encode;
> use Fcntl ':mode';
> use File::Find qw();
> use File::Basename qw(basename);
> -binmode STDOUT, ':utf8';
> +use open qw(:std :utf8);
>
> BEGIN {
> CGI->compile() if $ENV{'MOD_PERL'};
It would be wonderfull if such simple solution worked. We would be
then able to remove to_utf8() subroutine and do not worry that we
forgot to convert some string to Perl internal encoding, which could
result to curring wide (non US-ASCII) UTF-8 character to be cut in
half. (On the other hand we wouldn't have $fallback_encoding).
Unfortunately there are two problem (or rather a problem and a half)
with this approach.
First is that with this patch gitweb doesn't pass gitweb test
t/t9500-gitweb-standalone-no-errors.sh (this is with perl v5.8.6)
* ok 63: encode(commit): utf8
* ok 64: encode(commit): iso-8859-1
* ok 65: encode(log): utf-8 and iso-8859-1
[...]
* FAIL 71: URL: no project URLs, no base URL
gitweb_run "p=.git;a=summary"
[Wed Jul 2 13:10:15 2008] gitweb.perl: utf8 "\xC4" does not map to Unicode \
at /path/to/git/t/trash directory/../../gitweb/gitweb.perl line 2298, \
<$fd> line 1.
[Wed Jul 2 13:10:15 2008] gitweb.perl: Malformed UTF-8 character \
(unexpected end of string) at [...]/gitweb/gitweb.perl line 2303, \
<$fd> line 1.
which is
open my $fd, '-|', git_cmd(), 'for-each-ref',
($limit ? '--count='.($limit+1) : ()), '--sort=-committerdate',
'--format=%(objectname) %(refname) %(subject)%00%(committer)',
'refs/heads'
or return;
2298: while (my $line = <$fd>) {
my %ref_item;
chomp $line;
my ($refinfo, $committerinfo) = split(/\0/, $line);
2303: my ($hash, $name, $title) = split(' ', $refinfo, 3);
Second, what is minimal Perl version and Perl configuration (installed
modules) that support "use open qw(:std :utf8);"? We do have some
minimal requirements for gitweb, and it would be nice if we didn't add
to them. But we already require PerlIO, so it probably doesn't matter.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git push requires a subsequent git reset --hard ?
From: Dmitry Potapov @ 2008-07-02 13:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Neshama Parhoti, git
In-Reply-To: <m3vdzpfr16.fsf@localhost.localdomain>
On Tue, Jul 01, 2008 at 10:29:38AM -0700, Jakub Narebski wrote:
>
> This is considered normal. Push would never touch index nor working
> area (although if you are the only user, and you know what you are
> doing, you can add "git reset --hard HEAD" to post-receive hook).
Doing "reset --hard" makes all your uncommit changes to be lost.
OTOH, if you push on the local branch assotiated with HEAD then
recovering all uncommit changes later will not be easy either. So,
I wonder, if git push should require --force if you want to push
to the HEAD branch of a non-bare repo. It will be at least some
warning (especially for novices) to not to do that, and those who
really want to understand what they are doing can use --force.
Dmitry
^ permalink raw reply
* Re: git push requires a subsequent git reset --hard ?
From: Dmitry Potapov @ 2008-07-02 13:45 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Neshama Parhoti, git
In-Reply-To: <m3vdzpfr16.fsf@localhost.localdomain>
On Tue, Jul 01, 2008 at 10:29:38AM -0700, Jakub Narebski wrote:
>_
> This is considered normal. Push would never touch index nor working
> area (although if you are the only user, and you know what you are
> doing, you can add "git reset --hard HEAD" to post-receive hook).
Doing "reset --hard" makes all your uncommitted changes to be lost.
OTOH, if you push on the local branch associated with HEAD then
recovering all uncommitted changes later will not be easy either. So,
I wonder, if git push should require --force to push to HEAD of a
non-bare repository. It will be at least some warning (especially for
novices) to not to do that, and those who understand what they are
doing can use --force.
Dmitry
^ permalink raw reply
* Re: [PATCH] Disconnect stash from its base commit
From: Johannes Schindelin @ 2008-07-02 13:51 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Git Mailing List, Olivier Marin
In-Reply-To: <20080702195947.6117@nanako3.lavabit.com>
Hi,
On Wed, 2 Jul 2008, Nanako Shiraishi wrote:
> A stash records the state of the files in the working tree as a merge
> between the HEAD and another commit that records the state of the index,
> that in turn is a child commit of the HEAD commit. In order to later
> apply (or pop) the stash, however, only the tree objects of these three
> commits are necessary.
>
> This patch changes the structure of a stash to use a parentless new
> commit that has the same tree as the HEAD commit, in place of the HEAD
> commit. This way, a stash does not keep the history that leads to the
> HEAD commit reachable, even if the stash is kept forever.
May I register my suspicion that this is the wrong direction to go?
I actually find it quite nice that I can easily see in gitk where I
spawned off a certain stash, indeed, how the recent stash history
(manually specified with "stash@{0} stash@{1} stash@{2}" [*1*]), relates
to the current branch's history.
Ciao,
Dscho
P.S.: I vaguely remember that I once wrote a patch to turn "stash@{0..2}"
into exactly the same, but I do not remember why I did not follow up on
it. Was it refuted, or unwanted?
^ permalink raw reply
* Re: [PATCH 02/12] Do not complain about "no common commits" in an empty repo
From: Steffen Prohaska @ 2008-07-02 14:04 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: Johannes Sixt, Git Mailing List, msysGit
In-Reply-To: <7vskusd5nr.fsf@gitster.siamese.dyndns.org>
On Jul 2, 2008, at 10:58 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> From: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> If the repo is empty, we know that already, thank you very much.
>> So shut fetch-pack up about that case.
>
> Two complaints.
You are right, although I didn't intend to "hide" the patch. I just
went through the differences between the mainline and 4msysgit and
collected a patch series with all changes I found. I sent this series
to the list, so that the remaining differences do not get lost
unrecognized.
I didn't mean to bother you with incomplete patches. Maybe I should
have made my intention clearer by prefixing the subject lines with
WIP (or something similar). Apologies.
> * What does this have to do with Windows port? Please don't hide a
> general interface change in a larger and mostly unrelated topic.
I remember that users of msysgit's net installer complaint about this
warning. The warning appeared as part of the output of a sequence of
automatically executed commands. Without context, the users did not
understand what the warning means.
> * Do you think people can tell without reading the code in larger
> context
> outside the patch and this commit log text if you are talking
> about the
> case you fetch _into_ an empty repository, or if you are
> attempting to
> fetch _from_ an empty repository, or what? Please try to be a bit
> easier for _readers_. Being more redundant and verbose is better
> than
> being too concise.
>
> About the first point, "no common commits" is just a friendly
> reminder and
> not even an error. When you see it, you will learn to expect
> looooooooong
> download session.
>
> I personally happen to agree with the logic of this patch, though
> --- if
> you are fetching into an empty repository, you would already expect
> that
> the download is as big as the other end anyway, so you would not
> need to
> be further reminded about that.
>
> But that is just one-man's opinion. Maybe somebody knows a reason
> why I
> am (and the logic I am agreeing with is) wrong. Maybe not. So make
> the
> "remainder of Windows port" series 11 commits, and send this as a
> general
> interface fix via the normal channel to be discussed, please.
Dscho, will you send it? You are the original author.
Steffen
^ permalink raw reply
* [PATCH] Documentation: Point to gitcli(7) from git(1)
From: Brian Gernhardt @ 2008-07-02 14:13 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
---
Documentation/git.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index f9e4416..2b20b0d 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -601,7 +601,7 @@ SEE ALSO
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
linkgit:giteveryday[7], linkgit:gitcvs-migration[7],
linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
-link:user-manual.html[The Git User's Manual]
+linkgit:gitcli[7], link:user-manual.html[The Git User's Manual]
GIT
---
--
1.5.6.1.243.g6b82b
^ permalink raw reply related
* Re: [PATCH 08/12] fast-import: MinGW does not have getppid(). So do not print it.
From: Steffen Prohaska @ 2008-07-02 14:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git, msysgit, Johannes Schindelin
In-Reply-To: <7vzlp0bq2l.fsf@gitster.siamese.dyndns.org>
On Jul 2, 2008, at 11:20 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> diff --git a/fast-import.c b/fast-import.c
>> index e72b286..271b93c 100644
>> --- a/fast-import.c
>> +++ b/fast-import.c
>> @@ -391,7 +391,9 @@ static void write_crash_report(const char *err)
>>
>> fprintf(rpt, "fast-import crash report:\n");
>> fprintf(rpt, " fast-import process: %d\n", getpid());
>> +#ifndef __MINGW32__
>> fprintf(rpt, " parent process : %d\n", getppid());
>> +#endif
>> fprintf(rpt, " at %s\n", show_date(time(NULL), 0, DATE_LOCAL));
>> fputc('\n', rpt);
>>
>> --
>> 1.5.6.1.255.g32571
>
> It does not matter too much for this part that writes crash report,
> but
> keeping the file format the same across platforms will make it
> easier for
> tools to read output, so as a general principle, I think this is a
> suboptimal solution to the issue. How about throwing something like
> this
> in MinGW specific header files?
>
> #define getppid() 0
Hannes added something similar to the compat layer, so this commit
is no longer needed. I'll remove it from the series and revert it
in 4msysgit.
Steffen
^ permalink raw reply
* Re: [PATCH 11/12] verify_path(): do not allow absolute paths
From: Steffen Prohaska @ 2008-07-02 14:24 UTC (permalink / raw)
To: Johannes Sixt
Cc: Git Mailing List, msysGit, Junio C Hamano, Johannes Schindelin
In-Reply-To: <7vvdzobq0k.fsf@gitster.siamese.dyndns.org>
On Jul 2, 2008, at 11:21 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> No commit log message? Justification?
Hannes,
Do we still need this change in verify_path(). I am not sure.
Maybe it should be reverted in 4msysgit?
Steffen
^ permalink raw reply
* Re: [PATCH 04/12] Avoid calling signal(SIGPIPE, ..) for MinGW builds.
From: Steffen Prohaska @ 2008-07-02 14:29 UTC (permalink / raw)
To: Marius Storm-Olsen, Junio C Hamano
Cc: Johannes Sixt, Git Mailing List, msysGit, Marius Storm-Olsen
In-Reply-To: <486B5263.1060805@storm-olsen.com>
On Jul 2, 2008, at 12:03 PM, Marius Storm-Olsen wrote:
> Junio C Hamano said the following on 02.07.2008 11:22:
>> Steffen Prohaska <prohaska@zib.de> writes:
>>> From: Marius Storm-Olsen <mstormo_git@storm-olsen.com>
>>>
>>> SIGPIPE isn't supported in MinGW.
>> Shouldn't #ifdef be on SIGPIPE not on __MINGW32__?
>
> That's certainly a good suggestion. :-)
I reverted this in 4msysgit and will remove the patch from the
series.
Steffen
^ permalink raw reply
* RFC: grafts generalised
From: Stephen R. van den Berg @ 2008-07-02 14:35 UTC (permalink / raw)
To: git
I'm in the process of converting and stitching and patching vast amounts
of initially disjunct CVS and SVN repositories into larger complete
histories inside a single git repository. Recreating history as
accurately as possible.
The problem I encounter is that any number of times I have to "edit"
history in a non-parameterable fashion, in any of the following ways:
- Change parents.
- Add merges.
- Change author, committer, commitdate, authordate.
- Change the tree (because of conversion errors in the automated
conversion process) belonging to a single commit.
- Retrofit a patch which has to ripple through all of history until
the present.
The only things which are easily done at the moment are:
Change parents and add merges. This can be accomplished fairly easily
using the grafts file.
The other changes are messy at best and need to be parameterised into the
form of a shell script so that git filter-branch can have a go at it.
This parameterisation is doable for author/committer/dates in most cases
(but not pretty), but is rather (too) convoluted for ripple-through
patches.
You have to imagine that the whole tree has lots of interconnects
already (merges), and changing the tree at a point in history which has
to ripple through is a mess, because all references and interconnects
need to be rewritten as well.
I propose the following:
- Extend git fsck to do more sanity checks on the content of the grafts
file (to make it more difficult to shoot yourself in the foot with
that file; my feet will be grateful).
- Extend the grafts file format to support something like the following syntax:
commit eb03813cdb999f25628784bb4f07b3f4c8bfe3f6
Parent: 7bc72e647d54c2f713160b22e2e08c39d86c7c28
Merge: 3b3da24960a82a479b9ad64affab50226df02abe 13b8f53e8ccec3b08eeb6515e6a10a2a
Merge: ac719ed37270558f21d89676fce97eab4469b0f1
Tree: 32fc99814b97322174dbe97ec320cf32314959e2
Author: Foo Bar (FooBar) <foo@bar>
AuthorDate: Sat Jun 6 13:50:44 1998 +0000
Commit: Foo Bar (FooBar) <foo@bar>
CommitDate: Sat Jun 7 13:50:44 1998 +0000
Logmessage: First line of logmessage override
Logmessage: Second line of logmessage override
Logmessage: Etc.
- Whereas not specified fields default to not altering the commit for
those fields.
E.g.
commit eb03813cdb999f25628784bb4f07b3f4c8bfe3f6
Parent: 7bc72e647d54c2f713160b22e2e08c39d86c7c28
Would alter just the parent, nothing else.
- Keep backward compatibility with the old format.
Obviously, the use case for this is to change the tree as needed, then
run git filter-branch to actually get things in permanently, after which
it becomes clonable.
--
Sincerely,
Stephen R. van den Berg.
You are confused; but this is your normal state.
^ permalink raw reply
* Re: [PATCH 3/3] git-branch -v: show the remote tracking statistics
From: Brian Gernhardt @ 2008-07-02 14:44 UTC (permalink / raw)
To: Karl Hasselström
Cc: Johannes Sixt, Junio C Hamano, Ingo Molnar, Bruce Stephens, git
In-Reply-To: <20080702083306.GA28337@diana.vm.bytemark.co.uk>
On Jul 2, 2008, at 4:33 AM, Karl Hasselström wrote:
> On 2008-07-02 10:23:33 +0200, Johannes Sixt wrote:
>
>> * jc/report-tracking 41666f7 diverged 3 vs. 117
>
> Or even "ahead 3, behind 117" here. Otherwise the user has to remember
> which number is which, which kind of defeats your point. And it's just
> one more character.
>
>> foo 1234567 behind 22
>> bar fedcba9 ahead 6
This is probably the most useful for a new user. The short version of
that (config option to give it for power users and hide it from those
it would confuse) should use plus and minus for ahead and behind:
* jc/report-tracking 41666f7 [+3 -117] git-branch -v: show
the remo...
I can't follow the code with the ten seconds I have to look at it. Is
this ahead/behind current branch, tracking branch, or other?
~~ Brian
^ permalink raw reply
* Re: [RFC] Single system account for multiple git users
From: Dmitry Potapov @ 2008-07-02 14:45 UTC (permalink / raw)
To: Melchior FRANZ; +Cc: git
In-Reply-To: <200807011055.51738@rk-nord.at>
On Tue, Jul 01, 2008 at 10:55:50AM +0200, Melchior FRANZ wrote:
>
> Indeed. This is AFAIK the main reason why git might not be used
> by a project where I'm contributor. gitosis could help here, but
> I guess that a built-in solution would be preferred. An external
> addon looks a bit like band-aid. ;-)
Yes, and they impose some its own access control model, which is
different to what you normally have using git-shell. So, the purpose
of my patch was to provide the absolutely minimal change to git-shell
which allows to have a central Git server with multiple Git users under
one system account. I guess that most Git developers do not use Git in
this configuration, so they are not very interested in this patch. But
there are projects where having a central repo is strict requirement
(usually justified by having centralized place to backup all sources,
difficult exchanging patches by email especially in great volume, and
impossibility direct connection due to firewalls, etc...).
So, I believe that my patch (or something simple like that) could help
Git with wider adaptation.
Thanks,
Dmitry
^ permalink raw reply
* Re: How do I stop git enumerating my working directory
From: Paul Gardiner @ 2008-07-02 14:47 UTC (permalink / raw)
To: Glenn Griffin, git, lists
In-Reply-To: <c9e534200807011002q45ffca7bq8d91cd9b62335796@mail.gmail.com>
Glenn Griffin wrote:
> On Tue, Jul 1, 2008 at 8:57 AM, Paul Gardiner <lists@glidos.net> wrote:
>> Hi,
>>
>> I'm a recent convert to git. I've been swapping over my projects
>> from cvs to git. The latest candidate for conversion is the
>> config files for my Linux server. I've been using cvs to record
>> all the config changes, and - mostly-automatically - to setup
>> new servers. Git will do a far better job, I think, but
>> I think I'm going to run into a problem: the root directory
>> of the server will be the working directory. Only relatively
>> few files will be under version control. How do I stop git
>> enumerating the whole drive whenever I do things like git-diff?
>
> I'm doing a similar thing in my home directory where the vast majority of files
> are not being tracked, but only a select few are. I've found that git
> automatically handles this case much better than other SCM's like subversion
> because of it's concept of the index. Most of git's commands wont enumerate
> your directory they will first read the index to see what files it's interested
> in, and then do an lstat on those files to see which if any have changed.
> git-diff in particular should do this to my knowledge. git-status is one of
> the few commands that will actually enumerate your directory to tell you which
> files are untracked, so long as you use status with care you will probably find
> you don't need to do anything special or even setup
> a .gitignore.
>
> Like I said, that's my experience your's may vary.
Brilliant! I've now tried it and it does just as you say. I don't
need git-status so it's just fine. Thanks for the advice.
P.
^ permalink raw reply
* git describe --tags --long barfs on new tags?
From: Mark Burton @ 2008-07-02 14:45 UTC (permalink / raw)
To: git
Howdy folks,
Discovered this today:
~/git[master]$ git tag mb
~/git[master]$ git describe
v1.5.6.1-156-ge903b40
~/git[master]$ git describe --tags
mb
~/git[master]$ git describe --tags --long
Segmentation fault (core dumped)
Hope this is useful info.
BTW - just started using git and I am very impressed with it - took me a while to get my head around the "index" but now I wonder what the problem was.
Cheers,
Mark
^ permalink raw reply
* Re: How do I stop git enumerating my working directory
From: Paul Gardiner @ 2008-07-02 14:51 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, lists
In-Reply-To: <vpqr6ad5zms.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Paul Gardiner <lists@glidos.net> writes:
>
>> I don't think I can make .gitignore files do the job, because
>> it seems that you can set up to ignore a whole directory,
>> and then partially countermand that by placing a .gitignore
>> file (containing ! commands) inside the directory.
>
> To me, it seems the opposite ;-).
>
> I just tried to "git init" my $HOME, then "git status" takes forever,
> but "echo '*' > .gitignore; git status" completes immediately.
Ok, I was confusing myself because of having added files inside
subdirectories of the ignored directory. I'm glad it works the
way it does. Makes much more sense than what I'd thought it was
doing.
P.
^ permalink raw reply
* [PATCH] prevent checkout from creating branches that start with a dash
From: Bart Trojanowski @ 2008-07-02 15:01 UTC (permalink / raw)
To: Git Mailing List
It was previously possible to create a -f branch with git-checkout, which
could not be used or deleted.
$ git checkout -b -f master
Switched to a new branch "-f"
Signed-off-by: Bart Trojanowski <bart@jukie.net>
---
branch.c | 11 +++++++++++
branch.h | 5 +++++
builtin-checkout.c | 4 ++++
3 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/branch.c b/branch.c
index 56e9492..c25e362 100644
--- a/branch.c
+++ b/branch.c
@@ -170,3 +170,14 @@ void remove_branch_state(void)
unlink(git_path("MERGE_MSG"));
unlink(git_path("SQUASH_MSG"));
}
+
+int validate_branch_name(const char *branch_name)
+{
+ if (!*branch_name)
+ return -1;
+
+ if (*branch_name == '-')
+ return -1;
+
+ return 0;
+}
diff --git a/branch.h b/branch.h
index 9f0c2a2..13999ba 100644
--- a/branch.h
+++ b/branch.h
@@ -21,4 +21,9 @@ void create_branch(const char *head, const char *name, const char *start_name,
*/
void remove_branch_state(void);
+/*
+ * Check if the branch name given is well formed. Returns 0 on success.
+ */
+int validate_branch_name(const char *branch_name);
+
#endif
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 93ea69b..f425646 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -553,6 +553,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (opts.force && opts.merge)
die("git checkout: -f and -m are incompatible");
+ if (opts.new_branch && validate_branch_name(opts.new_branch))
+ die("git checkout: '%s' does not look like a valid branch name",
+ opts.new_branch);
+
if (argc) {
const char **pathspec = get_pathspec(prefix, argv);
--
1.5.6.1.109.ga974cd.dirty
^ permalink raw reply related
* Re: [PATCH] prevent checkout from creating branches that start with a dash
From: Brian Gernhardt @ 2008-07-02 15:22 UTC (permalink / raw)
To: Bart Trojanowski; +Cc: Git Mailing List
In-Reply-To: <20080702150128.GH26300@jukie.net>
On Jul 2, 2008, at 11:01 AM, Bart Trojanowski wrote:
> + if (opts.new_branch && validate_branch_name(opts.new_branch))
> + die("git checkout: '%s' does not look like a valid branch name",
> + opts.new_branch);
> +
> if (argc) {
> const char **pathspec = get_pathspec(prefix, argv);
Perhaps this should have !opts.force in that if? That way if someone
needs something like "-mm" branch, they can have it.
And that way, if people really want to shoot themselves in the foot
with a -f branch, they can? "git branch -f -b -f"?
~~ Brian
^ permalink raw reply
* Re: [PATCH] prevent checkout from creating branches that start with a dash
From: Johannes Sixt @ 2008-07-02 15:38 UTC (permalink / raw)
To: Bart Trojanowski; +Cc: Git Mailing List
In-Reply-To: <20080702150128.GH26300@jukie.net>
Bart Trojanowski schrieb:
> It was previously possible to create a -f branch with git-checkout, which
> could not be used or deleted.
>
> $ git checkout -b -f master
> Switched to a new branch "-f"
"-f" *is* a valid branch name and can be used and deleted:
$ git checkout -b -f next
Switched to a new branch "-f"
$ git checkout next
Switched to branch "next"
Your branch is ahead of the tracked remote branch 'origin/next' by 2 commits.
$ git checkout -- -f
Switched to branch "-f"
$ git checkout next
Switched to branch "next"
Your branch is ahead of the tracked remote branch 'origin/next' by 2 commits.
$ git branch -d -- -f
Deleted branch -f.
-- Hannes
^ 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